胖鸟

Les taux d’intérêt flottants sont-ils vraiment le plus gros point de douleur pour les joueurs DeFi qui font de l’arbitrage avec levier ?

Récemment, j’ai utilisé l’ETH en garantie : j’ai emprunté des stablecoins à 3% de taux pour faire de l’arbitrage. Résultat : au milieu de la nuit, le marché a violemment oscillé. Les fonds du pool ont été empruntés en grande partie, et le taux d’emprunt a bondi instantanément jusqu’à 50%.

Le lendemain matin, les gains d’arbitrage durement gagnés avaient déjà été engloutis par les intérêts… et j’ai failli être liquidé de force.

Voilà pourquoi, dans le prêt à taux variable, les intérêts sont incontrôlables. Ensuite, parlons du @TermMax , récemment au cœur du suivi : comment il a transposé le mécanisme de liquidité concentrée d’Uniswap V3 dans le prêt, pour bâtir une architecture sous-jacente de « taux fixe déterministe » + des produits dérivés avec levier. 🧵

Ne vous laissez pas impressionner par ces mots comme « obligations zéro-coupon » : en réalité, la logique d’emprunt ressemble à l’achat, on-chain, de coupons d’échange à prix réduit.

👉 Achetez pour 0,95 USDC un coupon d’échange de 1 USDC qui expire dans 3 mois. À l’échéance, le système vous rembourse directement 1:1, donc 1 USDC. Vous réalisez un bénéfice net de 0,05 USDC grâce à l’écart.

Au moment même où vous achetez, le rendement est déjà verrouillé. Même si ensuite le marché s’effondre, vos gains ne baisseront pas d’un centime.

Peut-être que certains se demandent : pourquoi personne n’utilisait auparavant les taux fixes ? Est-ce que TermMax y arrive vraiment ?

Avant, tout le monde n’utilisait pas les taux fixes parce que la liquidité était trop fragmentée : il y avait trop de pools, avec trop peu de montant. Quand il fallait emprunter de grosses sommes, le slippage devenait très élevé.

TermMax s’inspire de la liquidité concentrée d’Uniswap V3 : on peut personnaliser une plage de taux pour les ordres (par exemple, je n’emprunte que dans une fourchette d’environ 4% à 6% par an). Ainsi, les fonds ne se dispersent plus.

👉 Pas de liquidation physique façon « sell-off » massif
Le prêt redoute les cygnes noirs, mais avec TermMax, le collatéral est simplement transféré tel quel aux déposants : pas besoin de le vendre sur le marché secondaire pour casser le prix. On évite ainsi, à la racine, la crise de liquidité.

Avec ce type de mécanisme, on peut créer plein de nouveautés, par exemple :
👉 Faire tranquillement du prêt-circulaire : un actif générateur d’intérêts en garantie sert à emprunter des stablecoins, afin d’amplifier encore davantage les rendements.

👉 Une gestion patrimoniale stable pour les gros portefeuilles : comme acheter des bons du Trésor, on choisit un horizon d’échéance, on achète des certificats avec décote à l’avance — et la prévisibilité du rendement est très élevée.

*👉 Options de couverture à faible seuil : en combinant la date d’échéance et le mécanisme de livraison en nature, les traders avancés n’ont pas besoin d’aller sur des places d’options complexes et difficiles à comprendre ; ils peuvent directement construire sur leur position d’emprunt des combinaisons de type covered call et de couverture.

Aujourd’hui, avec l’évolution de la DeFi, les acteurs on-chain et les grandes institutions ne recherchent plus uniquement des rendements annuels élevés : ils veulent surtout de la déterminisme et de la sécurité.

#termmax

Il y a quelque temps, j’ai vu de nombreux projets RWA commencer à essayer de transférer des actifs traditionnels comme des actions, des obligations, etc., sur la chaîne.

Mais j’ai toujours l’impression qu’il y a ici une contradiction.

La caractéristique la plus importante de la blockchain, c’est la transparence. Or, dans les marchés financiers, beaucoup de fois, on ne souhaite pas que toutes les informations soient rendues publiques.

Lorsque j’ai vu pour la première fois @Dusk , je me suis dit que c’était sans doute une blockchain de confidentialité qui met l’accent sur la dissimulation des informations de transaction. Mais ensuite, j’ai découvert que cette compréhension était un peu simpliste.

En réalité, le secteur financier n’a pas forcément besoin d’une dissimulation totale. Si toutes les données sont invisibles, comment les institutions prouvent-elles que les actifs sont conformes ? Comment le régulateur peut-il confirmer que les règles sont bien appliquées ?

C’est justement ce qui rend Dusk particulièrement intéressant : il ne considère pas la confidentialité comme le fait de ne rien montrer aux autres. Grâce à Phoenix, il protège les détails des transactions via des preuves à divulgation nulle de connaissance, ce qui permet aux utilisateurs de ne pas exposer l’intégralité des informations tout en réalisant la vérification. En plus, grâce à la divulgation sélective, certaines informations peuvent être confirmées dans des circonstances particulières.

Cette approche ressemble en fait beaucoup à la finance réelle.

Une banque ne publie pas toutes les informations de ses clients, mais en cas de besoin, elle doit accepter un audit.

Les institutions ne publient pas toutes leurs stratégies de transaction, mais le marché doit pouvoir vérifier que les transactions respectent les règles.

La confidentialité, ce n’est pas le refus de la transparence ; c’est la décision de l’étendue dans laquelle la transparence s’applique.

Cependant, je pense qu’il y a aussi une question à observer ici.

La divulgation sélective semble idéale, mais en pratique, ce n’est pas si simple à mettre en œuvre.

