浏览器插件钱包技术实现 ​

本文档介绍浏览器插件钱包的技术架构，包括多链账户体系、Keyring 密钥管理、DApp Provider 注入、交易签名全链路等核心实现。

一、架构总览 ​

1.1 三大运行环境 ​

浏览器插件钱包运行在三个独立环境中，各司其职：

1.2 全链路架构 ​

从区块链节点到用户界面的完整链路：

各层职责：

二、账户体系 ​

2.1 多链钱包 SDK 注册 ​

每条链的账户创建、公钥生成、地址生成、签名操作均由独立的 SDK 完成：

注册模式统一为 (currency, WalletInstance) 映射：

// 钱包 SDK 配置
const wallets = [
  { currency: Currency.BTC, wallet: BtcWallet },
  { currency: Currency.ETH, wallet: EthWallet },
  { currency: Currency.SOL, wallet: SolanaWallet },
  // ...
];

// 统一注册
const registerWallet = (wallets, register) => {
  wallets.forEach(({ currency, wallet: Wallet, hook }) => {
    hook && hook();
    register(currency, new Wallet());
  });
};

2.2 Keyring 密钥管理 ​

Keyring 是密钥管理的核心模块，负责 HD 派生路径配置和多链密钥的统一管理：

派生路径配置示例（BTC）：

测试网使用 coin_type = 1（如 m/84'/1'/0'/0/{index}）。

Keyring 查找逻辑：

// 根据链名称获取 HDKeyring 类
const getHDKeyringByChain = (baseChain, coinType) => {
  if (typeof coinType === 'undefined') {
    throw new Error(`Cannot find HDKeyring for chain: ${baseChain}`);
  }
  return hdKeyringMap[baseChain] || hdKeyringMap.default;
};

2.3 网络配置 ​

每条链需要配置三个核心标识：

网络配置包含完整的链元数据：

{
  baseChain: 'bitcoin',
  chainId: 0,
  chainName: 'Bitcoin',
  coinId: 1,
  coinType: 0,
  decimalNum: 8,
  symbol: 'BTC',
  localType: 'bitcoin',
  providerType: 'bitcoin',
  // ...
}

三、转账模块 ​

3.1 发送交易 ​

发送交易由三个核心页面组成，每条链独立实现：

路由配置：通过 configs 匹配链类型，动态加载对应组件：

// 根据 baseCoinId 和 coinId 匹配对应链的发送页面
const config = configs.find(({ match }) => {
  return match(baseCoinId, coinId, protocolId);
});

const { AddressPage, AmountPage, ConfirmPage } = config.pages;

3.2 接收资产 ​

相对简单的模块，由 symbol（币种）、chainName（链名）、address（地址）组成收款码页面。

3.3 交易历史 ​

标准的订单 CRUD 操作，从后端服务读取和更新交易记录。

四、DApp 交互 ​

4.1 Provider 注入 ​

浏览器插件通过 Inpage 脚本向每个 DApp 页面注入 Provider 对象，使 DApp 能与钱包通信：

每条链的 Provider 独立创建：

// 创建 Bitcoin Provider
const createBitcoinInpageProvider = () => {
  const BaseBitcoinInpageProvider = createBaseBitcoinInpageProvider({
    providerType: PROVIDER_BITCOIN,
    localType: BITCOIN
  });

  return class BitcoinInpageProvider extends BaseBitcoinInpageProvider {
    constructor(connectionStream, { jsonRpcStreamName, logger, provider }) {
      super(connectionStream, { jsonRpcStreamName, logger, provider });
      provider.bitcoin = this;  // 挂载到 window 对象
    }
  };
};

4.2 Middleware 路由 ​

Provider 的 RPC 请求通过 Middleware 路由到对应的处理函数：

BTC Middleware 支持的 RPC 方法：

4.3 签名与广播 ​

DApp 交易签名后的处理流程：

签名后数据处理关键步骤：

1. 使用 SDK 计算 txHash
2. 构建广播参数（from、to、coinAmount、signedTx 等）
3. 根据交易来源选择广播接口（DApp / DEX）
4. 更新 DApp 请求状态

4.4 BTC 铭文操作（Mint / Etch） ​

BTC 铭文操作（BRC-20、Runes）有独立的签名流程：

Runes Mint 签名数据结构：

const signData = {
  type: 'RUNEMAIN',
  inputs: utxo.map(item => ({
    ...item,
    privateKey,
    publicKey,
    address,
  })),
  outputs: [{
    address,
    amount: outValue,
    data: inscriptions[0],
  }],
  runeData: {
    etching: null,
    useDefaultOutput: false,
    defaultOutput: 0,
    burn: false,
    mint: true,
    mintNum: inscriptions.length,
  },
  feePerB: satBytes,
};

五、UI 层模块划分 ​

5.1 页面模块结构 ​

5.2 DApp 交易确认 ​

DApp 交易确认采用类型转发模式，根据链和方法动态路由到对应 UI 组件：

// 根据请求类型路由到对应确认页面
switch (method) {
  case BTCRequestEnum.SIGN_MESSAGE:
    return <SignMessage unapproved={unapproved} />;
  case BTCRequestEnum.MINT:
    return <Mint unapproved={unapproved} />;
  case BTCRequestEnum.WATCHASSET:
    return <WatchAsset unapproved={unapproved} />;
  // ...
}

每个 DApp API 接口的支持程度不同，各页面自行控制错误提示和功能限制：

六、状态管理 ​

6.1 Redux 架构 ​

插件使用 Redux 管理全局状态：

6.2 BG-UI 通信 ​

Background 和 UI 之间通过适配层通信，业务逻辑对底层通信方式无感知：

七、多链支持策略 ​

7.1 新链接入清单 ​

接入一条新链需要完成以下模块的配置：

7.2 目前支持的链生态 ​

总结 ​

浏览器插件钱包的核心架构围绕 Background（后台服务）+ UI（用户界面）+ Inpage（DApp 注入） 三大运行环境构建：

1. 账户体系：通过统一的钱包 SDK 注册和 Keyring 密钥管理，支持数十条链的密钥派生和签名
2. DApp 交互：通过 Provider 注入 + Middleware 路由 + Handler 处理的三层架构，实现多链 RPC 方法的统一管理
3. 状态管理：Redux + backgroundConnect 的通信适配层，使 BG-UI 跨进程通信对业务透明
4. 可扩展性：新链接入只需按标准化流程配置 SDK → Keyring → Provider → Middleware → UI 页面