Ce que les smart contracts peuvent et ne peuvent pas imposer

L’expression smart contract fait beaucoup de travail qu’elle n’a pas mérité. Elle suggère quelque chose de juridique, quelque chose d’intelligent, quelque chose qui veille sur un accord. Ce qui est réellement déployé, c’est un programme stocké sur une blockchain, qui s’exécute lorsqu’il est déclenché et déplace des actifs selon son propre code. Comprendre l’écart entre le nom et le mécanisme explique l’essentiel du risque.

Ce qui est réellement déployé

Un smart contract est du code et des données stockées, résidant à une adresse sur une chaîne. N’importe qui peut lui envoyer une transaction qui appelle l’une de ses fonctions. Chaque nœud exécute le même code sur le même état et aboutit au même résultat, ce qui rend le résultat vérifiable plutôt que fondé sur la confiance.

L’exécution a un coût, généralement proportionnel au travail de calcul effectué. Ce coût n’est pas un simple détail comptable : il plafonne la complexité que peut atteindre en pratique une logique on-chain, et pousse les développeurs vers des contrats minimalistes, en traitant le plus possible hors chaîne (off-chain). Cela signifie aussi qu’un contrat peut échouer simplement parce qu’il a épuisé son budget en cours d’exécution.

Deux propriétés en découlent. L’exécution est déterministe : les mêmes entrées donnent toujours les mêmes sorties. Et sur la plupart des chaînes, le code déployé est immuable, si bien que ce que l’on déploie est ce qui s’exécutera pour toujours.

Ce qu’un smart contract fait réellement respecter

Au sein de sa propre chaîne, la capacité d’un contrat à faire respecter les règles est très forte. Il peut détenir des actifs et ne les libérer que lorsque des conditions énoncées sont remplies. Il peut imposer un ordre, de sorte que l’étape deux ne puisse pas se produire avant l’étape un. Il peut imposer des règles arithmétiques telles que des plafonds d’offre ou des calendriers d’émission. Il peut imposer un contrôle d’accès, en restreignant certaines fonctions à des adresses particulières. Et il peut faire tout cela sans opérateur susceptible de changer d’avis.

Il s’agit d’une capacité réelle. Un séquestre (escrow) qu’aucun intermédiaire ne peut piller, une offre de tokens que personne ne peut discrètement gonfler, et une tenue de marché automatisée (market making) fonctionnant sans carnet d’ordres, sont autant de véritables réussites de ce modèle. La valeur vient de la suppression du pouvoir discrétionnaire, pas de l’ajout d’intelligence.

Ce qu’il ne peut pas faire

Un contrat n’a pas de sens. Il ne peut pas voir une livraison arriver, un envoi passer la douane, ou un service être rendu. Il ne connaît que ce qui est inscrit dans l’état de sa chaîne. Toute interaction avec le monde physique nécessite qu’une personne l’atteste, et à ce moment-là, c’est à cet attestateur que l’on fait confiance.

Un contrat n’a pas non plus de portée. Il ne peut pas saisir des biens, effectuer une saisie sur salaire ni contraindre un comportement. Si un accord doit être appliqué contre une personne plutôt que contre une réserve d’actifs on-chain, le code ne le permet pas. En pratique, cela signifie que les smart contracts fonctionnent bien lorsque l’objet entier de l’accord est déjà on-chain, et de moins en moins bien à mesure que l’on s’en éloigne.

Un contrat ne peut pas non plus exercer de jugement. Il ne peut pas reconnaître qu’une contrepartie a agi de mauvaise foi tout en respectant la lettre des termes, ou que les circonstances ont changé d’une manière que personne n’avait anticipée. Les contrats humains survivent grâce à l’interprétation. Le code n’en a aucune.

Où le risque se concentre réellement

La cryptographie sous-jacente est rarement le problème. Les défaillances se concentrent dans quelques endroits reconnaissables.

Une logique qui fait ce qu’elle dit, pas ce qui était voulu

