

凌晨两点，城市的霓虹还亮着。
一台服务器向以太坊节点发送 `eth_getLogs` 请求。几秒后，接口返回十条日志。钱包根据这些日志计算余额，跨链协议根据这些日志释放资产，数据看板根据这些日志告诉用户：过去一小时，一切正常。
十条日志都是真的。
但谁能证明，服务器没有漏掉第十一条？
区块链可以保证已经写入区块的数据难以被篡改，却不天然保证某个 RPC、区块浏览器或索引服务商向你返回了完整结果。
你保管着私钥，却仍然需要相信别人告诉你链上发生过什么。
这正是递归 STARK 与 Trustless Log Index 想要进入的地方。
它们试图把一条普通的查询，从：
>“服务器说，这是全部结果。”

改造成：
>“这是查询结果，这是证明，你可以自己检查。”

当历史开始携带证明，区块链的无需信任属性才真正从写入端延伸到读取端。


----
## 01｜链是公开的，读取权却被托管了

大多数用户并不直接读取区块。
钱包、DEX、跨链桥、数据看板和链上游戏，通常依赖第三方 RPC、数据库或索引器获取历史事件。
典型的数据路径是：
```
Ethereum
   ↓
RPC Provider
   ↓
Indexer Database
   ↓
Application API
   ↓
User Interface

```

用户看到的并不是“区块链本身”。
用户看到的是某个基础设施服务商整理后的结果。
这套架构很高效，也很实用。但它隐藏了一个权力位置：**控制查询接口的人，可以决定你看到哪些历史。**
如果服务商返回一条伪造日志，Merkle 证明可以帮助识别它。
可如果服务商只是少返回一条日志呢？
一条真实记录，只能证明它存在。
十条真实记录，也不能证明只有十条。
对于普通 NFT 看板，这可能只是一次显示错误。对于托管协议、清算系统、跨链消息或审计工具，遗漏一条日志可能意味着错误释放资产、漏掉债务，或者让一笔本应执行的操作永远消失。
真正困难的问题不是：
>这条日志是真的吗？

而是：
>在指定区块范围和过滤条件内，这些日志是否完整？

“没有找到”也应该接受验证。
“没有其他记录”也应该交出证据。


----
## 02｜Trustless Log Index 让遗漏本身可以被发现

