fault_proving(compression): include commitment to transaction ids within compressed block header

[rymnc]

Linked Issues/PRs

closes #2569 and closes #2574

Description

instead of the merkle root of transaction ids, we directly commit to a hash of all tx ids ordered as they are in the block.

Checklist

• Breaking changes are clearly marked as such in the PR description and changelog
• New behavior is reflected in tests
• The specification matches the implemented behavior (link update PR if changes are needed)

Before requesting review

• I have reviewed the code myself
• I have created follow-up issues caused by this PR and linked them here

After merging, notify other teams

[Add or remove entries as needed]

• Rust SDK
• Sway compiler
• Platform documentation (for out-of-organization contributors, the person merging the PR will do this)
• Someone else?

[netrome]

Looks alright to me. Would be nice to have test coverage of this computation.

The base branch was changed.

[acerone85]

no comment from my side, looks in good shape

[xgreenx]

I don't see how it is useful for us to store hash of all transaction ids in the CompressedHeader. I see how it can be used while it is in the regular header(because we can prove that it is part of the block id, and block id is our main connection point with the block). While in the case of the compressed header, we only can prove that compressed header contains the hash of the some decompressed transactions, these transactions are not connected to the block.

[rymnc]

I don't see how it is useful for us to store hash of all transaction ids in the CompressedHeader. I see how it can be used while it is in the regular header(because we can prove that it is part of the block id, and block id is our main connection point with the block). While in the case of the compressed header, we only can prove that compressed header contains the hash of the some decompressed transactions, these transactions are not connected to the block.

when the user performs decompression, they end up with a PartialFuelBlock which has a list of transactions. they can then validate the generated PartialFuelBlock's Transactions with the tx_id_commitment in the compressed block header (which is what the validate_with() function does. we also have commitment to the block_id within the compressed header if you are looking for a connection point?