Associé de Multicoin : pourquoi les blockchains modulaires sont-elles surévaluées ?
TechFlow SélectionTechFlow Sélection
Associé de Multicoin : pourquoi les blockchains modulaires sont-elles surévaluées ?
La modularité est excellente, mais la clé pour construire une technologie gagnante consiste à déterminer quelles parties de la pile doivent être intégrées et lesquelles doivent être laissées à d'autres.
Dédié à des analyses Web3 approfondiesRédaction : Kyle Samani, associé chez Multicoin Capital
Traduction : Luffy, Foresight News
Ces deux dernières années, le débat sur l'évolutivité des blockchains s'est concentré autour d'un thème central : la confrontation entre modularité et intégration.
Notez que dans les discussions cryptographiques, on confond souvent les systèmes « unifiés » et « intégrés ». Le débat technique entre systèmes intégrés et modulaires s'étend sur une histoire de près de 40 ans. Ce débat dans le domaine crypto devrait être abordé à travers le même prisme historique, car il ne s'agit en rien d'une controverse nouvelle.
Lorsqu'on examine la modularité contre l'intégration, la décision de conception la plus importante qu'une blockchain puisse prendre concerne dans quelle mesure elle expose aux développeurs d'applications la complexité de sa pile technologique. Les clients des blockchains sont les développeurs d'applications ; c’est donc leur point de vue qui doit guider la conception finale.
Aujourd'hui, la modularité est largement considérée comme le principal moyen d’évolutivité des blockchains. Dans cet article, j’interrogerai ce postulat depuis les principes premiers, révélerai les mythes culturels entourant les systèmes modulaires ainsi que leurs coûts implicites, et partagerai les conclusions auxquelles je suis parvenu après six ans de réflexion sur ce sujet.
Les systèmes modulaires augmentent la complexité du développement
À ce jour, le coût implicite le plus important des systèmes modulaires réside dans l'accroissement de la complexité du processus de développement.
Les systèmes modulaires augmentent fortement la complexité que doivent gérer les développeurs d’applications, tant dans le contexte propre à leurs applications (complexité technique) que dans leurs interactions avec d'autres applications (complexité sociale).
Dans le contexte crypto, les blockchains modulaires permettent théoriquement une plus grande spécialisation, au prix de nouvelles complexités. Cette complexité — essentiellement technique et sociale — est transférée aux développeurs d’applications, rendant ainsi la création d’applications plus difficile.
Prenons par exemple OP Stack. À ce jour, il semble être le cadre modulaire le plus populaire. OP Stack oblige les développeurs à choisir entre adopter la Law of Chains (ce qui entraîne une forte complexité sociale), ou bien à faire un fork et gérer indépendamment. Ces deux choix imposent aux créateurs une complexité significative en aval. Si vous choisissez de faire un fork, bénéficierez-vous du soutien technique d’autres acteurs de l’écosystème (CEX, passerelles fiat, etc.) qui devront eux-mêmes supporter les coûts pour se conformer aux nouveaux standards techniques ? Si vous suivez la Law of Chains, quelles règles et contraintes seront appliquées aujourd’hui et demain ?
Source : modèle OSI
Les systèmes d'exploitation modernes (OS) sont des systèmes complexes composés de centaines de sous-systèmes. Un OS moderne gère les couches 2 à 6 du schéma ci-dessus. C’est un exemple classique d’intégration de composants modulaires afin de maîtriser la complexité exposée aux développeurs d’applications. Les développeurs d’applications ne veulent pas avoir à gérer quoi que ce soit en dessous de la couche 7 — raison même de l’existence des systèmes d’exploitation : ils absorbent la complexité des couches inférieures, permettant ainsi aux développeurs de se concentrer sur la couche 7. Ainsi, la modularité en soi ne devrait pas être un objectif, mais plutôt un moyen d’y parvenir.
Chaque grand système logiciel actuel — backend cloud, système d’exploitation, moteur de base de données, moteur de jeu, etc. — est hautement intégré tout en étant constitué de nombreux sous-systèmes modulaires. Les systèmes logiciels tendent vers une forte intégration afin de maximiser les performances et réduire la complexité du développement. Il en va de même pour les blockchains.
Au passage, Ethereum vise à réduire la complexité née à l’époque des forks de Bitcoin entre 2011 et 2014. Les partisans de la modularité soulignent souvent le modèle OSI (Open Systems Interconnection), affirmant que la disponibilité des données (DA) et l’exécution devraient être séparées ; toutefois, cet argument est largement mal compris. Une bonne compréhension du problème actuel conduit à une conclusion opposée : l’OSI illustre plutôt un système intégré qu’un système modulaire.
Les chaînes modulaires n'exécutent pas le code plus rapidement
Par définition, la caractéristique commune des « chaînes modulaires » est la séparation entre disponibilité des données (DA) et exécution : un ensemble de nœuds gère la DA, tandis qu’un autre (ou plusieurs autres) gère(nt) l’exécution. Les ensembles de nœuds n’ont pas besoin de se chevaucher, mais ils peuvent le faire.
En pratique, séparer DA et exécution n'améliore pas fondamentalement les performances de chacune ; quelque part dans le monde, un matériel doit effectuer la DA, et ailleurs un autre matériel doit assurer l’exécution. Séparer ces fonctions n’accélère ni l’une ni l’autre. Bien que cela puisse réduire les coûts de calcul, ce n’est possible qu’en centralisant l’exécution.
Il faut le redire : qu’il s’agisse d’architectures modulaires ou intégrées, du matériel quelque part doit accomplir le travail, et séparer DA et exécution sur différents matériels n’accélère ni n’augmente fondamentalement la capacité globale du système.
Certains affirment que la modularité permet à plusieurs EVM de fonctionner en parallèle via des rollups, permettant ainsi une évolutivité horizontale de l’exécution. Bien que cela soit théoriquement correct, cette vision met surtout en lumière les limites de l’EVM en tant que processeur monofil, plutôt que le principe fondamental de séparation DA/exécution dans le contexte de l’évolutivité globale du système.
La modularité seule n’améliore pas le débit.
La modularité augmente le coût des transactions pour les utilisateurs
Par définition, chaque L1 et chaque L2 constitue un registre d’actifs indépendant possédant son propre état. Ces fragments d’état peuvent communiquer, bien que cela implique des délais de transaction plus longs et une situation plus complexe pour les développeurs et les utilisateurs (via des ponts comme LayerZero et Wormhole).
Plus il y a de registres d’actifs, plus l’état global est fragmenté pour tous les comptes. Cela est problématique à la fois pour les chaînes et pour les utilisateurs traversant plusieurs chaînes. La fragmentation d’état peut entraîner plusieurs conséquences :
-
Réduction de la liquidité, entraînant des glissements de prix plus élevés ;
-
Consommation accrue de gaz (une transaction inter-chaînes nécessite au moins deux transactions sur au moins deux registres d’actifs) ;
-
Calculs redondants entre registres d’actifs (réduisant ainsi le débit total du système) : lorsque le prix ETH-USDC change sur Binance ou Coinbase, des opportunités d’arbitrage apparaissent sur chaque pool ETH-USDC de chaque registre d’actifs (on peut facilement imaginer un monde où chaque variation de prix génère plus de dix transactions simultanées sur divers registres. Maintenir la cohérence des prix dans un état fragmenté représente une utilisation extrêmement inefficace de l’espace bloc).
Il est crucial de comprendre que créer davantage de registres d’actifs augmente clairement les coûts dans toutes ces dimensions, en particulier ceux liés à la DeFi.
L’entrée principale de la DeFi est l’état on-chain (c’est-à-dire qui possède quels actifs). Quand une équipe lance une chaîne dédiée à une application / un rollup, elle crée naturellement une fragmentation d’état, ce qui nuit gravement à la DeFi, tant pour les développeurs (gestion de ponts, portefeuilles, latences, MEV inter-chaînes, etc.) que pour les utilisateurs (glissements, délais de règlement).
La DeFi fonctionne idéalement lorsque les actifs sont émis sur un seul registre d’actifs et échangés dans une seule machine d’état. Plus il y a de registres d’actifs, plus la complexité à gérer pour les développeurs augmente, et plus les coûts supportés par les utilisateurs grimpent.
Les rollups applicatifs n'ouvrent pas de nouvelles opportunités lucratives pour les développeurs
Les partisans des chaînes applicatives / rollups affirment que les incitations pousseront les développeurs à construire des rollups plutôt que sur L1 ou L2, afin que l’application puisse capter elle-même la valeur MEV. Toutefois, cette idée est erronée, car exécuter un rollup applicatif n’est pas la seule façon — ni même souvent la meilleure — de ramener la MEV vers le jeton de la couche applicative. Un jeton applicatif peut très bien coder dans ses contrats intelligents sur une chaîne générale la logique permettant de récupérer la MEV. Examinons quelques exemples :
-
Liquidations : si le DAO Compound ou Aave souhaite capter une partie de la MEV qui va aux robots de liquidation, il suffit de mettre à jour leurs contrats respectifs pour que, parmi les frais allant actuellement aux liquidateurs, une partie soit versée au DAO. Pas besoin d’une nouvelle chaîne / rollup.
-
Oracles : les jetons d’oracle peuvent capter la MEV en offrant un service de back running. En plus des mises à jour de prix, l’oracle peut regrouper toute transaction arbitraire garantie d’être exécutée immédiatement après la mise à jour. Ainsi, l’oracle peut capter la MEV en proposant ce service aux chercheurs (searchers), aux bâtisseurs de blocs, etc.
-
Frappe NFT : la frappe de NFT est envahie par des robots revendeurs. Cela peut être facilement atténué par un simple codage de redistribution progressive des profits. Par exemple, si quelqu’un revend son NFT dans les deux semaines suivant la frappe, 100 % des revenus retournent à l’émetteur ou au DAO. Ce pourcentage pourrait varier avec le temps.
Il n’existe pas de solution universelle pour capturer la MEV vers le jeton applicatif. Pourtant, avec un peu de réflexion, les développeurs peuvent aisément ramener la MEV vers leur propre jeton sur une chaîne générale. Créer une chaîne entièrement nouvelle est inutile, ajoute une complexité technique et sociale supplémentaire aux développeurs, et crée davantage de complications pour les utilisateurs en matière de portefeuilles et de liquidité.
Les rollups applicatifs ne résolvent pas les problèmes de congestion inter-applications
Beaucoup pensent que les chaînes applicatives / rollups garantissent que l’application ne sera pas affectée par les pics de gaz causés par d’autres activités sur la chaîne (comme la frappe d’un NFT populaire). Cette vision est partiellement juste, mais majoritairement fausse.
Ce problème est historique, dont la cause fondamentale est la nature monofil de l’EVM, et non l’absence de séparation entre DA et exécution. Tous les L2 paient des frais au L1, et les frais L1 peuvent augmenter à tout moment. Lors du boom des memecoins plus tôt cette année, les frais de transaction sur Arbitrum et Optimism ont dépassé 10 dollars. Récemment, les frais sur Optimism ont aussi grimpé brutalement à la suite du lancement de Worldcoin.
La seule solution aux pics de frais est : 1) maximiser la DA du L1, 2) raffiner autant que possible le marché des frais :
Si les ressources du L1 sont limitées, les pics d’utilisation dans les différents L2 se transmettent au L1, augmentant ainsi les coûts pour tous les autres L2. Par conséquent, les chaînes applicatives / rollups ne sont pas à l’abri des pics de gaz.
La coexistence de nombreux L2 EVM n’est qu’une tentative grossière de localiser les marchés de frais. C’est mieux que de placer le marché des frais sur un seul L1 EVM, mais cela ne résout pas le problème fondamental. Dès lors que l’on comprend que la solution réside dans la localisation des marchés de frais, la conclusion logique est d’avoir un marché de frais par état (plutôt que par L2).
D'autres chaînes ont déjà tiré cette conclusion. Solana et Aptos ont naturellement localisé leurs marchés de frais. Cela a exigé des années d’ingénierie intense adaptée à leurs environnements d’exécution respectifs. La plupart des partisans de la modularité sous-estiment gravement l’importance et la difficulté de cette ingénierie.
Marchés de frais localisés
En lançant plusieurs chaînes, les développeurs n’obtiennent aucun véritable gain de performance. Lorsqu’une application pousse le volume de transactions, le coût de toutes les chaînes L2 est impacté.
La flexibilité est surestimée
Les partisans des chaînes modulaires affirment que l’architecture modulaire offre plus de flexibilité. C’est manifestement vrai, mais cela a-t-il vraiment de l’importance ?
Depuis six ans, je cherche en vain des développeurs d’applications qui auraient besoin d’une flexibilité significative que ne leur offrirait pas un L1 généraliste. À ce jour, personne n’a pu clairement expliquer pourquoi la flexibilité est cruciale, ni comment elle aide directement à l’évolutivité, sauf pour trois cas très spécifiques. Voici les trois cas concrets où la flexibilité me paraît importante :
Applications exploitant un état « chaud ». L’état chaud désigne un état nécessaire à la coordination en temps réel d’un certain ensemble d’opérations, qui n’est temporairement validé sur la chaîne que de manière transitoire. Quelques exemples d’état chaud :
-
Les ordres limités dans un DEX, comme dYdX et Sei (beaucoup d’ordres sont finalement annulés).
-
dFlow coordonne en temps réel et identifie le flux d’ordres (dFlow est un protocole facilitant un marché décentralisé entre market makers et portefeuilles).
-
Les oracles comme Pyth, un oracle à faible latence. Pyth fonctionne comme une chaîne SVM indépendante. Pyth produit tellement de données que l’équipe principale a décidé qu’il valait mieux envoyer les mises à jour fréquentes de prix vers une chaîne distincte, puis les pontifier vers d’autres chaînes selon les besoins via Wormhole.
Chaînes modifiant le consensus. Le meilleur exemple est Osmosis (où toutes les transactions sont chiffrées avant d’atteindre les validateurs), et Thorchain (qui priorise les transactions dans un bloc selon les frais payés).
Infrastructure nécessitant un schéma de signature seuil (TSS). Parmi les exemples : Sommelier, Thorchain, Osmosis, Wormhole et Web3Auth.
Sauf Pyth et Wormhole, tous les exemples ci-dessus sont construits avec Cosmos SDK et fonctionnent comme des chaînes indépendantes. Cela témoigne pleinement de l’adéquation et de l’évolutivité de Cosmos SDK pour ces trois cas : état chaud, modification du consensus, et systèmes TSS.
Mais la plupart des projets listés ci-dessus ne sont pas des applications, ce sont des infrastructures.
Pyth et dFlow ne sont pas des applications, ce sont des infrastructures. Sommelier, Wormhole, Sei et Web3Auth ne sont pas des applications, ce sont des infrastructures. Parmi eux, le seul type d’application orientée utilisateur est un DEX spécifique (dYdX, Osmosis, Thorchain).
Depuis six ans, je demande aux partisans de Cosmos et Polkadot quels cas d’usage leur flexibilité permet. Je pense disposer désormais de suffisamment de données pour en tirer des conclusions :
Premièrement, les exemples d’infrastructure ne devraient pas exister sous forme de rollup, car ils produisent soit trop de données à faible valeur (comme l’état chaud, dont l’intérêt même est de ne pas soumettre les données au L1), soit ils remplissent des fonctions délibérément liées à la mise à jour d’état sur un registre d’actifs (tous les cas TSS).
Deuxièmement, le seul type d’application que j’ai vu bénéficier d’un changement de conception système est le DEX. Car les DEX regorgent de MEV, et les chaînes générales ne peuvent égaler la latence des CEX. Le consensus est la base de la qualité d’exécution des transactions et de la MEV, donc modifier le consensus ouvre naturellement de nombreuses opportunités d’innovation pour les DEX. Toutefois, comme mentionné plus haut, l’entrée principale d’un DEX au comptant est les actifs échangés. Les DEX se disputent les actifs, donc les émetteurs d’actifs. Dans ce cadre, une chaîne DEX indépendante a peu de chances de réussir, car les émetteurs d’actifs, lors de l’émission, ne pensent pas d’abord à la MEV liée au DEX, mais plutôt à la fonctionnalité générale des contrats intelligents et à leur intégration dans les applications des développeurs.
En revanche, les DEX de dérivés n’ont pas à se battre pour les émetteurs d’actifs ; ils dépendent principalement de collatéraux comme USDC et de flux de prix provenant d’oracles, et doivent nécessairement verrouiller les actifs des utilisateurs pour couvrir les positions de dérivés. Ainsi, dans la mesure où une chaîne DEX indépendante aurait un sens, c’est surtout pour des DEX spécialisés dans les dérivés comme dYdX et Sei.
Considérons maintenant les applications existantes sur des L1 intégrés généraux : jeux, systèmes DeSoc (comme Farcaster et Lens), protocoles DePIN (comme Helium, Hivemapper, Render Network, DIMO et Daylight), Sound, places de marché NFT, etc. Aucun de ces cas ne bénéficie particulièrement de la flexibilité apportée par la modification du consensus. Leurs registres d’actifs respectifs ont tous des exigences simples, évidentes et communes : frais bas, faible latence, accès aux DEX au comptant, accès aux stablecoins, et passerelles vers les monnaies fiduciaires, par exemple via les CEX.
Je crois que nous disposons désormais de suffisamment de données pour affirmer que la grande majorité des applications orientées utilisateur partagent les mêmes exigences générales que celles énumérées ci-dessus. Bien que certaines applications puissent optimiser marginalement d’autres variables grâce à des fonctionnalités personnalisées dans la pile, les compromis induits (plus de ponts, moins de prise en charge de portefeuilles, moins d’indexeurs / outils de requête, réduction des canaux fiduciaires, etc.) ne valent presque jamais le coup.
Lancer un nouveau registre d’actifs est une façon d’obtenir de la flexibilité, mais cela ajoute rarement de la valeur, et entraîne presque toujours une complexité technique et sociale importante pour un bénéfice final quasi négligeable aux développeurs d’applications.
Étendre la DA ne nécessite pas de re-staking
On entend aussi les partisans de la modularité parler de re-staking dans le contexte de l’évolutivité. C’est l’argument le plus spéculatif avancé par les défenseurs des chaînes modulaires, mais il mérite discussion.
L’idée générale est que, grâce au re-staking (par exemple via EigenLayer), tout l’écosystème crypto pourrait re-staker à l’infini l’ETH, alimentant un nombre illimité de couches DA (ex : EigenDA) et de couches d’exécution. Ainsi, tout en assurant l’appréciation de la valeur de l’ETH, on résoudrait l’évolutivité sous tous ses aspects.
Bien qu’il existe une incertitude énorme entre la réalité actuelle et ce futur théorique, admettons ici que toutes les hypothèses hiérarchisées fonctionnent comme annoncé.
Actuellement, la DA d’Ethereum est d’environ 83 Ko/s. Avec la sortie prévue de l’EIP-4844 plus tard cette année, cette vitesse doublera à environ 166 Ko/s. EigenDA pourrait ajouter 10 Mo/s supplémentaires, mais sous des hypothèses de sécurité différentes (pas tout l’ETH sera re-staké sur EigenDA).
En comparaison, Solana fournit actuellement environ 125 Mo/s de DA (32 000 shred par bloc, 1 280 octets par shred, 2,5 blocs par seconde). Solana est bien plus efficace qu’Ethereum et EigenDA. De plus, selon la loi de Nielsen, la DA de Solana s’étend au fil du temps.
Il existe de nombreuses façons d’étendre la DA via le re-staking et la modularité, mais ces mécanismes ne sont absolument pas nécessaires aujourd’hui, et ajoutent une complexité technique et sociale manifeste.
Construire pour les développeurs d'applications
Après des années de réflexion, j’en conclus que la modularité en soi ne devrait pas être un objectif.
Les blockchains doivent servir leurs clients — les développeurs d’applications — et donc doivent abstraire la complexité au niveau infrastructure, afin que les développeurs puissent se concentrer sur la création d’applications de premier plan.
La modularité est excellente. Mais la clé pour construire une technologie gagnante est de comprendre quelles parties de la pile doivent être intégrées, et lesquelles peuvent être laissées à d’autres. Pour l’instant, les chaînes intégrant DA et exécution offrent intrinsèquement une expérience plus simple pour les utilisateurs finaux et les développeurs, et constituent finalement une meilleure base pour des applications de premier ordre.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Multicoin Capital
