Les Smart Contracts sont de courts programmes installés directement sur tous les nœuds d’un réseau Blockchain. Ces Smart Contracts sont exécutés uniquement lorsque plusieurs conditions sont rassemblées. Et c’est lors de l’exécution que l’information contenue dans la Blockchain sera directement mis à jour. La forme que prennent les Smart Contracts peut différer d’une de DLT (Distributed Ledger Technologie) à une autre.

Par exemple, les Smart Contracts avec le Framework et plateforme Ethereum sont écris en Solidity tandis que ceux de Hyperledger sont développés en Go et sont appelés Chaincode.

Dans cet article nous discuterons des particularités de ces Smart Contracts avec tout d’abord un point de vue fonctionnel puis nous évoquerons une dimension plus technique de ces derniers axé sur la sécurité du Smart Contract. Tout ceci dans l’objectif de pouvoir répondre à la question de la nécessité du Smart Contract dans le déploiement d’un système « blockchainisé ».

Pourquoi les Smart Contracts ?

Un Smart Contracts peut être comparé à un contrat physique typique. Quand plusieurs parties arrivent à un commun accord sur un ensemble de termes, cet accord est formalisé sous la forme d’un contrat entre les parties. Et nous devons faire face à des contrats tous les jours, ces contrats peuvent prendre de nombreuses formes. Quand j’achète un ticket de cinéma, lorsque que le paiement est accepté, je vais recevoir un reçu papier avec lequel je peux entrer dans la salle et voir le film pour lequel j’ai payé. Le contrat est une des choses qui est à la base de la plupart de nos interactions sociales.

Mais comment puis-je être certain de l’application de ces contrats de tous les jours ? Comment puis-je être sûre que le morceau de papier que le cinéma m’a fourni est valide ? Plus généralement quand des contrats sont impliqués dans nos interactions, il est important de garantir que toutes les parties concernées respectent leur part du marché.

Et quand est-il de la transparence ? Peut-être que le cinéma n’est pas autorisé à diffuser le film pour lequel j’ai payé… Plus généralement, quand nous essayons d’arriver à un arrangement avec un tiers, on ne peut pas être sûrs qu’ils n’ont pas de données sensibles qui pourraient faire changer drastiquement les termes du futur contrat. Il n’y a pas non plus de règles universelles à propos de la mise en place de contrat. Je peux acheter mon ticket directement au cinéma ou passer par internet. Cela dépend, entre-autre, fortement du contexte mais aussi de la culture, de la juridiction et bien plus. Et c’est dans ces cas-là que les Smart Contracts se sont imposés comme une solution à ces problématiques. L’idée est d’utiliser des programmes pour assurer l’application des termes d’un contrat mais aussi de la transparence et de la protection contre la fraude.

Vous allez me dire qu’actuellement il existe des déjà des programmes qui donnent la possibilité de faciliter la création de contrat entre certaines entités, avec l’adoption d’internet par exemple, et que ceci est devenu quelque chose d’assez commun. C’est exact, mais la plupart du temps, seule une des parties aura une main mise supérieure aux autres. Il sera nécessaire de faire confiance à la personne offrant son service et/ou produit. Il est nécessaire d’avoir une certaine confiance en termes de sécurité de la donnée, et de l’application des termes du contrats, etc. Actuellement, les processus digitaux manquent cruellement de décentralisation et de transparence, c’est pourquoi les Smarts Contracts en association avec la blockchain pourraient être un moyen de remédier à cela.

Donc à la question, a-t-on besoin des Smart Contracts ? Je répondrai à cette question par une autre question : a-t-on besoin d’assurer l’application des termes de nos contrats en assurant transparence et décentralisation ? Si ce n’est pas le cas, il sera difficile de proposer un Smart Contracts parce que ce type de programme manque de beaucoup d’autres choses, comme la puissance de calcul.

Il est important de comprendre et de mesurer le coût en fonction du bénéfice d’une utilisation des Smart Contracts pour la résolution de certaines problématiques.

Évidemment, les Smart Contracts sont juste des programmes informatiques, donc ils ne peuvent pas forcer quiconque à honorer leur part d’un contrat particulièrement à l’extérieur des pays avec des hauts niveaux de confiance et de tradition démocratique. Mais dans la plupart des cas, les Smart Contracts et la Blockchain peuvent à minima ajouter du poids à la légitimité de votre parole en fonction de ce qui est stocké sur cette Blockchain en particulier.

