Skip to main content
在传统的链上数据处理架构中，开发者通常被迫处于“两难”境地：要么编写臃肿的单体程序，直接从 RPC 节点获取原始区块并解析所有逻辑，导致维护极其困难；要么在数据落表的同时，额外维护一套消息队列（如 Kafka）来驱动下游。这不仅让架构复杂度成倍增加，更导致了**“区块上下文（高度、哈希、时间戳）”在流转过程中的丢失**。 Chaintable 通过 基于 Block 表的区块事件订阅机制，打破了这一僵局，将复杂的链上数据处理简化为多级级联、天然闭环的事件驱动任务流水线（Pipeline）。

​
1. 核心运行机制

Chaintable 的事件驱动循环并不依赖外部独立的中间件，而是将“存储（BlockDB）”与“计算（BlockX）”通过事件纽带进行内聚绑定。

​
1. 以 Block 表为确定性事件源

每个 Block 表在 Chaintable 中都像是一个虚拟的“分布式账本”，它的数据按照区块粒度同频写入。当一个区块的数据在表中写入完成后，BlockDB 会原子性地抛出一个 Table Block Event（表级区块事件）。
  • 解耦处理链路：开发者可以将极其复杂的业务清洗逻辑拆解为多个单一职责的阶段。例如：原始 Trace 表 -> DEX 流动性池表 -> 标准 Token 转移表 -> 实时账户余额表。
  • 分层建模与数据复用：你不再需要每次都从最底层的原始区块开始解析。平台内任何已经由他人或自己分层加工好的 Block 表，都可以作为你的上游事件源。直接订阅中间层数据，即可开启全新的业务计算。

​
2. 全链路保持“区块上下文”

传统的流处理（如 Flink/Spark Streaming）通常是以“单行数据（Row）”或“挂钟时间（Wall-clock Time）”为驱动。而 Chaintable 的事件驱动循环始终运行在“区块时间（Block Time）”维度上。 无论数据流经多少层中间表的加工，激发的事件永远是一个包含完整区块元数据的结构。这意味着下游计算任务在执行时，天然知道自己当前正在处理的是哪一个确切的区块高度，确保了跨表级联查询时的数据血缘一致性。

​
2. 区块事件格式 (Protocol Schema)

当上游表完成一个区块的数据提交时，下游 Notebook 任务会接收到如下标准的 JSON 事件通知： 
{
    "tableName": "raw_balance.eth",
    "block": {
        "id": "0x123...",
        "height": 18000000,
        "timestamp": 1712345678
    }
}
在 Notebook 脚本中，你只需要注册一个简单的事件监听函数，系统便会在每当有新区块（或回填的历史区块）落表时，自动拉起 BlockX 集群执行你的 Python 逻辑： 

todo
为什么这种架构更优：
维度自建链上处理chaintable模式
驱动源仅限原始区块数据任意 Block 表，支持逐层加工
基础架构DB + Kafka + 消息处理worker池BlockDB + BlockX
上下文保留经消息队列后，从区块上下文变成单行数据上下文全链路保留区块上下文，支持写后读一致性
复杂度需要手动维护表与消息的同步天然闭环，订阅Block表变更即可触发计算