[DESIGN] Proving Execution Preconf

[SmoothBot]

Challenge

To support execution preconfs proposers will need to validate any execution preconf constraint has been met by the builder.

Context & Background

Currently there's no consensus on how best to generate an execution proof. It's an open problem.

More background here:

• https://dear-twist-ac1.notion.site/Execution-Proofs-are-much-harder-15e3b4619cb080f18cb2d6176ab3bf7c

Requirements

• Design decision on how execution preconf proofs can be supported
• Any required API spec updates complete

[SmoothBot]

Some more context from @JasonVranek
https://www.notion.so/The-current-API-only-support-inclusion-proofs-15e3b4619cb0809bad57fd3aaac8740e

[LampardNguyen234]

What if we relax the execution preconf constraint to just ensure that preconfed transactions will not revert? For example, a Uniswap swap has a minimumAcceptedAmount that the user wishes to receive, as long as the transaction doesn't revert (Receipt has Status=1), then it is acceptable from the sender perspective.

With that assumption, it is sufficient that an execution proof consists of the following information:

• Transaction index.
• Merkle path for the transaction.
• Transaction receipt of the transaction.

Note that the first two fields are already available in an inclusion proof.

What do you think @SmoothBot @JasonVranek?

[JasonVranek]

I've been a fan of these and think of it more like "preconfs as intents", i.e., by signing the preconf, the preconfer commits to "solving" the user's intent. This way you can transform some things into inclusion preconfs. I would argue though that while I see high utility in these and think people should build them (the pragmatic solution), they aren't technically "execution preconfs" which is synonymous with a "state proof" (the ideal solution). I think it's still worth thinking about how to support execution preconfs, even if the solution is a far off, e.g., verifying a ZKP.

[LampardNguyen234]

This way you can transform some things into inclusion preconfs.

Any execution preconf already implies an inclusion preconf, right?

they aren't technically "execution preconfs"

I think yes and no. The relaxed version is not necessarily the ultimate goal but it can cover most of the scenarios that a preconf is required. Plus, it gives an efficient proof construction (in the case of trusted relays), and an efficient dispute resolution (in case we have fraud challenge) without TEE or ZK proofs.

I think it's still worth thinking about how to support execution preconfs, even if the solution is a far off, e.g., verifying a ZKP.

I agree with you on this. This is still the ultimate goal.

[LampardNguyen234]

they aren't technically "execution preconfs" which is synonymous with a "state proof" (the ideal solution).

One downside of state proofs (if I understand correctly) is that one needs to perform an intermediate stateRoot calculation for every state preconfed transactions. This is unwanted due to performance degradation and was disabled in Ethereum implementation.

[LampardNguyen234]

Hi @JasonVranek and @SmoothBot,

I made a small note on this relaxed execution preconfs.

Keen to hear your thoughts.

[odyslam]

For execution preconfs, it seems to me that the only efficient way are through TEEs, which seems like an acceptable solution given threat model of this, that is if we want to treat them as validity proofs. Else, ZkVMs could be used as fraud proofs, meaning that block builders have some stake and then anyone can prove after the fact that a transaction didn't honor the preconf and slash the related block builder.

This is something that we are exploring at Phylax Systems and happy to chat about with anyone working on this. More specifically, I am looking at using exclusion preconfs as primitives to enforce security guarantees at the block building level (aka prevent hacks). Some context can be fond here

[JasonVranek]

Some references that might be helpful (note we've been moving towards "state lock" instead of "exclusion" preconfs as the naming convention:

• a reference Slasher contract implementation that interfaces with the URC
• ethresearch post regarding state locks

[odyslam]

This is great context @JasonVranek and fits nicely into our approach, will prep a research post and share it with some sketches. Will reply into the forum post with a few thoughts so that I don't derail the issue here.