Dans le cas d’une chaine de propriété, il est possible de savoir à n’importe quel moment qui est la personne qui détient quelque chose en particulier. Mais bien sûr, cela doit bien commencer quelque part, et il faudra donc croire en premier lieu à une entité qui peut tout à fait être un gouvernement par exemple.

Les Smart Contracts peuvent permettre de distinguer plusieurs étapes dans le cycle de vie d’un actif assurant ainsi par exemple un maximum de véracité en cas de litige.

Un autre exemple de possibilité est que lorsque j’achète un objet, l’argent que j’ai utilisé ne sera pas disponible pour aucune des parties jusqu’à ce que je reçoive l’objet. Encore une fois ici, le Smart Contract ne peut pas me forcer à débloquer la somme pour le vendeur mais je ne pourrais pas non plus la récupérer. Tout ce que j’obtiendrai sera une réputation ruinée, et il faut savoir que la réputation est un point important dans le monde commercial.

Les Smart Contracts pourront se trouver une place de choix dans le monde des systèmes d’information. Mais cela prendra du temps et demandera des efforts avant que nous arrivions au point que l’utilisation de Smart Contracts devienne une norme. Plus on s’attardera à appliquer la Blockchain et les Smart Contracts à la gestion d’actifs et de processus, plus tôt on pourra en tirer un maximum de profit. Bien qu’au début les Smart Contract ne pourront pas permettre de sécuriser rapidement les transactions, une approbation extérieure et non informatique sera probablement nécessaire, et il est possible que l’on arrive à une situation où la gestion sera assurée de bout en bout par la Blockchain.

Smart Contracts and Turing-Complétude

