Ci-après une traduction en français de l’article original The Meaning of Decentralization par Vitalik Buterin. La traduction française et l’annotation sont de Morgan Phuc pour le site BitConseil. Merci à lui d’avoir accepté la publication de cette traduction sur ce site.

. . .

“Décentralisation” est l’un des mots les plus fréquemment utilisés dans la sphère crypto-économique, et cette notion est souvent perçue comme la seule raison d’être de la blockchain, mais c’est aussi l’une des moins bien définies. Des milliers d’heures de recherches, et des milliards de dollars de puissance de calcul, ont été dépensés dans le seul but d’essayer d’en arriver à la décentralisation, de la protéger et de l’améliorer; et lorsque les discussions s’enveniment il est extrêmement courant pour les partisans d’un protocole (ou d’une extension du protocole) de prétendre que les propositions opposées sont “centralisées” comme argument ultime.

Mais il y a souvent beaucoup de confusion sur le sens réel de ce mot. Considérons, par exemple, le diagramme suivant, tout à fait inutile, mais malheureusement trop commun :

 

Maintenant, considérons les deux réponses sur Quora à la question “quelle est la différence entre distribué et décentralisé ?“. La première est essentiellement la répétition du diagramme ci-dessus, “décentralisé signifie qu’aucune entité n’a le contrôle sur l’ensemble des processus” tandis que la seconde prétend que “distribué signifie que tout le traitement des transactions ne se fait pas au même endroit”. Dans le même temps, la réponse qui arrive en tête sur l’Ethereum Stack Exchange renvoie à un diagramme très similaire, mais les mots “décentralisé” et “distribué” ont échangé leurs places ! A l’évidence, une clarification est requise.

Les trois types de décentralisation

Lorsque les gens parlent de décentralisation d’un logiciel, ils évoquent en fait trois axes distincts de centralisation/décentralisation. Si dans certains cas il est difficile de voir comment vous pouvez avoir l’un sans l’autre, ils sont en général tout à fait indépendants les uns des autres. Ces axes sont les suivants :

  • (Dé)centralisation architecturale – de combien d’ordinateurs physiques un système est-il constitué ? Combien le système peut-il tolérer d’ordinateurs en panne à un moment donné ?
  • (Dé)centralisation politique – combien d’individus ou d’organisations ont l’ultime contrôle des ordinateurs qui composent le système ?
  • (Dé)centralisation logique – est-ce que l’interface et les structures de données que le système présente et maintient ressemble plus à un unique objet monolithique ou à un essaim sans forme ? Une heuristique simple est : si vous coupez le système en deux, en y incluant les fournisseurs et les utilisateurs, les deux parties continueront-elles à fonctionner pleinement en tant qu’entités indépendantes ?

Essayons de mettre ces trois dimensions dans un tableau :

 

Notez que beaucoup de ces placements sont grossiers et très discutables. Mais essayons de creuser chacun d’entre eux :

  • Les corporations traditionnelles sont politiquement centralisées (un PDG), centralisées sur le plan architectural (un siège social) et logiquement centralisées (on ne peut pas vraiment les couper en deux).
  • Le droit romano-civiliste repose sur un organe législatif centralisé, tandis que la common law[footnote]Système juridique issu du droit anglais dont les règles sont principalement édictées par les tribunaux au fur et à mesure des décisions individuelles. La jurisprudence est ainsi la principale source du droit et la règle du précédent oblige les juges à suivre les décisions prises antérieurement par les tribunaux.[/footnote] est bâtie sur une série de précédents établis par beaucoup de juges différents. Les droits de tradition civiliste ont encore une certaine décentralisation architecturale car il existe de nombreux tribunaux qui ont un large pouvoir discrétionnaire, mais la common law en a davantage. Les deux sont logiquement centralisés («la loi est la loi»).
  • Les langues sont logiquement décentralisées; l’anglais parlé entre Alice et Bob et l’anglais parlé entre Charlie et David n’ont pas besoin d’être similaires. Il n’y a pas d’infrastructure centralisée requise pour qu’une langue existe, et les règles de la grammaire anglaise ne sont pas créées ou contrôlées par une unique personne (tandis que l’Esperanto a été originellement inventé par Ludwig Zamenhof, mais il fonctionne maintenant comme une langue vivante qui évolue progressivement sans autorité)
  • BitTorrent est logiquement décentralisé de la même façon que l’anglais. Les réseaux de distribution de contenu sont similaires, mais sont contrôlés par une seule entreprise.
  • Les blockchains sont politiquement décentralisées (personne ne les contrôle) et décentralisées sur le plan architectural (pas de point unique de défaillance[footnote]Un point unique de défaillance (single point of failure ou SPOF en anglais) est un nœud d’un système informatique dont le reste du système est dépendant et dont une panne entraîne l’arrêt complet du système.[/footnote] dans l’infrastructure) mais elles sont logiquement centralisées (il y a un état commun et le système se comporte comme un seul ordinateur)

