🔥 BRAVE 質押池已上線 — 在錢包搜尋 BRAVE 即可委託
简体

Brave基地

Brave
@47c132035ed7a1105a867946b99d67af Bitcoin研究小组 公开
讨论 BTC 生态浏览器钱包研究：格局、分歧与 BIP-322 签名之战

BTC 生态浏览器钱包研究：格局、分歧与 BIP-322 签名之战

写作日期：2026-08-20 数据截止：2026 年 8 月（Web3 钱包市场、发行商官方口径）

一、引子：一个没有"默认钱包"的生态

以太坊有 MetaMask，Solana 有 Phantom，币安系有 Trust Wallet（220M+ 用户，35% MAU 份额）。而比特币生态——市值 1 万亿美元级的网络——浏览器钱包的版图却是三足鼎立、标准分裂。

2026 年的现实是：比特币的钱包竞争不再围绕"谁能管 BTC"，因为几乎所有钱包都能管 BTC。竞争焦点转移到了两个维度的叠加：

  1. 资产协议覆盖：能否安全持有 Ordinals、Runes、BRC-20、Rare Sats 等原生资产；
  2. dApp 连接能力：能否让网页拿得到钱包的签名能力。

这两条轴构成了本文的分析框架。而它们共同指向一个此前几乎无人正视的问题——比特币生态至今没有一套统一的钱包连接标准。以太坊有 EIP-1193，比特币没有。这个空缺正在决定谁赢。

二、演化：从"收付款工具"到"资产协议的执行层"

比特币钱包的形态演进可以划分为四个阶段：

阶段时期核心抽象代表
托管时代2009–2016交易所账户Mt. Gox、Coinbase
自托管工具2016–2022地址与私钥管理Electrum、Sparrow、Bitcoin Core
资产协议时代2022–2024UTXO 与铭文资产UniSat、Xverse、Leather
多链聚合时代2024–2026多协议 + 多链 + dApp 桥Xverse、Lace、Brave、OKX

转折点是 2022 年。Ordinals 协议让比特币第一次拥有"可携带的链上资产"，BRC-20、Runes 接踵而至。钱包的职责从"安全地转移 BTC"扩展为"隔离并管理多种 UTXO 资产"。

这个转变带来一个此前不存在的安全问题：误花。一个支持 Ordinals 的钱包如果让普通 BTC 转账动用带有铭文的 UTXO，价值会作为手续费永久销毁。2026 年的主流判断（多家评测机构一致）是：钱包必须实现支付地址与 Taproot 资产地址的自动分离，或者至少提供 UTXO 保护机制。这成为钱包分层的第一道分水岭。

与此同时，另一个维度也在成型：dApp 连接。比特币生态对"钱包签名登录"的需求随着 DeFi 的扩张而出现，但比特币社区从未达成统一标准。各家钱包各自为政，形成了下文的分裂格局。

三、技术架构拆解：三条连接标准的分裂

3.1 CIP-30：Cardano 的例外

Cardano 生态拥有全行业最规整的钱包连接标准——CIP-30（dApp-Wallet Web Bridge）。它定义了 window.cardano.{walletName} 注入点，以及 enable() → signData()/signTx() 的完整流程。签名遵循 CIP-8（COSE_Sign1 格式），服务端可用 ed25519 验签。

CIP-30 的规范性直接导致了一个有趣的现象：Brave Wallet 在浏览器层面同时注入两套协议——EVM 走 window.ethereum，Solana 走 window.solana，而 Cardano 走 window.cardano.brave。官方文档明示其实现了 CIP-30 全流程（getNetworkId/getUtxos/getBalance/signTx/signData/submitTx）。Cardano 官方技能库确认其 dApp 支持在 Brave 1.88 版本默认启用，并验证了除 getRewardAddresses 外的全部 API 调用。

但 Cardano 的规范没有传染给比特币。同一款钱包（Brave、Lace）对 BTC 的态度截然不同——只管理，不开放。

3.2 BIP-322：迟到的通用签名标准

比特币缺的不是签名算法，而是签名消息的通用格式。旧版 signmessage（2012 年，Bitcoin Core RPC）只能签 P2PKH 地址（1...），对 SegWit（bc1q...）和 Taproot（bc1p...）无能为力。

BIP-322（Generic Signed Message Format）于 2018 年提出，2026 年 4 月定稿为 1.0.0，2026 年 6 月更新至 2.0.0。它用"构造虚拟交易再签名"的方式，让任意脚本类型（P2WPKH/P2WSH/P2TR）都能签名任意消息。三种变体：

变体前缀兼容脚本用途
Legacy无P2PKH向后兼容
SimplesmpP2WPKH、P2WSH、P2TR浏览器钱包主流
Fullful全部任意脚本
Full (PoF)pof全部证明对 UTXO 集合的控制权

Simple 变体是浏览器钱包的默认选择。它的签名是 base64 编码的 witness stack，服务端用 bip322-js 即可验证。BIP-322 之于比特币，等价于 CIP-8 之于 Cardano——但两者的钱包支持面完全不同。

