Ethereum : la blockchain aux pieds d’argile ?

La décentralisation monopolistique – Cet article est le résultat de mon interrogation des derniers jours suite à la lecture de divers commentaires Reddit et Twitter concernant la difficulté pour un individu lambda de monter un noeud Ethereum complet, mais également et principalement d’un article principal de StopAndDecrypt reprenant un certain nombre de faiblesses supposées du réseau.

Je vais tâcher au cours de cet article d’être synthétique (au risque de faire des erreurs de simplification, merci de ne pas convulser et de ne pas me noyer sous les commentaires) ; même s’il faut noter que si ce qui est avancé est véridique, un problème massif me semble venir pour la chaîne Ethereum, ses dApps et son rêve de grand “ordinateur décentralisé”, comme j’en discuterai plus tard dans cet article.

Si vous cherchez le détail technique du pourquoi du comment, je vous invite à vous référer à l’article original de StopAndDecrypt, en anglais cependant. A noter que certains des points qu’il avance ont été contestés par Vitalik Buterin par la suite, là aussi en anglais ; et depuis que StopAndDecrypt a relevé d’autres points de tension, notamment concernant le sharding, et que les deux protagonistes débattent en continu à ce propos sur Twitter.

Au cours des 11 derniers mois, la blockchain Ethereum a quintuplé de volume, à tel point qu’un développeur de Parity, un des principaux logiciels clients d’Ethereum, a récemment tiré la sonnette d’alarme : le risque est grand de voir sous peu la quasi-totalité des nœuds complets (fully validating nodes, et non pas les archival nodes plus légers mais reposant sur les nœuds complets) validant et entretenant Ethereum être gérée par une unique entité lucrative, centralisée et collectant des données personnelles, Infura.

Résumons donc le problème

Une blockchain dite décentralisée est censée être :

• Distribuée entre différents acteurs la validant. Appelons-les grossièrement des nœuds, sans faire de distinction entre mineurs (qui ne seront plus un élément de l’équation en cas de passage d’une PoW à une PoS), nœuds complets de différents types, et nœuds légers (dits SPV par exemple pour Bitcoin, et notamment fast et light pour leurs deux déclinaisons d’Ethereum) ; et donc entre nœuds validant réellement la blockchain et nœuds constatant seulement l’état actuel de la blockchain à partir d’un point donné (pruning, pour résumer là aussi grossièrement),
• Non hiérarchique, avec une relation de pair-à-pair, et pas de maître-à-esclaves,
• Incitative économiquement, que ce soit en reposant sur un token valorisé tout comme en étant très peu coûteux à mettre en place et à entretenir (en temps et du point de vue financier) du point de vue de l’opérateur de nœud non mineur.

Le souci se pose quand une fonctionnalité incluse dans un système entraîne plus de risques de déstabilisation qu’autre chose, et il s’agit non plus d’un souci mais d’un problème réel quand la simple utilisation d’un système peut avec le temps le compromettre sévèrement.

La taille de la blockchain ETH n’est pas tant le problème

Malgré les dénégations de certains développeurs Ethereum (cet article pour exemple), il semblerait bien que la taille globale de la blockchain Ethereum ait récemment dépassé la taille de 1 To. L’augmentation semble potentiellement exponentielle, là où celle de la blockchain Bitcoin est linéaire, et il s’agit d’un premier souci potentiel.

Souci car à l’heure où nous parlons, le 1To serait dépassé, et en suivant une projection, il est probable de voir la nécessité en espace pour faire tourner un nœud complet ETH littéralement exploser. Mais en soi, ce n’est pas le problème principal qui nous intéresse dans cet article.

Le besoin constant en bande passante

Si la taille de la blockchain peut théoriquement être “absorbée” par les progrès à venir concernant les capacités et les coûts des supports de stockage (cf. la loi de Moore à ce propos), il n’en est pas de même à la fois pour la bande passante et la latence, qui n’obéissent pas exactement aux mêmes lois et progressent moins rapidement (cf. la loi de Nielsen pour la bande passante).

