Tezos : un registre auto-modifiable
Position Paper

L.M Goodman – 3 Août 2014

Généralités

« Laissez faire les propriétaires » – Pierre-Joseph Proudhon

La popularisation de Bitcoin, une crypto-monnaie décentralisée, a inspiré la production de plusieurs monnaies alternatives, ou « alt » (altcoins). Ethereum, Cryptonote et Zerocash, représentent tous des contributions uniques au domaine des crypto-monnaies. Bien que la plupart des monnaies alternatives possèdent leur propre source d’innovation, elle n’ont aucun moyen d’adopter les innovations d’autres monnaies susceptibles de les succéder. Notre objectif est de remédier au potentiel d’évolution atrophiée du domaine des crypto-monnaies, en présentant Tezos, un crypto-registre auto-modifiable.

Tezos peut instancier n’importe quel protocole blockchain. Son protocole initial spécifie une procédure permettant aux parties prenantes d’approuver des amendements au protocole, y compris des amendements aux procédures d’amendements elles-mêmes. Les améliorations de Tezos sont exécutées à travers un environnement de test, afin de permettre aux parties prenantes de revoir les modifications potentiellement problématiques.

La philosophie de Tezos s’inspire du « Nomic » de Peter Suber [1], un jeu construit autour de l’introspection d’un ensemble de règles.

Dans ce Papier, nous espérons élucider les bénéfices potentiels de Tezos, notre choix d’implémenter un système de preuve d’enjeu, et notre choix de programmation en OCaml.

Sommaire

1  Motivation

1.1  Le problème de fork du protocole

1.1.1  Se maintenir dans l’innovation

1.1.2  L’économie des forks

1.2  Les faiblesses de la preuve de travail

1.2.1  La concentration de la puissance de minage

1.2.2  Les mauvaises incitations

1.2.3  Le coût

1.2.4  Les contrôles

1.3  Les Smart Contracts

1.4  L’exactitude

2  Généralités des Blockchains

2.1  Trois Protocoles

2.1.1 Le Protocole de réseau

2.1.2 Le Protocole de transaction

2.1.3 Le Protocole de consensus

2.2  Shell réseau

3 Preuve d’enjeu

3.1  La preuve d’enjeu est-elle impossible ?

3.2  Les mesures d’atténuations

3.2.1 Points de contrôle

3.2.2 Détection statistique

3.3  Le problème du « rien en jeu »

3.4  Les modèles de menaces

4  Développement potentiel

4.1  La confidentialité préserve les transactions

4.1.1  Les signatures d’anneau

4.1.2  Les preuves à divulgation nulle de connaissance

4.2  Les règles d’amendements

4.2.1  Le constitutionalisme

4.2.2  La futarchy

4.3  Résoudre les problèmes d’action collective

4.3.1  Eveiller les consciences

4.3.2  Financer l’innovation

1. Motivation

Dans notre développement de Tezos, nous souhaitons résoudre quatre problèmes que nous avons perçu dans Bitcoin.

  • Le problème du « Hard Fork », ou l’incapacité pour Bitcoin d’innover dynamiquement à cause de problèmes de coordinations
  • Le coût et les problèmes de centralisation du système de validation par preuve de travail pour Bitcoin
  • L’expression limitée du langage transactionnel de Bitcoin, poussant le développement des smart-contrats sur d’autres chaînes
  • Les soucis de sécurité concernant l’implémentation d’une crypto-monnaie

1.1. Le problème de fork du protocole

1.1.1. Se maintenir dans l’innovation

Suite au succès de Bitcoin, de nombreux développeurs et entrepreneurs ont publié des crypto-monnaies alternatives, « altcoins ». Alors que certains de ces altcoins n’étaient pas vraiment différents du code original de Bitcoin, d’autres présentaient des améliorations intéressantes. Par exemple, Litecoin a introduit la fonction de preuve de travail par mémoire forte et un temps plus court de confirmation des blocs. Parallèlement, Ethereum a conçu ses contrats dynamiques et son langage transactionnel Turing-complet [3]. Les contributions les plus importantes incluent la préservation de la vie privée avec les signatures d’anneau (CryptoNote) [4] et l’intraçabilité des transactions avec l’utilisation de SNARK (Zerocash) [5].

La montée des altcoins a inspiré une large compétition dans l’innovation logicielle. Les porteurs de cette croissance ont pourtant oublié un point fondamental : pour qu’une crypto-monnaie soit une forme effective de monnaie, elle doit constituer une réserve de valeur stable. L’innovation au sein d’un registre, préserve la valeur à travers la protection des effets de réseau, donnant à la monnaie sa valeur.

Pour illustrer le problème de nombreux altcoins en compétition, comparons une crypto-monnaie et un smartphone. Lors de l’achat d’un smartphone, le consommateur paie pour certaines fonctionnalités, comme la possibilité d’écouter de la musique, consulter ses emails, envoyer des messages à ses amis, et passer des appels.

Chaque semaine, un nouveau modèle de smartphone est mis en vente sur le marché et bien souvent contient de meilleures fonctionnalités. Bien que les consommateurs possédant l’ancien modèle soient jaloux de ceux qui possèdent le dernier modèle, l’introduction de nouveaux smartphones ne rend pas les anciens smartphone dysfonctionnels.

Cette dynamique changerait si les nouveaux smartphones ne pouvaient pas communiquer avec les anciens smartphones. Si les nombreux modèles et styles de smartphone ne pouvaient pas être utilisés ensemble parfaitement, la valeur de chaque smartphone serait réduite au nombre de personnes possédant le même modèle.

Les crypto-monnaies subissent le même sort que les smartphones qui sont incompatibles entre eux. Elles tirent leur valeur d’un effet de réseau, ou du nombre d’utilisateurs lui attribuant sa valeur. Ainsi, toute innovation qui se produit en dehors d’une crypto-monnaie va, soit échouer à construire suffisamment d’effet de réseau pour être remarquée, soit réussir mais compromettra la valeur des avoirs de l’ancienne monnaie. Si les smartphones étaient incompatibles avec les anciens modèles, il y aurait soit très peu d’innovation (sous entendue incrémentale) ou bien une innovation extrêmement disruptive, poussant les anciens smartphones dans l’obsolescence.

