Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
MASTER DE L’ECOLE POLYTECHNIQUE
Spécialité : « Projet Innovation Conception »
Blockchains, les plateformes logicielles décentralisées Etude des modes de fonctionnement et des mécanismes de gouvernance
Gautier MARIN-DAGANNAUD
Septembre 2016 - Août 2017
Entreprise partenaire : Ledgys
Tuteur d’entreprise : Quentin de Beauchesne
Tuteur académique : Rémi Maniak
Table des matières
Abstract 5 ..............................................................................................................Introduction 6 .......................................................................................................I. Bases de la blockchain 7 ...................................................................................
I.1. Introduction 7......................................................................................................I.2. Les origines de la blockchain 8...........................................................................I.3. Identifier les utilisateurs 9...................................................................................I.4. Les bases de la blockchain 9..............................................................................I.5. Créer un bloc : la « preuve de travail » 11..........................................................I.6. Propagation des blocs 12...................................................................................I.7. Au-delà de la monnaie 13...................................................................................
I.7.1. Internet de la valeur 13...........................................................................................I.7.2. « Colored Coins » et « Smart Contracts » 14.........................................................
I.8. Le rôle de la confiance 14...................................................................................II. Les plateformes 16 ...........................................................................................
II.1. Apport de la littérature 16...................................................................................II.1.1. Définition de plateforme et notions connexes 16...................................................II.1.2. Ouvrir les plateformes 17......................................................................................II.1.3. Les plateformes logicielles 18...............................................................................
II.2. Les plateformes blockchains 20.........................................................................II.2.1. Introduction 20.......................................................................................................II.2.2. Architecture simplifiée d’une blockchain 21...........................................................II.2.3. Exemples de cas 22..............................................................................................
II.2.3.1. Présentation de Ledgys 22............................................................................II.2.3.2. Sia, le « cloud décentralisé » 23....................................................................II.2.3.2. Ethereum 23..................................................................................................
II.2.3.2.1. Présentation de la plateforme 23........................................................II.2.3.2.2. L’incident « The DAO » 26..................................................................II.2.3.2.3. Aperçu de l’écosystème d’applications 28..........................................II.2.3.2.4. Un enjeu de la blockchain : l’enjeu légal 30........................................
II.2.3.3. Un exemple d’application Ethereum : Ownest 30..........................................II.2.3.3.1. Principe de fonctionnement 30...........................................................II.2.3.3.2. Avantages et inconvénients d’Ethereum 32........................................
�3
II.2.3.4. Tendermint et Cosmos : Un univers de blockchains 32.................................II.2.3.4.1. Tendermint, principe de fonctionnement 32........................................II.2.3.4.2. Tendermint, sécurisation et création de blocs 34................................II.2.3.4.3. Cosmos, univers de blockchains 35...................................................
III. Enjeu de la gouvernance 38 ..........................................................................III.1. Introduction 38..................................................................................................III.2. Apport de la littérature 39.................................................................................III.3. Ouverture et contrôle des plateformes blockchains 41.....................................
III.3.1. Blockchains « privées » 42...................................................................................III.3.1.1. Caractéristiques d’une blockchain privée 42.................................................III.3.1.2. Utilité d’une blockchain privée 43..................................................................III.3.1.3. Cas d’usages des blockchains privées 44....................................................
III.4. Création de valeur 45........................................................................................III.4.1. Plateformes logicielles actuelles 45......................................................................III.4.2. Plateformes blockchains 46..................................................................................
III.4.2.1. Le rôle des crypto-monnaies 46....................................................................III.4.2.2. Exemples d’ICOs 47.....................................................................................III.4.2.3. Distribution de la valeur dans une plateforme blockchain 48........................
III.4.2.3.1. Distribution pour un validateur 48......................................................III.4.2.3.2. Distribution pour un développeur d’application 49.............................
III.5. Coordination des acteurs 50.............................................................................III.5.1. Mécanismes de coordination dans les plateformes blockchains « classiques », mécanismes « off-chain » 50...........................................................................................
III.5.1.1. Répartition des responsabilités dans une blockchain « classique » 50........III.5.1.2. Prise de décision dans une blockchain « classique » 51..............................III.5.1.3. Exemple de situation conflictuelle dans Bitcoin 51.......................................
III.5.2. De nouveaux mécanismes de coordination des acteurs, les mécanismes « on-chain » 52........................................................................................................................
III.5.2.1. Sécurisation du réseau 53............................................................................III.5.2.2. Nouveaux modes de prises de décisions 54.................................................
III.5.2.2.1. Mécanisme de prise de décision 54..................................................III.5.2.2.2. Champ de la décision 54...................................................................III.5.2.2.3. Cosmos et Tezos en perspectives 56................................................
Conclusion 58 .........................................................................................................Références 59.........................................................................................................
�4
Abstract
La blockchain est une technologie permettant le déploiement de plateformes logicielles
ouvertes et décentralisées, c’est-à-dire sans acteur central de confiance. La première plateforme
blockchain est la crypto-monnaie Bitcoin. C’est de loin la plus connue. Cependant, la technologie
est présente dans de nombreuses autres plateformes, dont le nombre ne cesse de croître.
L’étude des plateformes logicielles et de leur gouvernance est un vaste domaine des sciences
de gestion. L’avènement des plateformes blockchain ouvre de nouvelles perspectives sur les modes
de fonctionnement des plateformes logicielles. Le domaine est très jeune et fait l’objet de
recherches actives, mais il est tout de même possible d’identifier un certain nombre de tendances
émergentes sur le fonctionnement de ces plateformes, notamment en ce qui concerne les
mécanismes de gouvernance.
�5
Introduction
La technologie blockchain est une innovation introduite en 2008 dans un papier publié sous
pseudonyme par Satoshi Nakamoto[1]. A l’origine, elle a été inventée pour permettre le
déploiement de la première crypto-monnaie décentralisée, Bitcoin. Depuis, son utilisation a été
étendue à de nombreuses autres applications. Cette technologie introduit de nouvelles perspectives
dans l’étude des plateformes logicielles. En effet, la quasi-totalité de la littérature s’intéresse aux
plateformes centralisées, c’est à dire fonctionnant avec un acteur central de contrôle (le créateur de
la plateforme dans la majorité des cas). C’est le cas des plateformes comme Android, Facebook,
Google, mais aussi des banques en ligne.
Les plateformes blockchains ne sont pas les premiers logiciels fonctionnant sans acteur
central de contrôle. De nombreux logiciels open-source fonctionnant sans acteur central existaient
avant l’apparition de la blockchain. Cependant, à la différence des plateformes blockchains, ces
logiciels ne possédaient pas de mécanisme de consensus résistants à un environnement hostile. En
clair, les plateformes blockchains possèdent ceci en plus qu’elles permettent aux utilisateurs de
s’accorder sur un état sans avoir recours à un intermédiaire, et sans avoir à se faire confiance les uns
avec les autres. Là où les logiciels open-source traditionnels permettent d’exécuter du code
indépendamment des autres utilisateurs, les plateformes blockchains permettent d’exécuter du code
en harmonie avec l’ensemble des autres utilisateurs. La blockchain est un mécanisme de consensus
qui permet à l’ensemble des utilisateurs du logiciel de s’accorder. Ces plateformes interactives d’un
nouveau genre ouvrent de nouvelles perspectives en ce qui concerne les problématiques
d’organisation et de gouvernance.
L’écosystème blockchain est un écosystème émergent. Afin de bien saisir les problématiques
qui s’y rattachent, j’ai travaillé dans une jeune startup française proposant des solutions
blockchains, Ledgys. Cette expérience m’a permis de vivre l’écosystème blockchain au plus près du
terrain et d’étudier un nombre important de cas d’usages. Bien que les plateformes blockchains
soient un phénomène très récent, un certain nombre de tendances concernant l’architecture des
plateformes et les modes de gouvernance commencent à émerger. Dans ce mémoire, nous nous
attacherons à étudier les modes de fonctionnement des plateformes blockchains ainsi que leurs
mécanismes de gouvernance.
�6
I. Bases de la blockchain
I.1. Introduction
Pour comprendre l’apport de la blockchain à la théorie des plateformes, il est indispensable
de comprendre les bases du fonctionnement de la technologie. Dans la suite, nous allons présenter
les concepts fondamentaux de la blockchain, ce qui permettra de clarifier ce qu’est (mais aussi, ce
que n’est pas) cette technologie.
Les plateformes logicielles actuelles (Facebook, Amazon, Uber, banques en ligne) ont toutes
un point commun, celui d’être organisées autour d’un acteur central chargé de maintenir leur
intégrité et d’assurer leur développement. Cette centralisation a des avantages, notamment en
termes de rapidité dans la gestion des conflits et de capacité à monter en charge, mais elle présente
également de nombreux inconvénients, comme la censure, le monopole ou la vulnérabilité aux
attaques.
La blockchain est une technologie permettant de partager une base de données de manière
décentralisée, c’est-à-dire entre acteurs ne se faisant pas nécessairement confiance et sans entité
centrale de contrôle. Elle rend possible la création d’un nouveau type de plateforme logicielle, les
plateformes décentralisées. Pour bien saisir ce changement de paradigme, il est nécessaire de
comprendre les bases du fonctionnement de cette technologie.
�7
Figure 1 : Deux systèmes de maintien d’un registre : centralisé vs décentralisé.
I.2. Les origines de la blockchain
À l’origine, la technologie blockchain a été inventée pour permettre la création de la
première monnaie numérique décentralisée, Bitcoin. Bitcoin est un système de paiement digital
s’appuyant sur la crypto-monnaie du même nom. Comme dans tout système de paiement, il est
nécessaire de tenir à jour un registre des comptes pour pouvoir connaître la balance financière de
chaque utilisateur. Dans le monde « réel », ce sont les banques qui tiennent ce registre. Si l’on
souhaite envoyer de l’argent à quelqu’un, il faut en faire la requête à la banque, puisque c’est elle
qui tient les comptes. On parle d’organisme centralisé. Le principe fondamental de Bitcoin est
relativement simple : au lieu que le registre soit maintenu par un seul organisme privé, il l’est de
manière décentralisée. En clair, chaque ordinateur (appelé nœud) du réseau contient une copie du
registre et aide à le maintenir à jour. Le registre est protégé par cette décentralisation. En effet,
même si un ou plusieurs nœuds sont altérés ou détruits, le registre sera conservé tant que
subsisteront des nœuds « honnêtes ».
�8
I.3. Identifier les utilisateurs
Les utilisateurs du réseau sont identifiés par leur adresse, qui permet aux autres utilisateurs
de leur envoyer des bitcoins. À chaque adresse est associée une clé privée. C’est elle qui permet de
« débloquer » les fonds. L’adresse est générée en local par l’utilisateur à partir de sa clé privée, et
ce, grâce à de complexes fonctions mathématiques, dont il suffit de retenir qu’elles fonctionnent à
sens unique. S’il est quasiment impossible de trouver la clé privée associée à une adresse donnée, il
est en revanche très facile de trouver l’adresse correspondant à une clé privée.
Pour débloquer les fonds, l’utilisateur n’a pas à communiquer sa clé privée au réseau. S’il le
faisait, n’importe quel nœud la recevant pourrait dépenser les fonds associés à l’adresse
correspondante. Au lieu de cela, il produit ‒ toujours en local ‒ une signature électronique associée
à la transaction qu’il souhaite effectuer. Cette signature électronique prouve que la personne
possédant la clé privée a bien approuvé la transaction. Elle est unique, ce qui signifie qu’elle ne peut
pas être réutilisée pour une autre transaction. De plus, la fonction permettant la création de la
signature est elle aussi à sens unique. Les nœuds du réseau ne peuvent donc pas deviner la clé
privée associée à cette signature.
Le mécanisme de la signature électronique permet donc d’autoriser des transactions sans
révéler la clé privée au réseau. Si la signature électronique est un outil indispensable au
fonctionnement de Bitcoin, ce n’est toutefois pas l’innovation apportée par la technologie
blockchain.
I.4. Les bases de la blockchain
L’innovation de la technologie blockchain porte sur le consensus. Plus précisément, il s’agit
d’apporter une solution au problème de la double dépense, un problème prépondérant dans tout
système décentralisé. Supposons qu’un utilisateur signe et envoie au même moment deux
transactions prenant en entrée le même bitcoin, mais ayant deux destinataires distincts. Certains
nœuds recevraient l’une des deux transactions en premier, ce qui invaliderait la seconde, tandis que
d’autres effectueraient le processus inverse. À l’échelle du réseau, il y aurait donc un désaccord sur
l’état du registre.
�9
Pour pallier ce problème, Bitcoin propose d’enregistrer de manière ordonnée et horodatée
les transactions dans une chaîne de blocs avec laquelle chacun des nœuds doit se synchroniser :
c’est la blockchain. Cette chaîne est unique et permet à tous les nœuds de s’accorder sur l’état du
registre. Les blocs contiennent une liste des transactions qui modifient l’état du registre. L’ajout de
blocs s’effectue au niveau de chaque nœud. Ainsi, tous les nœuds possèdent une copie à l’identique
de la blockchain (à quelques subtilités près). Chaque bloc référence le bloc précédent, ce qui forme
une chaîne de blocs qui s’étend jusqu’au « genesis block », le tout premier bloc à avoir été créé.
Pour connaître l’état du registre à un instant donné, il suffit de remonter la chaîne des blocs depuis
son origine jusqu’au dernier bloc ajouté avant l’instant considéré.
Figure 2 : Fonctionnement simplifié de la blockchain.
Après avoir été générée par un utilisateur, une transaction est transmise aux nœuds voisins,
puis relayée de pair en pair à travers le réseau. Pour qu’une transaction émise soit valide, il faut que
l’utilisateur dispose des fonds requis et que sa signature soit valide. Cependant, une transaction
n’est pas finalisée tant qu’elle n’a pas été incluse dans un bloc. De plus, deux transactions �10
concurrentes, c’est-à-dire qui tentent de dépenser les mêmes bitcoins, ne peuvent pas être incluses
dans le même bloc. Dans ce système, il est donc impossible d’effectuer une double dépense.
Reste à savoir quel nœud a le droit de créer le prochain bloc. Les nœuds créateurs de blocs
sont des nœuds spéciaux que l’on appelle « mineurs ». N’importe quel nœud peut devenir un
« mineur », il suffit pour l’internaute de disposer du matériel et du logiciel adéquats. Lorsqu’un
mineur reçoit une nouvelle transaction non validée, il la place dans ce que l’on appelle « l’ensemble
des transactions non confirmées ». Cet ensemble est propre à chaque mineur, il peut différer d’un
mineur à l’autre du fait du temps de propagation des transactions sur le réseau. C’est une sorte de
liste d’attente pour transactions, celles-ci en sortant une fois qu’elles ont été incluses dans un bloc.
I.5. Créer un bloc : la « preuve de travail »
N’importe quel mineur peut collecter un certain nombre de transactions dans sa liste, vérifier
leur validité et former un bloc. Cependant, ce bloc ne sera pas validé tant que le mineur n’aura pas
produit la preuve de travail (« Proof of Work ») associée au bloc considéré. Cette preuve de travail
est une donnée difficile à produire, mais facile à vérifier. Sans cette donnée, le bloc ne peut pas être
validé par les nœuds du réseau, même si les transactions qui le composent sont valides. Le fait qu’il
soit difficile de créer cette donnée permet de décider lequel des blocs créés par les mineurs sera
ajouté à la chaîne.
Pour produire cette donnée, les mineurs doivent calculer la valeur d’une fonction prenant
pour entrées l’empreinte1 (également appelée « hash ») du bloc précédent, l’empreinte des éléments
du bloc actuel et un nombre variable, appelé « nonce ». Les mineurs font varier ce nonce jusqu’à ce
que le résultat de la fonction réponde à des conditions prédéfinies par le protocole, notamment à un
paramètre nommé « difficulté », qui permet de définir l’étendue des résultats valides.
1Une empreinte, ou hash, est le résultat d’une fonction de hachage appliquée à une donnée initiale. La fonction de hachage est une fonction à sens unique. Son résultat est généralement un nombre hexadécimal (= de base 16) de taille fixe (256 bits, par exemple). Pour une même donnée initiale, on obtiendra toujours la même empreinte. En revanche, il
est quasiment impossible de déterminer la donnée initiale à partir de son empreinte.
�11
Plus la difficulté est élevée, et plus l’étendue est restreinte, ce qui rend la découverte d’un
nonce valide plus compliquée. Il est également important de noter que, là encore, la fonction est à
sens unique. Il est donc impossible de prédire à l’avance un nonce qui satisfasse aux conditions du
protocole. Ainsi, le seul moyen de trouver un nonce valide est de faire calculer à sa propre machine
un très grand nombre de nonces, d’évaluer pour chacun d’entre eux la valeur de la fonction et d’en
vérifier la validité. Pour un seul nœud, il faudrait en moyenne plusieurs années pour trouver un bloc
valide. À l’échelle du réseau, la difficulté est établie de telle sorte qu’en moyenne 10 minutes sont
nécessaires pour qu’un nœud trouve un bloc valide. Si la preuve de travail est difficile à produire,
elle est en revanche très facile à vérifier. Pour vérifier si une preuve est valide, il suffit d’évaluer la
valeur de la fonction pour le nonce donné. On peut faire une analogie avec la combinaison d’un
cadenas : trouver la combinaison par itérations est un processus très long, mais il est en revanche
très facile de vérifier si une combinaison ouvre le cadenas – dans notre cas, si elle est valide.
I.6. Propagation des blocs
Une fois la preuve trouvée, le nœud « gagnant » ajoute son bloc à la chaîne. On dit qu’il a
« miné » le bloc. Il reçoit en compensation une somme fixe déterminée par le réseau (12,5 bitcoins,
aujourd’hui), ainsi que les éventuels frais de transaction. Bitcoin encourage donc les mineurs à
entretenir le réseau en les récompensant par une rémunération. C’est par ailleurs de cette manière
que des bitcoins sont introduits dans l’écosystème.
Ensuite, le mineur transmet le bloc au reste du réseau. Tous les nœuds qui le reçoivent
vérifient la validité des transactions du bloc, ainsi que la preuve de travail, puis ajoutent le bloc à la
chaîne. Si le nœud est un mineur en train de chercher un bloc valide, il doit reprendre le processus
de création de bloc à partir de ce nouveau bloc créé (rappelons que tout bloc pointe sur le
précédent). Il est possible qu’un nœud du réseau reçoive des blocs ‒ ou des successions de blocs ‒
valides concurrents. Dans ce cas, la règle est de toujours prendre la chaîne la plus longue comme
référence.
�12
Figure 3 : Le basculement vers la chaîne de blocs la plus longue.
Cette règle implique que pour qu’un attaquant fasse accepter aux nœuds du réseau sa version
de la chaîne, il doit être en mesure de produire une chaîne de blocs valides plus longue que celle sur
laquelle travaillent tous les autres mineurs « honnêtes ». En d’autres termes, il doit posséder plus de
50 % de la capacité de calcul du réseau. C’est ce que l’on appelle une « attaque 51 % ». Le réseau
est donc d’autant plus sécurisé que la puissance de calcul combinée des mineurs est élevée. Notons
tout de même qu’une telle attaque ne permettrait pas aux attaquants de voler des bitcoins, puisque
ces derniers sont protégés par le mécanisme de signature digitale. Ils ne pourraient effectuer, tout au
plus, que des doubles dépenses ou des dénis de service.
I.7. Au-delà de la monnaie
I.7.1. Internet de la valeur
Au départ, l’innovation technologique de la chaîne de blocs avait été éclipsée par son
application première, la monnaie Bitcoin. Cependant, il n’a pas fallu longtemps pour que l’on
�13
prenne conscience de son potentiel. Les bitcoins ne sont qu’une suite de 0 et de 1, ils peuvent être
dupliqués sans effort. Comment s’assurer de la valeur d’un actif que l’on peut dupliquer
indéfiniment ? Dans le cas de la monnaie fiduciaire, on a recours à des autorités centrales qui
maintiennent l’intégrité du registre. Dans le cas de Bitcoin, c’est la blockchain qui assure la non-
multiplication de la monnaie. Le principal intérêt de la blockchain est sa capacité à donner de la
valeur à des actifs numériques, et ce, sans avoir recours à une autorité centrale.
I.7.2. « Colored Coins » et « Smart Contracts »
Les actifs numériques s’étendent au-delà de la monnaie. Par exemple, le protocole « Colored
Coins »[2] permet de représenter des actifs réels (actes de propriété, actions, obligations) via la
blockchain Bitcoin. D’autres blockchains ont été créées pour faciliter la création de tokens (des
jetons). L’une d’entre elles, Ethereum[3], est une blockchain permettant le déploiement de contrats
intelligents (« smart contracts »). Ces contrats sont des programmes dont l’exécution est assurée par
les nœuds du réseau. Ils permettent d’automatiser la logique contractuelle et de la transposer aux
actifs numériques. Avec Ethereum, il est possible de déployer une infinité d’actifs numériques
valorisés par la blockchain et d’en automatiser la gestion grâce à des contrats intelligents. Une fois
un tel contrat déployé sur le réseau, il est impossible d’en censurer l’exécution lorsqu’il est appelé,
ni de l’annuler. Seul un consensus mondial de l’ensemble des acteurs du réseau ‒ mineurs,
développeurs, échanges et utilisateurs ‒ peut permettre de revenir sur l’exécution d’un contrat. Cela
fait de la blockchain le système le plus résistant à l’intervention d’un tiers parti que nous n’ayons
jamais eu.
I.8. Le rôle de la confiance
La blockchain est une technologie de confiance. D’un point de vue purement académique,
c’est une technologie permettant de résoudre le problème des généraux byzantins sur un registre
répliqué. Nous l’avons vu, la blockchain permet à des acteurs ne se faisant pas confiance de
partager un registre. Les algorithmes de consensus sur registre distribué ne sont néanmoins pas
nouveaux. Nombre d’entre eux, comme Paxos[4] ou Raft[5], sont utilisés depuis longtemps dans
l’industrie.
�14
La spécificité des algorithmes byzantins est qu’il n’y a pas de présupposition concernant les
noeuds du réseaux. Cela signifie que les noeuds peuvent être malicieux. N’importe qui - y compris
des attaquants - peut se connecter et interagir avec les autres acteurs. Des systèmes de ce type
peuvent continuer à fonctionner tant que moins d’un tiers des acteurs est byzantin, c’est à dire
malicieux.
Des systèmes de ce type ont commencé à être envisagés par Castro et Liskov en 1999.
Cependant, ils n’étaient pas assez pratiques pour être déployés en conditions réelles. C’est avec
Bitcoin et la blockchain, qui ont rendu les systèmes résistants aux acteurs byzantins utilisables en
pratique, que l’intérêt pour de tels systèmes a été relancé. Aujourd’hui, de nombreuses entreprises et
chercheurs tentent d’améliorer l’algorithme initial de Bitcoin, la preuve de travail, pour le rendre
plus pratique, rapide et économique.
De plus, la majorité des entreprises développant des « blockchains 2.0 » tentent d’intégrer de
meilleurs mécanismes de gouvernance. En effet, les plateformes blockchains étant partagées entre
différents acteurs ne se faisant pas confiance, il est nécessaire de réinventer des mécanismes de
distribution de valeur et de résolution des conflits. Afin de comprendre tout cela plus en détails, il
est nécessaire de se pencher sur ce que la littérature nous apprend des plateformes logicielles.
�15
II. Les plateformes
II.1. Apport de la littérature
II.1.1. Définition de plateforme et notions connexes
D’après Baldwin et Woodard (2008), le concept de plateforme a été développé par les
chercheurs en gestion en 3 vagues distinctes se concentrant respectivement sur les produits, les
systèmes technologiques et les transactions.
Dans la première vague, les chercheurs en développement produit utilisent le terme
« plateforme » pour décrire une famille de produits d’une entreprise. Wheelwright et Clark (1992)
introduisent le terme « plateforme produit » pour décrire un ensemble de nouveaux produits conçus
pour être facilement modifiés (on voit apparaître ici la notion de modularité).
Dans la seconde vague, les plateformes sont identifiées comme point de contrôle dans une
industrie. La recherche a identifié l’avènement de meneurs de plateforme (« platform leadership »).
Notamment, Bresnahan et Greenstein (1999) ont développé une théorie pour expliquer l’évolution
de l’industrie informatique, qui s’est organisée autour d’un petit nombre de plateformes dominantes
alors même que la compétition était très intense.
Enfin, la dernière vague, portée par les économistes de l’industrie, utilise le terme
plateforme pour désigner des produits, entreprises ou institutions qui servent d’intermédiaires entre
au moins deux groupes d’agents (Rochet et Tirole, 2003).
En s’appuyant sur l’analyse de ces trois vagues, Baldwin et Woodard extraient une
définition unique du terme plateforme, suffisamment abstraite pour être applicable à toutes les
variantes précédemment évoquées. Selon eux, une plateforme est « un ensemble de composants
stables qui permettent à un système d’évoluer et de se diversifier en contraignant les liens entre les
autres composants ». Ainsi, toutes les plateformes ont une architecture similaire ; elles sont divisées
en un ensemble de composants « cœur » à faible variabilité et un ensemble de composants
« complémentaires » à haute variabilité.
Les composants à faible variabilité constituent la plateforme en elle-même. Ce sont des
composants réutilisables qui permettent d’atteindre des économies d’échelle. Cette dynamique a été
observée dès 1994 par Katz et Shapiro qui avaient conclu que la compétition dans l’industrie
�16
s’orientait de plus en plus vers une compétition entre écosystèmes basés sur des plateformes
(platform-centric écosystèmes). La notion d’écosystème est connexe à celle de plateforme.
Gawer et Cusumano (2002) définissent un écosystème comme la « collection d’une plateforme et
des modules spécifiques à cette plateforme ». Cette notion amène de nouvelles questions,
notamment sur l’ouverture des plateformes et de leurs écosystèmes, problématique qui a pris de
l’ampleur dans la littérature de ces dernières années.
II.1.2. Ouvrir les plateformes
Pour comprendre les implications que peuvent avoir l’ouverture ou la fermeture d’une
plateforme, il faut tout d’abord s’intéresser à la notion de plateforme-réseaux (« platform-mediated
networks »). Cette notion étend la sphère d’étude au-delà de l’écosystème. Aux acteurs de
l ’écosys tème - sponsors (propr ié ta i re e t const ructeur de la p la teforme) , e t
« complémenteurs » (développeurs de modules) - on ajoute les utilisateurs et les fournisseurs
d’accès (acteurs qui permettent l’accès aux écosystèmes). Chacun de ces rôles peut être ouvert
(Eisenmann, Parker, Alstyne, 2008), c’est à dire structuré de telle sorte que la participation
extérieure soit encouragée, ou fermée. Au niveau des sponsors, cela peut se traduire par une
coopération avec des plateformes concurrentes ou une attribution de licences d’exploitation
supplémentaires. En ce qui concerne les compléments, le sponsor peut se réserver le monopole sur
certains d’entre eux, ou bien en absorber dans le « cœur » de la plateforme.
La décision d’ouvrir une plateforme et, le cas échéant, de définir son niveau d’ouverture, est
crucial pour les entreprises qui créent et entretiennent des plateformes (Gawer et Cusumano, 2002 ;
West, 2003; Eisenmann, 2008). A chaque fois, les sponsors doivent trouver un compromis entre
adoption et appropriation. Ouvrir une plateforme peut stimuler l’adoption en s’appuyant sur des
effets réseaux, réduire les craintes des utilisateurs sur le contrôle auquel ils sont soumis et
encourager la production de biens différenciés qui répondent aux besoins d’une multitude de
segments utilisateurs. Néanmoins, cela réduit également le coût de conversion des utilisateurs
(adoption d’une plateforme concurrente) et augmente la compétition entre les fournisseurs d’accès
aux plateformes, ce qui diminue leur profitabilité à exploiter la plateforme (Eisenmann, Parker,
Alstyne, 2008).
�17
M.A. Schilling (2009) a également étudié le compromis entre protection et diffusion de
technologie. Elle commence par souligner que les recherches en management et économie
favorisaient traditionnellement l’appropriation, mais que les travaux plus récents tendent à remettre
en question cette assomption, en s’appuyant notamment sur la vitesse de diffusion des technologies
ouvertes. Ensuite, elle expose l’état de la recherche au moment où l’article est écrit, qui s’attache à
déterminer les avantages et inconvénients des différentes positions possibles sur l’échelle du
contrôle, qui s’étend de « complètement propriétaire » à « complètement ouverte ». Enfin, elle
identifie un facteur clé de succès : l’intégrité de la plateforme, c’est à dire sa capacité à ne pas se
fragmenter au travers de développements non coordonnés. Cette analyse conduit l’auteure à établir
une hypothèse qu’elle estime « controversée » : Etant donné que les plateformes ont besoin
d’intégrité, il est possible qu’une stratégie « complètement ouvert » ne soit jamais optimale, quelles
que soient les ressources de l’entreprise ou les conditions de l’industrie.
II.1.3. Les plateformes logicielles
Les plateformes logicielles ont connu un fort essor ces dernières années et ont acquis la
position de design dominant dans le secteur des services basés sur le logiciel. A l’inverse du
développement de logiciel traditionnel, ces plateformes mobilisent l’expertise d’une communauté
diverse de développeurs qui leur permettent d’évoluer au plus près de la demande utilisateur dans
des proportions que le propriétaire original n’aurait pu prévoir.
En s’appuyant sur la définition de Baldwin et Woodard (2008), Tiwana, Konsynski et Bush
(2010) définissent une plateforme-logicielle comme « le code source extensible d’un système
logiciel qui fournit les fonctionnalités de base partagées par les modules qui opèrent avec lui, ainsi
que les interfaces à travers lesquelles ils interagissent (e.g. iOS ou Firefox) ».
Ils définissent également un module comme un logiciel supplémentaire qui se connecte à la
plateforme pour y ajouter une fonctionnalité. Enfin, ils reprennent la définition d’écosystème de
Gawer et Cusumano (2002) comme la collection de la plateforme et de ses modules.
La littérature s’accorde pour dire que la compétition s’est déplacée au cours de ces dernières
années vers une compétition entre écosystèmes centrés sur des plateformes. Sont souvent cités les
navigateurs web (Firefox, Chrome, Opéra…), les systèmes d’exploitation pour smartphones (iOS et
Android), les services web (Google Payments, Amazon Elastic Cloud), les réseaux sociaux
(Facebook, Youtube, Snapchat), les places de marché (Amazon, eBay) et les consoles de jeux-vidéo �18
(Xbox, Playstation). L’analyse des dynamiques communes à ces écosystèmes révèle l’importance de
l’architecture de ces plateformes qui, combinées avec leurs principes d’organisations, déterminent
leurs trajectoires d’évolution (Tiwana, Konsynski et Bush, 2010). Très souvent, les auteurs
soulignent l’insuffisance de la recherche concernant les plateformes-logicielles, notamment sur les
problématiques d’ouverture, de coordination des acteurs de l’écosystème et de gouvernance (Bosch,
2009 ; Tiwana, Konsynski et Bush, 2010; Manikas et Hansen, 2012).
�19
II.2. Les plateformes blockchains
II.2.1. Introduction
Les plateformes blockchains sont des plateformes décentralisées. A l’inverse des
plateformes traditionnelles, elles fonctionnent sans acteur central de contrôle. Ci-après se trouve un
schéma soulignant les principales différences entre les plateformes logicielles traditionnelles et les
plateformes blockchains. Ce schéma présente ces différences d’un point de vue général, elles seront
détaillées dans la suite du mémoire.
Figure 4 : Comparaison plateformes logicielles traditionnelles vs plateformes blockchains
�20
II.2.2. Architecture simplifiée d’une blockchain
Les plateformes blockchains sont des plateformes logicielles décentralisées. Elles sont
constituées d’un code source public répliqué sur les nœuds du réseau. Ci-après est présenté un
schéma général de l’architecture d’une blockchain. Une blockchain peut être décomposée en 3
couches distinctes :
- La couche réseau, au niveau de laquelle sont gérées les communications entre nœuds.
Cette couche comprend les processus de transmission de messages de pair à pair et les mécanismes
de reconnaissance et d’authentification de noeuds.
- La couche consensus, au niveau de laquelle est gérée l’organisation des transactions et leur
ordonnancement en blocs. De manière conceptuelle, les noeuds utilisent la couche réseau pour
discuter et la partie consensus pour arriver à un accord sur l’état du registre grâce aux messages
envoyés.
- La couche application, qui gère la logique de transition, c’est-à-dire la validité et le
traitement des transactions qui modifient l’état du registre
Figure 5 : Architecture d’une plateforme blockchain
Une plateforme blockchain peut être une plateforme mono-application, c’est à dire que les 3
couches sont non-génériques et construits pour supporter cette unique application, ou multi-
�21
application, c’est à dire construite de manière à supporter le déploiement de multiples applications
décentralisées.
Dans la suite, nous allons étudier quelques exemples de plateformes et applications
décentralisées existantes pour bien comprendre leur diversité et leur mode de fonctionnement. J’ai
pu étudier de près ces plateformes lors de mon alternance chez Ledgys, que je vais également
présenter. Ce tour de table des applications décentralisées nous permettra de mettre en lumière les
problématiques et enjeux actuels des plateformes blockchains.
II.2.3. Exemples de cas
II.2.3.1. Présentation de Ledgys
Ledgys est une jeune startup française fondée en Janvier 2016. Elle comporte trois co-
fondateurs, Quentin Debeauchesne, Clément Bergé-Lefranc et Christophe Hénot. Originellement
axée autour d’un produit unique basé sur une blockchain publique, elle s’est peu à peu recentrée sur
la proposition de solutions blockchains pour les entreprises. Aujourd’hui, l’offre de Ledgys se
décompose en 3 axes : Formation, Conseil et Implémentation
Figure 6 : Offre de l’entreprise Ledgys
�22
Au sein de Ledgys, j’ai pu participer au développement de solutions blockchains et effectuer
un travail de veille technologique tout au long de l’année. Cela m’a permis d’être au contact de
l’ensemble des initiatives et innovations de l’écosystème en temps réel et d’en dégager les
principales tendances.
Ci-après, je vais présenter quelques plateformes blockchains représentatives des avancées de
l’écosystème et sur lesquelles j’ai effectué un travail de veille technologique tout au long de
l’année.
II.2.3.2. Sia, le « cloud décentralisé »
Sia[6] est un exemple de blockchain mono-application. Cette blockchain fonctionne de
manière similaire à Bitcoin mais possède des fonctionnalités supplémentaires lui permettant de
répondre aux besoins de l’application. Le but de Sia est de créer une plateforme de stockage
« cloud » décentralisée. Par rapport aux solutions de stockage numérique existantes comme Amazon
S3, Google Cloud ou Microsoft Azure, Sia promet d’être plus sécurisé, plus résistant et moins cher.
Grace à l’application Sia, n’importe quel utilisateur possédant de l’espace de stockage libre peut
proposer de le mettre en location, et n’importe quel utilisateur ayant besoin de stockage peut
demander à utiliser cet espace mis à disposition.
La blockchain sert à sécuriser les échanges monétaires entre acheteurs et loueurs ainsi qu’à
s’assurer de l’intégrité et de la disponibilité des données. Tout est automatisé : grâce à la
technologie blockchain, les deux partis n’ont pas à faire confiance à un intermédiaire, ce qui réduit
les coûts et la probabilité que les données soient altérées.
II.2.3.2. Ethereum
II.2.3.2.1. Présentation de la plateforme
Ethereum est la première plateforme blockchain ayant démocratisé le déploiement
d’applications décentralisées. Elle a été fondée en 2014 par Vitalik Buterin. A l’époque, la
blockchain commençait à être explorée pour des applications au-delà de la monnaie décentralisée.
En effet, la blockchain supporte un registre décentralisé. Ce registre peut maintenir les comptes de
la plus basique des unités de valeur, la monnaie, mais également d’actifs digitaux plus complexes,
comme des titres de propriétés, des obligations ou tout autre objet digital.
Un autre aspect important de la gestion du registre est celui de la logique applicative. Cette
logique gère les modalités de transition d’un état à l’autre du registre. Dans le cas de Bitcoin, la �23
logique est assez simple. Une transaction soustrait simplement une somme de Bitcoin du
portefeuille de l’émetteur pour l’ajouter à celui du destinataire (en réalité c’est un peu plus
complexe, voir [7] pour plus de détails). Cependant, pour des applications plus avancées, il est
nécessaire d’avoir des logiques de transitions d’état plus lourdes. Pour bien comprendre l’avancée
qu’a apporté Ethereum en 2014, il est nécessaire de bien comprendre comment fonctionne une
blockchain de manière conceptuelle.
Avant Ethereum, un développeur d’application blockchain avait globalement deux
possibilités : soit il utilisait la blockchain Bitcoin, ce qui limitait fortement ses possibilités, soit il
construisait une nouvelle blockchain. Pour ce faire, les développeurs devaient reconstruire
l’ensemble des trois couches constituant une blockchain, ce qui représentait un travail conséquent.
Pour pallier ce problème, Vitalik Buterin, aidé d’une dizaine de développeurs, a développé une
blockchain dont la couche application est une machine virtuelle permettant d’exécuter du code
arbitraire : Ethereum. En d’autres termes, Ethereum est une blockchain sur laquelle il est possible
de coder et déployer des programmes informatiques dont l’exécution sera répliquée sur l’ensemble
des noeuds du réseau. Ces programmes sont appelés contrats intelligents ou « smart contracts » et
constituent le cœur des applications décentralisées développées sur Ethereum. Ainsi, un
développeur souhaitant déployer une application décentralisée n’a pas à coder une blockchain
entière mais peut se contenter de déployer un ensemble de contrats intelligents sur Ethereum. Ce
faisant, il bénéficie de la sécurité, de la simplicité et de l’effet réseau d’une blockchain déjà établie.
�24
Figure 7 : Architecture de la blockchain Ethereum
Ethereum fonctionne avec une crypto-monnaie de base, l’ether, qui permet de payer les frais
de transactions. Pour qu’un contrat soit exécuté, il faut payer un certain montant en ether, appelé
gas, aux personnes qui exécutent le code et sécurisent le réseau. De plus, grâce aux contrats
intelligents, n’importe qui peut déployer sa propre crypto-monnaie en quelques lignes de code.
Cette crypto-monnaie sera une application décentralisée déployée et sécurisée par la plateforme
Ethereum. Ce type de monnaie, également appelée token, permet de représenter toutes sortes
d’actifs numériques. Ces actifs sont gérés par la logique programmatique définie dans les contrats
intelligents et, une fois déployés, personne ne peut en empêcher l’exécution s’ils sont appelés. Les
contrats intelligents peuvent communiquer les uns avec les autres, ce qui permet à des tokens d’être
utilisés dans d’autres applications décentralisées déployées sur Ethereum. Les contrats intelligents
forment donc un écosystème d’applications inter-opérables. Ces applications permettent de gérer
des actifs numériques de manière décentralisée, c’est-à-dire sans acteur central de contrôle et de
manière très résistante à la censure.
�25
II.2.3.2.2. L’incident « The DAO »
La promesse de Ethereum est de permettre le déploiement d’applications « impossibles à
arrêter ». Une fois déployées sur le réseau public, personne ne peut les en retirer. Si elles sont
appelées, elles seront exécutées selon le code qui les régit, et ce sans modification possible. Cette
promesse a été mise en perspective par un évènement qui a eu lieu en 2016, le hack de l’application
« The DAO »[8].
La blockchain Ethereum est sécurisée par le même mécanisme que Bitcoin, la preuve de
travail, mais la sécurité des contrats intelligents dépend de la qualité de leur code source. Il revient
au développeur du contrat intelligent de sécuriser son code de sorte à minimiser les failles
potentielles. Par conséquent, il est possible que certains contrats aient des défauts de construction
qui permettent à des attaquants de détourner des crypto-monnaies. Le fait que les applications
déployées sur Ethereum ne peuvent pas être arrêtées est à double tranchant : Ce qui est gagné en
résistance à la censure et en réduction de coût (lié à la suppression d’intermédiaires) rend plus
compliqué la prévention d’attaques contre des applications défaillantes.
En juillet 2016, l’application « The DAO » est lancée sur la plateforme Ethereum. « The
DAO » était une organisation autonome décentralisée dont le but était de mettre en place un fond
d’investissement décentralisé. La première phase fût une phase de collecte de fond, lors de laquelle
n’importe quel détenteur d’ether eut la possibilité d’envoyer des ethers à l’application pour
participer au fond. Lors de cette phase, l’application a récolté 11.5 millions d’ethers, ce qui
représentait 150 millions de dollar à l’époque et plus de 14% de la totalité des ethers existants.
Quelques semaines plus tard, un attaquant utilisa une faille dans un des contrats intelligents
de l’application pour dérober 3.6 millions d’ethers possédés par le fond d’investissement. Du fait de
la nature de la plateforme Ethereum, il était à priori impossible pour les utilisateurs de récupérer
leurs fonds. Le code n’avait pas été altéré, il ne s’était pas mal exécuté, il avait seulement été mal
conçu. Ethereum avait parfaitement fonctionné, ce sont les développeurs de l’application qui
avaient commis une erreur.
La communauté s’est alors retrouvée face à un dilemme. Le vol était conséquent, mais la
plateforme Ethereum n’avait pas eu de défaut de fonctionnement. La seule possibilité pour réparer
les dommages causés par le hack était d’effectuer un « hard fork » sur la plateforme Ethereum elle-
même. Un hard fork consiste à initier une nouvelle chaîne à partir de l’ancienne en modifiant le
registre ou le logiciel lui-même. La chaîne originelle n’est pas détruite (elle ne peut l’être), elle est
simplement dupliquée et modifiée. Une fois un hard fork effectué, deux chaînes co-existent et
�26
continuent leur évolution de manière indépendante. Les actifs numériques de la chaîne originelle
sont dupliqués et évoluent également de manière indépendante après la divergence.
La proposition de hard fork sur le chaine Ethereum donna lieu à un débat vif dans la
communauté.
D’un côté se trouvaient ceux qui pensaient que la chaîne ne devrait pas se séparer pour un
défaut dans une des applications qu’elle supporte. La blockchain elle-même ayant parfaitement
fonctionné, elle n’avait pas à être modifiée pour porter secours à une de ses applications. Modifier
le registre en effectuant un hard fork reviendrait selon eux à établir un mauvais précédent et à trahir
la promesse originale d’applications impossibles à stopper.
De l’autre côté, les défenseurs du hard fork défendaient le fait que ne rien faire serait le
mauvais précédent à établir, puisque cela signifierait que la communauté décentralisée composant
l’écosystème Ethereum serait prête à accepter un vol de grande ampleur sans rien faire. Selon eux,
la blockchain n’est qu’un outil permettant d’arriver de manière efficace à un consensus dans un
contexte public et décentralisé. Au final, ce sont des êtres humains qui possèdent les machines qui
sécurisent la blockchain et rien ne pourra les empêcher de s’accorder pour changer le registre si une
proportion suffisamment importante de la communauté supporte le changement. Dans le cas de
« The DAO », les défenseurs du hard fork défendaient le fait que le hack était suffisamment massif
pour justifier un changement dans la blockchain elle-même. Plus de 4% de la totalité des ethers
avaient été dérobés, ce qui constituait selon eux un montant trop massif pour laisser le hacker en
disposer. Effectuer un hard fork pour cette attaque ne signifiait pas que chaque faille serait
accompagnée d’une telle mesure, la communauté Ethereum étant suffisamment éclairée pour
pouvoir différencier chaque situation les unes des autres et déterminer si une telle solution est
nécessaire ou non.
Au final, le fork a eu lieu. Deux blockchains sont nées de ce fork. La chaîne originelle, sur
laquelle le hackeur a pu garder les tokens qu’il a dérobé, a pris le nom d’Ethereum classic. La
seconde, sur laquelle les investisseurs ont été remboursés, a gardé le nom d’Ethereum. Aujourd’hui,
les deux chaînes co-existent, et les deux tokens (ether classic et ether) sont utilisés. Cependant, c’est
la seconde, Ethereum, qui a capté le plus d’intérêt, du fait qu’elle a bénéficié du support de la
majorité des développeurs, échanges, mineurs et utilisateurs.
Cet incident a mis en lumière les problèmes de gouvernance que connaissent la plupart des
plateformes blockchains actuelles. Nous étudierons plus en détails cette problématique dans la suite
de ce mémoire.
�27
II.2.3.2.3. Aperçu de l’écosystème d’applications
Ci-après se trouve une liste succincte des applications Ethereum les plus connues.
• Augur[9] et Gnosis[10] - Ces applications sont des marchés prédictifs décentralisés. Elles
permettent aux utilisateurs de parier sur le résultat d’un évènement. Par exemple, des
questions à choix comme « Qui sera le prochain président des Etats-Unis » ou « Qui sera le
prochain lauréat de l’oscar masculin du meilleur acteur » peuvent être ouvertes par un
utilisateur. Ensuite, chaque personne possédant le token approprié peut parier sur l’évènement
qu’il juge le plus probable. S’il prédit le résultat correctement, il obtient la somme associée à
la côte au moment où il a effectué le pari. S’il se trompe, il perd la somme qu’il a pariée.
Tous les paris sont gérés par des contrats intelligents, c’est à dire sans courtier. Ces
plateformes promettent donc la possibilité de parier de partout dans le monde à frais réduits et
de manière complètement automatisée. Au-delà du simple pari, ces plateformes se vendent
comme des marchés prédictifs. En effet, les paris étant gérés par des contrats intelligents dont
le code est public, aucune manipulation n’est possible. Selon ces plateformes, l’absence de
friction ainsi générée permet à la modification des cotes suite à l’accumulation des paris de
tendre vers la probabilité exacte que l’évènement se réalise selon le choix donné. Elles
s’appuient sur la théorie de l’intelligence collective (« Wisdom of the crowd »[11]) selon
laquelle plus un nombre important d’acteurs divers (ici d’acteurs économiques dans un
contexte décentralisé) sont d’accords sur la finalité d’un évènement, plus cette finalité est
probable.
• Digix[12] : Digix est une plateforme permettant l’échange de matières précieuses de manière
décentralisée. Aujourd’hui, elle permet uniquement d’obtenir et d’échanger de l’or. Digix est
associée à une entreprise du même nom basée à Singapour qui stocke dans un coffre les
métaux précieux. Chaque gramme de métal est associé à un token déployé sur la blockchain
Ethereum. Ces tokens permettent à leur détenteur de réclamer leur or auprès de l’entreprise à
n’importe quel moment, en en faisant la requête puis en transférant les tokens à l’adresse de
l’entreprise. L’avantage de Digix est de permettre à n’importe qui dans le monde d’obtenir et
d’échanger très simplement des métaux précieux. Les tokens permettent de ne pas avoir à
sécuriser soi-même son or et de posséder un certificat de propriété sécurisé de manière
numérique, sans avoir à faire confiance à un intermédiaire.
�28
• Aragon[13] : Aragon est une application permettant le déploiement et la gestion simplifiée de
tokens d’organisations. Ces tokens peuvent représenter toutes sortes d’actifs liés à des
entreprises : actions, obligations, stock-options, BSA, etc. Ils peuvent être personnalisés selon
le statut ou les titres d’un membre de l’organisation. Aragon permet aussi d’automatiser un
paiement en ether (paiement d’obligation ou de salaire par exemple) et de conférer des droits
de vote aux détenteurs de certains tokens. Les avantages de Aragon sont similaires à ceux des
autres plateformes blockchains. Les titres sont possédés directement par leurs propriétaires
sans avoir besoin d’intermédiaire, les coûts de fonctionnement et ceux liés à la complexité
d’organisation des structures actuelles sont fortement réduits, et les tokens sont échangeables
avec n’importe quelle autre application de l’écosystème Ethereum. Ce dernier point permettra
notamment à une startup d’échanger certaines de ses actions sur le marché public Ethereum
sans avoir besoin (et bien avant) de faire une IPO.
• Contrat de levée de fonds ou ICO : Les contrats intelligents permettant de faire des « Initial
Coin Offering » (Distribution initiale de crypto-monnaie) sont de loin les plus utilisés.
En général, une application blockchain fonctionne avec un token central. Ce token doit être
distribué aux utilisateurs une première fois avant de pouvoir être utilisé. Pour ce faire, les
développeurs d’applications font ce qu’on appelle une « Initial Coin Offering » ou ICO. Cela
consiste à distribuer les tokens de l’application en échange d’une crypto-monnaie existante,
généralement l’ether. Les tokens sont distribués proportionnellement à la contribution de
chaque utilisateur. Généralement, l’entreprise qui crée l’application se réserve une partie des
tokens (5% à 20% en moyenne). C’est le principal business model des applications
décentralisées actuelles. Le but des développeurs est de faire monter la valeur du token de leur
application pour que leur propre stock s’apprécie. Ils se créent ainsi une incitation directe à
continuer le développement de la plateforme. Les fonds récoltés en ethers sont généralement
utilisés par les développeurs pour financer les coûts liés au lancement de l’application.
Cependant, les ICOs ne sont pas exemptes de critiques. En effet, des arnaques de plus en plus
nombreuses ont vu le jour (vente d’un token inutile par exemple). De plus, les montants levés
sont parfois ahurissants, atteignant les centaines de millions de dollar en équivalent ether, ce
qui soulève de nombreuses critiques et remises en question. Il ne faut pas oublier que les
ICOs, à l’instar de toutes les applications blockchains, n’en sont qu’à leur première itération et
qu’elles doivent par conséquent être considérées avec beaucoup de prudence.
A noter que les ICOs peuvent être également effectuées via d’autres blockchains comme
Bitcoin, mais que Ethereum reste de loin la plus utilisée pour ce cas d’usage. �29
II.2.3.2.4. Un enjeu de la blockchain : l’enjeu légal
Nous n’avons pu montrer qu’une toute petite partie des applications décentralisées
développées sur la plateforme Ethereum. Cependant, chacune de ces applications est confrontée à
d’importants enjeux légaux. C’est notamment le cas pour les applications ayant besoin de lier un
actif numérique à un actif réel (Digix pour l’or, Aragon pour les actions et obligations d’entreprise).
En effet, les blockchains étant des plateformes mondiales et décentralisées, elles existent par elles-
mêmes et ne peuvent être régulées par une entité centrale comme un gouvernement.
Les entreprises évoluant dans le domaine de la blockchain sont parfaitement conscientes des
problématiques liés à la validité légale des tokens qu’elles utilisent et ont commencé à intégrer les
autorités régulatrices comme les gouvernements ou les autorités des marchés financiers.
L’avantage des tokens supportés par la blockchain réside dans leur capacité à être
personnalisés. Il est par exemple tout à fait possible de faire porter à un token l’information qu’il a
été certifié par une adresse spécifique identifiée comme étant celle d’une autorité régulatrice. Ces
tokens auraient alors une valeur juridique dans le cadre donné par l’autorité considérée. Cependant,
pour que de tels tokens puissent voir le jour, un grand travail d’éducation et d’intégration reste à
effectuer.
II.2.3.3. Un exemple d’application Ethereum : Ownest
Ownest[14] est une application décentralisée que j’ai aidé à développer chez Ledgys. C’est
une application de traçabilité qui utilise la blockchain Ethereum pour représenter et tracer les actifs
des utilisateurs.
II.2.3.3.1. Principe de fonctionnement
Pour chaque objet tracé, un actif numérique correspondant est déclaré sur la blockchain
Ethereum via les contrats intelligents de la suite Ownest. Cet actif permet d’identifier le bien de
manière unique et d’en attribuer la possession à un acteur donné. Puisque l’actif est déclaré sur la
blockchain, aucune entité centrale ne peut changer ses caractéristiques et droits de propriété si cela
n’a pas été défini et autorisé préalablement par le contrat intelligent. La liaison entre l’actif
numérique et l’actif physique dépend de la valeur du bien. Il est impossible de faire un lien
complètement résistant à la manipulation, mais il est possible de faire un lien plus résistant pour un
actif de plus grande valeur. Par exemple, un objet de faible valeur pourra être identifié par une
simple référence facilement duplicable, tandis qu’un objet de grande valeur pourra être identifié par
une puce électronique placée à l’intérieur de l’objet et sécurisée à l’aide de méthodes �30
cryptographiques. A noter que Ownest n’a pas pour but de garantir l’authenticité du lien entre
l’objet physique et l’actif numérique. Ownest a simplement pour but d’établir une chaine de
propriété qui permet d’identifier clairement qui a possédé un objet considéré. Si un acteur de la
chaine se rend compte qu’on lui a transmis une contrefaçon, Ownest pourra fournir un faisceau de
preuve très puissant sur quels acteurs ont possédé le certificat électronique. Le nombre de potentiels
« coupables » est donc restreint, et les acteurs impliqués identifiés.
L’utilisateur qui possède un actif peut le transférer à un autre utilisateur, cédant ainsi ses
droits de propriété. Seul cet utilisateur est habilité à effectuer ce transfert, aucune autre entité n’en a
la possibilité (sauf si une telle clause a été préalablement inscrite dans le contrat intelligent). Ces
échanges étant enregistrés sur la blockchain publique Ethereum, il est possible de mettre en place
une chaîne de possession qui remonte jusqu’au créateur de l’actif. Cette chaîne permet à un
utilisateur de s’assurer que le bien a effectivement été créé par la bonne entité. En d’autres termes,
elle permet de garantir l’authenticité du bien.
Figure 8 : Chaîne de distribution Ownest
Ownest permet donc de tracer des actifs le long d’une chaine de possession, et ce de manière
décentralisée, publique et sans utiliser d’intermédiaires de confiance. Ce processus permet de
limiter fortement les fraudes et de réduire drastiquement les coûts de contrôle de chaines de
distribution ainsi que ceux liés aux pertes de produits. Par rapport à une solution centralisée, cette
solution a l’avantage de couter beaucoup moins cher et d’apporter une solution à des acteurs ayant
besoin d’interagir sans se faire confiance. Au lieu de déporter la confiance à un intermédiaire cher et
corruptible, nous utilisons la technologie blockchain.
�31
II.2.3.3.2. Avantages et inconvénients d’Ethereum
Grâce à Ethereum, Ledgys a pu déployer son application décentralisée sans avoir à lancer sa
propre blockchain. Nous avons pu profiter du langage solidity pour coder notre application, un
langage spécialement créé pour la blockchain Ethereum et relativement facile à apprendre. Nous
avons également pu profiter de l’équipe de développement de la plateforme Ethereum qui s’occupe
du maintien et de la mise à jour de la plateforme.
Cependant, Ethereum a ses défauts. Toutes les applications sont déployées sur la même
blockchain. Cela signifie que toutes les applications sont répliquées sur tous les noeuds du réseau.
Plus le nombre d’applications augmente, plus la blockchain grossit en taille. Le nombre de
transactions par bloc étant limité, cela signifie que les frais de transactions augmentent à mesure que
le nombre d’applications (et donc de transactions) augmente. Aujourd’hui, il est très cher de
déployer et d’utiliser une application sur la blockchain Ethereum. Les développeurs ne s’en cachent
pas, puisque cette plateforme est jeune et en phase de bêta. Des initiatives pour faire monter
Ethereum en charge sont en court de développement (e.g. le « sharding ») mais ne seront pas
opérationnelles avant plusieurs mois, voire années. Entre temps, le coût de la transaction va
continuer à augmenter, ce qui va rendre l’utilisation d’Ethereum de moins en moins attractive.
Cette problématique a conduit certains développeurs à envisager d’autres modèles
d’architecture pour le déploiement de plateformes blockchains et d’applications décentralisées.
Nous allons dans la suite de ce mémoire étudier l’un de ces modèles, celui de Cosmos.
II.2.3.4. Tendermint et Cosmos : Un univers de blockchains
II.2.3.4.1. Tendermint, principe de fonctionnement
Tendermint[15] propose un logiciel permettant de déployer des plateformes blockchains
rapides, peu coûteuses et capables de monter en charge. A l’inverse de Ethereum dont la vision
consiste à placer toutes les applications décentralisées sur une seule blockchain, Tendermint propose
de connecter les blockchains entre elles. Au lieu d’avoir une inter-opérabilité intra-blockchain
comme Ethereum, Tendermint propose une inter-opérabilité inter-blockchain.
Pour mieux comprendre, rappelons pourquoi Ethereum a été créée. Avant Ethereum, un
développeur d’application blockchain avait deux possibilités, soit il utilisait Bitcoin (compliqué et
possibilités limitées), soit il déployait sa propre blockchain, ce qui impliquait un travail important
car il devait créer les 3 couches réseau, consensus et application. Ethereum a donc entrepris de
faciliter la vie du développeur d’application décentralisée en proposant une blockchain agnostique �32
dotée d’un langage permettant le déploiement rapide et aisé de programmes appelés contrats
intelligents.
Tendermint propose une architecture offrant plus de modularité et de flexibilité aux
développeurs. Au lieu d’avoir une blockchain unique sur laquelle sont déployés tous les
programmes, Tendermint propose un logiciel s’occupant des couches réseau et consensus mais
laissant la couche application à la discrétion des développeurs.
Figure 9 : Architecture d’une blockchain Tendermint
Ce type d’architecture a plusieurs avantages. Tout d’abord, il facilite énormément le travail
du développeur. En effet, les couches réseaux et consensus d’une plateforme blockchain sont les
plus lourdes et compliquées à réaliser. En proposant un logiciel générique et puissant, Tendermint
permet aux développeurs d’avoir accès à des composants de qualité sans avoir à les créer eux-
mêmes. De plus, Tendermint permet aux développeurs d’avoir beaucoup de flexibilité quant au
langage qu’il souhaite utiliser pour développer leurs applications. En effet, Ethereum propose un
nombre de langages restreint qui doivent se conformer aux besoins de la plateforme (e.g. Solidity,
Serpent, LLL). Ces langages sont nouveaux, ce qui nécessite un temps d’apprentissage pour les
développeurs. De plus, ils sont peu développés (car jeunes) et offrent peu de possibilités. A
l’inverse, les développeurs utilisant Tendermint peuvent utiliser n’importe quel langage pour �33
développer leur application (C, C++, Python, Java, Javascript, etc.). Cela permet de faciliter l’usage
du logiciel et d’offrir une meilleure adaptabilité. En effet, un développeur est libre de choisir le
langage qu’il juge le plus spécifiquement adapté pour l’application qu’il souhaite développer.
Ce type d’architecture signifie aussi qu’il est très facile de déployer n’importe quelle
plateforme blockchain existante sur le moteur Tendermint. Il suffit de prendre la logique applicative
de la plateforme considérée et de la connecter au logiciel Tendermint. Par exemple, il est possible
de déployer la blockchain Ethereum sur le moteur Tendermint, bénéficiant ce faisant de sa rapidité.
Ce projet a déjà été réalisé sous le nom de Ethermint[16].
II.2.3.4.2. Tendermint, sécurisation et création de blocs
Tendermint, comme de plus en plus de logiciels blockchain, ne fonctionne pas avec la
traditionnelle preuve de travail présente dans Bitcoin et Ethereum. Pour rappel, la preuve de travail
est le mécanisme qui permet de décider quel nœud a le droit de créer le prochain bloc. Si un nœud
arrive à trouver cette preuve pour un bloc donné, le bloc sera valide. Ce mécanisme est
extrêmement sécurisé et robuste, mais il est également lent et couteux en énergie. Tendermint
fonctionne différemment. Un ensemble d’acteurs, appelés validateurs, est en charge de créer les
blocs. Conceptuellement, ce groupe peut être rapproché des mineurs d’une plateforme blockchain
fonctionnant avec la preuve de travail. A chaque bloc créé, un membre du groupe est désigné pour
créer le suivant de manière automatique et déterministe. Cet ensemble de validateur n’est pas fixe, il
évolue au cours du temps. Les modalités d’évolution du groupe de validateur et l’algorithme de
sélection du validateur du prochain bloc sont gérés au niveau de la couche application du système.
Cela signifie que selon la blockchain considérée, le mécanisme de sélection du prochain
créateur de bloc peut varier. Par exemple, dans un contexte privé, on peut imaginer que la création
de bloc se fasse à tour de rôle (pour plus de détails, voir section III.3.1.). Dans un contexte public, la
probabilité d’être le prochain validateur du groupe à être sélectionné pour créer un bloc peut
dépendre de la quantité de crypto-monnaies que l’on possède. Ce mécanisme de sélection est appelé
« Proof of stake » (preuve d’enjeu). La plupart des blockchains fonctionnant avec la preuve d’enjeu
sont encore considérées comme expérimentales, étant donné qu’elles n’ont eu l’épreuve du temps
pour prouver leurs robustesse, à l’inverse des blockchains fonctionnant avec la preuve de travail.
�34
II.2.3.4.3. Cosmos, univers de blockchains
L’un des principaux atouts de l’architecture Tendermint réside dans le fait que les
blockchains fonctionnant avec ce moteur sont inter-opérables. Plus précisément, il est possible
d’envoyer des tokens d’une blockchain Tendermint vers une autre grâce à un protocole appelé
« Inter-Blockchain Communication Protocol » (Protocole de Communication Inter-Blockchain). Ce
faisant, on obtient un « univers » de blockchains inter-opérables. Cet univers est appelé
Cosmos[17]. Il est composé de « zones », qui sont des blockchains « classiques » comme Bitcoin,
Ethereum ou Sia fonctionnant sur le moteur Tendermint, et de « hubs », qui servent de point de
connexion entre zones. Les hubs sont des blockchains qui servent à tenir un registre de compte des
tokens présents sur les différentes zones de l’écosystème. Une zone doit nécessairement passer par
un hub pour pouvoir envoyer des tokens à une autre.
Figure 10 : Un hub et des zones de l’univers Cosmos
Le Hub n’est pas unique, il peut en exister une infinité. Il n’est pas non plus centralisé,
puisque c’est une blockchain fonctionnant avec le moteur Tendermint.
Cosmos offre une solution extrêmement flexible. Un développeur d’application ne
souhaitant ou n’ayant pas besoin de déployer sa propre zone pourra utiliser une zone comme
Ethermint, il bénéficiera tout de même de l’écosystème Cosmos et ne sera pas limité à l’intra-�35
opérabilité au sein de Ethermint. Par ailleurs, un développeur souhaitant avoir sa propre blockchain
mono-application bénéficiera de l’écosystème de la même manière. Son application ne sera pas
limitée au silo de la blockchain sous-jacente, elle pourra échanger des actifs numériques avec
n’importe quelle autre zone de l’écosystème.
Cosmos peut en outre être considéré comme plus résilient que Ethereum. En effet, si la
plateforme Ethereum a un problème et cesse de fonctionner, l’ensemble des applications déployées
dessus cesseront de fonctionner. A l’inverse, si une zone de l’écosystème Cosmos a un problème de
fonctionnement, les autres zones de l’écosystème ne seront pas affectées. Elles pourront continuer à
être utilisées et à échanger de la valeur.
Cosmos n’est cependant pas indestructible. De manière conceptuelle, Tendermint enlève la
couche application de son logiciel pour la laisser à la discrétion du développeur, et permet aux
développeurs qui utilisent son logiciel comme base de se connecter avec les autres blockchains du
même type. L’écosystème Cosmos est donc résistant à un défaut dans la couche application d’une
ou plusieurs des zones qui le compose, au contraire de l’écosystème Ethereum. Cependant,
l’écosystème Cosmos n’est pas résistant à un défaut dans les couches réseau ou consensus. Si le
moteur Tendermint est défectueux, toutes les zones pourront être affectées. Dans ce cas, toutes les
zones de l’écosystème nécessiteront un hard fork pour résoudre le problème.
�36
Figure 11 : Architecture simplifiée de Cosmos
Aujourd’hui, Cosmos est en cours de développement. Tendermint est déjà fonctionnel et
utilisé, mais les fonctionnalités du Hub doivent encore être développées. Le lancement public de
l’écosystème Cosmos devrait avoir lieu à la fin de l’année 2017.
�37
III. Enjeu de la gouvernance
III.1. Introduction
Nous avons présenté quelques-unes des plateformes blockchains les plus connues.
Aujourd’hui, il en existe des centaines et toutes tentent d’apporter une innovation et de
perfectionner le design original de la blockchain Bitcoin. Les problématiques sont nombreuses :
montée en charge, ergonomie, législation, vie privée, autant de défis qui poussent chaque jour de
nouveaux acteurs à lancer de nouvelles plateformes. Parmi ces problématiques, celle de la
gouvernance est l’une des plus complexes et sujette à d’actives recherches.
Les plateformes blockchains sont des plateformes décentralisées. Cela signifie, comme nous
avons pu le voir, qu’elles fonctionnent sans autorité centrale de contrôle. Cependant, ne pas avoir
d’autorité centrale de contrôle ne signifie pas qu’il n’y a aucun contrôle. Les plateformes
blockchains ne sont pas statiques, elles doivent pouvoir évoluer. Cela signifie qu’il faut que les
acteurs prenant part à l’écosystème aient des moyens de s’accorder pour faire évoluer la plateforme
et prendre des décisions de manière collaborative.
La blockchain est une technologie permettant à des acteurs ne se faisant pas confiance de
s’accorder sur l’état d’un registre et sur son évolution selon les règles d’un protocole. Cependant,
les frameworks blockchain de base ne comportent pas de moyen incorporé au logiciel de mettre à
jour le protocole. Ils ne possèdent pas non plus de mécanismes de résolution de conflits et de prise
de décision collaborative. Pour ces tâches, les acteurs des blockchains « classiques » doivent utiliser
des moyens de communication dits « off-chain », c’est à dire en dehors de la blockchain. Ce sont
par exemple les forums ou les outils de discussion en ligne. Ce mode de fonctionnement est limité
et pose certains problèmes de montée en charge (à préciser). De manière générale, les mécanismes
de gouvernance sont très limités dans la plupart des blockchains existantes.
Dans la suite de ce mémoire, nous allons étudier plus en détails la notion de gouvernance
d’une plateforme logicielle. Nous décrirons quels sont les mécanismes de gouvernance actuels des
plateformes blockchains et quelles sont les initiatives qui ont été lancées pour tenter de les
améliorer.
�38
III.2. Apport de la littérature
La gouvernance des écosystèmes, et notamment ceux basés sur des plateformes logicielles,
est une problématique qui suscite de plus en plus d’intérêt chez les chercheurs en gestion. Alves,
Oliveira et Jansen (2010) ont entrepris une revue systématique de la littérature concernant la
gouvernance des écosystèmes logiciels. Ces chercheurs ont spécifié deux pistes de recherche pour
mener leur étude :
- Comment la gouvernance est-elle caractérisée dans la littérature sur les écosystèmes
logiciels ?
- Quels sont les mécanismes proposés pour gouverner un écosystème logiciel ?
La revue de littérature permet d’identifier plusieurs caractérisations du terme gouvernance.
Nous en retiendrons les suivantes : Pour Dubinsky et Kruchten (2009), la gouvernance est « la
façon dont une organisation est gérée, incluant ses pouvoirs, responsabilités et processus de
décisions ». Selon Ghazawne et Henfridsson (2010), la gouvernance des écosystèmes inclue « un
acte d’équilibre délicat du propriétaire de la plateforme pour garder le contrôle sur la plateforme
tout en cherchant à étendre la diversité des développeurs potentiels ».
Plus simplement, Tiwana, Konsynski et Bush (2010) définissent de manière générale la
gouvernance comme « qui décide de quoi dans un écosystème ». Ils insistent également sur le fait
que la gouvernance d’un écosystème « implique de partager les responsabilités et l’autorité,
d’aligner les incitations et de partager les enjeux ».
Les auteurs concluent en proposant leur propre définition de gouvernance : « Tous les processus qui
permettent à un acteur de créer de la valeur, coordonner les relations et définir qui contrôle quoi ».
Pour répondre à la seconde question, Alves, Oliveira et Jansen commencent par définir ce
qu’est un mécanisme de gouvernance d’écosystème. Selon ces auteurs, un mécanisme de
gouvernance d’écosystème est un outil de gestion dont le but est d’influencer la santé d’un
écosystème. Pour Tiwana (2010), ces mécanismes sont employés pour établir le niveau de contrôle,
les droits de décision et les droits d’appropriation.
La revue de littérature a permis de dégager 3 propositions de catégories dans lesquelles
classifier les différents mécanismes de gouvernance :
- Création de valeur : ensemble des mécanismes qui permettent de générer et distribuer la
valeur à travers l’écosystème. Ces mécanismes sont généralement proposés par le propriétaire de la �39
plateforme. Cette catégorie comprend toutes les incitations et bénéfices que les acteurs peuvent
obtenir en participant à un écosystème donné.
- Coordination des acteurs : ensemble des mécanismes qui permettent de maintenir une
cohérence et une intégration des activités, relations et structures d’un écosystème, afin d’obtenir une
coordination harmonieuse des acteurs de l’écosystème. Dans cette catégorie, les auteurs ont
identifié des mécanismes pour gérer les problèmes critiques, définir le rôle et les responsabilités de
chaque acteur, améliorer les moyens de communication et entretenir les collaborations.
- Ouverture et contrôle de l’organisation : Ces mécanismes traitent de la tension entre les
modèles d’organisation fermés et ouverts. Ils définissent dans quelle mesure le propriétaire de la
plateforme garde le contrôle et quelle autonomie sera accordée à la communauté.
Selon Tiwana, Konsynski et Bush (2010), la notion de contrôle fait référence à l’ensemble
des « mécanismes formels et informels implémentés par le propriétaire de la plateforme pour
encourager un comportement désirable chez les développeurs de modules, et vice et versa ». Ils
soulignent ensuite que le but des mécanismes de contrôle est de coordonner l'organisation plutôt que
de la protéger, et ce car la relation entre propriétaire de plateforme et développeurs de modules n’est
pas une relation principal-agent classique. Ils mentionnent également que le contrôle peut être
bidirectionnel : dans un modèle compétitif, les développeurs de module peuvent avoir un certain
contrôle sur les propriétaires de plateforme.
Un dernier attribut d’importance de la gouvernance mis en valeur par Tiwana, Konsynski et
Bush (2010) est celui de la propriété. La littérature sur les plateformes et écosystèmes donne une
place particulière aux propriétaires de plateformes, généralement identifiés à des entreprises.
Cependant, une plateforme peut être possédée par de multiples propriétaires (Eisenmann, Parker et
van Alstyne, 2006). Cette propriété ne doit pas être confondue avec la distinction « open vs closed -
source », qui stipule si les détails techniques de l’architecture d’une plateforme sont publics ou non.
Par exemple, Google Chrome est un logiciel propriétaire mais open-source, GNU Linux est open-
source et à propriété partagée et l’iOS d’Apple est propriétaire et closed-source. Pour les auteurs,
cette propriété influence l’évolution de la plateforme car elle détermine à quel point les enjeux sont
dispersés ou concentrés.
Pour finir, ils concluent en proposant des pistes de recherche, dont deux qui seront d’une
importance particulière pour notre étude : la relation entre nouvelles formes de gouvernance �40
et évolutions des écosystèmes, puis le rapport entre l’architecture des plateformes et la gouvernance
des plateformes. Notre sujet s’attache à montrer l’impact de la technologie blockchain sur les
plateformes logicielles. En proposant de nouveaux modes de gouvernance et de contrôle basés sur
une architecture technologique novatrice, la blockchain pourrait redéfinir l’organisation des
écosystèmes, la répartition des enjeux et intérêts des participants, et les mécanismes de contrôle.
III.3. Ouverture et contrôle des plateformes blockchains
Par construction, une blockchain n’est jamais contrôlée par un acteur central. Cela signifie
que les plateformes blockchains sont par essence collaboratives. Cela tranche avec la majorité des
plateformes actuelles qui sont pour la plupart contrôlées par le créateur du produit. Toutefois, bien
qu’elles ne soient jamais totalement fermées ou centralisées, les plateformes blockchains varient en
termes d’ouverture et de contrôle selon leur type.
Depuis le début de ce mémoire, nous n’avons abordé que les blockchains dites
« publiques ». Ces blockchains, comme Bitcoin ou Ethereum, sont open-source et non propriétaires.
Cela signifie que le logiciel est libre de droit et développé de manière communautaire. Cela signifie
également qu’il n’y a pas besoin de permission pour utiliser le logiciel et se connecter au réseau. Par
exemple, n’importe qui peut télécharger le logiciel Bitcoin, miner des bitcoins et les échanger avec
d’autres utilisateurs. Cependant, le propre de toutes les blockchains publiques est que le registre est
répliqué sur l’ensemble des noeuds d’un réseau ouvert. En d’autres termes, n’importe qui peut avoir
accès au registre. Pour certaines entreprises, ce manque de confidentialité est un problème.
Certaines blockchains publiques font des efforts en ce sens. Monero[18], par exemple, est une
blockchain publique qui garantit la confidentialité des transactions grâce à de complexes techniques
cryptographiques. Cependant, même si le registre est chiffré, il n’en reste pas moins public. De
nombreuses entreprises considèrent cela comme un problème pour certains cas d’usages. C’est ainsi
que sont apparus les blockchain dites « privées », également appelées registres distribués.
�41
III.3.1. Blockchains « privées »
Ces blockchains fonctionnent de la même manière que les blockchains publiques, à la
différence qu’elles limitent l’accès à certaines fonctionnalités à un nombre restreint d’acteurs
identifiés.
Par exemple, une blockchain privée peut autoriser n’importe qui à se connecter et utiliser le
réseau, mais restreindre le droit de créer des blocs, c’est à dire d’accepter des transactions, à un
groupe d’acteurs. Une blockchain privée peut également restreindre le droit de se connecter au
réseau, c’est-à-dire d’avoir accès au registre et de pouvoir envoyer des transactions, à un groupe
d’acteurs. Ce sera le cas si les données du registre sont hautement sensibles ou pertinentes
uniquement pour le groupe d’acteurs considéré.
Si l’on comprend qu’une blockchain n’est qu’un logiciel qui réplique un registre et une
logique de transition sur un ensemble de noeuds, on comprend qu’il est très facile de déployer une
blockchain publique dans un contexte privé. Par exemple, Multichain[19] est un logiciel adapté de
Bitcoin pour fonctionner de manière optimale dans un contexte privé.
D’autres logiciels blockchain comme Tendermint peuvent être déployés dans un contexte
privé sans avoir à les modifier. En effet, Tendermint laisse la couche application à la discrétion du
développeur. Ce dernier peut décider de développer son application pour qu’elle fonctionne dans un
contexte public ou privé. Dans les deux cas, le logiciel Tendermint, qui gère les couche réseau et
consensus, fonctionne de la même façon.
III.3.1.1. Caractéristiques d’une blockchain privée
• Une blockchain privée fonctionne généralement sans crypto-monnaie. Dans une blockchain
publique, la crypto-monnaie est essentielle au bon fonctionnement de la plateforme. En effet, elle
sert d’incitation aux acteurs qui effectuent le travail de sécurisation du réseau. Dans une
blockchain privée, les enjeux sont différents. Le groupe d’utilisateurs de l’écosystème est restreint
et les participants sont généralement identifiés. Cela signifie qu’il n’y a pas besoin de dépenser
énormément d’énergie pour sécuriser le réseau. En effet, dans une blockchain publique, personne
ne peut faire confiance à un acteur donné, puisqu’on ne connait pas son identité. C’est pour cela
que le mode de sécurisation de la preuve de travail ne s’appuie pas sur l’identité des acteurs mais
sur le coût d’opportunité représenté par la puissance de calcul qu’ils mettent à la disposition du
réseau. Dans une blockchain privée, les validateurs sont connus. Ils peuvent créer des blocs à tour
�42
de rôle sans avoir besoin de fournir une preuve de travail. S’ils dérogent au protocole, ils seront
exclus de la plateforme (rappelons que l’accès à la plateforme est soumis à permission dans une
blockchain privée) et perdront leur réputation. C’est pourquoi il n’y a pas un besoin fondamental
d’avoir une crypto-monnaie au cœur de la plateforme dans le cas d’une blockchain privée.
• Moins décentralisée : Une blockchain privée est généralement contrôlée par un nombre restreint
d’acteurs identifiés. Cela signifie qu’elle est beaucoup moins décentralisée qu’une blockchain
publique dans laquelle n’importe quel acteur peut participer au processus de contrôle et de
sécurisation. Cependant, ce n’est pas le but premier d’une blockchain privée que d’être
complètement décentralisé. Nous verrons en quoi elles peuvent être utile par la suite.
• Plus confidentielle : Une blockchain privée restreint généralement ses droits d’accès à des acteurs
identifiés. Cela signifie que pour se connecter au réseau et télécharger le registre depuis un pair, il
faut en avoir reçu l’autorisation préalable. Un tel registre distribué ne se dévoile donc qu’au
groupe restreint autorisé à se connecter, ce qui peut être avantageux dans le cadre d’un consortium
d’entreprises par exemple.
III.3.1.2. Utilité d’une blockchain privée
Une blockchain est une base de données partagée entre des acteurs qui ne se font pas
confiance. Si elle est publique, n’importe qui a le droit de la télécharger et d’y contribuer. Si elle est
privée, seules les personnes autorisées peuvent interagir avec. Dans les deux cas, il s’agit pour des
individus ne se faisant pas confiance de s’accorder sur l’état d’un registre.
La principale différence entre une blockchain privée et une base de données partagée comme
il en existe depuis longtemps réside dans le caractère byzantin des plateformes blockchains. Cela
signifie que la blockchain résiste non seulement à des défauts de fonctionnement comme un crash
serveur, mais aussi à des attaques volontaires venant de noeuds malicieux. Cela peut être utile dans
certains cas d’usages où les participants requièrent un important niveau de confiance. Par exemple,
des entreprises ne faisant pas confiance à leurs compétiteurs mais ayant besoin d’interagir avec eux
pourraient être intéressées par ce type de plateformes. C’est notamment le cas du consortium
R3[20], une initiative comportant plus de 70 institutions financières majeures dont le but est de
développer un logiciel de blockchain privée adapté à leurs besoins
�43
III.3.1.3. Cas d’usages des blockchains privées
Les cas d’usages identifiés des blockchains privées sont assez restreints. Selon Gideon
Greenspan[21], CEO de Multichain, il y a trois classes de cas d’usages (4 pour être précis, mais les
2 dernières coïncident) :
• Systèmes financiers allégés : Plusieurs entités ne se faisant pas confiance souhaitent mettre en
place un système financier entre elles. Ce système leur permet de se transmettre des actifs
numériques. Pour que de tels systèmes soient viables, il faut que la technologie utilisée assure
qu’un même actif ne puisse être transféré deux fois par son propriétaire (problème de la
double dépense), et qu’un actif ne puisse être créé sans qu’il corresponde à un bien réel, c’est-
à-dire qu’il ne soit pas possible de créer des contrefaçons. La technologie blockchain répond à
ces critères. Dans un contexte privé, elle permet également aux participants d’avoir une
certaine confidentialité en restreignant la lecture du registre.
• Systèmes de traçabilité : Dans ces systèmes, il s’agit de tracer des biens de valeur le long
d’une chaîne de distribution. Généralement, un token est créé lorsqu’un bien est enregistré.
Puis, le token est transmis à chaque fois que le bien réel est transmis. Ce faisant, il est possible
d’obtenir un historique de la chaîne de distribution d’un bien ainsi qu’un certificat de
provenance. S’il est important de cacher cette information aux personnes ne participant pas à
la chaîne de distribution, une blockchain privée peut être adaptée.
• Tenue de registre inter-organisationnelle : Il peut arriver que plusieurs parties ne se faisant pas
confiance aient besoin de maintenir un registre commun pour certaines informations. Par
exemple, les données KYC (« Know-Your-Customer ») qui donnent des informations sur les
clients d’une entreprise pourraient être partagées par plusieurs entreprises concurrentes pour
limiter la redondance et la complexité associées. Les entreprises d’un consortium peuvent
utiliser une technologie de blockchain privée pour partager de telles informations avec leurs
concurrents tout en gardant le contrôle dessus. Grâce à la blockchain, elles n’ont pas besoin de
faire appel à un intermédiaire de confiance, couteux et potentiellement corruptible.
Globalement, les cas d’usages des blockchains privées peuvent être également appliqués sur
des blockchains publiques. Dans certains cas où la confidentialité est d’importance capitale,
l’utilisation d’une blockchain privée peut être nécessaire. Cependant, si les blockchains privées
gagnent en confidentialité, elles perdent en inter-opérabilité. La barrière à l’entrée étant très basse
dans le cas des blockchains publiques, ces dernières bénéficient d’un effet réseau conséquent. Au
final, tout dépend du cas d’usage et de l’application considérés. Il est probable que les futurs �44
écosystèmes blockchains soient composés de blockchains privées interagissant avec des
blockchains publiques, et ce sans friction. Dans la suite de ce mémoire, nous nous intéresserons aux
blockchains publiques, ce type de blockchains étant le plus novateur et le plus utilisé.
III.4. Création de valeur
III.4.1. Plateformes logicielles actuelles
Dans un écosystème basé sur une plateforme logicielle, une des questions centrales est celle
de la création de valeur (business model) et de sa distribution, c’est-à-dire combien et à quels
acteurs donner. Dans les plateformes logicielles actuelles, les deux business model principaux sont
les suivants :
• Publicité : la plupart des plateformes « gratuites » pour les utilisateurs comme Facebook,
Youtube, Twitter ou Google Search créent de la valeur en vendant des espaces publicitaires
sur leur plateformes.
• Frais de transaction : le créateur de la plateforme prend une commission sur l’utilisation de sa
plateforme ou de l’un des modules qu’elle supporte. Par exemple, Apple prend une
commission sur l’achat des applications de son Apple Store. Mozilla propose Yahoo, Yandex
ou Baidu sur son moteur de recherche Firefox et perçoit une part des revenus générés par ces
modules. Enfin, les banques en lignes prennent une commission à chaque fois qu’un virement
est effectué.
Pour ce qui est de la distribution de valeur, c’est l’entité centrale créatrice de la plateforme
qui dans la quasi-totalité des écosystèmes actuels est en charge de distribuer la valeur aux
participants. De manière générale, la valeur créée selon le business model par l’ensemble des
composants de l’écosystème est redistribuée selon un modèle défini par le propriétaire de la
plateforme.
Les plateformes blockchains fonctionnent sans acteur central. Cela implique évidemment la
nécessité de trouver de nouveaux business model et de nouveaux moyens de distribuer la valeur aux
acteurs de l’écosystème. Les crypto-monnaies jouent un rôle fondamental dans ce mécanisme.
�45
III.4.2. Plateformes blockchains
III.4.2.1. Le rôle des crypto-monnaies
La décentralisation d’une plateforme logicielle a de fortes implications sur son business
model. La principale difficulté réside dans le fait que le code source du logiciel doit nécessairement
être open-source (c’est-à-dire public). En effet, les écosystèmes blockchain déplacent la confiance
d’un intermédiaire vers la technologie. Ce sont des systèmes où les acteurs n’ont pas à se faire
confiance les uns aux autres. Seule la confiance dans la technologie est nécessaire. Par conséquent,
si le code source n’est pas public, il est impossible de faire confiance à la technologie.
Le fait que le code source doive être public signifie qu’il est impossible pour les créateurs de
la plateforme de se rémunérer via des publicités ou des frais de transaction. En effet, si des frais de
transaction étaient inscris dans le code, n’importe quel développeur pourrait copier la plateforme et
la redéployer sans les frais de transaction. La plateforme ainsi créée serait plus attractive pour les
utilisateurs puisqu’elle serait moins couteuse. Le principe serait le même pour une plateforme ayant
des espaces publicitaires dans le code par défaut. A noter que ce principe n’est pas seulement
valable pour les plateformes blockchains, il l’est aussi pour l’ensemble des applications
décentralisées déployées sur des blockchains. C’est pourquoi, comme nous allons le voir, la quasi-
totalité des applications décentralisées incorpore un token au cœur de leur fonctionnement.
Les crypto-monnaies des plateformes blockchains publiques sont généralement cotées sur
des plateformes d’échanges qui permettent aux utilisateurs de les échanger contre d’autres crypto-
monnaies ou contre des monnaies fiduciaires comme le dollar ou l’euro. Il en résulte que chaque
crypto-monnaie a une valorisation en monnaie « courante », valorisation qui évolue en fonction de
l’offre et de la demande. Le business model des plateformes et applications blockchains consiste
généralement à faire augmenter la valeur de ces tokens.
Au lancement de la plateforme ou de l’application, les tokens sont distribués, et ce via une
ICO la plupart du temps. Généralement, les créateurs de la plateforme s’attribuent un certain
pourcentage de ces tokens (entre 5% et 20%). Dans le cas de certaines plateformes fonctionnant
avec la preuve de travail comme Bitcoin ou Monero, aucune ICO n’a eu lieu. Tout le stock de
monnaie est alors distribué via la création de blocs aux mineurs qui sécurisent le réseau. Les
créateurs de la plateforme sont alors incités à participer au développement futur de la plateforme en
achetant la monnaie auprès des mineurs (ou en la minant eux-mêmes) au début de la vie de la
plateforme avec pour perspective de pouvoir la revendre à un prix plus élevé. Dans tous les cas, les
�46
créateurs de la plateforme sont incités à la maintenir et continuer de développer des mises à jour
pour faire augmenter la valeur des tokens qu’ils possèdent.
III.4.2.2. Exemples d’ICOs
Le phénomène des ICOs a pris beaucoup d’ampleur depuis 2016. Les mécanismes de vente
de tokens diffèrent selon les projets. En effet, de nombreuses problématiques sont à prendre en
compte, et beaucoup d’ICOs ont été vivement critiquées pour avoir levé des montants trop élevés ou
pour avoir rendu la vente trop peu accessible.
Une équipe souhaitant distribuer un token via une ICO doit notamment considérer deux
paramètres :
• Le montant maximum pouvant être levé : Sur ce point, deux philosophies existent dans
l’écosystème blockchain. Certaines équipes ne souhaitent pas avoir de montant maximum (ou
alors un montant maximum très élevé, i.e. plusieurs centaines de millions de dollars), pour
protéger l’aspect décentralisé de la plateforme et permettre à tout le monde de participer. En
effet, un montant réduit autorise les gros détenteurs de capitaux à monopoliser une grande
partie des tokens. Cependant, ces développeurs s’exposent aux critiques qui avancent le fait
qu’aucune équipe n’a besoin de plusieurs centaines de millions de dollar pour construire un
logiciel, et qu’un tel montant enlève toute incitation à développer le produit. Ces critiques ont
pris de l’ampleur récemment avec les ICOs de EOS[22] et Tezos[23], deux plateformes
blockchains qui ont respectivement levées 185 et 232 millions de dollars.
D’autres équipes choisissent de fixer un montant maximum qu’elles jugent raisonnable, au
risque de limiter le nombre de détenteurs initiaux de token et d’avoir une proportion du stock
possédée par un nombre restreint de propriétaires. Par exemple, l’ICO de Cosmos ayant eu
lieu en Avril 2016 avait un montant maximum fixé à 17 millions de dollars, montant qui a été
atteint en moins d’une demi-heure[24].
• La distribution du token : Il s’agit de déterminer quelle portion du stock de token revient aux
contributeurs, et quelle portion revient aux créateurs de la plateforme. La plupart des
plateformes blockchains décident d’attribuer un pourcentage fixe aux créateurs (25% pour
Cosmos par exemple), mais d’autres adoptent des modes de répartition plus originaux. C’est
le cas de Gnosis qui a choisi d’utiliser une « enchère hollandaise inversée » pour distribuer ses
tokens. Le but de la vente est de distribuer un stock total de tokens à la quantité préalablement
définie. Dans une telle vente, le prix initial d’un token est placé à un niveau très élevé. A ce �47
prix, personne ou presque n’est censé acheter. L’incitation à ne pas acheter est renforcée par le
fait que la proportion de tokens retenus par l’équipe est de quasiment 100% au prix initial.
Puis, le prix décroit progressivement. A mesure que le prix décroit, la proportion de tokens
retenus par l’équipe décroit également. Les contributeurs ont donc une claire incitation à
attendre, puisqu’ils obtiendront une plus grande proportion du stock total de tokens à un prix
de plus en plus bas. Evidemment, il faut également prendre en compte le fait que le stock est
limité. Plus on attend, plus on court le risque de ne pas être en mesure d’acheter. Le but d’une
enchère hollandaise inversée est de laisser le marché décider du prix et de la répartition
adéquats au lieu de fixer des chiffres de manière arbitraire. Malheureusement, ce type de
vente ne fonctionne que si elle est bien préparée et expliquée. Les tokens mis en vente par
Gnosis ont quasiment tous été achetés au prix initial, de telle sorte que l’entreprise s’est
retrouvé avec plus de 95% des tokens entre les mains pour une valorisation du stock total de
300 millions de dollars. Selon certains experts, le prix initial fixé par Gnosis était trop bas, ce
qui a créé un effet de précipitation chez les investisseurs par peur de manquer l’opportunité.
Le mécanisme de baisse progressive du prix n’a donc quasiment pas eu lieu. Un prix initial de
plusieurs milliards de dollars par token aurait probablement permis d’avoir une baisse
progressive et une stabilisation autour du prix de marché.
III.4.2.3. Distribution de la valeur dans une plateforme blockchain
Les plateformes blockchains ont ceci de particulier qu’elles garantissent un contrôle total du
propriétaire sur ses actifs. Personne ne peut autoriser le transfert des actifs associés à une adresse
sinon celui qui en possède la clé privée. Cela signifie que chaque token reçu par une adresse a été
envoyé volontairement par une autre adresse, à l’exception des tokens créés via l’inflation dans le
cas des plateformes blockchains. Conceptuellement, la distribution de valeur dans un écosystème
blockchain n’est donc pas orchestrée par une entité centrale mais par une logique de marché libre.
Cette distribution varie cependant selon le type d’acteur considéré.
III.4.2.3.1. Distribution pour un validateur
Un validateur de plateforme blockchain est un agent dont le rôle est de sécuriser le réseau en
créant des blocs de transactions valides. Dans le cas de blockchains fonctionnant avec la preuve de
travail, les validateurs sont appelés mineurs. Pour leur travail de validation, ces agents peuvent
recevoir de la valeur selon deux moyens.
�48
Le premier est celui des frais de transaction. Lorsque l’on effectue une transaction de base
sur une plateforme blockchain comme Bitcoin ou Ethereum, on paie des frais de transaction aux
validateurs dans la monnaie de base du réseau (bitcoin ou ether). Ces frais sont associés à la
transaction. Les validateurs prennent les transactions ayant les frais les plus élevés pour les placer
dans les blocs. Cela signifie, la capacité de chaque bloc étant limité, que les frais de transactions ont
tendance à croitre à mesure que le volume de transaction augmente.
La seconde manière pour les validateurs de recevoir de la valeur est l’inflation. La quasi-
totalité des plateformes blockchains ont une inflation positive, c’est à dire une création monétaire.
Les tokens créés sont distribués aux validateurs en proportion de leur contribution à l’effort de
sécurisation du réseau. Le mécanisme d’inflation est surtout défendu comme nécessaire dans les
premières années de vie d’une plateforme blockchain, du fait que le volume de transactions est plus
faible lors du lancement du logiciel. Pour les blockchains fonctionnant avec la preuve de travail,
cette nécessité est d’autant plus évidente que l’inflation sert à distribuer le stock de tokens.
La plupart des plateformes blockchains prévoient de réduire l’inflation. Par exemple, il est
inscrit dans le protocole Bitcoin que la création monétaire par bloc est divisée par deux tous les 4
ans (aujourd’hui, un bloc rapporte 12.5 bitcoins à son mineur). Ce processus continuera jusqu’à ce
que le stock total de bitcoins disponibles atteigne 21 millions. Après, l’inflation sera de zéro. Le
choix de réduire l’inflation et de passer progressivement vers un modèle de rémunération des
validateurs basé uniquement sur les frais de transactions une fois la phase de lancement de la
plateforme achevée peut se comprendre par le fait que l’inflation est un chiffre fixe déterminé
arbitrairement. Il n’est pas adapté à des changements constants du volume de transactions comme
peut l’être un modèle basé sur des frais de transactions. Ce choix peut également être expliqué par
les principes philosophiques partagés par la majorité des premiers adoptants de la technologie, qui
considèrent l’inflation comme une taxe injuste sur le capital.
III.4.2.3.2. Distribution pour un développeur d’application
Nous avons vu que dans les plateformes logicielles traditionnelles, la valeur est
généralement distribuée aux développeurs de modules par le créateur de la plateforme. Dans le cas
d’applications blockchains, les développeurs de module créent généralement un token spécifique à
leur produit et nécessaire à son utilisation. Ce token est distribué via une ICO comme vu
précédemment, et une partie du stock est réservée pour l’équipe de développement. Une fois
distribué, ce token peut être échangé sur la plateforme blockchain qui le supporte contre d’autres
tokens (si la plateforme le permet), ou sur des plateformes d’échanges indépendantes de la �49
blockchain contre des crypto-monnaies d’autres plateformes ou des monnaies fiduciaires. Plus une
application est utilisée, plus le token est demandé et plus sa valeur augmente. Ainsi, les
développeurs d’application sont rémunérés par l’appréciation du token du module qu’ils ont
développé, et ce dans une logique de marché libre.
III.5. Coordination des acteurs
Dans les plateformes logicielles traditionnelles, c’est le créateur de la plateforme qui est en
charge de gérer les acteurs de l’écosystème. C’est lui qui est responsable de la résolution de conflits,
de l’amélioration du produit et de définir les responsabilités.
Dans une plateforme décentralisée, il est nécessaire de trouver de nouveaux moyens de
coordination. Le terme gouvernance, lorsqu’il est employé par les acteurs de l’écosystème
blockchain, fait généralement référence au mécanisme de coordination des acteurs. Les premières
plateformes blockchains n’incorporent pas de mécanisme de coordination, ce qui s’est révélé
problématique, comme nous allons le voir. C’est pourquoi de nombreuses blockchains « nouvelle
génération » tentent d’intégrer de tels mécanismes directement au sein de leur protocole.
III.5.1. Mécanismes de coordination dans les plateformes blockchains « classiques »,
mécanismes « off-chain »
III.5.1.1. Répartition des responsabilités dans une blockchain « classique »
Les blockchains « classiques » comme Bitcoin ou Ethereum répartissent les responsabilités
sur la base du volontariat. Il n’y a pas de permission à obtenir pour avoir un rôle spécifique dans
l’écosystème. Cependant, si tout le monde peut prétendre à avoir tel ou tel responsabilité au sein de
l’écosystème, toutes les voix n’ont pas la même importance. Le poids d’un acteur dépend du type de
responsabilité à laquelle il prétend.
Les deux responsabilités les plus importantes sont celles liées à la sécurisation du réseau
(validateurs) et aux mises à jour du logiciel (développeurs). Dans une plateforme blockchain
fonctionnant avec la preuve de travail, c’est la puissance de calcul qui définit le poids du validateur.
Dans une blockchain fonctionnant avec la preuve d’enjeu, c’est la quantité de crypto-monnaie
possédée qui définit le poids du validateur.
�50
En ce qui concerne les développeurs, le poids d’une contribution est généralement associé à
la réputation. Dans un contexte public et décentralisé, n’importe qui peut proposer des
modifications au code source du logiciel. Par exemple, pour le logiciel Bitcoin, il suffit de faire une
proposition de modification via un processus standard appelé « Bitcoin Improvement Proposal » ou
BIP[25]. De nombreux BIP sont ouverts mais seuls ceux proposés ou supportés par des
développeurs renommés seront réellement considérés par la communauté.
III.5.1.2. Prise de décision dans une blockchain « classique »
Le principal problème de gouvernance dans les plateformes blockchains actuelles concerne
la prise de décision. C’est notamment le cas lorsque plusieurs propositions d’amélioration ou de
résolution de conflit sont conflictuelles et qu’aucune majorité claire ne se dessine en faveur de l’une
d’entre elles. Etant donné qu’aucun mécanisme de résolution de conflit n’existe dans le logiciel des
blockchains « classiques », les membres de l’écosystème doivent avoir recours à des modes de
communication externes comme Reddit, Twitter ou Github. Ce mode de fonctionnement, appelé
gouvernance « off-chain », présente le double problème d’introduire une dépendance à des partis
externes à l’écosystème et de ne pas favoriser la clarté de la discussion. De plus, toute prise de
décision doit passer par un fork, c’est à dire une séparation de la chaine et donc de la communauté.
Un fork est un processus compliqué pour les acteurs de l’écosystème, et c’est pourquoi les
blockchains de nouvelle génération souhaitent en raréfier l’utilisation.
III.5.1.3. Exemple de situation conflictuelle dans Bitcoin
Bitcoin fixe une taille limite de 1 méga-octet sur les blocs de transaction. Cela signifie que
le réseau a une capacité maximale sur le nombre de transaction par seconde qu’il est en mesure de
traiter. Ce nombre de transaction est d’environ 7 par seconde. Bitcoin étant une plateforme gagnant
en popularité, de plus en plus de transactions sont envoyées, et le nombre de 7 transactions par
seconde a depuis longtemps été dépassé. Les transactions sélectionnées par les mineurs étant celles
dont les frais de transaction sont les plus élevées, le coût d’utilisation de Bitcoin a fortement
augmenté ces dernières années. Le réseau fait donc face à un clair souci de montée en charge.
Pour pallier ce problème, deux solutions ont émergé[26] :
• Segregated Witness (SegWit) / Lightning network : Cette solution en deux parties consiste à
réduire le poids des transactions en déportant une partie des données en dehors de la chaine
(Segregated Witness) et à réduire le nombre de transactions en déportant une partie des
transactions en dehors de la chaine (Lightning network). �51
• Modification de la taille des blocs : Cette solution consiste à faire varier la taille des blocs en
fonction du nombre de transactions. Plus le volume de transactions est élevé et plus la taille
des blocs le sera également.
Les défenseurs de la première solution attaquent le fait qu’une plus grande taille de bloc
porte atteinte à l’aspect décentralisé de Bitcoin. En effet, plus les blocs sont importants et plus ils
demandent de ressources aux mineurs. Des blocs de taille importante favorisent donc les « gros »
mineurs au détriment des petits, ce qui impacte négativement la décentralisation du réseau.
A l’inverse, les défenseurs de la seconde solution défendent le fait qu’une taille de bloc
arbitraire ne peut représenter la taille optimale, et que la solution proposée par le premier groupe ne
serait qu’une amélioration temporaire.
Ce débat, dont les premières traces remontent à 2010[27], a abouti le 1er Aout 2017 à un
hard fork dont 2 versions de Bitcoin ont émergé. La première, nommée Bitcoin, a activé le SegWit
et gardé une taille de bloc de 1 mega-octet. La seconde, nommée Bitcoin Cash, a gardé l’ancienne
version du protocole et augmenté la taille de bloc à 8 mega-octets. Bitcoin n’est pas la seule
blockchain à avoir connu de telles situations. Comme nous l’avons vu, Ethereum a également connu
un hard fork pour résoudre un problème qui avait divisé la communauté.
Au-delà des problèmes techniques du hard fork, comme les « replay attacks »[28] par
exemple, ces débats ont montré la difficulté des communautés décentralisées à résoudre les conflits.
Dans la communauté Bitcoin, certains voient cette difficulté à évoluer comme un atout de
résilience, mais d’autres considèrent que des blockchains plus ambitieuses en terme de possibilités
ne peuvent pas se permettre d’avoir un processus de prise de décision aussi lent et complexe.
III.5.2. De nouveaux mécanismes de coordination des acteurs, les mécanismes « on-
chain »
Certaines plateformes blockchains « nouvelle génération » considèrent la gouvernance
comme une caractéristique essentielle. Elles proposent de rendre plus optimale la prise de décision
en intégrant de nouveaux mécanismes directement sur la blockchain. Au lieu de débattre « off-
chain » et de prendre des décisions par hard fork, elles proposent d’incorporer des mécanismes de
vote et de changement de protocole directement dans le logiciel. Ce type de gouvernance est
appelée « on-chain ». De nombreuses blockchains de nouvelle génération proposent des
�52
mécanismes de gouvernance « on-chain ». Nous allons en étudier deux des plus connus : Cosmos
Hub[29] et Tezos.
Cosmos Hub et Tezos fonctionnent avec une crypto-monnaie centrale. Cette crypto-
monnaie, en plus d’être un moyen de paiement des frais de transaction, constitue un droit de vote.
Chaque détenteur de crypto-monnaies sur ces plateformes peut en déléguer une partie à un autre
utilisateur. Lorsque l’on délègue une crypto-monnaie (ou token), on en garde la propriété. Seul le
droit de vote est transféré. Ce mécanisme de délégation sert à répartir plusieurs responsabilités dans
l’écosystème, notamment les responsabilités de sécurisation et de prise de décision.
III.5.2.1. Sécurisation du réseau
Les validateurs du réseau sont les X adresses déclarées dont le poids est le plus important,
où le poids est la somme de la quantité de crypto-monnaie possédée par l’utilisateur et de la quantité
de crypto-monnaie qui lui est déléguée, et X un paramètre défini dans le protocole. Par exemple, si
X = 100, ce seront les 100 adresses s’étant déclarées comme candidates pour être validateur et dont
le poids est le plus important qui le deviendront. On comprend que cette liste est dynamique. Si un
validateur n’agit pas correctement, les utilisateurs arrêteront de lui déléguer des tokens et son poids
passera en dessous de celui du 100ème validateur, ce qui le rendra inactif.
Les validateurs sont identifiés et doivent maintenir une bonne réputation pour que les
utilisateurs leur délèguent des tokens. A l’instar des mineurs de Bitcoin ou Ethereum, un validateur
perçoit une récompense lorsqu’il crée un bloc. Cette récompense est partagée avec ses délégateurs
en proportion de leur contribution. Le validateur est libre de fixer des frais de transaction qui se
répercuteront sur le gain de ses délégateurs. Plus ces frais de transaction sont importants, et moins le
validateur sera attractif. La probabilité qu’un validateur soit choisi pour créer le prochain bloc est
exactement égale à la proportion de son poids dans le poids total des X validateurs. Par exemple, si
chacun des 100 validateurs a un poids de 1, alors chaque validateur aura une chance sur cent d’être
le prochain à créer un bloc.
Lorsqu’un validateur est sélectionné pour créer un bloc, il dispose d’un intervalle de temps
fini pour le faire. S’il ne produit pas de bloc dans cet intervalle, ou s’il produit un bloc frauduleux, il
est puni par le protocole. Dans ce cas, les personnes ayant délégué à ce validateur sont également
punies. C’est pourquoi la réputation des validateurs est vitale. Les utilisateurs ont un intérêt
économique direct à choisir un validateur honnête et performant.
�53
III.5.2.2. Nouveaux modes de prises de décisions
Dans la prise de décision, il faut distinguer le mécanisme de prise de décision et le champ de
la décision. Le mécanisme de prise de décision fait référence au modèle selon lequel est prise une
décision, c’est à dire l’ensemble des règles inscrites dans le protocole qui définissent le processus
qui aboutit à une décision. Le champ de la décision définit l’étendue du protocole sur laquelle il est
possible de prendre une décision.
III.5.2.2.1. Mécanisme de prise de décision
Dans Cosmos Hub et Tezos, le mécanisme de prise de décision est similaire. On l’a vu, les
crypto-monnaies centrales de ces plateformes confèrent à leurs propriétaires des droits de votes.
Outre le fait que les tokens permettent de participer au processus de sélection des validateurs, ils
permettent également d’élire des représentants qui se chargeront de prendre des décisions, à la
manière d’une démocratie indirecte. Le poids du vote d’un représentant est égal à la somme de ses
tokens et de ceux qui lui sont délégués. Les représentants peuvent être validateurs, mais ce n’est pas
nécessairement le cas. Ce type de système a l’avantage de prendre en compte le fait que la plupart
des utilisateurs du système n’ont pas l’intérêt, la disponibilité ou la compétence pour participer à
l’ensemble des prises de décisions. Dans Cosmos Hub, les représentants ont l’obligation de voter à
chaque décision, sous peine de subir une pénalité qui se répercute sur les personnes leur ayant
délégué des tokens. Ceci a pour but d’inciter les utilisateurs à déléguer leurs tokens à des
représentants non seulement capables de prendre de bonnes décisions, mais également des
représentants actifs. A noter que d’autres blockchains de « nouvelles génération » préfèrent un
système de vote direct au système de vote indirect, comme Dash[30] ou BOSCoin[31].
III.5.2.2.2. Champ de la décision
Le champ de la décision désigne ce sur quoi il est possible de prendre une décision via le
mécanisme de gouvernance intégré au logiciel. Les décisions qui sortent de ce champ doivent être
exécutées par un hard fork. Cosmos Hub et Tezos diffèrent sur ce point. Cela est dû à leur
différence d’architecture.
• Cosmos Hub
On l’a vu, les blockchains de l’univers Cosmos, dont les hubs, sont des blockchains
construites sur le moteur Tendermint.
�54
Figure 12 : Architecture d’une blockchain Tendermint (2)
Le mécanisme de prise de décision est défini au niveau de la couche application. Il est donc
spécifique à chaque blockchain de l’univers Cosmos. Cela implique que le mécanisme de prise de
décision ne peut pas modifier les couches réseau et consensus, à défaut de quoi la blockchain ne
serait plus compatible avec le reste de l’écosystème. Par conséquent, les modifications du moteur
Tendermint se font de la même manière que les modifications des blockchains Ethereum ou Bitcoin,
c’est-à-dire par un hard fork. Cependant, les modifications de la couche application ne nécessitent
pas de hard fork. Par exemple, l’incident « The DAO » ayant affecté Ethereum aurait pu être résolu
sans hard fork grâce au mécanisme de gouvernance du Cosmos Hub. D’autres exemples de
modifications possibles sont des modifications de paramètres, comme l’inflation ou le nombre de
validateurs. Le mécanisme de gouvernance permet aussi de voter sans engendrer nécessairement
d’exécution automatique de code. Cela peut être utile pour connaitre l’opinion des acteurs du réseau
dans le cas de modifications ne pouvant être gérées dans le protocole courant.
• Tezos
Tezos a une architecture similaire à Ethereum. C’est une plateforme dont le but est de
permettre le déploiement de contrats intelligents. Cependant, à la différence de Ethereum, Tezos �55
propose un modèle de blockchain muni d’un mécanisme de mise à jour automatique du protocole.
De plus, à la différence de Cosmos Hub, le champ de ces mises à jour couvre également les couches
réseau et consensus.
Figure 13 : Architecture de la blockchain Tezos
Pour modifier le protocole (quelle que soit la couche), un utilisateur peut ouvrir une
proposition de modification contenant le nouveau code à intégrer dans le logiciel. Pour éviter le
spam, il est possible de placer des frais de transaction minima que l’utilisateur doit régler pour que
sa proposition puisse être considérée. Une fois la proposition soumise au réseau, les représentants
disposent d’un intervalle pour voter. Si elle est acceptée, la modification de code associée est
automatiquement intégrée au logiciel de chacun des noeuds.
III.5.2.2.3. Cosmos et Tezos en perspectives
La grande majorité des acteurs de l’écosystème de la blockchain s’accordent pour dire que
les hard fork doivent être limités dans une plateforme blockchain. Cependant, s’affranchir
totalement de la nécessité de hard fork nécessite un compromis sur l’inter-opérabilité du système.
Dans le cas de Tezos, le fait que les 3 couches de la plateforme puissent être mises à jour
directement via le protocole limite de manière quasi totale le besoin d’effectuer des hard fork. �56
Cependant, cela enlève toute possibilité d’avoir des couches génériques et donc une inter-
opérabilité entre différentes blockchains qui gardent leur indépendance. Cosmos renonce à limiter
totalement les hard fork pour bénéficier de cette inter-opérabilité. Tezos mise sur l’intra-opérabilité
d’une plateforme unique capable d’évoluer tandis que Cosmos mise sur l’inter-opérabilité d’une
multitude de plateformes partageant une base commune. Ces deux choix de design peuvent tous les
deux être défendus et seule l’épreuve du temps permettra de déterminer lequel est le plus efficace.
�57
Conclusion
Dans ce mémoire, je me suis appuyé sur de nombreux cas que j’ai pu étudier lors de mon
année chez Ledgys afin d’exposer le fonctionnement des plateformes décentralisées utilisant la
technologie blockchain.
Nous avons tout d’abord montré comment les plateformes blockchains fonctionnent et en
quoi elles se différencient des plateformes logicielles traditionnelles. Notamment, nous avons
souligné l’importance de l’aspect collaboratif de ces plateformes et du rôle des crypto-monnaies.
Puis, nous nous sommes intéressés plus particulièrement à la problématique de la gouvernance.
Nous avons tout d’abord étudié la littérature sur la gouvernance des plateformes logicielles et en
avons identifié les trois mécanismes principaux que sont l’ouverture et le contrôle, la création de
valeur et la coordination des acteurs. Ensuite, nous avons identifié grâce à l’étude de nombreux cas
les tendances émergentes des plateformes blockchains pour chacun de ces mécanismes.
Pour l’ouverture et le contrôle, nous avons présenté les différences entre blockchains
publiques et blockchains privées. Pour la création de valeur, nous avons mis en valeur le rôle central
des crypto-monnaies. Enfin, pour la coordination des acteurs, nous avons montré l’état actuel de la
situation dans les blockchains bien implantées comme Bitcoin et Ethereum, celui d’une
gouvernance « off-chain », et exploré les tentatives d’amélioration de nouvelles plateformes qui
visent à intégrer des mécanismes de gouvernance « on-chain ».
Si les plateformes décentralisées ne sont que très peu développées aujourd’hui, il est
cependant clair qu’elles apportent de nouvelles perspectives au domaine des plateformes du point
de vue des sciences de gestion. Il serait intéressant de poursuivre l’étude de l’écosystème
blockchain dans les années à venir pour continuer à développer ces perspectives et approfondir les
premières tendances évoquées dans ce papier.
�58
Références
Références académiques
Academy, T., & Review, M. (2000). Toward a General Modular Systems Theory and Its Application
to Interfirm Product Modularity. The Academy of Management Review, (April 2000).
Alves, C., Oliveira, J., & Slinger, J. (2010). Software Ecosystems Governance : A Systematic
Literature Review and Research Agenda.
Baldwin, C. Y., Woodard, C. J., & Woodard, C. J. (2008). The Architecture of Platforms : A Unified
View The Architecture of Platforms : A Unified View. SSRN Electronic Journal.
Baldwin, C. Y. (2012). Organization Design for Business Ecosystems Organization Design for
Business Ecosystems, (May 2012).
Berk, I. Van Den. (2010). Software Ecosystems : A Software Ecosystem Strategy Assessment
Model, (c).
Bosch, J. (2009). From Software Product Lines to Software Ecosystems.
Bosch, J., & View, M. (2010). Architecture Challenges for Software Ecosystems, 93–95.
Bresnahan, F.T., & Greenstein, S. (1999) “Technological Competition and the Structure of the
Computer Industry.” The Journal of Industrial Economics, Blackwell Publishers Ltd, 27
Buterin, V. (2009). A next-generation smart contract & decentralized application platform,
(January), 1–36.
Chesbrough, H. W. (2007). Have Open Business Models
Cusumano, M.A., and Gawer, A. (2002) “The Elements of Platform Leadership.” MIT Sloan
Management Review
Dubinsky, Y, & Kruchten, K. (2009). “Software Development Governance (SDG): Report on 2nd
Workshop.” ACM SIGSOFT Software Engineering Notes, ACM.
Eisenmann, Thomas R, & Van Alstyne, W. M. (2006) “Strategies for Two-Sided Markets.” Harvard
Business Review, 26 Aug. 2015.
Eisenmann, Thomas R. (2008) “Managing Proprietary and Shared Platforms.” California
Management Review, vol. 50, no. 4, 2008, pp. 31–53.
Eisnmann, T.R., Parker, G., & Marshall, V. A. (2008). Opening Platforms : How , When and Why ?
SSRN Electronic Journal, (March).
Gawer, A. (2014). Bridging differing perspectives on technological platforms : Toward an
integrative framework. Research Policy, 43(7), 1239–1249.
Gawer, A. (2014). Industry Platforms and Ecosystem Innovation. Journal of Product Innovation
Management, (May 2014).
�59
Katz, M. L., & Shapiro, C. (1994). Systems Competition and Network Effects. Journal of Economic
Perspectives, 8(2), 93–115.
Manikas, K., & Hansen, K. M. (2013). Software Software ecosystems – A systematic literature
review. The Journal of Systems & Software, 86(5), 1294–1306.
Nakamoto, S. (2008). Bitcoin : A Peer-to-Peer Electronic Cash System, 1–9.
Rochet, J., & Tirole, J. (2003). Platform competition in two-sided markets. Journal of the European
Economic Association.
Schilling, M. A. (2009). Protecting or diffusing a technology platform : Tradeoffs in
appropriability , network externalities , and architectural control.
Tiwana, A., Konsynski, B., & Bush, A. A. (2010). Platform Evolution : Coevolution of Platform
Architecture , Governance , and Environmental Dynamics. Information Systems Research,
675–687.
West, J. (2003). How open is open enough ? Melding proprietary and open source platform
strategies, 32, 1259–1285
Wheelwright, Steven C., & Kim B. Clark. (1992). “Creating Project Plans to Focus Product
Development.” Harvard Business Review
Autres références
[1] https://bitcoin.org/bitcoin.pdf
[2] https://en.bitcoin.it/wiki/Colored_Coins
[3] https://github.com/ethereum/wiki/wiki/White-Paper
[4] https://en.wikipedia.org/wiki/Paxos_(computer_science)
[5] https://raft.github.io/
[6] https://www.sia.tech/whitepaper.pdf
[7]https://www.ethereum-france.com/comprendre-la-blockchain-ethereum-article-1-bitcoin-
premiere-implementation-de-la-blockchain-12/
[8] https://en.wikipedia.org/wiki/The_DAO_(organization)
[9]https://bravenewcoin.com/assets/Whitepapers/Augur-A-Decentralized-Open-Source-Platform-
for-Prediction-Markets.pdf
[10]https://gnosis.pm/resources/default/pdf/gnosis_whitepaper.pdf
[11] https://en.wikipedia.org/wiki/Wisdom_of_the_crowd
[12]https://digix.global/whitepaper.pdf
[13]https://github.com/aragon/whitepaper/blob/master/Aragon%20Whitepaper.pdf �60
https://ledgys.io
[14] https://ownest.io/
[15] https://tendermint.com/static/docs/tendermint.pdf
[16] https://github.com/tendermint/ethermint
[17] https://cosmos.network/whitepaper
[18] https://getmonero.org/
[19] https://www.multichain.com/download/MultiChain-White-Paper.pdf
[20] https://www.r3.com/
[21] https://www.multichain.com/blog/2016/05/four-genuine-blockchain-use-cases/
[22] https://fundraiser.cosmos.network/
[23] https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md
[24] https://www.tezos.com/governance
[25] https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals
[26] https://blog.sendwyre.com/bitcoin-scaling-debate-db3019603541
[27] http://fortune.com/2017/08/11/bitcoin-cash-hard-fork-price-date-why/
[28] https://en.wikipedia.org/wiki/Replay_attack
[29] https://cosmos.network/
[30] https://www.dash.org/wp-content/uploads/2015/04/Dash-WhitepaperV1.pdf
[31] https://boscoin.io/en/home/
�61