Qui décide quelles informations peuvent être consultées ?

Comment contrôler l’étendue de la divulgation ?

Si les exigences de conformité continuent d’augmenter à l’avenir, est-ce que l’espace de confidentialité deviendra de plus en plus réduit ?

Voilà des points que Dusk devra encore démontrer par la suite.
#dusk $DUSK

Récemment, j’ai aussi réussi à tomber dans le piège du portefeuille $QQQB

J’y joue depuis 3/4 jours. Pour l’instant, l’usure moyenne est d’environ 0,8/10 000, donc je peux dire que je suis sorti(e) de l’enfer. C’est juste que le temps est assez “malchanceux”

Après ne plus jouer au concours de transactions #ALPHA🔥 , j’ai l’impression que toute ma personne s’est élevée 😆#BsB

Ces derniers temps, j’ai investi dans pas mal de projets on-chain. Parmi tous ces projets, comment choisir un bon projet ? Ne pas avoir à s’inquiéter de la sécurité des fonds est un point clé. Donc, dès la première fois que j’ai vu @BabylonLabs_io , j’ai été attiré par son mécanisme unique.

Concernant Babylon, j’ai d’abord eu une compréhension assez intuitive : s’il veut faire participer des actifs externes à la sécurisation d’autres réseaux, le problème central doit être de savoir s’il y a suffisamment d’actifs qui sont mis en staking ; après tout, dans beaucoup de réseaux PoS, la robustesse de la sécurité est souvent directement liée à l’ampleur du staking.

Mais en participant plus en profondeur, j’ai découvert qu’il manquait une couche à cette compréhension. Parfois, le simple fait que des actifs existent ne signifie pas que la sécurité se produit vraiment.

Dit comme ça, ça peut sembler un peu compliqué. Si un réseau voit simplement beaucoup d’actifs verrouillés et considère que cela lui procure de la sécurité, ce n’est pas suffisant. Il faut aussi vérifier si ces actifs participent réellement à l’exécution du réseau conformément aux règles. Ces engagements de sécurité sont-ils correctement mis en œuvre ? Et comment les autres chaînes peuvent-elles confirmer que cette sécurité est réelle ?

En suivant cette idée, je trouve que le plus intéressant chez Babylon n’est pas d’introduire davantage de capitaux de staking, mais plutôt de tenter de mettre en place un processus de preuve de la sécurité.

Dans Babylon, l’accent est mis sur la question de savoir si la valeur se transforme en un résultat de sécurité digne de confiance. C’est aussi pour cela qu’il faut concevoir le mécanisme de Checkpoint : Babylon ne fait pas face à un consensus interne d’une seule chaîne, mais cherche à faire reconnaître le résultat de ce consensus par des réseaux externes.

Emm… c’est très différent du pont d’actifs. Le pont résout le problème du déplacement des actifs, tandis que #baby cherche à résoudre le problème du déplacement de la confiance.

C’est plutôt intéressant. En approfondissant, on voit qu’en réalité il change la définition même de la sécurité : il fait du résultat de sécurité quelque chose qui peut être vérifié et utilisé.

Cependant, il y a aussi un problème. Si, à l’avenir, de nombreuses chaînes dépendent de Babylon pour fournir des preuves de sécurité, alors $BABY deviendra lui-même une nouvelle source de confiance. À partir du moment où cette entrée ne peut pas être comprise et supervisée suffisamment par les participants, un système qui visait à réduire les coûts de confiance pourrait au contraire créer de nouvelles dépendances.

Donc, en regardant les choses de mon point de vue, le vrai intérêt n’est pas simplement d’apporter davantage d’actifs à la sécurité de la blockchain. Le point central, c’est qu’il réétudie comment la sécurité devrait être prouvée. Babylon veut faire de cette confiance une infrastructure qui soit vérifiable et connectable

Est-ce que c’est vraiment toujours comme ça ? La première fois que j’ai vu le @BabylonLabs_io , j’ai naturellement compris cela comme un système de Staking plus vaste. Ensuite, tout le temps, plus il y avait de dépôt (staking), plus il y avait de validateurs, et plus la sécurité du réseau était élevée.

Plus tard, en faisant concrètement l’expérience du processus de staking conçu par Babylon, j’ai constaté que cette compréhension était un peu superficielle. Si l’objectif est simplement d’augmenter le capital de sécurité, il n’est pas nécessaire de concevoir des rôles distincts comme Delegator et Finality Provider.

Je pense que le problème que Babylon cherche à résoudre n’est peut-être pas de savoir s’il existe assez d’actifs, mais plutôt, une fois ces actifs entrés dans le système, comment les transformer en une sécurité que d’autres réseaux peuvent reconnaître.

Cette différence est assez cruciale. En effet, dans un réseau PoS unique, les stakers, les validateurs et les acteurs qui exécutent la sécurité sont généralement couplés. Mais il existe une faille : lorsque la sécurité commence à circuler d’un réseau à l’autre, ce modèle pose problème.

Les gens compétents font ce qu’ils font de mieux. Ceux qui fournissent le financement ne sont pas forcément adaptés pour faire fonctionner une infrastructure de validation ; il leur faut peut-être un autre type de sécurité de chaîne, et ils ne veulent pas non plus recréer tout un système de validation. Donc, ce que fait Babylon n’est pas simplement d’augmenter le nombre de validateurs : il décompose le processus de sécurité. Le Delegator apporte un soutien économique, le Finality Provider participe à la confirmation de la sécurité, et la Consumer Chain utilise le résultat final de sécurité.

En mettant clairement toutes les responsabilités à leur place, et en suivant ce raisonnement, je pense que ce que Babylon cherche réellement à résoudre est la manière dont les ressources de sécurité peuvent passer d’un simple capital à une capacité réseau digne de confiance.

