Kaspa 即将登陆 SSP——其背后的库已经开源
Kaspa 支持即将登陆 SSP。它将采用你在 Bitcoin、Ethereum 和 Solana 上已经在用的同一套 2-of-2 多签：一把密钥在 SSP Wallet 中，一把在 SSP Key 上，两者都同意之前任何资金都不会移动。企业金库也将支持 Kaspa。
为了实现这一点，我们必须构建一个此前并不存在的东西。今天，我们可以分享其中已经公开的部分：@runonflux/kaspa-core，一个用于 Kaspa 交易和多签的开源 TypeScript 库，以 MIT 许可证发布。
为什么我们先做了一个库
在考虑添加 Kaspa 时，我们调研了能找到的所有 Kaspa JavaScript 包。没有一个能够真正端到端地构建并签署 Kaspa 多签交易——而这恰恰是 SSP 最需要的能力。
官方路线是把 Kaspa 的 Rust 代码编译成 WebAssembly。这是非常出色的软件，但并不适合 SSP。SSP Key 运行在 React Native 上，那里无法使用 WebAssembly；而浏览器扩展必须保持轻量——仅 WebAssembly 包本身就超过 11 MB。
于是我们用纯 TypeScript 从零实现了 Kaspa 的交易规则：地址、脚本、M-of-N 多签、签名哈希、Schnorr 签名、手续费与“质量”（mass）计算，以及输入选择。它只有两个运行时依赖——广泛使用且经过审计的 @noble 密码学库——并且无需修改即可在浏览器、扩展、Node 和 React Native 中运行。
我们如何验证它
对于钱包代码，“看起来能用”算不上标准。这个库的目标是可证明地与 Kaspa 节点本身完全一致：
- 对照 Kaspa 自身的代码检验。 测试套件将每个共识关键函数与参考节点实现 rusty-kaspa 进行对照，并让库签署的交易通过其真实的脚本引擎执行——覆盖从 1-of-1 到 15-of-15 的每一种 M-of-N 组合。
- 真实的主网数据。 主网上已有的交易 ID 和签名都能被精确复现。
- 有真实资金的主网交易。 十五笔真实交易——其中包括 SSP 风格的 2-of-2 支出、一笔 2-of-3，以及企业风格的 4-of-7、6-of-10 和 10-of-15 多签——均由该库构建并签名，并被网络接受。每一笔交易中，节点计算出的交易质量都与我们的计算完全一致。
- 对抗性审查。 多轮安全审查专门寻找欺骗签名方或抬高手续费的方法。未发现任何严重问题，所有发现的问题都已修复并补充了回归测试。审查报告与代码一同公开。
开放代码与可复现构建秉持同一原则：什么在为你的交易签名，你不应该只能听我们一面之词。
Kaspa 在 SSP 中将是什么样子
你的 Kaspa 金库将是一个 Kaspa 多签地址（以 kaspa:p 开头），按照 SSP 惯用的派生路径由你的两台设备共同派生。发送流程与其他链相同：SSP Wallet 准备并签署它的一半，SSP Key 向你显示收款方、金额和手续费，只有在你于 SSP Key 上批准之后，交易才会发送到网络。这是同一个 2-of-2 模型，只是换了一条新链。
几个 Kaspa 特有的细节影响了设计：
- 每台设备自行核对金额。 Kaspa 签名只承诺它所签署输入的金额，因此一台信任外部传入金额的设备可能会在手续费上被误导。在 SSP 中，每台设备在签名前都会自行查询被花费的币，并且只为自己的金库签名。
- 交易 ID 在签名前即已确定。 Kaspa 的交易 ID 不包含签名，因此 SSP 可以在任何一把密钥签名之前，就把交易锁定到它的最终 ID。
- 内置手续费上限。 手续费设有上限，因此错误的手续费估算不会酿成代价高昂的失误。
对于企业，SSP Enterprise 金库将以 M-of-N 审批方式支持 Kaspa，每个金库最多可达 Kaspa 的标准上限 15 把密钥。
首个版本不包含什么
我们宁愿把一件小事做好，也不愿把一件大事做得草率。首个版本仅涵盖主网上的 KAS 本身。KRC-20 代币、Kaspa 测试网、Kaspa 消息签名以及 Kaspa 的 WalletConnect 在发布时均不包含。
何时推出
Kaspa 支持已在 SSP Wallet、SSP Key 和 SSP Enterprise 中实现，目前正在进行最终测试。正式可用时，我们会在这里发布公告并附上版本说明。在此之前，没有任何功能需要开启，也没有任何东西需要下载；任何告诉你相反说法的人都不是我们。
与此同时，开发者今天就可以使用这个库：它在 npm 上名为 @runonflux/kaspa-core，GitHub 地址为 RunOnFlux/kaspa-core。