Les chaînes latérales (Sidechains) tentent de permettre des innovations qui resteraient compatibles avec Bitcoin, en rattachant la valeur d’une nouvelle devise à Bitcoin et en créant une convertibilité à double sens. Malheureusement, on ne sait pas si ces chaînes seront assez flexibles pour prendre en charge des protocoles substantiellement différents de Bitcoin. La seule alternative est de « forker » le protocole.

1.1.2. L’économie des Forks

Pour comprendre l’économie des Forks, il faut en d’abord comprendre que la valeur monétaire est avant tout issue d’un consensus social. La tentation est grande d’assimiler une crypto-monnaie à ses règles et son registre, mais en réalité les monnaies sont des points focaux : c’est parce qu’elles tirent leur valeur de connaissances communes qu’elles sont acceptées comme monnaie. Cela peut sembler circulaire mais il n’y a rien de paradoxal. Sous l’angle de la théorie des jeux, la perception d’un token en tant que réserve de valeur est valable tant qu’elle est répandue. Notons que, en tant que registre, Bitcoin est une série de 1 et de 0. Le choix de traiter ces montants encodés dans des soldes de compte, est purement un consensus social et non une propriété du protocole lui-même.

Les modifications apportées au protocole sont appelés « forks ». Ils sont appelés ainsi, parce qu’en principe, les utilisateurs ont la possibilité de continuer à utiliser de l’ancien protocole. Ainsi, pendant un fork, la monnaie se scinde en deux : une ancienne version et une nouvelle version.

Un fork réussi, ne requiert pas seulement de l’ingénierie logicielle, mais aussi la coordination d’un masse critique d’utilisateurs. En pratique, cette coordination est très difficile à accomplir. En effet, après un fork, deux registres existent et les utilisateurs sont confrontés à un dilemme. Comment devraient-ils valoriser chaque branche du fork, chaque registre ?

C’est un jeu de coordination où la réponse est de valoriser avant tout la branche que les autres utilisateurs ont l’intention de valoriser. Bien sûr, les utilisateurs vont probablement suivre la même stratégie et apprécier une branche pour la même raison. Ces jeux ont été analysés par l’économiste Thomas Schelling et les points focaux sont parfois fois appelés les « points Schelling » [6].

Malheureusement, rien de garantit que ce point Schelling soit le choix le plus souhaitable pour les parties prenantes, cela sera simplement le choix « par défaut ». A défaut, le choix serait de suivre l’orientation des équipes de développement logiciel ou les décrets d’un gouvernement, indépendamment de leur mérite.

Un attaquant capable de changer de consensus social, contrôle la monnaie pour toutes ses intentions et fins. La possibilité de rester avec le protocole original est sans importance si la valeur de ses tokens est annulée par un changement de position du consensus.

Les équipes de développement logiciel constituent une source de centralisation potentiellement dangereuse. Bien que les utilisateurs peuvent forker tout projet open source, cette potentialité n’offre aucune protection contre un attaquant avec assez d’influence pour modifier le consensus social. Même si, en assumant la probable bienveillance des équipes de développement logiciel, cela représente un point faible pouvant-être utilisé comme levier par un attaquant.

Tezos se protège contre les vulnérabilités façonnées par des sources de centralisation, bien que les forks du protocole sont radicalement décentralisés. Il utilise son propre registre crypté et laisse les parties prenantes se coordonner sur les forks. Cela permet la coordination et ancre le principe que les forks ne sont valident que s’ils sont endogènes. Ce qui le rend beaucoup plus difficile l’attaque du protocole, car il faudrait bouger le consensus.

Supposons par exemple qu’un développeur populaire annonce son intention de forker Tezos, sans faire usage de la procédure interne du protocole. « Pourquoi voudrait-il court-circuiter ce process ? » se demanderait un participant. Certainement, parcequ’il sait qu’il ne pourrait pas construire un consensus autour de sa proposition de fork au sein de Tezos.

Ces signaux indiquent aux parties prenantes que la préférence serait de rejeter le fork. Le point Schelling est par conséquent de le refuser, indépendamment de l’influence de ce développeur.

1.2. Faiblesses de la preuve de travail

Le mécanisme de preuve de travail utilisé par Bitcoin est un équilibre judicieux d’incentives visant à prévenir le problème de la double dépense. Alors que les propriétés théoriques sont appréciables en l’absence de collusion entre les Miners, ce mécanisme souffre en pratique de sévères faiblesses.

1.2.1. La concentration de la puissance de minage

La preuve de travail, en tant que fondement des crypto-monnaies, pose plusieurs problèmes. Le problème le plus important, et le plus pertinent depuis 2014, est celui de l’existence de pools centralisés de minage, qui concentrent la puissance dans les mains de quelques individus.

Le mécanisme de preuve de travail est décentralisé. Ce qui signifie que les utilisateurs n’ont pas besoin de faire explicitement confiance à un tiers pour sécuriser la monnaie. Cependant, implicitement, Bitcoin a donné un système où tous les utilisateurs doivent faire confiance à la bienveillance d’un ou deux pools pour sécuriser la monnaie.

La conspiration de Miners détenant plus de 50% de la puissance de hachage est connu sous le nom d’attaque à 51%. Cette situation permet aux attaquants d’empêcher la réalisation de transactions, d’annuler des transactions, de voler les coins récemment forgés et de pratiquer la double dépense [8].

Une forge centralisée signant les blocs serait aussi sécurisée, et bien moins gaspilleur qu’un Miner contrôlant 51% de la puissance de hachage. Si une forge centralisée est inacceptable pour les utilisateurs de Bitcoin, alors ils ne devraient pas de facto tolérer la centralisation de la puissance de minage.

La concentration de la puissance de minage n’est pas une coïncidence : les grands pools de minage ont des rendements moins variables que les autres compétiteurs, et peuvent se permettre d’accroître d’avantage leur exploitation. En retour, cette croissance augmente leurs parts de marché et baisse la variance de leurs rendements.

Pour aggraver les choses, le grand pool de minage ghash.io fait allusion à un modèle d’affaires où ils privilégieraient les transactions « Premium » qui leurs seraient directement soumises.