Par le passé, beaucoup de problèmes de chaînes ressemblent à ceci : comme si chaque ville devait reconstruire son propre réseau électrique. Le fonctionnement est possible, mais les coûts sont bien réels. C’est précisément ce que Babylon veut explorer.

Ehm… il y a aussi un problème ici : une fois les rôles séparés, même si le système devient plus flexible, les frontières de responsabilité deviennent plus complexes. Si la sécurité se révèle défaillante, à qui doit-on l’imputer : au capital mis en staking, ou aux nœuds qui exécutent la sécurité ? Et si les participants se préoccupent davantage des rendements que de l’entretien à long terme du réseau, les incitations économiques peuvent-elles rester efficaces ? Ce sont là les points que Babylon devra encore valider par la suite.

Babylon essaie également de voir si la sécurité peut être décomposée, combinée, puis fournie comme une capacité à d’autres réseaux. Si ce modèle fonctionne, à l’avenir, la manière de construire la sécurité pour les blockchains pourrait évoluer.
#baby $BABY

De nouveaux projets voient le jour en permanence, et les variations sont de plus en plus nombreuses. Avant aujourd’hui, je n’avais jamais compris pourquoi le @BabylonLabs_io choisit de protéger la finalité plutôt que de redessiner un consensus complet.

Parce que le problème le plus difficile à résoudre dans la blockchain n’est pas de produire des blocs : la plupart des réseaux savent générer des blocs rapidement. Le vrai défi, c’est lorsque deux états entrent en conflit : comment le réseau confirme quel résultat devient finalement irréversible. Les réseaux PoS traditionnels s’appuient généralement sur leur propre ensemble de validateurs : en maintenant la finalité grâce aux actifs mis en garantie. Mais pour les nouveaux réseaux, le nombre de validateurs, l’ampleur du capital mis en gage et la sécurité économique doivent être accumulés sur le long terme.

Hm… Ce qui est intéressant, c’est que Babylon n’a pas choisi de copier la façon de faire de Bitcoin ou d’Ethereum. Il a choisi d’entrer par la Finality. Dans la conception de Babylon, la chaîne PoS continue de fonctionner avec son propre consensus, et les validateurs restent responsables de la génération des blocs. Ce que fait Babylon, c’est de soumettre les états clés à Bitcoin via des Checkpoints, afin que Bitcoin fournisse un surcroît d’ordonnancement et une garantie d’immutabilité.

Le point le plus, le plus, le plus crucial : Babylon ne remplace pas la sécurité existante. Il ajoute une couche de sécurité économique au moment de la confirmation finale. Et cela m’a fait comprendre que ce que change réellement Babylon n’est pas qui produit les blocs. Donc je pense que les Finality Providers ne sont pas de simples nœuds : ils assument la responsabilité de la confirmation de finalité.

Je sens que Babylon cherche peut-être avant tout un moyen pour un réseau d’obtenir une plus forte déterministicité de l’état. Cela résout en fait un problème de longue date des réseaux PoS. Beaucoup de nouvelles chaînes ne sont pas incapables de fonctionner : à leurs débuts, il est simplement difficile d’établir des garanties de finalité suffisamment robustes.

Babylon propose un chemin nouveau. En y repensant, je pense que la valeur la plus importante de Babylon n’est pas d’offrir au BTC une nouvelle utilité.

Babylon tente de démontrer que la sécurité peut être modulaire. Un réseau peut avoir sa propre logique d’exécution, tout en empruntant une base de finalité plus forte.

Si, à l’avenir, de plus en plus de chaînes adoptent ce modèle, la sécurité de la blockchain ne sera peut-être plus quelque chose que chaque chaîne construit à répétition. Elle deviendra progressivement une infrastructure de base composable.
#baby $BABY

Quand j’ai vu pour la première fois @BabylonLabs_io , j’ai en fait naturellement classé cela comme un protocole de Staking. Cette logique ne diffère pas vraiment de la plupart des modèles de mise sous garantie des anciens réseaux PoS.

Mais ensuite, en relisant l’architecture complète de #baby , j’ai réalisé que cette compréhension était peut-être trop simple. Si l’objectif était simplement de créer un produit de Staking, il n’y aurait pas besoin de concevoir une relation de rôles aussi complexe. Du Delegator au Finality Provider, jusqu’à la Consumer Chain et au Checkpoint : Babylon y consacre beaucoup d’efforts non pas pour savoir comment immobiliser des actifs, mais pour résoudre un autre problème, plus difficile.

Comment un réseau peut-il confirmer que la sécurité fournie par un autre réseau est réelle et valide ?

Cette question m’a laissé silencieux un moment, car beaucoup de systèmes partent du principe que la sécurité ne peut venir que du sien. Une chaîne maintient ses propres validateurs, exécute son propre consensus, puis se fie à son état. Mais si, à l’avenir, de plus en plus de réseaux doivent partager leur sécurité, la véritable difficulté ne sera pas de savoir s’il y a du capital, mais plutôt comment transformer ce capital en preuves de sécurité que d’autres réseaux peuvent accepter.

Autrement dit, le staking ne fait que commencer : le plus important est de savoir qui prouve que la sécurité a bien eu lieu. En regardant $BABY , je trouve que le point le plus intéressant, c’est qu’il ne copie pas simplement la structure du PoS traditionnel : il décompose les responsabilités assumées par différents rôles. Le Delegator fournit le soutien économique, le Finality Provider participe à la confirmation de l’état, et la Consumer Chain utilise ces résultats de confirmation pour obtenir une sécurité supplémentaire. Le capital, l’exécution de la sécurité et la validation de l’état ne sont plus liés à un seul et même rôle.

