BRC-100：钱包与应用之间的标准接口

一句话理解 BRC-100

BRC-100 是 BSV 生态中用于描述“应用如何和钱包通信”的接口标准。

如果说钱包负责密钥、UTXO 和签名，应用负责业务意图，那么 BRC-100 关注的就是：应用如何安全、标准地告诉钱包“我想做这件事”，钱包又如何返回结果。

它不是 token 协议，也不是链上共识规则，而是位于应用与钱包之间的接口层。

理解这一点，有助于开发者把“业务逻辑”和“密钥控制”分开，构建更安全、可互操作的 BSV 应用。

为什么需要钱包与应用之间的标准接口

在没有统一接口的情况下，每个钱包都可能采用不同的调用方式：

• 一个钱包用一种方法创建交易。
• 另一个钱包用另一种方法签名。
• 有的钱包返回 raw transaction。
• 有的钱包只返回 txid。
• 有的钱包甚至要求应用直接处理私钥。

这会带来两个明显问题。

第一，应用开发会变得复杂。开发者需要为不同钱包适配不同接口，重复处理交易创建、签名、找零、授权等细节。

第二，用户容易被锁定在少数钱包中。如果某个应用只支持特定钱包，用户迁移和选择的成本都会上升。

BRC-100 这类接口标准的目的，就是让应用和钱包之间形成共同语言：应用提出请求，钱包理解请求并返回标准化结果。

应用不应该直接管理用户私钥

BRC-100 背后的重要安全直觉是：应用不应该直接管理用户私钥。

应用可能希望用户完成很多操作，例如：

• 支付一笔钱。
• 发布一条 OP_RETURN 数据。
• 创建一笔 token 相关交易。
• 签署一份凭证。
• 授权某个身份操作。

最危险的方式，是让用户把私钥或助记词输入应用。这样一来，一旦应用存在漏洞、被攻击或被恶意篡改，用户的资产和身份都可能暴露。

更合理的模式是：

在这个流程中，应用表达业务意图，钱包保留密钥控制权。用户通过钱包确认操作，应用只接收交易或签名后的结果，而不是直接接触私钥。

BRC-100 主要关注什么

BRC-100 关注的是钱包和应用之间的交互方式，而不是链上交易本身。

它关心的问题包括：

• 应用如何连接钱包。
• 应用如何请求创建交易。
• 应用如何请求签名。
• 钱包如何返回交易或结果。
• 用户如何授权。
• 应用如何获得可用输出或钱包能力。
• 钱包如何在不暴露私钥的情况下满足应用需求。

对新手来说，可以先把 BRC-100 理解为“BSV 应用调用钱包的标准接口思路”。它帮助应用以统一方式请求钱包执行操作，而不是让每个项目都从零实现一套钱包交互逻辑。

BRC-100 与 WalletClient 的关系

在 BSV TypeScript SDK 中，可以看到 WalletClient 这样的概念。

WalletClient 体现的正是应用通过钱包接口进行操作的思路。应用不需要自己从零选择 UTXO、计算找零、为每个 input 签名，而是向钱包发起请求，由钱包处理交易相关细节。

例如，应用可以请求钱包创建一个 action。钱包可以负责：

• 输入选择。
• 输出构造。
• 手续费。
• 找零。
• 用户授权。
• 签名。
• 返回交易相关结果。

这种方式降低了新手开发第一笔交易的门槛，也更接近真实应用架构：应用负责业务，钱包负责密钥和交易执行。

BRC-100 与非托管应用

BRC-100 风格的接口非常适合非托管应用。

所谓非托管，是指应用不替用户保管私钥。用户的钱包负责签名，应用只负责发起请求并处理返回结果。

这种架构有几个好处：

• 应用的安全责任降低。
• 用户对密钥和资产的控制权更强。
• 钱包可以统一管理授权。
• 多个应用可以复用同一个钱包。
• 应用之间更容易实现互操作。

不过，这种模式也对钱包体验提出了要求。如果钱包频繁弹窗，或者向用户展示过多难以理解的交易细节，用户体验可能会受到影响。因此，标准接口解决的是应用与钱包之间的通信问题，良好的授权展示和交互设计仍然需要钱包实现方认真处理。

BRC-100 与链上交易的关系

BRC-100 本身不是链上交易格式。它只是应用与钱包之间的接口约定。

真正上链的仍然是 BSV 交易。交易里包含 inputs、outputs、locking script、unlocking script、手续费、签名等要素。

BRC-100 可以帮助应用请求钱包创建这些交易，但它不改变底层交易规则。也就是说，使用 BRC-100 风格接口，并不意味着开发者可以完全忽略 BSV 交易结构。

钱包接口可以简化开发流程，但理解交易如何构造、签名、广播和验证，仍然是构建可靠 BSV 应用的基础。

一个典型的 BRC-100 风格交互流程

可以把 BRC-100 风格的应用与钱包交互理解为以下步骤：

1. 用户打开一个 BSV 应用。
2. 应用检测或连接钱包。
3. 应用构造一个请求，例如发布一条链上数据。
4. 钱包展示请求内容。
5. 用户确认。
6. 钱包选择 UTXO、创建交易并签名。
7. 钱包返回交易结果。
8. 应用记录 txid，并继续处理广播状态、确认或 SPV 证明。

这个流程把三件事拆开了：

• 用户授权由钱包呈现和确认。
• 密钥控制留在钱包侧。
• 业务逻辑由应用负责。

这种分工有助于应用保持非托管，同时让钱包成为用户管理密钥和授权的统一入口。

BSV 应用为什么需要这种标准

BSV 生态面向大量数据应用、微支付应用、token 应用和企业应用。如果每个应用都要求用户导入私钥，生态很难形成健康的应用体验和安全边界。

标准化的钱包接口可以带来几个实际价值：

• 应用更容易开发。
• 钱包更容易兼容多个应用。
• 用户不必在不同应用中重复暴露敏感密钥。
• 权限和授权体验更统一。
• 后续与 SPV、BEEF、BUMP、Overlay 等组件更容易衔接。

因此，BRC-100 可以看作 BSV 应用生态从“每个项目自己拼钱包”走向“钱包与应用分工”的基础之一。

新手常见误解

学习 BRC-100 时，需要特别避免以下误解：

• BRC-100 不是 token 协议。
• BRC-100 不是链上共识规则。
• BRC-100 不会替你保管私钥。
• 应用请求钱包操作，不等于应用拿到用户私钥。
• 钱包接口可以简化开发，但不能替代对交易结构的理解。
• 钱包返回 txid 后，应用仍要处理广播状态、确认和证明。

小结

BRC-100 的核心价值，是为 BSV 应用和钱包之间提供标准化的交互思路。

应用不需要直接管理私钥，也不需要为每个钱包单独适配一套交易和签名流程；钱包则可以在保留密钥控制权的前提下，响应应用的支付、数据发布、签名或授权请求。

对开发者来说，理解 BRC-100 有助于建立正确的 BSV 应用架构：应用表达意图，钱包执行授权和签名，链上仍然遵循 BSV 交易规则。

参考资料

• Wallet Toolbox docs: https://bsv-blockchain.github.io/wallet-toolbox/
• Wallet reference: https://bsv-blockchain.github.io/ts-sdk/reference/wallet/
• BRCs repository: https://github.com/bitcoin-sv/BRCs