Cela signifie que de grands Miners gagneraient proportionnellement plus que les petits Miners. Malheureusement, p2pool a eu des soucis pour attirer de la puissance de hachage, comme les Miners préfèrent égoïstement la commodité des pools de minage centralisés.

Beaucoup pensent que les craintes d’un marché concentré sont exagérées. Il s’agit d’une généralisation hâtive se basant sur l’économie du monde réel. Les vraies activités économiques se concurrencent dans un environnement rapidement changeant où la destruction créatrice de Schumpeter exerce une constante pression évolutive sur les acteurs en place. Les activités du monde réel ont besoin de compétences locales, font faces à des problèmes d’organisation et sont impactées par le problème du principal-agent.

Le minage de Bitcoin est un secteur économique purement synthétique, centré autour de la puissance de hachage, un bien purement fongible et intangible. Ce serait une erreur de généraliser hâtivement et penser qu’un tel environnement stérile est doté de la même robustesse organique qui caractérise une économie complexe et fertile.

De plus, l’argument économique soutient généralement que les monopoles naturels sont peu incités à abuser de leur position. La même chose pourrait être dite concernant un Miner de Bitcoin. Après tout, pourquoi un Miner dominant voudrait détruire la valeur de ses investissements en compromettant la monnaie ? Malheureusement, cela créer toujours un énorme risque systémique car ces Miners peuvent-être compromis par un attaquant malhonnête. Le coût d’une attaque par double dépense contre le réseau n’est pas supérieur au coût de subvertir quelques grands pools de minage.

Il y a eu des propositions visant à résoudre ce problème en peaufinant le protocole, afin qu’il soit impossible pour les pools de faire confiance à leurs membres pour de ne pas tricher. Cependant, ces propositions préviennent seulement les pools d’accumuler de la puissance de minage des participants anonymes, avec lesquels il n’y a pas de possibilités de représailles. Faire des pools est toujours possible entre des personnes non anonymes (identifiées) : les organisateurs devraient utiliser tout le matériel de mining, pendant que les participants détiennent les parts, ou les organisateurs devraient traquer les tricheurs en demandant l’inclusion d’un identifiant dans les blocs qu’ils sont supposés hacher. Le résultat de telles propositions serait donc d’augmenter la variance pour les opérations de minage anonymes et de pousser vers plus de concentration dans les mains des cartels de minage.

La preuve d’enjeu, mécanisme de validation utilisée par Tezos, ne souffre pas de ce problème. Autant qu’il soit possible de détenir 51% de la puissance de minage, cela implique détenir 51% de la monnaie. Non seulement c’est beaucoup plus onéreux que de contrôler de 51% de la puissance de hachage mais cela implique fondamentalement de meilleures incitations.

1.2.2. Les mauvaises incitations

La preuve de travail pose un problème encore plus grave, qui est beaucoup plus difficile à atténuer que la concentration de la puissance de minage : un mauvais alignement des incitations entre les Miners et les parties prenantes.

En effet, sur le long terme, le total des revenus du mining sera la somme de tous les frais de transactions payés aux Miners. Puisque que les Miners se font concurrence pour produire des haches, le montants dépensés sur le minage seront légèrement inférieurs aux revenus. A son tour, le montant dépensé sur les transactions dépend de l’offre et de la demande de transactions. L’offre de transactions sur la blockchain est déterminée par la taille des blocs, qui est fixe.

Malheureusement, si la demande de transactions s’éffondre à des niveaux très bas. Alors les gens utiliseront probablement des transactions en dehors du mécanisme de chaînes (« off-chain »), via des tiers de confiance, particulièrement pour des petits montants, afin d’alléger le besoin d’attendre les confirmations de leurs transactions. Dans ce cas les processeurs de paiements auront seulement besoin de s’expliquer plus rarement entre eux.

Ce scénario n’est pas seulement économiquement probable, il apparaît nécessaire étant donné le taux relativement faible de transactions supporté par Bitcoin. Puisque que les transactions blockchain devront concurrencer les transactions off-chain, le montant dépensé sur les transactions approchera de son coût, ce qui, étant donné l’infrastructure moderne, devrait-être proche de zéro.

Essayer d’imposer un minimum de frais de transactions, ne peut qu’aggraver le problème et pousser les utilisateurs à recourir d’avantage aux transactions off-chain. Comme le montant payé en frais de transactions s’effondre, alors les revenus des Miners s’effondreront aussi, ainsi que le coût d’exécution d’une attaque à 51%. Pour faire simple, la sécurité d’une blockchain en preuve de travail souffre d’un problème commun [9]. Mike Hearn, développeur logiciel, a suggéré l’utilisation de transactions spéciales pour subventionner le mining en utilisant un type de collecte de fond [10]. Un monnaie robuste ne devrait pas avoir besoin de compter sur la charité pour opérer en toute sécurité.

La preuve d’enjeu fixe ces mauvaises incitations, en alignant les incitations des Miners et celles des parties prenantes. Par définition : les Miners sont des parties prenantes et sont donc intéressés pour garder les coûts de transactions faibles. En même temps, parce que la preuve d’enjeu n’est pas basée sur la destruction de ressources, le coût de transaction (qu’il soit direct par les frais de transactions ou indirect par l’inflation) est entièrement récupéré par les Miners, qui peuvent couvrir leurs coûts d’exploitation sans avoir à se concurrencer à travers la destruction des ressources.

1.2.3. Coût

Une alternative consiste de garder permanentes les récompenses de minage, comme l’a fait Dogecoin. Malheureusement, la preuve de travail augmente arbitrairement les coûts pour les utilisateurs sans augmenter les profits pour les Miners, entraînant une perte sèche. En effet, comme les miners sont en compétition pour produire des hashes, la quantité de monnaie qu’ils dépensent sur le minage sera légèrement plus petite que leurs revenus. À long terme, leurs profits seront proportionnels à la valeur de leurs services de transactions, tandis que le coût de minage est bel et bien perdu pour tout le monde.