实际应用（2026）：BIP-322 在浏览器钱包 dApp 签名层的采纳面其实很广——Xverse、UniSat、Leather、Phantom、MetaMask（Wallet Standard 底层即 BIP-322）、OKX、Binance W3W 全部支持 signMessage，且 Phantom 官方文档直接用 bip322-js 演示验签。生产级落地集中于"身份证明/登录"：OrangeCheck 提供完整 Sign-in-with-Bitcoin 流程（challenge → 签名 → 会话，跨钱包适配器覆盖 UniSat/Xverse/Leather/Alby）；OC Lock/OC Chat 用一次 BIP-322 签名把浏览器 X25519 设备密钥绑定到 BTC 地址；libxmtp 有正式提案（issue #3568）将其作为 taproot 身份签名；Swiss Bitcoin Pay、Peach 用它做地址所有权证明；Sparrow、Specter、Bitcoin Core 25+ 桌面端已支持。窄的是"完整生态工具链"而非钱包覆盖：多签仍无法签名消息、Coldcard/旧 Trezor 固件不支持、Electrum 仅 legacy、硬件钱包只能走 PSBT 流程。

3.3 window.bitcoin：事实标准缺位下的各自为政

比特币没有官方定义的 provider 注入点。于是各家钱包按 EIP-1193 的灵感自行实现：

  • imToken：注入 window.bitcoin，提供 btc_signMessage（仅 bip-322-simple）、btc_signPsbt、btc_getUnspent 等方法（v2.15.4 起）。
  • Binance W3W：注入 binancew3w.bitcoin，并代理 window.unisat；signMessage(msg, "ecdsa" | "bip322-simple")。
  • Xverse（Sats Connect）：request("signMessage", { address, message, protocol })，protocol 可选 ECDSA 或 BIP322，是唯一对 BIP-322 支持做显式类型区分的钱包。
  • Leather：window.LeatherProvider.request("signMessage", { message, paymentType, network })，返回 { signature, messageHash, address }。

这套各自为政的 API 有一个共性问题：没有跨钱包互操作。同一个 dApp 要支持 Xverse 和 UniSat，就得写两套适配器，或者依赖 window.unisat 这个非官方的事实别名。

四、格局：三强与两支准队

4.1 Xverse：综合第一（用户量）

  • 官方口径"Trusted by nearly 2,000,000 users"；Chrome 扩展第三方统计当前安装量约 300,000（ExtScope，2026-08）。
  • 覆盖：BTC、Ordinals、Runes、BRC-20、Rare Sats、Stacks、Starknet、Spark、Lightning。
  • 硬件：Ledger、Keystone；审计：Least Authority；开源程度：核心部分闭源。
  • BIP-322 支持：全地址类型，protocol 显式可配。
  • 评价：多家评测（KuCoin、midl.xyz、Plisio）一致列为"综合最佳/新手首选"，门槛在 UI 复杂度与核心闭源。

4.2 UniSat：协议原教旨（开发者/交易者）

  • 2022 年第一个 Ordinals 原生钱包，自带最大 BRC-20 市场；完全开源（含 libbrc20-indexer，唯一第一方索引器）。
  • 独特能力：未确认铭文查看、Fractal Bitcoin 支持、UniHexa 统一交易所（2026-03 起 90 天零费率）。
  • 安全缺陷：BTC 与 Ordinals 共用单一 Taproot 地址，存在误花风险；硬件钱包支持有限。
  • 定位：深度交易者，界面不为新手设计。

4.3 Leather：Bitcoin DeFi 侧翼（原 Hiro）

  • 2023 年由 Trust Machines 从 Hiro 更名；完全开源 + 审计。
  • 总下载 375,000+，MAU 100,000+，月交易 300,000+（官方口径）。
  • 差异化：Stacks 生态深度集成、sBTC 桥、支付/资产地址自动分离（最安全）。
  • 短板：无移动端。

4.4 多链准队

钱包用户量BTC 资产支持dApp 签名
OKX Wallet大（未披露）Ordinals/Runes/BRC-20BIP-322（P2WPKH/P2TR）
Binance W3W大完整ECDSA / bip-322-simple
MetaMask30M+ MAU原生 BTC 管理（2025 起）有限
Phantom20MOrdinals/Runes（BRC-20 已移除）有限

4.5 双链但"BTC 封闭"的两家

这是本文最关键的一个观察。Lace 与 Brave 都同时支持 Cardano 和 BTC，但只对 Cardano 开放 dApp 签名，BTC 侧完全封闭。

  • Lace：Cardano → 完整 CIP-30；BTC（v1.22/1.24 上线，1.31 全量开放）只能收/发/存。官方 18 个月路线图（2025 Q1 起）中的 BTC 项只有 Basic BTC Support、BTC Wallet Acquisition、BTC DeFi（Cardinal 封装协议），没有 BTC dApp 签名 API。Lace 2.0.6 的签名改进全部属于 Cardano 侧（DRepID、Ledger stake key）。
  • Brave：BTC 自 v1.63（2024-02）支持，可收发全类型地址；Cardano 走 window.cardano.brave（CIP-30，v1.88 默认启用）；但不为 BTC 注入任何 provider，网站拿不到 BTC 签名能力。

