Sponsored content

Sandwich attacks cost Ethereum users an estimated $60 million annually. Transactions broadcast to public storage are publicly evident before they are enabled, which gives MEV bots the ability to influence the order of transactions and insert their own for profit. This problem persists at some level despite years of discussion and various attempts to mitigate the effects that are inconsistent with the protocol.

Encrypting transactions within the memory pool would be one of the most compelling solutions to prevent MEV. Although this idea has been actively discussed for years, it has not yet been implemented at the protocol level. In our previous research, we examined several threshold-based encryption proposals, including Shutter, Batched Threshold Encryption, and Flash Freezing Flash Boys. In this article we turn to a meta-proposal titled “Universal Encrypted Storage (EIP-8105)“.

How EIP-8105 approaches memory encryption

Universal encrypted storagealso known as EIP-8105, is a schema-independent encrypted memory design, which means it can support a wide range of encryption methods, including threshold encryption, MPC, TEE, delayed encryption, and fully homomorphic encryption. To facilitate this flexible design, a new system contract in the execution layer, called the key supplier register, is planned. This would allow any account to register as a key provider that stores and discloses decryption keys using its own preferred encryption technology.

How transactions are processed in the Universal Enshrined Encrypted Mempool

Universal Enshrined Encrypted Mempool introduces two new transaction types within the framework EIP-2718 framework: 0x05 for encrypted transactions and 0x06 for decrypted transactions. An encrypted transaction is an envelope containing an encrypted payload and a public payload that contains the disposable envelope, gas quantity, gas price parameters, key supplier ID, key ID and signature. This structure is required to link the transaction to a selected key supplier, assign a lump sum and ensure gas fees are covered for the block space.

EIP-8105 is a two-step process. In the first step, the encrypted transaction envelope is placed in the block, even though the payload itself remains hidden. Key providers monitor transactions with encrypted payloads, collect the appropriate transaction key IDs, and publish the appropriate decryption keys or hold notification after the block builder publishes the data.

Once the block builder publishes the execution payload, the corresponding key provider exposes the decryption key or hold notification. AND Cargo Timeliness Committee (PTC) monitors whether the decryption keys to which encrypted transactions refer are published on time, verifies them, and confirms whether a valid key was present or not. If the key is available and decryption is successful, the resulting decrypted transaction will be executed in the next block. If the key is missing, it will be held or decryption will fail, the decrypted payload will be skipped, the envelope will remain attached, and the transaction fee will still be paid.

EIP also enforces a block structure that prevents MEV extraction transactions from being inserted in the window between decryption and execution. Decrypted transactions must appear at the beginning of the block, plaintext transactions remain in the middle, and encrypted transactions are placed at the end. This order allows encrypted payloads to be revealed and executed only after they are enabled, while preventing secondary MEV.

While EIP-8105 significantly reduces exposure to MEV, upstream vendors in the block retain a limited ability to extract MEV from later transactions by selectively revealing or withholding decryption keys. The proposal attempts to mitigate this phenomenon by allowing key suppliers to designate other trusted suppliers and order transactions according to the resulting key supplier trust graph.

Encrypted Mempools and the Ethereum Roadmap

Encrypted memories are becoming an increasingly important part Ethereum roadmapas the ecosystem looks for ways at the protocol level to limit harmful MEVs. While EIP-8105 is no longer at the forefront of the first hard fork in 2027, it remains an open draft and its ideas continue to inform the broader effort to produce a leading encrypted memory upgrade proposal.