The Bit Garden

本文从移动端工程视角，说明 Flutter + Trust Wallet Core（多为 Dart FFI）+ 节点 RPC + 区块链 在用户完成一笔链上交易时的典型分工与数据流。适用于自托管钱包、DEX 集成等场景（具体产品可能叠加网关、风控、生物识别等）。

1. 先厘清三件事

1. 区块链节点不会直接和你的手机 App「长连接握手」完成业务；App 通常通过 HTTPS 上的 JSON-RPC（或 REST） 与远程节点通信。
2. Trust Wallet Core 一类库，主体多为 C++，负责 地址派生、交易构造、数字签名、按链协议序列化；不负责替你选公共节点或发起 HTTP（由宿主 App 实现）。
3. Flutter 负责 UI 与业务状态。与 TWC 的主交互在 Gate 类集成里常见为 Dart dart:ffi 加载 libTrustWalletCore.so（iOS 为进程内 WalletCore）；MethodChannel 更常用于 生物识别、Keychain/Keystore 解锁、Host API 等，与 FFI 可并存，但不替代「Dart 直接调 TWC」。

---

2. 分层总览：谁做什么

层级	典型技术	职责
表现层	Flutter Widget	表单、确认弹窗、加载态、结果页
业务 / 状态	Bloc / Riverpod / Provider 等	参数校验、组装交易模型、编排读链 / 签名 / 广播
TWC 绑定	dart:ffi（DynamicLibrary）+ 社区/自研 Dart API	Dart 进程内调用 C API：HDWallet、AnySigner 等
可选原生协作	MethodChannel / Pigeon	生物识别、安全存储解锁、壳层 Host；不是 TWC 的必经主路径
密码学 / 链协议	Trust Wallet Core（C++ .so / xcframework）	未签名交易 → 签名 → 原始交易字节 / hex
网络	Dio / web3dart Provider / OkHttp 等	调 RPC：读 nonce、余额、estimateGas；写 eth_sendRawTransaction 等
链	公链节点集群	验证交易、广播、mempool、出块

核心结论：「上链」在工程上 = 库内完成签名 + 网络层把已签名交易发给节点；在 Flutter 内置钱包场景下，签名一步多为 FFI → TWC。

---

3. 架构图：从界面到链（FFI 主路径）

flowchart TB
  subgraph UI["表现层"]
    F["Flutter Widget\n按钮、金额、链选择、确认弹窗"]
  end

  subgraph VM["业务层"]
    B["Flutter 业务逻辑\n校验、状态机、组装交易参数"]
  end

  subgraph Opt["可选：原生协作"]
    CH["MethodChannel / Pigeon\n生物识别、解锁密钥材料"]
    N1["Kotlin / Swift\nKeychain / Keystore"]
  end

  subgraph Crypto["密码学（同进程）"]
    FFI["dart:ffi\nDynamicLibrary.open"]
    N2["Trust Wallet Core\n(C++ 动态库)\n交易体 + 签名"]
  end

  subgraph Net["网络层"]
    H["HTTP / web3dart"]
    RPC["节点 RPC\nJSON-RPC / REST"]
  end

  subgraph Chain["区块链"]
    BC["共识与出块"]
  end

  F --> B
  B -.->|若产品要求| CH --> N1
  B --> FFI --> N2
  N2 -->|"signed tx"| B
  B --> H --> RPC --> BC

---

4. 主流程时序图：用户点击「确认」之后

以下为 Dart FFI 调 TWC 签名，RPC 由 Flutter / web3dart 发起 的常见形态（与 gate_global.apk 中 flutter_trust_wallet_core / ffi_impl 证据一致）。

sequenceDiagram
  autonumber
  participant U as 用户
  participant W as Flutter UI
  participant B as Flutter 业务层
  participant N as 原生宿主（可选）
  participant TWC as Trust Wallet Core（FFI）
  participant RPC as 节点 RPC
  participant BC as 区块链

  U->>W: 点击确认交易
  W->>B: 提交 to / amount / chainId 等
  B->>B: 校验与组装参数

  opt 生物识别 / 解锁安全存储
    B->>N: MethodChannel（一次性）
    N-->>B: 通过 / 取消
  end

  B->>RPC: 读链：nonce、fee、余额等
  RPC-->>B: 返回值

  B->>TWC: FFI：构造未签名交易并签名
  TWC-->>B: 已签名交易 hex / bytes

  B->>RPC: 写链：eth_sendRawTransaction 等
  RPC->>BC: 广播
  BC-->>RPC: 返回 tx hash
  RPC-->>B: tx hash

  B-->>W: 更新 UI
  W-->>U: 展示哈希 / 区块浏览器

