Après avoir lu les documents de mise en gage de @Dusk , j’ai réalisé que le nom « Hyperstaking » est assez trompeur. Ce n’est pas censé amplifier à l’infini les rendements du gage de base, mais plutôt permettre aux contrats intelligents de détenir directement les positions de mise en gage, de réclamer les récompenses, puis de répartir ces gains selon les règles écrites dans le contrat. La différence ne réside pas dans la provenance des récompenses, mais dans la personne (ou plutôt le système) qui exécute ce processus à votre place.
Pour une mise en gage classique, il faut au moins 1000 DUSK, et il faut aussi que le provisioner soit en ligne pour synchroniser. Avec le Stake Abstraction, cette capacité est ouverte aux contrats : les fonds se rassemblent d’abord dans un pool, puis via le Transfer Contract on déclenche stake_from_contract ; lors du désengagement et de la récupération des gains, le Stake Contract renvoie ensuite à la logique de réception du pool. Les contrats doivent eux aussi respecter le seuil de 1000 DUSK et une période de maturité d’environ 4320 blocs.
Ce que cette approche ouvre réellement, ce sont des possibilités de composition. De petites mises peuvent se regrouper pour participer, le pool peut réinvestir automatiquement et répartir les récompenses au prorata, voire mettre en place de la mise en gage liquide. Avant, le staking était un acte individuel ; maintenant, on peut l’écrire comme une stratégie financière qui tourne en continu. C’est aussi ce qui fait que la demande de mise en gage de $DUSK ne concerne plus seulement les opérateurs de nœuds, mais s’étend aux contrats d’application.
Le protocole de base ne supprime pas la période d’attente du staking ; cela ne signifie pas que les utilisateurs du pool peuvent quitter quand ils veulent. Le pool peut tout à fait ajouter lui-même une file d’attente, des frais ou des limitations de liquidité. Plus important encore : l’utilisateur ne supporte plus seulement le risque lié au nœud hors ligne et aux pénalités ; il doit aussi assumer des éléments additionnels, comme le calcul des parts, le traitement des rappels (callbacks), la répartition des récompenses et les droits de mise à niveau du contrat. Un socle sans custody (non-dépôt) ne veut pas dire qu’il n’y a pas de contrôles en haut.
Hyperstaking remplace l’exigence d’exécuter un nœud par une exigence d’audit du contrat ; pour les utilisateurs ordinaires, cette dernière peut être plus difficile. Le taux de rendement affiché par le pool doit aussi être décomposé : ce qui relève des récompenses du protocole, ce qui correspond au prélèvement de l’opérateur, ce qui est une subvention… tout ne peut pas être imputé uniquement au consensus Dusk.
À partir de maintenant, je ne retiens que quelques indicateurs vérifiables : le contrat du pool a-t-il été audité et publié en open source, les actifs et les récompenses peuvent-ils être rapprochés on-chain (sur la blockchain), et les règles de sortie sont-elles clairement séparées de celles du protocole de base. Le vrai intérêt de la mise en gage « contractuelle » réside dans l’automatisation de la coopération ; si ce n’est que remplacer le custody du nœud par une boîte noire de smart contract, cela n’élimine pas la confiance, cela fait simplement apparaître une enveloppe plus « on-chain ». #dusk @Dusk $DUSK
中午睡得正香,手机突然连环震,我眯着眼把清算警报划掉,迷迷糊糊翻链上记录,突然想到个之前没细想的问题:TermMax 那套实物交付,真有大家吹得那么稳吗? FT 持有人最怕的是对手方跑路,实物交付确实给了个兜底——清算不足时按比例分抵押品给你,而不是甩张坏账凭证。这点我认,比那些只给空气承诺的强。但“按比例”这仨字,好多人直接理解成“我肯定能拿回一部分”,很少有人往下算这个比例到底怎么来的。
你想想,违约发生的时候,是同一个抵押池里所有 FT 持有人在排队分。你能分到多少,不取决于你当初多少钱买的、什么时候买的,而是取决于那一刻池子里有多少人跟你一起抢。池子越挤,你分到的就越薄。你以为的保护,其实是个会被别人稀释的份额,而且稀释程度事前根本看不见。这就像一群人分蛋糕,你只看得到蛋糕多大,却不知道今天来了多少人。
Il y a peu, j’ai loué moi-même un serveur cloud pour bidouiller et valider un nœud. Vers minuit, gros souci : le réseau a tremblé, et je me suis retrouvé déconnecté. Sur le moment, j’étais tellement paniqué que j’en transpirais à grosses gouttes, en mode dépannage en catastrophe. Après avoir payé ces frais d’apprentissage, j’ai fini par comprendre une vérité : aujourd’hui, dans le milieu, on discute beaucoup du mécanisme PoS, et on vante sans arrêt des montants de staking de plusieurs centaines de millions ou les rendements annuels… Mais au final, une blockchain peut-elle réellement “tenir la route”, ce n’est pas aussi simple que regarder combien d’argent est verrouillé. L’efficacité des communications au niveau des nœuds, et leur capacité d’auto-réparation quand le réseau tombe, voilà le socle qui décide de la vie ou de la mort.
C’est aussi pour ça que j’ai récemment passé beaucoup de temps à disséquer le livre blanc de @Dusk . Leur consensus basé sur « preuve succincte d’attestation (Succinct Attestation) » a vraiment une approche solide et plutôt “nerveuse”. Le cœur du système, c’est une logique de comité élitiste avec élection déterministe. En clair : à chaque tour, on choisit un petit groupe de producteurs de blocs et un comité de validation, puis, grâce à un coût de diffusion (broadcast) extrêmement faible, on verrouille directement les transactions.
Beaucoup de gens qui font des “shitcoins” peuvent ne pas trop se soucier de la « finalité », mais pour une blockchain comme Dusk, qui veut absolument manger la tarte RWA (actifs du monde réel) et la tarte du règlement de titres, ces trois mots sont la clé. Imagine : le règlement d’une obligation à plusieurs dizaines de millions d’euros entre institutions. Si la chaîne bifurque ou si des blocs sont annulés en rollback, c’est un désastre.
Mais en vieux renard de la guerre, on apprend toujours à rester prudent avec les projets :
Concentration du pouvoir du comité : regarder le nombre de nœuds sur tout le réseau ne sert à rien. L’important, c’est de voir si les adresses choisies pour le comité central sont suffisamment dispersées. Si toute la parole est captée par quelques gros détenteurs, alors la décentralisation n’est plus qu’un discours. Les seuils de staking en coulisse, et les mécanismes de slashing (punition/privation), doivent être assez sévères.
Test en situation avec Kadcast : ils ont certes mis en place le protocole Kadcast pour faire de la diffusion ciblée, en promettant de concilier vitesse de transmission et confidentialité des nœuds. Mais est-ce que des données “parfaites” en laboratoire suffisent à encaisser les bombardements de trafic réels lors des pics du réseau principal ? Là encore, il faut rester sceptique.
J’ai toujours pensé que, dans une infrastructure financière vraiment fiable, l’essentiel n’est pas d’exiger que chaque machine ne tombe jamais en panne, mais plutôt d’être capable de « tolérer une coupure partielle » tout en gardant le grand livre aussi stable qu’une montagne.
Quand vous choisissez une blockchain au quotidien, vous accordez plus d’importance à la vitesse des benchmarks, ou comme moi vous privilégiez la finalité qui résiste aux risques ? Discutons-en ensemble dans les commentaires !
Hier soir, en dépouillant en parallèle les logs d’erreurs des nœuds RPC, j’ai aussi ressorti les enregistrements on-chain de l’incident de sécurité du pont inter-chaînes survenu mi-janvier (@Dusk ) pour en faire la reconstitution. J’ai l’habitude, dans le trading de crypto et l’interaction, de suivre une règle : « sauver sa vie d’abord ». Dès qu’il y a le moindre bruit, ma réaction instinctive est de ne jamais me fier aux rumeurs : il faut impérativement aller fouiller le code et les flux on-chain pour trouver la vérité.
À l’époque, beaucoup étaient complètement paniqués, pensant que le protocole sous-jacent de Dusk s’était effondré. Mais j’ai vérifié la trace on-chain : il faut d’abord dire quelque chose d’objectif pour sa couche de consensus. Le consensus DuskDS sous-jacent n’a pas été percé, et le code du protocole central ne présentait pas de bug. Ce que les hackers ont vraiment malmené, c’est le portefeuille de signature du service de pont qui connecte la chaîne EVM. En clair : ce n’est pas le protocole qui a une fuite, c’est le « gardien » en charge de la clé privée—lequel s’est fait voler.
Lors de la reconstitution de la transaction de la nuit, les actions de l’attaquant ont commencé à 21:28. Plus de 2,7 millions, 1,9 million et 8 millions ($DUSK ) ont été vidés un à un, coup par coup, jusqu’à ce qu’à peu près deux heures plus tard l’équipe coupe d’urgence les accès. La dernière transaction, avec 8,91 millions d’unités, a finalement été bloquée de façon ferme. Entre-temps, une partie des fonds a été blanchie vers la BSC.
Cette affaire m’a profondément marqué. En temps normal, quand on écrit nos propres contrats Solidity ou quand on conçoit une architecture, on croit souvent aveuglément à la soi-disant « modularité et découplage » : séparer clairement consensus, règlement et exécution, avec l’impression que tout est extrêmement solide. Mais la réalité est cruelle : plus on découpe finement les composants d’un système, plus on multiplie les « jonctions » exposées à l’extérieur. Pour aller vite et intégrer le tout de façon légère, le projet a concentré les autorisations de signature sur un chemin unique, forcément fragile. Ainsi, les murs construits dans la chaîne via ZKP (preuves de connaissance zéro) et une finalité déterministe sont restés intacts, solides comme du roc—mais, à l’extérieur, le portefeuille de signature inter-chaînes n’a tenu qu’une seule attaque.
Donc, aujourd’hui, quand j’observe un projet, je ne me fie plus à l’idée que « le consensus est forcément ultra-robuste ». Dès que des actifs sortent de la couche de règlement native, ces ponts périphériques et portefeuilles de signature, à la première occasion, peuvent ramener la décentralisation dans un bourbier de confiance humaine fragile. Ce sont souvent ces faiblesses de sécurité aux frontières qui constituent le vrai danger le plus mortel.
Les gars, selon vous, pour ce pont inter-chaînes à risque de point unique d’une blockchain modulaire, existe-t-il une solution au niveau du code ?
Déballer le récit de « Confiance sans nécessité » de Babylon : une affaire de multisignature d’alliance vêtue d’un vernis de cryptographie Ne vous laissez pas intoxiquer par cette mise en scène de « Trustless ». Les histoires de ponts inter-chaînes qui explosent et de multisigs qui s’enfuient, ça fait déjà longtemps que c’est rôdé dans le milieu crypto. Aujourd’hui, le BTC mis en gage de Babylon n’est rien d’autre qu’une vieille bouteille remplie d’un nouvel élixir. En creusant son architecture sous-jacente et la logique des scripts, on découvre que ce prétendu mécanisme décentralisé ne tient tout simplement pas face à une vérification en situation réelle. La fausse souveraineté d’actifs contrôlée par le « Covenant Committee » Babylon proclame haut et fort que les utilisateurs ont un contrôle absolu sur le BTC, mais si l’on démonte ses voies de Slashing, on constate que l’exécution fondamentale ne peut pas contourner le « Covenant Committee ». Que ce soit pour libérer les fonds ou déclencher un Slashing, il faut réunir la signature seuil correspondant à ce comité. Comparé à la conservation institutionnelle « en clair » de la WBTC, Babylon ne fait que conditionner une « alliance multisig de niveau supérieur » à l’aide de l’arbre Taproot et des signatures Schnorr. Tant que les artères de l’actif restent entre les mains de l’état serveur d’un petit nombre de nœuds de validation, de quelle « auto-conservation de la clé privée » peut-on encore parler ? Dès que ces nœuds font l’objet d’une attaque ciblée ou d’une panne collective, les preuves de mise en gage en BTC des utilisateurs se transforment en créances irrécouvrables. Impasse d’un jeu économique de preuves de fraude BitVM3 Examinons ensuite le TBV (Trustless Bitcoin Vault) que les officiels mettent chaudement en avant. Son socle repose sur des calculs hors-chaîne et des preuves de fraude en chaîne : on dirait une réplique, sur le BTC, de l’Optimistic Rollup d’Ethereum. Mais le réseau Bitcoin ne dispose pas d’une infrastructure de vérification à faible coût ; pendant la longue fenêtre de contestation, si aucun « Challenger » ne débourse des frais de mineur élevés pour soumettre une preuve de fraude, le réseau présume simplement la transaction valide. Dans l’environnement de Gas actuel, où l’on parle souvent de plusieurs centaines de satoshis, qui va jouer le rôle du « crieur » payé pour produire un bénéfice négatif ? En essence, cette logique est un jeu économique fragile, pas une sécurité absolue au sens mathématique. Si les gains de la malveillance dépassent largement le coût de la contestation, l’ensemble du système risque fortement de basculer dans un état « nu », sans surveillance, faute de supervision. Interaction inhumaine et trou noir des responsabilités Du point de vue pratique, le flux entier relève presque de la catastrophe : la mise en gage, la libération (解绑) et le Slashing exigent une série d’opérations de pré-signature longues et complexes. Cette pile de scripts inhumaine n’effraie pas seulement les particuliers ; surtout, elle transforme la malveillance centralisée, visible, en une « vacuité de responsabilité » invisible et difficilement attribuable. Une architecture complexe n’a pas supprimé le risque ; au contraire, elle a considérablement relevé le seuil de reproche et d’imputation une fois que les problèmes surviennent.