Fix some panicking code

[carllin]

Problem

1. block_id() is None on your own leader blocks, so highest_frozen_bank.block_id().unwrap() was panicking
2. assert!(poh_start_slot < highest_frozen_bank.slot()); was panicking because it's possible that poh finishes the last tick for leader bank X+1, calls flush_tick_cache(), which will set the poh_start_slot to bank X+1. This means it's possible for the start_slot to be X+1 before replay_stage detects the bank is finished and freezes the bank, which makes it possible that start_slot = X+1 and the highest_frozen_slot = X.

Summary of Changes

1. Make block id default for now, not sure how to handle this for leader blocks
2. Removed the assert in reset poh logic

Fixes #

[wen-coding]

Hmm, I thought you said you wanted to remove this code, why do we need it in Alpenglow?

[carllin]

I think it's necessary to keep the poh up to date for banking stage would_be_leader() checks

Ideally those get replaced eventually by the separate skip loop timer which tracks the current slot

[wen-coding]

Please add comment saying why we want this now and when we plan to remove it.

[wen-coding]

Do we have block_id now? I thought you want block_id when you are not the leader?

[carllin]

yeah it exists right now, i'll replicate that behavior

[wen-coding]

Then I think you want block_id().unwrap_or() rather than Hash::default()? And add it to comment we need to fix it for leader block in the future (maybe file an issue)

[carllin]

alpenglow/core/src/consensus.rs

Line 627 in 6770619

Hash::default()

. looks like leaders will be Hash::default()

[wen-coding]

Hmm why? The leaders should know block_id when the block is complete and it wants to endorse its own block?

[carllin]

oh and this PR description: anza-xyz/agave#2776 (comment)

[carllin]

ah i remember now, it's because

1. Bank tick is registered in Poh
2. Replay detects the bank ticks are full, freezes the bank
3. Shred is created by broadcast

There is no guarantee 3 happens before 2, so it's not necessarily possible for the leader to compute the block id

[wen-coding]

I would prefer leader votes with its own block-id if possible, I would still say chat with Ashwin to see if we can do that.

[carllin]

"or to simply resend the vote once the last shred is finished (this would involve messing with the timestamp or deduplication code)."

I think this was the original plan

[wen-coding]

I think we can also hold the vote, I don't think we need to hold the vote for that long, shred in broadcast should be fast?