Ce n’est pas simplement un effet nominal : des biens économiques réels (temps de fabrication, électricité, efforts d’ingénierie) sont retirés de l’économie au profit du minage de la preuve de travail. En Juin 2014, l’inflation annuelle de Bitcoin atteignait plus de 10% et environ $2.16M dollars sont brûlés quotidiennement, afin de maintenir un système qui apporte peu de sécurité autour d’un système centralisé entre les mains de ghash.io.

La sécurité d’un système de preuve de travail, repose sur le fait que son coût réel est supérieur à ce qu’un attaquant est prêt à payer, ce qui est lié à l’augmentation du succès de la monnaie.

La preuve d’enjeu élimine cette source de gaspillage, sans baisser le coût de l’attaque. En effet, le coût de l’attaque augmente proportionnellement à l’appréciation de la monnaie. Car la chose à prouver pour sécuriser le réseau n’est pas la destruction des ressources existantes, mais la provision des ressources existantes. Une monnaie en preuve d’enjeu ne repose pas sur la destruction massive de ressources puisqu’elle gagne en popularité.

1.2.4. Controles

Enfin, le système de preuve de travail confie la responsabilité du réseau aux Miners et non aux parties prenantes. Les forks par exemple, nécessitent le consentement de la majorité des Miners. Cela pose potentiellement un conflit d’intérêt : une majorité de Miners pourraient décider de prendre la blockchain en otage jusqu’à ce que les parties prenantes consentent à un fork du protocole augmentant les récompenses des Miners. Plus généralement, les Miners conserveront ce système coûteux qui les encouragera plus longtemps qu’il ne bénéficiera économiquement aux utilisateurs.

1.3. Smart contracts

Bien que Bitcoin permette l’écriture et l’exécution de smart-contrats, la plupart de ces fonctionnalités ont été historiquement désactivées et les possibilités sont limitées. Ethereum a introduit un système de smart-contracts avec des différences majeures : le langage de script est dit de Turing complet et ils se substituent aux outputs non-dépensés des comptes d’état de Bitcoin. Bien que l’accent ait été mis sur l’aspect Turing complet du langage, la seconde propriété est de loin la plus intéressante et la plus puissante des deux. Dans Bitcoin, un output peut avoir seulement deux états : dépensé ou non-dépensé. Dans Ethereum, les comptes (protégés par une clé) tiennent un solde, un code contrat et une réserve de données. L’état de la réserve d’un compte peut-être modifié en exécutant une transaction vers ce compte. La transaction spécifie un montant et les paramètres transmis au code du contrat.

L’inconvénient d’un langage de script Turing complet est que le nombre d’étapes nécessaires pour exécuter un script est potentiellement illimité, une propriété qui est généralement non calculable.

Pour résoudre ce problème, Ethereum a mis au point un système par lequel le Miner validant la transaction, exige des frais proportionnels à la complexité et au nombre d’étapes nécessaires à l’exécution du contrat.

Cependant, pour que la blockchain soit sécurisée, tous les noeuds actifs doivent valider la transaction. Un Miner malveillant pourrait inclure dans son bloc une transaction qu’il a spécialement conçue pour lancer une boucle infinie et se payer lui-même des frais exorbitants pour valider la transaction. D’autres Miners pourraient gaspiller beaucoup de temps pour valider cette transaction. Pire, ils pourraient simplement relâcher leurs efforts et échouer dans sa validation.

Mais en pratique, la plupart des smart contracts peuvent-être implémentés avec une logique métier très simple et ne nécessitent pas de calculs complexes.

Notre solution consiste à plafonner le nombre maximal d’étapes qu’un programme est autorisé à exécuter pour une simple transaction. Puisque que les blocs ont une limite de taille qui plafonne le nombre de transactions par bloc, le nombre d’étapes de calcul par bloc est aussi limité. Ce taux limite déjoue les attaques par dénis de service via l’utilisation du CPU. Les Miners peuvent décider d’exclure les exécutions trop longues, s’ils estiment que les frais inclus sont trop faibles. Puisque le protocole Tezos est amendable, le plafond peut-être augmenté lors de futures révisions et des nouvelles primitives cryptographiques incluses dans le langage de script au fur et à mesure que le besoin se développe.

1.4. Exactitude

Bitcoin est le sous-jacent d’une valeur de $8 Milliards avec une simple base de codes. Comme l’explique Dan Kaminsky, chercheur en sécurité, sur le papier Bitcoin ressemble à un cauchemar en matière de sécurité. Une base codée en C++ avec un protocole binaire personnalisé, alimente les noeuds connectés à Internet tout en détenant de la monnaie électronique, ressemble à la recette d’un désastre. Les programmes C++ sont souvent des énigmes avec des bugs de corruption de mémoire. Quand ils sont connectés à Internet cela créer des vulnérabilités exploitables par les attaquants à distance. La monnaie électronique procure une avantage immédiat à n’importe quel attaquant suffisamment malin pour découvrir et exploiter une telle vulnérabilité.

Heureusement, l’implémentation de Bitcoin a prouvé jusqu’ici, sa grande résistance aux attaques, à quelques exceptions près. En Août 2010, un bug où la somme de deux outputs ont constitué un nombre négatif, a permis aux attaquants der créer deux outputs de 92233720368.54 coins à partir d’un input de 0.50 coins. Plus récemment, des vulnérabilités majeures telles que le bug du Heartbleed ont été découvert dans les librairies OpenSSL. Ces vulnérabilités ont un point commun, elles se sont produites parce que les langages C et C++ n’effectuent pas de vérification sur les opérations qu’ils exécutent. Par soucis d’efficacité, ils peuvent accéder à des parties aléatoires de la mémoire, ajouter des entiers plus grands que ceux qui sont supportés nativement, etc. Bien que ces vulnérabilités aient épargné Bitcoin, elles ne présagent rien de bon pour la sécurité du système.

D’autres langages ne présentent pas ces problèmes. OCaml est un langage de programmation fonctionnel développé par l’INRIA depuis 1996 (et lui même basé sur des précédents travaux). Sa vitesse est comparable à celle du C++ et il figure généralement parmi les langages de programmation les plus rapides selon les benchmarks [12]. Plus important encore, OCaml est fortement dactylographié et offre un puissant système d’inférence. Sa syntaxe et sa sémantique expressives, avec un modèle puissant de correspondances et des modules d’ordre supérieur, facilite la description concise et exacte du type de logique qui sous-tend les protocoles basés sur la Blockchain.