Pour être excessivement synthétique, le fait que les blocs ETH ne soient pas limités en taille d’une façon aussi abrupte que Bitcoin peut expliquer ce qui s’observe : les blocs ETH évoluent différemment (pour rappel, le bloc BTC est théoriquement limité à 1MB, même si l’implantation de Segwit a assoupli cette limite), et plus le réseau Ethereum est utilisé, plus ces blocs servent à inclure toutes les transactions, qu’elles soient à but monétaire ou bien qu’elles servent au fonctionnement des dApps basées sur la blockchain Ethereum. Notons tout de même une forme de “cap” mis en place à l’aide des frais en gas pour les transactions, gas dont le coût peut occasionnellement littéralement exploser en cas de congestion du réseau, entraînant avec lui une hausse notable des frais de transaction et donc d’utilisation des dApps. Ce n’est néanmoins pas forcément un problème spécifique à Ethereum (les frais de transaction de Bitcoin également ont connu des périodes grossièrement haussières), mais qui peut poser une difficulté d’ordre différent cependant, puisque ces surcoûts pourraient être limitants vis-à-vis de l’utilisation de dApps.

Ainsi, par le passé, l’utilisation massive de certaines dApps a déjà illustré de façon criante les risques pour le bon fonctionnement du réseau : citons pour mémoire les épisodes de surcharge du réseau s’étant observées par exemple avec les Crypto-Kitties, qui ont dans leurs moments de hype paralysé tout le reste des opérations s’appuyant sur la Blockchain Ethereum.

Donc, très sommairement, plus le réseau ETH est massivement sollicité, plus il demande de ressources massives à tout nœud réellement complet (fully-validating node) et ainsi il entraîne un mouvement de centralisation de ces noeuds, car à la différence de Bitcoin, il faut que l’infrastructure du noeud-même progresse de concert avec la sollicitation du réseau Ethereum pour qu’il puisse se synchroniser complètement et le rester ; de plus, plus il est sollicité, et moins la diversité de dApps est susceptible de continuer à tenir la charge, potentiellement jusqu’à arrêter de fonctionner.

Des nœuds plus tellement validants

https://twitter.com/StopAndDecrypt/status/991683846100963328

Un hiatus s’observe donc de plus en plus, concernant l’impossibilité pure et simple pour tout un chacun de pouvoir monter un nœud complet sur du matériel informatique classique d’abord, mais maintenant même sur du matériel haut-de-gamme, résultant en une limitation du nombre de nœuds complets en définitive et en une possible centralisation de ces nœuds. Dans ces cas de plus en plus nombreux, le nœud en cours de synchronisation n’arrive jamais à se synchroniser totalement, finissant par devenir un nœud fast recevant et transmettant seulement les en-têtes des blocs (headers), ce qui théoriquement n’est pas une véritable validation mais une simple propagation, reposant donc sur une confiance envers les validateurs complets résiduels, n’empêchant pas de propager des transactions fausses incluses dans un bloc par un attaquant malveillant, et ne validant pas à proprement parler la totalité de la blockchain.

Pour illustrer le problème technique rencontré, l’ordinateur lambda n’arrivera pas à la fois à recevoir et valider la blockchain Ethereum, du fait de ce qu’elle demande déjà en autres ressources réseau.

C’est une situation qui peut également s’observer sur Bitcoin, mais dans un cas précis : le montage d’un nœud complet sur un matériel informatique limité (type Raspberry Pi), sur lequel un opérateur essaierait de synchroniser et valider de zéro la blockchain. Sur un matériel limité, la synchronisation n’arrivera pas à se faire entièrement. Néanmoins, c’est un problème qui ne s’observe pas actuellement et à priori ne s’observera pas sur un ordinateur même basique ou ancien, même si la synchronisation initiale pourra être longue. Dans le pire des cas, restera la solution de télécharger la Blockchain Bitcoin en torrent pour lancer un nœud complet, même si cette solution est moins trustless.

Pour le nœud Ethereum, cette possibilité n’est pas disponible, et si le nœud en cours de synchronisation ne peut plus rattraper son retard, il abandonne la tentative de synchronisation complète pour devenir un simple nœud light (recevant les headers seulement pour remonter le retard).

Pour résumer

• De moins en moins de nœuds complets valident à l’heure actuelle la blockchain ETH dans son entièreté, et la tendance semble se poursuivre dangereusement.
• Il est théoriquement possible de monter un nœud complet Ethereum sur tout matériel informatique, mais dans la pratique les ressources demandées nécessitent déjà un matériel trop coûteux et spécifique pour qu’un opérateur lambda monte un nœud complet aussi facilement que sur Bitcoin, par exemple, c’est pourquoi la plupart des nœuds complets sont aujourd’hui gérés et entretenus par une seule entreprise privée, Infura, sur laquelle repose la grande majorité des dApps, et donc de facto le fonctionnement centralisé d’un réseau présenté pourtant comme décentralisé.
• Les dApps sont de plus susceptibles de ne plus pouvoir fonctionner lors de pics d’utilisation (par exemple observé avec la première vague de Crypto-Kitties), le réseau Ethereum étant alors totalement congestionné.

