上一篇我们把交易所风控体系补齐，这一篇给交易所钱包接入 Solana 链。Solana 的账户模型、日志存储和确认机制与以太坊系链有很大的不同，如果沿用以太坊套路，还是很容易踩坑的。下面我们梳理一下记录Solana 的整体思路。
了解独特的 Solana
Solana 账户模型
Solana 使用程序与数据分离的模型，程序是可以共用的，而程序的数据是通过 PDA（Program Derived Address）账户单独保存的，由于程序是共用的，因此需要 Token Mint 来区别不同的 Token。Token Mint 账户存储代币的全局元数据，存储例如 铸造权限（mint_authority）、 总供应量（supply）、 小数位数（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 扫块追踪，需要添加以下三张表：
表名 关键字段 说明 冗余 slot 信息，便于检测分叉并触发回滚 存储充值/提现等交易明细， 记录用户 ATA 映射，scan 模块可按 solana_slotsslotblock_hash, status, parent_slotsolana_transactionstx_hashslot, to_addr, token_mint, amount, typetx_hash 唯一，用于双签追踪solana_token_accountswallet_idwallet_address, token_mint, ata_addressata_address 反查内部账户
其中：
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 链上数据，通常有两个方法：
扫签名：getSignaturesForAddress()
扫块：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 产生，动态更新目标
使用
confirmedcommitment 获取区块，兼顾实时性
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 链类似，但在交易构建有差异：
在 Solana 上，有两种 Token： 普通 SPL-Token 和 SPL-Token 2022，两个 Token 的programID 是不同的，在构造交易指令时，需要区分。（当前 SPL-Token 2022 比较少，也可以选择不支持 token 2022 ）
Solana 的交易由两部分组成：
signatures（一组 ed25519 签名）和 message（包含 header、accountKeys、recentBlockhash、instructions）message 的内容被哈希并被签名，放在signatures。在 Solana 交易中没有 nonce，而是使用 recentBlockhash 来约束交易有效期，recentBlockhash 只有 150 个区块的有效期（约 1 分钟），因此每次发起交易时 recentBlockhash 需要从链上实时获取到最新的 recentBlockhash，如果提现交易需要人工审核，那就的重新获取 recentBlockhash 够着交易结构再次请求签名。
提现流程
其实这里把获取交易 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
注意这里有两个待实现的优化：
ATA 预检查：在提现前应确保目标地址的 ATA 账户已创建，否则需要额外费用创建 ATA
优先费用：在网络拥堵时可设置
computeUnitPrice提高交易优先级
总结
交易所接入 Solana 链在总体架构上没有变化，关键是适配其独特的账户模型、交易结构以及共识确认机制。
在处理充值时预先建立并维护 ATA 到钱包地址的映射表，用于 Token 转账识别，统一监控 blockhash 变化检测区块重组，动态更新交易状态（confirmed → finalized）。
在提现时，使用 getLatestBlockhash() 获取交易参数，同时区分 Sol、 SPL Token 和 Token-2022 来构造不同的交易。
