Вход на сайт

Просмотр новости

Найдите то, что Вас интересует

EIP-8304: Trustless log and transaction index

Дата публикации: 26-10-2026 17:56:44

Hi! If there is a new version of eth_getLogs then I think it is indeed a good idea to prepare for adding proofs. Now regarding EIP-8304, the good thing is that technically speaking it is in a pretty good state, the proof generation and verification is implemented and proven efficient, I even implemented an API endpoint. The not so good thing is that it’s been rejected for H* because other priorities or whatever. Which does not mean that it cannot get into I* or some subsequent fork, but I don’t want this project to get stuck for years so I decided to try to validate the log index without a protocol change, using ZKPs. So leaving the proof format open is a wise choice, because while I intend to see this project through, it’s really not clear in what exact form it is going to work out in the end and that will also affect the proof format.
Specifying the referenceHead parameter and proof response now as placeholders is possible, though I think adding them later is no big deal either if it does not change the behavior of the API otherwise. Regarding the result count, I think it is important regardless of proofs to have a result count limitation. And I would also strongly suggest to add a “reverse limitation” option, meaning that the request returns the last N results if there are more than N results in the searched range. I think it is even more useful than the “forward limitation”. If you want to list certain interesting events and it turns out that there are millions of them then it feels logical that you would want to see the most recent ones first and then either paginate backwards or tighten the search params.
Btw you can check out the currently implemented proof format here (note that if we go the ZKP way then the top part of the proof, the table root proving logic will be different)
And here is my PoC logs-with-proofs API endpoint spec. It’s different from JSON-RPC and more similar to the CL REST API, but the result count limitation logic could be applied to the JSON-RPC call format too.

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

#Наименование новостиТональностьИнформативностьДата публикации
1All Core Devs - Consensus (ACDC) #183, July 23 2026015.1813-07-2026
2[Idea/Draft] Protocol-Level Smart Contract Invariant Protection via Pre-Mempool Validation (Security Manifests)010.7622-07-2026
3EIP-8386: Transaction Events View014.9521-08-2026
4ERC-8354: Confidential Agent Policy Verdicts012.8724-07-2026
5ERC-TBA: Agent Credit Backers08.7826-10-2026
6EIP-8372: Normalized state gas limit010.9406-08-2026
7ERC-8004: Trustless Agents08.5427-07-2026
8ERC-8350: Agent Memory State Registry013.3214-08-2026
9EIP-8037: State Creation Gas Cost Increase019.6728-07-2026
10Rapidblocks with split proofs: execution proofs that outlive their state05.914-10-2026

Классификация: . Схожих патентов: 0. Схожих новостей: 10. Тональность: 0. Информативность: 5.18. Источник: ethereum-magicians.org.