wz爱喝牛奶

我看 TermMax V2 的 Smart Unwind 时，第一反应是：借款都还没到期，为什么还要提前给自己设置一个“退出价格”？

后来把资金路径拆开，我才发现这里解决的其实不是还款，而是**被固定期限卡住的流动性**。

TermMax 原来的固定期限借款有个天然问题：借出去的资产可能一路锁到 maturity。V2 的 Smart Unwind 则允许借款人在开仓时设置目标 APR 或价格条件，条件满足后，新的借款人或套利者可以接手原来的仓位，资金重新回到借贷池。

> 固定期限没有被取消，只是协议给仓位增加了一扇提前换手的门。

站在借款人角度，这个设计很有意思。

我原本锁了一笔固定融资。

如果市场后来按我的预期变化，继续抱着这笔仓位反而可能浪费机会。

Smart Unwind 让我提前设一个退出条件，达标就让别人接手。

我拿到预期收益，新的参与者拿到他认为还有价值的仓位，原本被锁住的资金也重新进入市场。

但代价同样明显。

你设置的退出条件不是保证成交。

市场没有人愿意接，你还是得继续扛到下一步。

所以 TermMax 真正解决的不是“固定期限太死”，而是让**固定期限里的仓位也有机会重新定价、重新换手**。

我觉得这才是 V2 真正有意思的地方。

你会愿意为了提前锁定一个退出目标，把自己的仓位交给市场重新接手，还是宁愿拿着固定融资一直到期，少折腾但也少一次主动退出的机会？@TermMax

#termmax

我最近看 Dusk 的金融市场工作流时，真正让我警觉的是一个很传统、但上链后反而更难的问题：

**证券已经转给你了，钱却还没真正到卖方手里，怎么办？**

普通链上交易很容易把“资产转移”和“付款”看成两笔独立交易。

但金融市场不是这么玩的。

Dusk 的官方市场基础设施设计把 asset leg 和 payment leg 放在同一个结算问题里，强调受监管资产交易需要可预测地协调两条腿，而不是让一边先完成、另一边慢慢补。

> 我觉得这里真正重要的不是“结算更快”，而是别让交易双方先后暴露在对方违约的时间差里。

站在卖方角度，我当然希望资产转出去的同时，付款也已经确定。

买方也一样。

谁都不想先把自己的东西交出去，再祈祷另一边的钱按时出现。

这就是 DvP 这类结算逻辑存在的意义：

资产腿和付款腿必须一起考虑。

但代价也很明显。

系统不能只优化其中一笔转账，而要同时处理资产、付款、参与者资格和最终结算状态。

流程更复杂。

规则也更多。

可对于证券、基金或者其他真实金融资产，我反而觉得这种复杂是躲不掉的。

因为传统金融最麻烦的地方，从来不是“资产怎么转”，而是：

**谁先交，谁先付，什么时候双方都算真正完成。**

如果你是机构交易员，你会接受多一套结算规则，换取双方同时完成交割；还是宁愿保留普通链上那种“资产和付款各自处理”的简单流程？@Dusk

#dusk $DUSK

我最近看 TermMax 的到期机制时，反而卡在一个很现实的问题上：既然借款利率和期限都提前定死了，为什么协议还要给借款人设计 Roll 的出口？

按固定期限借款的直觉，到了 maturity 就还钱，事情结束。

可现实里最麻烦的恰恰是这一天。

本金可能还在抵押资产里。

仓位也没有坏。

只是你手上的现金，刚好没准备好。

TermMax 的固定期限设计天然存在这个“到期悬崖”：借款人到期要么一次性偿还，要么寻找新的融资来源。官方和 Morpho 的集成方案，就是把再融资这条路提前接进来，让借款人在接近到期时可以退出原来的固定利率头寸，再寻找新的资金来源。

> 我觉得这里真正需要管理的，不是利率，而是“时间到了以后，谁来给本金续命”。

这对借款人很重要。

因为固定利率给了你可预测的成本，却没有自动保证你到期那一天刚好有足够现金。

所以 TermMax 这里出现了一个很有意思的取舍：

固定期限让融资计划更清楚。

但期限越明确，到期日也越像一道硬门槛。

提前准备好再融资，仓位可以继续运转。

没准备好，就可能被迫退出原来的融资结构。

我现在反而觉得，固定利率真正难的部分不是“锁住利率”，而是**怎么安全地走出这笔期限交易**。

如果你是借款人，你更愿意接受一个利率稍高、但可以灵活续上的融资方案，还是宁愿锁住更低的固定成本，自己承担到期前找下一笔钱的压力？@TermMax

#termmax

我最近看 Dusk 的受监管资产设计时，真正让我停下来的是一个很小的区别：为什么“这个钱包能签交易”，还不能直接等于“这个钱包有资格买这项资产”？

普通代币逻辑很简单。

有余额。

