In the Solana white paper, the author mentions how to generate the sequence timestamps when events come into the picture. Their proposal appends the previous hash to the input to compute the next hash.
While it certainly prevents the reordering attack in section 4.5, I don't see how it prevents an attacker from using the last legit hash prior to inputting reversed events. Using the notation from the paper, the attacker uses the true prior hash, hash10a, instead of hash10b. Now the attacker submits event3+hash10a, computes hash20c, and publishes to peers. How can a peer know whether either hash20c or hash20a is legit?