发表更新Web3 / Wallet21 分钟读完 (大约3110个字)

Trust Wallet Core 功能路径总览：从助记词到多链签名

摘要

Trust Wallet Core 可以理解成一个多链钱包底层库：它主要处理本地的助记词、HD 派生、私钥/公钥、地址、交易/消息编码与签名。它不是 web3.js、ethers.js 那种面向节点 RPC 与合约交互的网络层，也不负责行情、余额索引、广播重试、风控或账户体系。

更准确的一句话是：

Trust Wallet Core 负责把「本地密钥材料」变成「多链地址」和「可广播/可验证的签名结果」；链上参数查询、交易广播、回执轮询和业务风控由 App、后端或 RPC 层完成。

一、先看整体定位

在一个内置钱包或多链 App 里，链路通常可以拆成三层：

层级 典型职责 Trust Wallet Core 是否负责
钱包底层 助记词、派生路径、私钥、公钥、地址、签名、交易编码 负责
链上通信 JSON-RPC、节点 Provider、广播 raw transaction、查询 receipt 不负责
产品业务 账户体系、KYC、风控、行情、报价、路由、资产聚合 不负责

所以它和 web3.js / ethers.js 的定位并不相同。web3.js 更偏「和 EVM 节点对话」，Trust Wallet Core 更偏「本地多链签名器 + 地址/编码工具」。

二、主功能路径图