有签名。

交易就走。

但如果换成证券类资产，这套逻辑马上不够用了。Dusk 当前文档把 eligibility、身份、wallet binding 和 access control 单独放进资产工作流里。也就是说，链上要判断的不只是“谁在发起交易”，还包括“这个参与者是否符合这项资产的持有条件”。

> 我觉得这里真正被拆开的，是“控制钱包”和“拥有资格”这两件事。

站在投资者角度，这意味着一个地址即使掌握私钥，也不代表它天然可以接收所有受监管资产。

站在发行方角度，这反而是必要的。

因为证券上链以后，最怕的不是没人交易，而是资产被转给一个本来就不应该进入这个市场的地址。

Dusk 的 Citadel 作为身份与访问层，就是在处理这条边界，让资格和链上账户之间建立关系，同时又支持只披露必要的信息，而不是把整套身份资料摊在公网上。

代价也很明显。

普通代币只要钱包和签名没问题就能转。

受监管资产却多了一层资格判断。

体验没那么“无脑”。

但这恰恰可能是金融资产真正上链后逃不开的一笔账：

**开放的地址，不等于开放的资产资格。**

如果你是资产发行方，你会接受多一层身份和资格限制，换取资产真正进入合规市场；还是宁愿保持普通代币那种“谁有钱包，谁就能接”的简单规则？@Dusk

#dusk $DUSK

我看到 TermMax V2 有个设计，第一反应其实挺矛盾：一个主打“固定利率”的协议，为什么还要把没借出去的钱放进 Aave、Morpho、Venus 这种浮动利率市场？

按直觉，既然都来 TermMax 了，不应该把资金老老实实锁在固定收益里吗？

我把资金路径重新拆了一遍，才发现这其实是在解决一个很现实的 LP 问题。

固定利率订单最怕什么？

不是收益低。

而是**钱挂着，没人借。**

TermMax 的 Composable Base Yield 做的事情，就是让还没被匹配的资金先去底层收益协议产生基础收益，等固定利率订单真正成交，再回到 TermMax 的固定收益逻辑里。官方目前明确把 Aave、Morpho、Venus 作为这类底层收益来源。

> 我觉得这个设计真正解决的不是“收益更高”，而是把“等待成交”这段原本可能浪费掉的时间也拿来利用。

站在 LP 角度就很直观：

钱已经准备好了。

但借款人没出现。

如果只能干等，资本利用率天然被拖低。

TermMax 反过来把这段空档接到浮动收益市场上。

不过代价也很明确。

你追求固定收益，却不得不接受一部分资金在等待期间暴露于底层浮动利率和协议风险。

也就是说，TermMax 并没有消灭浮动利率，只是把它从“借款成本”挪成了“闲置资本的等待收益”。

这点我觉得比“固定利率”四个字本身有意思得多。

真正的问题变成：

**一个固定收益协议，到底该不该为了提高资金利用率，主动拥抱一点浮动收益风险？**

如果你是 LP，你会宁愿让资金躺着等固定订单，还是接受底层浮动收益，换取这段等待时间也不吃空窗期？@TermMax

#termmax

Quand j’ai étudié cette fois-ci les règles de transfert d’actifs de Dusk, je me suis plutôt attardé sur une action assez peu spectaculaire : pourquoi fait-elle d’abord des vérifications et une simulation avant de soumettre la transaction ?

Auparavant, en regardant des transferts sur la blockchain, j’étais habitué au schéma suivant : signer, envoyer, puis attendre le résultat.

Mais avec des actifs réglementés, ce n’est pas comme ça.

Un investisseur peut avoir un solde, mais ne pas avoir le droit de détenir un certain type d’actif ; une adresse peut aussi être en mesure de recevoir des paiements, mais les règles actuelles ne lui permettent pas de recevoir cet actif. Le design officiel de Dusk intègre ce genre de notion d’éligibilité et de vérification du transfert à l’avance dans le processus : la transaction peut être vérifiée ou simulée avant d’être soumise officiellement.

> À mon avis, ce que cette étape résout vraiment, ce n’est pas seulement les quatre mots « la transaction échoue », mais surtout d’éviter qu’une erreur d’opération ne devienne un fait déjà inscrit sur la blockchain.

Du point de vue de l’émetteur ou d’une place de marché, la différence est énorme.

La logique classique sur la blockchain ressemble plutôt à :

D’abord soumettre.

En cas d’échec, on s’en occupe après.

Ce que Dusk veut faire, c’est :

D’abord vérifier.

Si ce n’est pas conforme aux règles, autant que possible empêcher la soumission avant.

Bien sûr, cela ajoute une couche de logique de contrôle, et le transfert d’actifs ne se limite plus, comme pour les jetons ordinaires, à vérifier le solde et la signature.

Mais en échange, on intègre en avance, dans le flux on-chain, nombre de décisions de conformité qui devaient autrement être rattrapées par une intervention manuelle en back-office.

