The invalid XDM fraud proof is unsound and maybe unnecessary

[NingLin-P]

Currently, the invalid XDM fraud proof is verified by calling into the is_valid_xdm domain runtime API with the genesis state of the domain:

subspace/crates/sp-domains-fraud-proof/src/host_functions.rs

Lines 340 to 351 in 3494834

	let domain_initial_state = consensus_api
	.domain_instance_data(consensus_block_hash.into(), domain_id)
	.expect("Runtime Api must not fail. This is unrecoverable error")?
	.0
	.raw_genesis
	.into_storage();
	domain_stateless_runtime.set_storage(domain_initial_state);
	let encoded_extrinsic = opaque_extrinsic.encode();
	domain_stateless_runtime
	.is_valid_xdm(encoded_extrinsic)
	.expect("Runtime api must not fail. This is an unrecoverable error")

while the actual xdm verification is not stateless and involves runtime state like current channel nonce that is not included in the genesis state. So in the invalid XDM FP verification the is_valid_xdm will always return false, if there is a valid XDM the attacker can submit FP to claim the XDM is invalid and the honest bundle author will be slash, this scenario is not covered in the test unfortunately.

Looking closer, the invalid XDM is actually covered by the illegal tx FP, which is essentially proving the pre_dispath result of an extrinsic and the pre_dispath of the XDM included the XDM verification, moreover unlike the current invalid XDM FP, the illegal tx FP is using an execution proof which includes all the required state during pre_dispath, so the invalid XDM can be proved by the illegal tx FP and the current invalid XDM FP is unnecessary.

cc @vedhavyas @dariolina

[dariolina]

If it can be covered within illegal tx proof, I'm all pro removing an XDM fraud proof type

[vedhavyas]

Agree. This is mostly a remnent from our previous XDM validation.
I have no concern removing this and use the illegal tx FP itself 👍🏼