Smart Account Encrypted Mempools
Written by Marc Harvey-Hill @ Nethermind. Special thanks for feedback from Ahmad Bitar, Aikaterini-Panagiota Stouka, Stefano De Angelis, Conor McMenamin, Lin Oshitani, and Julie Bettens. Feedback is not necessarily an endorsement.
This post explores the concept of using smart accounts to validate that encrypted mempool rules are followed. This can strengthen guarantees of frontrunning protection and censorship resistance for cases where block proposers attempt to violate the encrypted mempool rules.
In an encrypted mempool users send encrypted transactions that are posted onchain in a public constraint. This is a constraint on the next proposer to include these transactions in a predefined order (such as ordered by priority fee). Just before the next slot the decryption keys are revealed so that the proposer can decrypt and include the transactions from the public constraint. They should include all of the valid transactions that were in the constraint at the top of their block in a predetermined order, inserting no transactions beforehand that could frontrun the decrypted transactions. We are concerned with enforcing that proposers follow these rules.
Smart accounts can be used to prevent frontrunning by a malicious proposer. Rather than encrypting normal transactions, users can instead encrypt ERC-4337 smart account transactions (UserOps) that carry out a check that they have been included in the correct order at the correct index within the block (i.e. at the top). If the check fails then the main body of the UserOp (e.g. the swap) will not run, so it is impossible for them to be frontrun.
They can also provide protection if the proposer is not malicious, but goes offline. In these cases the decryption keys will still be revealed, so now everyone can see the decrypted transactions. This means that the next proposer could include these decrypted transactions and insert their own frontrunning transactions beforehand. Again smart accounts can provide protection; as part of the checks performed at the start of the UserOp we can verify that the UserOp is being executed in the slot that it was intended for. If the check fails then the body of the UserOp will not run, so the attack is no longer possible.
In order to have their key properties, frontrunning protection and censorship resistance, encrypted mempools should enforce two rules respectively: ordering and inclusion. As stated smart accounts can be used to enforce ordering, meaning that transactions must be executed in the correct slot, in the correct order, at the correct index within the block (top of block). We will also explore how inclusion can be enforced through a fraud proof game, meaning that if the proposer does not include transactions that were in the public constraint they will lose out on rewards, and potentially be slashed.
Smart account encrypted mempools have several benefits:
- Unconditional frontrunning protection: A proposer cannot frontrun transactions under any circumstance. Even if they are offline and the decrypted transactions are leaked, a future proposer cannot include and frontrun them as the main body of the transaction will not execute in future slots.
- Reorg safety: In the event of a reorg it is still not possible to frontrun.
- Incentive alignment: Proposers miss out on all tips if they censor any encrypted mempool transaction.
Background
For background I would recommend this 5 minute talk I gave outlining the design space of encrypted mempools.
To summarise:
- Users encrypt their transactions.
- The encrypted transactions are posted onchain in a public constraint. The proposer for the next slot should include all of these transactions in a predefined order at the top of their block.
- Just before the start of the next slot, the decryption keys are revealed by âkeypersâ.
- If the proposer is online they build their block. Smart accounts and a fraud proof game can be used to enforce that the proposer follows the rules, respecting the public constraint.
This design focuses on point 4: how to enforce that all transactions from the constraint are included in the correct order. We will explore a smart account approach that mitigates the problem of malicious and offline proposers by enforcing ordering and inclusion rules.
There are other important aspects of the design such as the encryption mechanism, the nature of the keypers, where exactly the public constraint is posted; I will not cover these in this post.
Encrypted Mempool Taxonomy
We can classify encrypted mempool designs by how strongly they enforce the ordering and inclusion rules on proposers.
Stage 0 - Trusted
- Fully trusted proposer.
- Ordering and inclusion not enforced, so able to frontrun and censor without consequence.
Stage 1 - Staking
- Proposer has stake that can be slashed. They could issue proposer commitments.
- If proposer reorders or censors their stake can be slashed. Requires posting proof of proposer breaking rules.
- Ordering only enforced retroactively so still possible to frontrun. Could happen if payoff exceeds stake.
- Instead of slashing, the stake could be used to compensate users.
- Problem: must slash offline proposer who allows decrypted transactions to be leaked, even if they didnât receive the keys in time.
- Stage 1 mempools are explored in this whitepaper. It uses slashing and proposer commitments.
Stage 2 - Smart Account
- Ordering enforced by smart account.
- Proposer proves correct ordering onchain before executing.
- Impossible to frontrun, UserOp body will not execute if the ordering is incorrect.
- Proposer loses all encrypted mempool rewards if inclusion is not satisfied. Could also be slashed as in stage 1.
Stage 3 - Enshrined
- Enforced by block validity conditions.
- Proposer cannot build a valid block if ordering and inclusion are not satisfied; this means they would miss out on block rewards.
- Would have to be enshrined in-protocol through a hard fork.
- Will take longer to coordinate on a design suitable for enshrinement.
Stage 2 has the benefit over stage 1 of unconditional frontrunning protection. With stage 1 frontrunning is still possible as it is only punished after the fact; it could happen if the value gained exceeds the losses from slashing. It could also happen in the case that a proposer simply goes offline and the decrypted transactions from their slot are leaked. With stage 1 the proposer may be slashed for this (which could be unfair if they did not receive the decryption keys in time), whereas with stage 2 this is not a problem as the leaked transactions could not be executed outside of their intended slot.
Ultimately stage 3 will provide the strongest security guarantees in the long term, but realistically it will take a long time to reach consensus on a design suitable to be enshrined in-protocol. For the short to medium term stage 2 should give sufficient protection.
The various enforcement mechanisms of different stages of encrypted mempools are summarised in the following table:
| Stage | Ordering | Inclusion |
|---|---|---|
| 0 | None | None |
| 1 | Slashing | Slashing |
| 2 | Smart account | Slashing |
| 3 | Consensus | Consensus |
Note that the stage of an encrypted mempool is not the only factor in how secure it is, this also depends on other aspects such as the keyper mechanism.
Design
I will present a design that enforces ordering and inclusion rules on proposers using smart accounts and a fraud proof game. We will start with a high level overview of how this works before exploring the details:
- Users create and encrypt UserOps. These UserOps specify in which slot they should be executed (i.e. the next slot).
- Encrypted UserOps are included onchain in a public constraint.
- At the start of the next slot the decryption keys are broadcasted and the proposer decrypts the UserOps for their slot. They begin building their block (they may use MEV-boost, this is discussed in the PBS section).
- The proposer creates an âordering declarationâ. This declaration is the proposer claiming which transactions were in the public constraint and how they should be ordered according to the rules of the mempool. They can also claim that certain decrypted UserOps were invalid and not include them.
- The proposer bundles together all of the (valid) decrypted UserOps together into a single ERC-4337 transaction. The ordering declaration should be passed into this transaction as calldata.
- The proposer should include this bundled transaction at the top of their block.
- The validation checks are carried out onchain as part of this bundled transaction. The ordering declaration can be verified to satisfy the public constraint, and then each UserOp can then be verified to follow the ordering declaration.
- If the checks pass the UserOp bodies will be executed, otherwise they stop after the check is performed and the main body will not be executed.
- The proposer could have falsely claimed that certain valid transactions were invalid; this is where the fraud proof game is used. The transaction tips are locked up for some challenge period in which anyone can provide proof that the proposer lied about a certain transaction being invalid. The proposer would then be unable to collect their rewards and could be slashed.
The flow is illustrated in this figure:
We will now step through an example to see this design working in practice, before exploring the different parts of the process in more detail.
Example
Three users have UserOps that they want to execute through the encrypted mempool. These UserOps have the hashes 0xa, 0xb, 0xc. The users encrypt their UserOps and send them to the encrypted mempool.
The encrypted UserOps are included in a public constraint posted onchain in blobs or calldata. Alongside the ciphertext the hashes of the underlying UserOps are revealed, as well as a proof that these hashes are of the plaintext UserOps.
Before the start of the next slot the keypers reveal the decryption keys for the UserOps; the proposer must now construct an ordering declaration.
In this example the encrypted mempool does ordering by priority fee. The proposer provides a proof of the priority fee for each UserOp and orders them accordingly. The proposer also declares that the UserOp with hash 0xa was invalid against the prestate. The proposer must now construct their block.
The proposer has bundled the valid UserOps into a single transaction which they included at the top of the block. Within this transaction the ordering declaration is first verified. Next the valid UserOps 0xb and 0xc are executed in the correct order. For each of these the validation checks are first carried out before the main body is executed.
Since the proposer declared that UserOp with hash 0xa was invalid they did not include it. However, now anyone can submit a proof that 0xa was actually valid and claim the proposer tips for this slot.
Ordering Declaration
Once the UserOps are decrypted, the proposer must first post an âordering declarationâ in calldata. This is a list of UserOp hashes that the proposer is declaring to be the correct ordering. Once this list has been proven to be correct against the public constraint, it can then be used by each UserOp to check that it has been included in the correct order.
The ordering declaration should:
(1) Respect the ordering rules of the mempool eg. ordering by priority fee or FCFS.
(2) Not contain any UserOps that were not present in the original constraint.
(3) Declare which UserOps from the constraint were invalid against the prestate.
We can verify (2) immediately by comparing the declaration to the public constraint which was posted in blobs or calldata; the proposer can prove the contents of the constraint against the blob KZG commitment. The public constraint should expose the hashes of the UserOps (users can prove the hash when they submit); these hashes can then be compared to the ordering declaration to ensure there are no hashes present that were not included in the original constraint.
We can also verify (1) immediately by comparing the ordering declaration to the hash list from the public constraint. In the case of FCFS the lists should be identical. With priority fee ordering the proposer must provide an additional proof of the priority fee for each UserOp.
The declaration (3) allows the proposer to claim that some UserOps were not valid so do not need to be included. It would be very expensive to prove this upfront so it can instead be verified afterwards in a fraud proof game. We will expand further on this in the inclusion section.
Once (1) and (2) have been proven onchain the ordering declaration can now be used in the UserOp ordering checks.
Ordering
Before the body of a UserOp is executed, checks must be carried out to verify that:
- The UserOp is being executed in the correct place, matching the ordering declaration.
- The current slot matches the one included in the UserOp. This can be checked with the SLOT precompile.
- The bundled transaction is executed at the top of block. This can be checked with the TXINDEX precompile.
- No previous UserOp failed the validation check.
Only once these things have been verified will the main body of the UserOp be executed. If any checks fail then the UserOp body, and those of subsequent UserOps, cannot be executed; the proposer will be unable to claim any rewards and they may be slashed.
Inclusion
A fraud proof game is used to verify that the proposer did not censor any transactions from the public constraint that were valid. Proposer tips are accumulated in a smart contract and held for some challenge period. During this period anyone can submit a zk proof that a UserOp that the proposer declared to be invalid was indeed valid against the prestate, and there was enough gas left to include it. Anyone who submits this proof can claim the proposer tips from that slot, and the proposer could also be slashed. Some percentage of the rewards could be burned to disincentive the proposer from submitting the fraud proof themselves (if there is no slashing). If no challenge is submitted within the challenge period then the proposer is able to claim all of the tips.
An alternative design could enforce that the proposer provides proof of invalid transactions upfront. Since generating these proofs would be expensive this could lead to griefing attacks against the proposer, so I propose the fraud proof game instead.
Considerations
Dependencies
This proposal depends on EIP-7793, the TXINDEX precompile; no other consensus level changes are required. It is necessary to have the transaction index in order to check that the bundled transaction is executed at the top of block.
EIP-7843, the SLOT precompile, is a soft dependency. With this precompile we can verify that the current slot matches the one specified in the UserOp. It is not a strict dependency as the UserOp could instead contain a timestamp which is checked against the TIMESTAMP opcode. This approach works but is less future-proof as it would need to be updated in the event of a change to the slot length.
ERC-6900 modular smart accounts may be preferable to standard ERC-4337 accounts. These support the implementation of pre-execution hooks that can be used to run the checks before the main UserOp body is executed.
Reorg Safety
For reorg safety, the decrypted UserOps must be executed in the slot directly after the one in which the public constraint is posted. To understand this, consider what could happen if we post a constraint onchain in slot x, and include the decrypted UserOps in slot x+2. An attacker could wait until the UserOps are decrypted in slot x+2, and then reorg the chain to include a block at slot x+1 containing frontrunning transactions.
This requirement could be removed once single slot finality is implemented.
Leaking Intentions
Imagine a user is making a large swap from token X to Y through the encrypted mempool. The proposer for the slot is offline so the decrypted UserOp is revealed to everyone. As discussed the swap cannot be included in a future slot where it can be frontrun, as the body of the UserOp will not execute in future slots. However, the users intention to make the swap has been leaked, so someone else could buy up token Y in anticipation of the user resubmitting their swap, effectively frontrunning the user.
It is not clear that this attack could reliably be carried out. It could be the case that the transaction was leaked intentionally in an attempt to manipulate the market and increase the price of token Y, for example.
In some cases this could be a bigger problem, for example if the encrypted mempool was used to submit a transaction to register an ENS name. Although the transaction could not technically be frontrun, leaking the intention to register the name may not be an acceptable risk.
Hashes or Commitments
For simplicity, I suggested that the public constraint should reveal the hashes of the plaintext UserOps so that they can be compared onchain with the ordering declaration. This approach would undermine the security of the encryption mechanism, since the hash is deterministic this would make the encryption scheme insecure against a chosen plaintext attack.
Instead of a hash, we could use a commitment that will not leak information about the plaintext. It may be possible to use techniques from Lee et al., 2019 and Campanelli et al., 2019 that combine encryption schemes with commitments.
EOA Support
With EIP-7702 the same functionality can be brought to EOAs by deploying ERC-6900 code to their address.
Proposer Builder Separation
So far we have assumed that the proposer will be building the block locally, but the design can still work with MEV-boost or ePBS. The proposer can construct the bundled transaction as usual and request that the builder includes at the top of the block through the constraints API.
Conclusion
I have outlined a design for a maximally trustless enforcement mechanism for encrypted mempools that requires minimal consensus-level changes. This provides strong guarantees against frontrunning and censorship. Future posts will explore in more detail other parts of the design such as the public constraint.