Cela m’a fait penser à beaucoup de problèmes d’infrastructure : bien souvent, ce qui manque à un système, ce ne sont pas des ressources, mais la confiance entre les ressources. S’il n’existe aucun moyen de prouver que cette sécurité est réellement valide, ces ressources ne peuvent pas circuler de façon effective.

Ce que fait Babylon, c’est essentiellement établir ce type de connexion.

Le Checkpoint ne consiste pas seulement à enregistrer un état donné : il fournit entre différents réseaux un résultat de consensus qui peut être vérifié. Il ne résout pas un problème de transmission de données, mais plutôt la question de savoir comment un autre système peut reconnaître l’état sécurisé.

Donc, en y revenant maintenant, je pense que la plus grande valeur de Babylon n’est peut-être pas d’avoir créé un nouveau marché du Staking.

Il y a quelque temps, en discutant d’Internet avec des amis, j’ai soudain remarqué que @BabylonLabs_io a en fait de grandes similitudes avec ceci. D’abord, une question pour tout le monde : si on remontait aux débuts d’Internet, une équipe de startup qui voulait créer un site web, quel était le premier problème à résoudre ?

Le problème le plus concret devait être celui des serveurs. À l’époque, beaucoup d’entreprises devaient acheter leurs propres serveurs et entretenir leurs salles informatiques, car les infrastructures n’étaient pas encore abstraites. Ce n’est qu’après l’arrivée du cloud computing que les développeurs n’ont plus besoin de reconstruire toute l’infrastructure de base à partir de zéro.

Ce point ressemble un peu à ce que fait la blockchain aujourd’hui : pour de nombreux nouveaux réseaux PoS qui se lancent, en plus de développer l’application elle-même, il faut aussi résoudre la question de la sécurité—d’où elle vient, et comment elle est fournie.

Dans le passé, la plupart des chaînes créaient un système de validateurs via leur propre économie de tokens, où les participants mettent en jeu des actifs pour maintenir le réseau. Mais pour des projets en phase initiale, ce n’est pas facile. Sans suffisamment de valeur, il est difficile d’attirer des validateurs ; sans sécurité suffisante, il est difficile d’attirer des utilisateurs et un écosystème. En réalité, ce problème est aussi un peu comme celui des débuts d’Internet.

Baby propose un modèle de sécurité partagé, permettant aux nouveaux réseaux PoS de ne pas construire entièrement leur propre système de sécurité depuis zéro, mais plutôt de s’appuyer sur les capacités de sécurité fournies par #baby .

Et dans ce processus, $BABY met en relation le réseau qui a besoin de sécurité et les participants disposés à fournir cette sécurité. Grâce à des mécanismes comme les Finality Providers, il leur permet de participer aux processus de confirmation de différents réseaux, tandis que le réseau intégré n’a pas besoin de compter entièrement sur son propre système de validateurs pour établir la sécurité.

Cela m’amène à penser que Babylon ne fait pas simplement ajouter davantage de ressources de sécurité, mais modifie plutôt la manière dont les ressources de sécurité sont utilisées. Autrefois, chaque chaîne, comme une application de l’Internet naissant, devait résoudre elle-même les problèmes de couche de base. Mais si, à l’avenir, davantage de chaînes apparaissent, la sécurité ne restera peut-être pas toujours le modèle consistant à reconstruire à chaque fois, pour chaque chaîne, toute une nouvelle série de sécurité.

Bien sûr, pour savoir si cette direction peut vraiment fonctionner, il faudra du temps pour le vérifier. Car la sécurité n’est pas comme les ressources de calcul : elle touche au consensus, aux incitations économiques et aux comportements à long terme des participants, des sujets bien plus complexes que le cloud computing.

Peut-être que dans le futur, le développement des infrastructures blockchain ne se jouera pas seulement sur la performance et la taille de l’écosystème, mais aussi sur la capacité à rendre la sécurité, comme les ressources de calcul, plus facile à obtenir et à utiliser.

Récemment, en lisant des discussions sur le @BabylonLabs_io 社区, j’ai vu quelqu’un mentionner des sujets liés aux Finality Provider. Je me suis alors demandé : si, à l’avenir, de plus en plus de réseaux s’appuient sur Babylon pour assurer la sécurité, sur quoi s’appuieront ceux qui participent à la sécurité pour garantir qu’ils ne commettront pas de méfaits ?

Cette question est en fait assez intéressante. Quand on parle de sécurité partagée, la première réaction consiste généralement à regarder combien d’actifs entrent en jeu, combien de réseaux sont connectés, mais très peu de gens cherchent à comprendre : si un participant fait vraiment quelque chose de mal, comment le système le sait ? Et comment le sanctionner ?

Avant, les réseaux PoS géraient ce problème de manière relativement directe : les validateurs bloquaient leurs propres actifs ; en cas de double signature, la chaîne pouvait directement appliquer un Slash. Mais la situation à laquelle fait face Babylon n’est pas exactement la même. Les participants fournissent des capacités de sécurité supplémentaires, et le système doit donc se demander comment s’assurer que ces participants externes restent suffisamment contraints.

Mais il y a ici une différence : dans un PoS traditionnel, les validateurs et le réseau appartiennent au même système ; après une erreur, la chaîne peut gérer directement. En revanche, le $BABY fait face à un contexte différent : la personne qui fournit la sécurité ne fait pas partie de ces réseaux.

C’est précisément sur ce point que j’ai commencé à porter attention à l’EOTS. Quand un Finality Provider participe à une confirmation, il doit générer une signature à usage unique via l’EOTS. Si un participant tente de créer un état de conflit au même niveau, cette action laisse une preuve identifiable, qui déclenche ensuite une punition.

