Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA Nice post! I think exploring designs without batch decryption is a useful direction, and I appreciate the detailed discussion of the design choices and tradeoffs.
Reading the design, I have a concern regarding rejected payloads, if I interpret the following passage correctly:
GottfriedHerold:
If the etx_seen bitfield of the block with rejected payload was valid, then the next (hopefully non-empty) block B' must contain the exact same etx_seen bitfield. Otherwise, it behaves like a missed slot, i.e., B' must decrypt and execute those transactions ToB, whose tickets are in B's grandparent and whose etx_seen bitfield is in B's parent block.
Observe that the key that is to be released in B' is actually the same as the one that may have been released in B. If it was already released in B, then the etx_seen bitfield in B must have been valid, so the etx_seen bitfield in B' must be the same and the builder of B' cannot choose it depending on sk_id and the transactions that can be decrypted with it.
It seems as if the payload of B' (the recovery payload) executes only the transactions intended for the failed payload, while carrying forward etx_seen for those whose key may already have been released during the slot of B. In LUCID, we execute both the decrypted transactions intended for the failed payload and those intended for the next payload together ToB, older first. It seems to me that this should also be incorporated here.
While the new tickets introduced in B can be invalidated, there are still transactions intended for execution in the slot of B, as well as transactions whose key may have been released during that slot. Their tickets were included in B's grandparent and parent, respectively, so knowing that their ticket-carrying payloads were valid does not prevent this overlap. Preserving etx_seen fixes the selection, but if the transactions selected by etx_seen in B are postponed after their key is public, ordinary transactions in the recovery payload can be chosen with knowledge of the plaintexts and frontrun them (failure case A). I would therefore adapt the recovery logic from LUCID, including capacity for executing all of these transactions together.
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | Mempool Account Transaction Capacity from Historical Activity (MATCHA) | 0 | 9.38 | 22-09-2026 |
| 2 | EIP-8184: LUCID encrypted mempool | 0 | 8.44 | 14-08-2026 |
| 3 | Cryptographic canaries and backups | 0 | 8.77 | 18-09-2026 |
| 4 | ERC-8340: Transaction Metadata Encoding | 0 | 34.21 | 15-07-2026 |
| 5 | Preserving censorship resistance for BAL data in EIP-7999 | 0 | 6.62 | 14-08-2026 |
| 6 | Encrypt The Mempool #7, July 22, 2026 | 0 | 25.23 | 20-07-2026 |
| 7 | Timelock Account recovery: A trust minimized recovery system for Smart Accounts | 0 | 6.22 | 14-07-2026 |
| 8 | ERC-8100: Representable Contract State | 0 | 5 | 08-07-2026 |
| 9 | EIP-8146: Block Access List Sidecars | 0 | 6 | 10-07-2026 |
| 10 | EIP-7906: Transaction Assertions via State Diff Opcode | 0 | 3 | 08-07-2026 |