Je pense que c’est ça, le vrai côté intéressant de Dusk.

Ce n’est pas seulement « mettre » des titres sur la blockchain : c’est tenter de faire en sorte que « qui peut transférer, qui peut recevoir, et dans quels cas il faut refuser » devienne lui-même une partie des règles de fonctionnement de l’actif.

Si vous êtes l’émetteur, accepteriez-vous plutôt de faire une étape de vérification supplémentaire en amont, ou préféreriez-vous garder un processus simple à la manière des jetons ordinaires — transférer d’abord puis gérer les exceptions ?@Dusk

#dusk $DUSK

我这次看 TermMax V2 的 Atomic Order，第一反应其实有点不舒服：同一笔 USDC 为什么可以同时挂在多个市场？这看起来像是在凭空把流动性放大了。

继续往机制里看，关键恰恰不在“同时出现”，而在**成交以后怎么消失**。

TermMax 的 Atomic Order 允许同一笔流动性同时服务多个市场。假设一个 Vault 有一笔资金，它可以同时出现在不同借贷市场里，但这笔钱实际上只能被成交一次。某个市场先吃掉其中一部分后，对应的其他市场额度会在同一交易中同步撤掉。官方把这套逻辑设计成原子操作。

> 真正有价值的不是把一笔钱“看起来变多”，而是协议敢让多个市场共享同一笔钱，却不允许它被重复花掉。

站在借款人的角度，这解决的是大额订单。

以前流动性被拆在不同市场里，大单很容易遇到单市场深度不够的问题。现在协议可以先把多个市场的可用流动性放进同一套执行逻辑，再由一次成交决定资金到底被哪个市场拿走。

但代价也很直接。

用户看到的账面流动性，并不代表每个市场都拥有一份独立资金。你看到的深度，本质上是**共享池里的可竞争额度**。

这就要求协议的原子同步必须真的可靠。

否则“多市场共享”不是资本效率，而是假流动性。

我觉得这是 TermMax V2 一个很容易被忽略的设计：它没有简单增加资金，而是在重新定义“市场深度”到底属于谁。

如果你是大额借款人，你更愿意面对一个看起来更深、但资金共享的订单簿，还是一个深度更小、但每个市场资金完全独立的市场？@TermMax

#termmax

我这次看 Dusk 的交易生命周期时，真正让我停下来的，是它没有把“确认”和“最终完成”当成一回事。

官方文档把一笔交易拆得很清楚：先从 mempool 移除，再进入 confirmed，最后 block 达到 finality，交易才变成不可逆的最终状态。

乍看像是多做了一层状态。

但站在金融资产结算的人角度，这个区别其实很要命。

普通转账里，看到 confirmed，很多人可能就继续下一步了。

但证券、支付或者资产交割不一样。

你真正需要确认的不是：

“这笔交易大概率没问题。”

而是：

“这笔资产现在到底能不能当成最终结果记账？”

> 对金融市场来说，“大概率不会回滚”和“已经不可逆”不是一回事。

Dusk 的设计把这两个阶段拆开，就是把“先看到结果”和“结果已经锁死”分开处理。

这会带来一个很现实的成本。

等待 finality，意味着应用不能只盯着第一条确认状态就立刻把后续流程全部推进。

但换来的，是更明确的结算边界。

对于普通链上转账，这点差异可能没那么刺眼。

对于代币化证券、支付腿和资产腿同时推进的交易，结算边界一旦模糊，后面的交割、记录和权限判断都会跟着乱。

所以我现在越来越觉得，Dusk强调 deterministic settlement，不只是为了“快”。

它更在乎：

**什么时候可以真正把这笔交易从“发生了”变成“已经定了”。**

如果你是金融机构的后台，你会更在意几乎立刻看到成交，还是宁愿多等一个明确的 finality，再把整笔资产正式记入账？@Dusk

#dusk $DUSK

我这两天看 TermMax 的 Vault 设计时，反而被一个看起来很“反用户”的决定吸引住了：明明固定利率市场已经把收益和期限写得很清楚，为什么还要让用户把钱交给 Curator 管？

按我的理解，最直觉的玩法应该是自己挑市场、自己看期限、自己买入 FT，然后等到期。

TermMax V2 的 Vault 却走了另一条路：用户把资产存进去，资金再由 Curator 按策略分配到多个固定期限借贷市场。官方目前还给 Vault 设置容量上限，让单一市场不会无限吸走资金。

> 这其实是在拿一部分“我自己决定”的权利，换更低的操作成本。

站在存款人的角度，我少做很多筛选。

不用每天盯不同到期日。

不用自己比较多个固定利率。

也不用每次市场变化都重新调仓。

但代价同样明显：

你的判断权交出去了。

Curator 配错市场，或者策略本身不适合当前利率环境，最终承担结果的还是存款人。

