EIP-7919: Pureth 元提案
属于 Pureth 提案的 EIP 列表
Authors | Etan Kissling (@etan-status), Gajinder Singh (@g11tech) |
---|---|
Created | 2025-03-26 |
Discussion Link | https://ethereum-magicians.org/t/eip-7919-pureth-meta/23273 |
Requires | EIP-6404, EIP-6465, EIP-6466, EIP-6493, EIP-7495, EIP-7668, EIP-7688, EIP-7706, EIP-7708, EIP-7745, EIP-7792, EIP-7799, EIP-7807, EIP-7916 |
Table of Contents
摘要
本 Meta EIP 列出了属于 Pureth 提案的 EIP。
动机
目前,在不依赖可信 API 网关的情况下,为了有效地重构账户活动,消费给定账户的以太坊数据是不可行的。这对以下情况来说是一个问题:
- 终端用户,通过移动端或基于浏览器的钱包,因为本地全节点不可行
- 通过 JSON-RPC 与以太坊交互的 dApp
- 通过 Merkle 证明从以太坊读取数据的 L2 网络
- 旨在成为去中心化存档节点的 Portal 网络
依赖可信 API 网关会将应用程序暴露于外部隐私政策和特定地区的限制。
规范
本文档中的关键词“必须”、“禁止”、“需要”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选”按照 RFC 2119 和 RFC 8174 中的描述进行解释。
PURGE: LOG 改革
某些 EVM 操作可能会更改 ETH 余额,而不会发出适当的日志。例如,SELFDESTRUCT 可以将任意 ETH 余额发送到任意账户,例如,作为基于智能合约的钱包的一部分。为了监控此类操作,应用程序必须在每个区块的每个交易上使用追踪 API。为 ETH 转移添加日志可以使用现有的 eth_getLogs
基础设施来获取完全准确的账户历史记录。
当所有区块头可用时,可以对照包含区块验证单个 eth_getLogs
结果,但是验证响应的穷尽性是不可行的,即没有隐藏任何日志,因为当前基于 Bloom 的日志过滤器存在误报。此外,每个收据的日志 Bloom 基本上是无用的,因为它无法在不下载包括所有日志数据的完整收据的情况下独立验证。这可以通过更好的日志索引来解决,该索引允许枚举与查询匹配的所有日志,以及按哈希查找区块、交易和日志的位置信息。
- EIP-7668: 移除 bloom 过滤器
- EIP-7745: 二维日志过滤器数据结构
- EIP-7792: 可验证的日志 (可选,使用 ZK 在外部存储过滤器承诺)
新的日志过滤器基于 SSZ,以支持证明日志数据的各个部分。这对于 L2 智能合约在处理可能很大的欺诈证明时非常有用,因为整个收据可能太大而无法放入 calldata 中。
PURGE: 移除旧交易类型
将日志移动到 SSZ 会影响由各种交易类型定义的收据结构。因此,更改收据会破坏向后兼容性。通过引入新的交易类型,可以引入一种新的收据类型。将新的交易类型建立在 SSZ 的基础上还可以为 calldata 的各个部分启用证明。
现有的 RLP 交易继续在 mempool 中得到支持,但在捆绑到执行块中时会转换为 SSZ。转换是无损的,因此完整节点可以在验证块时恢复原始 RLP 表示形式。除了完整节点之外,没有其他客户端需要原始表示形式:链上数据遵循单一的 SSZ 格式,该格式在 fork 之间向前兼容 (StableContainer
),并且从原始 RLP 表示形式计算出的属性(from
/ contract_address
)的承诺包含在收据数据中。
为了在不经过转换的情况下启用 SSZ 交易的本地使用,提出了一种新的签名方案。可以在不引入其他交易类型的情况下引入新的交易功能,例如多维费用、CREATE2 部署和后量子签名类型。
- EIP-6493: SSZ 交易签名方案 (可选)
PURGE: 序列化协调
虽然提议的更改不会影响通过 JSON-RPC 使用可信 API 网关的应用程序,但它们代表了对今天验证以太坊数据的应用程序的重大更改。为避免重复的重大更改,执行块的其余部分也同时转换为 SSZ。这可能需要与依赖于有关区块头布局的假设的流行应用程序合作。
除了状态树之外的所有执行结构都已转换为 SSZ,现在可以将辅助二进制 API 定义为过时的 JSON-RPC API 的替代方案,并且也可以取代引擎 API。该二进制 API 将遵循与 beacon-APIs 相同的方法,基于 REST、SSZ 和 Snappy 压缩,并支持与 JSON-RPC 类似的功能,不同之处在于,现在所有响应数据都带有正确性和穷尽性证明。SSZ 对象旨在有效地服务于 API 请求,通常允许直接从数据库回答,而无需解压缩服务器上存储的数据,也无需查询辅助索引(例如,回答 eth_getTransactionReceipt
查询)。
简单序列化 (SSZ) 要求
这些 EIP 需要将生产级别的简单序列化 (SSZ) 库添加到所有执行客户端实现中。此外,需要新的 SSZ 数据类型才能在保持合理的效率的同时实现向前兼容性。
理由
请参阅各个 EIP。
安全注意事项
请参阅各个 EIP。
版权
在 CC0 下放弃版权及相关权利。
Citation
Please cite this document as:
Etan Kissling (@etan-status), Gajinder Singh (@g11tech), "EIP-7919: Pureth 元提案 [DRAFT]," Ethereum Improvement Proposals, no. 7919, March 2025. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7919.