一条区块链网络中，全节点保存完整历史并执行所有交易验证，轻客户端只保存区块头并通过 SPV（简化支付验证）确认自己的交易。这一差异在网络层产生截然不同的行为模式：全节点是"服务提供者"，轻客户端是"服务消耗者"。理解这种不对称是理解网络吞吐瓶颈的关键。

6.6.1 SPV 轻客户端的工作原理

轻客户端的核心假设：只要区块头链是正确的（工作量大、难度递增、哈希链接完好），则该区块中的交易 Merkle 路径即可证明交易已被包含。

所需数据量对比：

轻客户端如何确认"我的交易 tx_237 是否在区块 #876543 中"？

1. 获取区块头：验证其包含的 PoW 和难度；
2. 请求 Merkle 路径：向全节点请求 tx_237 的 Merkle Proof（仅需 $O(\log_2 n)$ 字节）；
3. 本地验证：重新计算路径上的哈希，最终得到一个根，与区块头中存储的 merkle_root 比对。

graph LR
    A[轻客户端<br>~80MB] --> B{需要验证
    tx 或 余额}
    B --> C[请求: 区块头 + Merkle 路径]
    C --> D[全节点<br>~500GB]
    D --> E[返回: 80B 头 + 哈希路径]
    E --> F[轻客户端本地验证
    根哈希匹配]
    F -->|是| G[确认交易有效]
    F -->|否| H[拒绝/怀疑链分叉]
    style D fill:#ffffcc
    style A fill:#ccffcc

6.6.2 全节点的服务负担

当一个轻客户端连接到全节点时，全节点需要提供：

• 过滤服务（如 BIP37 Bloom Filter）：根据客户端发送的 Filter，仅推送匹配的交易；
• Merkle 证明服务：为特定交易生成并返回 Merkle 路径；
• 区块/交易查询：响应 getdata 请求；
• 历史数据提供：对于需要归档查询的客户端，返回老区块数据。

资源消耗的数学模型：

假设网络中有 $N_{full}$ 个全节点，$N_{spv}$ 个轻客户端。每个轻客户端消耗全节点的平均带宽为 $B_{spv}$，则全节点侧的总服务带宽：

在轻客户端数量远超全节点时，全节点可能面临服务过载。这就是为什么 BIP37 引入了带宽限制与过滤精确度参数，允许全节点调节服务粒度。

6.6.3 以太坊的同步模式：从全归档到快照

以太坊提供四种客户端同步模式，本质上是"信任 vs 验证"的连续谱：

// client-sync-strategy.ts
// 纯内置：模拟不同同步模式下客户端的信任抽象层

type SyncStrategy = 'archive' | 'full' | 'snap' | 'light';

function trustLevel(strategy: SyncStrategy): string {
  const map: Record<SyncStrategy, { trust: string; depth: string }> = {
    archive:  { trust: '零信任',          depth: '全历史执行' },
    full:     { trust: '零信任',          depth: '当前完整状态' },
    snap:     { trust: '弱信任（状态根一次）', depth: '快照后递增' },
    light:    { trust: '强信任（提供节点）',  depth: 'SPV 级别' },
  };
  return map[strategy].trust;
}

// 模拟 4 种同步模式的存储/时间/信任权衡
const strategies: SyncStrategy[] = ['archive', 'full', 'snap', 'light'];
for (const s of strategies) {
  console.log(`模式 ${s}:${trustLevel(s)}`);
}
// 输出：由零信任到强信任的完整谱系

关键认知：轻客户端与全节点的分化是区块链"可扩展性"与"去信任化"之间的永久张力。全节点提供终极安全与完整验证，轻客户端提供移动友好与秒级就绪。理解每种模式的信任假设，才能为特定应用选择正确的客户端策略。

← 6.5 网络层攻击 | 前往 → 6.7 网络升级与协议版本协商