La sémantique d’OCaml est justement rigoureuse et un très grand sous-ensemble a été formalisé [13], ce qui retire toute ambiguïté quant au comportement attendu des amendements.

De plus, Coq, un des logiciels de vérification de preuve les plus avancés, est capable d’extraire le code OCaml des preuves. Au fur et à mesure du développement de Tezos, il sera possible d’extraire automatiquement les parties clés du code du protocole depuis les preuves d’exactitude mathématiques.

Les exemples d’échecs spectaculaires de logiciels sont abondants. Le bug du Heartbleed a causé des dommages de plusieurs millions de dollars. En 2013, un seul bug dans le domaine du trading haute fréquence chez la société Knight Capital, a causé des pertes équivalant à un demi milliard de dommages. En 1996, un bug a provoqué le crash d’Ariane 5, une fusée qui a coûté $7 milliards en développement. Le coût de la fusée et de sa cargaison était estimé à $500M.

Tous ces bugs auraient pu être évités grâce à la vérification formelle. La vérification formelle a progressé à grands pas ces dernières années, il est temps de l’utiliser pour des systèmes réels.

2. Généralités des Blockchains

Tezos tente de représenter un protocole Blockchain de façon la plus générale possible, tout en essayant de rester aussi efficace qu’un protocole natif. L’objectif d’une blockchain est de représenter un seul état pendant qu’il est édité. Afin d’éviter les conflits entre les éditions simultanées, il représente l’état comme un registre, c’est-à-dire comme une série de transformations appliquées à un état initial. Ces transformations constituent les « blocs » de la blockchain, et  – dans le cas de Bitcoin – l’état correspond essentiellement à l’ensemble des outputs non dépensés. Puisque les blocs sont créés de manière asynchrones par plusieurs noeuds simultanés, une arborescence de blocs est formée. Chaque feuille de cet arbre représente un état possible et la fin d’une blockchain différente. Bitcoin spécifie qu’une seule branche doit être considérée comme la branche valide : celle qui présente la plus grande difficulté. Les blocs, comme leur nom l’indique, regroupent en réalité plusieurs opérations (appelées transactions dans le cas de Bitcoin). Ces opérations sont appliquées à l’état de façon séquentielle.

2.1. Trois Protocoles

Il est important de distinguer trois protocoles dans les crypto registres : le protocole de réseau, le protocole de transaction, et le protocole de consensus. Le rôle du meta shell est de gérer le protocole de réseau de la manière la plus agnostique possible, tout en délèguant les protocoles de transaction et de consensus à une implémentation abstraite.

2.1.1. Le protocole de réseau

Le protocole de réseau de Bitcoin est essentiellement le réseau de rumeurs qui permet la diffusion des transactions, le téléchargement et la publication des blocs, la découverte des pairs, etc. C’est ici que la plupart des développements ont lieu. Par exemple, les « bloom filters », ont été introduits en 2012 via le BIP0037 pour accélérer la vérification des paiements simples pour les clients qui ne téléchargent pas toute la blockchain.

Les modifications apportées au protocole de réseau sont relativement peu controversés. Il peut y avoir des désaccords initiaux sur les opportunités de ces changements, mais les intérêts de toutes les parties sont globalement fondamentalement alignés.

Ces changements n’ont pas non plus besoin de survenir en même temps. On pourrait trouver un moyen d’intégrer les transactions Bitcoin, de façon stéganographique, dans des images de chats postées sur Internet. Si assez de personnes commençaient à publier les transactions de cette manière, les Miners commenceraient à analyser des images de chats pour trouver les transactions à inclure dans la blockchain.

Alors qu’un réseau sain requiert de la compatibilité, l’innovation compétitive au sein du protocole réseau, renforce généralement la crypto monnaie.

2.1.2. Le protocole de transaction

Le protocole de transaction décrit ce qui rend les transactions valides. Par exemple, dans Bitcoin, il est définit à travers un langage de script. D’abord, des coins sont créés par les Miners lorsqu’ils trouvent un bloc. Le Miner attache ensuite un script aux coins qu’il vient de miner. Ce script est appelé « unspent output » – état de sortie non dépensé.

Les transactions combinent les outputs en fournissant des arguments pour lesquels leurs scripts prennent la valeur de « vraie ». Ces arguments peuvent-être considérés comme des clés, et les scripts comme des cadenas.

Dans des transactions simples, de tels scripts sont seulement des scripts de vérification de signature, mais des scripts plus complexes peuvent être conçus. Ces outputs sont ajoutés et alloués au sein d’un ensemble de nouveaux outputs. Si le montant de l’output dépensé est plus grand que le montant alloué, la différence peut-être réclamée par le Miner.

Les modifications apportées au protocole de transactions sont plus controversées que les modifications apportées au protocole de réseau. Bien qu’un petit groupe de personne peut unilatéralement utiliser l’algorithme de diffusion d’images de chats, modifier le protocole de transactions est plus compliqué. Typiquement, de telles modifications n’affectent pas la validité des blocs et requiert seulement la coopération de la majorité des Miners. C’est ce qu’on appelle des « soft-fork ».

Certaines modifications, relativement peu controversées, ont tout de même une chance d’être implémenté ici. Par exemple, un correctif au problème de malléabilité des transactions, serait un changement au niveau du protocole de transactions. Egalement, l’introduction de Zerocash serait un changement au niveau de protocole de transaction, qui risquerait d’être trop controversé pour être entrepris.

2.1.3. Le protocole de consensus

Le protocole de consensus de Bitcoin décrit la manière dont le consensus est construit autour de la chaîne la plus difficile et la planification des récompenses des Miners. Il permet aux Miners d’établir des transactions à partir de la base de coins, il impose la manière dont la difficulté change au fil du temps, il indique quel bloc est valide et quels blocs forment les parties « officielles » de la chaîne.

C’est de loin le protocole le plus difficile à modifier, car les changements sont conséquents. Il nécessite souvent un « hard-fork », qui invalide et supprime les anciens blocs. Par exemple cette modification peut concerner le système de preuve de travail, tout comme l’algorithme en SHA256 de ce système, etc.

