Extrinsic Commitment should be hash of hashes

[gavofyork]

At present the Extrinsic Commitment is a hash of the extrinsic data. This should be changed to either a Merkle root of all the various extrinsic components, or, slightly simpler and more efficient, a hash of the concatenated hashes of the components.

Components at need of this are those larger items which we expect to be pre-distributed to the block:

• guarantees
• preimages

[tomusdrw]

Binary merkle tree, while more complicated, would be much more friendly for light clients / bridges that would need a proof of finality of a particular extrinsic. There is a BEEFY commitment, but AFAICT it's build from the whole blocks now, alternatively BEEFY could just include headers and only the required extrinsic could be provided alongside the proof.

[gavofyork]

that would need a proof of finality of a particular extrinsic.

Not sure what you mean by "finality of a particular extrinsic" here. We're not talking about anything which would make a lot of sense for user-level consideration alone. Finality isn't especially relevant for JAM extrinsic inclusion since a) the finalised inclusion of a guarantee does not strictly imply that the associated work report will ever be accumulated as it could be dropped before becoming available; and b) even if it is known to have been made available (e.g. by checking said guarantee's assurances later), the effect of accumulation is what matters, not the finality of refinement and this cannot generally be known without either inspecting the post-state of the service or checking the accumulation output (via a BEEFY commitment, say). Later changes (ordered accumulation) will only undermine this disconnect further.

BEEFY (or a Grandpa state proof) is how you check some particular transition happened.