Très souvent lorsque les gens parlent des vertus de la blockchain, ils décrivent les avantages pratiques d’avoir une “base de données centrale”; il disent que la centralisation est une centralisation logique, et que c’est une forme de centralisation qui est bonne dans bien des cas (bien que Juan Benet, créateur de l’IPFS préconise la décentralisation logique chaque fois que possible carles systèmes logiquement décentralisés ont tendance à très bien survivre lors d’une partition du réseau, fonctionnent correctement dans des régions du monde qui ont une mauvaise connectivité, etc; voir aussi cet article de Scuttlebot préconisant explicitement la décentralisation logique).

La centralisation architecturale conduit souvent à la centralisation politique, quoique pas nécessairement – dans une démocratie formelle, les politiciens se rencontrent et votent dans une salle de gouvernance physique, mais ceux qui la tiennent ne finissent pas par obtenir un pouvoir important sur la prise de décision. Dans les systèmes informatisés, la décentralisation architecturale mais non politique peut se produire s’il existe une communauté en ligne qui utilise un forum centralisé pour sa commodité, mais où il y a un contrat social largement accepté. Si les propriétaires du forum agissent de manière malveillante, tout le monde passera à un autre forum (les communautés qui se sont formées par rébellion contre ce qu’elles perçoivent comme de la censure ont probablement mis cette propriété en pratique).

La centralisation logique rend la décentralisation architecturale plus difficile, mais pas impossible – regardez comment les réseaux de consensus décentralisés ont déjà fait leurs preuves, bien qu’ils soient plus difficiles à maintenir que BitTorrent. Et la centralisation logique rend la décentralisation politique plus difficile – dans les systèmes logiquement centralisés, il est plus difficile de résoudre la controverse en acceptant simplement de «vivre et laisser vivre».

Trois raisons à la décentralisation

La question suivante est : en premier lieu, pourquoi la décentralisation est-elle utile ? Il y a généralement plusieurs arguments soulevés :

  • Tolérance aux pannes – les systèmes décentralisés sont moins susceptibles d’échouer accidentellement parce qu’ils reposent sur de nombreuses composantes distinctes.
  • Résistance aux attaques – les systèmes décentralisés sont plus coûteux à attaquer et à détruire ou à manipuler. Ils ne possèdent pas de points uniques de défaillance, qui pourraient être attaqués pour un coût beaucoup plus faible que la taille économique du système environnant.
  • Résistance à la collusion – il est beaucoup plus difficile pour les participants dans les systèmes décentralisés de s’entendre pour agir de manière à en bénéficier au détriment des autres participants, alors que les dirigeants des sociétés et des gouvernements s’entendent pour défendre leur propre intérêt tout en nuisant aux citoyens moins bien coordonnés, aux employés et au grand public, et ce, en permanence.

Ces trois arguments sont importants et valables, mais tous aboutissent à des conclusions intéressantes et différentes dès que vous commencez à réfléchir aux décisions du protocole avec les trois perspectives distinctes à l’esprit. Essayons d’élargir chacun de ces arguments un par un.

. . .

En ce qui concerne la tolérance aux pannes, l’argument de base est simple. Qu’est-ce qui est le moins susceptible de se produire: un seul ordinateur défaillant, ou cinq ordinateurs sur dix tombant tous en panne en même temps? Le principe est incontestable, et est utilisé dans de nombreuses situations de la vie réelle, comprenant les moteurs à réaction, les générateurs de secours notamment dans des endroits comme les hôpitaux, l’infrastructure militaire, la diversification du portefeuille financier, et oui, les réseaux informatiques.

