EIP-8304 解读基于系统合约的免信任日志与交易索引Index Tables【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-8304Trustless log and transaction index免信任日志与交易索引提出在区块处理逻辑中将按区块生成的「索引表」index tables的根哈希写入一个系统合约的存储中从而为日志log与交易查询提供规模合理、可验证的免信任证明。本文以 EIPS/eip-8304.md 为骨架完整展开其条目编码、建表/合并规则、系统合约 get/set 语义、EVM 字节码与部署流程并结合仓库内 EIPS/eip-4788.md、EIPS/eip-8141.md、EIPS/eip-7708.md、EIPS/eip-161.md 等关联提案说明其演进脉络。读完本文你将理解为什么现有 bloom filter 已无法支撑内容查询、索引表如何用固定深度的二叉树哈希与合并、客户端如何以极小的额外成本在区块处理期间维护多级索引、以及系统合约如何遵循 EIP-4788 的SYSTEM_ADDRESS调用约定完成根哈希的写入与读取。1. 背景与动机日志便宜但查不到以太坊上写入日志LOG操作的 gas 成本显著低于写状态因此日志是链上事件数据的低成本载体。然而协议层面定义的数据结构并没有提供任何接近高效的内容查找手段区块头中原有的 per-block bloom filter 早期尚可如今已严重饱和oversaturated实际几乎不可用全节点可以自行维护索引结构但大多数用户依赖远程提供方RPC 服务商而这些提供方无法证明查询结果的正确性依赖可信第三方来获取智能合约的输出违背了将这些合约维护在分布式免信任账本上的初衷。EIP-8304 提出的索引机制具有两个关键特性更新成本远低于状态树——区块处理期间只做哈希与少量存储写入LOG的 gas 成本无需提高查询证明规模合理——通过多级索引表 二叉树的 Merkle 包含/排除证明用户可以自行验证查询结果。1.1 免信任的端用户访问随着以太坊处理能力增长信息不对称只会加剧签名交易的端用户应用与获取结果的另一端用户应用之间依赖的是不可证明的中间服务。EIP-8304 的目标是把「免信任可证明性」贯穿整个技术栈——从端用户应用签名交易到该应用或其他应用获取所需结果都应当建立在可验证的证明之上而不是对远程节点的信任之上。1.2 跨链通信日志条目带有时间维度非常适合做差量更新differential updates接收方合约可以只处理「自上次更新以来」的相关事件的索引查询证明。只要知道另一条实现了本 EIP 的链的近期区块哈希就能高效地以日志形式接收来自该链的消息——这为跨链消息传递提供了免信任的基础。1.3 与 ZKP 批量预检查的协同无状态见证stateless witnesses与后量子PQ签名都会显著增加证明交易有效性所需的数据量。一个可预见的改进路径是用递归 ZKP 批量完成这些授权/验证步骤从而避免在整个网络中传播全部授权与见证数据。仓库中的 EIPS/eip-8141.mdFrame Transaction已经支持把交易执行拆出纯代码部分。虽然日志查询证明比状态见证更大但未来可以在 ZKP 批处理中做验证链上只提交查询引用与结果从而最小化链上 gas 成本。1.4 一种新的「状态」形态如果 EVM 未来扩展出「查询当前块或最近若干块中日志」的能力这些块尚未被批量证明覆盖日志甚至可以作为状态的替代形态写入极便宜写日志比写状态便宜得多天然支持过期合约设计上可以只检索最近 N 个块轻松实现过期策略缓解状态膨胀协议参与者可以遗忘任何超过几百个块的历史把证明更早数据的责任交给用户对异步/并行执行友好日志写入从不冲突。2. 核心设计多级索引表2.1 参数一览参数值TABLE_SIZES[1, 4, 16, 64, 256]TABLES_PER_LEVEL1024SYSTEM_ADDRESS0xfffffffffffffffffffffffffffffffffffffffeINDEX_CONTRACT_ADDRESSTBDEIP 定义len(TABLE_SIZES) 5 级索引表每一级表索引固定数量的区块第i级表的table_size TABLE_SIZES[i]。各级表的根哈希存放在系统索引合约中长度为TABLES_PER_LEVEL1024的环形缓冲区ring buffer里。2.2 索引表Index Tables的构成一张索引表是索引条目index entries的有序列表被哈希进一棵固定深度的二叉树。要点如下条目有多个类型每种类型有独立的二进制编码格式该格式同时用于哈希与排序表中条目的顺序是其二进制表示的字典序lexicographical ordering每个区块会按索引规则生成一组确定的索引条目每张表代表「单个区块」或「同一链上一段连续区块」生成的条目在给定规范链canonical chain的语境下表由first_block与table_size区块数量唯一标识表可以基于区块及其收据直接生成也可以通过合并相邻区块范围的已排序表得到。协议规定在固定数量的层级上生成表每层table_size TABLE_SIZES[i]first_block始终是table_size的倍数且对i0TABLE_SIZES[i]总是TABLE_SIZES[i-1]的倍数。这使得高层表可以由下一层的固定数量表合并而来本设计中每张高层表由 4 张低层表合并。2.3 条目类型与编码条目类型type id内容位置信息编码长度block0区块哈希区块号2328 42transaction1交易哈希区块号、交易索引、累计日志数232844 50log.address2日志地址区块号、交易索引、日志索引220844 38log.topics[0]3日志主题区块号、交易索引、日志索引232844 50log.topics[1]4日志主题区块号、交易索引、日志索引232844 50log.topics[2]5日志主题区块号、交易索引、日志索引232844 50log.topics[3]6日志主题区块号、交易索引、日志索引232844 50编码要点条目 条目类型 id2 字节 可搜索内容 位置信息交易条目额外携带累计日志数cumulative log count即该交易之前块内日志总数用于证明「该交易之后没有更多匹配日志」地址/主题条目的日志索引相对于交易开始处所有数字按**大端序big-endian**编码保证基于二进制表示的排序正确log.address内容为 20 字节地址其余内容均为 32 字节哈希/主题。2.3.1 EIP-8141 扩展帧索引如果激活了 EIPS/eip-8141.mdFrame Transaction则交易索引与日志索引之间会插入一个两字节的帧索引frame index。文档特别指出用独立帧索引编码位置信息在收据编码改为 SSZ 时最有用但「现在就加上」比以后升级更容易收据格式本身不直接影响本协议更新但树哈希的收据编码可以基于 tx/frame/log 位置信息给出单个日志的 Merkle 包含证明使日志查询证明显著更高效由于索引条目提供的是「证明包含集合完备性」的排除证明其位置编码必须与包含证明的位置信息匹配二者才能相互对证。2.3.2 未来扩展性未来若区块结构变化可能需要新增条目类型或修改位置编码这无需对分叉前区块重建索引——分叉前后的表条目可以直接合并。需要维护的唯一不变量是条目按照与哈希所用相同的二进制编码进行字典序排序。由于条目以类型 id 为前缀新增描述新事件种类的条目类型毫无障碍也可以在位置信息的区块号字段之后修改或扩展已有编码同时保持「类型与值相同的条目位置顺序」正确。2.4 索引规则Indexing rules交易与日志地址/主题索引很直接被索引区块中的每笔交易、每个日志事件都添加相应索引条目区块条目延迟一个区块添加对区块N添加的是父区块N-1的区块条目创世块不添加区块条目因此覆盖区块范围first_block到first_block table_size - 1的多块合并表包含的是first_block - 1到first_block table_size - 2的区块条目这个一个区块的偏移one-block offset源于单块表是在处理实际区块时被引用的而此时该区块自身的哈希尚不可知。2.5 索引表示例Block #40–#43假设表覆盖以下四个区块Block #40空Block #41空Block #42Tx #0WETH 从 Alice 转账给 BobUSDT 从 Bob 转账给 AliceTx #1Bob 的 WETH 提款Block #43Tx #0USDT 从 Alice 转账给 Carol按时间顺序生成的未排序条目如下注意 Block 条目来自 39–42Block #Tx #Log #TypeValue390 (Block)0xbf98e6cb26f6ff... (block hash)400 (Block)0x42f66a2e9f9c68... (block hash)410 (Block)0x978ce0036b6d1c... (block hash)42001 (Tx)0xca2d12d1b8132d... (tx hash)42002 (Address)0xc02aaa39b223fe... (WETH)42003 (Topic0)0xddf252ad1be2c8... (Transfer)42004 (Topic1)0x00..004a5e9a3b... (Alice)42005 (Topic2)0x00..00f2a5fd4d... (Bob)42012 (Address)0xdac17f958d2ee5... (USDT)42013 (Topic0)0xddf252ad1be2c8... (Transfer)42014 (Topic1)0x00..00f2a5fd4d... (Bob)42015 (Topic2)0x00..004a5e9a3b... (Alice)42121 (Tx)0xa75590c9ced728... (tx hash)42102 (Address)0xc02aaa39b223fe... (WETH)42103 (Topic0)0x7fcf532c15f0a6... (Withdrawal)42104 (Topic1)0x00..00f2a5fd4d... (Bob)420 (Block)0x66f42ef12b140e... (block hash)43001 (Tx)0x7046035b326ab2... (tx hash)43002 (Address)0xdac17f958d2ee5... (USDT)43003 (Topic0)0xddf252ad1be2c8... (Transfer)43004 (Topic1)0x00..004a5e9a3b... (Alice)43005 (Topic2)0x00..00ac8cbe20... (Carol)按排序优先级重排后得到已排序的索引表先按类型再按值最后按位置TypeValueBlock #Tx #Log #0 (Block)0x42f66a2e9f9c68... (block hash)400 (Block)0x66f42ef12b140e... (block hash)420 (Block)0x978ce0036b6d1c... (block hash)410 (Block)0xbf98e6cb26f6ff... (block hash)391 (Tx)0x7046035b326ab2... (tx hash)43001 (Tx)0xa75590c9ced728... (tx hash)42121 (Tx)0xca2d12d1b8132d... (tx hash)42002 (Address)0xc02aaa39b223fe... (WETH)42002 (Address)0xc02aaa39b223fe... (WETH)42102 (Address)0xdac17f958d2ee5... (USDT)42012 (Address)0xdac17f958d2ee5... (USDT)43003 (Topic0)0x7fcf532c15f0a6... (Withdrawal)42103 (Topic0)0xddf252ad1be2c8... (Transfer)42003 (Topic0)0xddf252ad1be2c8... (Transfer)42013 (Topic0)0xddf252ad1be2c8... (Transfer)43004 (Topic1)0x00..004a5e9a3b... (Alice)42004 (Topic1)0x00..004a5e9a3b... (Alice)43004 (Topic1)0x00..00f2a5fd4d... (Bob)42014 (Topic1)0x00..00f2a5fd4d... (Bob)42105 (Topic2)0x00..004a5e9a3b... (Alice)42015 (Topic2)0x00..00ac8cbe20... (Carol)43005 (Topic2)0x00..00f2a5fd4d... (Bob)4200对应的二进制编码字典序与上表顺序一致如下。读者可以对照解析0001前缀后跟 32 字节交易哈希、8 字节区块号、4 字节交易索引、4 字节累计日志数/日志索引000042f66a2e9f9c68e223e8d826145d7cfacb00520dba6a9555803121de29790b650000000000000028 000066f42ef12b140e8004ad39a760191457f485204ee6c9f990c33f14014e521f20000000000000002a 0000978ce0036b6d1c62d716045505587d15cc85a1def92f9f450937b6467295e5170000000000000029 0000bf98e6cb26f6ff312586968d1f343a3d3c439a8c5c86233aff2a82f1a68263df0000000000000027 00017046035b326ab22a3142e4416ed4300a28a483a31a1e04cf62bec575b2e7cf09000000000000002b0000000000000000 000175590c9ced72898d6207c917e11b452949043404a1802b893f7717a9c1c8f45d000000000000002a0000000100000002 0001ca2d12d1b8132de09d0d668cc87349dc70134bee3010e03ddb2d83f7160bd6e3000000000000002a0000000000000000 0002c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2000000000000002a0000000000000000 0002c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2000000000000002a0000000100000000 0002dac17f958d2ee523a2206206994597c13d831ec7000000000000002a0000000000000001 0002dac17f958d2ee523a2206206994597c13d831ec7000000000000002b0000000000000000 00037fcf532c15f0a6db0bd6d0e038bea71d30d808c7d98cb3bf7268a95bf5081b65000000000000002a0000000100000000 0003ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef000000000000002a0000000000000000 0003ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef000000000000002a0000000000000001 0003ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef000000000000002b0000000000000000 00040000000000000000000000004a5e9a3bf35df5e0ea4b4cd3289e0111f1deadf7000000000000002a0000000000000000 00040000000000000000000000004a5e9a3bf35df5e0ea4b4cd3289e0111f1deadf7000000000000002b0000000000000000 0004000000000000000000000000f2a5fd4d5bb24b651d1198bc014941a16f6edde5000000000000002a0000000000000001 0004000000000000000000000000f2a5fd4d5bb24b651d1198bc014941a16f6edde5000000000000002a0000000100000000 00050000000000000000000000004a5e9a3bf35df5e0ea4b4cd3289e0111f1deadf7000000000000002a0000000000000001 0005000000000000000000000000ac8cbe20039c2e9547da9107456179bd4f39a734000000000000002b0000000000000000 0005000000000000000000000000f2a5fd4d5bb24b651d1198bc014941a16f6edde5000000000000002a0000000000000000观察几个细节Block #40 的区块号十六进制0x28、#41 为0x29、#42 为0x2a、#43 为0x2b且区块条目按值哈希而非按区块号排序——这正是「以二进制表示的字典序」的体现同一 WETH 地址0xc02aaa...在 Block #42 的两笔交易Tx #0 Log #0、Tx #1 Log #0各出现一次地址值相同则按位置排序。2.6 表根哈希计算表根哈希是如下 SSZ 列表的根List[Hash32, entry_count]其中列表元素是各条目的二进制编码的SHA2-256 哈希entry_count是表中条目总数。说明与以太坊状态树普遍使用的 Keccak-256 不同此处哈希算法选择 SHA2-256并且采用 SSZ 的 Merkleization 规则对定长哈希列表求根。3. 区块处理Block processing对每个协议强制的索引层级i生成table_size TABLE_SIZES[i]且first_block为该table_size倍数的表并将其table_root加入索引合约层级 0单块表处理完所有交易后立即添加更高层级表延迟TABLE_SIZES[i] // 4个区块后同样在对应区块处理结束时添加。例如 256 块表延迟 64 块。延迟机制保证了高层表可以异步地从低层表合并而不会增加区块处理延迟。3.1 系统调用约定对齐 EIP-4788表根通过一次以SYSTEM_ADDRESS0xfffffffffffffffffffffffffffffffffffffffe为调用者的对INDEX_CONTRACT_ADDRESS的调用来写入calldata 为 3×32 字节first_block、table_size均大端序与table_rootgas 上限30_000_000value 为0。这会触发历史合约的set()例程。这是与 EIPS/eip-4788.md 相同的系统操作约定因此调用必须执行到完成调用不计入区块 gas 上限调用不遵循 EIP-1559 的销毁语义——调用中不应转移任何 value如果INDEX_CONTRACT_ADDRESS处没有代码调用必须静默失败。备注客户端也可以选择直接写入合约存储但通过 EVM 调用合约仍是首选方案。3.2 链/状态同步后的初始化本 EIP不需要扩展同步协议所有必需的表都可以在同步完成后从近期区块重新生成。最坏情况下同步后验证的第一个区块恰好是需要添加最高层级表根的那个区块客户端需要最近TABLE_SIZES[len(TABLE_SIZES)-1] * 5 // 4 - 1个区块来生成该表根——在当前参数下为319 个区块。虽然客户端目前同步并保留的链历史远超此数但即便未来发生变化仅为建索引而下载这些区块相比同步状态也是一次性、极小的成本。3.3 未来的无状态/执行证明实现在完全无状态协议中状态转换可仅基于见证验证、客户端以最小启动开销开始验证表合并也可以借助「部分合并表的见证」实现。例如一个 64 块表同时落在 256 块边界上刚被添加延迟 16 块需要在随后 48 个块内完成最后四张 64 块表的合并那么无状态协议可以基于合并表预期的总entry_count定义均匀分布的entry_index检查点并要求每批见证都附带「下一个检查点处部分合并表的 Merkle 边界证明」。这样每个区块的生产者承诺表的下一段合并结果而验证者可以基于低层级各表对应切片的见证来验证该切片。同样的方法也可用于生成执行 ZKP不过表合并也可以选择异步证明。无论如何实现历史索引合约见下文都需要表合并的 ZKP。4. 索引合约Index Contract索引合约仿照 EIPS/eip-4788.md 的信标根合约设计提供两个操作get与set。输入本身不用于选择函数而是依据caller判断当caller SYSTEM_ADDRESS时执行set否则执行get。4.1get调用者以 calldata 提供索引表参数first_block位于calldata[0:32]大端序table_size位于calldata[32:64]大端序在以下任一情况下回滚revertcalldata 不是 64 字节first_block不是table_size的倍数请求的表根尚未设置或已按当前block.number被环形缓冲区覆盖取回的table_root为零——无论是因为分叉后从未初始化还是table_size无效。否则从存储位置table_size * TABLES_PER_LEVEL (first_block // table_size) % TABLES_PER_LEVEL取回有效table_root并返回。get有两种典型用途在 EVM 内验证链上索引表证明或配合执行见证execution witness作为链下索引查询证明的一部分。证明方与验证方也可以自行计算存储地址并基于状态证明创建/验证但需注意其他索引合约见下文可能使用不同的内部存储方案。4.2set调用者以 calldata 提供三个参数first_block位于calldata[0:32]大端序table_size位于calldata[32:64]大端序table_root位于calldata[64:96]然后将存储位置table_size * TABLES_PER_LEVEL (first_block // table_size) % TABLES_PER_LEVEL的值设置为table_root。约定前提first_block是table_size的倍数、table_size是TABLE_SIZES列表中的值之一且合约在区块first_block table_size - 1 table_size // 4的所有交易处理完之后被调用。4.3 合约字节码EIP 给出了可直接用于索引合约的精确 EVM 汇编caller push20 0xfffffffffffffffffffffffffffffffffffffffe eq push1 0x60 jumpi push1 0x40 calldatasize sub push1 0x5c jumpi push1 0x20 calldataload dup1 push1 0x80 shr push1 0x5c jumpi push2 0x0400 dup2 push1 0x04 dup2 div number sub div dup3 dup3 mul swap3 push0 calldataload dup2 dup2 mod push1 0x5c jumpi div swap1 dup2 sub not push2 0x03ff lt push1 0x5c jumpi mod add sload dup1 iszero push1 0x5c jumpi push0 mstore push1 0x20 push0 return jumpdest push0 push0 revert jumpdest push1 0x40 calldataload push1 0x20 calldataload push2 0x0400 dup2 dup2 mul swap2 push0 calldataload div mod add sstore stop对照逻辑可以确认开头比较caller与SYSTEM_ADDRESS相等则跳转到set分支0x60处get分支校验 calldata 长度 64、校验first_block % table_size 0、校验环形缓冲区范围内且值非零最后sloadreturn32 字节所有失败路径都跳到0x5c处的revertset分支calldataload(0x20)得到table_size、calldataload(0x40)得到table_root计算存储槽table_size * 0x0400 (first_block // table_size) % 0x0400后sstorestop。4.4 部署合约通过「从期望的部署交易反推合成地址」的方式部署。EIP 给出如下部署交易模板{ type: 0x0, nonce: 0x0, to: null, gas: 0x3d090, gasPrice: 0xe8d4a51000, maxPriorityFeePerGas: null, maxFeePerGas: null, value: 0x0, input: 0x60758060095f395ff33373fffffffffffffffffffffffffffffffffffffffe1460605760403603605c576020358060801c605c576104008160048104430304828202925f35818106605c5704908103196103ff10605c570601548015605c575f5260205ff35b5f5ffd5b604035602035610400818102915f350406015500, v: TBD, r: TBD, s: TBD, hash: TBD }其中 input 是运行时字节码前面加上简单构造前缀constructor prefixing得到的 initcode。发送者地址与INDEX_CONTRACT_ADDRESS即rlp([sender, 0])该账户部署的第一个合约地址由 TBD 项推导。虽然这种合约创建方式不像 create2 那样绑定特定 initcode但合成地址在密码学上绑定于交易的输入数据即 initcode。4.5 历史索引合约History index contract本 EIP 强制所有协议参与者用固定的一组表大小更新INDEX_CONTRACT_ADDRESS处的索引合约。在此基础上更大的表覆盖数百万区块也可以生成并存入其他索引合约中这些合约共享相同的get接口但有自己的方式确保存储的表根正确索引查询证明的接收方可以自行决定除系统合约外还信任哪些替代索引合约基础设施提供方为了给长历史查询提供规模合理的证明可能维护覆盖数百万区块的索引表。为了向客户端免信任地证明这些协议外表他们可以生成表根的 ZKP并发送给一个「验证对应证明后才存储根」的索引合约历史索引合约在本 EIP 中不定义——它是独立开发工作且技术上与本协议变更相互独立。4.6 替代索引合约替代或扩展的索引数据也可以存入索引表并在索引合约中引用。例如 EIPS/eip-7708.mdETH 转账发日志激活后可以用新增的 ETH 转账/销毁日志对整个链历史重新处理并加入索引表。虽然用 ZKP 证明 11 年重处理链历史的正确性以当今技术可能过于昂贵但作为一次性场景通过人类共识认可一个不可变索引合约的正确性或许是可接受的。4.7 EIP-161 处理上述字节码以 EIP-4788 的方式部署à la EIP-4788。因此INDEX_CONTRACT_ADDRESS处的账户会有代码、nonce 为 1并豁免于 EIPS/eip-161.md 的空账户清理规则。这与信标根合约的账户处理保持一致。4.8 Gas 成本由于生成单块索引表的成本很低且更大的表可以在区块处理之间异步合并LOG操作的 gas 成本不需要提高。5. 设计理由Rationale5.1 协议内 ZKP 的混合方案设计在协议内维护有限大小最多 256 块的表同时假设更大的表数百万区块由基础设施维护者创建并通过 ZKP 证明。若在协议内创建大型历史表会给所有节点带来显著额外负担隐含「所有节点都持有数百万区块链历史」的假设这与当前路线图未来兼容性不符。之所以选择「协议内 ZKP」混合方案是因为完全交给外部证明者无法达到同等效用即使索引合约每块更新一次每块一次链上 ZKP 验证的高成本最后一个区块永远不会被索引若链上更新不那么频繁链最近段通常是最感兴趣的事件区段不会被索引任何有意义的证明都要包含自上次合约更新以来的全部区块收据对 API 证明而言成本不切实际对链上/跨链证明而言更是不可行。5.2 表层级数量与环形缓冲区大小当前参数下协议内维护 5 级表表大小构成公比为 4 的几何序列——第 0 级以上的每张表都由下一级 4 张表合并而来。公比 4 是「索引查询证明大小开销」与「协议内处理成本」之间的平衡更小的公比达到同样最高table_size256需要更多层级因此需要更多树哈希更大的公比会增加每个证明所需的小表数量查询证明要覆盖被查询区块范围用覆盖相邻区块范围的独立表证明拼接从而增大典型证明体积。每级环形缓冲区长度为 1024 张表意味着大约最近2**18个区块由 256 块表覆盖其根哈希被引用在状态中。更早的链历史预期由 ZKP 证明的大表覆盖并引用在历史索引合约中理想情况下每 1024 个区块可以向历史索引合约添加一张 1024 块表这样每级实际上只需要最近 0..4 张表但由于依赖外部参与者不宜完全依赖这种假设因此在系统索引合约中保留更多表根更稳妥每级存储 1024 个表根的数据量并不过分且只要最近被证明的历史表不早于约 36 天整条链就保持可搜索若使用数百张表证明效率会下降、证明时间会增加正常的索引查询证明预期由 30–50 张单表证明组成因此在系统合约中存储长得多的表根历史是无用的——证明效率无论如何都会变得不切实际。6. 向后兼容性本 EIP 对区块验证规则集引入了向后不兼容的变更但这两类变更都不会破坏当前用户活动与体验相关的任何内容。7. 安全考量合约系统或非系统存在「热更新路径」即分支会带来「分支投毒」branch poisoning攻击风险攻击者可能在这些热路径周围撒布微量 ETH。但评估认为要造成状态根更新出现有意义的变慢攻击成本会显著升级因此该风险可接受。8. 版权本提案相关权利依据 LICENSE.md 中声明的 CC0 协议放弃。9. 关联提案与阅读路径EIP-8304 处于 Draft 状态创建于 2026-06-17作者 Zsolt Felföldi属于 Standards Track / Core 类别依赖 EIPS/eip-4788.md。理解本提案建议按以下顺序阅读仓库内资料EIPS/eip-4788.md系统合约调用约定的来源SYSTEM_ADDRESS、get/set双操作模式与环形缓冲区设计均沿袭于此EIPS/eip-8141.mdFrame Transaction激活后索引条目位置信息将插入帧索引字段EIPS/eip-7708.mdETH 转账发日志激活后可据此对历史重新处理以构建替代索引EIPS/eip-161.md状态树清空规则索引合约账户据其获得豁免。各关联提案在仓库中的对应文件均可直接查阅原文作为实现与讨论的进一步依据。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考