交易所钱包系统开发 #6 - 接入 Solana 链

上一篇我们把交易所风控体系补齐，这一篇给交易所钱包接入 Solana 链。Solana 的账户模型、日志存储和确认机制与以太坊系链有很大的不同，如果沿用以太坊套路，还是很容易踩坑的。下面我们梳理一下记录Solana 的整体思路。

了解独特的 Solana

Solana 账户模型

Solana 使用程序与数据分离的模型，程序是可以共用的，而程序的数据是通过 PDA（Program Derived Address）账户单独保存的，由于程序是共用的，因此需要 Token Mint 来区别不同的 Token。Token Mint 账户存储代币的全局元数据，存储例如 <strong>铸造权限（mint_authority）</strong>、 <strong>总供应量（supply）</strong>、 小数位数（decimals） 等， 每个代币都有唯一的 Mint 账户地址作为标识符，例如 USD Coin（USDC）在 Solana 主网的 Mint 地址是 EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v。

Solana 上两套 Token 程序，一个是SPL Token，一个是SPL Token-2022，每种 SPL Token 都有独立的 ATA（Associated Token Account）来保存用户的余额，在 Token 转账时，实际上是调用各自的程序在 Token 在 ATA 账户之间在转移。

Solana 日志限制

在以太坊上，是通过解析历史的转账日志来获取 Token 转账的，但是 Solana 的执行日志默认不会永久保留，Solana 的日志不属于账本状态（state）的（也没有日志的布隆过滤器），并且可能在执行过程中截断输出。 因此，我们不能通过“扫描日志”来做充值对账，而是要使用 getBlock 或者 getSignaturesForAddress 来解析指令。

Solana 确认与重组

Solana 出块时间为 400ms，经过 32 个确认（大概 12 s）会达到 finalized ， 如果实时性要求不高的话，简单的方法是只信任 finalized 的区块。 如果想要更高的实时性，就需要考虑可能会出现的区块重组，尽管较少出现。但是 Solana 共识不依赖 parentBlockHash 形成链结构，不能像类似以太坊那样通过 parentBlockHash 和数据库中的 blockHash 不一样来判断分叉。那应该使用怎样方法来判断区块被重组了呢？ 在本地扫块时，我们要记录 slot 的 blockhash ，如果出现同 slot 的 blockhash 有变化，那就说明发生了回滚。

理解 Solana 的不同，接下来就可以着手实现了，先看看数据库要做怎样的修改：

数据库表设计

由于 Solana 有两种类型的 Token ， 因此，我们需要在 tokens 表上，添加一个 token_type 用来区分 spl-token 和 spl-token-2022

Solana 地址尽管和以太坊不一样，但是同样可以通过 BIP32、BIP44 衍生，只不过衍生的路径不一样而已，因此只需要使用原有 wallets 表，但为了支持 ATA 地址映射，Solana 扫块追踪，需要添加以下三张表：

其中：

• solana_slots 会记录 confirmed/finalized/skipped，扫描器根据状态决定是否落库或回滚。
• solana_transactions 以 lamports 或 token 最小单位入库，并带 type 字段区分 deposit/withdraw 等业务场景，敏感写入仍需风控签名。
• solana_token_accounts 与 wallets/users 建立外键关系，保证 ATA 的唯一性（wallet_address + token_mint 唯一），也是扫描逻辑的核心索引。

详细表定义可参考 db_gateway/database.md

处理用户充值

处理用户充值，需要不断的扫描 Solana 链上数据，通常有两个方法：

1. 扫签名：getSignaturesForAddress()
2. 扫块：getBlock()

方法 1 ：扫地址的签名，通过调用 getSignaturesForAddress(address, { before, until, limit })，传入我们关注的地址作为参数，这个地址是我们为用户生成的 ATA 地址，也可以是 programID（注意 spl-token 的 transfer 指令调用是不包含 mint 地址的) 并通过控制 before、 until 参数不断的 拉取增量签名，然后在通过getTransaction(signature) 获取交易的信息数据。

这个方法可以适合数据量或账号较少的情况，如果账户数非常大，使用扫块更适合，我们这里就是使用扫块方法。

