Le trilemme de la blockchain : ce qui limite le développement des réseaux cryptographiques

Pendant longtemps, le trilemme de la blockchain a servi d'explication pratique à la quasi-totalité des limites des réseaux cryptographiques. Il décrit une réalité simple mais inconfortable : une blockchain ne peut pas être à la fois décentralisée, sécurisée et évolutive. C'est du moins l'hypothèse qui a prévalu tout au long de la première décennie d'existence des crypto-monnaies.

Cette formule est devenue un cadre utile pour expliquer presque tous les problèmes du secteur. Si un réseau est lent, c'est le prix de la décentralisation. S'il est rapide, c'est qu'il doit y avoir un compromis quelque part au niveau de la sécurité ou du contrôle. Et lorsque quelqu'un a promis les trois à la fois, cela s'est généralement soldé soit par une centralisation, soit par des défaillances du réseau.

Le trilemme en pratique

Le bitcoin est un exemple classique de la façon dont le trilemme se manifeste dans la vie réelle. Son architecture est principalement conçue autour de la sécurité et de la décentralisation. N'importe qui peut gérer un nœud, les règles sont simples et immuables, et l'historique des transactions est pratiquement impossible à réécrire. Le coût de ce choix de conception est l'évolutivité. Un faible débit et des frais élevés pendant les périodes de congestion ne sont pas des bogues, mais des conséquences.

Ethereum a suivi une voie similaire. Dans ses premières années, il a aussi délibérément sacrifié l'évolutivité au profit de la décentralisation et de la sécurité. Cela est apparu clairement lors de chaque cycle d'engouement, des ICO aux NFT, lorsque le réseau s'étouffait tout simplement sous la demande. C'est à ce moment-là que l'idée qu'Ethereum "n'est pas évolutif" s'est imposée, même si, en réalité, il n'essayait pas de tout résoudre à un seul niveau.

Solana, en revanche, est souvent cité comme un exemple de changement d'équilibre en faveur de l'évolutivité. Un débit élevé et des frais peu élevés l'ont rendu attrayant pour les utilisateurs et les développeurs. Toutefois, ces avantages sont assortis d'exigences élevées en matière de matériel pour les nœuds et d'une architecture plus complexe, ce qui entraîne régulièrement des pannes et soulève des questions quant au véritable niveau de décentralisation du réseau.

Aucun de ces exemples n'est bon ou mauvais. Ils illustrent simplement la manière dont le trilemme oblige les projets à faire des compromis.

Pourquoi le trilemme est-il resté sans solution pendant des années ?

La principale raison est que le trilemme n'a jamais été un problème technique au sens traditionnel du terme. Il ne s'agit pas d'un bogue ou d'un manque d'optimisation. Il s'agit d'une conséquence de la tentative de combiner trop de fonctions au sein d'une seule couche de blockchain : consensus, exécution des transactions, stockage des données et sécurité.

Toute tentative d'accélérer le réseau à ce niveau a inévitablement conduit soit à une réduction du nombre de participants indépendants, soit à une augmentation des risques. Par conséquent, la plupart des promesses de "résolution" du trilemme sont restées théoriques, confinées dans des livres blancs ou limitées à des réseaux expérimentaux.

Comment Ethereum a abordé le trilemme

Au lieu d'essayer de briser le trilemme en un seul endroit, Ethereum a commencé à le répartir sur plusieurs couches. L'idée était simple, bien que longtemps irréalisable : conserver la décentralisation et la sécurité au niveau de la couche de base tout en déplaçant l'évolutivité vers les couches supérieures.

C'est là qu'interviennent PeerDAS et zkEVM, deux composants que Vitalik Buterin présente aujourd'hui comme la preuve que le trilemme n'est plus une contrainte fondamentale. PeerDAS, introduit dans la mise à jour Fusaka, s'attaque au problème de la disponibilité des données. Il permet au réseau de transmettre beaucoup plus de données sans que chaque nœud ait à les stocker intégralement. Cela supprime l'un des principaux goulets d'étranglement de la mise à l'échelle sans introduire de centralisation.

Loading...

Le tweet a été supprimé par son auteur.

Mais nous avons tout sauvegardé 🙂.

zkEVM, à son tour, déplace l'exécution des transactions dans un environnement sans connaissance. Les transactions peuvent être traitées en dehors de la chaîne principale, mais leur exactitude est toujours vérifiée par Ethereum. Ainsi, la mise à l'échelle ne nuit pas à la sécurité de la couche 1, mais s'appuie au contraire sur elle.

Pourquoi Buterin affirme que le trilemme est résolu

Lorsque Vitalik Buterin parle d'un trilemme résolu, il ne prétend pas qu'Ethereum est déjà parfait. Son argument est différent : la limitation n'est plus architecturale. Une partie de la solution est déjà en place sur le réseau principal, tandis que l'autre partie est prête pour la production du point de vue des performances, bien qu'elle nécessite encore des améliorations en matière de sécurité.

Loading...

Le tweet a été supprimé par son auteur.

Mais nous avons tout sauvegardé 🙂.

Il parle également ouvertement du calendrier. La mise en œuvre complète de ce modèle prendra encore plusieurs années, jusqu'à la fin de la décennie. Ce qui importe, cependant, c'est qu'il ne s'agit pas d'une hypothèse, mais d'un déploiement progressif déjà en cours.

Ce que cela signifie pour l'industrie

Si Buterin a raison, le trilemme cesse d'être une excuse universelle. Il ne disparaît pas, mais il cesse d'être un verdict. La question n'est plus de savoir ce qu'il faut sacrifier, mais comment répartir la complexité entre les différentes couches du système.

Cela ne rend pas toutes les blockchains identiques, ni n'élimine la concurrence. Mais cela déplace le point de référence. Alors que la vitesse et la décentralisation semblaient auparavant s'exclure mutuellement, elles deviennent désormais des questions d'architecture, de temps et de discipline dans l'exécution.

Ethereum n'a peut-être pas aboli le trilemme, mais a montré qu'il était le résultat de choix de conception précoces plutôt qu'une limitation inévitable des blockchains.