EIP-7792 可验证日志：用链上日志累积器让 eth_getLogs 响应可验证-北京尧图网络

EIP-7792 可验证日志用链上日志累积器让 eth_getLogs 响应可验证【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs本指南以仓库中的 EIPS/eip-7792.md 为蓝本系统讲解如何通过一个位于固定地址、无代码的日志累积合约将每个区块产生的日志承诺增量地写入状态存储从而让钱包在不必信任数据提供商的前提下高效验证eth_getLogs返回结果的正确性与完整性。读完本文你将掌握其存储布局、SSZ 数据结构、累积算法伪代码、blockTimestamp字段扩展以及完整的四步验证流程并理解它为何选择在元数据中记录区块号与交易索引而非区块哈希。背景为什么eth_getLogs的响应需要可验证eth_getLogs是钱包获取某个账户或某个主题topic相关交易历史的核心 JSON-RPC 端点。然而在默认情况下它的响应来自钱包所连接的数据提供商节点响应是否正确且完整没有被省略、没有夹带无关日志完全依赖提供商的诚信。在 EIP-7792 出现之前唯一可用的验证手段是钱包自行获取所有相关区块头再逐一对照日志布隆过滤器logs bloom做存在性检查。这一机制存在两个根本性问题误报率高布隆过滤器本质上是概率性数据结构命中并不代表日志真的存在验证结论不可靠网络往返过多为验证一段跨区块范围的日志需要逐个拉取区块头涉及不切实际的大量 RPC 往返实践中难以落地。EIP-7792标题为Verifiable logs状态Stagnant类型为 Standards Track / Core创建于 2024-10-21作者包括 Etan Kissling、Gajinder Singh 与 Vitalik Buterin正是为此定义了一个替代机制以增量、高效的方式验证eth_getLogs响应的正确性与完整性。根据仓库中的 EIPS/eip-1.md 对 EIP 状态的说明Stagnant表示该提案在 Draft/Review/Last Call 阶段超过 6 个月无活动而被暂时搁置但仍可被作者或编辑恢复读者应将其视为一份处于早期设计阶段的技术方案而非已定稿的协议标准。方案总览EIP-7792 的核心思路可以概括为一句话让日志的可验证性从下载区块头查布隆过滤器转变为在链上增量累积日志承诺commitment再用 Merkle 证明去校验累积结果。具体包含三个组成部分链上日志累积器Log Accumulator每个区块执行完所有交易后将该区块所有日志的承诺写入一个固定地址LOG_CONTRACT_ADDRESS的存储槽中SSZ 结构化日志条目为每条日志附加区块时间戳、区块号、交易索引等元数据形成统一的LogEntry结构其根即被累积扩展的 JSON-RPC 与验证流程eth_getLogs响应新增blockTimestamp字段配合区块头与eth_getProof完成端到端校验。配置日志累积合约地址规范首先定义了一个全协议统一的常量| 名称 | 值 | | - | - | |LOG_CONTRACT_ADDRESS|0xfffffffffffffffffffffffffffffffffffffffe|该地址上的合约实际上没有任何代码no code它仅仅作为状态存储的载体存在。之所以要用这种形式是因为它复用了以太坊世界状态state trie中现成的存储证明能力——eth_getProof可以直接对该地址的存储槽生成 Merkle 证明而无需引入新的密码学原语。日志累积存储布局与累积算法存储布局与 EIP-158 防护在区块内所有交易执行完毕后该区块产生的所有日志承诺都会被累积到LOG_CONTRACT_ADDRESS的存储中。存储布局由三个mapping类型的槽位构成| 名称 | 槽位 | 类型 | | - | - | - | |LOG_ADDRESS_STORAGE_SLOT|0|mapping(address bytes32)| |LOG_TOPICS_STORAGE_SLOT|1|mapping(bytes32 bytes32)| |LOG_ADDRESS_TOPICS_STORAGE_SLOT|2|mapping(bytes32 bytes32)|三个槽位分别服务于三种过滤场景仅按address过滤、仅按topics过滤、按addresstopics组合过滤。一个容易被忽略但至关重要的细节是合约的 nonce 必须在首次写入时被设为1。原因在于 EIPS/eip-158.mdState clearing规定当一次状态变更使账户变为空账户nonce0、balance0、code 为空、storage 为空时该账户会被直接删除。日志累积合约虽然只有存储没有代码但如果它的 nonce 保持为 0那么在某个区块没有产生任何日志没有写入时它就会满足空账户条件而被清理从而导致累积状态丢失。将 nonce 预置为 1 可以确保该账户始终存活这一手法与 EIP-4788 等系统合约的部署方式类似。日志条目的 SSZ 结构每条被累积的日志都会携带来源元数据。规范复用了 EIP-6466SSZ receipts即把 RLP 收据迁移为 SSZ 编码中定义的Log类型并在此基础上扩展出LogMeta与LogEntryclass BlockMeta(Container): timestamp: uint64 number: uint64 class LogMeta(Container): block: BlockMeta transaction_index: uint64 class Log(Container): address: ExecutionAddress topics: List[Bytes32, MAX_TOPICS_PER_LOG] data: ByteList[MAX_LOG_DATA_SIZE] class LogEntry(Container): meta: LogMeta log: Log其中Log各字段的含义在 EIPS/eip-6466.md 中有更完整的定义MAX_TOPICS_PER_LOG为4对应LOG0~LOG4操作码允许 0~4 个主题address是 20 字节的执行层地址data是日志负载字节串。EIP-7792 将其中的data表述为有界类型ByteList[MAX_LOG_DATA_SIZE]并额外引入BlockMeta区块时间戳与区块号与LogMeta区块元数据交易索引作为每条日志的来源证明。最终被累积进链上存储的是hash_tree_root(LogEntry)这个 32 字节承诺根。累积算法SHA256 链式哈希累积过程使用 SHA256 而非以太坊常用的 KECCAK256其算法如下def accumulate_log(evm: Evm, entry_root: Bytes32, key: Bytes32): root hashlib.sha256() root.update(entry_root) root.update(sload(evm.env.state, LOG_CONTRACT_ADDRESS, key)) sstore(evm.env.state, LOG_CONTRACT_ADDRESS, key, root.digest()) def track_log(evm: Evm, entry: LogEntry) - None: entry_root entry.hash_tree_root() # Allow verification via address filter key keccak256(abi.encode(entry.log.address, LOG_ADDRESS_STORAGE_SLOT)) accumulate_log(evm, entry_root, key) for topic in entry.log.topics: # Allow verification via topics filter key keccak256(abi.encode(topic, LOG_TOPICS_STORAGE_SLOT)) accumulate_log(evm, entry_root, key) # Allow verification via combined address topics filter key keccak256(abi.encode(entry.log.address, topic)) key keccak256(abi.encode(key, LOG_ADDRESS_TOPICS_STORAGE_SLOT)) accumulate_log(evm, entry_root, key)可以将其理解为一条按过滤键key分组的哈希链对于每个 key新累积值 SHA256(新条目根 || 旧累积值)。这样设计有三个关键性质可增量验证验证者只需从某个历史累积值出发按响应中的日志顺序逐个重放accumulate_log即可得到当前累积值无需重放整个区块覆盖三种过滤方式同一日志会同时被写入按地址、按每个主题、按地址主题组合三条链因此无论钱包以何种过滤器发起查询都能找到对应的累积链来校验key 的计算遵循 Solidity 的mapping槽位规则keccak256(abi.encode(key, slot))这正是eth_getProof对mapping存储槽生成证明时使用的寻址方式保证了证明与链上存储一一对应。值得注意的是track_log为每条日志的每个主题都执行了accumulate_log而同一个entry_root会被写入多个 key 的链中——这也意味着存储写入量随日志数量线性增长是后续 Gas 成本讨论的根源。JSON-RPC API 扩展新增blockTimestamp为了让验证者能够将响应条目与区块头对应起来eth_getLogs的响应格式被扩展每个日志对象新增一个字段blockTimestampQUANTITY—— 该日志所在区块由blockHash指向的timestamp字段。按照 EIPS/eip-1474.md 中关于Quantity编码的约定该字段必须是0x前缀的十六进制、使用最少的十六进制位数表达且零值表示为0x0。blockTimestamp的加入让验证者无需单独查询区块头即可获得验证BlockMeta.timestamp所需的输入。验证流程四步增量校验对于一次eth_getLogs(address, topics, fromBlock, toBlock)请求响应数据的正确性与完整性可以通过以下四步验证获取并校验区块头取得fromBlock与toBlock的区块头并与它们已知的哈希值blockHash比对获取fromBlock的父区块头取得fromBlock的parentBlock头并用fromBlock.parentHash校验之获取历史累积值基于给定的过滤器通过eth_getProof取得parentBlock处对应的历史日志累积值即起点状态获取终点累积值同样通过eth_getProof基于相同过滤器取得toBlock处的日志累积值即终点状态。随后验证者从步骤 (3) 的历史累积值出发将响应中的每一条日志条目按与accumulate_log兼容的方式逐一应用即构造LogEntry、计算entry_root、SHA256 链接旧值。如果最终计算出的累积值与步骤 (4) 从链上证明获得的累积值一致则响应数据是正确且完整的由它推导出的LogEntry可以被信任。这套流程完全复用了现有的两条证明基建——eth_getProof对世界状态存储槽的 Merkle 证明与 SSZ Merkle 证明来自 EIP-6466 的 receipts 根没有引入任何新的密码学假设因此安全性建立在以太坊既有的状态树安全模型之上。设计权衡与 Rationale为何做摆脱对可信数据提供商的依赖让eth_getLogs响应可验证本质上是为钱包补上安全属性钱包可以不再依赖任何可信的数据提供商从而不再受制于特定提供商的隐私政策最终提升钱包的隐私保证——它无需向提供商暴露完整的查询意图也能自行核验结果的真实性。Gas 成本显著高于LOG#操作码方案规范明确承认该方案的 Gas 成本显著高于Prague 升级中LOG#操作码方案原因主要有两点每条日志的每次累积都涉及额外的SLOAD/SSTORESHA256操作码的成本是KECCAK256操作码的两倍而累积链恰好使用 SHA256。这些增加的成本超过了因去掉日志布隆过滤器logs bloom而节省的开销。规范进一步给出了备选演进方向如果该机制即便经过优化仍然过于昂贵则可能需要将日志累积器迁移到独立优化的数据结构中不放入state_root或交给协议外的零知识zk系统。即便如此日志的 Gas 成本也应反映更新典型协议外累积器的真实总成本以阻止日志垃圾攻击log spamming。为何元数据用区块号/交易索引而非区块哈希一个深刻的循环依赖问题只要累积器存储在状态树state trie中它就不能引用区块哈希——因为区块哈希本身是对状态树求哈希得到的引用会产生循环依赖cycle。因此规范选择在BlockMeta中记录number与timestamp、在LogMeta中记录transaction_index。而如果改用外部系统如协议外累积器则可以在元数据中包含哈希因为那种场景下状态根不再受 IVCincremental verifiable computation增量可验证计算影响。向后兼容性该方案对现有生态是渐进式的来自可信服务器的eth_getLogs响应仍然可以原样处理不强制要求验证唯一需要客户端适配的点是对响应做严格字段校验的客户端应用可能需要更新以允许额外的blockTimestamp字段。这与 EIPS/eip-234.md为过滤器选项增加blockHash的历史经验一脉相承每次为eth_getLogs增加字段都会要求严格校验的客户端放宽 schema但老客户端在信任模式下不受影响。安全考虑规范声称该方案不引入新的安全风险它复用了已有的eth_getProof与 SSZ Merkle 证明机制安全边界完全落在以太坊现有状态树与收据树的密码学保证之上。验证者需要自行承担的风险仍与过去一致——即区块头哈希的来源必须是可信的通常通过轻客户端或共识层轻同步获得。在仓库中的定位与延伸阅读本提案属于以太坊日志可验证性路线图的一部分与本仓库中以下文档构成完整的知识链EIPS/eip-6466.mdSSZ receipts定义了本文复用的Log类型与 receipts 的 SSZ 迁移是hash_tree_root(LogEntry)的编码基础EIPS/eip-158.mdState clearing解释了为何必须将累积合约 nonce 置 1 以防被清理EIPS/eip-234.md为eth_getLogs过滤器增加blockHash选项的既有接口演进先例EIPS/eip-1474.mdJSON-RPC 规范定义了QUANTITY编码规则是blockTimestamp字段的格式依据。总结EIP-7792 通过固定地址无代码合约三个 mapping 存储槽 SSZ 日志条目 SHA256 链式累积的组合为eth_getLogs构建了一套可增量验证的链上日志累积机制。它的设计精髓在于把验证所需的全部证据沉淀进以太坊世界状态从而复用成熟的eth_getProof基建让钱包能够以获取两个区块头两个 Merkle 证明本地重放累积的轻量方式获得对日志响应正确性与完整性的密码学保证。尽管当前其 Gas 成本仍高于直接方案且提案处于Stagnant状态但它为钱包脱离可信提供商、提升隐私这一目标提供了一条清晰的、基于现有共识层原语的技术路径。说明本文基于本仓库 EIPS/eip-7792.md 及其依赖文档撰写代码与伪代码均直接引自仓库原文文中涉及的协议状态、常量与算法均以该文档当前版本为准。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

EIP-7792 可验证日志：用链上日志累积器让 eth_getLogs 响应可验证

相关推荐

宝塔面板快速部署Typecho个人博客：从零到上线全攻略

TanStack Solid Start 生成式引擎优化（GEO）实战指南：让 AI 助手准确理解、引用并推荐你的应用

ArduPilot 中通过 Lua 脚本驱动 SkyPower EFI：参数配置、CAN 通信与自动重启实战指南

更多资讯

经典ASP多用户多主题信息查询系统：从zip部署到IIS排错全解析

NFS与SMB怎么选？跨平台文件共享混用避坑指南

Flink StandAlone模式作业提交全流程实战指南

CAD图纸坐标转GIS总对不上？椭球基准与七参数转换实战指南

C盘又红？从存储原理解析到系统盘空间清理与迁移实战

Event-Driven Architecture 事件驱动架构完整实践指南：Awesome Software Architecture 的事件驱动学习与实践路线

今日更新

基于高阶循环谱的MPSK载波频率估计与MATLAB实现

MiniPdf方：.NET开源Office转PDF的高效解决方案

Solon AI v3.10：Java全栈智能体开发框架解析

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？