方法 2：扫块的方法是不断是拿到最新的 Slot, 调用 getBlock(slot) 获取完整的交易详细信息、签名或帐户，然后获取根据指令与账户，过滤出我们所需要的数据。

备注：由于 Solana 交易流量大、TPS 高，在生产环境中，很可能出现解析过滤速度跟不上 Solana 的出块速度，这时需要使用消息队列，简单过滤出所有的 token 转账，将可能的“潜在充值事件” 推送到如 Kafka/RabbitMQ 消息队列，再由后续的队列消费者模块精准过滤并写入数据库中，为了加快过滤效率，一些热点数据需要保存在 Redis，避免队列堆积。如果用户地址非常多，可以按 ATA 地址分片，多个消费者监听不同分片来提高效率。

如果不想自己扫块，还有一个方法是使用第三方 RPC 服务商提供额外的 Indexer 服务， 例如提供 Webhook、账号 Account 监听与高阶的过滤支持，可承担大数据量解析压力。

扫块流程

我们使用了方法二，相关代码在 scan/solana-scan 模块下的 blockScanner.ts 和 txParser.ts，主要流程如下：

1. 初始同步阶段、补历史区块（performInitialSync）

• 从上次扫描的 slot 开始，逐个扫描到最新的 slot
• 每 100 个 slot 检查是否有新 slot 产生，动态更新目标
• 使用 confirmed commitment 获取区块，兼顾实时性

2. 扫描阶段（scanNewSlots）

• 不断检查是否有新 slot 产生
• 重新验证最近的 confirmed slot（检测回滚）

3. 区块解析（txParser.parseBlock）

• 调用 getBlock(slot, { commitment: "confirmed", encoding: "jsonParsed" })
• 遍历每笔交易的 transaction.message.instructions 和 meta.innerInstructions
• 只处理成功的交易（tx.meta.err === null）

4. 指令解析（txParser.parseInstruction）

• SOL 转账：匹配 System Program (11111...) 的 transfer 类型, 地址直接匹配 destination 地址是否在监控地址列表中
• SPL Token 转账：匹配 Token Program 或 Token-2022 Program 的 transfer/transferChecked，destination 匹配 ATA 地址，然后通过数据库映射到钱包地址和 TokenMint 地址。

回滚具体处理： 程序会不断的获取 finalizedSlot，当 slot ≤ finalizedSlot 时标记为 finalized，对于依旧在 confirmed 状态的块，判断 blockhash 是否更改来判断回滚。

示例核心代码如下：

// blockScanner.ts - 扫描单个槽位
async scanSingleSlot(slot: number) {
  const block = await solanaClient.getBlock(slot);
  if (!block) {
    await insertSlot({ slot, status: 'skipped' });
    return;
  }

  const finalizedSlot = await getCachedFinalizedSlot();
  const status = slot <= finalizedSlot ? 'finalized' : 'confirmed';

  await processBlock(slot, block, status);
}

// txParser.ts - 解析转账指令
for (const tx of block.transactions) {
  if (tx.meta?.err) continue; // 跳过失败的交易

  const instructions = [
    ...tx.transaction.message.instructions,
    ...(tx.meta.innerInstructions ?? []).flatMap(i => i.instructions)
  ];

  for (const ix of instructions) {
    // SOL 转账
    if (ix.programId === SYSTEM_PROGRAM_ID && ix.parsed?.type === 'transfer') {
      if (monitoredAddresses.has(ix.parsed.info.destination)) {
         // ...
      }
    }

    // Token 转账
    if (ix.programId === TOKEN_PROGRAM_ID || ix.programId === TOKEN_2022_PROGRAM_ID) {
        if (ix.parsed?.type === 'transfer' || ix.parsed?.type === 'transferChecked')) {
          const ataAddress = ix.parsed.info.destination; // ATA 地址
          const walletAddress = ataToWalletMap.get(ataAddress); // 映射到钱包地址
          if (walletAddress && monitoredAddresses.has(walletAddress)) {
            // ...
          }
      }
    }
  }
}

在扫描到充值交易后，沿用 DB Gateway + 风控双签名的安全，在验证之后，将数据写入的资金流水表中 credits。

提现

Solana 的提现流程与 EVM 链类似，但在交易构建有差异：

