Scaling Ethereum with recursive STARKs and the Trustless Log Index

Дата публикации: 15-09-2026 12:37:57

Scaling Ethereum with recursive STARKs and the Trustless Log Index
TL;DR The need to switch to PQ cryptography and the size of PQ signatures suggests that recursive STARK transaction pre-authorization, as proposed in EIP-8288, is a very likely upgrade path and will probably be considered a high priority in the near future. In addition to cheap signatures, in this scenario the on-chain cost of any statelessly verifiable witness data is drastically reduced, including log query proofs based on the index tables of EIP-8304 (Trustless Log Index, more info here). This makes log index tables a viable alternative to the state tree with a much lower write cost, while also making cross-chain messaging and execution sharding cheaper and easier.
Trustless chain indexers and cross-chain messages
Building an application specific chain index and validating it on-chain is already possible with SNARKs, but EIP-8288 is expected to make the on-chain ZKP verification even cheaper, making more of these applications viable. While EIP-8304 is an indexer itself, it can serve as the basis for more lightweight application specific indexers interested only in a small subset of events. Processing the entire receipt sets of each block with ZKPs is possible but expensive, and right now this cost has to be paid by anyone who wants to build their own trustless index. When built on top of the log index, they can reduce their own prover costs by relying on log filter proofs proving only the relevant set of logs since the last indexed checkpoint.
Cross-chain or cross-shard messaging is also a kind of chain indexing application where a relevant message filter function is evaluated on the source chain and validated on the target chain. Using logs to represent contract state (see below) and having cheap log-based cross-shard messaging could simplify cross-shard contract design, ultimately making execution sharding easier.
Latency and incentives: the hybrid approach of EIP-8304
Based on these considerations it is a fair question whether the log index could also be verified on-chain entirely with ZKPs, without adding anything to the core protocol. EIP-8304 specifies processing small index tables (up to 256 blocks) in the core protocol while validating further table merges on-chain with ZKPs. One reason for this is that it ensures that the index is always available even for the actual chain head, which would not be possible at all with external indexing. In any event filtering application (either user API or on-chain messaging) the most recent events are typically the most interesting. The other main reason is incentives; the log index belongs to core infrastructure and no third party is interested in funding this service alone for the entire ecosystem. Historic index tables (1024 blocks and above) need to be updated every 1024 blocks in the best case (the system can work though even if they are updated every 256k blocks), this is something that larger API providers will probably be willing to do so just to reduce their bandwidth requirements by making log query proofs smaller. Updating small tables though needs to happen at least every few blocks, otherwise the whole system is pointless (its value is significantly reduced by every unindexed recent block).
For the same latency guarantee and incentive alignment reasons, in a native multi-shard environment the cross-shard message filtering should probably also be protocol mandated, while L2 messages and application-specific indexes should be processed and paid for by their owners.
Statelessness and state expiry with log events
The main difference between the state tree and log index tables is that index tables are generated individually for each block and then asynchronously merged together. This means very cheap addition; in the block production bottleneck the current block’s entries are sorted in memory and tree hashed in a single run (cca 2 hash operations per entry). Then a logarithmic number of table merge rounds create bigger tables but those happen asynchronously and they are also efficient (merge sort with linear reads/writes and binary tree hashing) and are highly paralellizable. On the flip side, witnesses are somewhat bigger (exclusion proofs are roughly log squared instead of logarithmic), but that cost is off-chain only with ZKP pre-authorization (Note that a PoC SP1 log query proof verifier is already being worked on by Willow Network).
A new type of storage
Another difference is that logs are not a key/value store but a time series of tuples. A key/value storage can be implemented using logs (each write emits a log, each read searches for the last write to the given address) but they can also represent sets and ordered lists in a collision-free manner. This can be useful for true statelessness and cross-shard contract logic. Once a block is assembled and executed, it is easy to statelessly re-execute with BALs based on the known set of accessed keys, but if we don’t want to assume a block builder who has the entire state available then transactions need their own witnesses attached and cannot read or write keys not included there. For example, if a contract adds entries to a list then a transaction sender need to know the number of items in the list at the time of execution to correctly predict the accessed storage keys. If it is a popular contract with many hits per block then this might be hard and could turn out to be a real obstacle to actual scaling. With logs, a list can be represented by assigning each entry to the same list ID and a read can retrieve multiple entries in order, without collisions.
Of course, similar to state tree witnesses, a log witness can only prove relevant events until a known previous block. In order to make logs suitable as storage we also need to make logs emitted in the current block (or last few blocks) searchable from the EVM. Ideally this could be integrated with pre-processed witness verification, so that the contract can easily query for example the last 5 matches to a query pattern, in which case the witness can prove the last 5 matches until the parent block, some of which might be replaced during block processing if new matches have been emitted in the current block.
Availability and expiry
Entries are never removed from index tables but older tables can be forgotten by most of the network. Tables can be merged until they reach a certain size, then kept around for a while (table retention can be governed by “soft consensus” similar to EIP-4444). After that, it becomes the responsibility of users or application maintainers to remember the parts of old tables relevant to their accounts or applications, which is again possible because these tables do not change anymore so witness maintenance is not required. Contracts can also choose to implement explicit storage expiry simply by querying a limited amount of history.

Схожие новости

#	Наименование новости	Тональность	Информативность	Дата публикации
1	Bloom Filters And Keyed Nonces	0	8.23	08-09-2026
2	Public-mempool gas sponsorship needs escrow, a bond, or trust	0	6.46	14-09-2026
3	Mempool Account Transaction Capacity from Historical Activity (MATCHA)	0	9.38	22-09-2026
4	Etheorem update: the complete executable consensus specs written in Lean 4	0	4.8	21-09-2026
5	Native UTXOs on Ethereum	0	6.61	08-09-2026
6	EIP-8411: what segmented payload diffusion is made of	0	8.61	17-09-2026
7	ERC-8354: Confidential Agent Policy Verdicts	0	12.87	24-07-2026
8	Exploring the Design Space for a Post-Quantum Public Key Registry for Ethereum Validators	0	9.18	07-09-2026
9	Lean4 SSZ library: formally verified and easy to use	0	13.53	13-09-2026
10	[Idea/Draft] Protocol-Level Smart Contract Invariant Protection via Pre-Mempool Validation (Security Manifests)	0	10.76	22-07-2026

Классификация: . Схожих патентов: 0. Схожих новостей: 10. Тональность: 0. Информативность: 6.14. Источник: ethresear.ch.