This post addresses the different Time Evaluation Tiers as can be found in the current proof-of-time design.
The current proof-of-time spec does not specify how time evaluators should act in a case of a fork, that is when they obtain a different proof of time from the one they compute, in the general case. For fraud proofs, it specified to ignore such proofs. This leads to inconsistencies and to a security gap described here.
The proof-of-time algorithm takes a block from the (consensus) blockchain and “injects” it into the timechain. From that point until the next injection the algorithm is deterministic.
In the 3rd verification tier “optimistic verification”, in case an incorrect proof of time is sent by a time evaluator, farmers rely on other time evaluators to send a fraud proof.
Suppose that (honest) time evaluators are working on the current chain. A malicious time evaluator, that in addition does not control the majority of space, can start working on a private chain where some proofs of time are incorrect. At some point this chain is announced.
When a farmer obtains either a block or a proof of time from that fork, they should decide whether to keep on working on the (honest) fork they have been working on or discard it and switch to the newly observed chain. Since we follow the heaviest-chain rule, the farmer will check if the (malicious) fork is heavier.
The attacker can easily build a heavier chain, since proof-of-space challenges are derived from proofs of time, and the latter are fake.
In this case we would like the time evaluators to reveal the fraud. The current spec does not address this case, as long as incorrect proofs start to appear after a different injection point (the section on fraud proofs, which used to say to ignore the proofs, is currently outdated).
It is assumed that time evaluators are synced with the blockchain, as they need the “injection blocks”. When a fork in the consensus chain is revealed, time evaluators like any other node should apply the fork-choice rule. It appears that time evaluators should apply full verification on such forks.
Yet, since the attack could be easily duplicated, forcing the time evaluator to verify forks opens the door to denial of service. Lastly, since the attacker could also produce correct proofs of time, such verification, if used, should be done in an unpredictable sequence of proofs.