Delphi Labs : Dans un contexte, une vision et des valeurs spécifiques, Cosmos devient le choix optimal
TechFlow SélectionTechFlow Sélection
Delphi Labs : Dans un contexte, une vision et des valeurs spécifiques, Cosmos devient le choix optimal
Analyser chaque écosystème et expliquer la raison finale du choix de Cosmos.
Dédié à des analyses Web3 approfondiesRédaction : Delphidigital
Traduction : Oncle Rouge - IBCL
Introduction
Delphi Labs est le département de recherche et développement protocolaire de Delphi, une équipe d’environ 50 personnes dédiée à la construction de nouveaux primitifs Web3. Auparavant, cette équipe se concentrait sur la recherche et le développement de protocoles sur Terra. Après l’effondrement de Terra, Delphi Labs a dû prendre une décision cruciale quant à l’orientation future de nos efforts de construction.
L'effondrement de Terra ayant mis en lumière les risques potentiels liés à la construction sur une mauvaise plateforme, nous avons souhaité prendre le temps nécessaire pour tirer des enseignements et faire le bon choix quant à la direction à suivre. Notre objectif était d’étudier chaque L1/L2 majeur, actuel ou émergent, comprendre leurs forces et faiblesses, et identifier où se situerait la prochaine frontière la plus prometteuse pour la DeFi.
Avant même de commencer, il est important de souligner que cet article ne doit pas être considéré comme un jugement absolu sur l’écosystème « meilleur », mais plutôt comme une analyse subjective de quel écosystème convient le mieux à notre contexte, vision et valeurs spécifiques.
Dans la première partie, nous exposons ces contraintes de conception ainsi que les critères clés que nous souhaitons optimiser.
Dans la deuxième partie, nous analysons chaque plateforme selon ces critères et expliquons pourquoi nous avons finalement décidé de nous concentrer sur l’écosystème Cosmos.
Ce fut un processus d’apprentissage profond, et cet article représente notre tentative de rendre publiques les découvertes issues de cette étude, dans l’espoir qu’elles puissent aider d’autres acteurs du secteur. Nous accueillons avec plaisir les retours et critiques de la communauté afin de tester la solidité de nos idées et nous assurer de n’avoir rien omis.
Première partie — Contraintes internes de Delphi Labs
Bien que nous ayons tenté autant que possible de procéder à partir d’une page blanche, les antécédents, visions et valeurs existantes de Labs ont limité notre espace de décision. Cela inclut notre intérêt marqué pour la DeFi et notre vision de sa construction, notre perception de la tendance multi-chaînes et de l’évolution du secteur, ainsi que l’importance qui en découle accordée à l’interopérabilité inter-chaînes.
Construit pour la DeFi
Il existe de nombreux types différents de protocoles et produits Web3, chacun confronté à des contraintes de conception distinctes lorsqu’il s’agit de choisir la bonne plateforme. Les activités de recherche et développement de Delphi Labs sont principalement centrées sur les protocoles DeFi, car c’est le domaine vertical qui nous intéresse le plus et qui correspond le mieux aux compétences et antécédents de notre équipe.
Nous réfléchissons à ce domaine depuis longtemps : nous avons commencé à y travailler dès 2018, investi via Ventures en 2019, et avant même le lancement officiel de Labs en tant que division indépendante de Delphi, nous avons eu la chance de conseiller pendant plusieurs années des pionniers mondiaux de la DeFi. C’est donc le domaine que nous pensons connaître le mieux, et c’est sous cet angle que nous avons mené toute notre analyse.
Reconditionnement de la DeFi
Nous ne pensons pas que l’expérience utilisateur finale en DeFi consistera à utiliser des protocoles séparés pour chaque fonctionnalité (échange au comptant, prêt, trading avec effet de levier, yield farming, dérivés, etc.). Nous pensons plutôt que cela sera regroupé en une expérience unique, verticalement intégrée, ressemblant davantage à un CEX.
Plus précisément, le crédit DeFi offert par Mars permettrait de créer un « compte de crédit DeFi universel » permettant aux utilisateurs d’interagir de manière levée avec des applications DeFi approuvées, via un seul compte doté d’un ratio LTV global.
Cela reproduit une expérience similaire aux « sous-comptes » des exchanges centralisés, tout en conservant les avantages de la décentralisation : non-custodialité, résistance à la censure, et intégration de primitifs DeFi clés. Cela nécessite une grande rapidité et une composable synchronisée (nous estimons qu’une expérience reposant sur des appels asynchrones entre chaînes ne pourra jamais rivaliser avec celle d’un CEX), ainsi qu’un écosystème dynamique favorisant l’intégration et la liquidité.
C’est notre meilleure estimation de ce à quoi pourrait ressembler l’expérience finale en DeFi, et nous voulons donc nous assurer de choisir un écosystème capable de soutenir cette vision.
Les tendances que nous observons dans le secteur
Deux visions extrêmes s’opposent quant à l’état final de la cryptomonnaie. La première suppose que toutes les activités convergeront vers un environnement d’exécution unique (le modèle dit « monolithique »). La seconde postule l’existence d’un grand nombre d’environnements d’exécution spécialisés, chacun avec ses propres compromis (modèle dit « multi-chaînes »). Évidemment, divers points intermédiaires existent entre ces deux extrêmes.
En fin de compte, nous pensons que le compromis central ici oppose la composable synchronisée offerte par les monolithes aux avantages de la spécialisation.
Notre conviction est que les projets opteront de plus en plus pour la spécialisation, conduisant à un paysage crypto fondamentalement multi-chaînes. Dans cette section, nous expliquerons pourquoi nous pensons que cela va se produire.
Nous identifions trois principaux avantages à la spécialisation : coûts inférieurs ou plus prévisibles, personnalisation, et souveraineté.
Coûts de ressources inférieurs ou plus prévisibles
Notre hypothèse de base est que la demande d’espace-bloc, comme la demande de calcul, est élastique : plus l’espace-bloc est bon marché, plus il y aura de types de calcul pouvant migrer sur chaîne. Cela signifie que peu importe la rapidité d’une chaîne monolithique, la demande pour l’espace-bloc risque de dépasser l’offre, entraînant une hausse progressive des coûts.
En outre, les applications sur une chaîne monolithique doivent constamment concurrencer toutes les autres applications présentes sur cette même chaîne pour l’espace-bloc. Cela peut provoquer des congestions réseau, perturbant l’expérience utilisateur via des frais exorbitants ou même des arrêts complets de la chaîne.
Pendant le minting des Otherdeeds, les transferts ETH ont dépassé 500 $ par transaction
Dans l’ensemble, cela signifie que les dApps sur une chaîne monolithique subiront :
a) Une augmentation progressive des coûts à mesure que davantage d’activités migrent sur chaîne
b) Une plus grande incertitude quant au coût des ressources, car celui-ci dépend de la demande d’autres dApps pour l’espace-bloc
Bien que certains dApps puissent accepter ces compromis en échange des bénéfices liés au prototypage rapide, à la composable synchronisée et aux effets réseau, nous pensons que ce compromis n’a pas de sens pour de nombreuses applications.
Un exemple typique est le jeu vidéo, un domaine qui nous enthousiasme particulièrement. À mesure que les jeux déplaceront davantage leur économie, voire leur logique de jeu elle-même, sur chaîne, la prévisibilité des coûts de ressources deviendra cruciale.
Si un NFT populaire fait grimper les frais de transaction ou bloque la chaîne entière, les utilisateurs ne pourront plus jouer au jeu.
Le coût est élevé, surtout quand on considère que les jeux constituent largement des écosystèmes isolés, tirant peu ou pas de bénéfice de la composable.
Même si les chaînes monolithes peuvent continuer à étendre verticalement leur espace-bloc, cela ne résout pas véritablement le problème, car la demande continuera d’augmenter et les applications resteront en concurrence. Les chaînes applicatives spécialisées offrent une solution de marché libre, permettant une décomposition horizontale de l’espace-bloc et garantissant un haut niveau de localité des données.
Personnalisabilité
Toutes les applications lancées sur une blockchain monolithique héritent et doivent accepter une série de décisions de conception imposées par la plateforme : modèle de consensus, sécurité, runtime, mempool, machine virtuelle, etc. En revanche, une chaîne dédiée à une application spécifique peut personnaliser tous les composants de sa pile technologique, en les optimisant pour ladite application ou catégorie. Comme Dan Robinson et Charlie Noyes de Paradigm nous l’ont dit :
« La conception des protocoles blockchain est floue. Il n’existe pas de réponse unique et « correcte » à la question de l’évolutivité ou de la sécurité. Des propriétés comme la neutralité de confiance ne peuvent être pleinement définies. Aujourd’hui, les plateformes d’applications appliquent des réglages statiques fixes à ces décisions de conception. »
Pour comprendre les bénéfices de la personnalisabilité, examinons quelques exemples :
Optimisation du dilemme évolutivité
Une chaîne dédiée à une application peut adapter sa stratégie dans le dilemme évolutivité-sécurité-décentralisation selon ses besoins, au lieu d’accepter le compromis imposé par une plateforme donnée. Un jeu pourrait par exemple se soucier moins de la décentralisation/sécurité, et être exécuté par un petit ensemble de validateurs, potentiellement autorisé, avec des exigences matérielles plus élevées, afin d’améliorer les performances. Par exemple, DeFi Kingdoms (Crabada) était initialement un dApp smart contract sur la chaîne Avalanche C-Chain, puis a migré vers son propre subnet, sacrifiant ainsi de la sécurité pour bénéficier de frais de gaz plus bas.
Personnalisation de la machine d'état
Une plateforme peut personnaliser tous les aspects de sa machine d’état : mempool, diffusion des transactions, ordonnancement des blocs, distribution des récompenses de mise, modèle d’exécution, précompilations, frais, etc. Quelques exemples :
1. Modèles de frais personnalisés :
- Osmosis ajoutera une cryptographie seuil pour atténuer le « mauvais MEV » (ex. attaques sandwich), tout en internalisant le « bon MEV » : le protocole pourra arbitrer ses propres pools et redistribuer les profits aux stakers OSMO.Osmosis permet aux utilisateurs de payer les frais de transaction dans n’importe quel token disponible sur son DEX. Il permet également d’intégrer ces frais aux frais d’échange, simplifiant encore davantage l’expérience utilisateur.
- dYdX facture des frais de swap au lieu de frais de gaz sur les transactions.
2. Solutions MEV personnalisées :
- Sur THORChain, l’ordre des échanges est déterminé par une logique de file d’attente intégrée à la machine d’état. Les swaps générant les frais les plus élevés passent toujours en tête. Les nœuds THORChain ne peuvent pas réordonner les échanges.
- Injective peut régler son carnet d’ordres via des enchères par lots automatiques par bloc, minimisant ainsi le MEV.
Optimisation des performances / évolutivité :
- Solana, Sui, Aptos, Fuel, Injective, Osmosis, Sei, etc., exploitent l’exécution parallèle pour traiter les transactions qui n’impliquent pas le même état (paires/pools distincts), augmentant fortement l’évolutivité.
Validateurs offrant des services supplémentaires :
- La chaîne Stargaze, axée sur les NFT, dispose de validateurs supportant le service IPFS pinning, facilitant l’upload de données NFT sur IPFS.
- Injective inclut un pont Ethereum sécurisé par les validateurs, garantissant que la sécurité économique du pont soit identique à celle de la chaîne.
Personnalisation du mempool / consensus :
- Sommelier expérimente une nouvelle conception de mempool basée sur un DAG, offrant des garanties de disponibilité et de causalité, tout en réduisant la charge du consensus ; cette avancée a d’abord été adoptée par des monolithes rapides comme Aptos et Sui.
- dYdX déplace hors chaîne le moteur d’appariement des ordres, réalisant ainsi des calculs off-chain tout en conservant le règlement des transactions on-chain. Cela améliore fortement l’évolutivité.
- ABCI++ est un outil ajoutant de la programmabilité à chaque étape du processus de consensus Tendermint. Celestia utilise ABCI++ pour intégrer le codage d’effacement dans son processus de production de blocs.
Confidentialité :
- Secret Network est une plateforme de contrats intelligents générale par défaut privée, utilisant des enclaves Intel SGX dans des environnements d’exécution fiables (TEE) pour garantir la sécurité et l’anonymat des données.
- Penumbra est une autre blockchain par défaut privée, mais davantage centrée sur la DeFi et la gouvernance, utilisant la cryptographie plutôt que le matériel (Intel SGX) comme Secret Network. Penumbra utilise Tendermint et se connecte via IBC, mais remplace le SDK Cosmos par sa propre implémentation Rust personnalisée. Ils intègrent directement la cryptographie seuil au consensus, leur permettant d’exécuter des opérations telles que des swaps masqués.
Capture de valeur :
- Dans toute blockchain, les applications transfèrent de la valeur au protocole sous-jacent, sous forme de frais et de MEV, ou plus précisément, au token gas/frais sous-jacent. À long terme, nous pensons que les plus grands dApps pourraient devenir plus importants que n’importe quel L1 individuel, s’étendant sur plusieurs L1/rollups, combinant liquidité, marque, expérience utilisateur, etc. Ils contrôleront aussi la relation avec les utilisateurs, ce qui leur permettra éventuellement d’intégrer verticalement leur propre L1 spécialisé, internalisant ainsi les revenus de frais et les fuites de MEV (ex. dYdX). Ce niveau de spécialisation aligne les intérêts de l’application et de la couche sous-jacente (exécution, règlement, consensus) autour d’un seul token.
Souveraineté
Une différence clé entre les contrats intelligents et les chaînes applicatives est que ces dernières possèdent une souveraineté indépendante, contrairement aux premiers. La gouvernance des contrats intelligents dépend finalement de celle de la blockchain hôte. Cela introduit un risque de plateforme : de nouvelles fonctionnalités ou mises à jour sur la chaîne de base peuvent nuire à l’expérience utilisateur du contrat intelligent, voire le briser dans certains cas.
L’importance de la souveraineté devient également évidente lors d’une vulnérabilité logicielle : un dApp exploité ne peut pas récupérer par un fork sans convaincre la chaîne de base de bifurquer, ce qui constitue une barrière quasi insurmontable sauf cas exceptionnels.
Inconvénients de la spécialisation
La spécialisation présente également plusieurs inconvénients majeurs :
-
Coût — Lancer une chaîne indépendante est plus chronophage et coûteux que de simplement déployer un contrat intelligent sur une chaîne existante. Cela requiert davantage de compétences techniques, la mobilisation de validateurs, et augmente la complexité infrastructurelle (indexation, portefeuilles, explorateurs, etc.).
-
Absence de composable synchronisée — Sur une chaîne monolithique, toutes les applications tournent sur une machine d’état partagée, bénéficiant ainsi d’une composable atomique et synchronisée. L’infrastructure inter-chaînes ne permet actuellement pas cela, et introduit toujours des hypothèses de confiance supplémentaires.
Concernant le coût, bien qu’une chaîne dédiée n’ait jamais été aussi facile à déployer qu’un contrat intelligent sur une chaîne existante, nous pensons que l’écart s’est considérablement réduit grâce à la maturation technologique et à l’arrivée de projets comme Interchain Security, et qu’il pourrait continuer à se réduire.
Le vrai inconvénient est la perte de composable synchronisée. Nous avons vu les bénéfices apportés par la re-gageabilité des tokens dans la croissance de la DeFi sur Ethereum, et il reste probablement une longue liste d’utilisations permises par la composable sans permission.
Bien que cela soit important, deux contre-arguments importants existent.
Premièrement, nous pensons que seules quelques applications tirent réellement profit de la composable synchronisée. Ces cas concernent principalement la DeFi, où la re-gageabilité des tokens est cruciale (ex. yield farming). Même dans la DeFi, on peut discuter de la nécessité réelle de la composable synchronisée, comme le succès de dYdX le démontre. Pour la majorité des autres dApps, nous pensons qu’une composable asynchrone est suffisante, à condition de disposer d’outils inter-chaînes robustes permettant un transfert fluide des actifs et une expérience utilisateur transparente.
Deuxièmement, la spécialisation ne signifie pas nécessairement déployer une seule application par chaîne, mais plutôt un groupe d’applications capables de collaborer efficacement ou de servir un cas d’usage spécifique.
Par exemple, bien qu’Osmosis soit souvent perçu comme une chaîne AMM, elle évolue vers une chaîne DeFi complète, accueillant désormais de nombreux dApps (marchés monétaires, stablecoins, vaults, etc.). Nous pensons que les applications bénéficiant de la composable auront naturellement tendance à se regrouper sur des chaînes spécialisées, permettant ainsi aux dApps qui en ont besoin de « choisir d’y adhérer ».
Pour ces raisons, nous pensons que toutes les activités ne se concentreront pas sur une seule chaîne monolithique, mais évolueront vers un maillage de chaînes spécialisées/rollups interconnectés, organisés autour de cas d’usage spécifiques.
Architecture inter-chaînes
En résumé, bien que la couche applicative DeFi puisse se regrouper, nous pensons que la couche blockchain continuera à se fragmenter, avec de plus en plus d’équipes de dApps choisissant de déployer leur propre chaîne applicative dédiée.
Cependant, nous pensons qu’il est peu probable que chacune de ces chaînes développe son propre écosystème DeFi, car :
a) Cela obligerait chaque chaîne à reconstruire tout l’écosystème DeFi, une tâche difficile ;
b) Cela fragmenterait la liquidité et conduirait à une expérience utilisateur sous-optimale.
Au contraire, nous pensons qu’il existera des centres spécialisés en DeFi, vers lesquels les chaînes applicatives spécialisées déployeront leurs tokens/économies.
Une analogie utile est celle des chaînes applicatives comme banlieues, les ponts formant la couche de transport reliant ces banlieues aux centres financiers urbains (c’est-à-dire les chaînes DeFi centrales).
Étant donné que la composable est cruciale pour l’expérience UX réintégrée mentionnée précédemment, et que nous ne voulons pas miser sur une seule chaîne, nous pensons que les meilleurs dApps DeFi se déployeront sur plusieurs centres DeFi gagnants, renforçant ainsi les effets réseau transversaux de liquidité, de marque et d’UX. C’est pourquoi nous tenons à passer du temps à explorer cette architecture et à identifier quels écosystèmes facilitent le mieux cela.
À ce jour, les applications inter-chaînes suivent deux approches principales :
-
Déploiements indépendants, sans communication entre eux (ex. Aave, Uniswap, Sushi, Curve). Cela signifie que le dApp existe nativement sur chaque chaîne où il est déployé, et peut composer synchroniquement avec tous les primitifs natifs. Toutefois, cela conduit à une fragmentation de la liquidité et à une mauvaise expérience utilisateur, car les traders/prêteurs reçoivent une exécution sous-optimale, et les LP doivent déplacer manuellement leur capital pour optimiser son utilisation.
-
Déploiement d’une chaîne applicative unique, sur laquelle toute la liquidité est centralisée (ex. Thorchain, Osmosis). C’est plus efficace en termes de capital, mais empêche la composition synchronisée avec d’autres dApps sur d’autres chaînes.
Delphi Labs explore actuellement une troisième voie — déployer des instances d’application sur plusieurs chaînes (avant-postes), mais en les reliant via une couche de coordination facilitant la communication et la redistribution de liquidité entre ces avant-postes. Vous pouvez lire ici ([1]) comment nous pensons que cette stratégie pourrait fonctionner sur Mars.
Si elle réussit, cela améliorera la performance des LP (déposer une fois, gagner des frais sur toutes les chaînes intégrées), l’exécution pour les traders/emprunteurs, et permettra à ces deux primitifs de composer synchroniquement avec d’autres dApps sur chaîne. C’est particulièrement crucial pour la vision de super-application, qui repose sur la composable synchronisée en termes d’intégration et de rapidité (les appels inter-chaînes sont trop lents pour offrir une bonne expérience aux traders avancés).
Exigences de la plateforme
En résumé, nos contraintes sont :
-
Nous nous concentrons sur les applications DeFi
-
Nous croyons que la DeFi sera regroupée en une expérience intégrée
-
Nous croyons que le monde deviendra de plus en plus multi-chaînes, et que les applications DeFi doivent être conçues pour pouvoir se déployer nativement sur plusieurs chaînes.
Sur la base de ces contraintes, certaines exigences clés de plateforme émergent :
-
Rapidité : Bien qu’elle ne puisse jamais être aussi rapide qu’un CEX, elle devrait idéalement s’en rapprocher le plus possible. Le temps de bloc détermine l’écart d’expérience par rapport à un CEX. Des temps de bloc plus courts améliorent l’efficacité du capital grâce à des mises à jour plus rapides des oracles, des liquidations plus rapides et des taux de levier plus élevés. Bien que non indispensable, des temps de bloc rapides et un débit élevé peuvent également permettre des carnets d’ordres on-chain, offrant une meilleure expérience utilisateur.
-
Écosystème : Outre la non-custodialité et l’accès sans permission, l’avantage principal d’une super-application DeFi face à un CEX réside dans la composable et le nombre d’intégrations possibles. Contrairement aux CEX, limités à leurs propres produits, une telle application peut intégrer n’importe quel primitif DeFi, permettant aux utilisateurs de combiner positions de liquidité, vaults, farming, staking, NFT, etc. La liquidité sur chaîne est également importante, car elle impacte directement l’expérience de trading.
Bien que la rapidité et l’écosystème soient les exigences principales, d’autres facteurs sont importants lors du choix de la plateforme :
-
Décentralisation : La différence principale entre une super-application et un CEX est la décentralisation, c’est-à-dire la non-custodialité, l’accès sans permission et la résistance à la censure. La décentralisation est un terme lourd, mais en fin de compte, toute chaîne que nous déployons doit offrir de fortes garanties de sécurité et d’activité. De nombreux rollups et chaînes atteignent une faible latence, souvent au prix de l’un ou l’autre de ces aspects. Notre évaluation de la décentralisation est subjective, mais prend en compte des facteurs comme : points de défaillance centralisés, résilience face aux attaques réglementaires, concentration de la gouvernance/actionnariat, nombre de nœuds, nombre d’entités indépendantes contribuant au développement, etc.
-
Interopérabilité inter-chaînes : Pour réaliser la vision d’architecture inter-chaînes décrite ci-dessus, la chaîne doit disposer d’une infrastructure mature, fiable et minimisant la confiance pour le transfert de messages et d’actifs entre chaînes. Sans cela, les instances ne pourront pas communiquer, ou seulement en exposant tout le système à des risques supplémentaires.
-
Maturité technologique : Comme nous l’avons vu avec Solana et d’autres chaînes, en particulier celles reposant sur des innovations expérimentales radicalement nouvelles, une technologie immature peut entraîner des interruptions et des risques durant le développement, comme des indisponibilités pour les premiers adopteurs. Pour une application axée sur l’effet de levier, une panne est très problématique (car les liquidations doivent se produire en temps voulu), et ajouter un risque technique à un protocole déjà complexe est généralement indésirable.
-
Portabilité du code : Bien que ce ne soit pas un facteur central dans notre analyse, nous avons également considéré la portabilité du code écrit pour une plateforme spécifique. Les écosystèmes utilisant des langages ou machines virtuelles de niche sont plus coûteux, car si l’écosystème échoue, le code ne pourra pas être réutilisé ailleurs.
Deuxième partie — Choix de l’écosystème
Comparaison des écosystèmes
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
Delphi Digital