Je pense que l’EOTS n’agit pas vraiment en rendant les participants plus forts, mais en leur faisant comprendre que le fait de commettre un méfait laissera des traces.

C’est à ce moment-là aussi que j’ai réalisé que le problème que #baby cherche à résoudre n’est peut-être pas aussi simple. Beaucoup de projets, lorsqu’ils parlent de sécurité, mettent l’accent sur le montant des fonds impliqués. Mais ce qui détermine réellement si un système de sécurité peut fonctionner durablement, c’est : après qu’un participant a commis une erreur, le système a-t-il la capacité de le retrouver ?

En revenant à l’EOTS, je trouve intéressant non pas tant qu’il crée un nouveau type de signature, mais qu’il comble une étape dans le système de sécurité partagée qui peut facilement être négligée. À mesure que davantage de participants externes entrent dans le dispositif de sécurité du réseau, la manière de prouver qui respecte les règles et qui essaie de les violer pourrait devenir un problème clé dans la compétition entre infrastructures.

Bien sûr, il faudra du temps pour savoir si ce mécanisme pourra être validé sur le long terme.

Au début, quand j’ai regardé @BabylonLabs_io , je me suis surtout concentré sur le Staking. Après tout, la compréhension la plus intuitive de Babylon par le marché, c’est de faire en sorte que davantage d’actifs participent à la sécurité du réseau. Mais ensuite, j’ai réalisé que le plus intéressant, c’est justement pourquoi il fallait concevoir des Checkpoints.

Beaucoup de projets, quand ils font de l’interconnexion inter-chaînes ou connectent des écosystèmes, se focalisent généralement sur la façon dont les actifs sont transférés et sur la façon dont les messages sont transmis. Mais plus tard, j’ai découvert que le véritable problème n’est pas tant comment connecter les réseaux, mais plutôt : si l’état d’un réseau doit être reconnu par un autre réseau, sur quoi se baser pour prouver que cet événement a bien eu lieu ?

Ce problème est en fait plus difficile que la simple connexion. Dans le passé, beaucoup de solutions faisaient intervenir des rôles de vérification supplémentaires, en chargeant un certain système d’indiquer à tout le monde que cet état est réel. Mais une fois qu’on fait ça, un nouveau point de confiance apparaît forcément.

Et ce qui m’intéresse dans le Checkpoint de #baby , c’est qu’il n’a pas choisi d’ajouter encore une couche de vérification, mais qu’il a essayé de rendre l’état lui-même plus facile à confirmer. Dans ce processus, le Finality Provider participe à la confirmation de l’état, tandis que l’EOTS sert à contraindre le comportement des participants.

En réalité, c’est aussi ce que je trouve particulièrement spécial à $BABY : ce n’est pas simplement la création d’un nouveau mécanisme de staking, ni la mise en place d’un écosystème fermé. C’est plutôt une tentative de fournir une capacité de base qui puisse être utilisée par différents réseaux. En termes simples, ce n’est pas seulement une question de qui fournit la sécurité, mais aussi de la manière dont ce résultat de sécurité peut être vérifié.

C’est, selon moi, un enjeu très important pour l’environnement multi-chaînes à venir. À mesure que de plus en plus de réseaux commencent à se connecter entre eux, le vrai défi ne sera peut-être pas de leur permettre de communiquer, mais de leur permettre d’établir une confiance durable. Un réseau qui fonctionne correctement aujourd’hui ne signifie pas qu’il sera fiable à l’avenir. Les états passés et les enregistrements historiques doivent également être confirmés.

Bien sûr, il faudra du temps pour vérifier si cette direction peut réellement aboutir. Le point le plus difficile pour les projets d’infrastructure n’a jamais été de concevoir un mécanisme, mais plutôt de faire en sorte qu’assez de participants soient disposés à l’utiliser sur le long terme.

emm... Je pense que le point qui mérite le plus d’être remarqué, c’est qu’il ne cherche pas seulement à résoudre un problème unique : qui fournit la sécurité. Il essaie aussi de résoudre la question de la manière dont, à mesure que de plus en plus de réseaux commencent à se connecter, la confiance entre eux devrait être établie. C’est peut-être la direction que Babylon cherche vraiment à explorer.

Il y a quelque temps, lorsque j’ai vu les changements de données écologiques publiés par @BabylonLabs_io , je me suis toujours demandé pourquoi, aujourd’hui, beaucoup de nouveaux projets de chaîne ne rencontrent pas tant des difficultés au moment du développement, mais plutôt au moment du déploiement : comment établir rapidement une base de sécurité fiable et digne de confiance ?

Depuis le lancement de Babylon, de plus en plus de réseaux PoS commencent à s’intéresser au modèle de sécurité partagée. À ce jour, l’écosystème de Babylon a déjà connecté des dizaines de réseaux blockchain. La participation de BTC Staking continue également de croître, et de plus en plus d’actifs entrent sur ce marché de la sécurité.

Ce changement m’a paru intéressant.

Car par le passé, de nombreux projets se concentraient sur la façon d’attirer des utilisateurs et d’augmenter le TVL. Mais l’approche de Babylon pose une autre question : celle de la manière de réduire le coût de mise en place d’un système de sécurité pour un nouveau réseau.

Au début, en étudiant Babylon, je l’ai aussi compris comme un protocole de staking. Mais en approfondissant son mécanisme, j’ai découvert que ce qu’il cherche à résoudre n’est pas simplement d’ajouter un nouveau type de rendement, mais de modifier la voie par laquelle un nouveau réseau établit sa sécurité.