所以我觉得 TermMax Vault 真正卖的不是“省事”，而是**把选市场这件苦差事专业化**。

这和传统 DeFi 最大的区别就在这里。

以前：

钱交给协议，策略自己做。

现在：

钱交给 Vault，策略由 Curator 做。

而 TermMax 真正要证明的，也就变成了另一件事：

Curator 创造的收益，能不能长期覆盖用户放弃自主决策后承担的那部分风险？

如果是你，你更愿意自己挑固定利率市场，还是宁愿把选择权交给 Curator，换一个更省事的固定收益入口？@TermMax

#termmax

Lorsque j’ai consulté la documentation de développement de Dusk, ce n’est pas la fonctionnalité de confidentialité qui m’a vraiment fait m’arrêter, mais plutôt la raison pour laquelle ils ne se contentent pas de faire un simple EVM.

Désormais, Dusk conserve à la fois DuskVM et DuskEVM : le premier s’exécute directement sur Dusk L1 et s’adresse aux contrats Rust/WASM ; le second fournit Solidity, Vyper et une chaîne d’outils EVM familière. La réponse officielle aux développeurs est en réalité très simple : ces deux voies ne résolvent pas le même problème.

> Cela ressemble à une redondance, mais en réalité, on échange de la « commodité de développement » contre des « capacités natives ».

Du point de vue d’un développeur EVM classique, DuskEVM est nettement plus pratique. Le portefeuille, le langage et l’outillage sont plus familiers, le coût de migration est plus faible, et l’équipe n’a pas besoin d’apprendre une toute nouvelle manière de développer, totalement étrangère.

Mais si l’application doit interagir directement avec les actifs natifs de Dusk, ses capacités de confidentialité, sa logique de zéro-connaissance, ou encore s’intégrer davantage à l’environnement d’exécution proche de L1, alors DuskVM a aussi sa raison d’exister. La documentation officielle distingue clairement ces deux parcours, au lieu d’imposer de force que toutes les applications suivent la même voie.

Le problème est là.

Deux environnements d’exécution impliquent une complexité plus élevée pour le développement et la maintenance, et les outils de l’écosystème ne peuvent pas être totalement unifiés.

Mais si l’objectif se limite à la compatibilité EVM, Dusk risque aussi de verrouiller ses capacités les plus particulières dans un cadre d’exécution générique.

Je me dis de plus en plus que le vrai pari de Dusk n’est pas « est-ce que je dois être compatible avec Ethereum », mais plutôt :

**Est-ce qu’on peut faire en sorte que les développeurs entrent d’abord avec des outils et habitudes familiers, puis, lorsqu’ils auront vraiment besoin des capacités natives, accepter d’emprunter une autre voie ?**

Si vous êtes développeur, choisiriez-vous un EVM plus familier pour un lancement rapide, ou accepteriez-vous, pour la confidentialité et les capacités natives, de supporter le coût d’apprentissage d’un nouvel environnement d’exécution ? @Dusk

#dusk $DUSK

我这次看 Dusk 节点质押时，真正停下来的不是最低质押门槛，而是它为什么要把一笔 Staking 的钥匙拆成两种：Consensus Key 负责节点参与共识，Owner Key 负责解除质押和提取资金。

乍看很麻烦。

一把钥匙不就够了吗？

但站在节点运营者的位置，这其实是在处理一个很现实的问题：**“让机器能签块”，和“让资金能被拿走”，根本不该是同一件事。**

> 节点天天在线，热密钥要持续工作；质押资产却没必要跟着一起暴露。

如果共识密钥和资产控制权绑死，节点机器一旦成为攻击入口，风险就不只是“节点掉线”这么简单，资金控制权也可能被一起拖进去。

Dusk 的拆分思路很直接：

Consensus Key 管运行。

Owner Key 管资产。

机器负责干活，资金控制权留给另一套权限。

这套设计当然不是白赚的。

钥匙拆开后，节点运维更复杂，备份、恢复、权限管理都要多一道流程。对于小型节点来说，这甚至可能变成新的操作负担。

但我觉得这正是基础设施和普通钱包最大的区别。

普通用户最怕记不住助记词。

节点运营者更怕的是：

**一台长期在线的机器，顺手把自己的资金也变成在线资产。**

所以我现在更关注一个问题：

你会愿意为了少一道操作，把“签块权”和“提款权”绑在一起，还是宁愿多一点运维麻烦，也把机器和资金彻底隔开？@Dusk

#dusk $DUSK

Dusk 的节点，不靠算力靠抵押
聊 Dusk 的人都在说隐私，但很少人看它节点怎么跑。

我查了一下，它不做 PoW，也不走普通 PoS，而是用抵押加抽签的方式选验证者。DUSK 不押进去，节点身份都没有。押进去之后，出块权靠随机，不是谁钱多谁说了算。

