SIMD-0298

TL;DR

This proposal adds the bank hash to the block footer and introduces validity constraints to ensure the bank hash matches the expected value.

Summary

This proposal adds the bank hash to the block footer and introduces validity constraints to ensure the bank hash matches the expected value.

Motivation

This proposal is part of the changes required for Alpenglow. In Alpenglow, votes do not contain the `bank_hash`. Instead they are purely on `block_id` If we remove `bank_hash` from votes without any other changes, then execution would not be a part of consensus at all, meaning if there is a bug in the runtime which causes a `bank_hash` mismatch it could be difficult to identify quickly and resolve. This proposal moves consensus on the `bank_hash` to the block footer so that we still have consensus on execution state.

Key Changes

• footer_version: u16 - Version number for the footer structure (currently 1)
• block_producer_time_nanos: u64 - Nanosecond UNIX timestamp when the block producer started constructing the block
• block_user_agent_len: u8 - Length of the user agent string in bytes
• block_user_agent: String - Variable length UTF-8 encoded string (up to 255 bytes) identifying the block producer
• parent_bank_hash - Hash of the parent bank's state (32 bytes)
• signature_count - Total number of signatures processed in the bank (64 bits)
• last_blockhash - The blockhash used for transaction processing (32 bytes)
• accounts_lt_hash_checksum - Checksum of the accounts ledger tree (32 bytes)
• accounts - Detailed account state information (variable size)
• Hard Fork Data (when applicable) - If the current slot is a hard fork slot, additional hard fork data is hashed into the final result
• The bank_hash does not match the post execution state of the block
• The bank_hash is missing (for blocks after the feature is activated)
• The bank_hash will be computed at the end of packing each block.
• Replaying validators will verify the bank_hash in the block footer
• Implementation of the new block footer structure
• Updates to block production logic to include the bank_hash
• Updates to block replay logic to verify the bank_hash correctly corresponds to the post execution bank state

Impact

Blocks now contain slightly more metadata bytes which cannot be used for transactions.

Backwards Compatibility

This change is not backwards compatible and requires a feature flag for activation. All validators must upgrade to support the new block footer format and validation rules before the feature is activated.

Security Considerations

This change makes block validity more restrictive. No blocks would be valid under this proposal that would otherwise be invalid today.