Rezolve 分布式数据库与 Web3 数据

　　2026 年 8 月 25 日，Rezolve Ai 通过 GlobeNewswire 发布了一则企业新闻稿，标题直白——“Google Selects Rezolve Ai’s Proprietary Distributed Database Platform”。需要先厘清一个背景：新闻稿里所谓“Rezolve 的专有分布式数据库平台”，并非 Rezolve 自研，而是其于 2025 年 10 月收购的 Subsquid（SQD） 去中心化数据网络的技术栈——SQD 此前已运营着 2,500+ 节点、全网管理约 2.1PB 索引数据。据稿中所述，Google Cloud 在“基础设施层面”整合了该平台，任务是为 Google Cloud Web3 的区块链数据集提供底层的索引与数据管道；首期部署涵盖 10 个区块链网络（稿未披露具体名单）、约 100TB 历史数据，每一个数据块在进入 Google Cloud 公共数据集之前，都要先通过 6 项密码学检查 以及结构与交叉验证。这里要立刻划清分寸：合作由 Rezolve 单方面宣布，Google Cloud 官方新闻室并无对应独立官宣、亦未公开否认，因此“Google 主动选择并背书”只能视为发布方叙事。这条新闻之所以仍值得技术人认真对待，不在于“谁选了谁”的口径，而在于它恰好暴露了链上数据走向“可查询公共服务”时最硬核的那段工程：如何把不可信、异构、持续增长的链上原始流，变成可被 SQL 随手检索的可信数据集。我们把它拆成三层来看。

　　第一层是数据管线（pipeline）本身的架构位置。Google Cloud 的区块链数据集并非新生事物——它此前就以 bigquery-public-data.goog_blockchain_* 系列数据集（如 goog_blockchain_ethereum_mainnet_us）的形式挂在 BigQuery 上对外提供。对同类链（如 Google 设计的 bitcoin-like 统一 schema 系列）可复用同一套 double-entry ledger 视图跨链查询地址余额、合约调用与代币流转；跨异构链则需分别取数后再联合，并非一条 SQL 直接 JOIN 所有链。背后是一整套从节点同步、区块解析到列存入库的工程链。Rezolve 的分布式数据库平台（即 SQD 栈）此次扮演的角色，正是这条链里的索引与数据管道层：它从各链全节点拉取原始区块，做解析、清洗、建立索引，再向上游的公共数据集供给规范化数据。

　　值得注意的是，这次“Google 选择”更宜理解为既有集成的延伸而非从天而降的陌生背书：Google Cloud 早在 2023 年就发布过 Built with BigQuery 官方文章《How to unlock Web3 data with BigQuery and Subsquid》，当时 Subsquid 已与 BigQuery 打通；Rezolve 2025 年报还引用了 Google Cloud EMEA 总裁 Tara Brady 的署名语，称其正“将独特的 agentic 能力直接集成进 Google Cloud 基础设施”。也就是说，这条新闻的技术底色是延续，而非首秀。这里的“基础设施层面”也需被准确理解——它不是说 Google 用 Rezolve 替换掉了 Spanner/Bigtable/BigQuery 这些底层存储，而是在既有数据集产品的 ingestion（摄取）与 indexing（索引）环节，嵌入了 SQD 的分布式处理栈，作为面向区块链场景的专用数据管线。对一个每天仍在追加新区块、且需要回灌约 100TB（仅为 SQD 全网 2.1PB 体量的一小部分）历史数据的系统而言，瓶颈从来不在最终存储，而在“如何把异构的原始链数据稳定地、可重放地变成结构化记录”——这正是该平台要补的那段。

　　第二层，也是技术含量最高的一层，是每块入仓前的密码学验证管线。新闻稿给出的约束很具体：每个区块在落入公共数据集前，必须通过 6 项密码学检查（six cryptographic checks），并辅以 schema validation（模式校验）、structural checks（结构检查）与 cross-validation（交叉验证）。需要强调：新闻稿只写了 “six cryptographic checks” 六字，并未公开具体是哪六项；下面以 EVM 链为例列出业界通用的区块链可信化校验范式，用以还原其工程内涵，而非声称这就是 Rezolve 的实际清单：

