I recently wrote the post you referenced on smart account encrypted mempools and have some thoughts on how the two approaches compare. Generally I see smart accounts as another way of achieving sealed transactions.
Recent proposals also based on threshold cryptography include a roadmap for leveraging proposer commitments and an alternative approach using smart-account encrypted mempools
These proposals are not based on threshold cryptography, they address something separate. We need to separate the commit-reveal mechanism (eg. threshold cryptography), from how rules for including unsealed transactions are enforced (eg. smart accounts, proposer commitments). The proposals are concerned with the latter, and are independent of the commit-reveal scheme used.
I would characterise this design for sealed transactions as using an enshrined fork-choice approach for enforcing rules, and a manual commit-reveal scheme where users have to reveal their unsealed txs at some time.
Enshrined
- In my post I categorised encrypted mempools by how they their enforce rules. This approach is most similar to a stage 3 enshrined mempool.
- Enshrinement is a good option in the long term, but will require large coordination to pull of complex changes to the protocol such as including new attestation committees for sealed transactions. This would need to be implemented through a hard fork; it could take a long time to reach consensus on a design ready to be included.
- Enshrinement also locks us in to one design, encryption scheme etc. Out-of-protocol solutions can benefit from more experimentation and improvements, such as in cryptography.
Fork-Choice enforced
- An important difference from how I categorised stage 3 mempools is that instead of enforcing through the block validity conditions, this approach uses fork choice. This means that it does not provide unconditional frontrunning protection, as attesters may fail to reorg a block which frontruns unsealed transactions.
- An interesting approach is to augment smart account enforcement with fork choice. This provides guarantees of unconditional frontrunning protection. It improves the UX of the smart account approach in the case that a proposer does not include unsealed transactions and includes other (potentially frontrunning) transactions. Normally users would have to resubmit their transactions as they would no longer execute, but instead attesters could attempt to reorg the block and the unsealed transactions could be included in the next one.
Manual commit-reveal
- The design requires users to reveal their unsealed transactions instead of using a threshold encryption approach like Shutter that aims to avoid this by effectively automating the reveal process.
- Having to manually reveal unsealed transactions would add significant added complexity for wallets.
- It allows attacks where the user does not reveal their unsealed transactions, which could be profitable even if they are slashed.
- Requires significant added complexity of new attester committee, and potentially timing difficulties to reveal unsealed transactions in time for the proposer to include them.
- If you want to avoid the honest majority assumption of threshold encryption, using delay encryption seems like a more promising approach to me.
Misc
Users indicate Block A as the correct anchor for the unsealed tx (for example by block hash) to ensure that the unsealed tx is invalid if Block A is reorged
It is unclear to me how the unsealed transaction is invalid here, this is where I think smart accounts are useful. Maybe you are suggesting to enshrine this into the validity conditions for all transactions which could add significant overhead. Also when users post their transactions they would not know the hash of block A which has not been proposed yet, so I suggested including the slot number which would achieve the same goal of tying the transaction to block A.
Once a user has observed its sealed tx in a commitment struct and is sure that Block B is the next block to be proposed
How could a user be sure of the next block?
Transactors must trust includers to properly include their unsealed tx
With FOCIL, inclusion list builders have no control over where transactions will be included in the final block, this is determined by the builder.
the
gasObligation[is] charged from the transactor and burned
Burning ETH to reserve space is the same approach currently used by Shutter. One disadvantage here is that it imposes significant gas overhead as the user must pay double the gas costs, to first burn, and then execute their unsealed transaction.
A promising approach using smart accounts could be to send ETH to a paymaster to reserve space, and having the paymaster then cover the gas costs of your unsealed UserOp. In this way the user only pays for gas once. You could send extra to the paymaster to cover future transactions and amortise the gas costs of transferring.
Users broadcast sealed txs which are commitments consisting of a cryptographic hash
Using hashes could leak information, using another type of commitment could be better.
top-of-block fee
Minor point - is it necessary to introduce a new fee here? Proposers could instead order by priority fee.