Stateless validation of WASM execution

[jakmeier]

Q: What would it take for WASM smart contract execution outcomes to be verifiable without prior state?

In today's architecture, we fetch the following state from the DB, which can't be derived from the latest block and chunk alone:

1. account meta data (balance, locked balance, storage usage, code hash)
2. pre-compiled contract executable
3. input data receipts
4. any values accessed through the TrieAPI

A naive stateless implementation would therefore add the following information to the execution outcome witness of a function call::

• The Account struct value stored in the TrieKey::Account row.
• The raw WASM stored in the TrieKey::ContractCode row.
• A (possibly empty) list of data receipts stored in the TrieKey::ReceivedData row.
• A (possibly empty) list of key-value pairs stored in the TrieKey::State row.

As you can see, all the necessary data is already in the merkle-patritia trie, so we can include merkle proof for all these inputs.

Stateless validation would then work as follows:

1. Validate all input proofs
2. Validate & compile WASM code (the same work which a chunk producer does in the Deploy action)
3. Perform a normal execution like today

Problem 1: Witness Size

With the naive solution, we have to include many key-value pairs alongside their proofs. The contract code is likely to be hundreds of kB, potentially up to 4MB. Contract's key-value pairs are also only limited to 4MB.

To address the size, we are looking into better suited state representations and adding stricter size limits where appropriate.

Ongoing research:

• average witness size analysis: seems managable, see Zulip message
• Worst-case witness size for stateless validation #9378
• Verkle Tree over MPT (TOOD: existing issue?)

Problem 2: Execution Delay

The deploy-ahead-of-time optimization that makes function calls so cheap is no longer viable. We would have to compile functions every time we execute them.

More details in

• WASM execution without prior deployment #9379