SIMD-0307: Add Block Footer #307

jherrera-jump · 2025-06-17T20:20:31Z

No description provided.

MaxResnick · 2025-06-17T21:23:49Z

💯

apfitzge · 2025-06-18T17:45:03Z

I can understand the motivation, but I'm not convinced this will be used properly.

As an operator, I'm competing with every other node on the network for stakers, if I'm generating higher returns by producing better blocks, why would I willingly share any information about how I'm doing that? In fact, I'd say I'm incentivized to lie! If I can generate higher returns by using jito-agave I will make my blocks state that I'm using native-firedancer as an attempt to trick other operators into using a different client than me.

apfitzge · 2025-06-18T17:51:22Z

proposals/0307-add-block-header.md

+- `version: u64` is a positive integer which changes anytime a change is made to
+the header. The initial version will be 1.
+
+- `header_length: u64` is the length of the rest of the header in bytes (i.e.


Do we need such large lengths for the header? Could this be a u16?

apfitzge · 2025-06-18T17:52:13Z

proposals/0307-add-block-header.md

+- `block_producer_time_nanos: u64` is a nanosecond UNIX timestamp representing
+the time when the block producer became leader and started constructing the
+block.


Let's be specific that this is the time they started constructing the block. Current description to me had some ambiguity on if it's when I became leader (for my entire allocation) or separately for each block. I think the intent here is a separate timestamp for each block.

I can't think of an incentivized reason to lie about this, but it also cannot be verified. Is there a concern about having incorrect values on this?

There is a slight incentive for block-time cheaters to lie, but this can probably be detected if its too aggregious. Eventually would be nice to make this timestamp consensus-based like the vote timestamp but I figured that would be its own future SIMD.

apfitzge · 2025-06-18T17:56:44Z

proposals/0307-add-block-header.md

+following fields in the header
+
+- `block_producer_time_nanos`: u64
+- `block_user_agent`: [u8; 256]


Can you explain thoughts here on having a static size here for the block_user_agent? Why not u8 length with trailing bytes?

I figured the overhead was minimal and the extra unused space could be used as a scratch pad whatever the validator wants (e.g. non-string binary data). Happy to change this though if you feel you strongly prefer a variable-length string.

Yah variable length sounds fine

Just specify if >256 the block is invalid

MaxResnick · 2025-06-18T18:01:08Z

I can understand the motivation, but I'm not convinced this will be used properly.

As an operator, I'm competing with every other node on the network for stakers, if I'm generating higher returns by producing better blocks, why would I willingly share any information about how I'm doing that? In fact, I'd say I'm incentivized to lie! If I can generate higher returns by using jito-agave I will make my blocks state that I'm using native-firedancer as an attempt to trick other operators into using a different client than me.

At some point pal validators were not reporting that they were pal in gossip but I believe they are reporting now. Either way I think that specific field may or may not be useful but many of the other fields seem very useful.

jherrera-jump · 2025-06-18T19:14:10Z

I can understand the motivation, but I'm not convinced this will be used properly.

As an operator, I'm competing with every other node on the network for stakers, if I'm generating higher returns by producing better blocks, why would I willingly share any information about how I'm doing that? In fact, I'd say I'm incentivized to lie! If I can generate higher returns by using jito-agave I will make my blocks state that I'm using native-firedancer as an attempt to trick other operators into using a different client than me.

Yea I agree some validators will most likely lie, intentionally or even unintentionally (e.g. a software fork that doesn't see updating this field as a huge priority and just never gets to it). Unfortunately there isn't a straightforward way to fix this problem, which exists for gossip-sourced metrics already. The community will use this metric whether its fully trustworthy or not, and if we don't include it in the block header we'll just keep getting it from gossip. The real benefit here is the metric persisted on the chain, and we get a bunch of extra info that isn't currently in gossip.

Also, I'd say persisting the info on the chain actually improves accountability, since there is now a public, easily accessible history of what you claimed to be. There are real world incentives not to be caught lying (e.g. stake from pools, reputation), and there are ways to catch liers (sometimes) by inferring the client (e.g. suble differences in the way jito bundles are sent to agave vs frankdancer. Patterns in transaction ordering that differ in different scheduler implementations, etc.)

apfitzge · 2025-06-20T14:33:52Z

The community will use this metric whether its fully trustworthy or not, and if we don't include it in the block header we'll just keep getting it from gossip. The real benefit here is the metric persisted on the chain, and we get a bunch of extra info that isn't currently in gossip.

Thanks for this clarification, I had overlooked we publish this information over gossip already, but its' done on a less granular & trackable way than what this proposal provides. I'd need to constantly be listening gossip in order to get rough estimate.

KirillLykov

To me seems to be valuable for the analysis of the cluster behavior to have additional block information such as when block production has started and other additional data which might be added later as follow up of this proposal.

KirillLykov · 2025-06-22T14:42:07Z

proposals/0307-add-block-header.md

+- `block_producer_time_nanos: u64` is a nanosecond UNIX timestamp representing
+the time when the block producer started constructing the block.
+
+- `block_user_agent: [u8; 256]` is a string that provides identifying


Maybe a naive question, but don't we know the leader for each block from schedule?

Yeah, the leader schedule is generated two epochs in advance from information in staked on-chain vote accounts. We don't know much more than the leader pubkey and info related to active stake.

A use case for block_user_agent these fields is to get validator implementation specific information, which is more detailed than what's just on the leader schedule or even whats described by any part of the solana protocol. A use case for block_producer_time_nanos is to estimate when blocks were added to the chain and their duration (protocol limits for these quantities, but are fairly loose, and identifiying exact timestamps / durations is useful).

KirillLykov · 2025-06-22T15:14:36Z

proposals/0307-add-block-header.md

+- `header_length: u16` is the length of the rest of the header in bytes (i.e.
+not including the `block_header_flag`, `version`, and `header_length` fields).
+
+- `block_producer_time_nanos: u64` is a nanosecond UNIX timestamp representing


don't we need to have also the information about how long it took to execute this block? The timestamp in the block is in seconds so hard to use it.

We can estimate block duration (including network latency) by taking the difference in timestamps between adjacent blocks.

I figured this would be sufficient for an MVP of the block header. There's an endless list of metrics we could additionally include in the block header (e.g. how long it took to execute the block, how long it took to fetch / resolve account data, timing for votes / non-votes, timing for validation checks like deduplication or expiration ). Since its not obvious which ones are worth persisting in the block header I think they should be a future SIMD.

Agree, I think even this timestamp would be sweet to have. The current block timestamp was quite useless for me due to lack of precision.

In the pre-Alpenglow era, does started constructing effectively mean when I started generating the PoH ticks? Or when replay/maybe_start_leader decided it was my turn to start packing transactions?

Agree w/ your point that there are a million metrics we could debate, and I don't have a strong preference on what we include for v1, but I do have a preference to get really specific on what the metrics are supposed to mean

I'm leaning towards replay/maybe_start_leader since POH will get removed with alpenglow anyways. I'll add something a bit more specific

bw-solana · 2025-06-30T20:37:44Z

proposals/0307-add-block-header.md

+- `header_length: u16` is the length of the rest of the header in bytes (i.e.
+not including the `block_header_flag`, `version`, and `header_length` fields).
+
+- `block_producer_time_nanos: u64` is a nanosecond UNIX timestamp representing


In the pre-Alpenglow era, does started constructing effectively mean when I started generating the PoH ticks? Or when replay/maybe_start_leader decided it was my turn to start packing transactions?

Agree w/ your point that there are a million metrics we could debate, and I don't have a strong preference on what we include for v1, but I do have a preference to get really specific on what the metrics are supposed to mean

bw-solana · 2025-06-30T20:45:51Z

proposals/0307-add-block-header.md

+}
+```
+<!-- markdownlint-restore -->
+


You mention this below, but I think it would be good to include a section here to mention that we need to mark blocks dead if they don't contain a valid header at the beginning of the payload section

bw-solana · 2025-06-30T20:48:32Z

proposals/0307-add-block-header.md

+
+## Security Considerations
+
+- The header fields are untrusted and purely informational. Tools that expose


I'm okay starting with this.

But I think if we truly want to replay timestamps in vote (which will definitely be going away as part of Alpenglow), we might want to wrap some policy around the timestamp piece.

But again, this could be a follow-up

bw-solana · 2025-06-30T20:57:05Z

proposals/0307-add-block-header.md

+This SIMD add the following header at the beginning of the raw block data. This
+puts it on the same abstraction layer as serialized entry batch data. Put
+differently, the serialized header will be prepended to the first serialized
+entry batch in the block.


I have mixed feelings about this... On the one hand having this special header come first makes replay easier because we can treat the first "entry" differently and then assume we are only deserializing entries thereafter.

On the other hand, it means we need to fill out all the block header data up front before constructing/sending out anything else. I don't think this matters for any of the fields you mention below. However, for something like SIMD-0298, this means we need the bank hash for N-1 before we can build N. Doesn't seem great for pipelining w/ async.

Would a Block footer give us more flexibility? Might be a pain in the ass for deserializing if we don't know exactly where the end is...

Apologies for the gripe w/o a clear alternative suggestion. Just want to make sure we don't overlook this constraint we're introducing.

You make a good point, I think a block "footer" makes more sense with chained merkle shreds. A footer also makes sense if we eventually include more timing metrics.

I think we should just be able to add the footer as a suffix to the block payload.

From the shred spec document (which is hopefully not outdated)
The serialization of a batch is the concatenation of all serialized entries, prefixed by the entry count as a u64 integer (8 bytes).
Since the first byte of a typical entry batch starts with a positive, non-zero integer, but this footer starts with 0 (block_header_flag), replay can know to treat this "entry batch" differently.

Yeah I like footer better. But should note 0298 is more like training wheels eventually we plan to remove that check once we are comfortable with the VMs playing nicely with each other.

bw-solana · 2025-07-03T20:38:18Z

This latest version looks good to me. @apfitzge what do you think?

MaxResnick · 2025-07-06T20:07:35Z

proposals/0307-add-block-footer.md

+```
+           Block Footer Layout
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| block_footer_flag           (64 bits) |


Now that we have changed to Block Footer instead of Header should `block_footer_flag' be placed at the end? Otherwise you need to know the offset to read the block_footer_flag which is supposed to tell you the offset?

I'm assuming block_footer_flag at beginning is still correct. It would be nice to know the offset of the footer, but this would mean buffering and stalling the pipeline.

I believe the implication here is a batch of 0 entries is still invalid and will be used to indicate this must be the start of the footer

Is the idea that after this is committed to block store the fields would be available so the only time we need to reference the flag for the offsets is during replay in which case we see the flag as we are reading the block top to bottom?

yes, that's my assumption

apfitzge

Overall looks good to me. Few comments on the some specific wording.

It's implied that this footer is the last thing in the block, since we call it a "footer". But we never explicitly state what to do if there's stuff after it.
Let's add a short description of how to handle blocks that have this footer serialized somewhere in the middle of a block. i.e. [entries, footer, entries].

apfitzge · 2025-07-08T15:31:18Z

proposals/0307-add-block-footer.md

+highest layer a block consists of some number (~100+) FEC sets. A single FEC
+set contains a handful of shreds (~32). Once sufficient shreds are available
+the raw block data is reconstructed and reinterpreted as an array of entry
+batches. Entry batches do not cross shred boundaries.


Entry batches do not cross shred boundaries.

This isn't true, right? shreds are MTU sized and batches of transactions are (often) larger than that, so they'd be split between threads.

Maybe I misunderstand what is meant by "shred boundary" here.

Bad wording on my part, I mean that entry batches are aligned with shred boundaries (i.e. they will start / stop at a shred boundary).

apfitzge · 2025-07-08T15:36:08Z

proposals/0307-add-block-footer.md

+
+While it is possible to make the block footer optional thanks to the
+`block_footer_flag` field, this proposal makes it mandatory. Blocks that don't
+include a valid footer in the block payload will be flagged as dead blocks and


Request a slight change of wording:

will be flagged as dead blocks

to

must be flagged as dead blocks

jherrera-jump force-pushed the add-block-header branch from 4b45bde to 5558f57 Compare June 17, 2025 20:21

jherrera-jump changed the title ~~SIMD-XXXX: Add Block Header~~ SIMD-0307: Add Block Header Jun 17, 2025

jherrera-jump force-pushed the add-block-header branch 3 times, most recently from 911787c to 459b5a9 Compare June 17, 2025 20:31

SIMD-0307: Add Block Header

5100ff7

jherrera-jump force-pushed the add-block-header branch from 459b5a9 to 5100ff7 Compare June 17, 2025 20:32

apfitzge reviewed Jun 18, 2025

View reviewed changes

KirillLykov reviewed Jun 22, 2025

View reviewed changes

github-actions bot mentioned this pull request Jun 23, 2025

Upstream Updates - Mon Jun 23 00:18:03 UTC 2025 smartcontractkit/chainlink-solana#1273

Open

change header_length type, change block_producer_time_nanos description

154d60a

jherrera-jump force-pushed the add-block-header branch from b026020 to 154d60a Compare June 24, 2025 16:13

bw-solana reviewed Jun 30, 2025

View reviewed changes

use footer instead of header

66a0d14

jherrera-jump force-pushed the add-block-header branch from ac72270 to 66a0d14 Compare July 2, 2025 19:40

jherrera-jump changed the title ~~SIMD-0307: Add Block Header~~ SIMD-0307: Add Block Footer Jul 2, 2025

MaxResnick reviewed Jul 6, 2025

View reviewed changes

apfitzge reviewed Jul 8, 2025

View reviewed changes

clarify wording in data layout + mandate sections

6428df0

jherrera-jump force-pushed the add-block-header branch from fc68b06 to 6428df0 Compare July 10, 2025 16:13

apfitzge approved these changes Jul 14, 2025

View reviewed changes

MaxResnick mentioned this pull request Jul 18, 2025

Roadmap: Async Execution #324

Open

wen-coding mentioned this pull request Aug 1, 2025

SIMD-0326: Alpenglow #326

Open


		## Security Considerations

		- The header fields are untrusted and purely informational. Tools that expose

SIMD-0307: Add Block Footer #307

Are you sure you want to change the base?

SIMD-0307: Add Block Footer #307

Uh oh!

Conversation

jherrera-jump commented Jun 17, 2025

Uh oh!

MaxResnick commented Jun 17, 2025

Uh oh!

apfitzge commented Jun 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MaxResnick commented Jun 18, 2025

Uh oh!

jherrera-jump commented Jun 18, 2025

Uh oh!

apfitzge commented Jun 20, 2025

Uh oh!

KirillLykov left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jherrera-jump Jul 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bw-solana commented Jul 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

apfitzge left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

jherrera-jump Jul 2, 2025 •

edited

Loading