Fix mismatch in receipts

[badrogger]

Description

Fixes a receiptsRoot mismatch between block producers and syncing nodes.

The EIP-2718 typed-receipt encoding in Block::enact and Block::commitToSeal was gated on EIP1559TransactionsPatch. Since skaled accepts the EIP-1559 transaction format before the Berlin fork, nodes with that patch active would start emitting typed receipt encodings
(0x01/0x02-prefixed RLP) for blocks produced before the coordinated Berlin fork timestamp. A node re-enacting those blocks (e.g. a sync/archive node catching up) would then compute a different receiptsRoot than the one sealed in the block header, causing a
state/receipts mismatch.

This change gates the typed-receipt encoding on BerlinForkPatch instead, in both code paths, so the receipt encoding only changes at the coordinated Berlin fork and pre-Berlin blocks keep their original receiptsRoot. The EIP-1559 transaction format itself remains
accepted before Berlin; only the receipt encoding activation point moves.

Tests

• Reproduced and verified the fix with the existing test/api-tests/hardfork-compat suite, which performs a 5.1.0 → 5.2.0 upgrade scenario: runs a mixed workload on a 5.1.0 primary (legacy transfers, Type-1 access-list txs, Type-2 EIP-1559 txs, contract deploys,
  CREATE/CREATE2 factory), then launches a 5.2.0 sync node (syncNode=true, archiveMode=true) and asserts per-block stateRoot and block-hash equality across the whole chain. Before the fix the sync node diverged on blocks containing typed transactions produced
  pre-Berlin; with the fix the comparison passes.
• Existing unit tests covering typed-receipt RLP round-trips and Berlin schedule behavior (test/unittests/libethereum/BerlinForkTransaction.cpp) continue to pass.

No new tests were added; the existing hardfork-compat suite already covers the failing scenario.

Performance Impact

None expected. The change only swaps which patch flag is consulted (BerlinForkPatch vs EIP1559TransactionsPatch) — both are constant-time timestamp checks — and the receipt encoding work performed per transaction is unchanged. No benchmarks were run as the change is
not on a hot path beyond what already executed per receipt.

[github-actions]

SUGGESTIONS BEFORE MERGE:

1. Build custom container here: https://github.com/skalenetwork/skaled/actions?query=workflow%3A%22Custom+Docker+and+Binary%22
2. Test it here: https://github.com/skalenetwork/skale-ci-integration_tests/actions?query=workflow%3A%22Skaled+Nightly+Tests%22
3. Edit VERSION file appropriately to your changes!
   See https://skalelabs.atlassian.net/wiki/spaces/SKALE/pages/2444951553/Branching+instructions

[Copilot]

Pull request overview

This PR fixes a consensus-critical receiptsRoot mismatch by aligning EIP-2718 typed-receipt encoding activation with BerlinForkPatch (instead of EIP1559TransactionsPatch) in both block production (commitToSeal) and block re-enactment (enact). This ensures pre-Berlin blocks retain their original receipt encoding/root even if typed transaction formats are accepted earlier.

Changes:

• Gate typed receipt encoding on BerlinForkPatch in Block::enact when computing receiptsRoot.
• Gate typed receipt encoding on BerlinForkPatch in Block::commitToSeal when computing the receipts trie/root.
• Add clarifying comments explaining why receipt encoding activation differs from early typed-transaction acceptance.

Review Findings (sorted by severity)

Critical: None found.
High: None found.
Medium: None found.
Low:

• A nearby comment in the transaction-encoding section still states it is “Same as receiptBytes creation”, which becomes misleading after this change because receipts are now gated by BerlinForkPatch while tx wrapping remains gated by EIP1559TransactionsPatch. (PR comment left.)

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.