fix(headers): move tx_id_commitment to application_headers

[rymnc]

Linked Issues/PRs

• fault_proving(headers): create new version of the block header, with tx_id_commitment #2648

Description

We get rid of enum_dispatch because if you try to derive the impl on a trait with a generic, you also have to apply the generic to the enum ~ which we don't need. rather than having 2 traits, one generic and one not, opted to cut enum_dispatch altogether.

idk why we were directly accessing the block header fields in the whole codebase without using accessor methods, even when we had defined an enum for block header. this PR fixes that.

if fault-proving is enabled, we now generate BlockV1 with BlockHeaderV2. tx_id_commitment has been moved to GeneratedApplicationFieldsV2, renamed GeneratedApplicationFields to GeneratedApplicationFieldsV1. maybe we can remove pub from a lot of fields and convert to pub(crate) but i can do that in a follow up PR.

I still favour having a separate FaultProvingHeader field on the header, since we anyway have to define a new hash function for the ApplicationHeader<GeneratedApplicationFieldsV2>, it was less verbose before.

Reviewers guide

• all of the changes in crates other than types is just using getters/setters where necessary
• in types/header, refactored, removed enum_dispatch due to generic usage that didn't apply on parent enum
• moved tx_id_commitment from fault_proving_header to application_header. New struct GeneratedApplicationFieldsV2 to accommodate it.

AI generated desc

This pull request includes several changes to improve the consistency and readability of the code by replacing direct field accesses with method calls for accessing block header fields. The most important changes include updates to the BlockHeader field access, test adjustments, and feature additions in the Cargo.toml file.

Block Header Field Access Updates:

• Updated impl LastBlockConfig in crates/chain-config/src/config/state.rs to use method calls for accessing block header fields instead of direct field accesses.
• Modified impl From<&BlockHeader> for CompressedBlockHeader in crates/compression/src/compressed_block_payload/v1.rs to use method calls for accessing block header fields.
• Updated impl Header in crates/fuel-core/src/schema/block.rs to use method calls for accessing block header fields.

Test Adjustments:

• Adjusted various test cases in crates/fuel-core/src/executor.rs to use method calls for accessing block header fields. [1] [2] [3] [4]
• Updated test cases in crates/fuel-core/src/service/adapters/consensus_parameters_provider.rs to use method calls for setting consensus parameters version.

Feature Additions:

• Added new feature fault-proving in Cargo.toml for crates/services/consensus_module.
• Updated imports and function implementations in crates/services/consensus_module/poa/src/verifier.rs to support the new feature and improve code structure. [1] [2] [3]

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]

One nit, and one question. Only blocker from my side is that we should update the changelog:

1. The previous entry from fault_proving(headers): create new version of the block header, with tx_id_commitment #2648 should be marked as breaking iirc.
2. We should either modify or write a new entry for this PR if we change visibility of public fields in the block header.

Other than that, this looks good to me.

[netrome]

Thanks for the update. Looks good now!

[xgreenx]

I don't see what is the use case of having a trait for getters(and setters in the case of the tests).

Because it is generic, it means that it will be implemented only for HeaderV1 and HeaderV2 only. It can't be implemented for the BlockHeader enum, so it can't be used with it. Then, why do we need it? Looks like just public getters from impl section should be enough.

[rymnc]

leftover code from enum_dispatch land, will fix

[rymnc]

addressed in 28a816a