Turing-complet est une propriété des langages de programmation. Il est dit qu’avec ce type de langage, il est possible d’exprimer et d’implémenter tout type de calcul et même de simuler tous les autres langages. Et lorsqu’on parle de n’importe quel calcul, on peut souvent entendre que : « avec un espace et un temps infini, il est possible de simuler l’univers avec un langage Turing-Complet » (Voir https://xkcd.com/505/).

Généralement, ces langages sont fortement typés et sont vérifiés statiquement. Les langages Turing-Complet sont tellement répandus qu’ils apparaissent même dans les systèmes les plus simples.

La Turing-Complétude est lié au principe de décidabilité. On peut tout simplement se demander si oui ou non un problème peut être résolu ou calculé par un algorithme. Ou encore plus trivialement, de savoir si un programme s’arrête faisant référence au « problème de l’arrêt ».

D’après le théorème de Rice, il n’existe pas de procédure générale qui puisse décider si un programme se terminera ou non. Il n’est même pas certain de pouvoir prédire des comportements non-triviaux. Mais cela implique qu’il existe des programmes qui se terminent et qui se comportent comme prévu, pourtant, on ne peut pas le prouver. On peut trouver un moyen de calculer la plupart des programmes mais pas tous.

Vous vous demandez quel est le lien entre Turing-Complétude et Smart Contracts ? Le fait est que l’on voit souvent que les Smart Contracts sont écrits dans des langages Turing-Complet.

Mais est-ce bien ou pas ? Est-ce nécessaire ou pas ? Il n’y pas de réponses évidentes à ces questions. La communauté autour de la Blockchain est quelque peu divisée sur ce point et cela dépend notamment aussi des besoins.

D’un côté, on peut prouver que les programmes écrits dans un langage Non-Turing-Complet s’arrête toujours. C’est cette affirmation en particulier qui conduit à un quiproquo : « si l’on considère le problème de l’arrêt dans les langages Turing-Complet impliquant que l’on ne peut pas prédire le comportement des programmes, alors nous pouvons écrire ces programmes dans un langage qui assure la terminaison et il sera donc possible de prédire le comportement du dit programme ».

C’est faux, il est possible de prouver la terminaison mais il n’est pas possible de décider le comportement si par exemple le programme atteint une erreur pour toutes les entrées.

Mais cela ne nous empêche pas de considérer ces langages parce que les langages Turing-complet ne sont pas forcément nécessaires et seraient même de trop quand il est question de « business logic » de la blockchain considérée.

Bitcoin script est un langage Non-Turing-Complet et cela est suffisant pour ce qu’il y a à faire au sein du réseau, c’est-à-dire fournir un mécanisme simple de distribution de monnaie. Mais il est important de noter que le protocole a recours à ce qu’on appelle des UTXO (unspent transaction outputs), et ces transactions sont créées lors de la soumission d’autres transactions dans le but d’assurer la distribution. Donc, avec ce type de model, on est rapidement limités en termes de complexité de la « business logic » à cause de la grande quantité d’étapes et de transactions nécessaires.

D’un autre coté les langages Turing-Complet peuvent être utilisés pour construire des Smart Contracts qui permettent de faire bien plus de taches qu’une blockchain typique comme Bitcoin. Mais il existe tout de même un risque que ce type de langage mène à un comportement qui n’était pas prévu initialement, provoquant des situations plutôt embarrassantes dans ce genre de réseau. On peut prendre, pour illustrer ce propos, l’attaque sur la DAO (Decentralized Autonomous Organization) de Ethereum pendant laquelle 3 millions d’Ether ont été volés. Quelqu’un a été capable de prédire plus précisément le comportement de « la business logic » que les administrateurs du réseau, même s’il est fondamentalement impossible de savoir ce qui peut se passer.

Certaines personnes diront que l’existence de ce genre de problème fait que la Turing-Complétude est dépréciée pour les Smart Contracts, et qu’il faut de la décidabilité.

Ce n’est pas si simple et manichéen, car même s’il n’est pas possible de prédire exactement le comportement, il est possible de limiter le Smart Contract en temps et/ou en nombre d’étapes, ce qui aura pour effet de sécuriser la terminaison de l’exécution. Et c’est ce que la plateforme Ethereum fait.

Certains ajoutent dans le débat que à cause du théorème de Post, il est possible d’être plus efficace dans la gestion du réseau. Et bien cela est vrai, mais en affirmant cela on s’écarte un peu du sujet. Le but principal des Smart Contracts n’est pas d’être le plus efficace possible mais plutôt de permettre un plus large panel de tâches effectuables sur un réseau Blockchain, qu’on appellera « rich statefullness ».

Il est donc plutôt difficile de sortir de ce problème. Une autre façon de voir le problème serait de s’attarder plutôt sur d’autres propriétés des langages, c’est-à-dire un langage « ease to reason » ou un langage « expressive »

Un langage « ease to reason » évalue la possibilité de reproduire facilement ou pas le programme dans l’esprit humain, tandis que l’expressivité du langage évalue la capacité de celui-ci à exprimer clairement ce qu’un programme fait (Groovy est plus expressif que Java). Les automates sont très « ease to reason » mais pas vraiment expressifs.

Et ces deux caractéristiques ne sont pas du tout corrélées avec le fait qu’un langage soit Turing-Complet. Pour illustrer, voici un programme écrit en Malbolgue.

Ce programme affichera « Hello World ! ». Ce n’est pas « ease to reason » ni « expressive » mais ce langage est Turing-Complet.

On peut aussi ajouter à cela la justesse des programmes. Un domaine montant de l’informatique qui peut produire des programmes que l’on peut prouver comme étant correct. En spécifiant les propriétés à vérifier, il est possible de prouver qu’un programme est correct. De plus, en assumant le fait que les Smart Contracts sont écrits en peu de lignes de code, on peut, sans trop se mouiller, admettre qu’ils font de très bons candidats pour ce domaine. Et c’est grâce à cela que l’on pourra donner plus de crédit à des langages Turing-Complet pour l’écriture des Smart Contracts.

Conclusion

Avec tout ce qui vient d’être dit, on voit que l’utilisation de Smart Contract implique de nombreux problèmes. Il est donc essentiel de prendre son temps lors de la décision d’utiliser les Smarts Contract et ainsi que le choix du langage adéquat. Pour conclure, l’utilisation de Smart Contract sur un réseau Blockchain dépend largement des besoins liés à certains problèmes. Il est essentiel d’être prudent avec les Smarts Contracts, autant qu’avec la Blockchain. C’est un outil vraiment puissant lorsqu’il est question de faire plus qu’échanger une monnaie comme le réseau Bitcoin. Smart Contract peut entraîner une implémentation de « business logic » provenant de process existants pour les faire profiter des avantages de la Blockchain. Mais cela peut évidemment être dangereux, du fait des comportements que l’on ne peut prévoir.

Il est donc important d’analyser les besoins avant d’utiliser une Blockchain faisant évoluer des Smarts Contracts.

References

• https://medium.com/@Jernfrost/what-is-a-smart-contract-and-why-do-we-need-them-7d92f2131f03
• https://medium.com/@abarrera/are-smart-contracts-really-needed-8ebac81c91b
• https://hackernoon.com/ethereum-turing-completeness-and-rich-statefulness-explained-e650db7fc1fb
• https://hackernoon.com/smart-contracts-turing-completeness-reality-3eb897996621
• https://equationdelaconfiance.fr/decryptage/mais-quoi-servent-les-smart-contracts