Support RLP-encoded block header validation against `blockHash`

[0xClandestine]

🧐 Motivation

It would be valuable if the Blockhash utility supported verifying RLP-encoded block headers against historical block hashes. This is useful for block header, account, storage, tx, and event proofs.

📝 Details

Proposed implementation (should definitely include calldata variants given rlp block headers are typically provided by the user as calldata):

/**
 * @dev Verifies that the RLP-encoded block header matches the canonical block hash.
 * @param blockHeader The full RLP-encoded block header.
 * @param blockNumber The block number it claims to correspond to.
 * @return True if the keccak256 hash of the blockHeader matches the historical block hash.
 */
function verifyBlockHeader(bytes memory blockHeader, uint256 blockNumber) internal view returns (bool) {
    return blockHeader.blockHash() == blockNumber.blockHash();
}

/**
 * @dev Computes the hash of an RLP-encoded block header.
 * @param rlp The RLP-encoded header data.
 * @return hash The keccak256 hash of the RLP payload.
 */
function blockHash(bytes memory rlp) internal pure returns (bytes32 hash) {
    assembly {
        hash := keccak256(add(rlp, 0x20), mload(rlp))
    }
}

This addition would complement #5680.

[0xClandestine]

Probably a good idea to include something like this as well. Was able to significantly reduce the cost to decode the most commonly used header fields (e.g. stateRoot, txRoot, recieptsRoot, and logsBloom) by hardcoding their offsets/lengths.

/// @notice Efficiently extracts one of the first 7 fields from an RLP-encoded Ethereum block header.
/// @dev Optimized for extracting one of the first 7 fields (parentHash, ommersHash, etc.)
///      from a canonical RLP-encoded block header using precomputed offsets.
///      Much faster and cheaper than generic RLP decoding for these fields.
function decodeLeadingField(bytes calldata header, uint256 field) internal pure returns (bytes memory) {
    unchecked {
        // Field 0: parentHash (32 bytes)
        // Field 1: ommersHash (32 bytes)
        // Field 2: beneficiary (20 bytes)
        // Field 3: stateRoot (32 bytes)
        // Field 4: transactionsRoot (32 bytes)
        // Field 5: receiptsRoot (32 bytes)
        // Field 6: logsBloom (259 bytes)
        uint8[7] memory offsets = [1, 34, 67, 88, 121, 154, 186];
        uint16[7] memory lengths = [32, 32, 20, 32, 32, 32, 259];
        uint256 start = 1 + (uint8(header[0]) - (LIST_LONG_START - 1)) + offsets[field];
        return header[start:start + lengths[field]];
    }
}

[0xClandestine]

cc @ernestognw

[Amxx]

function blockHash(bytes memory rlpblockHeader) is just doing keccak256(blockHeader). I'm not sure it comes with any significant value as a helper.

Maybe a better direction is to provide parser for blockHeaders, allowing to split the various elements. If we had a function blockNumber(bytes memory header) returns (uint256), then we would be able to write

function verify(bytes memory blockHeader) internal view returns (bool) {
    return keccak256(blockHeader) == Blockhash.blockHash(blockNumber(blockHeader));
}

The issue with parsing functions is that:

• size of a blockHeader is not constant, some elements can be added to it. This means we have to be particularly carefull about futur proffness (we don't want the functions to break is the size of the block header is extended again)
  • for example, EIP-1559 added base_fee_per_gas at the end of the block, that was not present before
• some of the elements don't have a constant size, so just looking at the overall size of the header doesn't tell use what format it should be.