Fondateur de Synthetix : Reconsidérer la vision multi-chaînes de Synthetix et le partage de liquidité
TechFlow SélectionTechFlow Sélection
Fondateur de Synthetix : Reconsidérer la vision multi-chaînes de Synthetix et le partage de liquidité
Cet article se concentrera sur le jeton SNX et son rôle dans l'écosystème.
Dédié à des analyses Web3 approfondiesRédaction : Kain.eth
Traduction : TechFlow
Avec le lancement officiel de Synthetix V3, c’est le moment idéal pour remettre en question certaines hypothèses passées afin de s’assurer que la communauté reste alignée avec la vision à long terme. Cet article se concentrera sur le token SNX et son rôle au sein de l’écosystème.
Multi-chaînes
La vision de Synthetix est ambitieuse. Déployer le protocole Synthetix sur plusieurs chaînes est considérablement plus difficile que pour la plupart des autres protocoles DeFi. En effet, la majorité des protocoles déployent une instance indépendante sur chaque chaîne, ce qui introduit une complexité opérationnelle, mais constitue le moyen le plus simple d’exister sur plusieurs réseaux. Ensuite, de nombreux protocoles utilisent une gouvernance unifiée pour contrôler ces différentes instances. Bien que cela ajoute une complexité supplémentaire, la gouvernance fonctionne généralement hors chaîne ou sur un seul réseau. Certains protocoles vont plus loin encore, en permettant qu’une opération sur une chaîne affecte toutes les autres. Cela peut se faire via des ponts inter-chaînes, la gestion de liquidités ou des mécanismes de liquidation partagés. Les protocoles peuvent également assurer l’interopérabilité des actifs inter-chaînes via des wrappers ou des ponts. Dès le début 2020, la communauté Synthetix a imaginé un scénario bien plus vaste : un unique protocole s’étendant sur plusieurs réseaux, où le système se comporte comme si chaque opération sur chaque chaîne avait lieu sur une seule et même chaîne unifiée. Bien que nous soyons aujourd’hui plus proches de cet objectif qu’il y a trois ans, il reste insaisissable. De nombreux défis techniques non résolus persistent. Compte tenu de l’évolution de la cryptomonnaie ces dernières années, il convient de se demander si cette approche multi-chaînes reste la meilleure voie possible.
Pourquoi partager la liquidité ?
Imaginons le déploiement de Synthetix sur cinq réseaux EVM distincts. Le token SNX pourrait se déplacer sans friction entre ces chaînes et être utilisé pour fournir de la liquidité (LP SNX) sur chacune d’elles afin de soutenir les échanges. La complexité apparaît lorsque ces positions LP SNX soutiennent également la liquidité sur d’autres réseaux. Si Alice ne fait confiance qu’à Mainnet, elle peut y fournir de la liquidité SNX et ainsi soutenir les quatre autres réseaux supportés. Mais un paradoxe potentiel se pose ici : si elle ne fait confiance qu’à Mainnet, pourquoi voudrait-elle soutenir la liquidité sur d’autres réseaux ? Bob peut fournir de la liquidité SNX sur Optimism et soutenir Mainnet, Optimism et Base. Carol peut fournir de la liquidité sur Avalanche et ne soutenir que ce réseau. Théoriquement, le marché devrait régler cela, et la liquidité devrait se diriger vers les endroits où la demande d’échanges est la plus forte. Cette conception repose sur l’hypothèse que chaque réseau dispose d’un certain nombre d’utilisateurs uniques qui n’échangent que sur ce réseau-là, et nulle part ailleurs. S’ils ne peuvent pas fournir de liquidité ni échanger sur leur réseau préféré, ils seront complètement exclus de Synthetix. Nous pouvons remettre cette hypothèse en question plus tard ; pour l’instant, examinons ce que sa mise en œuvre requiert.
Mise en œuvre du partage de liquidité
L’approche complexe consiste à déployer des marchés et des pools différents sur chaque réseau, puis à autoriser les fournisseurs de liquidité à offrir de la liquidité transversale depuis n’importe quelle chaîne. Dans Synthetix V3, un marché représente un actif individuel, par exemple sBTC, tandis qu’un pool permet aux fournisseurs de liquidité d’envoyer leur liquidité à un agrégateur de marchés, qui la délègue ensuite à plusieurs marchés. Le principal pool sera le Spartan Pool, qui inclura tous les marchés « officiellement supportés ». Dans Synthetix V2x, un seul pool contenait tous les marchés supportés, et tous les fournisseurs de liquidité étaient obligés d’y déléguer leur liquidité.
Très bien, examinons maintenant un trader spécifique pour comprendre l’impact sur celui-ci. Supposons que ce trader échange uniquement sur Base. Il aime faire du trading de swing sur ETH ; pour garantir qu’il puisse continuer à ouvrir de nouvelles positions, il doit y avoir suffisamment de liquidité déléguée au Spartan Pool de Base et/ou au pool ETH de Base. Rappelez-vous que dans ce modèle, cela ne nécessite pas nécessairement que quelqu’un fournisse de la liquidité sur Base ; toute cette liquidité peut provenir de Mainnet ou d’autres chaînes. Cela fonctionne pour le trader de Base, car la demande de sETH sur Base entraînera que des fournisseurs de liquidité d’autres réseaux délèguent directement de la liquidité à ce marché via un pool de marché unique ou un pool incluant le marché ETH.
Pour que cette mise en œuvre fonctionne, une communication inter-chaînes très importante est nécessaire. En réalité, c’est une tâche extrêmement lourde, particulièrement à mesure que le nombre de réseaux supportés augmente. Cela pourrait être réalisé via CCIP et certaines infrastructures Chainlink à venir, mais ici, la question que nous devons nous poser n’est pas « Pouvons-nous le faire ? », mais plutôt « Devrions-nous le faire ? ».
Qu’est-ce que nous voulons accomplir ?
En fin de compte, nous souhaitons obtenir un marché de liquidité efficace, dans lequel la demande sur n’importe quelle chaîne soit couverte par l’offre sur cette même chaîne. Une hypothèse sous-jacente est que la liquidité est limitée, donc nous devons pouvoir la partager entre réseaux pour éviter la fragmentation de la liquidité — situation où les échanges sont possibles sur chaque chaîne, mais où la liquidité limitée est trop dispersée, rendant la liquidité médiocre sur tous les réseaux. Cela crée un problème de démarrage à froid : un manque de liquidité sur un réseau freine la demande, ce qui réduit encore l’incitation à fournir davantage de liquidité. Oui, la liquidité est limitée, mais certaines formes de liquidité le sont plus que d’autres. En partie, cette complexité multi-chaînes découle de la prise de conscience par la communauté qu’à court terme, la liquidité SNX sera probablement insuffisante pour répondre à la demande sur tous les réseaux. Ainsi, pour éviter d’introduire d’autres collatéraux, nous devons nous contorsionner de diverses façons afin de mettre en place ce système de liquidité inter-chaînes et éviter la fragmentation de la liquidité SNX. Ici, je veux souligner que selon moi, à long terme, si la demande existe, le token SNX s’élargira pour supporter le niveau de liquidité requis. Le problème est qu’en période de marché baissier, ce processus est retardé, car la demande n’augmente pas assez rapidement le collatéral SNX. Par conséquent, nous sommes forcés de choisir entre deux compromis : augmenter la complexité du système pour consolider le rôle du SNX comme principal collatéral, ou trouver un compromis.
Pourquoi ne pas rester uniquement sur Optimism ?
Un postulat clé de cette analyse est que les marchés doivent exister sur chaque chaîne. Je pense que c’est une hypothèse raisonnable. Mais c’est une hypothèse que nous devrions remettre en question. Un cas similaire serait que Coinbase dispose d’un exchange différent pour chaque système d’exploitation, permettant ainsi aux utilisateurs d’échanger quel que soit leur OS préféré. Combien de liquidité pourrait-on espérer sur Coinbase sur Debian ? Cette analogie s’éloigne un peu du sujet ; une comparaison plus pertinente serait que Coinbase ait un marché différent pour chaque moteur de base de données, répondant aux préférences des utilisateurs. Les utilisateurs ont-ils des préférences assez fortes pour un moteur de base de données au point d’affecter leur choix de plateforme d’échange ? Pourtant, c’est exactement la situation à laquelle nous faisons face dans la cryptomonnaie aujourd’hui. Certains utilisateurs soutiennent fermement une chaîne spécifique et refusent même de reconnaître ou d’échanger sur d’autres réseaux. Pourquoi assistons-nous à ce phénomène sur les plateformes de contrats intelligents, alors que ce n’est pas le cas avec les bases de données ? Dans cette analogie, les moteurs de base de données représentent la couche de stockage d’état du CeFi, tandis que les réseaux L1/L2 sont la couche d’exécution et/ou de stockage d’état du DeFi. La réponse est simple : on appelle ça un token. Bien que les supporters de certains moteurs de base de données puissent être agaçants, il n’existe aucun mécanisme pour transmettre ce tribalisme technologique aux utilisateurs finaux. En revanche, dans la cryptomonnaie, nous avons créé un incitatif extrêmement puissant pour encourager ces préférences utilisateur. Cette phase finira peut-être par passer, mais pour l’instant, je pense qu’il est raisonnable de supposer qu’il existe des groupes d’utilisateurs distincts sur la plupart des réseaux.
Fragmentation permanente ?
D’accord, la fragmentation des utilisateurs au niveau de l’exécution n’est pas surprenante, et nous semblons temporairement coincés dans cette situation. Même si les utilisateurs recherchent avant tout l’utilité, ils ont aussi un fort incitatif à vouloir que cette utilité n’existe que sur le réseau qu’ils soutiennent. Ainsi, même si nous construisions l’exchange le plus optimisé de l’histoire, s’il n’existait que sur une seule chaîne, il serait isolé et ne recevrait pas l’attention qu’il mérite. Ce constat est d’autant plus évident lorsque des concurrents — des exchanges centralisés — peuvent choisir n’importe quelle pile technique et regrouper tous les utilisateurs dans une seule base de données, sans que personne ne s’en soucie. Cela signifie que toute leur liquidité se trouve sur une île unique, un avantage énorme que les DEX décentralisés inter-chaînes ne peuvent égaler. À propos, une façon de résoudre ce problème serait d’abstraire le réseau et de fonctionner plus comme un exchange centralisé ; c’est précisément l’expérience que Infinex souhaite tenter. Du point de vue de Synthetix, c’est une expérience précieuse. Mais Synthetix doit s’optimiser pour le cas où Infinex échoue, ce qui signifie qu’en tant que protocole, il doit rejoindre les utilisateurs là où ils veulent échanger ou fournir de la liquidité — sur chaque chaîne.
Quelles sont nos options ?
Si nous acceptons que le protocole Synthetix doive se trouver là où sont les utilisateurs, comment y parvenir ? Selon moi, il existe trois méthodes.
-
Déployer une version fourchue de Synthetix sur chaque chaîne ;
-
Mettre en œuvre un protocole inter-chaînes unifié, où chaque changement d’état doit être propagé à toutes les chaînes ;
-
Déployer une instance indépendante sur chaque nouvelle chaîne, en minimisant les messages inter-chaînes et la fragmentation de liquidité grâce à l’utilisation de collatéraux non-SNX.
Option 1 : Faire des fourches indéfiniment
Ce n’est pas une solution viable, même si cela pourrait être amusant. Le principal obstacle est la dépendance au token SNX comme collatéral. Si vous avez 10 versions fourchées de SNX, elles perdront probablement toutes de la valeur, et la liquidité sur chaque fourche sera fortement réduite, sapant justement l’objectif d’éviter la fragmentation. La plupart des protocoles se contentent de déployer une nouvelle instance de leurs contrats et laissent la liquidité suivre naturellement le nouveau réseau ; Aave et Uniswap en sont de bons exemples. Pour Synthetix, nous avons besoin d’une quantité importante de SNX comme collatéral sur chaque réseau, ainsi que d’une charge de gouvernance élevée. Nous serions donc probablement amenés à fourcher le token SNX sur chaque réseau. Vous pouvez tester ce processus sur Base. Nous pourrions déployer une instance entièrement nouvelle de Synthetix, incluant SNX, en ajoutant un 'b' devant chaque token. Nous aurions alors bSNX, bsUSD et bsBTC. Bien que cela puisse sembler intéressant, je ne pense pas que ce soit notre meilleur espoir. Encore une fois, ce serait très amusant, et je ne dis pas que nous ne devrions pas y réfléchir. Un avantage des méthodes de fourchage aujourd’hui, par rapport à il y a quelques années, est que les déploiements sont désormais bien plus simples. Autrefois, déployer Synthetix sur un seul réseau pouvait prendre plusieurs jours. À cette époque, même avec des instances indépendantes, déployer sur plusieurs réseaux simultanément était impossible.
Option 2 : Théorie de la liquidité unifiée
Cette méthode consiste simplement à résoudre tous les problèmes techniques et à construire un protocole réseau capable de gérer tous les messages inter-chaînes nécessaires. Nous pourrions alors continuer à dépendre uniquement du collatéral SNX. Cela semble théoriquement excellent, et nous progressons dans cette direction, mais que se passe-t-il si nos hypothèses ci-dessus sont fausses ? Et s’il n’y avait pas suffisamment d’utilisateurs indépendants sur toutes ces chaînes pour générer un volume d’échanges supplémentaire significatif ? Et si nous passions trop de temps à construire cette infrastructure de support, pendant qu’un autre protocole développerait une solution mono-chaîne tellement supérieure que les utilisateurs commenceraient à migrer vers elle ? Il existe un précédent : dYdX. Ils ont construit un moteur de trading suffisamment performant pour attirer les traders. Si leur nouveau moteur sur Cosmos est nettement meilleur que tous les autres DEX, les utilisateurs EVM migrent-ils massivement ? Je pense que nous devrions concentrer la majeure partie de nos efforts sur les fonctionnalités principales du produit, plutôt que sur l’infrastructure de support. Toutefois, nous devrions au moins mener quelques expériences pour déterminer s’il existe suffisamment de volume d’échanges sur d’autres chaînes pour justifier une solution inter-chaînes.
Option 3 : Explorer les eaux interdites
Moi et d’autres anciens, nous croyons fermement au dogme du collatéral pur SNX. Quiconque remet en cause la sainteté du collatéral purement SNX doit être brûlé ou attaché et jeté dans un lac (métaphoriquement parlant). Même le noble duo Fifa et ha-oN ne serait pas épargné s’ils cédaient à la tentation du « sale » collatéral Ethereum. Pourtant, nous avons ici une excellente opportunité de tester l’hypothèse de demande réseau potentielle, sans avoir à déplacer le collatéral SNX inter-chaînes. Nous pourrions déployer les contrats perpétuels sur Base en utilisant uniquement Ethereum comme collatéral. Cela réduirait le risque de déplacer la liquidité SNX depuis Optimism. Cela nécessiterait presque aucune communication inter-chaînes. Le principal problème serait de transférer les frais vers Optimism pour les brûler. Mais il existe une autre option : utiliser les frais générés sur ce réseau pour racheter et brûler du SNX. Cela nous permettrait de tester simultanément deux approches novatrices avec un risque relativement faible. Si l’une d’entre elles échoue, nous aurons déjà établi une position sur le nouveau réseau, et pourrons ultérieurement passer à un collatéral SNX. Nous pourrions aussi revenir à la destruction de dette sur ce réseau plutôt que racheter. Cela soulève une dernière question : le meilleur mécanisme d’incitation pour la fourniture de liquidité consiste à brûler la dette uniquement sur le réseau où la liquidité est fournie, et non une dette globale. Sinon, nous créons un problème de « passager clandestin » : il pourrait être avantageux de camper sur le réseau le « plus sûr », même s’il n’a pas la demande la plus forte, et même si ce n’est pas là que les profits sont maximisés.
Un nouvel espoir
Si nous libérons le collatéral ETH sur un nouveau réseau, je pense que Base est le meilleur choix. Cela nous permettrait d’augmenter le volume d’échanges sans menacer les revenus d’échanges sur Optimism. C’est aussi moins risqué que Arbitrum. Cela devrait être une victoire pour les fournisseurs de liquidité SNX. L’objection serait : si nous permettons aux gens de transférer leur SNX vers Base et d’y fournir de la liquidité, le SNX capterait 100 % des frais sur les deux réseaux, au lieu de les partager. C’est vrai, mais le risque pour les fournisseurs de liquidité SNX est minime, car nous contrôlons la gouvernance. Nous pouvons mener cette expérience contrôlée, puis décider, en fonction des données, quelle option est la meilleure pour les détenteurs de SNX. Ce test n’est pas irréversible : si nous avons trop de collatéral SNX sur Optimism, nous pouvons autoriser le transfert de SNX vers Base comme collatéral. Cela diluerait les gains d’ETH et atteindrait un nouvel équilibre. Nous pourrions même imposer un plafond à la liquidité ETH ou l’interdire complètement comme collatéral. C’est pourquoi le contrôle de la gouvernance doit rester entièrement entre les mains des fournisseurs de liquidité SNX. Crucialement, cette expérience prouvera une chose : qu’il existe un volume d’échanges supplémentaire sur un nouveau réseau, sans nuire au volume existant sur Optimism. Tant que la part des frais allouée au SNX est suffisamment élevée, nous devrions pouvoir bien mesurer les revenus supplémentaires générables. Je pense que nous devrions commencer à un niveau modéré, puis ajuster progressivement. Capturer 40 % des frais pour les fournisseurs de liquidité SNX est un bon point de départ, à partir duquel nous pourrons ajuster. Nous devons vérifier si les fournisseurs de liquidité ETH sont prêts à rejoindre le réseau ; si la part des frais pour le SNX est trop élevée, nous ne pourrons pas correctement tester leur inclination à fournir de la liquidité ETH.
Et si ce modèle fonctionnait ?
Si nous menons cette expérience et observons une forte demande pour la liquidité ETH et les échanges sur la nouvelle chaîne, devrions-nous brûler le token SNX ? Je ne pense pas. Si cela fonctionne, nous pourrions étendre l’expérience à d’autres chaînes ; Arbitrum et Polygon seraient les choix les plus évidents. À ce stade, nous aurions probablement suffisamment de données pour reconnaître que les échanges sur Optimism sont également limités par la liquidité SNX. Si c’est le cas, nous pourrions également autoriser ETH comme collatéral sur Optimism. Plus radicalement encore, si la demande de liquidité soutenue par ETH s’avère bien supérieure à celle soutenue par SNX, nous pourrions même décider de désactiver la liquidité SNX sur Optimism. Mais si nous faisons cela, je pense que nous devons prendre des mesures supplémentaires.
Notre propre chaîne
Si après ces expériences, la demande du marché pour les échanges soutenus par ETH est nettement supérieure à ceux soutenus par SNX, nous devons l’accepter et en tirer parti. L’étape suivante serait de créer une AppChain sur la superchaîne Optimism. Cela nous permettrait de déplacer la gouvernance vers une chaîne que nous contrôlons ; ce serait aussi l’endroit où vous pourriez obtenir des prêts avec effet de levier en sUSD contre du SNX. C’est toujours une fonctionnalité clé du réseau Synthetix, et l’un des principaux avantages du stake de SNX. Je pense que nous n’aurions même pas besoin d’activer les échanges sur ce réseau, car la liquidité ETH y serait extrêmement faible. Ce serait le réseau où résideraient toutes les fonctions arrière-plan du SNX. Si, à l’avenir, nous pensons pouvoir développer efficacement un système de partage de liquidité inter-chaînes, c’est là que la liquidité existerait et serait déléguée aux autres chaînes.
Réseau ouvert
La fourniture de liquidité via SNX a toujours été difficile et très risquée, en raison des besoins de couverture. Ce problème, combiné à un taux d’inflation élevé, signifie que peu d’intégrateurs sont disposés à créer des solutions de mise en gage pour SNX. En migrant vers une AppChain, nous pourrions réduire le risque lié au stake de SNX et éliminer complètement l’inflation. Cela pourrait permettre d’intégrer le stake de SNX à davantage de plateformes et d’ouvrir le réseau à un public plus large. Actuellement, en raison des exigences de couverture, le rendement ajusté au risque des fournisseurs de liquidité est beaucoup plus faible. Peut-être que le SNX resterait comme fonds d’assurance du réseau, mais cela n’aurait pas besoin d’être maintenu activement, et serait bien moins risqué que la couverture continue.
Et les échanges inter-chaînes ?
Ils peuvent toujours être pris en charge dans cette nouvelle architecture ; ils nécessiteront CCIP, mais en principe, même si chaque chaîne dispose de sa propre liquidité, nous pouvons toujours assurer l’interopérabilité des Synths entre chaînes. Cela nécessite certes des messages inter-chaînes, mais c’est bien moins lourd que de supporter une liquidité inter-chaînes. Les échanges inter-chaînes restent un marché très lucratif et émergent. Bien que se concentrer sur les contrats perpétuels soit actuellement la stratégie optimale, nous devrions absolument continuer à expérimenter les Synth Teleporters et d’autres mécanismes innovants.
Conclusion
En résumé, nous faisons face à plusieurs défis techniques : nous pouvons les contourner et tester l’une de nos hypothèses fondamentales. Existe-t-il une demande latente pour les échanges sur d’autres réseaux ? Nous pouvons le faire en utilisant le collatéral ETH, avec peu de risques. Si cela fonctionne, nous pouvons étendre l’expérience à d’autres réseaux. Si cette voie s’avère correcte, nous pouvons migrer vers notre propre AppChain, percevoir des frais depuis plusieurs réseaux en utilisant le collatéral ETH, et n’utiliser le SNX que pour coordonner et gérer le protocole. Nous renonçons à une partie des frais totaux, mais nous pouvons nous développer rapidement et éviter qu’un autre protocole ne devienne dominant. Nous pouvons à tout moment tester un collatéral exclusif SNX sur n’importe quel réseau, et limiter si nécessaire le collatéral ETH ou d’autres collatéraux. Cela nous permet d’étendre rapidement à plusieurs chaînes avec un fardeau technique minimal. Beaucoup de données doivent être collectées durant ce processus, et nous devrions tester chaque étape progressivement, comme nous l’avons toujours fait dans Synthetix.
Je termine avec cette question cruciale : Sommes-nous prêts à capturer dès maintenant une part du total adressable des frais, ou préférons-nous attendre plus longtemps afin de capter 100 % des futurs frais lorsqu’une véritable implémentation inter-chaînes sera prête ? La bonne nouvelle est que nous pourrions potentiellement avoir les deux. Et si la première option s’avère plus rentable, nous aboutirons finalement à un réseau plus accessible, où n’importe qui pourra facilement miser et rejoindre le réseau, avec des barrières d’entrée bien plus basses.
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
@kaiynne