2.2. Shell réseau

Tezos sépare ces trois protocoles. Le protocole de transaction et le protocole de consensus sont implémentés dans un module isolé, plugué dans shell réseau générique (network shell) responsable de maintenir la blockchain.

Pour que le protocole reste générique, nous définissons l’interface suivante.

Nous voulons que notre blockchain représente l’état actuel de l’économie, ce que nous appelons dans Tezos le Contexte. Cela peut inclure les soldes des nombreux comptes et autres informations telles que le numéro du bloc actuel. Les blocs sont considérés comme des opérateurs qui transforment un état ancien en un état nouveau. Pour cela, le protocole peut-être décrit par seulement deux fonctions :

  • appliquer : qui prend un Contexte et un bloc et retourne soit un contexte valide soit un résultat invalide (si le bloc est invalide)
  • marquer : qui prend un Contexte et retourne une partition qui nous permet de comparer les différentes feuilles de la blockchain pour déterminer celle qui est canonique. Dans Bitcoin, il s’agit simplement d’enregistrer la difficulté totale ou la chaîne dans le contexte, et de retourner cette valeur.

Etonnement, ces deux fonctions, peuvent à elles seules implémenter n’importe quel crypto-registre basé sur une blockchain. De plus, nous attachons ces fonctions au contexte lui même et exposons les deux fonctions suivantes au protocole :

  • set_test_protocol (« définir  un protocole de test ») qui remplace le protocole utilisé dans le testnet (réseau de test) avec un nouveau protocole (typiquement celui qui a été adopté par le vote d’une partie prenante).
  • promote_test_protocol (« promouvoir un protocole adopté par une partie prenante ») qui remplace le protocole actuel par le protocole testé.

Ces deux procédures permettent au protocole de valider son propre remplacement. Tandis que le protocole initial repose sur une simple règle de super-majorité avec un quorum, des règles plus complexes pourront être adoptées à l’avenir. Par exemple, les parties prenantes, pourraient voter pour exiger que certaines propriétés soient respectées par n’importe quel protocole futur. Cela pourrait être réalisé en intégrant un vérificateur de preuve au sein du protocole et en exigeant que chaque amendement inclus une preuve de constitutionnalité.

3. Preuve d’enjeu

Tezos peut implémenter n’importe quel type d’algorithme blockchain : preuve de travail, preuve d’enjeu, ou même centralisé. À cause des faiblesses du mécanisme de preuve de travail, le protocole initial de Tezos implémente un système de preuve d’enjeu. Pour autant, il existe des obstacles théoriques considérables à la conception d’un système de preuve d’enjeu. Nous allons vous expliquer comment nous les avons gérés.

3.1. La preuve d’enjeu est-elle impossible ?

Tout système en preuve d’enjeu présente de sérieux obstacles théoriques. Le principal argument qui s’oppose la preuve d’enjeu est le suivant : un nouvel utilisateur télécharge un client et se connecte pour la première fois au réseau. Il reçoit l’arborescence des blocs avec deux grandes branches commençant au « Genesis hash », le tout premier hash généré lors de la création du premier bloc. Les deux branches affichent une activité économique prospère, mais elles représentent fondamentalement deux histoires différentes. Une branche a clairement été fabriquée par un attaquant, mais laquelle est la vraie chaîne ?

Dans le cas de Bitcoin, la véritable chaîne (aussi appelée chaîne canonique) est celle qui représente la plus grande quantité de travail (car elle fonctionne sur un système de preuve de travail). Cela ne signifie pas que réécrire l’historique est impossible, mais il est plus coûteux de le faire. D’autant plus que la puissance de calcul pourrait-être utilisée pour miner des blocs sur la véritable blockchain. Dans un système de preuve d’enjeu, où les blocs sont signés par les parties prenantes, une ancienne partie prenante (qui s’est retiré depuis), pourrait utiliser son ancienne signature pour scinder -« forker »- la blockchain sans coûts. Ce problème est connu sous le nom du problème du « rien en jeu » ou « nothing-at-stake ».

3.2. Mesures d’atténuations

Bien que cette objection théorique semble solide, il existe de réelles mesures d’atténuation efficaces contre cet obstacle. Il est important de considérer qu’il existe environ deux types de forks : le fork en profondeur, qui réécrit une partie substantielle de l’historique, et le fork court correspondant à une tentative de fraude type « double dépense ». A priori, il s’agit seulement d’une différence quantitative entre les deux types de fork. Mais en pratique, les motivations, les raisons et les stratégies d’atténuations sont différentes.

Aucun système est inconditionnellement sécurisé. Ni Bitcoin, ni même une clé publique cryptographique. Les systèmes sont conçus pour être sécurisés pour un modèle de menaces donné. La qualité avec laquelle ce modèle se saisit de la réalité est en fin compte une question empirique.

3.2.1. Points de contrôle

Des points de contrôle occasionnels peuvent constituer un moyen efficace d’empêcher les très longues réorganisations de la blockchain. Les points de contrôle sont un hack. Comme Ben Laurie le mentionne, l’utilisation des points de contrôle par Bitcoin révèle son statut de monnaie entièrement décentralisée [14].

Pourtant, en pratique, des points de contrôle annuels ou semestriels, ne semblent pas problématiques. Former un consensus autour de la valeur d’un seul hash sur une période de plusieurs mois, est quelque chose que les institutions humaines sont parfaitement capables d’accomplir en toute sécurité. Ce hash peut-être publié dans les principaux journaux du monde, gravés sur les tables des étudiants de première année, tagué sous les ponts, inclus dans des chansons, imprimé sur du béton, gravé dans le marbre… Il existe un nombre incalculable de façons d’enregistrer des points de contrôles occasionnels, de manière à rendre la falsification impossible. En revanche, le problème de former un consensus sur une période de quelques minutes est résolu de façon plus sécurisé par un protocole décentralisé.

3.2.2. Détection statistique

