L’ICO d’EOS a fait couler beaucoup d’encre : il s’agit du financement participatif le plus important de l’Histoire. Le lancement de la plateforme conçue par Dan Larimer, concurrente d’Ethereum, a eu lieu en juin 2018. Quel est le fonctionnement d’EOS ? Qu’est-ce que la preuve d’enjeu déléguée ? Quels sont les fondements de la bataille opposant Vitalik Buterin et Dan Larimer ? Plongée au cœur du projet le plus ambitieux jamais développé dans l’écosystème blockchain.
Sommaire :
Qu’est-ce que la preuve d’enjeu (proof of stake, PoS) ?
Naissance de la preuve d’enjeu déléguée (delegated proof of stake, DPoS)
Fonctionnement d’EOS et de la preuve d’enjeu déléguée
- Fonctionnement normal
- Fork minoritaire
- Double production par une minorité déconnectée
- Fragmentation du réseau
- Double production par une minorité connectée
- Finalité : dernier bloc irréversible
- Absence de quorum des producteurs de blocs
- Corruption de la majorité des producteurs de blocs
- Aléa de l’ordre de passage des producteurs
- Financement d’EOS et récompense
- Gouvernance et mise à jour du protocole EOS
- Performances d’EOS
Critiques de la preuve d’enjeu déléguée
- Un mécanisme de vote peu incitatif
- Le mythe de l’absence de frais pour l’utilisateur
- De la démocratie à la ploutocratie
- Trilemme des blockchains : le choix de la centralisation
Introduction
EOS est une plateforme blockchain ultrascalable qui permettra de déployer des smart contracts et des applications décentralisées, à l’instar d’Ethereum. Elle est développée par la firme Block.one, fondée par Daniel Larimer.
Actuellement, même si des applications décentralisées existent dans tous les domaines (places de marché, jeu en ligne, crypto-collectibles…), la plateforme EOS est utilisée principalement pour l’online gambling (paris et casinos en ligne) à l’instar des nombreux casinos en ligne acceptant BTC.
Le premier article de BitConseil consacré à cette entreprise exceptionnelle avait été publié au tout début de la vente de tokens, menée par rondes successives de 23 heures. À l’heure actuelle, les sommes investies font frémir : plus de 3,5 milliards de dollars, ce qui en fait la levée de fonds la plus élevée de l’histoire[1]. Cette somme peut sembler délirante à bien des égards, mais elle est à la hauteur de l’ambition de Dan Larimer : construire une plateforme décentralisée hautement scalable pouvant reléguer Ethereum au rang de jouet pour geeks adolescents. Ironie plaisante, c’est précisément à travers Ethereum que se déroule cette ICO.
Il est assez surprenant de voir de nombreux analystes du marché des ICOs placer Filecoin ou Tezos sur la première place du podium (en termes de fonds levés). En réalité, le record est établi par EOS, et de très loin. À la date d’écriture, plus de 5 millions d’ethers ont été récoltés. Chaque matin, en prenant son café, l’ami Dan compte les dizaines de milliers d’ethers apparus depuis la veille : ce système de vente à rondes multiples est intéressant, car il assure une distribution plus juste des tokens (les gros investisseurs n’ont pas d’avantages significatifs avec ce modèle, et les variables de détermination des prix sont beaucoup plus transparentes). De plus, l’investisseur peut trouver des opportunités d’arbitrage entre le prix des EOS achetés via l’ICO et le prix sur les marchés secondaires.
Pour de plus amples informations concernant l’ICO en elle-même (token design, structure et modalités de participation), voir l’article dédié par BitConseil.
Attention ! Il ne s’agit pas de conseils en investissement ! BitConseil recommande avant tout d’investir dans la connaissance, une préconisation qui n’a pas forcément été suivie par la horde de spéculateurs qui s’empresse de déverser des flots d’ethers vers l’adresse d’EOS… Rassurez-vous, après la lecture de cet article, vous serez éclairés sur le sujet !
Nous étudierons dans cet article les concepts de preuve d’enjeu (proof of stake – PoS), de preuve d’enjeu déléguée (delegated proof of stake – DPoS), ainsi que le débat passionnant autour de la scalabilité et de la gouvernance d’une blockchain, à travers le fameux projet EOS. Dan Larimer et Vitalik Buterin n’ont pas du tout la même approche du problème, et de longs échanges musclés ont déjà eu lieu entre les deux porteurs de projet.
Le trilemme des blockchains
Mis en lumière par Vitalik Buterin, le trilemme des blockchains stipule qu’un système blockchain ne peut assurer tout au plus que deux des trois propriétés suivantes :
- La décentralisation totale de la production des blocs ;
- La sécurité du réseau (sa résistance face aux attaques) ;
- La scalabilité du réseau (sa capacité à soutenir la montée en charge, liée au nombre de transactions que le réseau peut traiter dans un intervalle de temps donné).
De nombreuses pistes de solutions ont été proposées par les chercheurs pour s’approcher de l’idéal. Par exemple, la communauté Bitcoin cherche à résoudre ce problème en ajoutant des couches extra-protocolaires pouvant augmenter le nombre de transactions par seconde, sans pour autant sacrifier le niveau de sécurité ou de décentralisation du réseau (le Lightning Network). Sur Ethereum, le sharding (fragmentation de la blockchain) ou les solutions de couche secondaire comme Plasma tentent de contourner les limitations inhérentes au mécanisme de consensus utilisé.
Qu’est-ce que la preuve d’enjeu ?
La preuve d’enjeu (proof of stake, PoS) est un mécanisme de consensus où la production des blocs dépend de l’engagement économique des participants au réseau. Il s’agit de valider un bloc non pas en fonction de la quantité de ressources informatiques que sa production a nécessitée, mais en fonction des fonds – la quantité d’unités comptables propres à la blockchain considérée – que son producteur a mis en jeu. Ainsi, les producteurs de blocs mettent des fonds sous séquestre pour soumettre un bloc de transactions aux validateurs, qui vont à leur tour voter en engageant des fonds pour inclure le bloc ou non dans la chaîne.
Les participants sont légèrement récompensés pour cela, et sévèrement punis s’ils tentent de tricher.
À la différence des mineurs dans le cas de la preuve de travail, on appelle les producteurs de blocs des minters, du verbe to mint – battre monnaie – dans le cadre de la preuve d’enjeu.
La première monnaie numérique décentralisée à avoir implémenté le PoS est Peercoin, mais c’est Vitalik Buterin qui a amélioré et popularisé le concept. Vous trouverez son approche et ses explications dans cet article majeur. Pour des explications techniques plus poussées, en attendant un article dédié sur BitConseil, l’excellente Proof of Stake FAQ vous donnera beaucoup d’informations (en anglais).
Tentons de simplifier un peu les choses.
Dans la pratique :
- L’algorithme maintient à jour une liste de validateurs (aussi appelés les stakers, il s’agit des participants au réseau qui auront mis sous séquestre des fonds, via une transaction spéciale, pour pouvoir prétendre à ce rôle).
- L’algorithme définit de façon pseudo-aléatoire le staker qui aura le droit d’inscrire un bloc dans la blockchain, qui sera légèrement récompensé pour cela.
- Les validateurs votent alors pour inclure ce bloc dans la blockchain au prorata de leur stake, c’est-à-dire d’une quantité de coins qu’ils ont mis sous séquestre.
- En cas de mauvais comportement, les validateurs sont sévèrement punis : une partie de leur enjeu (stake) est brûlée[2].
Il y a bien sûr de nombreuses variantes aux modalités de l’algorithme de consensus en question, que nous pourrions explorer plus en détails, mais contentons-nous de cette présentation générale.
Quels sont les avantages de la preuve d’enjeu ?
L’avantage majeur est l’argument écologique – il n’y a pas besoin de dépenser de grandes quantités d’électricité pour sécuriser la blockchain – mais il n’est pas le seul :
- Étant donné cette consommation énergétique moindre, il n’y a pas besoin de récompenser fortement les participants au réseau par la création de nouveaux coins.
- Le PoS permet de trouver de meilleurs mécanismes que le PoW pour décourager la formation de cartels centralisés (regroupement d’acteurs souhaitant corrompre le réseau, ou lui nuire).
- Les risques de centralisation sont réduits, car les récompenses sont proportionnelles à la quantité d’avoirs mis sous séquestre : chaque acteur peut acheter le matériel nécessaire en fonction de son engagement[3].
- Les attaques de type 51 % sont beaucoup plus coûteuses à mener que dans le cas du PoW.
Ces points sont évidemment tous discutables, mais restons-en là pour le moment.
Le problème du “nothing at stake” :
Il s’agit du premier obstacle théorique à l’élaboration d’un mécanisme de preuve d’enjeu incorruptible.
Pour comprendre le problème du nothing at stake, il faut faire un peu de théorie des jeux. Ce problème se pose dans le cas où la blockchain se divise (fork) en deux branches. Quel choix maximisera alors les gains des validateurs ?
Dans le cas du minage par la preuve de travail, étant donné que c’est la chaîne qui présente la preuve de travail cumulée la plus élevée qui gagne, les mineurs ont intérêt à choisir la branche qui présente la plus forte probabilité de réussir. Si le mineur choisit les deux chaînes à la fois, il devra y répartir sa puissance de hachage, et son espérance de gain sera par conséquent moindre que s’il mine exclusivement la chaîne qui a le plus de chances de réussir.
Dans le cas de la preuve d’enjeu, les producteurs de blocs ont plutôt intérêt à engager leur stake (les fonds mis en jeu) sur les deux chaînes. Leur espérance de gain est alors supérieure à celle qu’ils obtiendraient en ne forgeant qu’une seule chaîne.
Pour pallier ce problème, il faut pénaliser les producteurs de blocs qui s’engagent sur plus d’une chaîne à la fois. On appelle cette méthode le slashing :
On peut également pénaliser les producteurs de blocs qui tentent de forger la “mauvaise” chaîne (celle qui est minoritaire) :
Vitalik Buterin a formalisé la première version de son système de proof of stake, Casper, dénommé The Friendly Finality Gadget (Casper FFG pour les intimes). Il s’agit en fait d’un hybride entre preuve de travail et preuve d’enjeu; ce mécanisme de consensus permettra de faire la transition en douceur entre les deux méthodes. Les blocs sont tout d’abord produits via la preuve de travail, puis le réseau les valide via la preuve d’enjeu. Prévue dans le Yellow Paper d’Ethereum, cette modification du protocole est définie dans l’EIP 1011, et ne nécessite pas de changement majeur pour être implémentée.
Vlad Zamfir, quant à lui, a poussé ses recherches pour proposer la version définitive de Casper, qui permettra à Ethereum de passer entièrement à la preuve d’enjeu. Pour cela, il a formalisé un protocole de consensus dit “correct par conception”, c’est-à-dire que le modèle mathématique utilisé pour construire le protocole entraîne bien les propriétés désirées une fois mis en pratique, sans imprévu (tout du moins, souhaitons-le). Pour cela, il faut tester tous les cas limites et les attaques qui pourraient éprouver le système.
La version de Vlad Zamfir est dénommée Casper the Friendly GHOST: Correct by Construction (CBC). Outre la référence au gentil fantôme, GHOST signifie Greediest Heaviest Observed Sub-Tree (sous-arbre le plus lourd et le plus avare observé), ce qui signifie que ce protocole permet de choisir entre les différents forks de la blockchain, selon des règles qui assurent les propriétés désirées (notamment l’impossibilité d’effectuer des doubles dépenses et des attaques).
Nous étudierons plus en détails le cas d’Ethereum et de Casper dans un article à part entière.
Naissance de la preuve d’enjeu déléguée
Ce mécanisme de consensus – delegated proof of stake (preuve d’enjeu déléguée, DPoS) – a été imaginé par Dan Larimer en 2013, pour répondre au trilemme des blockchains.
Dan Larimer est un pionnier du crypto-univers, l’un des premiers développeurs à avoir soulevé les problèmes et les limitations de la preuve de travail, des remarques qu’il a adressées à Satoshi Nakamoto lui-même. Dans le cas d’un réseau de paiement numérique pair-à-pair tel que Bitcoin, les propriétés de résistance à la censure et la sécurité du protocole sont cruciales, et passent avant la scalabilité. Par contre, dans le cas d’une blockchain servant à déployer des applications décentralisées, qui doivent effectuer une grande quantité de transactions en un minimum de temps, il est indispensable de trouver un moyen pour que le réseau puisse s’adapter à une montée en charge toujours plus importante. Le pari de Dan Larimer est de rendre la scalabilité inhérente au protocole, par conception.
La preuve d’enjeu, sous sa forme initiale – permettre à tous les participants au réseau de devenir validateurs des transactions – ne plaisait guère à Dan Larimer :
- Haute probabilité que les validateurs ne soient pas en ligne ;
- Sans surveillance des pairs, le pouvoir de nuisance d’un attaquant est proportionnel à ses fonds ;
- Sans processus de minage, générer un nombre aléatoire afin de sélectionner le validateur d’un bloc est impossible (un attaquant pourrait contrôler la génération aléatoire).
- Et surtout, confier tout le pouvoir au seul code informatique (code is law) rend le réseau tout entier très résistant face à la corruption, mais fragile face à l’erreur.
L’idée du DPoS est de confier la validation des blocs à un groupe restreint d’entités, les délégués (appelés aussi témoins), qui sont élus par les détenteurs du token natif de la blockchain. Ainsi, contrairement à la preuve d’enjeu classique, où tout possesseur de coins peut devenir validateur-producteur de bloc, et être récompensé au prorata de ses avoirs mis sous séquestre, la preuve d’enjeu déléguée est un mécanisme de consensus reposant sur le vote démocratique des détenteurs du token. Ces derniers élisent des nœuds au pouvoir suprême : celui de valider et d’inscrire des blocs sur la chaîne.
La première mise en œuvre de ce système fut pour le réseau BitShares; une autre version est employée pour la blockchain de Steemit, la plateforme décentralisée de publication en ligne[4].
Il y a bien sûr de nombreuses critiques qui pourraient être adressées aux systèmes démocratiques, mais bien évidemment, dans le cadre du DPoS, le postulat de départ est qu’il s’agit du processus de gouvernance le plus efficace et le plus juste existant à ce jour. De plus, grâce à la blockchain, ce processus de vote démocratique, liquide et représentatif, est complètement transparent.
Fonctionnement d’EOS et de la preuve d’enjeu déléguée
Le nombre de délégués requis pour assurer la validation des blocs varie suivant les réseaux (21 pour EOS), mais le mécanisme assurant leur élection est toujours le même. Nous nous baserons ici sur le modèle le plus récent, celui d’EOS.
Les détenteurs de tokens élisent leurs délégués en votant via une transaction spéciale. Ce vote est pondéré au prorata de la quantité de tokens qu’ils consacrent à cet effet. Dans le cas d’EOS, un token donne droit à trente votes différents[5]. On peut également donner ses droits de vote à un autre participant. Bien entendu, il est possible de se rétracter, par exemple dans le cas où un délégué agit de façon contraire à l’intérêt général.
Les producteurs de blocs potentiels soumettent leur candidature. Ils doivent bien sûr prouver que leur matériel est suffisamment robuste pour assurer un fonctionnement continu, et que leur engagement envers l’écosystème est maximal. Les candidatures sont libres et chacun peut proposer la sienne ici. La liste des candidats pour EOS est régulièrement mise à jour.
Les détenteurs de tokens votent alors pour leurs délégués favoris selon les modalités suivantes :
- Les tokens servant à voter sont mis sous séquestre pour une durée minimale de trois jours.
- Chaque token mis sous séquestre donne accès à 30 droits de vote. Il n’est pas possible de voter deux fois pour le même délégué avec le même token.
- À chaque ronde de production de blocs, les participants peuvent voter à nouveau pour les délégués de leur choix. Les votes sont reconductibles tant que les tokens des votants sont sous séquestre.
Le nombre de candidatures pour devenir délégué est illimité, mais seuls les 121 premiers délégués toucheront une récompense pour leur rôle.
Les 21 délégués ayant reçu le plus de votes de la part de la communauté ont alors le droit d’inscrire des blocs sur la chaîne. Si un des délégués est éjecté de la liste pour mauvais comportement, ou qu’il est hors ligne pendant une certaine durée, alors le délégué potentiel placé le plus haut dans la liste prend sa place.
Une fois que le réseau a déterminé qui sont les producteurs de blocs, la ronde de production se déroule ainsi :
- L’algorithme va sélectionner de manière aléatoire la séquence des producteurs de blocs à venir. Ceux-ci ont trois secondes pour produire leur bloc.
- Produire un bloc consiste à réunir les transactions des utilisateurs et signer ce bloc (avec la clef privée du délégué – producteur).
- Une fois le bloc produit, il est soumis à la validation des autres délégués. Ces derniers doivent l’approuver : les deux-tiers des délégués plus un doivent approuver un bloc pour qu’il soit valide et inscrit sur la chaîne.
Si un des délégués produit un bloc hors de l’intervalle temporel pour lequel il est désigné, ce bloc est invalide.
Dans le cas d’un fork de la blockchain, à l’instar de la preuve de travail, c’est la chaîne la plus longue qui sera considérée comme valide par l’ensemble du réseau.
Qui est le plus légitime pour expliquer de façon concise un mécanisme complexe ? Son créateur lui-même, bien sûr ! Je reprendrai donc ici l’article de Dan Larimer “DPOS Consensus Algorithm – The Missing White Paper“, qui est certainement le plus clair disponible sur la toile. Si le lecteur s’intéresse au personnage, il trouvera au gré de sa prose prolifique moult idées intéressantes et brillamment écrites, à condition qu’il ne soit pas allergique à la langue de Shakespeare, bien sûr.
Pour cette illustration, le nombre de producteurs de blocs est réduit à trois : les producteurs A, B et C. Chaque bloc sera donc produit de manière aléatoire par A, B ou C, et validé par l’ensemble des trois délégués (c’est une simplification, en réalité les délégués sont au nombre de 21 et les blocs doivent être approuvés par les deux-tiers des délégués plus un). Ici, c’est le producteur C qui départage les cas limites.
Il faut noter que le problème sus-cité du nothing at stake ne se pose pas dans le cas du DPoS : les détenteurs de tokens votent pour des validateurs, et non pour des blocs. Le nombre de validateurs est fixe et l’ordre selon lequel ils produisent des blocs est également défini par le protocole : il est impossible pour une minorité d’entre eux de créer un fork qui pourrait prendre le dessus sur la chaîne “honnête”.
Fonctionnement normal :
Lorsque le réseau opère normalement, l’algorithme assigne un intervalle temporel de trois secondes à chaque producteur de bloc, durant lequel il peut créer un bloc et le soumettre aux autre validateurs. Tout bloc soumis aux validateurs hors de l’intervalle temporel assigné à son producteur sera rejeté. Si aucun producteur ne rate son tour, ce sera toujours la chaîne la plus longue qui sera produite ainsi.
Fork minoritaire :
Dans le cas où une partie minoritaire des acteurs – jusqu’à 1/3 des producteurs de blocs – produit une chaîne de blocs différente (comportement malicieux ou dysfonctionnement technique), le temps passé à produire ces blocs sera toujours plus élevé que le temps que passera le reste des participants à construire la chaîne majoritaire (1 bloc toutes les 9 secondes dans cet exemple, contre 2 blocs toutes les 9 secondes pour la chaîne “honnête”). Ce sera donc toujours la chaîne “honnête” qui sera la plus longue, et le reste du réseau considérera donc cette dernière comme valide.
Double production par une minorité déconnectée :
Ici encore, si une minorité produit plusieurs forks, le temps passé à créer ces blocs sera toujours supérieur à celui qui est requis pour que la majorité des producteurs construise une chaîne valide. Ces forks seront donc toujours invalides.
Fragmentation du réseau
En cas de mauvaise connectivité entre les producteurs, il est possible de se retrouver avec plusieurs chaînes.
Si aucune d’entre elles n’a la majorité des votes des producteurs, c’est la chaîne minoritaire la plus longue qui prend le dessus.
Si deux chaînes majoritaires sont de longueur équivalente, lors de la reconnexion, les producteurs ayant forgé une chaîne minoritaire choisiront de rejoindre l’une des chaînes majoritaires, et seule l’une d’entre elle prendra alors le dessus.
Double production par une minorité connectée
Dans ce cas de figure, une minorité de producteurs décide de produire plusieurs blocs dans le même intervalle temporel. Lors de la prochaine ronde, le producteur suivant devra alors choisir n’importe laquelle des chaînes alternatives proposées, en faisant alors la chaîne la plus longue. Le reste des nœuds choisira donc cette dernière : cela permet de s’assurer que, quel que soit le nombre de blocs “alternatifs” produits par la minorité malicieuse, ils ne feront partie de la plus longue chaîne que durant un unique intervalle temporel.
Finalité : dernier bloc irréversible
La notion de finalité est propre à la preuve d’enjeu – il s’agit du point à partir duquel un bloc est considéré comme irréversible, immuable, par le logiciel client. Dans le cas de la preuve de travail, cette notion de finalité n’existe pas : un bloc est valide dès que le consensus des nœuds du réseau a permis son inscription sur la blockchain. Les confirmations supplémentaires viendront assurer que le risque de fork devient négligeable.
Dans certains cas de fragmentation prolongée du réseau, plusieurs chaînes pourraient continuer à se développer. Comme vu précédemment, ce sera toujours la chaîne la plus longue qui gagnera; mais il faut un moyen pour que les observateurs (les nœuds relayant les transactions) puissent déterminer avec certitude le point où un bloc est finalisé. C’est ici que la confirmation des deux tiers des validateurs plus un est requise : une fois que le vote est effectué, on peut être assuré qu’aucune chaîne alternative ne pourra être plus longue que la chaîne choisie par les producteurs de blocs (dans la mesure, bien sûr, ou au moins 2/3 des participants sont honnêtes). Cela se rapproche de la règle des 6 confirmations sur le réseau Bitcoin, à partir de laquelle on considère que la probabilité qu’un fork concurrent à la blockchain soit soumis au réseau devient totalement négligeable. Le cas extrême où, par collusion très bien coordonnée des attaquants, deux blocs irréversibles différents pourraient coexister – il faudrait pour cela un contrôle total des communications entre les producteurs – peut être, à terme, mitigé par la règle de la chaîne la plus longue. Dan Larimer considère cette attaque comme hautement improbable et ses conséquences économiques seraient insignifiantes.
Absence de quorum des producteurs de blocs
Dans le cas improbable où il n’y a pas de consensus des producteurs, une chaîne minoritaire peut survivre. Ce sont alors les détenteurs de tokens qui voteront pour sélectionner un nouvel ensemble de producteurs, restaurant ainsi le taux de participation maximal. Il est alors possible que ce soit la chaîne minoritaire qui se retrouve alors avec 100% de participation, devenant ainsi la seule chaîne valide. Dans ce cas, les observateurs du réseau devront garder à l’esprit qu’il existe une petite probabilité que le consensus valide une chaîne minoritaire à l’instant t. C’est équivalent au fait de considérer comme valide une transaction présentant moins de trois confirmations sur le réseau Bitcoin.
Corruption de la majorité des producteurs de blocs
Dans le cas où plus des deux tiers des producteurs de blocs seraient corrompus, ces derniers pourraient alors faire coexister plusieurs forks, présentant des blocs ayant des confirmations identiques. Ce sera alors à la minorité de faire pencher la balance d’un côté. Les détenteurs de tokens voteront pour éliminer ces producteurs corrompus.
Aléa de l’ordre de passage des producteurs et transaction comme preuve d’enjeu
En pratique, le mécanisme de sélection qui détermine “l’ordre de passage” des producteurs de blocs est aléatoire. Cet “ordre de passage” change tous les N blocs, où N est le nombre de producteurs de blocs.
Il faut également ajouter que chaque fois qu’une transaction est signée, puis diffusée sur le réseau, elle présente un hash faisant référence à un bloc précédent. Si ce bloc est inexistant sur la chaîne la plus longue (par exemple dans le cas où l’utilisateur signant sa transaction a choisi un état de la blockchain qui a depuis lors été invalidé par le consensus), cette transaction sera rejetée.
Cela signifie, indirectement, que chaque utilisateur confirme l’état de la blockchain comme valide à chaque transaction (via une preuve de Merkel, contrairement aux allégations de Vitalik).
Financement de la blockchain et récompense :
Comme la majorité des blockchains ouvertes, les producteurs de blocs et les validateurs sont récompensés à travers l’inflation. Sur EOS :
- Le taux d’émission monétaire est plafonné à 5 % par an. Il peut être modifié (à la baisse seulement), comme c’est le cas sur Steemit.
- Sur ces 5 %, un cinquième des fonds est alloué aux producteurs de blocs.
- Sur ce cinquième, le quart revient aux 21 délégués, et les trois quarts restants vont aux délégués en stand-by qui génèrent plus de 100 EOS par jour.
- Les producteurs de blocs sont rémunérés au prorata de leur capital mis en jeu.
- La partie restante des 5 % d’inflation sera allouée aux développements futurs d’EOS, qui seront approuvés par le vote des délégués, à la façon de la gouvernance de Dash.
L’idée est de financer à la fois les 21 producteurs de blocs actifs, mais aussi ceux qui sont sur la liste d’attente, de façon à pouvoir couvrir les frais de maintenance d’une infrastructure connectée en permanence au réseau.
Gouvernance et mise à jour du protocole EOS
La gouvernance d’EOS repose sur les délégués élus par les détenteurs du token. La mise à jour du protocole est effectuée selon les modalités suivantes :
- Un changement est proposé par un producteur de bloc. Il doit recueillir l’approbation de 17 délégués sur 21.
- L’approbation de 17 délégués sur 21 doit être maintenue durant 30 jours.
- Les producteurs de blocs doivent alors adopter les changements du code source et soumettre ce dernier sur la blockchain.
- Le changement doit encore être approuvé par au moins 17 délégués sur 21 durant 30 jours consécutifs de plus.
- Tous les nœuds complets ont alors une semaine pour adopter les changements.
- À la fin de ce délai, les nœuds qui ne suivent pas le nouveau protocole sont automatiquement exclus.
Performances
L’idée d’EOS et de son DPoS est donc de minimiser le nombre de producteurs de blocs, afin d’assurer une propagation très rapide de l’information. Avec seulement 21 délégués, les performances avancées par l’équipe de Block.one sont extrêmement impressionnantes :
- Absence de frais de transaction ;
- Délai inter-blocs de 3 secondes ;
- Débit allant jusqu’à plusieurs centaines de milliers de transactions par seconde ;
- Possibilité de mettre à jour les applications décentralisées déployées sur EOS très facilement ;
- Possibilité de réparer les bugs ou de retrouver l’accès perdu à un compte ;
- Parallélisation des tâches ;
- Gouvernance flexible, transparente et démocratique.
Critiques de la preuve d’enjeu déléguée
Bien entendu, aucun système de consensus n’étant parfait, de nombreuses critiques ont été émises à l’égard du delegated proof-of-stake de Dan Larimer, notamment par Vitalik Buterin lui-même. Je m’attacherai ici à énoncer les principales.
Un mécanisme de vote peu incitatif
Pour assurer la sécurité du système et prévenir la collusion, le système se base sur le vote, et non sur la validation du registre par la totalité des nœuds du réseau. Or, cela pose certains problèmes :
- Faible participation des votants (inférieure à 10 % pour la plupart des communautés blockchain ayant tenté l’expérience).
- Les votants ayant individuellement très peu d’influence sur le résultat du vote, l’incitation à voter “correctement” est très faible. Les détenteurs de tokens délégueront probablement leurs droits de vote aux plateformes de change qui hébergent leurs coins, sans trop s’en soucier.
- Les intérêts des gros détenteurs de coins ne sont pas vraiment alignés avec ceux des utilisateurs du réseau (les whales ont plus d’intérêt à voter pour des propositions qui maximisent la valeur du coin et non l’efficience du réseau).
Selon Vitalik, le protocole DPoS manque également d’incitations économiques empêchant les délégués de mal se comporter.
Le mythe de l’absence de frais pour l’utilisateur
Effectivement, EOS ne nécessitera pas de frais pour que l’utilisateur final puisse effectuer des transactions. Cependant, les frais existent, et sont déguisés sous forme d’inflation. Les 5% d’inflation annuelle (servant à récompenser les délégués pour leur travail, et donc à les inciter économiquement à sécuriser la blockchain), peuvent être considérés comme des frais cachés.
De plus, il y a un mécanisme subtil (non cité plus haut pour ne pas trop compliquer les choses), qui restreint le nombre de transactions qu’un utilisateur peut soumettre au réseau. Pour chaque période, l’utilisateur détenant N coins pourra soumettre un maximum de N * k transactions.
- C’est problématique pour les “pauvres”, ainsi que pour l’utilisateur qui ne compte se servir d’EOS que de manière occasionnelle (il devra à chaque fois acheter puis revendre des coins).
- Cela oblige les utilisateurs qui ne connaissent que très rarement des pics de demande à posséder en permanence suffisamment de coins pour couvrir ces cas très rares.
De la démocratie à la ploutocratie
Contrairement à une démocratie représentative typique, ou chaque individu possède un vote unique, la gouvernance d’une blockchain reposant sur le vote de ses participants via leur stake (leurs avoirs mis en jeu) se base sur l’idée 1 token = 1 vote.
Ainsi, il est possible pour une même personne de voter proportionnellement à la quantité d’avoirs qu’elle possède, ce qui mène irrémédiablement à la ploutocratie :
- Les plus riches auront plus de poids que les pauvres ;
- Si une minorité de possédants (les fameuses “baleines”) se retrouvent avec une très grande proportion de la provision totale de tokens en circulation, la gouvernance devient alors très centralisée.
Une autre critique peut être adressée à cette forme de gouvernance qui se veut démocratique : les détenteurs de tokens ne sont pas forcément les plus avisés pour décider des orientations que doit prendre le protocole. Ces derniers n’ont pas forcément les connaissances techniques leur permettant de faire des choix avisés quant aux évolutions qui bénéficieraient à la communauté dans son ensemble.
La gouvernance d’Ethereum est ainsi “dirigée” par le “dictateur bénévole” Vitalik, assisté par les éditeurs (les développeurs qui peuvent prendre la décision d’inclure ou non un EIP – une proposition d’amélioration du protocole Ethereum). Si les membres de la communauté Ethereum et Vitalik Buterin sont très critiqués quant à ce mode de fonctionnement, il faut reconnaître que cela s’est avéré être un modèle assez flexible, ayant permis de résoudre de nombreux problèmes, notamment en prenant des décisions rapides dans le cas de failles de sécurité cruciales.
Selon Vitalik Buterin, placer trop de confiance dans le consensus social, sans incitations économiques fortes à prendre des décisions avisées qui favorisent l’intérêt général, est plutôt dangereux. Le principe même de la crypto-économie repose sur ces incentives, qui rendent le système beaucoup plus sûr en l’administrant de cette façon plutôt qu’en se reposant sur le vote de la majorité. Les postulats sociaux sont variables selon les cultures et le nombre de participants au système, tandis que les mécanismes crypto-économiques permettent de quantifier les coûts d’une attaque et de punir immédiatement les mauvais comportements.
On pourrait résumer cela ainsi : dans les mécanismes de consensus tels que la preuve de travail et la preuve d’enjeu, ce sont les règles du protocole qui vont déterminer la récompense qu’obtiendront les participants, proportionnellement à leur performance. Dans le cadre du DPoS, la récompense est fixe, cela incite donc les participants à choisir le producteur de blocs leur donnant la plus grande part de cette récompense, indépendamment de leur performance.
Nous en arrivons donc à un des plus gros défauts du DPoS : l’attaque de corruption. Il s’agit de récompenser les votants financièrement pour leur vote : un producteur de blocs peut octroyer une partie de la récompense acquise par son travail de production et de validation à ceux qui votent pour lui.
Trilemme des blockchains : le choix de la centralisation
Pour en revenir à notre fameux trilemme des blockchains, le DPoS favorise la scalabilité de la blockchain au détriment de la décentralisation des producteurs de blocs. Or, la propriété la plus importante qu’assure la décentralisation d’un protocole de consensus est la résistance à la censure. Cette propriété fondamentale des blockchains est mise à mal par la centralisation des producteurs de blocs, qui pourraient décider, par exemple, de ne pas inclure certaines transactions, d’autant plus qu’il sera possible d’identifier de nombreux utilisateurs avec le système de comptes utilisateurs d’EOS. Par définition, cette propriété de résistance à la censure est assez binaire : si un protocole de consensus distribué ne peut pas garantir de résistance à la censure, alors ce protocole est centralisé.
Cette critique concernant la centralisation est tout à fait recevable, mais il faut noter que répartir la production de blocs entre 21 entités n’est pas forcément moins centralisé que de répartir la puissance de hachage d’un réseau, fonctionnant via la preuve de travail, entre quelques grosses pools de minage :
Comparaison de la centralisation de la production de blocs entre différents réseaux, par Senzheng.
Conclusion
Les débats autour de la fiabilité des différents mécanismes de consensus basés sur la preuve d’enjeu, et notamment la bataille entre le proof-of-stake de Vitalik Buterin et le delegated proof-of-stake de Dan Larimer, cristallisent les neurones des plus brillants cerveaux de l’écosystème crypto-économique, et n’ont pas fini de durer. L’idée de cet article n’est pas de prendre parti, mais de décortiquer le fonctionnement de ce mécanisme de consensus prétendument supérieur à la preuve de travail, et d’exposer les différents arguments des uns et des autres.
Il faut noter que le DPoS a été testé et approuvé grâce au premier projet blockchain de Dan, BitShares, durant plusieurs années : il s’agit toujours d’une des blockchains les plus rapides au monde. Quant à Steemit, il s’agit de la blockchain traitant le plus de transactions quotidiennement, toutes cryptomonnaies confondues. On peut donc dire que le DPoS fonctionne plutôt bien en termes de performances techniques.
C’est fort de cette expérience que le brillant développeur a conçu le modèle propre à EOS. Il s’agit d’une solution extrêmement intéressante et performante pour améliorer la scalabilité d’une blockchain. Il ne fait nul doute qu’EOS aura une place très importante dans l’univers des plateformes d’applications décentralisées, et cette architecture élégante pourrait bien faire de l’ombre aux plateformes existantes. De plus, les fonds récoltés par Block.one pour assurer son développement sont très importants. De nombreux projets dédiés pourront être financés, et leur déploiement sera rapide. La centralisation du registre distribué est un compromis qui fait grincer des dents les puristes de la crypto-anarchie, mais les propriétés d’EOS en feront certainement une plateforme incontournable pour le déploiement d’applications industrielles.
Seule l’expérience confirmera ou infirmera la valeur de ces nouveaux systèmes complexes, et si le comportement des humains est imprévisible, celui des algorithmes l’est également, malgré tous les efforts déployés pour vérifier de façon formelle les multiples possibilités induites par ces modèles mathématiques et sociaux. Il n’y a rien de plus excitant que les expérimentations technologiques et sociales autour de ces mécanismes de consensus et de gouvernance inédits !
En scannant un QR code avec votre smartphone, jouez instantanément à un revival de Space Invaders, sur la blockchain d'EOS, grâce à EOS Authority (candidat au cercle des 21) - sans KYC, et en un clic, comme pour l'ICO :).
Ressources :
Whitepapers et code source :
- Le whitepaper de BitShares
- Le whitepaper de Steem
- Le whitepaper d’EOS
- Le code source d’EOS, la documentation, les librairies…
Les blogs et comptes personnels de réseaux sociaux de Dan Larimer :
EOS et BlockOne :
Le débat Vitalik/Dan
- Round 1 : Vitalik 1 – Dan 0
- Round 2 : Vitalik 1 – Dan 1
- Round 3 : Vitalik 2 – Dan 1
- Round 4 : Vitalik 2 – Dan 2
Crédits illustrations : Image d'en-tête : Swann - Schémas DPoS : Dan Larimer - autres illustrations : EOS, BitShares, Shutterstock, BitConseil
Commentaires