Handling Legacy and New RLP Encoding of Boolean Values

[ChenxingLi]

In the legacy RLP encoding implementation, boolean values are encoded as follows: false is encoded as 0 while true is encoded as 1.

In the new RLP encoding implementation, false is represented as an empty list. This change has introduced potential compatibility issues when upgrading to the new RLP implementation, as observed in a recent PR #3247 attempting to update the RLP version. While the PR added partial forward compatibility by handling legacy decoding, this approach is insufficient. A more comprehensive treatment is required, depending on the specific context of usage.

1. Consensus-Related Data
   For consensus-critical data (e.g., receipts), the encoding directly impacts consensus and must remain unchanged to avoid breaking the consensus rules.
   Solution: Manually override the encoding behavior for such cases to ensure false is encoded as 0 rather than as an empty list. This ensures backward compatibility and consistency with legacy implementations.

2. P2P Protocol Data
   For P2P data exchange, as implemented in the current PR, the decode logic is backward-compatible, but the encode logic immediately adopts the new RLP spec. This renders P2P data generated from new nodes incompatible with legacy nodes.
   Proposed Phased Upgrade:

   • Phase 1: All nodes must support decoding both legacy (0 and 1) and new (empty list) boolean decodings. Encoding should strictly follow the legacy method (false as 0, true as 1).
   • Phase 2: All nodes must support decoding both formats but now transition to encoding using the new RLP spec (false as an empty list, true as 1).

3. Database-Related Data
   For data stored in the database, the current implementation's decoding compatibility is sufficient.

Carefully audit types and decoding logic to identify any potential decode errors. These errors could lead to unintended consequences, including consensus divergence. Special attention should be given to fields that require strict decoding consistency to avoid breaking consensus.

This issue will remain open until the completion of Phase 2 of the P2P-related upgrade, ensuring full compatibility across both encode and decode paths.