结论："双链钱包"不等于"双标准签名钱包"。资产管理层的多链是一回事，dApp 签名层的跨链是另一回事。截至 2026 年，没有任何一款钱包同时在 CIP-30 与 BIP-322 两个标准上提供 dApp 签名。

五、范式移转：从"托管资产的容器"到"签名的门禁"

维度旧模型（2016–2022）新模型（2024–2026）
钱包职责安全持有与转移 BTC隔离多资产 + 提供 dApp 签名原语
核心资产BTCBTC + Ordinals + Runes + BRC-20 + Rare Sats
连接标准无 / 私有 RPCBIP-322（定稿）vs 各自 window.bitcoin
用户身份地址签名（证明对地址的控制权）
竞争维度安全、易用协议覆盖 × 连接标准兼容面

这不是量变，是质变。比特币钱包从一个"保险箱"变成了一个"验证者"。它不再是替用户保管资产的终端，而是网站用来**确认"这个用户控制这把私钥"**的中间人。钱包登录（Sign in with Wallet）因此成为所有 BTC 生态应用的第一道门。

而门的钥匙，就是签名消息标准。谁的标准被广泛采纳，谁就掌握了生态入口的闸门。

六、主权个人的基础设施

对主权个人而言，浏览器钱包是唯一零门槛的自托管入口。2026 年的几个数字定义了问题的规模：

  • 全球比特币持有者估约 4.5–5.6 亿；链上非空地址 5845 万（2026-03 历史新高）。
  • 但自托管实践的只有约 3000 万人，其中"安全自托管"仅约 1000 万（Ledger 口径）。
  • 浏览器扩展仅占钱包使用量的约 12%（移动端 72%）。

浏览器钱包的分裂对主权个人的直接影响是可退出成本与依赖面：

  1. 标准依赖：没有统一连接标准，意味着每个 dApp 的兼容面由钱包决定。用户选用 Xverse，就在事实上选择了一个闭源供应商的 API 方言。
  2. 签名即身份：CIP-8 让 Cardano 用户可以用钱包签名登录 WordPress 等传统应用（已有生产级插件实现）；BIP-322 为比特币补上了同样的能力，但采纳率取决于钱包厂商。
  3. 资产安全：UTXO 保护与地址分离是 2026 年的安全底线。UniSat 的单一 Taproot 地址方案被主流评测点名警告。

主权个人的最优解是：选择开源 + 支持 BIP-322 + 地址自动分离 + 硬件钱包可配对的钱包。当前唯一同时满足前三条的是 Leather（开源 + BIP-322 + 自动分离）；Xverse 补齐硬件支持但核心闭源。

七、局限与挑战

  1. BIP-322 工具链不完整，但钱包覆盖广：浏览器钱包层面支持面广（Xverse/UniSat/Leather/Phantom/MetaMask/OKX 全员支持 signMessage），窄的是工具链：多签无法签名消息、Electrum 只支持 legacy、Coldcard/旧 Trezor 不支持，硬件钱包只能走 PSBT 流程。
  2. 验证复杂度：BIP-322 验签需解析 witness stack 并区分 Schnorr/ECDSA 及 P2TR/P2WPKH 场景，服务端实现门槛高于 CIP-8 的单一 ed25519。
  3. 无统一 provider：window.bitcoin 是非官方方言；window.unisat 被多钱包代理但无标准约束。跨钱包互操作缺失。
  4. 移动端主导：浏览器扩展仅占 12%，而登录场景多在桌面；移动钱包的 window.* 注入机制（如 WalletConnect 类桥）在比特币侧尚无 CIP-45 对应标准。
  5. 双链封闭：Lace、Brave 的 BTC 侧不开放签名；Cardano 与 BTC 的登录无法由同一款钱包同时完成，应用被迫维护两套分支。
  6. 安全责任转移：钱包厂商在"误花保护"上承担了前所未有的责任，但无统一审计与保险机制；闭源核心（Xverse）与开源（UniSat/Leather）并存，透明度参差。

八、小结

BTC 生态浏览器钱包的 2026 格局由两条轴定义：资产协议覆盖（Ordinals/Runes/BRC-20）与 dApp 签名标准（BIP-322 vs 私有方言）。Xverse 以用户量领先，UniSat 以协议深度与开源取胜，Leather 以安全与 DeFi 立身，Lace 与 Brave 证明"多链资产 ≠ 多链签名"。

BIP-322 的定稿是比特币补上"通用签名标准"这一课的关键一步——它是比特币版的 CIP-8，浏览器钱包覆盖已很广，但生态工具链（多签/冷钱包）仍不完整。任何要在 BTC 生态做钱包登录的应用，短期内的现实选择是接入 Xverse/UniSat/Leather/Phantom/MetaMask 的 BIP-322 signMessage；统一 provider 注入点、移动桥接、以及一款真正横跨两套签名标准的钱包，仍是这个生态最缺的三块拼图。

参考资源