⚠️ Draft Meta

EIP-7919: Pureth Meta

List of EIPs belonging to the Pureth proposal

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

Abstract
Motivation
Specification
Rationale
Security Considerations
Copyright

Abstract

This Meta EIP lists the EIPs which belong to the Pureth proposal.

Motivation

It is currently not feasible to consume Ethereum data for a given account to efficiently reconstruct the account activity, without relying on a trusted API gateway. This is a problem for:

End users, through mobile or browser based wallets where a local full node is not viable
dApps that interact with Ethereum through JSON-RPC
L2 networks that read data from Ethereum through Merkle proofs
Portal network which aims to be a decentralized archive node

Relying on a trusted API gateway exposes the application to external privacy policies and region-specific restrictions.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

PURGE: LOG Reform

Certain EVM operations can change the ETH balance, without an appropriate log being emitted. For example, a SELFDESTRUCT can send an arbitrary ETH balance to an arbitrary account, e.g., as part of a smart contract based wallet. To monitor such operations, the application would have to use tracing APIs on every single transaction of every single block. Adding logs for ETH transfers enables the use of existing eth_getLogs infrastructure to obtain a fully accurate account history.

While individual eth_getLogs results can be verified against the containing block when all block headers are available, it is not viable to verify exhaustiveness of the response, i.e., no logs were withheld, as the current Bloom based log filter suffers from false positives. Further, the per-receipt logs Bloom is essentially useless because it cannot be verified independently without also downloading the full receipt including all log data. This can be addressed by a better log index that allows enumerating all logs matching a query as well as looking up position information by hash for blocks, transactions, and logs.

EIP-7668: Remove bloom filters
EIP-7745: Two dimensional log filter data structure
EIP-7792: Verifiable logs (optional, uses ZK to store the filter commitment externally)

The new log filter is based on SSZ to support proving individual parts of log data. This is useful for L2 smart contracts when processing potentially large fraud proofs where the entire receipt may be too large to fit into calldata.

PURGE: Remove old tx types

Moving logs to SSZ affects the receipts structure, which are defined by the various transaction types. Therefore, changing the receipts breaks backwards compatibility. By introducing a new transaction type, a new receipt type can be introduced. Basing that new transaction type on SSZ also enables proofs for individual parts of calldata.

Existing RLP transactions continue to be supported in the mempool, but are converted to SSZ when bundled into an execution block. The conversion is lossless, so that full nodes can recover the original RLP representation when validating a block. Besides full nodes, no other client requires that original representation: The on-chain data follows a single SSZ format that’s forward compatible across forks (StableContainer), and commitments to properties computed from the original RLP representation (from / contract_address) are included in the receipt data.

To enable native use of SSZ transactions without going through the conversion, a new signature scheme is proposed. New transaction features such as multidimensional fees, CREATE2 deployment, and post-quantum signature types, can be introduced without requiring introducing additional transaction types.

EIP-6493: SSZ transaction signature scheme (optional)

PURGE: Serialization harmonization

While the proposed changes do not affect applications that use a trusted API gateway via JSON-RPC, they represent breaking changes for applications that verify Ethereum data today. To avoid recurring breaking changes, the rest of the execution block is also transitioned to SSZ at the same time. This will likely require cooperating with popular applications that rely on assumptions about the block header layout.

With all execution structures besides the state trie transitioned to SSZ, a secondary binary API can now be defined as an alternative to the dated JSON-RPC API and could also replace the engine API. That binary API would follow the same approach as beacon-APIs, be based on REST, SSZ, and Snappy compression, and support similar functionality as JSON-RPC, except that all response data now comes with a correctness and exhaustiveness proof. The SSZ objects are designed to efficiently serve API requests, often allowing to answer directly from the database without having to decompress stored data on the server and without having to consult auxiliary indices (e.g., to answer a eth_getTransactionReceipt query).

Simple Serialize (SSZ) requirements

The EIPs require adding production-grade Simple Serialize (SSZ) libraries to all execution client implementations. Further, new SSZ data types are required to achieve forward compatibility while maintaining reasonable efficiency.

Rationale

See individual EIPs.

Security Considerations