Cependant, ce type de décentralisation, bien qu’efficace et très important, se révèle souvent ne pas être la panacée telle qu’elle est décrite parfois par des modèles mathématique naïfs. La raison en est la défaillance de mode commun (common mode failure)[footnote]Défaillances de différentes parties d’un système – ces événements n’étant pas statistiquement indépendants – provoquées par une faute unique (les causes de ce type de défaillance comprennent, entre autres, les conditions environnementales, les défauts de conception, de fabrication et de construction, les erreurs humaines au niveau de l’exploitation et de l’entretien, les phénomènes naturels ou provoqués par l’homme)[/footnote]. Bien sûr, quatre moteurs à réaction sont moins susceptibles de tomber en panne qu’un seul moteur à réaction, mais que faire s’il ont tous les quatre été fabriqués dans la même usine, et qu’une faille a été introduite en chacun d’entre eux par le même employé scélérat ?

Est-ce que les blockchains telles qu’elles sont aujourd’hui arrivent à nous protéger d’une défaillance de mode commun ? Pas nécessairement. Considérons les scénarios suivants :

  • Tous les noeuds d’une blockchain exécutent le même logiciel client, et celui-ci présente un bug.
  • Tous les noeuds d’une blockchain exécutent le même logiciel client, et l’équipe de développeurs derrière le logiciel s’avère être socialement corrompue.
  • L’équipe de recherche qui propose les mises à jour du protocole s’avère être socialement corrompue.
  • Dans le cadre d’une blockchain basée sur la preuve de travail, 70% des mineurs sont dans le même pays et le gouvernement de ce pays décide de saisir tout le matériel de minage pour des raisons de sécurité nationale.
  • La majorité du matériel de minage est construit par la même entreprise, et cette société est soudoyée ou contrainte à mettre en œuvre une backdoor qui permet de rendre inopérant ce matériel à volonté.
  • Dans une blockchain basée sur la preuve d’enjeu (proof of stake[footnote]Preuve d’enjeu ou preuve de participation : cette méthode demande à l’utilisateur de prouver la possession d’une certaine quantité de cryptomonnaie (leur « participation ») pour prétendre à pouvoir valider des blocs supplémentaires dans la chaîne de blocs et de pouvoir toucher la récompense, s’il y en a une, à l’addition de ces blocs.[/footnote]), 70% des tokens en jeu sont possédés par une seule plateforme de change.

Une vision holistique de la décentralisation de la tolérance aux pannes examinerait tous ces aspects, et verrait comment ils peuvent être minimisés. Certaines conclusions naturelles qui s’imposent sont assez évidentes:

Notez que les exigences requises quant à la tolérance aux pannes sous sa forme naïve se focalise sur la décentralisation architecturale, mais dès que vous commencez à penser à la tolérance aux fautes de la communauté qui gouverne le développement du protocole, alors la décentralisation politique est également importante.

. . .

Maintenant, examinons la résistance aux attaques. Certains modèles économiques purs ont parfois pour résultat que la décentralisation n’a même pas d’importance. Si vous créez un protocole où les validateurs ont la garantie de perdre 50 millions en cas d’attaque de type 51% (i.e. réversion de finalité), alors cela n’a pas vraiment d’importance que les validateurs soient contrôlés par une ou 100 compagnies – 50 millions restent 50 millions. En fait, il y a de profondes raisons issues de la théorie des jeux selon lesquelles la centralisation peut même maximiser cette notion de sécurité économique (le modèle de sélection des transactions dans les blockchains existantes reflète cette vision, car l’inclusion des transactions en blocs via les mineurs est en fait une dictature tournante).