Le cas classique est celui d’une fonction pouvant être ré-entrée avant qu’elle n’ait terminé de mettre à jour sa propre comptabilité, permettant à un appelant de retirer des fonds à répétition contre un solde qui n’a pas encore été décrémenté. Le code s’est exécuté correctement. C’est la conception qui était erronée. L’immuabilité rend alors l’erreur permanente, à moins qu’un mécanisme de secours n’ait été intégré.

Le contrôle d’accès

De nombreux incidents se résument à une fonction privilégiée qui n’a pas été correctement restreinte, ou à une clé administrative plus puissante ou moins protégée que les utilisateurs ne le pensaient. Un contrat peut être irréprochable dans sa logique centrale tandis qu’une adresse propriétaire conserve discrètement le pouvoir de le vider.

De mauvaises données en entrée

Les contrats qui font référence à des prix, des taux ou des résultats dépendent d’oracles. Lorsqu’un prix est lu à partir d’une source qu’il est possible de manipuler à peu de frais, un attaquant peut fausser la donnée d’entrée et laisser le contrat causer les dégâts en son nom. Le contrat se comporte correctement d’un bout à l’autre.

La composition

Les protocoles s’appuient les uns sur les autres, et un contrat sûr isolément peut ne plus l’être lorsqu’un autre contrat peut l’appeler selon une séquence inattendue au sein d’une même transaction. Le comportement émergent entre des composants individuellement sains est l’une des catégories de risque les plus difficiles à appréhender.

L’immuabilité, une propriété à double tranchant

L’immuabilité est la raison pour laquelle un smart contract peut inspirer confiance sans qu’il faille faire confiance à son auteur. C’est aussi la raison pour laquelle un bug peut être impossible à corriger. Les équipes réagissent avec des schémas évolutifs (upgradeable), des timelocks qui retardent les changements afin que les utilisateurs puissent sortir, et un contrôle multi-signature des clés administratives. Chaque mesure d’atténuation est une réintroduction partielle de confiance, choisie délibérément.

Aucune configuration ne permet d’éliminer ce compromis. Totalement immuable signifie totalement engagé envers ce qui a été déployé. Évolutif signifie que quelqu’un peut changer les règles. La position honnête consiste à savoir quel modèle un protocole donné utilise, qui détient les clés, et quel délai existe avant que les changements ne prennent effet.

En quoi cela touche le minage et le consensus

Les contrats s’exécutent à l’intérieur de blocs, ce qui signifie que leurs garanties ne valent que ce que valent les garanties de règlement de la chaîne sous-jacente. Sur une chaîne où les réorganisations sont peu coûteuses, une transaction qui semblait définitive peut être annulée, et tout état de contrat qui en dépendait disparaît avec elle. La sécurité de la chaîne, qu’elle provienne du proof of work accumulé ou du stake engagé, fait donc partie du modèle de sécurité d’un contrat, et non d’un sujet distinct. Cette relation est détaillée plus en profondeur dans notre couverture de la technologie blockchain.

Une méthode pratique pour en évaluer un

Avant d’interagir avec un contrat, quelques questions permettent de faire l’essentiel du travail. Le code source est-il vérifié et lisible, ou s’agit-il seulement d’un binaire compilé ? Est-il évolutif, et si oui, qui peut le mettre à jour et à quelle vitesse ? De quelles données externes dépend-il, et comment ces données sont-elles obtenues ? A-t-il fait l’objet d’un audit, à quelle version, et les conclusions ont-elles été traitées ? Quelle valeur a-t-il détenue, et pendant combien de temps ?

Rien de tout cela ne garantit la sécurité. Cela permet de passer d’une confiance accordée à une description à une évaluation d’un mécanisme, ce qui est le maximum que l’on puisse honnêtement obtenir. Pour la terminologie environnante, voir le glossaire, et pour savoir comment nous abordons ce type de sujet en général, voir notre méthodologie. Rien ici ne constitue un conseil financier.