This Meta EIP bundles a set of improvements to make Ethereum data easier to access and verify without relying on trusted RPC providers or third-party indexers. The improvements achieve this by changing data structures for blocks, transactions, and receipts, so that efficient correctness (i.e., validity) and completion (i.e., nothing omitted) proofs can be added to the RPC responses.
Security: Today, most wallets and dApps consume data from very few large RPC providers, which exposes users to the risk of incorrect and incomplete data in case the RPC provider gets hacked, becomes malicious, or uses a faulty software version.
Privacy: Centralized infrastructure is subject to external data collection and privacy policies; users may be profiled across distinct wallets even when there is no on-chain link between them.
Cost: External indexers can be quite costly, however, are required for even basic wallet use cases. Reducing reliance on them helps lower-funded developers.
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.
ETH transfers currently don't emit logs, and in many situations don't leave any on-chain record in neither transaction nor receipt that they took place. For example, SENDALL can send an arbitrary ETH balance to an arbitrary account as part of a smart contract based wallet. Or a new contract deployment may send ETH to a new account of which not even the address is known yet. This makes basic flows, such as detecting a user deposit onto an exchange, very tricky. Wallets, dApps etc. either have to use tracing debug APIs on every single transaction of every single block, or integrate an external trusted indexing service which can be costly.
The current 2048-bit Bloom filter has a high false positive rate, which grows further as more logs are packed into each block. Combined with the requirements to obtain all historical block headers to obtain a complete view of an account's history, the Bloom filter becomes practically irrelevant. A new on-chain 2D log index with bounded false positive rate and a historical accumulator is proposed that is highly efficient, further reducing the need for external indexing services for basic wallet use cases.
There are various JSON-RPC fields that are missing on-chain and inefficient to prove:
from, contractAddress, and authority addresses: need to fetch transaction + use ecrecovergasUsed: needs current and prior receipt, as on-chain data stores cumulative not individual gas usedlogIndex: need to fetch all receipts in the blocktxHash: the on-chain data is based on an MPT-prefixed hash, which is different from the RPC hashFurther, calldata and log data can be very large, but can only be verified by downloading the entire receipt / transaction data. This data is needed even if just basic items such as amount and destination are queried.
Switching transactions and receipts to SSZ normalizes the format, changes to tree-based hash for more efficient proofs, and is also extensible for future transaction features such as multidimensional fees, CREATE2 deployment, and post-quantum signature types, without breaking verifiers that only check common fields.
Changing the remainder of the EL to SSZ enables a switch to a binary API as an alternative to the dated JSON-RPC API. This is especially interesting for the engine API which currently encodes all blobs as ASCII hex-strings over JSON. 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.
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 when using nested lists of large theoretical capacity.
See individual EIPs.
See individual EIPs.
Copyright and related rights waived via CC0.