Cependant, une fois que vous adoptez un modèle économique plus riche, et en particulier un modèle qui admet la possibilité de coercition (ou de choses moindres comme les attaques DoS ciblées contre les nœuds), la décentralisation devient plus importante. Si vous menacez une personne de mort, soudainement les 50 millions de dollars n’auront plus autant d’importance à ses yeux. Mais si les 50 millions de dollars sont répartis entre dix personnes, alors il faut menacer dix fois plus de gens, et le faire en même temps. En général, le monde moderne est dans bien des cas caractérisé par une asymétrie attaque/défense en faveur de l’attaquant – un bâtiment qui coûte 10 millions de dollars à construire peut coûter moins de 100 000 $ à détruire, mais le rapport (coût de l’attaque/valeur du système visé) de l’attaquant est souvent sublinéaire : si un bâtiment coûtant 10 millions de dollars à construire nécessite un coût de 100 000 $ pour le détruire, un bâtiment qui coûte 1 million de dollars à construire peut coûter par exemple 30 000 $ à détruire.

Où mène ce raisonnement ? Premièrement, il nous pousse fortement en faveur de la proof of stake plutôt que de la proof of work, étant donné que le matériel informatique est facile à détecter, réguler, ou attaquer, tandis que les coins peuvent être cachés beaucoup plus facilement (la proof of stake est également une méthode fortement résistante aux attaques pour d’autres raisons). Deuxièmement, c’est un point en faveur du fait de disposer d’équipes de développement largement réparties, y compris géographiquement parlant. Troisièmement, cela implique que le modèle économique et le modèle de tolérance aux pannes doivent être examinés lors de la conception d’un protocole de consensus.

. . .

Enfin, nous pouvons aborder l’argument qui est peut-être le plus complexe des trois, la résistance à la collusion. La collusion est difficile à définir; peut-être que la seule façon vraiment valable de la définir est de dire simplement que la collusion est une «coordination que nous n’aimons pas». Il existe de nombreuses situations dans la vie réelle où même si une parfaite coordination entre tout le monde serait idéale, un sous-groupe étant en mesure de se coordonner tandis que les autres ne le peuvent pas est dangereux.

Un exemple simple est la loi antitrust – les barrières réglementaires mises en place afin de rendre plus difficile pour les participants d’une partie du marché de se rassembler et d’agir comme un monopole et d’obtenir des bénéfices extérieurs aux dépens de l’autre partie du marché et du bien-être social général. Un autre exemple est l’ensemble de règles contre la coordination active entre les candidats et les super-PACs[footnote]Comité d’action politique (en anglais, political action committee ou PAC) : nom communément utilisé pour désigner, indépendamment de sa taille, une organisation privée dont le but est d’aider ou au contraire de gêner des élus, ainsi que d’encourager ou de dissuader l’adoption de certaines lois.[/footnote] aux États-Unis, bien que celles-ci se soient avérées difficiles à appliquer dans la pratique. Un exemple moindre est la règle présente dans certains tournois d’échecs empêchant deux joueurs de jouer de nombreux jeux l’un contre l’autre afin d’essayer d’augmenter le score de l’un d’entre eux. Peu importe où vous regardez, les tentatives pour empêcher une coordination indésirable dans les institutions sophistiquées sont partout.

Dans le cas des protocoles blockchain, le raisonnement mathématique et économique derrière la sécurité du consensus repose souvent de façon cruciale sur le modèle du choix non coordonné, ou sur l’hypothèse selon laquelle le jeu se compose de nombreux petits acteurs qui prennent des décisions indépendamment.

Si un acteur obtient plus d’un tiers du pouvoir de minage dans un système basé sur la preuve de travail, il peut obtenir des bénéfices surévalués en faisant du minage égoïste (selfish mining)[footnote]Attaque sur l’intégrité du réseau Bitcoin : un mineur ou pool de minage choisit de ne pas publier et distribuer une solution valide au reste du réseau. Le mineur égoïste continue alors à miner le bloc suivant, puis les autres, maintenant ainsi son avance. Lorsque le reste du réseau est sur le point d’attraper le selfish miner, il ou ils injectent leur portion de blocs résolus dans le réseau. Leur chaîne étant alors la plus longue et la preuve de travail associée la plus difficile, le reste du réseau adopte leurs solutions et les mineurs réclament leur récompense.[/footnote].

Cependant, pouvons-nous vraiment dire que le modèle du choix non coordonné est réaliste lorsque des personnes possédant 90% de la puissance de minage du réseau Bitcoin sont suffisamment bien coordonnées pour se présenter ensemble à la même conférence?

 

