区块链与链上数据基础：区块、交易、地址、账本模型与主流公链数据结构差异

链上数据分析的前提，是理解区块链底层的数据组织方式。比特币、以太坊、Solana 虽然都叫“区块链”，但它们在区块结构、交易模型、地址体系、账户状态存储上存在根本性差异。这些差异直接决定了我们如何解析交易、如何计算地址余额、如何追踪资金流向，以及如何设计链上指标。本章从区块与交易的基本单元出发，逐步拆解 UTXO 与账户模型的本质区别，并对比三大主流公链的数据结构，为后续的流量分析打下坚实的认知基础。

3.1 区块与交易：链上数据的最小组织单元

核心原理：区块如何“打包”交易

区块链的本质是一个由区块组成的单向链表。每个区块包含两部分核心内容：区块头（Header）和交易体（Body）。区块头存储元信息——前一区块哈希（PrevHash）、Merkle根、时间戳、难度目标、Nonce等；交易体则包含该区块内所有已确认的交易记录。这种“哈希指针”结构保证了数据不可篡改：任何一笔交易的改动都会导致Merkle根变化，进而影响后续所有区块的哈希值。

从数据分析视角看，我们最关心的是交易（Transaction）。一笔交易通常包含输入（Inputs）、输出（Outputs）、签名、费用等字段。交易哈希（TxHash）是交易的唯一标识，也是链上追踪的起点。理解交易结构，是解析资金流向、计算活跃地址、识别交易所热钱包充提行为的基础。

判断方法：如何区分交易类型

在实际分析中，我们常需要区分普通转账、合约调用、跨链桥操作等交易类型。判断依据主要有三点：

• 接收方类型：如果接收方是合约地址（如ERC-20代币合约），则该交易大概率是代币转账或合约交互；如果接收方是EOA（外部拥有账户），则是普通转账。
• 输入数据（Input Data）：以太坊交易的data字段包含函数选择器（前4字节），通过解析可以判断调用了哪个合约的哪个方法。
• 交易日志（Logs）：合约事件（Event）会记录在交易收据中，例如Transfer事件可以精确识别代币转移的发送方、接收方和金额。

案例拆解：一笔BTC转账的完整生命周期

假设用户A要向用户B发送0.5 BTC。在UTXO模型下，这笔交易的过程如下：

1. 输入选择：钱包扫描A的UTXO集合，找到一笔或多笔未花费输出，总金额≥0.5 BTC + 矿工费。
2. 输出构造：交易输出包含两个部分——给B的0.5 BTC（锁定到B的地址），以及找零（回到A的另一个地址）。
3. 签名：A使用私钥对交易进行签名，证明其拥有输入UTXO的所有权。
4. 广播与确认：交易进入内存池（Mempool），矿工打包进区块，经过6个区块确认后视为最终有效。

这个过程中，A的原始UTXO被“销毁”，生成了两个新的UTXO。链上分析时，我们追踪的就是这些UTXO的流向——从A的地址到B的地址，以及找零地址。这种“找零地址”的识别，是链上数据清洗中一个重要的技术点。

常见误区与复盘

3.2 账本模型：UTXO与账户模型的本质差异

核心原理：两种截然不同的状态记录方式

UTXO（Unspent Transaction Output）模型是比特币采用的方式。它不记录“地址有多少钱”，而是记录“哪些交易输出尚未被花费”。每个UTXO都是一个独立的数据单元，包含金额、锁定脚本（通常对应一个地址）、创建交易哈希等。当一笔交易发生时，输入UTXO被销毁，输出UTXO被创建。这种设计天然支持并行验证，且隐私性较好（一个地址可以有多个UTXO），但缺点是状态数据量会持续增长。

账户模型（Account Model）是以太坊、Solana等智能合约平台采用的方式。它直接记录每个地址的余额（Balance）、Nonce、存储（Storage）和代码（Code）。交易发生时，直接从发送方账户扣减余额，向接收方账户增加余额。这种模型更接近传统银行账户，易于理解和编程，但需要处理“重入攻击”等安全问题，且状态存储占用较大。

