熬夜翻Babylon资料的时候，我本来只想确认清算人的权限边界。结果越翻越困，反而被一个事情弄清醒了——存款和提款，信任逻辑完全不是一回事
我一开始以为整个金库系统的信任模型是统一的。看到后面才发现，存款环节需要一堆人点头，提款和清算的信任逻辑完全不一样
存款那边，你得求人。建金库时，你要在以太坊提交Peg-In请求，附带只有自己知道的哈希锁秘密。然后在比特币网络广播Pre-PegIn交易，把BTC锁进跟哈希锁关联的Taproot地址。接下来真正的麻烦才开始——你需要Vault Provider和AVK在链下跟你一起构建预签名交易图，每个参与者都要签名。存款人揭示哈希锁秘密后金库才算正式激活
提款和清算，逻辑完全不一样。提款走的是预签名路径——金库创建时所有合法的支出路径已经全部预签完，金库一旦生成就没有人能伪造新的支出。提款时存款人直接用创建时的密钥自己广播交易，不需要任何其他人配合。
清算那边，触发条件是借款人的健康因子跌破1.0。清算分许可和无许可两条路径，但不管是哪条路，规则在金库创建时已经写死了，不需要清算人求谁批准。
翻到文档里一句话让我停了一下：“Trust is optional and removable”。存款需要多方参与，是因为金库还没建立，信任关系还在构建中——需要Vault Provider驱动设置、AVK共同签名、Universal Challengers见证。但金库一旦建立，预签名交易图冻结后，你不需要再依赖任何第三方
查了一晚上，清算人权限没看完，反而被存款提款的信任反差绕进去了。但想通之后反而觉得合理——存款求人办事是因为信任还没建立，提款清算不求人是因为信任已经被锁进代码里了。你觉得这套“构建期依赖人、成熟后只信代码”的设计是精妙还是多此一举？评论区聊聊。
#BABY $BABY @BabylonLabs_io
我一开始以为整个金库系统的信任模型是统一的。看到后面才发现，存款环节需要一堆人点头，提款和清算的信任逻辑完全不一样
存款那边，你得求人。建金库时，你要在以太坊提交Peg-In请求，附带只有自己知道的哈希锁秘密。然后在比特币网络广播Pre-PegIn交易，把BTC锁进跟哈希锁关联的Taproot地址。接下来真正的麻烦才开始——你需要Vault Provider和AVK在链下跟你一起构建预签名交易图，每个参与者都要签名。存款人揭示哈希锁秘密后金库才算正式激活
提款和清算，逻辑完全不一样。提款走的是预签名路径——金库创建时所有合法的支出路径已经全部预签完，金库一旦生成就没有人能伪造新的支出。提款时存款人直接用创建时的密钥自己广播交易，不需要任何其他人配合。
清算那边，触发条件是借款人的健康因子跌破1.0。清算分许可和无许可两条路径，但不管是哪条路，规则在金库创建时已经写死了，不需要清算人求谁批准。
翻到文档里一句话让我停了一下：“Trust is optional and removable”。存款需要多方参与，是因为金库还没建立，信任关系还在构建中——需要Vault Provider驱动设置、AVK共同签名、Universal Challengers见证。但金库一旦建立，预签名交易图冻结后，你不需要再依赖任何第三方
查了一晚上，清算人权限没看完，反而被存款提款的信任反差绕进去了。但想通之后反而觉得合理——存款求人办事是因为信任还没建立，提款清算不求人是因为信任已经被锁进代码里了。你觉得这套“构建期依赖人、成熟后只信代码”的设计是精妙还是多此一举？评论区聊聊。
#BABY $BABY @BabylonLabs_io