Blockchains, les plateformes logicielles décentralisées Ledgys.pdf · Septembre 2016 - Août 2017...

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://bitcoin.org/bitcoin.pdf

https://en.wikipedia.org/wiki/Paxos_(computer_science)

https://www.ethereum-france.com/comprendre-la-blockchain-ethereum-article-1-bitcoin-premiere-implementation-de-la-blockchain-12/

https://en.wikipedia.org/wiki/The_DAO_(organization)

https://gnosis.pm/resources/default/pdf/gnosis_whitepaper.pdf

https://en.wikipedia.org/wiki/Wisdom_of_the_crowd

https://digix.global/whitepaper.pdf

https://github.com/aragon/whitepaper/blob/master/Aragon%20Whitepaper.pdf

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

https://ownest.io/

https://tendermint.com/static/docs/tendermint.pdf

https://github.com/tendermint/ethermint

https://cosmos.network/whitepaper

https://www.r3.com/

https://www.multichain.com/blog/2016/05/four-genuine-blockchain-use-cases/

https://fundraiser.cosmos.network/

https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md

https://blog.sendwyre.com/bitcoin-scaling-debate-db3019603541

http://fortune.com/2017/08/11/bitcoin-cash-hard-fork-price-date-why/

https://en.wikipedia.org/wiki/Replay_attack

https://cosmos.network/

https://www.dash.org/wp-content/uploads/2015/04/Dash-WhitepaperV1.pdf

Blockchains, les plateformes logicielles décentralisées Ledgys.pdf · Septembre 2016 - Août 2017...

Documents

Transcript of Blockchains, les plateformes logicielles décentralisées Ledgys.pdf · Septembre 2016 - Août 2017...