How to make the runtime API call error out during the execution when the recorded storage proof size exceeds the maximum proof size

[liuchengxu]

In Subspace, we employ an optimistic rollup solution for the execution chain. When a dispute arises, the operator generates a fraud proof, which is then sent to the consensus layer as an unsigned extrinsic. As is commonly understood, extrinsic inherently carries a size limit. Therefore, it's imperative that the size of the fraud proof does not exceed this limit, ensuring it fits within the extrinsic.

The most substantial portion of the fraud proof is the storage proof recorded during the challenged state transition (InitializeBlock/ApplyExtirnsic/FinalizeBlock). Given that the exact size of the storage proof cannot be determined until execution, we need to limit storage access during regular block execution. If the storage proof, required to verify the transition, exceeds the maximum proof size limit, the execution fails.

substrate/primitives/trie/src/recorder.rs

Lines 235 to 238 in 689da49

	struct TrieRecorder<H: Hasher, I> {
	inner: I,
	storage_root: H::Out,
	encoded_size_estimation: Arc<AtomicUsize>,

If I'm not mistaken, we currently have the ability to determine the exact proof size using the existing TrieRecorder.encoded_size_estimation. Our challenge now is figuring out how to trigger an error during runtime API execution when the proof size surpasses its limit. Do you have any insights on the best way to tackle this? Also, we would be more than willing to contribute to Substrate if this feature is considered broadly beneficial.

[ggwpez]

Given that the exact size of the storage proof cannot be determined until execution, we need to limit storage access during regular block execution.

Sure things like on_initialize could over use weight, but that can be prevented by benchmarking them.
For normal extrinsics you can just set the PoV weight of the block to something smaller. Are you using chromatic weights in your runtime?

Our challenge now is figuring out how to trigger an error during runtime API execution when the proof size surpasses its limit.

I dont understand where the proof is verified. Why is it verified in a runtime API and not an extrinsic?
So is the problem in the proof creation or its verification?

[liuchengxu]

• Every operator (L2 validator) executes the transactions using the custom TrieBackendWithRecorder that would fail the transaction in such a case the storage proof to verify this transaction execution is huge, a selected operator will submit the execution result to the consensus chain.
• If a bad operator was selected and submitted an incorrect execution result to the consensus chain, the other honest operator will observe this and submit a fraud proof in an extrinsic to the consensus chain accordingly.
• The consensus chain node will receive the fraud proof extrinsic and verify the proof validity by re-executing the fraudulent transaction and comparing the state root after execution. If the proof is valid, pack the fraud proof extrinsic into the next consensus block, prune the bad execution result and punish the bad operator.

So the execution chain nodes always run the code and error out in case of the huge fraud proof, the consensus chain node runs the code only when the fraud proof is submitted.

[bkchr]

The consensus chain node will receive the fraud proof extrinsic

But what if the bad actor included some transaction for that the honest operator can not build a fraud proof that is small enough to fit into the extrinsic?

[nazar-pc]

But what if the bad actor included some transaction for that the honest operator can not build a fraud proof that is small enough to fit into the extrinsic?

This is exactly the point here: we need to detect this and abort execution. Then fraud proof can include amount of data that is right above configured read limit and anyone would be able to verify that transaction does not terminate before that, while clearly already exceeding allowed limit.

[bkchr]

Okay, that sounds already a little bit different. You would then check that the consensus node has read all the data of the fraud proof, but the transaction would still try to read data that isn't available in the proof?

In general we don't have anything that would error on reading. Probably the best would be to write some Externalities wrapper or something similar. Or a modified TrieBackend. However, it will be complicated to put the stuff in there on upstream. Will require some tinkering.

[liuchengxu]

Yes, but it's actually straightforward for the consensus node as it re-executes the transaction in the same way as the operator does, with the data provided in the fraud proof. Ideally, after reading some storage, the execution should smoothly return an error like OutOfStorage from apply_extrinsic API, indicating the tx failure and producing a new state root.

Will have an experiment on our side and then see whether it's possible to upstream back.