Sealed transactions

[aelowsson]

Thanks for your feedback @and882 (and once again thanks to @Marchhill).

Generalizing Sealed transactions

@Marchhill

This is why I think delay encryption could be the endgame solution when the cryptography is ready.

@and882

…letting the wallet reveal the sealed transaction probably adds quite some complexity for wallets.
…what happens if the user device loses internet connection or crashes?

For delay encryption, I think the main problem is to set the difficulty parameter correctly, so that the transaction gets revealed just in time.

I do believe there are benefits and drawbacks of all decryption schemes. However, to better understand the contributions of this proposal, it can be interesting to first take a step back and look at the similarities that exist between Sealed transactions and the Shutterized beacon chain:

1. Some form of sealed tx is broadcasted acting as a commitment
2. …and included in a block.
3. Within a defined time period, an unsealed tx is broadcasted
4. …and subsequently included top-of-block.

Sealed transactions however differ in that:

• the protocol does not provide the means for decryption,
• the protocol does provide enshrined oversight of the release of the unsealed tx, relieving the proposer of its duties if this tx is not provided. This is ensured by the fork-choice enforcement mechanism.

This distinction is particularly useful in the context of generalizing encrypted mempools. Given some standardized format for the commit–reveal scheme, there would be nothing stopping a transactor from independently using threshold decryption for unsealing the tx in (3). They could for example engage a restaking service such as EigenLayer to this end. Some users may prioritize broad staker coverage for Sybil resistance, others may prefer a diverse set of identifiable parties, and some will ultimately favor a fully trustless solution. Delay encryption could also be leveraged in various setups—it is hard to predict beforehand which among these that will be the most favorable. The consensus layer does not need to have an opinion on this matter and does not need to enshrine one specific decryption scheme. It can merely provide a framework that can be used by any scheme, including the proposed trustless variant.

Re-reading your recent roadmap post, it seems you are indeed looking to a future where the encryption mechanism can be generalized.

@and882

We also consider a more generalized approach that abstracts away the specific encryption mechanism. That is, the exact technology—whether threshold encryption, delay encryption, TEEs, or any other method—is not the focus as long as the chosen mechanism reliably outputs the decryption key in time to decrypt transactions. Essentially, we treat the encryption mechanism as a black box that accepts an input and produces the necessary decryption keys, allowing flexibility in implementation while maintaining the desired functionality.

Importantly, fork-choice enforcement as in Sealed transaction does away with the requirement:

@and882

as long as the chosen mechanism reliably outputs the decryption key in time to decrypt transactions.

With in-protocol oversight of unsealed txs, the protocol can afford to be more permissive, allowing users to manage decryption themselves. My reading of the shutterized beacon chain is that there is no such oversight, but happy to be corrected.

In conclusion, in-protocol oversight of the decryption step seems like an important component of a fully generalized encrypted mempool, and the Sealed transactions mechanism can be leveraged to this end.

Answers to other questions

@Marchhill

My point here is that you need to include something which ties it to a specific block at the point you create the hashed commitment to prevent it being copied and used elsewhere. Since the block hash is not available when the commitment is created that is why I suggest using the slot number.

Given that the protocol does not permit a tx to be included several times, the sealed tx cannot be used after having being included. If the user needs to know beforehand in which slot the sealed tx will be included, UX is degraded or protocol complexity increases.

@Marchhill

If we’ve seen Block A and are waiting for the next block, there is no way to know what will be proposed in the next slot unless you are the builder / proposer (even they don’t know until all txs are unsealed) - there may be no block at all. Do you mean that we know that Block B will contain certain unsealed transactions?

Assuming no delay, the protocol will insist that any unsealed txs go into the next block, if the previous block contained the sealed tx. This is the point of the fork-choice enforcement illustrated in Figure 1 in the post, where attesters make observations at T_3 and enforce these observations at T_5.