Les réseaux PoS traditionnels doivent former leurs validateurs, concevoir leurs propres incitations économiques, puis accumuler progressivement de la sécurité.

Babylon propose, lui, une autre solution : grâce à un mécanisme de sécurité partagée, un nouveau réseau peut accéder aux capacités de sécurité fournies par Babylon, sans avoir à construire de zéro un système de sécurité complet.

Parmi les éléments qui m’intéressent particulièrement, il y a la couche Finality Provider. Quand beaucoup de gens parlent de Babylon, ils mettent souvent l’accent sur le staking en tant que tel. Mais en réalité, ce qui fait transiter les capacités de sécurité entre différents réseaux, ce sont ces acteurs chargés de la finalité et de la vérification. Ce sont eux qui relient les actifs, les ressources de sécurité et les réseaux d’applications.

C’est aussi, selon moi, ce qui rend Babylon intéressant.

Il ne s’agit pas simplement de créer un nouveau scénario d’application, mais de redéfinir ce dont un réseau a besoin au moment de son démarrage.

Babylon explore l’idée que la sécurité elle-même peut devenir une sorte d’infrastructure. Bien sûr, reste à observer si, à l’avenir, le modèle de sécurité partagée pourra former un écosystème durable à long terme. Il faudra notamment examiner des points comme les mécanismes d’incitation de différents réseaux, la taille des participants et la soutenabilité à long terme.

À l’avenir, la compétition entre blockchains ne se résumera peut-être plus à savoir qui a le plus d’utilisateurs et de liquidités. Elle pourrait aussi opposer ceux qui parviennent à établir plus efficacement une base de confiance. C’est peut-être précisément l’orientation que Babylon cherche à explorer.
#baby $BABY

Beaucoup de gens pensent que le plus difficile à copier avec le BTC, c’est sa rareté, mais après les recherches récentes @BabylonLabs_io , j’ai réalisé que ce qui est vraiment difficile à remplacer, c’est le consensus de sécurité qui s’est formé au cours de plus de dix ans de fonctionnement.

C’est aussi la raison pour laquelle je me suis récemment intéressé à $BABY .

Honnêtement, au début, en voyant la direction du BTC Staking, je n’étais pas particulièrement excité. Ces dernières années, le marché a proposé de nombreuses options permettant de générer des rendements avec le BTC. Pourtant, dans l’essentiel, elles consistaient souvent à emballer le BTC sous forme de nouveaux produits financiers, en faisant porter aux utilisateurs des risques supplémentaires, sans pour autant libérer véritablement la valeur du Bitcoin lui-même.

Là où Babylon m’a fait changer d’avis, c’est qu’il ne cherche pas à savoir comment consommer la liquidité du BTC, mais comment exploiter les capacités de sécurité que Bitcoin a déjà construites.

L’idée centrale de #baby consiste à, grâce aux Trustless Bitcoin Vaults et au mécanisme de BTC Staking, permettre aux détenteurs de BTC de soutenir un réseau PoS tout en conservant le contrôle de leurs actifs.

En termes simples, Babylon ne demande pas aux utilisateurs de transférer leur BTC vers d’autres écosystèmes, ni de dépendre de structures centralisées qui le mettent en garde. L’objectif est plutôt d’utiliser les attributs natifs de sécurité de Bitcoin afin que le BTC devienne une base de sécurité permettant de relier d’autres réseaux blockchain.

Ce cap me semble intéressant, car il résout un problème de longue durée de l’écosystème PoS. De nombreuses blockchains émergentes ne manquent ni de technologie, ni de développeurs. En revanche, au stade initial, il est souvent difficile d’établir rapidement un dispositif de sécurité suffisamment solide. Le nombre de validateurs, la taille du staking et le coût économique influencent tous la capacité d’un réseau à résister aux attaques.

Et Bitcoin a déjà prouvé sa sécurité en plus de dix ans. Si, à l’avenir, cette capacité de sécurité pouvait être exploitée par davantage de réseaux PoS, le rôle du BTC pourrait alors évoluer.

Bien sûr, je ne pense pas simplement que $BABY réussira forcément. Dans l’histoire de la crypto, il ne manque jamais de grands récits. Au final, ce qui détermine la valeur d’un projet d’infrastructure, c’est surtout si la technologie est fiable, si le modèle de sécurité a été validé, et si l’écosystème l’adopte réellement.

Auparavant, quand nous comprenions le BTC, nous nous concentrions davantage sur sa rareté et son prix. Mais si, à l’avenir, les capacités de sécurité de Bitcoin peuvent servir davantage de réseaux, les limites de la valeur du BTC pourraient être redéfinies.

Peut-être que dans le futur, nous ne nous intéresserons pas seulement à Bitcoin parce qu’il est assez rare.

Est-ce que quelqu’un participe vraiment ? 1 point pour échanger 1u alpha, c’est tellement une perte, même les caleçons sont rincés, non ?

Parfois, je me rends compte qu’un jour où une entreprise est le plus susceptible de rencontrer des problèmes, ce n’est pas parce qu’il n’y a personne pour s’en occuper, mais plutôt parce que tout le monde en est un peu responsable. L’équipe produit pense que le développement a déjà confirmé. Le développement estime que l’exploitation a déjà approuvé. L’exploitation pense alors que le service juridique n’aura pas d’objection. Et quand finalement les choses tournent mal, chacun a participé, mais personne n’arrive à dire clairement à quel moment exact ça a dérapé.

Plus tard, en voyant @NewtonProtocol un très petit élément de conception, j’ai soudain pensé que je n’avais pas vraiment prêté attention à l’Authorization Receipt. Je croyais que c’était simplement un document généré après l’exécution, un peu comme des logs ou un reçu. À mes yeux, il servait surtout à archiver. Mais en continuant à regarder, je me suis rendu compte que sa position était assez étrange.