Visuellement, résumons l’état du processus de validation de la Blockchain Ethereum ainsi :

Néanmoins, le sharding (dont voici le détail technique traduit en français, selon Vitalik Buterin initialement) à venir sur la Blockchain Ethereum pour permettre un fonctionnement à une bien plus grande échelle (scaling) réorganiserait le réseau de la façon suivante :

Néanmoins, au vu des accrocs soulevés précédemment, il semble difficile de convenir que le sharding changerait forcément quelque chose aux problèmes exposés, à la fois concernant le besoin exponentiel en bande passante pour permettre le fonctionnement du réseau et par extension la centralisation des nœuds complets véritables, qui resteraient probablement à minima relativement centralisés. De plus, le système passant sur une forme de PoS, la centralisation serait possiblement accentuée, comme le souligne StopAndDecrypt : le montant nécessaire à verrouiller sur le réseau en tant que preuve d’enjeu pour pouvoir participer au sharding étant de 32 ETH ainsi que la nécessité pour chaque shard d’être connecté à un set d’autres nœuds validateurs complets posent le problème d’un nombre possiblement très réduit de participants “maîtres du réseau”. Vitalik estime à 400 individus potentiels le nombre de ces participants “privilégiés”.

Yes, 32 ETH is the staking minimum in the sharding proposal.

— vitalik.eth (@VitalikButerin) June 2, 2018

https://twitter.com/StopAndDecrypt/status/1002919384325787648

> Even with a hundred shards, how many validators per?

3125 slots. If we assume a Zipf's law distribution of people staking, that might represent ~400 unique individuals.

— vitalik.eth (@VitalikButerin) June 3, 2018

Hypothèses cependant

D’après StopAndDecrypt, voilà donc l’état et le tableau général de la Blockchain Ethereum. Il reste difficile de donner une réponse définitive, notamment en ce qui concerne principalement le véritable nombre de nœuds ou la taille globale de la blockchain Ethereum pour un fully-validating node, principalement parce que ces informations ne sont pas facilement disponibles : la seule estimation de la taille de la blockchain Ethereum disponible sur Etherscan ne concerne que les nœuds fast (pour rappel, autour de 80Go au maximum, mais ils ne sont pas concernés par cet article) alors que les données ne sont plus actualisées pour la taille de la blockchain en full node (ici), de plus le nombre de nœuds complets du réseau n’est plus disponible non plus sur Etherscan.

En conclusion

Si ces éléments sont véridiques (et le conditionnel est d’importance), les implications pour Ethereum peuvent être massives dans le futur : le réseau serait à l’antithèse d’un “ordinateur universel décentralisé”, il reposerait sur un opérateur plus ou moins monopolistique détenant des informations personnelles de façon assez littérale, les développeurs et les utilisateurs de dApps étant par la force des choses dans l’obligation de faire confiance à une entreprise extérieure pour leur fournir l’infrastructure nécessaire au bon fonctionnement d’Ethereum et par extension faire tourner les dApps potentielles. De plus, l’équilibre pourrait sembler passablement fragile, dans un futur relativement proche, avec Ethereum qui pourrait tout à fait continuer à fonctionner en l’état sans problème… jusqu’à ce que ce ne soit plus le cas brutalement (Oui, je vous entends crier au FUD, servez-vous un grand verre d’eau, respirez profondément, et gardez en tête que tout cela est du conditionnel à l’heure actuelle).

Soyons donc clair pour conclure : le but de cet article est bien non pas de lancer un FUD, mais d’exposer des éléments récents qui peuvent poser question concernant la Blockchain Ethereum.

Notamment, les plus vives interrogations concernent en résumé principalement une apparente augmentation de la difficulté pour tout volontaire de monter de zéro un nœud validateur complet sans pruning sur un poste informatique moyen, ayant pour conséquence une forme de centralisation d’un réseau se disant pourtant décentralisé (sous l’autorité indirecte d’Infura).

La future évolution vers le sharding et le passage en PoS nécessaire ne semble pas être un frein à cette tendance, au contraire un catalyseur potentiel, avec une centralisation possiblement augmentée du fait d’un effet de ploutocratisation de la validation des transactions. Parallèlement, les frais nécessaires à l’utilisation des dApps pourraient également poser problème dans le futur.

Le fait qu’Ethereum ne reste pas sur un modèle totalement décentralisé n’est pas forcément une erreur, mais il semblerait qu’en assumant pas assez son caractère centralisé, il ne fasse que s’encombrer de certaines des faiblesses et des mauvais côtés des deux approches de PoW et PoS.