这背后有个挺别扭的设计：你要帮全网验证交易，但你手里跑的那些交易，很多都是加密的。也就是说，作为验证者，你得确认一批你自己也看不清完整内容的交易合法。做不到？系统用零知识证明来补，验证者只需要确认证明成立，不需要看懂全貌。

但这件事的成本，最后压在质押的人身上。节点要稳定在线，要跑 Rusk 这套虚拟机，硬件和运维不便宜。出块奖励能否覆盖，官方文档里没有写死一个保证收益，这比多数 PoS 链更冷。

有意思的是，普通用户质押 DUSK，收益不是靠“参与治理”，而是你的币被系统当成安全垫。网络越需要隐私验证，对节点的要求就越高，要求越高，愿意跑节点的人越少。那收益从哪来？早期靠通胀，长期得靠网络的手续费。手续费上不来，节点会走。

我原本以为 Dusk 节点和别的链差不多，看完机制才发现，它把隐私成本转成了验证成本，又把这成本转给了质押者。

所以问题来了：你愿意拿着 DUSK 去质押，赚一份说不清的收益，同时替全网隐私交易扛成本吗？

还是说，宁可拿着币什么都不干，也不让自己成为那个“不知道在验什么却要负责”的人？@Dusk

#dusk $DUSK

Votre confidentialité, les interrupteurs ne sont pas entre vos mains
Acheter des pièces de confidentialité, c’est souvent chercher un “moyen d’échapper à toute traçabilité”. Mais dans le contrat XSC de Dusk, l’émetteur peut laisser une clé à l’auditeur. Cela ressemble à une porte dérobée, mais en réalité, c’est noir sur blanc dans la “divulgation de conformité” prévue par la conception.

Au départ, je pensais que la finalité d’une blockchain de confidentialité était une anonymisation totale. Puis en relisant la documentation de Dusk, j’ai vu que la norme XSC autorise l’émetteur des actifs à définir un “rôle d’audit” : seul ce rôle, lorsqu’un ensemble de conditions spécifiques est déclenché, peut consulter les détails des transactions. Ce n’est pas donné à n’importe qui de voir, mais ce n’est pas non plus à vous de refuser.

Qu’est-ce que cela implique ? La confidentialité de vos transactions n’est pas sous votre contrôle, mais entre les mains de l’émetteur et de l’auditeur. Vous détenez les pièces, mais l’interrupteur “qui a le droit de consulter votre registre” n’est pas accessible.

Pourquoi le concevoir ainsi ? Parce que les actifs financiers doivent être mis en chaîne : les institutions doivent passer par la procédure KYC/AML, et la réglementation doit pouvoir vérifier les comptes. Une blockchain totalement anonyme, les institutions n’oseraient pas y entrer, et les échanges pourraient aussi la retirer.

Dusk parie donc ceci : en échange d’une partie de la confidentialité des utilisateurs, offrir un chemin de survie conforme aux actifs.

Le coût est clair : les détenteurs renoncent à la “confidentialité absolue” pour obtenir un canal potentiellement accepté par le courant principal. Le gain, c’est que les actifs sur DUSK ne seront pas considérés comme des outils pour activités illégales, et le risque de retrait est moindre. Le risque, lui, c’est que si le rôle d’audit est détourné, ou si les règles changent, vous disposez de très peu de marge de négociation.

Maintenant, ce choix s’offre à vous : acceptez-vous de céder une partie du contrôle de la confidentialité, pour que les actifs restent sur la table ; ou préférez-vous l’anonymat total, même si cette chaîne finit par être isolée ?

Je ne choisis pas à votre place, mais je me poserai cette question : si l’interrupteur de confidentialité de mon portefeuille est entre les mains de quelqu’un d’autre, est-ce que je pourrai encore dormir tranquille ?
@Dusk

#dusk $DUSK

Je relis ces deux derniers jours le modèle de transactions de Dusk, et je me suis fait bloquer par un design assez contre-intuitif : pourquoi ne pas tout simplement faire en sorte que toutes les transactions soient privées ?

La réponse est en fait très réaliste.

Dusk a aujourd’hui décomposé la circulation des actifs natifs en deux modèles : Moonlight et Phoenix. Dans Moonlight, les comptes, les soldes, l’expéditeur et le destinataire sont publics ; avec Phoenix, les fonds sont placés dans un Note chiffrée : une preuve à divulgation nulle de connaissance vérifie la transaction, tout en cachant le montant et les liens entre transactions. Et au besoin, il est possible de procéder à une divulgation sélective via une « viewing key ».

> Ce n’est pas une question de « la confidentialité est-elle assez forte ». C’est plutôt que, dans les marchés financiers, certaines informations ne peuvent tout simplement pas être cachées indéfiniment.

Les virements classiques et certains scénarios de gestion partielle des fonds doivent être vérifiables.