判断方法：如何识别链上数据属于哪种模型

在接入链上数据源时，首先要判断该链的账本模型，因为这会直接影响数据解析方式：

• 看交易结构：如果交易包含vin和vout数组，且每个输出有scriptPubKey，则是UTXO模型；如果交易包含from、to、value字段，则是账户模型。
• 看地址体系：UTXO链的地址通常由公钥哈希生成（如BTC的Base58Check），账户链的地址通常是公钥的后20字节（如ETH的0x开头40位hex）。
• 看余额查询方式：UTXO链需要扫描所有交易输出并汇总；账户链直接读取状态数据库中的Balance字段。

案例拆解：同一笔转账在两种模型下的数据表现

假设Alice向Bob转账1 ETH（或等值BTC），两种模型的数据表现截然不同：

// BTC（UTXO模型）交易结构
{
  "txid": "abc123...",
  "vin": [{
    "txid": "prev_tx_1",
    "vout": 0,
    "scriptSig": "..."
  }],
  "vout": [
    {"value": 0.8, "scriptPubKey": "OP_DUP OP_HASH160 <Bob_hash> ..."},
    {"value": 0.19, "scriptPubKey": "OP_DUP OP_HASH160 <Alice_change> ..."}
  ]
}

// ETH（账户模型）交易结构
{
  "hash": "0xdef456...",
  "from": "0xAliceAddress",
  "to": "0xBobAddress",
  "value": "1000000000000000000",  // 1 ETH = 10^18 Wei
  "nonce": 5,
  "gasPrice": "20000000000",
  "gas": 21000
}

注意BTC交易中，Alice的输入是0.99 BTC（0.8+0.19），输出给Bob 0.8 BTC，找零0.19 BTC（假设矿工费0.01 BTC）。而ETH交易中，Alice的余额直接减少1 ETH + Gas费，Bob的余额直接增加1 ETH。这种差异意味着：分析BTC链上数据时，必须处理“找零”逻辑；分析ETH链上数据时，则要关注Nonce和Gas消耗。

常见误区与复盘

3.3 主流公链数据结构差异：BTC、ETH、SOL

核心原理：三条链的“基因”决定了数据形态

BTC、ETH、SOL代表了区块链发展的三个阶段，它们的数据结构差异源于设计目标的不同：

• BTC（2009）：目标是“点对点电子现金”，因此采用UTXO模型，数据结构简洁，安全性优先，但功能单一。
• ETH（2015）：目标是“世界计算机”，引入账户模型和EVM，支持智能合约，但状态膨胀问题突出。
• SOL（2020）：目标是“高性能公链”，采用账户模型+并行执行，通过“历史证明”（PoH）机制实现高吞吐，但数据复杂度更高。

判断方法：从区块浏览器字段识别链类型

当你打开一个区块浏览器时，可以通过以下字段快速判断链的类型：

案例拆解：同一笔“转账”在三条链上的数据差异

假设我们要追踪一笔价值约1000美元的转账，三条链的数据表现如下：

// BTC：确认时间约10分钟，费用约2美元
// 交易结构：1个输入（可能来自多个UTXO合并），2个输出（接收方+找零）

// ETH：确认时间约12秒，费用约3美元（Gas费）
// 交易结构：from/to/value，附带Gas Price和Nonce
// 如果涉及ERC-20代币，还需要解析Logs中的Transfer事件

// SOL：确认时间约400毫秒，费用约0.0001美元
// 交易结构：包含多个Instruction（指令），每个指令指定Program ID
// 转账通常通过System Program的Transfer指令完成

这个对比告诉我们：在跨链分析时，不能使用统一的解析逻辑。例如，追踪BTC的“找零地址”在ETH中不存在；而SOL的交易可能包含多个指令（如“转账+质押+投票”），需要拆解每个指令的意图。

常见误区与复盘