Les transactions peuvent faire référence à des blocs appartenant à la blockchain initiale, signant ainsi implicitement la chaîne. Un attaquant essayant de falsifier la chaîne, par une longue réorganisation, ne peut produire que des transactions impliquants des coins qu’il a contrôlé au dernier point de contrôle. Une longue et légitime chaîne, montrerait généralement une activité sur une plus grande fraction de coins, et se distinguerait donc statistiquement de la falsification.

Cette famille de techniques (souvent appelée TAPOS, pour « Transactions As Proof Of Stake » – transactions en tant que preuve d’enjeu) ne fonctionne pas très bien pour les forks courts, où l’échantillon est trop petit pour réaliser un test statistique fiable. Cependant, elle peut-être combinée avec une technique utilisant des forks courts, pour former un algorithme de sélection composite robuste aux deux types de forks.

3.3. Le problème du « rien en jeu »

Dans l’algorithme Slasher [15], Vitalik Buterin a présenté une approche intéressante pour résoudre le problème du « rien en jeu ». Toutefois, Slasher s’appuie toujours sur un mécanisme de preuve de travail pour extraire des blocs et admet une limite sur la longueur des forks possibles.

Nous retenons l’idée principale qui consiste à punir les doubles signataires. Si les récompenses de signature sont retardées, elles peuvent être bloquées en cas de détection d’une tentative de fraude par double dépense. C’est suffisant pour empêcher un acteur égoïste d’essayer de signer un fork de manière opportuniste, motivé par la récompense en cas de réussite du fork. Cependant, une fois les récompenses payées, cette incitation visant à récompenser les comportements honnêtes disparaît. Par conséquent, nous utilisons un délai suffisamment long pour que TAPOS devienne statistiquement significatif ou que des points de contrôle aient lieu.

Afin d’inciter les parties prenantes à se comporter honnêtement, nous introduisons un système de ticker. Un éventuel mineur doit graver un certain nombre de coins pour pouvoir exercer son droit de minage. Ce montant lui est automatiquement restitué s’il ne parvient pas à miner, ou après un long délai.

Une clé de signature différente est utilisée, pour éviter aux parties prenantes une connexion permanente à Internet et l’exposition des clés privées.

3.4. Modèles de menaces

Aucun système est inconditionnellement sécurisé. Ni Bitcoin, ni même une clé publique cryptographique. Les systèmes sont conçus pour être sécurisés pour un modèle de menaces donné. La qualité avec laquelle ce modèle se saisit de la réalité est en fin compte une question empirique.

Bitcoin offre une garantie intéressante : il tente de tolérer des participants amoraux mais égoïstes. Tant que les mineurs ne s’entendent pas, il n’est pas nécessaire de supposer qu’un participant est honnête, mais simplement parce qu’il préfère gagner de l’argent plutôt que détruire le réseau. Cependant, la non-collusion, une condition essentielle, est trop souvent oubliée et l’affirmation du «manque de confiance» de Bitcoin est répétée avec zèle sans trop y penser.

Avec un point de contrôle (annuel), les mêmes propriétés peuvent être obtenues par un système de preuve d’enjeu.

Sans points de contrôle, les systèmes de preuve d’enjeu ne peuvent en dire autant. En effet, il serait théoriquement possible pour un attaquant d’acheter d’anciennes clés à un grand nombre d’anciens intervenants, sans conséquence pour eux.

Dans ce cas, une hypothèse plus forte s’impose concernant les participants, à savoir qu’une majorité d’acteurs actuels ou anciens ne peut pas être corrompue à moindre coût pour participer à une attaque sur le réseau. Dans ce cas, le rôle «en jeu» dans la preuve d’enjeu consiste uniquement à éviter une sélection adverse par des acteurs malveillants du groupe de consensus.

4. Développement potentiel

Dans cette section, nous explorons quelques idées que nous souhaitons intégrer au protocole Tezos.

4.1. La confidentialité préserve les transactions

L’une des mises à jour de protocole les plus urgentes sera l’introduction de transactions préservant la confidentialité. Nous connaissons deux manières d’y parvenir: les signatures d’anneau et les preuves à divulgation nulle de connaissance (Non-Interactive Zero-Knowledge Proofs of Knowledge – NIZKPK). 

4.1.1. Les signatures d’anneau

CryptoNote a créé un protocole utilisant des signatures d’anneau pour préserver la confidentialité. Les utilisateurs peuvent dépenser des coins sans révéler laquelle des N adresses ont été dépensées. Les fraudes par double dépense sont révélées et les transactions sont réputées invalides. Cela fonctionne de la même manière que le protocole de CoinJoin sans nécessiter la coopération des adresses impliquées dans le brouillage de la transaction. L’un des principaux avantages des signatures d’anneau est qu’elles sont comparativement plus simples à mettre en œuvre que NIZKPK et reposent sur des primitives cryptographiques plus matures qui ont déjà fait leurs preuves.

4.1.2. Les preuves à divulgation nulle de connaissance

Matthew Green a proposé l’utilisation de NIZKPK pour obtenir la traçabilité des transactions dans une crypto-monnaie basée sur une blockchain. La dernière proposition, Zerocash, maintient un ensemble de coins avec des secrets attachés dans un arbre de Merkle. Les coins engagés sont échangés en fournissant un NIZKPK du secret attaché à une pièce de monnaie dans l’arbre. Il utilise une primitive relativement nouvelle, SNARK, pour construire de très petites preuves pouvant être efficacement vérifiées. Cette technique est attrayante mais souffre d’inconvénients. Les primitives cryptographiques impliquées sont relativement nouvelles et n’ont pas été aussi minutieusement analysées que la simple cryptographie sur les courbes elliptiques impliquée dans Bitcoin. Deuxièmement, la construction de ces preuves repose sur le modèle CRS. Cela signifie qu’effectivement, une configuration sécurisée est requise, bien que l’utilisation d’un calcul multipartite sécurisé puisse réduire le risque de compromission d’une telle configuration.

4.2. Les règles d’amendements

4.2.1. Le constitutionnalisme

Bien que cela soit plus avancé, il est possible d’intégrer un vérificateur de preuves dans le protocole afin que seules les modifications portant une preuve formelle du respect de propriétés particulières puissent être adoptées. En réalité, cela impose une forme de constitutionnalité.

4.2.2. La futarchy