Les transactions institutionnelles : ces acteurs ne veulent pas non plus exposer directement leurs positions et leurs montants sur la chaîne.

Les audits de conformité : ils ne peuvent pas non plus accepter « qu’on ne voie rien du tout ».

C’est pourquoi Dusk n’a pas choisi la voie d’une « anonymisation totale » ; elle a mis la **comptabilité publique et la comptabilité privée dans le même réseau sous-jacent**.

Le plus intéressant, à mon avis, est justement le compromis.

Tout rendre public : audit simple, mais les institutions ne veulent pas exposer entièrement la circulation d’actifs sensibles.

Tout garder privé : les utilisateurs sont à l’aise, mais la conformité et la gestion des actifs se retrouvent bloquées.

La solution de Dusk est en réalité assez ferme : permettre à chaque transaction de choisir combien d’informations elle doit exposer.

Cela explique aussi pourquoi Dusk insiste toujours sur le « regulated onchain finance », plutôt que de vendre seulement une histoire de « blockchain privée ». L’architecture actuelle de Dusk découpe justement en modules le règlement, la confidentialité, l’identité et la divulgation sélective.

Ce que je veux surtout voir, c’est une autre question :

Si vous êtes une institution qui gère réellement des actifs financiers, qu’est-ce qui vous fait davantage peur : la fuite d’informations on-chain, ou le fait de ne pas pouvoir fournir de preuves quand la réglementation exige de vérifier les comptes ?@Dusk

#dusk $DUSK

昨天重新看 Babylon 的验证参与机制时，我一直在关注一个容易被忽略的角色：那些真正跑节点、维护网络安全的人。

很多讨论都会把重点放在 BTC 持有人能不能获得收益，但对于验证者来说，问题完全不同。

他们面对的不是“要不要锁一部分 BTC”，而是：

接入新的安全体系，会不会让自己的运营成本增加？

一个节点运营者最关心的事情很现实。

服务器成本。

维护时间。

风险控制。

收益是否覆盖投入。

Babylon 想连接 Bitcoin 的经济安全，但这套设计最终也需要有人参与维护网络运行。

> 任何安全模型最后都绕不开一个问题：有没有足够多的人愿意长期承担成本。

如果收益足够吸引，更多参与者进入，可以增强网络安全。

但如果运营门槛提高，或者收益无法覆盖实际投入，参与者可能会减少。

这也是很多链上基础设施都会遇到的矛盾。

安全越强，通常意味着更多规则和要求。

规则越多，参与成本也可能提高。

我觉得 Babylon 有意思的地方，不只是让 BTC 产生新的使用场景，而是在尝试重新分配链上安全市场里的角色。

过去：

一条链需要自己培养验证者。

现在：

验证者可以通过新的方式参与更广泛的安全体系。

但最终决定这套模式能不能长期运行的，不只是技术设计，而是现实中的节点运营者愿不愿意持续投入。

因为区块链世界里，真正支撑安全的从来不是一句理念，而是一群每天维护机器、承担成本的人。

如果未来 Babylon 生态扩大，你认为最关键的竞争会是吸引更多 BTC，还是吸引更多愿意长期运行节点的人？

#baby $BABY

昨天看 Babylon 生态项目接入情况时，我一直在想一个问题：对于一条刚启动的新链来说，拥有 Bitcoin Security 到底是一种加速器，还是另一种新的依赖？

很多项目上线前都会面临同一个现实。

功能可以快速开发。

代币可以快速发行。

但安全体系不是靠宣传就能建立。

验证者数量、经济激励、长期维护，这些都需要时间积累。

所以 Babylon 提供的 BTC 安全方案，对于很多新链来说像是一条捷径。

> 但捷径背后也有一个选择：获得更快的安全启动，还是坚持完全依靠自己的验证网络成长。

站在新链团队角度，接入成熟安全来源，可以降低早期冷启动压力。

不用一开始就承担巨大安全预算，也不用等待多年才能建立足够强的验证者体系。

但另一面，依赖外部安全层，也意味着未来发展过程中需要持续协调双方关系。

如果一条链越来越依赖外部安全，它自己的安全体系还会不会继续成长？

这个问题没有简单答案。

因为完全自主建设安全，也不是免费的。

很多新链最后失败，并不是因为技术不好，而是因为没有足够经济规模支撑安全。

Babylon 的设计，其实是在解决一个长期存在的矛盾：

小链需要安全，但安全本身需要规模。

Bitcoin 拥有规模。

新链需要规模。

两者之间产生了连接。

我觉得 Babylon 真正有意思的地方，不只是让 BTC 参与安全，而是改变了新链建立信任的路径。

以前：

一条链需要自己慢慢证明安全。

未来：

它可能先借助已有经济安全，再逐渐建立自己的网络价值。

但问题也留给市场：

