SIMD-0307

TL;DR

Add a block footer to Solana blocks and expose footer fields in the `getBlock` rpc endpoint.

Summary

Add a block footer to Solana blocks and expose footer fields in the `getBlock` rpc endpoint.

Motivation

For the purposes of historical monitoring, development, and auditing, it is important to know exactly who produced a block and when it was produced. Currently, this information can be partially inferred from Gossip and from vote timestamps. Unfortunately there are some problems with the current approach: - The information from gossip is ephemeral. Currently a peer needs to record and persist it. This may cause synchronization issues when matching client updates in gossip with the correct slot. - Gossip lacks important information that may useful for monitoring (e.g. scheduler used, mods, configuration settings, etc). - Vote timestamps have a granularity of 1-second, so they cannot be used to estimate block duration. - Vote timestamps will be removed with Alpenglow. This SIMD solves these issues by including relevant information in a static block footer.

Key Changes

• Client - The software run by leaders to interface with a solana cluster. (e.g. agave or frankendancer)
• Block Producer - The client that produced a given block
• Scheduler - The system responsible for processing incoming transactions and ordering them for block construction.
• Forward Error Correction set (FEC set) - A collection of shreds. At a high level, this is a construct that leverages Reed-Solomon encoding to overcome the problem of data loss from packet drops.
• Shreds - A fixed chunk of encoded raw block data.
• Entry Batch - An array of entries.
• Entry - An array of transactions.
• Block Marker - A chunk of structured non-transaction data that can be placed before, after, or in-between entry batches in a block.
• version: u16 is a positive integer which changes anytime a change is made to
• variant: u8 is an integer which identifies the structure of the block marker
• length: u16 is the length of the block marker payload in bytes (i.e. not
• footer_version: u16 is a positive integer which changes anytime a change is
• block_producer_time_nanos: u64 is a nanosecond UNIX timestamp representing
• block_user_agent_len: u8 the length of the block_user_agent string in
• block_user_agent: String is a variable length utf-8 encoded string that
• amend the footer_version and add the field the footer
• create a new block marker variant and add the field to its payload
• block_producer_time_nanos: u64
• block_user_agent_len: u8
• block_user_agent: String

Impact

This change will enable more reliable monitoring and benchmarking for operators and for the community. Clients and indexers will need to extend both in-memory and long-term block storage to be aware of the new columns added to the block footer. The client rpc engine will need to change to support the new fields.

Backwards Compatibility

- RPC requests for old slots should properly document and return a suitable default value (e.g. None). - Clients that don't implement this SIMD will reject new blocks because they will fail to parse the new footer. - Because this footer is mandatory, leaders that produce blocks without a footer will skip.

Security Considerations

- The footer fields are untrusted and purely informational. Tools that expose these fields to external users should clearly communicate their untrusted nature.