Il n’est pas placé à la fin du processus. Il se trouve aux côtés d’Authorization, de Policy et d’Operator, et fait partie du déroulement complet de l’exécution. Puis j’ai relu ce passage plusieurs fois, et j’ai enfin compris que ma compréhension initiale était décalée. Avant, beaucoup de systèmes sauvegardaient uniquement des résultats : la transaction a réussi, l’actif a été transféré, l’état a été mis à jour… tout cela laisse des traces. Mais quand il y a vraiment un problème, les gens continuent souvent à demander : qui a approuvé ? Sur quelle règle s’est-on appuyé ? Y a-t-il eu une étape sautée au milieu ? Dans beaucoup de cas, ces informations ne peuvent être reconstituées que petit à petit à partir des logs.

Newton semble justement résoudre ce problème. L’Authorization Receipt ne consigne pas seulement une exécution terminée. Il relie une autorisation donnée, la Policy correspondante, l’Operator qui l’a exécutée, puis le résultat final, en une chaîne complète. À l’avenir, si quelqu’un remet en question cette exécution, le système n’a pas besoin de refaire confiance à un nœud en particulier, ni de demander à la partie “exploitation”. Il suffit de remonter cette trace et de revalider à nouveau chaque étape : pourquoi elle est valable, et quelles preuves y correspondent.

En voyant cela, je me suis soudain rendu compte que, dans Newton, le Receipt n’est en fait pas un simple reçu. C’est plutôt une chaîne de responsabilité de l’exécution.

Donc, quand je regarde à nouveau l’Authorization Receipt, je pense que ce qu’il laisse derrière lui n’est pas une simple trace.
Ce qu’il laisse, c’est l’ensemble des preuves d’une exécution, depuis l’autorisation et le jugement jusqu’à l’achèvement. Et ce qui peut être cru durablement, peut-être, ce n’est jamais un nœud unique, ni une plateforme unique : c’est plutôt le processus lui-même, celui que n’importe qui peut vérifier à nouveau.
#newt $NEWT

Incroyable

Ces derniers temps, le mois dernier, je n’ai pas récupéré l’airdrop #ALPHA . Tout le monde est devenu aussi acharné comme ça ? Ce soir à 19h : airdrop en boîte surprise avec 251 points, c’est un peu délirant.

Ça me met mal à l’aise : un cycle ne permet de ne manger qu’une seule fois.

