Fedimint

假设安娜使用连接本地联邦的钱包，彼得的咖啡馆接受这个联邦的 e-cash。每买一杯咖啡，不一定都要产生单独的 Bitcoin 交易。应用处理的是共同发行机构 mint 的数字代币，实际的比特币仍在联邦储备中，安娜与彼得之间转移的是代币。Fedimint 提供构建工具，管理者运营具体联邦，钱包则是安娜与联邦交互的界面。这是不同的事物。标准模块处理 Bitcoin、Lightning Network 和 e-cash，其他模块还能提供更多服务。每个联邦独立运营并持有自己的储备，其代币不会自动被所有其他联邦接受。即使管理者内部达成一致，也不能替代 Bitcoin 网络的规则。 [1] [2]

联邦的用意是避免关键操作由单一运营者控制。以 3-of-4 门限为例，发行代币需要四位管理者中的三份有效签名份额。一人离线仍可能凑齐门限，两人离线就不够了。但三名份额持有人也能合作，在未经最后一人同意时产生签名。分散权限本身不保证诚实或足额储备。这属于 Counterparty risk，也就是依赖的人或机构可能无法履行兑付的风险。e-cash 的门限签名与 Multisig，即共同控制比特币储备的多重签名，承担的任务也不同，需要核对具体联邦的实际规则。 [3] [4]

安娜通过区块链（已确认交易的公开历史）直接存入比特币时，钱包应用提交相关输出的证明，联邦须按自身规则接受。每个这样的输出记录一笔金额以及花费它所需满足的条件。提款时则由联邦使用储备构建并签署 Bitcoin 交易。代币本身并不给安娜一把能绕过其他人提款的密钥。这与 Self-Custody，即自行掌管用于签署比特币付款的密钥，有着关键区别。兑付仍需管理者在线、资金充足、支付费用并满足确认要求。因此，系统内付款迅速，不等于任何金额都能同样迅速提走。 [4] [7]

e-cash 的隐私依靠 Blind Signature，也就是盲签名。客户端先用数学方法隐藏具体代币，请求签名，再移除盲化。最终结果可以验证，但 mint 无法仅凭代币，把日后兑付关联到某一次发行请求。对技术细节感兴趣的读者可以进一步了解：文档描述的是基于 BLS12-381 的门限 BLS 签名，而非用 FROST 签署代币。客户端将足够的有效份额合成为一个可验证签名。每种面额有自己的密钥，因此隐藏代币身份，并不意味着 mint 不知道所发行的面额类别。 [3]

彼得可以验证代币带有联邦的有效签名，但这还不能证明它此前未被兑付。数字数据可以复制，安娜可能仍保存着同一代币。因此联邦会记录已花费的代币标识 nonce，并拒绝重复使用。收款人需要成功换成新代币，而不能只相信对方承诺不使用另一份副本。签名真实、代币未花费、比特币储备充足，是三个独立问题。验证其中一个，不代表另外两个也已解决。 [3]

如果咖啡馆接受普通 Lightning Network 付款，可以由 gateway，即支付网关，完成转移。它连接联邦与 Lightning，且两边都需要流动性，也就是可用资金。网关不一定是联邦管理者。V2 模块文档描述了按付款条件释放资金的合约，以及条件满足时公开的秘密值 preimage。付款失败时有依合约退款的路径，但这不是服务持续可用的保证。即使 mint 正常，网关故障或流动性不足也可能阻止支付。 [5]

盲签名使 mint 无法仅凭代币，把它的发行与日后的兑付关联起来。它不会抹去其他痕迹。对方可能知道是安娜付款，网关会看到处理 Lightning 付款所需的信息，观察者可以比较时间和金额，网络连接数据也可能提供线索。因此应先问清：什么信息要对谁隐藏，是 mint 管理者、咖啡馆、网关，还是网络观察者？更私密的代币流转，不会自动让所有存入、提取及人与人的联系都匿名。 [3] [5]

如果应用支持且已正确设置恢复机制，手机丢失不一定意味着代币丢失。文档中的设计使用应用的主要秘密值重新计算所需数据，并结合加密状态快照与可用的联邦历史。具体步骤依应用及版本而定，并不是把 Bitcoin Seed Phrase 随便输入任意钱包即可。因此，依赖服务前，应分别测试客户端恢复与小额提款。备份有助于找回丢失的数据，却不能填补空缺的储备，也不能强迫足够多的管理者合作。 [6] [4]