Kyle Samani, partenaire de Multicoin Capital, explique 7 raisons pour lesquelles les blockchains modulaires sont surévaluées.
Écrit par : Kyle Samani, associé, Multicoin Capital
Compilé par : Luffy, Foresight News
Au cours des deux dernières années, le débat sur l'évolutivité de la blockchain s'est concentré sur le sujet central du « débat entre modularité et intégration ».
Notez que les discussions sur les crypto-monnaies confondent souvent les systèmes « uniques » et « intégrés ». Le débat technique sur les systèmes intégrés par rapport aux systèmes modulaires s'étend sur 40 ans. Cette conversation dans l’espace des crypto-monnaies devrait être encadrée dans le même prisme que l’histoire, et c’est loin d’être un nouveau débat.
Lorsque l’on considère la modularité par rapport à l’intégration, la décision de conception la plus importante qu’une blockchain puisse prendre est la mesure dans laquelle la complexité de la pile est exposée aux développeurs d’applications. Les clients de la blockchain sont des développeurs d’applications, les décisions de conception finales doivent donc tenir compte de leur point de vue.
Aujourd’hui, la modularité est largement saluée comme le principal moyen d’évolution des blockchains. Dans cet article, je vais remettre en question cette hypothèse à partir des premiers principes, découvrir les mythes culturels et les coûts cachés des systèmes modulaires, et partager les conclusions que j'ai tirées de ma réflexion sur ce débat au cours des six dernières années.
Les systèmes modulaires augmentent la complexité du développement
Le coût caché de loin le plus important des systèmes modulaires est la complexité supplémentaire du processus de développement.
Les systèmes modulaires augmentent considérablement la complexité que les développeurs d'applications doivent gérer, tant dans le contexte de leurs propres applications (complexité technique) que dans le contexte des interactions avec d'autres applications (complexité sociale).
Dans le contexte des crypto-monnaies, les blockchains modulaires permettent théoriquement une plus grande spécialisation, mais au prix d’une nouvelle complexité. Cette complexité (de nature à la fois technique et sociale) est transmise aux développeurs d'applications, ce qui rend finalement la création d'applications plus difficile.
Par exemple, considérons la pile OP. Pour l’instant, il semble être le framework modulaire le plus populaire. OP Stack oblige les développeurs à choisir entre adopter la loi des chaînes (qui apporte beaucoup de complexité sociale) ou les bifurquer et les gérer séparément. Les deux options créent une complexité significative en aval pour les constructeurs. Si vous choisissez de fork, recevrez-vous le support technique d'autres acteurs de l'écosystème (CEX, Fiat on-ramp, etc.) qui doivent engager des coûts pour se conformer aux nouvelles normes technologiques ? Si vous choisissez de suivre la Loi des Chaînes, quelles règles et contraintes vous seront imposées aujourd’hui et demain ?
Source : modèle OSI
Les systèmes d'exploitation (OS) modernes sont des systèmes vastes et complexes contenant des centaines de sous-systèmes. Les systèmes d'exploitation modernes gèrent les couches 2 à 6 dans le diagramme ci-dessus. Il s'agit d'un exemple classique d'intégration de composants modulaires pour gérer la complexité de la pile exposée aux développeurs d'applications. Les développeurs d'applications ne veulent rien gérer en dessous de la couche 7, c'est pourquoi les systèmes d'exploitation existent : le système d'exploitation gère la complexité des couches inférieures afin que les développeurs d'applications puissent se concentrer sur la couche 7. La modularité ne doit donc pas être un but en soi, mais un moyen pour parvenir à une fin.
Aujourd'hui, tous les principaux systèmes logiciels dans le monde (backends cloud, systèmes d'exploitation, moteurs de bases de données, moteurs de jeux, etc.) sont hautement intégrés et composés de nombreux sous-systèmes modulaires. Les systèmes logiciels ont tendance à être hautement intégrés pour maximiser les performances et réduire la complexité du développement. Il en va de même pour la blockchain.
Soit dit en passant, Ethereum réduit la complexité apparue au cours de l’ère du fork Bitcoin 2011-2014. Les partisans de la modularité mettent souvent l'accent sur le modèle d'interconnexion des systèmes ouverts (OSI), arguant que la disponibilité des données (DA) et l'exécution doivent être séparées. Cependant, cet argument est largement mal compris. Une bonne compréhension du problème conduit à la conclusion opposée : l’argument selon lequel OSI est un système intégré plutôt qu’un système modulaire.
Les chaînes modulaires ne peuvent pas exécuter le code plus rapidement
De par sa conception, une définition courante de la « chaîne modulaire » est la séparation de la disponibilité des données (DA) et de l'exécution : un ensemble de nœuds est responsable de la DA, tandis qu'un autre ensemble (ou plusieurs ensembles) de nœuds est responsable de l'exécution. Les collections de nœuds ne doivent pas nécessairement se chevaucher, mais elles le peuvent.
En pratique, séparer l'AD de l'exécution n'améliore pas en soi les performances de l'un ou l'autre ; au contraire, certains matériels quelque part dans le monde doivent exécuter l'AD, et certains matériels quelque part doivent implémenter l'exécution. La séparation de ces fonctions n’améliore les performances d’aucune d’entre elles. Même si la séparation peut réduire les coûts de calcul, elle ne peut être réduite qu’en centralisant l’exécution.
Pour réitérer : quelle que soit l'architecture modulaire ou intégrée, un certain matériel doit faire le travail quelque part, et séparer l'AD et l'exécution sur du matériel distinct n'accélère ni n'augmente en soi la capacité globale du système.
Certains soutiennent que la modularité permet à plusieurs EVM de s'exécuter en parallèle de manière cumulative, permettant ainsi à l'exécution d'évoluer horizontalement. Bien que cela soit théoriquement correct, ce point de vue met en réalité l'accent sur les limites de l'EVM en tant que processeur monothread plutôt que sur le principe de base de la séparation de l'AD et de l'exécution dans le contexte de la mise à l'échelle du débit global du système.
La modularité à elle seule n’améliore pas le débit.
La modularité augmente les coûts de transaction pour les utilisateurs
Par définition, chaque L1 et L2 sont un registre d’actifs indépendant avec son propre état. Ces éléments d'état distincts peuvent communiquer, mais avec des latences de transaction plus longues et une plus grande complexité pour les développeurs et les utilisateurs (via des ponts inter-chaînes comme LayerZero et Wormhole).
Plus il y a de registres d’actifs, plus l’état global de tous les comptes devient fragmenté. C'est terrible à la fois pour les chaînes et pour les utilisateurs de plusieurs chaînes. La fragmentation de l’État peut entraîner une série de conséquences :
Liquidité réduite, entraînant un dérapage commercial plus élevé ;
Plus de consommation totale de gaz (les transactions inter-chaînes nécessitent au moins deux transactions sur au moins deux registres d'actifs) ;
Augmentation du double comptage dans les registres d'actifs (réduisant ainsi le débit global du système) : lorsque le prix de l'ETH-USDC évolue sur Binance ou Coinbase, des opportunités d'arbitrage se présenteront sur chaque pool ETH-USDC dans tous les registres d'actifs (vous pouvez facilement imaginer un Dans un monde où chaque fois que le prix ETH-USDC change sur Binance ou Coinbase, il y a plus de 10 transactions sur les différents registres d'actifs. Maintenir la cohérence des prix dans un état fragmenté est extrêmement faible en termes d'utilisation efficace des blocs).
Il est important de réaliser que la création d’un plus grand nombre de registres d’actifs augmente considérablement les coûts dans toutes ces dimensions, en particulier celles associées à DeFi.
La principale entrée de DeFi est l’état de la chaîne (c’est-à-dire qui possède quels actifs). Lorsque les équipes lancent des chaînes/Rollups d'applications, elles créent naturellement une fragmentation des états, ce qui est très préjudiciable à la DeFi, tant les développeurs gérant la complexité de l'application (ponts, portefeuilles, délais, MEV cross-chain, etc.), que les utilisateurs ( Glissements, retards de règlement).
La condition la plus idéale pour DeFi est que les actifs soient émis sur un seul registre d’actifs et négociés au sein d’une seule machine d’état. Plus le registre des actifs est important, plus les développeurs d’applications doivent gérer une complexité accrue et plus les coûts doivent être supportés par les utilisateurs.
App Rollup ne créera pas de nouvelles opportunités de monétisation pour les développeurs
Les partisans d'AppChain/Rollup estiment que les incitations conduiront les développeurs d'applications à développer des Rollups plutôt que de s'appuyer sur L1 ou L2 afin que les applications puissent elles-mêmes capturer la valeur MEV. Cependant, cette idée est erronée car l'exécution d'un cumul d'application n'est pas le seul moyen de capturer le MEV dans les jetons de la couche d'application, et ce n'est pas le meilleur moyen dans la plupart des cas. Les jetons de la couche application peuvent capturer le MEV dans leurs propres jetons simplement en codant la logique dans les contrats intelligents sur la chaîne commune. Considérons quelques exemples :
Liquidation : si Compound ou Aave DAO souhaitent capturer une partie du MEV allant au robot de liquidation, ils peuvent simplement mettre à jour leurs contrats respectifs afin qu'une partie des frais actuellement versés au liquidateur soit versée à leur propre DAO, sans qu'il soit nécessaire de le faire. pour une nouvelle chaîne/Rollup .
Oracle : les jetons Oracle peuvent capturer le MEV en fournissant des services de retour. En plus des mises à jour de prix, Oracle peut également regrouper toutes les transactions arbitraires en chaîne dont l'exécution est garantie immédiatement après une mise à jour de prix. Par conséquent, les oracles peuvent capturer MEV en fournissant des services de retour aux chercheurs, aux constructeurs de blocs, etc.
NFT Minting : NFT Minting regorge de robots scalpeurs. Cela peut être facilement atténué en codifiant simplement la réaffectation des bénéfices en baisse. Par exemple, si quelqu'un tente de revendre son NFT dans les deux semaines suivant la création du NFT, 100 % du produit reviendra à l'émetteur ou au DAO. Ce pourcentage peut évoluer avec le temps.
Il n’existe pas de réponse universelle à la capture du MEV dans des jetons de couche application. Cependant, avec un peu de réflexion, les développeurs d'applications peuvent facilement capturer MEV dans leurs propres jetons sur la chaîne universelle. Le lancement d’une toute nouvelle chaîne est tout simplement inutile et apporterait une complexité technique et sociale supplémentaire aux développeurs, ainsi que davantage de problèmes de portefeuille et de liquidité pour les utilisateurs.
Le correctif cumulatif d'applications ne peut pas résoudre les problèmes de congestion entre applications
Beaucoup pensent qu'Application Chain/Rollup garantit que les applications ne sont pas affectées par les pics de gaz causés par d'autres activités en chaîne, telles que le populaire minting NFT. Cette vision est en partie vraie, mais surtout fausse.
Il s'agit d'un problème historique, et la cause première est la nature monothread de l'EVM, et non pas parce qu'il n'y a pas de séparation entre DA et exécution. Tous les L2 paient des frais à L1, et les frais L1 peuvent être augmentés à tout moment. Lors de l'engouement pour les memecoins plus tôt cette année, les frais de transaction sur Arbitrum et Optimism ont brièvement dépassé 10 $. Les frais d’Optimism ont également récemment grimpé en flèche suite au lancement de Worldcoin.
Les seules solutions pour faire face aux hausses de frais sont : 1) maximiser le L1 DA, 2) affiner le marché des frais autant que possible :
Si les ressources de L1 sont limitées, les pics d'utilisation dans les L2 individuels seront répercutés sur L1, ce qui imposera des coûts plus élevés à tous les autres L2. L’application chain/Rollup n’est donc pas à l’abri des pics de gaz.
La coexistence de nombreux EVM L2 n'est qu'un moyen rudimentaire de tester le marché des frais de localisation. C'est mieux que de regrouper le marché des frais dans un seul EVM L1, mais cela ne résout pas le problème principal. Lorsque vous réalisez que la solution est un marché de frais localisé, le point final logique est un marché de frais par État (plutôt qu’un marché de frais par L2).
D'autres chaînes sont déjà parvenues à cette conclusion. Solana et Aptos localisent naturellement les marchés de frais. Cela a nécessité un travail d'ingénierie approfondi sur de nombreuses années pour les environnements d'exécution respectifs. La plupart des partisans du module sous-estiment gravement l’importance et la difficulté de concevoir des marchés de frais locaux.
En lançant plusieurs chaînes, les développeurs ne débloquent pas de réels gains de performances. Lorsque des applications entraînent une augmentation du volume de transactions, les coûts de toutes les chaînes L2 sont affectés.
La flexibilité est surfaite
Les partisans des chaînes modulaires soutiennent que l'architecture modulaire est plus flexible. Cette affirmation est évidemment vraie, mais est-elle vraiment importante ?
Depuis six ans, j'essaie de trouver des développeurs d'applications pour lesquels un L1 générique ne pourrait pas offrir une flexibilité significative. Mais jusqu’à présent, en dehors de trois cas d’utilisation très spécifiques, personne n’a été en mesure d’expliquer pourquoi la flexibilité est importante et comment elle contribue directement à l’évolution. Trois cas d'utilisation spécifiques dans lesquels je trouve que la flexibilité est importante sont :
Applications qui profitent de l’état « chaud ». L'état chaud est un état nécessaire pour coordonner un ensemble d'opérations en temps réel, mais ne sera soumis à la chaîne que temporairement et n'existera pas éternellement. Quelques exemples d’états thermiques :
Ordres limités dans les DEX tels que dYdX et Sei (de nombreux ordres limités finissent par être annulés).
Le flux d'ordres est coordonné et identifié en temps réel dans dFlow (dFlow est un protocole qui facilite un marché de flux d'ordres décentralisé entre les teneurs de marché et les portefeuilles).
Des oracles comme Pyth, qui est un oracle à faible latence. Pyth fonctionne comme une chaîne SVM autonome. Pyth génère tellement de données que l'équipe principale de Pyth a décidé qu'il était préférable d'envoyer des mises à jour de prix à haute fréquence à une chaîne autonome, puis d'utiliser Wormhole pour relier les prix à d'autres chaînes si nécessaire.
Modifier la chaîne de consensus. Les meilleurs exemples sont Osmosis (où toutes les transactions sont cryptées avant d'être envoyées aux validateurs) et Thorchain (où les transactions au sein d'un bloc sont priorisées en fonction des frais payés).
Une infrastructure est nécessaire pour exploiter le schéma de signature à seuil (TSS) d'une manière ou d'une autre. Quelques exemples de ceci sont Sommelier, Thorchain, Osmosis, Wormhole et Web3Auth.
À l'exception de Pyth et Wormhole, tous les exemples répertoriés ci-dessus sont construits à l'aide du SDK Cosmos et exécutés en tant que chaînes autonomes. Cela en dit long sur l’adéquation et l’évolutivité du SDK Cosmos pour les trois cas d’utilisation : les états chauds, les modifications par consensus et les systèmes Threshold Signature Scheme (TSS).
Cependant, la plupart des projets dans les trois cas d’utilisation ci-dessus ne sont pas des applications, mais 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, il n’existe qu’un seul type spécifique d’application destinée à l’utilisateur : DEX (dYdX, Osmosis, Thorchain).
Depuis six ans, j'interroge les partisans de Cosmos et Polkadot sur les cas d'utilisation qui résultent de la flexibilité qu'ils offrent. Je pense qu'il y a suffisamment de données pour faire quelques déductions :
Tout d'abord, les exemples d'infrastructure ne devraient pas exister sous forme de cumuls, soit parce qu'ils produisent trop de données de faible valeur (telles que les états chauds, et tout l'intérêt des états chauds est que les données ne sont pas validées vers L1), soit parce qu'ils effectuent quelque chose d'intentionnellement incompatible avec les actifs du grand livre, la fonctionnalité liée à la mise à jour du statut (par exemple, tous les cas d'utilisation de TSS).
Deuxièmement, la seule application que j'ai vue qui pourrait bénéficier d'une modification de la conception du système de base est un DEX. Parce que DEX est inondé de MEV et que les chaînes universelles ne peuvent pas égaler la latence de CEX. Le consensus est la base de la qualité de l'exécution des transactions et du MEV, de sorte que les changements basés sur le consensus apporteront naturellement de nombreuses opportunités d'innovation à DEX. Cependant, comme mentionné précédemment dans cet article, le principal élément d’entrée d’un DEX au comptant est l’actif négocié. Les DEX se disputent les actifs et donc les émetteurs d’actifs. Dans ce cadre, il est peu probable que les chaînes DEX indépendantes réussissent, car le principal problème pris en compte par les émetteurs d'actifs lors de l'émission d'actifs n'est pas le MEV lié au DEX, mais la fonctionnalité générale des contrats intelligents et l'intégration de cette fonctionnalité dans les applications respectives des développeurs.
Cependant, les DEX dérivés n'ont pas besoin de rivaliser pour les émetteurs d'actifs. Ils s'appuient principalement sur des garanties telles que l'USDC et les flux de prix Oracle, et doivent essentiellement verrouiller les actifs des utilisateurs pour garantir les positions sur les dérivés. Ainsi, dans le sens de chaînes DEX indépendantes, ils sont plus susceptibles de fonctionner pour les DEX axés sur les dérivés comme dYdX et Sei.
Examinons les applications L1 intégrées courantes qui existent aujourd'hui, notamment : les jeux, les systèmes DeSoc (tels que Farcaster et Lens), les protocoles DePIN (tels que Helium, Hivemapper, Render Network, DIMO et Daylight), le son, les échanges NFT, etc. . Aucun d'entre eux ne bénéficie particulièrement de la flexibilité apportée par la modification du consensus, leurs registres d'actifs respectifs ont un ensemble d'exigences assez simples, évidentes et communes : frais faibles, faible latence, accès au spot DEX, accès aux pièces stables et accès aux monnaies fiduciaires. canaux, tels que CEX.
Je pense que nous disposons désormais de suffisamment de données pour affirmer dans une certaine mesure que la grande majorité des applications destinées aux utilisateurs ont les mêmes exigences générales énumérées dans le paragraphe précédent. Bien que certaines applications puissent optimiser d'autres variables à la marge avec des fonctionnalités personnalisées dans la pile, les compromis qui accompagnent ces personnalisations n'en valent généralement pas la peine (plus de ponts, moins de prise en charge du portefeuille, moins de prise en charge du programme d'indexation/enquête, réduction de la monnaie légale). chaînes, etc.).
Le déploiement de nouveaux registres d'actifs est un moyen d'atteindre la flexibilité, mais cela ajoute rarement de la valeur et introduit presque toujours une complexité technique et sociale avec peu d'avantages ultimes pour les développeurs d'applications.
Le DA étendu ne nécessite pas de réhypothèque
Vous entendrez également les partisans du module parler de réhypothécation dans le contexte de la mise à l’échelle. Il s’agit de l’argument le plus spéculatif avancé par les partisans de la chaîne modulaire, mais il mérite d’être discuté.
Il indique en gros qu'en raison du re-staking (par exemple, via des systèmes comme EigenLayer), l'ensemble de l'écosystème cryptographique peut re-staker l'ETH un nombre infini de fois, permettant ainsi un nombre illimité de couches DA (par exemple, EigenDA) et de couches d'exécution. Par conséquent, l’évolutivité est résolue sous tous les aspects tout en garantissant l’appréciation de la valeur de l’ETH.
Malgré l’énorme incertitude entre la situation actuelle et l’avenir théorique, nous tenons pour acquis que toutes les hypothèses de stratification fonctionnent comme annoncé.
Le DA d’Ethereum est actuellement d’environ 83 Ko/s. Avec l'introduction de l'EIP-4844 plus tard cette année, cette vitesse peut doubler pour atteindre environ 166 Ko/s. EigenDA peut ajouter 10 Mo/s supplémentaires, mais nécessite un ensemble différent d'hypothèses de sécurité (tous les ETH ne seront pas re-garantis auprès d'EigenDA).
À titre de comparaison, Solana propose actuellement un DA d'environ 125 Mo/s (32 000 fragments par bloc, 1 280 octets par fragment, 2,5 blocs par seconde). Solana est beaucoup plus efficace qu'Ethereum et EigenDA. De plus, le DA de Solana se développe avec le temps selon la loi de Nelson.
Il existe de nombreuses façons d’étendre l’AD via le réhypothèque et la modularisation, mais ces mécanismes ne sont tout simplement pas nécessaires aujourd’hui et introduisent d’importantes complexités techniques et sociales.
Conçu pour les développeurs d'applications
Après des années de réflexion, j'arrive à la conclusion que la modularité ne doit pas être un objectif en soi.
La blockchain doit servir ses clients (c'est-à-dire les développeurs d'applications). Par conséquent, la blockchain doit abstraire la complexité au niveau de l'infrastructure afin que les développeurs puissent se concentrer sur la création d'applications de classe mondiale.
La modularité est géniale. Mais la clé pour créer une technologie gagnante consiste à déterminer quelles parties de la pile doivent être intégrées et lesquelles sont laissées aux autres. Pour l'instant, l'intégration de l'AD et des chaînes d'exécution offre par nature une expérience plus simple à l'utilisateur final et au développeur et fournira à terme une meilleure base pour les meilleures applications de leur catégorie.
Lien d'origine
Cet article est reproduit de Foresight News avec autorisation
Cet article Partenaire Multicoin d'une institution de capital-risque : Pourquoi la blockchain modulaire est surévaluée est apparu pour la première fois sur Zombit.