Introduction
Ethereum lacks a trustless mechanism to shield transactions (txs) from MEV extraction. The current recourse—private orderflow—gives trusted actors excessive control over the tx supply network, degrading decentralization and censorship resistance of MEV inducing txs. To alleviate this, the shutterized beacon chain proposal uses an encrypted mempool, with encryption keys provided by a set of “keypers”. The encrypted txs are included in a block, and the keypers then use threshold cryptography to decrypt the txs in time for their final execution in a subsequent block. A potential concern is the protocol’s reliance on keypers to honestly and consistently perform their duties.
Recent proposals also based on threshold cryptography include a roadmap for leveraging proposer commitments and an alternative approach using smart-account encrypted mempools. A simple cryptographic strategy, relying on participants themselves for encrypting and decrypting their data, was recently proposed in the form of a sealed execution auction. Builders make sealed bids for the right to propose an execution block. The sealed bids are collated and builders then reveal their bids, as observed by attesters. The next proposer collates the revealed bids in the block, and attesters provide attestations contingent on correct collation.
This post explores sealed transactions, relying on the primitive developed in the sealed execution auction to achieve an encrypted mempool. It introduces a new tx inclusion path that users can rely on to trustlessly protect their txs against MEV extraction. Users broadcast sealed txs which are commitments consisting of a cryptographic hash computed from the raw tx and a top-of-block fee f_\text{ToB}. These are included in a commitment struct in the first block. Users then unseal their raw txs, as observed by attesters, and the txs are included top-of-block in the next block, ordered by f_\text{ToB}. Attesters attest to the block contingent on correct collation. The mechanism is thus “fork-choice enforced”, a strategy familiar from FOCIL, MEV smoothing, MEV burn, and the sealed execution auction.
Mechanism
Figure 1 outlines the sealed transactions mechanism.
- Before T_1 – Users post sealed txs to the mempool. Sealed txs can be formatted similar to regular txs, but lack
toandvaluefields. They further contain a cryptographic hash. This hash is computed from the raw tx that will eventually be “unsealed” and executed, alongside the f_\text{ToB}. A special form ofgasLimitfor the tx to be unsealed is also provided, which is charged in full beforehand, directly when the sealed tx is committed. It must cover for the gas consumed by the unsealed tx and will hereinafter be denoted as thegasObligation. The transactor might wish to specify a highergasObligationthan necessary, to further obfuscate the content of the tx. - T_1 – Sealed txs are included in a specific commitment struct in
Block A. Gas for inclusion in the struct (e.g., covering for storing the sealed tx) as well as thegasObligationare charged from the transactor and burned. The priority fee befalls the proposer ofBlock A. To ensure that the transactor eventually is able to pay the penalty if it fails to unseal its tx, the penalty is reserved by the protocol, for example by charging and burning it, to then be returned upon correct inclusion. The commitment struct has space for txs up to some proportion g_p of the gas limit g_l. Thus, the totalgasObligationacross all entries in the commitment struct must be below the threshold g_t=g_p \times g_l. - T_2 – Once a user has observed its sealed tx in a commitment struct and is sure that
Block Bis the next block to be proposed, it broadcasts its unsealed tx to the mempool, thus also revealing the f_\text{ToB}. Nodes might at this point only propagate unsealed txs if the cryptographic hash contained in the sealed tx matches the hash computed from the unsealed tx, but this depends on compute requirements. Users indicateBlock Aas the correct anchor for the unsealed tx (for example by block hash) to ensure that the unsealed tx is invalid ifBlock Ais reorged. They can include a priority fee with the unsealed tx. - T_3 – Attesters observe the timeliness of unsealed txs at T_3, e.g., 3s before the new slot begins. They verify that the cryptographic hash in the sealed commitment matches the hash computed from the unsealed tx and that the raw tx otherwise also fits requirements. If a tx is not properly unsealed at this point, they record that it can be penalized. This will ultimately depend on if the proposer includes the unsealed tx in
Block Bor not. - T_4 – The proposer of
Block Borders proper unsealed txs top-of-block sorted according to f_\text{ToB} and the f_\text{ToB} is burned. The priority fee(s) can be used as a tiebreaker for ordering, and, in either case, the tx hash can be used as a final tiebreaker. The reserved amount for the penalty is returned for properly unsealed txs. For accounting purposes, the proposer may indicate missing unsealed txs with a reference to the corresponding sealed tx, although this is otherwise implied fromBlock A. IfBlock Bfails to extend the blockchain, the unsealed txs are instead scheduled for the next block. - T_5 – Attesters attest contingent on correct collation.
Figure 1. The sealed transactions mechanism. Sealed txs with associated gas fees are broadcast and collated in Block A. They are then unsealed by the transactors themselves, as observed by attesters, and included top-of-block in Block B, ordered by f_\text{ToB}. Attesters finally attest contingent on correct collation.
Discussion
User sophistication and UX
One concern is the increased sophistication required from transactors that wish to utilize the trustless mechanism. Users who do not run a node must rely on their wallet to fetch data from providers such as Infura or Alchemy. The wallet could for example issue a JSON-RPC API call similar to eth_getTransactionReceipt for their sealed txs, in this case instead requesting data from the commitment struct (clients must implement this extension). Upon call receipt and assurance that Block B is the next block to be proposed, the wallet will release the unsealed tx. This whole procedure will be automated from the user’s perspective, but increased complexity is still something to keep in mind.
Users also take on the risk of being penalized if their unsealed tx does not reach the attesters on time—and—the proposer does not see it, or elects to not include it upon realizing that attesters have not observed it in time. Given that proposers may act as a safety net to include late unsealed txs, a priority fee should presumably also be implemented for unsealed txs (in extension to f_\text{ToB}). There is no other reason for priority fees, given that proposers are forced to include unsealed txs via the fork choice rule. Users must further hold sufficient balance so that the penalty can be reserved.
Liveness
Constraints to the fork choice must always be scrutinized, to ensure that it does not get overloaded in such a way that liveness is degraded. The rationale for directly relying on fork-choice enforcement in sealed transactions is that all relevant txs are known—if they are scheduled for inclusion they must have been included in a prior block. There is thus a finite number of txs for attesters to observe, and they will have a list of these txs ready beforehand. Yet, this list ought to perhaps not be too extensive, which is ultimately determined by g_t. The potential for liveness degradation, together with degraded UX, are probably the biggest drawbacks of the proposed mechanism and merit further scrutiny.
One question is whether includers otherwise can be leveraged, as a middle-man between transactors and the proposer. Any unsealed txs included in the \text{IL}_\text{agg} will of course need to be included in the block. However, if the mechanism strictly relies on ILs for enforcement, the transactors must trust includers to properly include their unsealed tx. This would seem like a fairly severe downgrade to what is otherwise a trustless mechanism for preventing MEV extraction. Of course, it would be possible to have includers instead/also list sealed txs before T_1, to prevent their censorship. However, txs with unknown content are less likely to be censored in the first place.
Inclusion delay
Should there be a delay between Block A and Block B, or should these blocks be consecutive? Furthermore, should transactors independently be able to set such a delay? One reason for a delay is that it gives greater certainty to the transactor that Block A will not get reorged. A reorg could occur under the current Gasper consensus mechanism. Under SSF, reducing the delay to 0 seems appropriate. The damage from a block reorg is however moderate. The unsealed tx would still not be executable if Block A is reorged, because the tx will specify that Block A is the only block to which it anchors. A shorter delay is naturally generally better simply because it enables a tx to be settled faster.
Giving the transactor the ability to independently set the delay could be beneficial. But one cause for concern then is the additional complexity in keeping txs from overflowing some specific future block. The gas threshold g_t must in this case have a forward property and apply to blocks in the future. The proposer would be responsible for tracking txs committed to a future block and ensuring that they do not exceed g_t. There would at the same time still need to be some threshold also for the commitment struct and a limit to how many slots in the future a tx can specify. In some scenarios, users will be eager to have their tx included in a specific slot in the future. Allowing the user to specify a specific future slot for the unsealed tx, as opposed to only a generic delay from getting the sealed tx included, would make this possible. Such an option would prevent a sealed tx from getting included in the “wrong” slot when the user must rely on a delay while trying to target a specific future slot.
Magnitude of penalty for failure to unseal a tx
What should the penalty be for a failure to unseal a tx? This depends on how much MEV that can be extracted—in expectation—by posting sealed txs with the intent of only unsealing them if it is profitable to do so. It is not a straightforward MEV extraction technique—the extractor must guess the potential tx content and will lack knowledge of f_\text{ToB} and thus the ordering of txs available for extraction. With some appropriate estimate of the expected value of this MEV extraction technique, the penalty can be designed, accounting for the already existing cost of sealed txs (remember, the user must always pay the full gas amount already at Block A). The penalty should presumably be fixed, perhaps adding a component that varies with the basefee as well. It is of course possible that a penalty of zero turns out to be appropriate. Finally note that the sealed txs can still be backrun when building the rest of the block, though this is not particularly harmful.
Mechanics during missed slots
If the slot is missed, the queued txs are instead included in the next block. The unsealed txs will thus never be skipped over just because Block B fails to extend the blockchain; they must be included in the correct order in the first successful block. If there is a delay between Block A and Block B, there might be several queued batches up to g_t of gas of unsealed txs ready for inclusion, once there are missed blocks. For example, if there is a delay of two additional slots between the blocks and a block is missed, then the next block would need to include two batches of unsealed txs. Two solutions are possible:
- If the delay is moderate and g_t also moderate, all txs can be mandated to be included in the first posted block after the missed proposals.
- Another option is to delay by blocks from
Block AtoBlock B, not slots. Thus, if a block is missed, the entire queue is shifted one slot. It should however be noted that this can disrupt the user’s timing for unsealing the tx when a block gets reorged, thus complicating the approach.
Does the sealed transactions mechanism provide an additional reason to pursue missed proposal penalties? Since tx ordering is not disrupted by a failed proposal, it might not be critical but is still one of many reasons to increase incentives for proposers to avoid missed slots.
just one question