J’hésite un peu : faut-il attendre le nouveau projet de la semaine prochaine (#tge ) ou vaut-il mieux d’abord le récupérer ?

估计又要有一批人赚麻了

不出意外下周二会上新久违的TGE项目

这次的#tge 采用新的规则，热度不是一般的高

兄弟们都准备好了吗？

按照$GRVT Whales Market 盘前折算价，目前 FDV 大约落在 3.5 亿刀。接下来老规矩，咱用大白话简单拆解一下这个项目到底能不能打。

​从基本面看@grvt_io 确实解决了行业痛点，其首创的One Balance余额系统，让保证金不再是死钱，在交易开仓的同时还能无缝吃满底层最高11% 的自动生息收益。结合CEX 的速度 + DEX 的资产自托管的混血叙事，加之高盛和 Meta 的团队背景，长期的基本盘非常扎实。

但是最致命的黑天鹅也摆在明处，这次官方把社区空投的比例直接从 20% 一路死磕加码到了 28%！更要命的是TGE筹码当天不强制锁仓，这28％的天量筹码一旦瞬间砸向市场，对二级的承接力将是一场极度严苛的极限压力测试。

不过我个人觉得不至于是开盘即巅峰，毕竟它背后是zkSync生态航母级资源包，作为zkSync Hyperchain上的核心旗舰生态预期，GRVT不仅仅是一个交易所，它更加在底层充当着整个生态流动性中继和数据交割的重要节点。

如果开盘第一波泥石流抛压能被做市商消化，后面真实交易数据跑起来，那么它那套One Balance的飞轮效应就会开始展现威力。大资金和长线 LP 为了吃那 11% 的生息红利，会源源不断地从以太坊$ETH 主网倒灌资金进来，形成一个天然的吸金黑洞。

总的来说#grvt 机制不错，但 3.5 亿的盘前估值，短线大概率顶不住 28% 的天量空投踩踏，最好是等订单簿稳定、链上筹码洗得差不多了再进场，我的心里价位是在$0.2以下。

兄弟们觉得 $0.35 的盘前价能守住吗，你们的心理防线入场价是多少呢，不妨来聊聊

Ne te laisse plus avoir par les promesses extravagantes récentes de <c-1/>GRVT.

Cette chose n’est pas aussi favorable aux particuliers que tu pourrais le croire.

Ces derniers jours, j’ai synchronisé la documentation officielle associée à @grvt_io et j’ai fini par tomber, dans les structures de données de règlement, sur deux « venue » et « broker » dont presque personne ne parle. Après avoir retracé le chemin de compensation en profondeur, j’ai eu un frisson : tout le monde regarde comment les échanges acheteur/vendeur sont joués en surface, mais ignore totalement le fait qu’au niveau le plus bas, elle ouvre un RFQ de gré à gré aux gros acteurs et aux institutions. Les particuliers jouent avec les mêmes produits dérivés que les gros, mais ils doivent naturellement encaisser un coup de massue lié à un avantage informationnel.

J’ai remarqué qu’au sein du socle de #grvt , les opérations classiques d’achat/vente unidirectionnelles passent par un carnet d’ordres public. Mais dès qu’il est question de combinaisons d’options complexes ou de transactions par blocs d’une taille énorme, le système coupe directement ces gros flux vers des sessions d’interrogation RFQ dédiées, puis effectue un rapprochement privé hors chaîne via des courtiers de premier plan comme CoinRoutes.

Que signifie tout cela ?

Les meilleures cotations pour des blocs — celles qui permettent de réduire au minimum les coûts de couverture — ont déjà été « mangées » hors chaîne, en amont, par les institutions et les courtiers professionnels. Ce que les particuliers voient sur le carnet d’ordres public n’est en réalité que des résidus laissés. Si tu passes tout ton temps à essayer d’assortir acheteurs et vendeurs sur le carnet public, non seulement le spread acheteur-vendeur est plus large, mais tu dois aussi assumer le risque de « Legging » invisible, lié au fait que chaque jambe s’exécute séparément. Concevoir un verrouillage du pouvoir de tarification des blocs les plus juteux dans le cercle des courtiers revient, sans qu’on s’en rende compte, à ériger un mur invisible très haut pour le petit particulier.

Mais en mettant de côté cette isolation des cotations pour les particuliers, d’un point de vue macro de la résilience du système du marché, cette architecture qui sépare totalement les blocs des flux de détail est au contraire extrêmement intelligente. Les plateformes traditionnelles en chaîne connaissent, de temps en temps, des ruptures de liquidité, justement parce que les ordres dispersés des particuliers et les positions en blocs des institutions se retrouvent mélangés dans le même bassin. Dès qu’un marché se fait violemment « laver » (shake-out), si les positions multi-jambes à plusieurs millions des institutions sont contraintes de se dénouer directement sur le carnet public, cela déclenche instantanément une cascade de piétinements, explosant toutes les ordres stop-loss des particuliers. GRVT permet que les transactions de blocs empruntent un routage RFQ indépendant hors chaîne : en utilisant le mécanisme des courtiers comme zone tampon, elle neutralise discrètement, en dehors du terrain, ces têtes nucléaires destructrices.

Même si cela réduit un peu les opportunités de marges/arbitrages très lucratifs pour le détail, cela offre en échange une élasticité du carnet extrêmement stable à l’échelle de tout le marché, en pleine tempête : quand les particuliers doivent fuir, ils peuvent à tout moment retirer leurs ordres.

Vraiment, j’ai sous-estimé l’ambition de @NewtonProtocol . La nuit dernière, je suis allé(e) lire par moi-même quelques chapitres de sa “white paper” sur l’architecture cross-chain et la synchronisation de la puissance de calcul, et j’ai découvert le genre de manœuvre sulfureuse qu’il cache dans l’ombre : en réalité, son objectif est de supprimer la fragmentation des exigences de conformité qui rend le monde multi-chaînes si pénible, ainsi que la crise de confiance dans les ponts cross-chain.

La white paper de $NEWT mentionne un protocole de synchronisation “multi-chaîne” de table de puissance de calcul appelé “basé sur la spécification ELIP-008 de EigenLayer”. Le nom fait très “tech” et assez hardcore, n’est-ce pas ? À première vue, je pensais aussi qu’il s’agissait surtout de jargon. Mais en y réfléchissant un peu, je me rends compte que ça résout en fait un nœud extrêmement vicieux — et surtout, un nœud qui n’avait jamais été vraiment résolu auparavant — dans la finance on-chain : comment permettre aux applications de différentes chaînes de partager la même “carte maîtresse” de sécurité économique de niveau Ethereum, très robuste.

Tu vois, aujourd’hui le monde multi-chaînes est fortement fragmenté. Par exemple, si un stablecoin ou un projet RWA veut être émis à la fois sur Ethereum, Base, Arbitrum et Optimism, l’approche classique est extrêmement douloureuse. Soit tu dois trouver, pour chaque chaîne, un ensemble séparé de nœuds de vérification de conformité, soit tu dois utiliser ces ponts cross-chain tiers, extrêmement fragiles, qui te font passer tes journées à attendre anxieusement qu’un hacker fasse de l’empoisonnement cross-chain. Résultat : les grandes institutions n’osent tout simplement pas investir des montants colossaux sur les L2.

Avant, tout le monde considérait que c’était une tare “impossible à corriger”. Mais Newton a cette fois directement débloqué le problème à la base, via la cryptographie. Dans la logique de #newt , son réseau décentralisé de puissance de calcul n’a besoin de s’enregistrer sur le réseau principal Ethereum et d’être reproposé une seule fois dans EigenLayer. Dès que l’état — par exemple les membres des nœuds Ethereum, leurs pondérations de mise, ou les conditions de sanctions en cas de mauvaise conduite — évolue, les nœuds de Newton crachent collectivement, au niveau bas, une table de puissance de calcul “marquée” par une signature BLS, sous forme d’une racine Merkle.

La manœuvre la plus impressionnante, c’est que cette signature qui porte la garantie de sécurité économique de dizaines de milliards de nœuds du mainnet est ensuite synchronisée frénétiquement vers tous les principaux L2 via un Relayer totalement non autorisé (sans permission). Sur la chaîne cible, les smart contracts n’ont alors qu’à vérifier, avec de simples formules mathématiques, cette signature BLS agrégée : dès que la vérification de bilan passe, la table de pondération locale de la puissance de calcul se met à jour instantanément.

En gros, j’ai compris le flux de synchronisation cross-chain de la puissance de calcul basé sur ELIP-008. Ce projet ne raconte pas une histoire de conformité grandiose : il a réellement fourni une “performance cryptographique” impossible à copier par d’autres. Il transforme directement les rails de conformité multi-chaînes en un seul réseau de sécurité continu, sans couture.