> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chaintable.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 事件驱动循环

> 深入理解 Chaintable 基于区块表的事件驱动流水线架构与全链路区块上下文保持机制

***

在传统的链上数据处理架构中，开发者通常被迫处于“两难”境地：要么编写臃肿的单体程序，直接从 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 事件通知：

```json theme={null}
{
    "tableName": "raw_balance.eth",
    "block": {
        "id": "0x123...",
        "height": 18000000,
        "timestamp": 1712345678
    }
}
```

在 Notebook 脚本中，你只需要注册一个简单的事件监听函数，系统便会在每当有新区块（或回填的历史区块）落表时，自动拉起 BlockX 集群执行你的 Python 逻辑：

```python theme={null}

todo
  
```

为什么这种架构更优：

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