Les défenseurs de la blockchain font également valoir qu’il est plus sûr de développer un service sur une blockchain parce qu’on ne peut pas changer ses règles de façon arbitraire sur un coup de tête quand on le veut, mais ce cas serait difficile à défendre si les développeurs du logiciel et du protocole travaillaient tous pour la même entreprise, faisaient partie de la même famille et étaient assis dans la même pièce. Le point principal est que ces systèmes ne devraient pas agir comme un agrégat de monopoles ne défendant que leur propre intérêt. Par conséquent, vous pouvez certainement soulever le fait que les blockchains seraient plus sûres si elles tendaient plus vers la “non coordination”.

Cependant, cette explication laisse persister un paradoxe fondamental. Beaucoup de communautés, y compris celle d’Ethereum, sont souvent vues positivement grâce à l’existence un esprit communautaire solide et sa faculté d’être en mesure de se coordonner rapidement pour la mise en œuvre et l’activation d’un hard fork, afin de résoudre  en six jours les problèmes de déni de service présents dans le protocole. Mais comment pouvons-nous favoriser et améliorer ce “bon” type de coordination, tout en empêchant la « mauvaise coordination » de mineurs tentant de tromper tout le monde en coordonnant à plusieurs reprises des attaques de type 51% ?

. . .

Il y a trois façons de répondre à cette question :

  • Ne vous embêtez pas à atténuer la coordination indésirable; essayez plutôt de construire des protocoles qui peuvent y résister.
  • Essayez de trouver un juste milieu qui permet une coordination suffisante afin que le protocole évolue, mais insuffisante pour mener des attaques.
  • Essayez de faire une distinction entre la coordination bénéfique et la coordination nuisible, rendez la première plus facile et la dernière plus difficile.

La première approche constitue une large part de la philosophie qui est derrière la conception de Casper[footnote]Protocole de consensus basé sur la preuve d’enjeu (proof of stake) pour le réseau Ethereum, contrairement à la méthode actuelle basée sur la preuve de travail (proof of work).[/footnote]. Cependant, elle est en elle-même insuffisante, car se fier à l’économie seule ne traite pas des deux autres préoccupations concernant la décentralisation. La seconde est difficile à concevoir techniquement, surtout au long terme, mais arrive souvent par hasard. Par exemple, le fait que les core developers de Bitcoin parlent généralement anglais, mais que les mineurs parlent généralement chinois, peut être considéré comme un heureux hasard, car il crée une sorte de gouvernance «bicamérale» qui rend la coordination plus difficile, avec le bénéfice de réduire le risque de common mode failure, car les communautés anglaise et chinoise raisonneront différemment en raison de la distance et des difficultés de communication et seront donc moins susceptibles de faire la même erreur.

La troisième est un défi social plus que toute autre chose; les solutions à cet égard peuvent comprendre :

  • Des interventions sociales, tentant d’accroître la loyauté des participants à la communauté autour de la blockchain dans son ensemble, substituant ou décourageant la collusion d’une partie des acteurs du marché.
  • La promotion de la communication entre les différents “camps du marché” dans le même contexte, afin de réduire la possibilité que les validateurs, développeurs ou mineurs commencent à se voir eux-mêmes comme une sorte de “classe” devant se coordonner pour défendre leurs intérêts contre les autres “classes”.
  • La conception du protocole de telle façon qu’il réduise l’incitation que pourraient avoir les validateurs/mineurs à s’engager dans des “relations spéciales” en tête-à-tête, des réseaux de relais centralisés et autres mécanismes de super-protocole.
  • Des normes claires au sujet des propriétés fondamentales que le protocole est supposé posséder, et le type d’actions qui ne devraient pas arriver, ou qui devraient au moins n’être exécutées qu’en cas de circonstances particulièrement extrêmes.

Ce troisième type de décentralisation, la décentralisation en tant que moyen d’éviter une coordination non-désirée, est donc peut-être la plus difficile à réaliser, et les compromis sont inévitables. La meilleure solution pourrait être de s’appuyer fortement sur le seul groupe dont la décentralisation est garantie : les utilisateurs du protocole.