以 EVM 链为例，每个区块进入公共数据集前的验证管线（业界通用范式）:

  [1] 区块哈希校验      block_hash == Hash(block_header)        # 防篡改
  [2] 默克尔根校验      tx_root == MerkleRoot(txs)             # 交易集完整
  [3] 父哈希链校验      block.parent == prev_block.hash        # 链式连续
  [4] 共识规则校验      valid_by_consensus(block)              # 满足出块规则(PoS: 罚没/最终性; PoW: 难度目标)
  [5] 提议者签名校验    verify(sig, proposer_pubkey, block)    # 出块者身份(EVM/PoS beacon block proposer signature)
  [6] 状态根/ receipt 根 verify(state_root, receipts_root)     # 状态可验证(以太坊 header 的 stateRoot/receiptsRoot)
        │
        └─> 叠加: schema / structural / cross-validation
              (字段类型、长度、跨表外键一致性)

  注: 以上为 EVM 范式。UTXO 类链(如 BTC)无 [5][6] 这两个原语——
      比特币区块本身无出块者签名(PoW 即证明)，header 也无状态根/receipt 根，
      对应以 coinbase 交易、累积难度(nBits)等原语替代。

　　这条管线的意义在于：它把“信任”从“我相信某个节点”迁移到“我验证过密码学证据”。传统做法里，数据管道往往默认上游节点可信，一旦上游被污染或分叉回滚，下游数据集就会出现静默错误；而 6 项密码学检查（以 EVM 范式看，默克尔根 + 父哈希链 + 共识规则构成核心防线）让每个区块在进入公共数据集前都先自证清白，足以在绝大多数情况下抵御孤块、重组（reorg）与恶意节点的注入。对面向公众的查询服务而言，这一步不是锦上添花，而是“可被外部独立验证”这一产品承诺的底线。

　　第三层是分布式数据库的存储与规模含义。首期 10 条链、约 100TB 历史数据，需明确这只是本次部署的首期子集——作为对照，SQD 全网自述管理着约 2.1PB 索引数据、日服务约 1.4PB，100TB 仅占其体量的一小部分，不该被误读成整套栈的总规模。即便如此，难点仍在于它是持续增长的冷+热混合负载：链上历史是只追加（append-only）的冷数据，需要高压缩比与廉价顺序读；而最新区块与实时索引是高频写入的热数据，需要低延迟写入与即时可查。一个能同时吃下这两端的分布式数据库平台，底层通常要具备分片（sharding）、多副本一致性、以及按时间/链维度做物理分区的能力。更关键的是“可重放性”——当某条链发生深度重组，管道必须能从特定高度回滚并重新摄取，而不能靠手工修数。这恰好呼应了 Rezolve 把该平台定位成“为 AI Agent 提供实时数据基础设施”的叙事：Agent 要的不是一份静态快照，而是一条始终一致、可验证、可重放的活数据流，链上数据集正是这种数据流的典型样本。

　　把三层叠起来看，这件事的技术轮廓就清晰了：Google Cloud Web3 数据集是面向开发者的可查询区块链数据服务（BaaS 化的数据层），它的价值不在存储容量，而在可信摄取 + 可验证索引 + 即席 SQL。Rezolve 借由收购而来的 SQD 栈切入的，正是把原始链流变成可信结构化数据那段最硬的 ingestion/indexing 工程；6 项密码学检查（以业界范式还原）是这段工程的信任锚点；100TB 首期 + 10 链 + 持续追加，则是这套架构的规模与演化压力测试。至于“全球顶尖科技巨头首次大规模商业化部署”这种话，属于新闻稿的叙事口径，我们更应关注它揭示的工程事实——链上数据要成为公共基础设施，密码学验证必须前置到数据管道里，而不是事后审计。

　　最后再压实一句分寸：这则消息由 Rezolve Ai 单方面宣布（经 GlobeNewswire 发出），Google Cloud 无对应独立官宣、亦未公开否认，外部无法独立证实 Google 是否主动“选择”并公开背书；所谓合作目前只能定位于“据 Rezolve 新闻稿所述”。但即便如此，把这条新闻放回 2023 年 BigQuery × Subsquid 的既有集成脉络里看，它更像一次品牌延续下的能力延伸，而非凭空的新背书。对技术读者而言，新闻稿里那套“6 项密码学检查（以业界范式还原）+ 索引/管道集成”的架构描述，本身就足够作为一份有价值的工程参考——无论发布方是谁，把信任前置进数据管线的思路，都值得在自建链上数据服务时借鉴。