多链支持
BNB 到 SOL、AVAX 到 TRX,一条钱包管 10 条链。除了「能用」,更重要的是「数据准确」——非 EVM 链无法用 EVM 的套路查询,本篇拆解多链接入、节点择优与资产一致性的底层实现。
0110 条链支持矩阵
AI Crypto Wallet 支持 10 条主流区块链,分为 EVM 兼容链与非 EVM 链两大类:
| 类别 | 链(标识) | 接入方式 | 原生币 |
|---|---|---|---|
| EVM 兼容链 | BNB | EVM RPC(AVE 自建代理) | BNB |
| ETH | EVM RPC | ETH | |
| MATIC(Polygon) | EVM RPC | MATIC | |
| AVAX | EVM RPC | AVAX | |
| FTM(Fantom) | EVM RPC | FTM | |
| ARB(Arbitrum) | EVM RPC | ETH | |
| OP(Optimism) | EVM RPC | ETH | |
| BASE | EVM RPC | ETH | |
| 非 EVM 链 | SOL(Solana) | Solana JSON-RPC | SOL |
| TRX(Tron) | Tron Grid API | TRX |
EVM 链共享同一套合约调用与 ABi 解析逻辑,显著降低接入成本;SOL 与 TRX 使用各自的原生 RPC 协议(详见下文「EVM / 非 EVM 原生查询」)。
02节点管理与切换
NodeManager 负责为每条链维护节点列表并择优使用,核心能力包括:
- 节点健康检查:周期性探测节点可用性。
- 延迟监控:记录每个节点的往返延迟,作为择优依据。
- 自动切换最优节点:主节点失败时自动回退备用节点。
- 链感知:每条链独立维护节点池,互不干扰。
例如 BSC 采用 AVE 自建代理节点(延迟约 200ms),而原 Defibit 节点延迟高达 835ms,NodeManager 会优先选择低延迟、高成功率的主节点。
03EVM / 非 EVM 原生查询
这是多链实现中最关键、也最容易出错的部分。ChainAPI 会根据链类型选择不同的查询协议,绝不能拿 EVM 的套路套用到 SOL/TRX。
EVM 链查询
EVM 链通过 eth_call 与 getAllTokenBalances 批量查询合约余额,支持任意只读合约调用(call_contract_read)。
非 EVM:SOL(Solana)原生查询
Solana 使用 getTokenAccountsByOwner 按所有者地址查询其持有的 SPL 代币账户,能精确返回每个代币的余额与发行方信息。
# Solana 原生查询:按所有者枚举 SPL 代币账户
POST {solana_rpc} (Content-Type: application/json)
{
"jsonrpc": "2.0",
"id": 1,
"method": "getTokenAccountsByOwner",
"params": [
"OWNER_ADDRESS",
{ "programId": "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA" },
{ "encoding": "jsonParsed" }
]
}
非 EVM:TRX(Tron)原生查询
Tron 使用 Grid API 查询地址下的 TRC20 代币余额:
# Tron 原生查询:获取地址的 TRC20 资产
GET /v1/accounts/{address}/trc20
Multicall3 是 EVM 专用聚合合约,无法用于非 EVM 链。若强行用 Multicall3 的地址查询 SOL/TRX,会返回假零余额(0),导致用户资产被误判为空。因此必须为 SOL/TRX 走各自的 getTokenAccountsByOwner 与 /v1/accounts/trc20 原生查询路径,确保数据真实。
04资产一致性与缓存
多链钱包最容易出现「切链后资产错乱」的问题。AI Crypto Wallet 通过 DataCache 严格防止跨钱包、跨链的数据串扰。
按「钱包地址 + 链」校验
所有缓存数据都以 钱包地址 + 链 作为复合 Key 校验。切换钱包或切换链时,缓存会重新按当前组合加载,绝不复用其他组合的旧数据。
钱包卡片显示所选链缓存资产
钱包卡片展示的是当前所选链的缓存资产,而非全局汇总。这样:
- 切换链时,卡片立即反映该链的真实持仓,避免「显示的是别的链的资产」。
- 缓存命中时秒开(无需重新请求),提升浏览体验。
- 缓存过期或失效时自动刷新,保证数据新鲜度。
资产一致性 = 「按钱包地址 + 链双维度隔离」+「按所选链命中的缓存」。这把「缓存提速」与「数据准确」两个目标统一起来,避免多链场景下最常见的脏数据陷阱。
05SOL 节点选择
Solana 的 RPC 节点选择尤其考究,因为公共节点差异巨大。应用采用「主节点 + 备用节点池」策略:
| 类型 | 节点 | 说明 |
|---|---|---|
| 主节点 | solana1.mytokenpocket.vip | 自选主节点,稳定且低延迟 |
| 备用节点 | api.mainnet-beta.solana.com | Solana 官方主网节点 |
api.mainnet.solana.com | Solana 官方主网节点(备用) |
被排除的节点
- publicnode:返回 403(Cloudflare 拦截),不可用,已排除。
- helius-rpc:需要 API Key,匿名访问不可用,已排除。
SOL 节点池的挑选遵循「可达性优先」:先排除已验证不可用的节点(403 / 需 key),再按延迟与稳定性排序主备用。这与 NodeManager 的链感知策略一致,保证非 EVM 查询同样稳定。
06IPv4 优先
在节点连接层面,应用默认 IPv4 优先。IPv6 在部分网络环境(尤其是国内运营商与部分企业网络)存在不稳定或不可达的情况,优先使用 IPv4 可以显著提升连接成功率与稳定性。
- 解析节点域名时优先采用 IPv4 地址。
- 当 IPv4 不可达时,再回退尝试其他记录。
- 该策略与节点切换、超时回退相结合,共同保证链上查询的高可用。
多链支持 = 10 条链的接入矩阵 + 链感知的节点择优 + 分协议的原生查询(杜绝假零余额)+ 双维度隔离的资产缓存 + 稳妥的节点与网络策略。每一层都服务于同一个目标:让每条链的数据都真实、及时、可靠。