Ecash 生态推进多实现方案,瞄准比特币托管去单点故障

Ecash 生态推进多实现方案,瞄准比特币托管去单点故障

N
News Editor
2026-10-06 15:55:06
Bitcoin Magazine 刊发 Obi Nwosu 署名文章称,围绕比特币托管的核心问题不应只停留在“可信”或“无须信任”的二分法,而应关注需要多少独立环节同时失效,用户才会丢币。文中提到,Fedimint 开发者已在柏林 Ecash Hackday 上让一个联邦运行在 3 个独立实现之上;Calle 则在 bitcoin++ 发布 Federated Cashu,称任意 4/5 组合可继续维持联邦运行。作者还列出协议、钱包、硬件、人和司法辖区五个独立性层面。

Bitcoin Magazine 刊发 Fedi 与 Fedimint 联合创始人 Obi Nwosu 的署名文章,讨论比特币托管的安全边界。文章认为,行业持续把问题表述为「可信」或「无须信任」,但真正该问的是:「在你失去资金之前,需要有多少个彼此独立的环节同时出错?」

文中说明,这是 Obi Nwosu 的客座文章,观点仅代表其本人,不一定代表 BTC Inc. 或 Bitcoin Magazine。

从单一软件实现到独立失败域

Obi Nwosu 在文中提到,此前无论是 Liquid,还是更早几周围绕 Coldcard 的讨论,都暴露出同一个问题。Matt Corallo 对此有一句简洁概括:运行相同的软件,就会承受相同的漏洞。

他表示,这一批评同样适用于 Fedimint,而且他本人也是第一个承认这一点的人。Fedimint 的设计目标,是移除单个人和单一机构作为失效点;但在此之下,协议此前只有一个软件实现,形成了位于人为联邦之下的软件单一种植。按文中表述,这样的安全性仍然不够。

柏林 Ecash Hackday:一个联邦跑在 3 个独立实现上

文章称,Fedimint 开发者已经作出回应。在柏林举行的 Ecash Hackday 上,Fedimint 团队让同一个联邦运行在 3 个独立实现之上,其中一个实现由 Cashu 的 thesimplekid 构建。

文中引用了 elsirion 于 2026 年 9 月 30 日发布的内容,原文写道:「Had a great time at Ecash Hackday in Berlin, got a Fedimint running with 3 different implementations by @thesimplekid, me and the Fedimint team! Already got 3 Fedimint implementations now, who will build the 4th one?」

按文章表述,这意味着 3 套彼此分离的代码库,可以在同一个联邦中共同托管资金。作者认为,开发者已经开始着手解决他几周前指出的软件单一种植问题,而团队接下来的回应是继续追问「谁来构建第 4 个实现」,这正是他希望看到的方向。

bitcoin++:Calle 发布 Federated Cashu

除 Fedimint 外,文章还提到 Calle 在 bitcoin++ 上展示了另一条路径,即 Federated Cashu。按文中说法,这一设计方式旨在避免单一运营者独自站在用户资金背后。

文章援引 Matthew Vuk 于 2026 年 10 月 1 日转述的内容称,Calle 在 @btcplusplus 上发布「Federated Cashu」时表示:「You don’t need to trust the operator with your privacy, but you do need to trust the operator with your security」以及「Any combination of 4/5 continues the federation」,并提到其中采用了一种新的 Blind BLS 签名方案。

作者将此概括为:两个团队,两种路径,一个共同目标——在几周时间里推动生态系统韧性向前发展。

作者列出的五个独立性层面

文章指出,容错能力并不只来自系统是否值得信任,也不只取决于审计、形式化验证和安全文化。按作者说法,真正的容错来自独立的失败域:不能让单一漏洞、单一供应商或单一司法辖区一次性夺走全部安全边界。

为说明这一点,Obi Nwosu 在文中区分了协议层与产品层。他写道,Fedimint 是开源协议,Fedi 是其上构建的产品。当协议出现第二个和第三个实现后,每一个联邦都会变得更具韧性,而成员使用钱包的方式无需发生改变。Guardians 可以运行不同的软件,同时继续服务同一批用户。

随后,他列出五个必须保持独立性的层面:

  • 每一个持有资金的协议都应有多个实现。
  • 应有多个钱包实现。
  • 密钥应在来自不同厂商的硬件上生成。
  • 每一个持有资金的系统背后,都应有多个独立且值得信任的人,同时这些人的隐私应得到保护。
  • 系统应分布在不同地域和司法辖区,因为一个司法辖区的规则可能在一夜之间发生变化。

AI 辅助威胁背景下的托管安全

文章最后表示,参与柏林开发工作的开发者,让上述五个层面离现实更近了一步。作者向持续构建并公开展示工作成果的人致谢,同时也写道,生态系统的工作还没有结束。

他呼吁整个生态在每一层都要求独立性,包括软件、硬件、人员和司法辖区。按其说法,只有这样,才能在生态系统进入一个面对 AI 辅助威胁的新阶段时,维持用户对比特币的信心。

这篇文章最早发表于 Bitcoin Magazine,作者为 Obi Nwosu。

本文最初由 Bit.Fan 发布。 欲了解更多加密货币新闻与市场洞察,请访问 www.bit.fan.
200

免责声明:

本平台展示的市场信息、项目资料与第三方内容仅用于行业信息分享,不构成任何形式的投资建议或收益承诺。

加密资产交易具有较高风险,用户应充分评估自身风险承受能力并独立作出决策,相关盈亏及法律责任由用户自行承担。