1. 在 Solana 上，有两种 Token： 普通 SPL-Token 和 SPL-Token 2022，两个 Token 的programID 是不同的，在构造交易指令时，需要区分。（当前 SPL-Token 2022 比较少，也可以选择不支持 token 2022 ）

2. Solana 的交易由两部分组成：signatures（一组 ed25519 签名）和 message（包含 header、accountKeys、recentBlockhash、instructions）message 的内容被哈希并被签名，放在signatures。在 Solana 交易中没有 nonce，而是使用 recentBlockhash 来约束交易有效期，recentBlockhash 只有 150 个区块的有效期（约 1 分钟），因此每次发起交易时 recentBlockhash 需要从链上实时获取到最新的 recentBlockhash，如果提现交易需要人工审核，那就的重新获取 recentBlockhash 够着交易结构再次请求签名。

提现流程

sequenceDiagram

    participant 用户
    participant wallet
    participant 风控    
    participant 签名机
    participant RPC 节点
   participant Solana_Scan

   用户 ->> wallet: 发起提现(指定链、token 、数量）
    wallet ->> wallet: 用户余额检查，选择热钱包

    note over wallet, RPC 节点: Solana 交易参数准备
    wallet->>RPC 节点: 获取 recentBlockhash + lastValidBlockHeight
    RPC 节点-->>wallet: 返回 blockhash 和有效期

    note over wallet, 签名机: 确保提现交易安全
    wallet->>风控: 请求风控检查，获取风控签名
    风控->>wallet: 返回风控签名或建议

    wallet ->> 签名机: 提交业务签名 + 风控签名
    签名机-->>wallet: 返回交易签名
    wallet->>RPC 节点: 广播交易

    Solana_Scan->>RPC 节点: 确认提款交易完成

其实这里把获取交易 Blockhash 放在风控检查之后根更好

Signer 模块签名交易核心代码如下：

根据交易类型构建不同的指令：

// SOL 转账指令
const instruction = getTransferSolInstruction({
  source: hotWalletSigner,
  destination: solanaAddress(to),
  amount: BigInt(amount)
});

// 2. 构建 Token 转账指令
const instruction = getTransferInstruction({
  source: sourceAta,
  destination: destAta,
  authority: hotWalletSigner,
  amount: BigInt(amount)
});

构建并签名交易消息：

// 使用 @solana/kit 构建交易
const transactionMessage = pipe(
  createTransactionMessage({ version: 0 }),
  tx => setTransactionMessageFeePayerSigner(hotWalletSigner, tx),
  tx => setTransactionMessageLifetimeUsingBlockhash({
    blockhash: blockhash,
    lastValidBlockHeight: BigInt(lastValidBlockHeight)
  }, tx),
  tx => appendTransactionMessageInstruction(instruction, tx)
);

// 签名交易
const signedTx = await signTransactionMessageWithSigners(transactionMessage);

// 返回两种编码：
// 1. Base64 编码的完整交易（用于发送到网络）
const signedTransaction = getBase64EncodedWireTransaction(signedTx);

Wallet 模块发送交易到网络

// 使用 @solana/web3.js 发送交易
const solanaRpc = chainConfigManager.getSolanaRpc();
const txSignature = await solanaRpc.sendTransaction(
  signedTransaction,  // Base64 编码的交易
  ...
);

完整的提现实现代码位于：

• Wallet 模块：walletBusinessService.ts:405-754
• Signer 模块：solanaSigner.ts:29-122
• 测试脚本：requestWithdrawOnSolana.ts

注意这里有两个待实现的优化：

1. ATA 预检查：在提现前应确保目标地址的 ATA 账户已创建，否则需要额外费用创建 ATA
2. 优先费用：在网络拥堵时可设置 computeUnitPrice 提高交易优先级

总结

交易所接入 Solana 链在总体架构上没有变化，关键是适配其独特的账户模型、交易结构以及共识确认机制。 在处理充值时预先建立并维护 ATA 到钱包地址的映射表，用于 Token 转账识别，统一监控 blockhash 变化检测区块重组，动态更新交易状态（confirmed → finalized）。 在提现时，使用 getLatestBlockhash() 获取交易参数，同时区分 Sol、 SPL Token 和 Token-2022 来构造不同的交易。