一条新链如果靠 Bitcoin Security 起步，当它成长起来后，你认为它应该继续依赖外部安全，还是最终必须建立完全属于自己的安全体系？

#baby $BABY

最近和几个跑节点的朋友聊天，我发现一个挺有意思的变化。

以前大家讨论一条PoS链，最关心的是节点能不能赚到奖励。

现在提到Babylon，很多人开始问另一件事：

如果未来越来越多网络共享Bitcoin安全，节点还能靠什么建立自己的竞争力？

以前节点之间拼的是硬件、稳定性和运营能力。

这些差距虽然存在，但规则相对清楚。

可一旦安全来源开始发生变化，节点的角色也会慢慢变化。

安全不再只是自己提供。

更多时候，节点需要思考的是：

怎样和新的安全体系协同，而不是重复投入。

我觉得这可能是很多人容易忽略的一点。

大家总在讨论BTC有没有释放流动性，却很少讨论节点生态会不会因此重新分工。

一个成熟的基础设施，不一定会让节点消失。

更大的可能，是让节点把更多精力放到网络服务、数据同步、运行效率这些真正能够体现价值的地方。

这和过去不断堆质押规模，其实是两种完全不同的发展思路。

所以我现在看Babylon，已经不会只盯着TVL或者质押数据。

我更想观察的是：

未来节点运营者会不会主动调整自己的角色。

如果答案是会，那Babylon影响的就不只是BTC资产利用率。

它还有可能改变一部分PoS网络的运行方式。

真正值得长期关注的，也许不是有多少BTC进入协议。

而是越来越多生态参与者，开始重新定义自己在整个网络里的位置。

#baby $BABY

Hier, lorsque j’ai étudié le mécanisme de BTC Staking de Babylon, je n’ai pas poursuivi l’analyse des détails techniques. Je me suis plutôt concentré sur une question plus concrète : pourquoi une personne qui détient du BTC sur le long terme accepterait-elle de changer activement ses habitudes de détention ?

Par le passé, ce que beaucoup de détenteurs de BTC appréciaient le plus, c’était la simplicité.

Acheter.

Transférer vers un portefeuille froid.

Attendre.

Leur confiance dans Bitcoin tient, dans une large mesure, au fait qu’il n’y a pas de porte d’entrée complexe pour générer des rendements, ni trop d’opérations supplémentaires.

Mais ce que Babylon veut faire, c’est justement de modifier cette habitude.

Il souhaite faire participer des BTC inactifs à la sécurité de la chaîne, et permettre aux détenteurs de bénéficier d’une nouvelle source de valeur. Or, il existe ici une contradiction que beaucoup de gens ont tendance à négliger :

> Lorsque le BTC commence à générer des rendements, il ne s’agit plus seulement d’un actif “mis de côté”. Il devient un marché de choix où il faut évaluer les risques et le coût d’opportunité.

Pour le protocole, plus de BTC impliqués signifie une sécurité économique plus forte.

Mais pour l’utilisateur, cela crée un nouveau problème :

Que faire si, pendant la période de verrouillage, le marché offre une opportunité ?

Que faire si un autre réseau rencontre un problème ?

Et si les rendements ne suffisent pas à couvrir les risques engagés ?

C’est le défi réel auquel Babylon doit faire face.

Sur le plan technique, faire participer le BTC à un système de sécurité, c’est une chose.

Mais faire en sorte que ceux qui croient le plus à la valeur simple de Bitcoin acceptent de changer de comportement, c’est une autre histoire.

Je pense que le véritable concurrent de Babylon n’est pas d’autres projets BTC, mais bien la barrière psychologique des détenteurs de BTC eux-mêmes.

Parce que beaucoup achètent du BTC non pas pour réaliser plus d’opérations, mais pour en faire moins.

Babylon apporte une nouvelle possibilité :

Transformer le BTC, qui était un actif d’épargne statique, en capital de sécurité on-chain.

Mais le coût, lui aussi, est clair :

À mesure que les rendements augmentent, le coût de décision augmente également.

Avant, la question était simplement :

“Dois-je acheter du BTC ?”

Désormais, elle pourrait devenir :

“Mon BTC doit-il participer à la sécurité d’un autre réseau ?”

Si, à l’avenir, le BTC Staking se généralise progressivement, préférez-vous que votre BTC travaille pour générer des rendements, ou pensez-vous que la valeur maximale du BTC réside dans le fait de rester simple, éternellement ?

#baby $BABY

Hier soir, en relisant la “White Paper” de Babylon, je suis resté bloqué sur une phrase : “Bitcoin Security”, et non “Bitcoin Consensus”. Il n’y a que quelques mots qui séparent les deux, mais la conception qui se cache derrière n’a rien à voir.

Au début, je pensais que, puisque Babylon veut intégrer Bitcoin dans un réseau PoS, cela signifiait que le BTC participerait directement à la validation, à la production de blocs ou au vote. Mais plus j’avançais, plus je voyais que les responsables évitent volontairement cette voie.

