At Record Stage, it seems there is possibility about not hashing when tick event.

[JhChoy]

Please correct me if I'm wrong.
At record_stage.rs :: fn try_process_signals,
if let Some(entry) = recorder.tick(start_time, tick_duration) { sender.send(entry).or(Err(()))?; }

recorder.rs :: fn tick, it returns
Some(self.record(vec![]))

and at fn record
Entry::new_mut(&mut self.last_hash, &mut self.num_hashes, transactions)

goes to Entry:: fn new_mut,
let entry = Self::new(start_hash, *cur_hashes, transactions);
and reset num_hashes and start_hash
*start_hash = entry.id; *cur_hashes = 0;

At fn new, it calls next_hash and there,

if !hash_data.is_empty() {
        extend_and_hash(&id, &hash_data)
    } else if num_hashes != 0 {
        hash(&id)
    } else {
        id
    }

hash(&id) looks like to use for hashing tick event b/c tick event doesn't have data, just num_hashes.
However, when if tick event occurs just after recording entry with txs, tick event will have 0 num_hashes because it always resets after calling Entry::new_mut. Therefore, tick event couldn't be hashed.
I want you to let me know if I'm mistaken or if this is a bug.

[garious]

Not exactly a bug, but a redundant entry. The first entry in the genesis block actually uses this "feature" to communicate the ledger's seed hash.

@rob-solana, did you coincidently fix exactly this last week? Maybe validators should probably reject ledgers with empty entries after the genesis' entry0? I can't think of how you'd use empty entries to perform an attack, but it does seem weird that empty entries would allow multiple valid ledgers to coexist.

[garious]

@rob-solana, ping

[rob-solana]

I'm pretty sure there's no possibility of generating a hashless Entry in record any more. Entry test code can still generate weird entries, but PoH code is very strict.