%%{ init: { "flowchart": { "nodeSpacing": 32, "rankSpacing": 54, "padding": 14, "htmlLabels": true } } }%%
flowchart LR
  A["输入来源
助记词 / Seed / 私钥 / Keystore
链参数 / 交易参数"]
  B["密钥树
BIP39 / BIP32 / BIP44
CoinType / 派生路径"]
  C["地址与账户
子私钥 / 公钥 / 链地址
地址校验 / 多链格式"]
  D["交易或消息准备
SigningInput / ABI / RLP / Script
各链 Proto"]
  E["签名与编码
AnySigner / MessageSigner
TransactionCompiler"]
  F["输出给业务层
地址 / signature / raw tx
error / txHash 前数据"]
  G["业务层继续处理
RPC 广播 / receipt 轮询
状态展示 / 风控"]

  A --> B --> C --> D --> E --> F --> G

这张图里最重要的边界是：Wallet Core 到 F 基本就结束了。拿到签名或 raw transaction 以后，是否广播、发到哪个节点、失败怎么重试、最终状态怎么落库，都属于业务层。

三、逐层拆解

1. 密钥材料层

输入可以是：

  • 新生成的随机熵；
  • BIP39 助记词；
  • seed；
  • 已有私钥；
  • 加密过的 keystore / stored key。

对应的能力包括：

  • TWMnemonic：助记词校验与相关工具；
  • TWHDWallet：HD 钱包；
  • TWPrivateKey / TWPublicKey：私钥、公钥；
  • TWStoredKey：本地加密存储容器。

这里容易误解的是：HD 钱包不是一把私钥挂很多账户名。更准确地说，同一个助记词会得到同一个种子，种子再生成一棵确定性的密钥树；树上的不同路径通常对应不同子私钥。

2. 派生路径层

BIP44 常见路径格式：

1
m / purpose' / coin_type' / account' / change / address_index

例如 Ethereum 常见第一个地址：

1
m/44'/60'/0'/0/0

其中：

  • 44'：表示 BIP44；
  • 60'：Ethereum 的 coin type；
  • 0'：第 0 个账户；
  • 0：外部收款地址链；
  • 0：第 0 个地址索引。

Trust Wallet Core 通过 CoinType 和派生路径，把同一套助记词映射到不同链、不同账户和不同地址。

3. 地址层

地址不是简单地把公钥转成字符串。不同链的规则差异很大：

  • EVM：公钥哈希后得到 0x 地址；
  • Bitcoin：P2PKH、P2SH、Bech32 等不同格式；
  • Solana：基于 Ed25519 公钥和 Base58；
  • Tron：地址格式和 EVM 有亲缘关系，但展示格式不同；
  • Filecoin、Cosmos、TON 等又有各自规则。

这一层典型 API 包括：

  • TWAnyAddress：统一多链地址入口；
  • TWCoinTypeConfiguration：链的展示名、符号、小数位等配置；
  • 各链专用 Address 工具：如 Bitcoin、SegWit、Solana、Filecoin 等。

4. 交易 / 消息准备层

签名之前，业务层通常要先准备好链上参数：

  • EVM：chainId、nonce、gasLimit、maxFeePerGas、to、value、data；
  • UTXO 链：UTXO 列表、脚本、找零地址、手续费率；
  • Cosmos 类：account number、sequence、fee、memo；
  • Solana：recent blockhash、instructions；
  • 合约交互：ABI、method、参数、calldata。

Trust Wallet Core 不会替你查这些数据。它需要你把这些参数填进对应链的 SigningInput，然后再做编码和签名。

5. 编码与预签名层

不同链“到底签什么”并不一样。

EVM 里可能涉及：

  • ABI 编码；
  • RLP 编码；
  • legacy transaction；
  • EIP-1559 transaction；
  • EIP-712 typed data；
  • ERC20 / ERC721 / ERC1155 的 calldata。

Bitcoin 类链则更多涉及：

  • UTXO；
  • Script；
  • sighash；
  • 找零；
  • 输入输出排序与序列化。

所以 Wallet Core 不只是“拿私钥签一下 hash”，它还包含大量链特定编码规则。

6. 签名输出层

常见输出有三类：

  1. 地址类输出：例如 ETH 地址、BTC 地址、Solana 地址；
  2. 消息签名输出：例如登录签名、Typed Data 签名、授权签名；
  3. 交易签名输出：例如可广播的 raw transaction。

典型入口：

  • TWAnySigner：多链统一签名入口；
  • TWEthereumMessageSigner、TWBitcoinMessageSigner、TWTronMessageSigner 等：链特定消息签名；
  • TWTransactionCompiler：更底层的交易编译/签名辅助。

四、EVM 签交易路径

%%{ init: { "sequence": { "mirrorActors": false, "messageAlign": "center", "showSequenceNumbers": true } } }%%
sequenceDiagram
  participant U as 用户
  participant App as App/Flutter
  participant RPC as RPC/后端
  participant TWC as Trust Wallet Core

  U->>App: 输入收款地址、金额，点击发送
  App->>RPC: 查询 chainId、nonce、gas、余额
  RPC-->>App: 返回链上参数与手续费建议
  App->>App: 组装 to / value / data / fee
  App->>TWC: 构造 Ethereum SigningInput
  TWC->>TWC: ABI/RLP/交易类型编码
  TWC->>TWC: 使用派生私钥签名
  TWC-->>App: 返回 encoded raw transaction
  App->>RPC: eth_sendRawTransaction
  RPC-->>App: 返回 txHash
  App->>RPC: eth_getTransactionReceipt 轮询
  RPC-->>App: 返回成功/失败/待确认
  App-->>U: 展示交易状态

这条路径中，Trust Wallet Core 的关键职责是：

  • 根据 EVM 规则构造待签名数据；
  • 用本地私钥签名；
  • 输出 raw transaction。

它不负责：

  • 估 gas；
  • 查询 nonce；
  • 发 RPC；
  • 判断交易最终是否成功。

五、BTC / UTXO 类链签交易路径

%%{ init: { "sequence": { "mirrorActors": false, "messageAlign": "center", "showSequenceNumbers": true } } }%%
sequenceDiagram
  participant U as 用户
  participant App as App/Flutter
  participant Indexer as 节点/索引服务
  participant TWC as Trust Wallet Core

  U->>App: 输入目标地址与金额
  App->>Indexer: 查询可用 UTXO 与推荐费率
  Indexer-->>App: 返回 UTXO 列表、余额、feeRate
  App->>App: 选币、计算找零、准备输出
  App->>TWC: 构造 Bitcoin SigningInput
  TWC->>TWC: 处理 Script / sighash / 序列化
  TWC->>TWC: 使用对应私钥签名各输入
  TWC-->>App: 返回 signed transaction
  App->>Indexer: 广播 raw transaction
  Indexer-->>App: 返回 txid
  App-->>U: 展示提交结果与确认状态

UTXO 类链和 EVM 最大的差别是：业务层要提前拿到 UTXO 并完成选币/找零策略。Wallet Core 可以帮你签，但它不知道你的后端如何索引 UTXO，也不知道你的产品想怎么控制手续费和找零。

六、创建 / 恢复钱包并导出地址时序图

%%{ init: { "sequence": { "mirrorActors": false, "messageAlign": "center", "showSequenceNumbers": true } } }%%
sequenceDiagram
  participant U as 用户
  participant App as App/Flutter
  participant TWC as Trust Wallet Core
  participant Safe as 安全存储

  U->>App: 点击创建钱包或导入助记词
  App->>TWC: 创建 HDWallet 或用助记词恢复
  TWC->>TWC: BIP39 校验，seed -> master key
  App->>TWC: 指定 CoinType 与派生路径
  TWC->>TWC: 派生子私钥 -> 公钥 -> 地址
  TWC-->>App: 返回地址 / account 信息
  App->>Safe: 加密保存助记词、私钥或 StoredKey
  App-->>U: 展示地址与备份提醒

这张图可以帮助区分两件事：

  • Trust Wallet Core 负责算出地址；
  • App 负责安全存储、备份提醒、二次验证、恢复流程。

安全存储不是简单把助记词放本地。生产环境还要考虑：

  • 本地加密；
  • 生物识别；
  • 截屏防护；
  • Root / 越狱检测；
  • 备份引导；
  • 用户忘记密码后的恢复策略；
  • 风控与异常设备判断。

七、BIP39 / BIP32 / BIP44 的生成与派生时序图

这三者在钱包创建链路里的职责不同：

  • BIP39：负责「随机熵 → 助记词」以及「助记词 → seed」。
  • BIP32：负责「seed → master node」以及「父节点 → 子节点」的密钥树派生。
  • BIP44：负责规定 BIP32 这棵树的路径结构，例如 m/44'/60'/0'/0/0。
%%{ init: { "sequence": { "mirrorActors": false, "messageAlign": "center", "showSequenceNumbers": true } } }%%
sequenceDiagram
  participant Wallet as 钱包业务
  participant RNG as 安全随机数
  participant B39 as BIP39
  participant B32 as BIP32
  participant B44 as BIP44 路径规范
  participant Chain as 链地址规则

  Wallet->>RNG: 请求创建新钱包
  RNG-->>B39: entropy 随机熵
  B39->>B39: entropy + checksum
  B39->>B39: 按 11 bit 映射到 BIP39 词表
  B39-->>Wallet: mnemonic 助记词

  Wallet->>B39: mnemonic + 可选 passphrase
  B39->>B39: PBKDF2-HMAC-SHA512
  B39-->>B32: seed

  B32->>B32: HMAC-SHA512(key="Bitcoin seed", data=seed)
  B32->>B32: 左半部分 = master private key
  B32->>B32: 右半部分 = master chain code
  B32-->>Wallet: master node 根节点

  Wallet->>B44: 选择币种、账户和地址索引
  B44-->>Wallet: 路径 m/44'/60'/0'/0/0

  Wallet->>B32: 按 BIP44 路径逐层派生
  B32->>B32: 44' hardened
  B32->>B32: 60' hardened
  B32->>B32: 0' hardened
  B32->>B32: 0 non-hardened
  B32->>B32: 0 non-hardened
  B32-->>Wallet: leaf child private key + chain code

  Wallet->>Chain: private key -> public key -> address
  Chain-->>Wallet: 目标链地址

所以流程不是「BIP39、BIP32、BIP44 三个并列模块各做一段业务」，而是：

1
2
3
4
BIP39 生成助记词和 seed
  -> BIP32 生成根节点并负责派生算法
  -> BIP44 提供路径规范
  -> BIP32 按该路径逐层派生到具体地址

八、模块能力地图

功能域 典型模块 / API 解决的问题
钱包与密钥 HDWallet、Mnemonic、PrivateKey、PublicKey、StoredKey 助记词、派生、私钥/公钥、加密存储
地址体系 AnyAddress、CoinType、各链专用 Address 生成、解析、校验、展示链地址
交易签名 AnySigner、各链 SigningInput、TransactionCompiler 把结构化输入变成签名后的链上数据
消息签名 Ethereum / Bitcoin / Tron / Tezos 等 MessageSigner 登录、授权、Typed Data、链特定消息
编码与密码学 Hash、AES、PBKDF2、Base58、Bech32、RLP、ABI 底层编码、哈希、KDF、ABI 编解码
链特化能力 Bitcoin Script、THORChainSwap、LiquidStaking 等 部分链的脚本、质押、Swap、特殊交易
平台集成 C ABI、Swift、Kotlin/JNI、WASM、NPM、Go 等 把 C++ 核心暴露给移动端和其它运行时
不包含的业务层 RPC、行情、回执、KYC、风控 这些通常由 App、后端或节点服务完成

九、看源码或文档时怎么找

想确认什么 看哪里 能回答的问题
支持哪些链 docs/registry.md / registry.json 有没有这个 CoinType / 网络
公开 C API include/TrustWalletCore/TW*.h 外部能调用哪些核心能力
每条链交易结构 src/proto/*.proto SigningInput / SigningOutput 长什么样
链实现细节 src/<ChainName>/ 地址、签名、序列化到底怎么实现
真实参数示例 tests / samples 业务参数应该怎么填

如果是在 Flutter 项目里用社区绑定，通常会再多一层：

1
2
3
4
5
Flutter/Dart
  -> trust_wallet_core Dart API
  -> FFI / Plugin
  -> WalletCore native library
  -> C++ core

也就是说，Dart 侧看到的 HDWallet、TWCoinType、AnySigner 等只是绑定层暴露出来的入口，真正的链规则和签名实现仍在 native 库里。

十、总结

Trust Wallet Core 的主线可以记成：

1
2
3
4
5
6
7
8
助记词 / Seed / 私钥
  -> BIP39 / BIP32 / BIP44 派生
  -> 子私钥 / 公钥 / 链地址
  -> SigningInput / MessageInput
  -> ABI / RLP / Script / Proto 编码
  -> 签名
  -> raw transaction / signature / address
  -> 业务层 RPC 广播或服务端验签

它的核心价值不是“替你完成整个 Web3 业务闭环”，而是把最容易出错、最依赖链规则的本地钱包底层能力统一起来：密钥、地址、编码、签名。

换句话说：

  • Trust Wallet Core 管私钥和签名；
  • RPC / Provider 管链上读写；
  • App / 后端管产品闭环。

把这三层分清，后面无论接 Flutter、原生、WalletConnect、还是自研后端网关，架构边界都会清楚很多。

Trust Wallet Core 功能路径总览：从助记词到多链签名

https://bitgarden.cn/2025/02/03/Web3/TrustWalletCore-功能路径总览/

作者

Felix Tao

发布于

2025-02-03

更新于

2026-03-04

许可协议

#
关注我

链接

分类

最新文章

归档

标签

AI1
Activity2
Algorithm7
Android9
Architecture5
ArkTS1
Backend1
Blockchain3
Browser1
Combine1
Component3
Components2
Concurrency1
Cpp1
Cross-Platform4
Dart3
Design Patterns1
DevOps1
EIP15591
Electron2
Ethereum5
Event Loop1
Fiber2
Flutter14
GCD1
Gas1
HarmonyOS4
Hooks2
Hot Update2
Image Loading1
JSON-RPC1
JSPatch1
JavaScript3
Jetpack Compose1
KMP1
Kotlin1
MCP1
Memory Safety1
Mermaid2
Modular3
Multithreading1
Native Bridge1
Navigator2
Next.js1
Nginx1
Node.js1
Objective-C1
Optimization1
Performance2
Platform Channel2
Q-A1
React8
React Native3
Reactive1
Reactive Programming2
ReactiveCocoa1
Routing2
RunLoop1
Runtime1
Rust1
RxJava1
RxSwift2
SDWebImage1
Scheduling1
Service2
Skills1
Smart Contract1
Solana1
Solidity1
State Management4
Swift1
SwiftUI1
Systems Programming1
Taro1
Tools2
Trust Wallet Core1
VSCode1
Viem1
Wagmi1
Wallet2
WalletConnect1
Web39
Workflow1
ethers.js2
go_router1
iOS14
npm1
代码审查1
跨平台1

订阅更新

follow.it

×