Need to verify a block contains the expected number of hashes

[mvines]

When we enable real PoH, ticks will always be separated from the previous tick by a well-known number of hashes. Blocks that do not contain this expected separation should be rejected as malformed, as that indicates somebody trying to propose a "short block".

blocktree_processor.rs is likely where this additional verification should go.

[jstarry]

@mvines I'm confused by this comment: https://github.com/solana-labs/solana/blob/master/core/src/entry.rs#L89 Is it outdated? A tick should have poh.hashes_per_tick right?

[jstarry]

Should both tick entries and transaction entries have the same number of hashes? It looks that way from poh.rs but not confident

[jstarry]

Should verification be disabled when hashes_per_tick == None? I think it would be nice to cleaner to remove the possibility of hashes_per_tick being None and instead setting it to a small number.. Thoughts?

[jstarry]

Looks like slot 0 gets filled with ticks with only 1 hash each https://github.com/solana-labs/solana/blob/master/core/src/entry.rs#L369. Is this by design or should it be updated to use the hashes_per_tick config value?

[mvines]

Should both tick entries and transaction entries have the same number of hashes? It looks that way from poh.rs but not confident

Not necessarily. The sum of hashes in all entries leading up to an including the next tick entry should totally hashes_per_tick

[mvines]

Should verification be disabled when hashes_per_tick == None? I think it would be nice to cleaner to remove the possibility of hashes_per_tick being None and instead setting it to a small number.. Thoughts?

Small number probably won't work as even at None, each entry with transactions within it will get at least 1 hash. So a small number would artificially limit to number of transactions that can end up in a given tick.

[mvines]

Looks like slot 0 gets filled with ticks with only 1 hash each https://github.com/solana-labs/solana/blob/master/core/src/entry.rs#L369. Is this by design or should it be updated to use the hashes_per_tick config value?

It should be updated as well