步骤解读

1. 用户操作：仅在 UI 层。
2. 业务层：产品规则校验（限额、格式），编排后续步骤。
3. 可选 MethodChannel：仅当策略要求签名前走原生认证 / 解锁；不是「每笔签名都经 Channel 调 TWC」。
4. 读链 RPC：nonce、gas 等与签名无关的只读，走 HTTP / JSON-RPC。
5. TWC（FFI）：输入链类型、账户、交易内容，输出 签名后的原始交易。
6. 写链 RPC：将已签名交易发给节点。
7. 链：打包与确认。

---

5. 变体：若团队把签名完全下沉到原生

少数架构会让 原生 Kotlin/Swift 再调 TWC（JNI / Swift 绑定），Dart 只经 MethodChannel 拿 signedHex。这与 Dart FFI 直调 .so 是两条不同集成路径；Gate 类 Flutter 包证据指向后者为主。

sequenceDiagram
  participant B as Flutter
  participant CH as MethodChannel
  participant N as 原生
  participant TWC as Trust Wallet Core
  participant RPC as 节点

  Note over B,TWC: 变体：签名在原生侧完成（非 Gate FFI 主路径）
  B->>CH: signOnly(unsignedTxParams)
  CH->>N: 
  N->>TWC: 签名（JNI / 绑定）
  TWC-->>N: signed hex
  N-->>CH: 
  CH-->>B: signed hex

  B->>RPC: eth_sendRawTransaction(signedHex)
  RPC-->>B: tx hash

---

6. 数据流简图：字节往哪走

flowchart LR
  subgraph in["输入"]
    A1["用户输入\n地址、金额"]
    A2["链与合约参数\nchainId、ABI、nonce"]
  end

  subgraph twc["Trust Wallet Core（经 FFI）"]
    S["编码 + 签名\n→ raw transaction"]
  end

  subgraph out["对外"]
    H["0x… 已签名交易"]
    TX["交易哈希"]
  end

  A1 --> S
  A2 --> S
  S --> H
  H -->|"HTTPS JSON-RPC"| RPC["节点"]
  RPC --> TX

---

7. Trust Wallet Core 与「和链交互」的关系

• 开发语言：核心为 C++；Android 为 libTrustWalletCore.so，iOS 为 xcframework。
• Flutter 绑定：常见为 Dart FFI（DynamicLibrary.open / DynamicLibrary.process）+ Dart API；插件注册（如 TrustWalletCorePlugin）多用于打包与初始化，日常 HDWallet / 签名不走 MethodChannel 转发 TWC。
• 和链的交互方式：
  • 库内部：密码学、交易结构、签名算法、各链差异。
  • 库外部：App 用 RPC 把 signed transaction 和只读请求发到节点；协议多为 JSON-RPC。

因此：「与区块链交互」在实现上 = RPC 上的读写；TWC 负责产生可被链接受的那串字节。

---

8. 安全与工程要点

• 私钥与助记词：优先 Keychain / Keystore / 硬件模块；即便签名走 FFI，仍应控制明文在 Dart 中的暴露面，并按产品策略叠加生物识别。
• Channel 传参：若用 MethodChannel，传 交易参数、链 ID、认证结果，不传私钥明文。
• RPC 端点：生产环境常配合 证书钉扎、代理、自有网关。
• 重放与链切换：正确设置 chainId（EIP-155）。

---

9. 与「交易所托管」模式的对比（扩展）

若业务是 CEX 托管钱包，时序里往往在 用户确认 之后增加 服务端：风控、限额、内部记账，再由服务端或专用签名机与链交互。此时与纯 自托管 + TWC（FFI） 的图不同。

---

10. 小结

问题	答案
Flutter 怎么「上链」？	FFI（或少数架构下的原生）完成签名 + HTTP JSON-RPC 广播 / 查回执。
TWC 与 Dart 怎么交互？	Gate 类证据：Dart FFI → libTrustWalletCore.so；MethodChannel 多为生物识别 / Host。
TWC 做什么？	交易构造与签名（C++ 库）。
链从哪里来？	远程节点；广播即节点接受 sendRawTransaction。

---

文档为通用架构说明；Gate App 逆向结论仅作绑定方式参考，具体产品以实际源码与策略为准。