[EIP-8304](https://eips.ethereum.org/EIPS/eip-8304) 提出的 Trustless Log Index，试图为以太坊建立一套可以被密码学验证的日志与交易索引。
它的基本思路并不神秘。
每个区块中的交易、日志地址和日志 topics 被整理成有序的索引条目。索引条目经过哈希后形成一张索引表，索引表的根哈希由系统合约保存。
小表还可以继续合并成更大的表。
当前草案中的协议内表规模包括：
```
1 block
4 blocks
16 blocks
64 blocks
256 blocks
```

查询服务商不再只返回日志，还要返回与查询结果对应的证明：
```
Smart Contract emits logs
          ↓
Index table is generated
          ↓
Table root is committed
          ↓
Indexer returns results + proof
          ↓
Wallet or contract verifies
```

这份证明需要同时处理两件事：
1. 返回的日志确实包含在对应区块中；
2. 在已证明的范围内，没有遗漏其他符合条件的日志。

第一部分是包含证明。
第二部分需要排除证明。
两者结合，才能证明查询结果的完整性。
这是一种很典型的密码朋克改造：它没有要求索引服务商变得更诚实，而是降低了使用者必须相信它的程度。
索引器依然可以提供缓存、数据库和高速接口。
但它交付的结果开始接受计算。


----
## 03｜验证索引根，同样需要一个可信起点

Trustless 并不意味着凭空验证。
验证者仍然需要知道某个规范链区块的哈希与高度，才能确认索引根属于正确的以太坊历史。Trustless Log Index 项目资料把近期规范区块作为查询证明的参考锚点，并提出可以通过 Beacon Light Client 获得这个锚点。
这一步非常关键。
如果同一个服务商既提供查询结果，又提供一个从未核验过的区块根，那么所谓的“验证”仍然可能发生在它自己构造的世界里。
完整的信任路径应该类似：
```
Beacon Light Client
        ↓
Canonical Ethereum Header
        ↓
Index Contract State
        ↓
Index Table Root
        ↓
Log Query Proof
        ↓
Verified Results
```

你需要知道自己验证的是哪条链、哪个区块，以及哪一个索引承诺。
密码学不会替人选择正确的现实起点。
但一旦起点确定，它可以让后续的每一步不再依赖口头保证。


----
## 04｜递归 STARK 把大量验证压缩成一份证明

[EIP-8288](https://eips.ethereum.org/EIPS/eip-8288) 最初面对的是另一个问题：后量子签名和 STARK 证明通常很大，直接把它们放进交易并让所有节点分别验证，会带来显著的数据和 gas 成本。
它提出让交易声明自己依赖哪些签名或证明，再由链下参与者把这些依赖递归聚合。
最终，区块不需要重复携带和验证所有原始证明，而是携带一份聚合后的递归 STARK，证明这些依赖已经全部通过验证。
所谓递归，意味着：
>一份证明可以证明其他证明已经被正确验证。

聚合可以从 mempool 阶段开始。节点不断合并已经收到的证明，区块构建者再为最终纳入区块的依赖生成区块级证明。
```
Proof A ─┐
Proof B ─┼─→ Recursive STARK ─→ One verification result
Proof C ─┘
```

这套路径最初服务于抗量子签名与证明聚合，但它可能承接更多可无状态验证的数据。
日志查询证明就是其中之一。
如果 Trustless Log Index 生成的查询证明可以进入同一套验证与聚合框架，那么应用索引、跨链消息和其他链上数据证明的验证成本，都可能被进一步摊薄。
不过，这里有一条必须保留的边界：
**递归不会消灭计算。它只是重新安排计算发生在哪里，以及最终需要验证多少次。**
证明仍然要生成。
历史数据仍然要读取。
验证程序、证明格式和协议接口仍然要完成衔接。
递归 STARK 提供了一条成本下降的路线，不是一张已经兑现的免费支票。


----
## 05｜创新应用一：给每个应用建立可验证索引

今天，一个 DeFi 协议如果需要自己的历史状态，通常会运行专用索引器，持续处理每个区块的交易回执。
它需要相信自己的数据库没有漏块、没有错误回滚，也没有在重组后留下过期数据。
Trustless Log Index 可以成为更底层的公共索引。
应用索引器只需要关注与自己相关的一小部分事件，并利用日志过滤证明确认：
>从上一个检查点到现在，这就是全部相关事件。

例如，一个链上托管协议可以查询：
```
Contract: Escrow
Events: Deposit, Withdraw
Range: block N → block N + 10,000
```

索引服务商返回事件和证明。
协议自己的客户端验证证明，再更新本地状态。
即使原来的索引服务商关闭，应用也可以换一家服务商重新获取相同范围的结果。只要证明仍然能够被验证，切换提供者就不意味着切换历史。
这就是退出权在数据基础设施中的形态：
**你可以使用服务，但不必把事实一起托管给服务商。**


----
## 06｜创新应用二：让跨链消息携带来源证明

跨链消息在结构上也是一种日志查询。
源链合约发出事件，目标链寻找与自己相关的消息，然后决定是否执行。
传统设计可能依赖多签委员会、预言机网络或一组中继者告诉目标链：
>这条消息确实在源链出现过。

如果源链能够提供可验证的日志索引，目标链就可以接收：
```
Message
+ Source block reference
+ Log inclusion proof
+ Query completeness proof
```

递归 STARK 再把多条消息或多份证明聚合起来，降低批量验证的成本。
这可能让跨链消息过滤变得更轻，也可能为执行分片中的异步通信提供公共基础设施。
但索引证明只解决消息路径中的一部分。
跨链系统仍然要处理：
- 源链共识与最终性；
- 链重组；
- 消息顺序；
- 重放攻击；
- 目标合约执行；
- 数据可用性。

证明一条消息存在，不等于整座桥已经安全。
密码朋克需要的不是更大的承诺，而是把每一层假设写清楚。


----
## 07｜创新应用三：把日志变成一种新的状态材料

以太坊当前的状态更像一张不断修改的键值表。
每次状态更新都要修改状态树，这也是状态膨胀与无状态验证需要面对的问题之一。
日志则更像一条只追加的时间序列：
```
Key A = 10
Key A = 15
Key A = 21
```
读取时，可以查找某个键最近一次出现的值。
列表、集合和历史版本也可以通过事件自然表达。
因为日志只追加，不直接覆盖旧值，不同交易写入日志时也不容易发生状态写入冲突。这让日志在异步执行、状态过期和执行分片研究中具有吸引力。
Trustless Log Index 为这类日志提供可验证的查找能力。
递归 STARK 则可能压缩这些查找证明的验证成本。
但当前 Solidity 合约不能直接读取历史日志，即使日志是合约自己发出的。要让日志成为普遍可用的合约状态，还需要新的协议接口、见证机制，以及对当前区块和最近区块日志的特殊处理。
这是一个研究方向。
也是一个值得实验的方向。
它还不是已经部署的以太坊能力。


----
## 08｜可验证不等于永远在线

公共索引仍然需要有人维护。
EIP-8304 当前采用的是混合方向：协议负责较近区块的小型索引表，更大的历史索引表由基础设施提供者生成，再通过 ZK 证明把索引根提交给历史索引合约。
问题随之而来：
谁保存旧数据？
谁生成大范围历史证明？
谁支付持续更新的成本？
如果所有历史提供者同时下线，一份正确的索引根并不能自动找回已经无人保存的数据。
证明可以约束答案。
证明不能代替存储。
证明也不能强迫服务器回应请求。
因此，一套真正开放的链上数据基础设施至少要分别解决三个问题：
```
Integrity      结果有没有被修改
Completeness   结果有没有被遗漏
Availability   结果还能不能被获取
```

Trustless Log Index 主要推进前两个问题。
历史保存、抗审查访问和服务激励，仍然需要独立设计。
这与 Filecoin 所面对的问题很相似：哈希可以确认你拿到的是不是原来的文件，但持续存储仍然需要资源、证明与经济激励。
**数学可以证明字节没有撒谎，却不能要求某个人永远替你保存字节。**


----
## 09｜新的权力可能出现在证明生成端

当验证成本下降，证明生成的成本就更值得被观察。
如果生成大规模历史证明需要昂贵硬件，并且只有少数团队能够以足够低的延迟完成，那么新的基础设施依赖可能集中在证明生成端。
这并不会让可验证索引失去价值。
但我们需要测量真实成本：
- 证明生成时间；
- 内存与 CPU 或 GPU 消耗；
- 证明大小；
- 网络带宽；
- 链上验证成本；
- 索引更新延迟；
- 历史数据保存费用。

链上 gas 降低，只代表系统中的一项成本下降。
密码朋克关心的是：普通用户是否真的能够独立核验，以及当某个提供者拒绝服务时，用户能否找到另一个出口。
如果验证仍然只能由少数机构承担，那么协议写着 permissionless，现实仍然可能被成本设置门槛。


----
## 10｜现在可以怎样参与

EIP-8288 与 EIP-8304 目前都处于 Draft 状态。它们属于正在推进的研究与标准讨论，尚不能被视为已经确定的以太坊升级路线。
开发者现在可以做的，是把宏大的叙事拆成可以运行的实验。
选择一个合约、一类事件和一个有限的区块范围，然后测试：
```
正常查询
空结果
遗漏一条日志
伪造一条日志
错误的参考区块
链重组后的旧证明
重复提交的跨链消息
```

ZK 开发者可以记录证明时间、内存、证明大小和验证成本。
客户端开发者可以尝试从轻客户端区块头开始，验证索引根与查询结果。
跨链开发者可以观察一条日志证明究竟替代了哪些信任假设，还有哪些安全问题依然存在。
项目仓库已经提供了查询格式、证明结构与开发中的实现资料：
- [Ethereum Research 原始讨论](https://ethresear.ch/t/scaling-ethereum-with-recursive-starks-and-the-trustless-log-index/26002)
- [EIP-8288](https://eips.ethereum.org/EIPS/eip-8288)
- [EIP-8304](https://eips.ethereum.org/EIPS/eip-8304)
- [Trustless Log Index 项目仓库](https://github.com/zsfelfoldi/tli)

复现它。
测量它。
尝试伪造一份结果，再看看验证器能否拒绝它。
协议的可信度，不应该来自提案写得多漂亮，而应该来自攻击失败时留下的证据。


----
## 结语：不要只给我历史，请给我证明

在旧互联网中，服务器返回什么，用户就看到什么。
数据库管理员拥有解释历史的权力。平台关闭接口，普通用户甚至无法带走自己的查询结果。
区块链改变了写入规则。
Trustless Log Index 试图继续改变读取规则。
递归 STARK 则试图让这种验证不再昂贵到只能停留在论文里。
它们真正指向的，并不只是更快的日志查询。
它们指向一种新的数据关系：
服务商可以计算。
索引器可以加速。
应用可以包装。
但任何人都应该有权检查最终答案。
当钱包告诉我过去发生过什么，它应该同时交出证据。
当跨链协议声称某条消息来自另一条链，它应该允许目标链自己验证。
当一个平台关闭、域名过期、霓虹熄灭，历史仍然不应随着界面一起消失。
**不要替我保管真相。**
**把证明交给我。**
**Don’t trust the indexer. Verify the history.**

凌晨两点，城市的霓虹还亮着。一台服务器向以太坊节点发送 eth_getLogs 请求。几秒后，接口返回十条日志。钱包根据这些日志计算余额，跨链协议根据这些日志释放资产，数据看板根据这些日志告诉用户：过去一小时，一切正常。十条日志都是真的。但谁能证明，服务器没有漏掉第十一条？区块链可以保证已经写入区块的数据难以被篡改，却不天然保证某个 RPC、区块浏览器或索引服务商向你返回了完整结果。你保管着私钥，却仍然需要相信别人告诉你链上发生过什么。这正是递归 STARK 与 Trustless Log Index 想要进入的地方。它们试图把一条普通的查询，从：

当以太坊的历史开始携带证明——递归 STARK 与 Trustless Log Index 如何把链上数据的验证权交还给用户

人工智能

把区块链查询从"服务器说了算"改造成"可验证的完整结果"，通过递归STARK与可验证日志索引，让遗漏、伪造和缺失可被检测。确保每条历史记录都附带密码学证明，用户不必再盲目信任RPC或索引服务商。

数据库管理

数据可用性

代码解释

数据库

服务器

区块链

DeFi

腾讯云BI特惠9.9元起！


4核4G3M云服务器 新用户低至38元/年！

热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

当以太坊的历史开始携带证明——递归 STARK 与 Trustless Log Index 如何把链上数据的验证权交还给用户-腾讯云开发者社区-腾讯云

当以太坊的历史开始携带证明——递归 STARK 与 Trustless Log Index 如何把链上数据的验证权交还给用户

当以太坊的历史开始携带证明——递归 STARK 与 Trustless Log Index 如何把链上数据的验证权交还给用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