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?

[xgreenx]

The tx_commitment is not related to the block or block id. You can prove that you can decompress transactions using data from the compressed header, but it doesn't prove decompression for the regular block.

Anyone can submit a valid compressed header with valid transactions, and you can verify that you can decompress transactions, but these transactions will not be from the block, they can be any random transactions.

If tx_commitment was a part of the regular block, then you could prove that decompressed transactions are unrelated to the block within the decompression game.

By having tx_commitment only in a compressed header, we require our block-proving game to take a compressed header as an input along with a regular header, mixing execution game and decompression game.

[netrome]

The tx_commitment is not related to the block or block id. You can prove that you can decompress transactions using data from the compressed header, but it doesn't prove decompression for the regular block.

Anyone can submit a valid compressed header with valid transactions, and you can verify that you can decompress transactions, but these transactions will not be from the block, they can be any random transactions.

If tx_commitment was a part of the regular block, then you could prove that decompressed transactions are unrelated to the block within the decompression game.

By having tx_commitment only in a compressed header, we require our block-proving game to take a compressed header as an input along with a regular header, mixing execution game and decompression game.

@rymnc, @xgreenx and I just discussed this and we agreed to:

1. Have the tx_commitment (which commits to the transaction IDs) be part of the full uncompressed block header.
2. Add a "deregister" range of block heights to the compressed block header. This range identifies which blocks that have been "evicted" from the temporal registry.
3. Make the compressed block header a strict superset of the full uncompressed block header. Note 1: This means that we don't need to explicitly store the block ID in the compressed block header, since this should be computable. Note 2: We'll still have fields (e.g. temporal registry commitment etc.) that belong in the compressed block header but not full block header.

[rymnc]

closing in favor of #2572