Robin Hanson a proposé de voter sur les valeurs et de miser sur les croyances. Il appelle un tel système, la «Futarchy» [16]. L’idée principale de ce système, est que les valeurs sont mieux saisies par un consensus majoritaire. Tandis que le choix des politiques favorables à la réalisation de ces valeurs, est mieux laissé à un marché prédictif. Ce système peut littéralement être implémenté dans Tezos. Les parties prenantes devraient d’abord voter sur un flux de données de confiance, représentant la satisfaction d’une valeur. Cela peut être, par exemple, le taux de change des coins par rapport à un panier de monnaies internationales. Un marché de prévision interne serait créé pour estimer l’évolution de cet indicateur, sous réserve de l’adoption de diverses modifications du code. Le marché établi dans ces contrats, peut être subventionné en émettant des coins aux market-makers afin d’améliorer la découverte des prix et la liquidité. Finalement, l’amendement jugé le plus susceptible d’améliorer l’indicateur serait automatiquement adopté.

4.3. Résoudre les problèmes d’action collective

Le problème de l’action collective se pose lorsque plusieurs parties bénéficient d’une action mais que personne ne bénéficie d’une action individuelle. Ce problème est également connu sous le nom de problème du passager clandestin (free-rider). Les détenteurs d’une crypto-monnaie peuvent entreprendre plusieurs actions pour mieux se faire connaître ou se défendre contre des poursuites judiciaires.

4.3.1. Eveiller les consciences

En juillet 2014, la capitalisation boursière de Bitcoin s’élevait aux alentours de 8 milliards de dollars. En dépensant mensuellement environ 0,05% de sa masse monétaire, Bitcoin pourrait faire des dons de bienfaisance conséquents, d’un million de dollars chaque semaine. En 2014, une année entière de dons hebdomadaires augmenterait-elle la valeur de Bitcoin de plus de 0,6%? Nous pensons que la réponse est clairement et catégoriquement : «oui». Les parties prenantes de Bitcoin se porteraient bien tout en faisant le bien.

Cependant, les parties prenantes de Bitcoin ne sont pas en mesure d’entreprendre une telle opération en raison de la difficulté de former de gros contrats contraignants. Ce type de problème d’action collective est résolu dans Tezos. Un amendement au protocole peut mettre en place une procédure permettant aux parties prenantes de voter mensuellement sur quelques adresses où 0,05% de la masse monétaire serait dépensé. Les parties prenantes pourraient s’entendre pour éviter la dilution en votant sur une adresse invalide, mais il se pourrait également que l’argent soit mieux dépensé en dons de bienfaisance.

4.3.2. Financer l’innovation

Le financement de l’innovation serait également facilité par l’intégration directe des primes dans le protocole. Un protocole pourrait définir des tests unitaires et récompenser automatiquement toute proposition de code qui passe ces tests.

À l’inverse, un innovateur concevant un nouveau protocole pourrait inclure une récompense pour lui-même dans le protocole. Bien que son protocole puisse être copié et que la récompense soit retirée, le consensus de la partie prenante consisterait probablement à récompenser le créateur original. Les parties prenantes jouent à un jeu répété et il serait insensé de ne pas y participer en refusant une récompense raisonnable.

Conclusion

Nous avons présenté les problèmes liés aux crypto-monnaies existantes et proposé Tezos comme solution. Alors que l’ironie d’empêcher la fragmentation des crypto-monnaies en en publiant une nouvelle ne nous échappe pas, Tezos se veut véritablement la dernière crypto-monnaie. Quelles que soient les innovations produites par les autres protocoles, les parties prenantes de Tezos pourront adopter ces innovations. De plus, la capacité de résoudre des problèmes d’action collective et d’implémenter facilement des protocoles dans OCaml, fera de Tezos l’une des crypto-monnaies les plus réactives.

Références

    1. [1]  Peter Suber. Nomic: A game of self-amendment. http://legacy. earlham.edu/~peters/writing/nomic.htm, 1982.
    1. [2]  Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. https://bitcoin.org/bitcoin.pdf, 2008.
    1. [3]  Vitalik Buterin et al. A next-generation smart contract and decentral- ized application platform. https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-White-Paper, 2014.
    1. [4]  Nicolas van Saberhagen. Cryptonote v 2.0. https://cryptonote.org/whitepaper.pdf, 2013.
    1. [5]  Matthew Green et al. Zerocash: Decentralized anonymous pay- ments from bitcoin. http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf, 2014.
    1. [6]  Thomas Schelling. The Strategy of conflict. Cambridge: Harvard University Press, 1960.
    1. [7]  Bitcoin Wiki. Weaknesses. https://en.bitcoin.it/wiki/Attacks#Attacker_has_a_lot_of_computing_power, 2014.
    1. [8]  Gaving Andresen. Centralized mining. http://bitcoinfoundation.org/centralized-mining/, 2014.
  1. [9]  Bitcoin Wiki. Tragedy of the commons. https://en.bitcoin.it/wiki/Tragedy_of_the_Commons, 2014.17
    1. [10]  Bitcoin Wiki. Dominant assurance contracts. https://en.bitcoin.it/wiki/Dominant_Assurance_Contracts, 2014.
    1. [11]  Simon de la Rouviere. Not actually capped at 100 billion? https://github.com/dogecoin/dogecoin/issues/23, 2013.
    1. [12]  Debian project. Computer language benchmarks game. http://benchmarksgame.alioth.debian.org/u32/index.html, 2014.
    1. [13]  Scott Owens. A sound semantics for ocaml light. http://www.cl.cam.ac.uk/~so294/ocaml/paper.pdf, 2008.
    1. [14]  Ben Laurie. Decentralised currencies are probably impossible, but let’s at least make them efficient. http://www.links.org/files/decentralised-currencies.pdf, 2011.
    1. [15]  Vitalik Buterin. Slasher: A punitive proof-of-stake al- gorithm. https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/, 2014.
  1. [16]  Robin Hanson. Shall we vote on values, but bet on beliefs? http://mason. gmu.edu/~rhanson/futarchy2013.pdf, 2013.

Ce document est une traduction du Position Paper de Tezos, proposée par Tezos France.