Comment concevoir un contrat autonome ? Quelle blockchain choisir ? Quelles sont les problématiques de développement ? Quelles idées reçues circulent encore sur ces technologies ?
Le principe de contrat autonome a été décrit pour la première fois par Nick Szabo au début des années 90. L’expression “smart contract” prête à confusion : d’une part ces contrats n’ont rien d’intelligent et d’autre part ils n’ont pas grand-chose à voir avec les contrats au sens courant et juridique du terme. Un contrat autonome est un programme qui s’exécute sans qu’un tiers puisse l’empêcher ou le modifier.
Pas de blockchain, pas de contrat.
S’il est déployé sur un serveur centralisé, une panne ou une attaque peut bloquer l’exécution. L’admin du serveur en question peut effacer arbitrairement le contrat en question. Pour s’émanciper de ces intermédiaires, il fallait qu’on se mette d’accord sur un protocole de registre distribué (ou plutôt réparti) ouvert sur lequel on pourrait déployer ces contrats, c’est-à-dire une blockchain. La proposition de Satoshi est sur la table en 2008. Au fur et à mesure que Bitcoin se développe et gagne en popularité, la demande d’outils de mise en place de contrats autonomes se fait de plus en plus forte.
C’est ce qu’a vite compris Vitalik Buterin. Après avoir contribué aux projets Bitcoin, Name Coin et Colored Coin, il conclut qu’une blockchain spécifiquement “orientée contrat” répondrait mieux aux besoins des uns et des autres : la première description technique d’Ethereum est publiée à la fin de l’année 2013. Ethereum est donc une plateforme d’applications décentralisées qu’on appelle aussi “dapps” et qui désigne le contrat et son interface utilisateur. La blockchain d’Ethereum est opérationnelle depuis juillet 2015 et STATE OF THE ÐAPPS recense aujourd’hui une centaine de contrats déployés sur cette chaîne.
Même si Bitcoin et Ethereum sont les deux plus importantes blockchains publiques qui existent, elles relèvent encore de l’expérimentation : même si le numéro de version n’est pas toujours significatif, la version 1.0 de Bitcoin n’est même pas encore sortie et Ethereum n’est qu’en version Beta… Les choses avancent extrêmement vite et plus rien ne peut arrêter le développement de ces technologies mais il est recommandé de les utiliser avec un minimum de prudence. Vous voilà prévenus.
Ceci étant dit, c’est bien le moment de faire preuve d’imagination et d’inventivité car le potentiel de ces techno donne réellement le tournis : infrastructures monétaires, finance, transferts de fonds, crowdfunding, assurances, mutuelles, syndicats, droits d’auteurs, administration, systèmes de vote, certifications, recherche collaborative, réseaux sociaux, marketing, publicité, notariat ne seront plus comme avant. Il n’est pas inutile d’anticiper ces bouleversements qui représentent probablement des dizaines de milliards d’économies dans tous ces domaines d’activité dans les années qui viennent.
Il faut distinguer blockchains et contrats. Déployer un contrat sur une chaîne robuste (dont la puissance de calcul est telle que “l’attaque des 51%” sera difficile et coûteuse) est essentiel. On ne construit pas sur des sables mouvants : si la chaîne sur laquelle j’ai déployé mon super contrat casse, c’est game over. Puisqu’un certain nombre de standards de rédaction de contrats émergent progressivement, on peut concevoir ces applications indépendamment du choix de la chaîne. Ce choix peut se faire dans un deuxième temps. Pour l’instant, c’est soit Bitcoin, soit Ethereum. Hadrien Charlanes décrit dans cet article quelques subtilités concernant Ethereum et rappelle à juste titre qu’il est encore trop tôt pour compter sur une “immuabilité” totale d’une blockchain. Y arrivera-t-on un jour ? Difficile à dire : on s’en approchera toujours un peu plus mais le “100% immuable” ne sera probablement jamais atteint. Quant aux blockchains dites “privées” dont l’accès est restreint (“permissioned”), elles n’ont que très peu d’intérêt : si vous souhaitez tout contrôler vous-même, si la transparence n’est pas votre problème, mieux vaut en rester à des solutions centralisées. Pas besoin de blockchain pour ça. On peut également ajouter que les progrès de l’informatique quantique et son impact sur la cryptologie mèneront à de sérieuses remises en question d’ici quelques années. Certains parlent déjà de “quantum chains”… et il existe d’autres projets très séduisants comme IOTA qui se passe de blockchain pour (re)décentraliser le Web.
Un exemple de contrat
Voici un exemple de contrat autonome codé en Solidity par Stéphane Bortzmeyer dont je recommande par ailleurs la lecture de l’article récent À quoi peut bien servir la chaîne de blocs ? ainsi que cette excellente présentation technique d’Ethereum. Une enveloppe Soleau est un document protégé par le cachet de l’INPI qui permet de prouver juridiquement l’antériorité d’un document sur un autre. Le service coûte 15 euros. La certification de documents est un cas d’utilisation typique de la blockchain. Vous obtenez une protection équivalente, voire meilleure, en appelant ce contrat de 54 lignes :
D’un point de vue commercial et dans l’état actuel du développement de ces technologies, les entreprises de l’écosystème préfèrent à juste titre proposer à leurs clients ce type de service sur Bitcoin. C’est le cas des startups françaises Woleet (certification et horodatage de documents) ou Czam (points de fidélité et billetterie). On peut tout à fait proposer des contrats autonomes sur Bitcoin et la sortie du projet Rootstock est très attendue. Elle est annoncée pour la fin de cette année 2016.
Emergence des bonnes pratiques
La programmation de contrats autonomes est une discipline très nouvelle et les bonnes pratiques commencent seulement à émerger. Depuis le hack de « The DAO » du 17 juin 2016, toute la communauté a bien pris note des leçons à tirer. Avant cet événement, cette DAO avait tout de même réussi à récolter plus de 200 millions de dollars en financement participatif ce qui est un record absolu dans le domaine. Beaucoup de traders du dimanche y ont vu l’opportunité de générer de rapides profits. Ils ont investis sans comprendre ce qu’ils faisaient et l’équipe a été dépassée par les événements. La communauté Ethereum a dû faire le nécessaire pour qu’ils puissent être remboursés.
Voici les bonnes pratiques plus évidentes à garder à l’esprit dans la conception de vos futurs contrats :
– Limite des montants. Un contrat déployé est aussi une adresse, c’est-à-dire un compte qui peut “contenir” des fonds. Il peut être sage d’indiquer une limite de montant accepté. Tous les contrats n’ont pas vocation à accumuler des millions de dollars mais pour des raisons de sécurité, il est raisonnable d’organiser une bonne circulation des fonds, et éventuellement dépenser l’argent au lieu qu’il s’accumule.
– Maintenance. Il n’est pas possible de modifier un contrat déployé sur blockchain sauf si vous stipulez explicitement les conditions dans lesquelles une nouvelle version de ce contrat peut être déployée. Si tout le pouvoir est confié au développeur qui assumera cette tâche, cela casse le schéma de gouvernance décrit dans le contrat. S’il s’agit d’un schéma avec une hiérarchie quelconque, cela pose moins de problème que si le pouvoir de décision est réparti sur l’ensemble des participants.
– Hazard coding. Si les montants en jeu peuvent être importants, la programmation de contrat n’a plus rien n’a voir avec le code d’une simple appli ou d’une page Web. On peut tout à fait comparer cela à la conception de logiciels destinés à l’aéronautique ou à ce type d’industrie à haut risque. Les américains appellent ça “hazard coding”. La moindre erreur peut-être fatale et cela implique, entre autre, des procédures de test extrêmement rigoureuses.
– Complexité Vs sécurité. On parle de “trivialité du code”, c’est-à-dire qu’il est plus prudent d’être très explicite et clair sur ce que fait le contrat et d’aller droit au but : par exemple, on peut “dire” au contrat “à telle condition, effectue un virement vers telle adresse” sans fleurs et sans ambiguïtés au lieu d’ajouter des facteurs complexes qui rendent la lecture humaine difficile. C’est aussi pour cette raison que le découpage en plusieurs contrats qui s’appellent les uns les autres est recommandé par rapport à un seul contrat qui porterait toute la logique de votre projet.
– Stress Tests. La phase de relecture et de test du code est absolument cruciale. Il existe déjà plusieurs process standards qu’il convient de respecter à la lettre pour éviter les mauvaises surprises. Les contrats sont souvent testés en local dans un premier temps, puis sur la chaîne “testnet”, qui est une copie de la vraie, avant d’être officiellement déployés sur la blockchain. On peut même recommander d’appliquer la preuve de programme pour s’approcher de la “fiabilité totale” qui d’ailleurs n’existe pas.
Les questions épineuses
– Identités. Dans la présentation technique de Bitcoin, Satoshi adopte une approche extrêmement soucieuse du respect des identité réelle des utilisateurs. Vous pouvez avoir autant d’adresses que vous voulez mais lier votre propre identité à une adresse publique comporte de vrais risques de perte de contrôle de celle-ci. Or, pour certains services (banque, vote, …), il est demandé à l’utilisateur de dévoiler cette intimité. Dans une présentation récente, David Birch évoque cette question de façon assez complète et voit même un nouveau débouché pour nos amis banquiers à qui on pourrait éventuellement confier la protection de cette information si particulière. Cela permettrait notamment de ne jamais diffuser celle-ci sur les réseaux. Le projet uPort propose aux gens de se constituer des « persona » différentes : identité réelle, pseudonyme, ou anonyme ce qui vous permet de choisir et donc de maîtriser les choses.
– Données personnelles. Souvenez-vous que sur une blockchain publique, tout est public donc il n’est pas question de stocker la moindre information confidentielle. Il y a plusieurs solutions pour résoudre ce problème. C’est notamment pour cette raisons que les banques qui se réunissent une fois par mois à New York pour partager les résultats de leurs recherches sur le projet de blockchain privée. On peut aussi stocker des informations sensibles sur IPFS (un espace de stockage décentralisé) par exemple et gérer les règles d’accès au sein du contrat en lui-même.
– Gestion des clés privées. La bonne pratique consiste à stocker hors-ligne vos clés privées, on appelle ça le “stockage à froid”. Ce n’est pas du tout évident, y compris pour les professionnels, de les gérer comme il faut, sans jamais en perdre un peu dans le feu de l’action. Des applications comme Metamask, par exemple, résolvent en partie le problème en rendant plus simples les interactions avec les contrats (ou juste “possible” pour l’internaute lambda).
– Sécurité de bout en bout. Il est difficile de contrôler la sécurité des différents appareils qu’on utilise au quotidien, sans parler de toutes sortes de malveillance possibles et imaginables si le contrat s’appuie sur l’intégrité des données en provenance des utilisateurs pour “garantir” la géolocalisation de ces derniers par exemple. Donc la question de la sécurité à tous les étages (device, browser, back-end) est également à garder à l’esprit. La paranoïa est moins justifiée si les enjeux sont faibles.
Idées reçues sur les blockchains
Tout le monde n’a pas forcément le temps de se plonger dans les détails des algorithmes de consensus de chaque blockchain. Beaucoup d’erreurs sont répandues aussi bien dans les médias que dans les milieux académiques. Voici quelques idées reçues que je tenais à évoquer au passage.
“Les blockchains sont trop gourmandes en énergie.”
Ce n’est que partiellement vrai. Le réseau Bitcoin consomme 10 Gigawatts par jour pour fonctionner. Le chiffre est impressionnant mais on ne sait pas vraiment ce qu’une transaction via le réseau Visa coûte d’un point de vue énergétique. Compte tenu du grand nombre d’intermédiaires qui interviennent au cours du process, cette usine à gaz n’a plus de raison d’être aujourd’hui.
Par ailleurs, il est prévu qu’Ethereum passe en proof-of-stake, un algo de consensus beaucoup plus raisonnable sur le plan énergétique car les mineurs ne doivent pas faire faire des calculs (résoudre une sorte de puzzle) à leur machine comme c’est le cas en proof-of-work. On peut comparer le PoS (proof-of-stake) à du “minage virtuel”. Cela consiste à “montrer qu’on en a” et la limite minimum n’est pas encore fixée : si celle-ci est faible, tout le monde pourra contribuer au maintien du réseau, ce qui favorisera la décentralisation du système. Pour que la solution proposée par les développeurs d’Ethereum soit pérenne, le PoS devra être combiné avec la technique dite du sharding.
“Le design de Bitcoin est fondamentalement inégalitaire.”
Aujourd’hui, il vaut mieux être équipé d’une machine puissante pour espérer miner le moindre bloc. Donc il est vrai que le minage n’a rien de démocratique, mais si on compare avec le processus de création monétaire de monnaies fiat (type euro), c’est bien pire. La première façon de se procurer du bitcoin, c’est de l’accepter dans ses échanges et c’est clairement à la portée de tout le monde. Les “premiers entrants”, celles et ceux qui se sont procurés du bitcoin avant 2013 sont aujourd’hui plus ou moins riches : il faudra m’expliquer en quoi c’est un problème.
“Le bitcoin est fait pour les libertariens.”
En théorie, la masse monétaire totale n’excédera jamais les 21 millions de bitcoins et la monnaie de Satoshi est certes inspirée des principes économique de l’Ecole Autrichienne mais en quoi cela poserait-t-il un problème ? Certains ne comprennent pas qu’on peut très bien posséder 0,00001 bitcoin, ce qu’on peut difficilement faire avec un actif comme l’or par exemple. De plus Bitcoin n’a pas du tout la prétention hégémonique qu’a le dollar : c’est une monnaie complémentaire qui contribue à la diversité monétaire qui fait actuellement défaut à notre système et qui explique en grande partie les dizaines de crises à répétition que nous avons subies, dont celle de 2007-2008.
“Le bitcoin est la monnaie des brigands.”
C’est un non-sens total. Il est certes possible de rendre la chose anonyme, mais les transactions en Bitcoin ne sont pas anonymes mais pseudonymes : on peut voir toutes les transactions qui ont lieu sur le réseau sur blockchain.info par exemple (montants et pseudos). Même si c’est effectivement un cas d’utilisation assez répandu (ce qui est d’ailleurs bon signe d’un point de vue scientifique), criminaliser Bitcoin équivaut à interdire l’usage des voitures au prétexte que des braqueurs de banques l’utilisent comme voiture-bélier. On arrive tout de même à trouver quelques politicards de droite qui ont ajouté ce genre d’interdiction aussi fascisante que mal documentée à leur liste au Père Noël.
“L’automatisation et les blockchains vont supprimer des emplois.”
Ce n’est pas faux mais les fabricants d’appareils photos argentiques se sont-ils accrochés à cette technologie ? Non : ils se sont adaptés au numérique, notamment à la demande de leurs clients. Les moines copistes ont également dû trouver une autre activité quand l’imprimerie s’est imposée. Il n’est pas impossible de se former à toutes sortes de métiers passionnants si la blockchain rend obsolète telles ou telles anciennes pratiques (notariat, administration, finance, etc). Lionel Dricot explique ça mieux que moi.
“Bitcoin n’est pas légal.”
C’est vrai mais il n’est pas illégal non plus. On parle d’alégalité. Cela signifie qu’un commerçant peut tout à fait l’accepter (pour des raisons pratiques, marketing, politiques, ou autres). Le Code Monétaire et Financier force les commerçants à accepter l’euro, mais rien ne les empêche d’accepter des devises étrangères ou bien des monnaies locales par exemple. J’ajoute qu’une transaction via le réseau Bitcoin est une preuve irréfutable, et il y a fort à parier que cette question se posera bientôt dans quelques tribunaux français : la réponse fera jurisprudence en temps voulu.
Cet article a remporté le 1er prix du concours organisé par bitcoin.fr le mois dernier.
A propos de l’auteur :
Julien Béranger travaille sur les aspects adoption et vulgarisation des crypto-monnaies depuis avril 2013. Il développe actuellement le projet Abie Fund, une DAO à but non-lucratif à destination des associations et ONG.