Dans Babylon, le rôle du BTC ressemble davantage à une garantie économique publique, affichée au premier plan, plutôt qu’à un acteur chargé d’exécuter le consensus dans le réseau. Les véritables nœuds qui font fonctionner le réseau PoS restent, comme auparavant, les nœuds de validation d’origine. Le BTC apporte une couche de contraintes de sécurité supplémentaires : elle augmente le coût de la malveillance, au lieu de servir d’exécuteur du consensus pour les autres.

> J’ai fini par comprendre que c’est un peu comme ajouter une assurance à un immeuble, plutôt que de démonter toute la structure porteuse pour la reconstruire.

Forcer Bitcoin à prendre en charge le processus de consensus du PoS ne serait pas seulement limité par les capacités des scripts de Bitcoin et par les particularités du réseau ; cela créerait aussi une sorte de tiraillement entre deux mécanismes entièrement différents. Au contraire, Babylon trace très clairement la frontière : le BTC est responsable de la sécurité, tandis que la chaîne PoS continue d’exécuter, chacun en conservant ses avantages initiaux.

Cette conception a bien sûr un coût. Le protocole doit mettre en place un ensemble supplémentaire de mécanismes pour faire correspondre la sécurité économique de Bitcoin à différents réseaux PoS. L’ensemble devient alors plus complexe qu’un modèle de staking traditionnel, et le seuil de compréhension est plus élevé. Mais, en échange, on n’a pas besoin de modifier Bitcoin lui-même : on peut exploiter la valeur accumulée pendant des décennies.

Avant, je pensais souvent que l’innovation de Babylon consistait simplement à “pouvoir mettre du BTC en staking”. Maintenant, en la regardant à nouveau, je vois que ce qu’elle fait vraiment, c’est transformer le Bitcoin — d’un actif échangeable — en une ressource de sécurité réutilisable.

Si, à l’avenir, de plus en plus de chaînes publiques commencent à emprunter la “Bitcoin Security”, penses-tu que le BTC pourrait progressivement évoluer de “réserve de valeur” vers une couche de sécurité sous-jacente à l’ensemble du monde PoS ?

#baby $BABY

En retravaillant aujourd’hui le design de Babylon Genesis, je suis resté bloqué sur une question : puisque l’ensemble du protocole repose sur la sécurité de la BTC, pourquoi l’organe officiel émettrait-il quand même un BABY à part, au lieu de laisser la BTC assumer toutes les fonctions ?

En poursuivant, j’ai découvert que, dès le départ, l’officiel n’avait pas l’intention de faire de la BTC un « actif universel » dans le réseau.

Dans Babylon, la BTC ressemble davantage à une garantie de sécurité. Elle fournit la sécurité économique, afin que les réseaux PoS connectés puissent s’appuyer sur la valeur de Bitcoin. Mais ce qui fait réellement fonctionner le réseau, c’est une logique différente.

Les paiements de gas, les votes de gouvernance, les incitations à l’écosystème : toutes ces actions à haute fréquence sont confiées au BABY.

Plus tard, j’ai réalisé que c’était intentionnel : éviter une contradiction. Faire porter à un actif à tendance plutôt « réserve de valeur » des tâches d’exécution à haute fréquence.

Si toutes les opérations dépendaient de la BTC, chaque interaction du réseau serait directement liée à l’actif BTC lui-même. Que ce soit l’expérience utilisateur ou la conception des incitations, tout serait forcément limité. Babylon choisit de confier la couche d’exécution au BABY et de laisser la couche de sécurité à la BTC. Au fond, il s’agit de permettre aux deux actifs de faire chacun ce dont ils sont le mieux capables, plutôt que de se remplacer.

Bien sûr, ce choix a un coût. Le protocole doit maintenir deux systèmes économiques, le seuil de compréhension des utilisateurs augmente, et le développement de l’écosystème doit aussi tenir compte à la fois des détenteurs de BTC et des utilisateurs de BABY. Mais par rapport à l’idée de concentrer toute la responsabilité sur un seul actif, cette répartition offre davantage d’espace pour les extensions à venir.

Auparavant, je pensais souvent que l’innovation de Babylon consistait simplement à dire : « la BTC peut être mise en jeu en natif ». Aujourd’hui, je vois plutôt qu’elle veut réellement mettre en place une architecture séparant la couche de sécurité et la couche d’exécution, et que la présence du BABY est une pièce essentielle pour que cette répartition puisse fonctionner durablement.

À l’avenir, si davantage de protocoles de l’écosystème Bitcoin adoptent un modèle similaire, accepteriez-vous davantage l’idée : « un actif s’occupe de la sécurité, un autre s’occupe de l’exécution », ou préféreriez-vous conserver toutes les fonctions concentrées sur la BTC ?

#baby $BABY