# Forks in time, the optimistic verification case **URL:** \ **Category:** Research\ **Created:** [June 23, 2023, 10:45am UTC](https://forum.autonomys.xyz/t/forks-in-time-the-optimistic-verification-case/1540 "2023-06-23T10:45:26Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Barak](https://avatars.discourse-cdn.com/v4/letter/b/dbc845/32.png) [@Barak](https://forum.autonomys.xyz/u/Barak)\ **Post date:** [June 23, 2023, 10:45am UTC](https://forum.autonomys.xyz/t/forks-in-time-the-optimistic-verification-case/1540/1 "2023-06-23T10:45:26Z")
This post addresses the different Time Evaluation Tiers as can be found in the current proof-of-time [design](https://subspacelabs.notion.site/Proof-of-Time-Design-Document-WIP-c96562871568476390fd71667eac5173). The current proof-of-time [spec](https://subspacelabs.notion.site/PoT-Specification-WIP-4e17a6d5b03a4abea864ba2d0b97970e) 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. Background: - 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. ---
**Author:** ![nazar-pc](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.autonomys.xyz/nazar-pc/32/6_2.png) [@nazar-pc](https://forum.autonomys.xyz/u/nazar-pc)\ **Post date:** [June 23, 2023, 11:34am UTC](https://forum.autonomys.xyz/t/forks-in-time-the-optimistic-verification-case/1540/2 "2023-06-23T11:34:45Z")
> It appears that time evaluators should apply full verification on such forks. Both forks could be perfectly valid, what do you mean by “full verification”? Verification is done by default by absolutely all nodes on the network, including farmers. ---
**Author:** ![Barak](https://avatars.discourse-cdn.com/v4/letter/b/dbc845/32.png) [@Barak](https://forum.autonomys.xyz/u/Barak)\ **Post date:** [June 23, 2023, 12:47pm UTC](https://forum.autonomys.xyz/t/forks-in-time-the-optimistic-verification-case/1540/3 "2023-06-23T12:47:53Z")
By full verification I mean verification of proofs of time as well. In the optimistic verification case farmers don’t verify it. ---
**Author:** ![nazar-pc](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.autonomys.xyz/nazar-pc/32/6_2.png) [@nazar-pc](https://forum.autonomys.xyz/u/nazar-pc)\ **Post date:** [June 23, 2023, 1:04pm UTC](https://forum.autonomys.xyz/t/forks-in-time-the-optimistic-verification-case/1540/4 "2023-06-23T13:04:51Z")
Time evaluators have proof of time produced locally, verifying is just comparing two proofs for equality, I think they should do that and generate fraud proofs once we switch to optimistic approach. Before that farmers will verify everything and will not include invalid proof of time to begin with. ---
**Author:** ![Barak](https://avatars.discourse-cdn.com/v4/letter/b/dbc845/32.png) [@Barak](https://forum.autonomys.xyz/u/Barak)\ **Post date:** [June 23, 2023, 1:27pm UTC](https://forum.autonomys.xyz/t/forks-in-time-the-optimistic-verification-case/1540/5 "2023-06-23T13:27:20Z")
It appears I’ve done bad job in describing the scenario: > verifying is just comparing two proofs for equality This will not be the case if the proof-of-time seed is different, and the seed is derived from the injected block. In other words, a long enough fork in the blockchain will lead to incomparable proofs of time, where both could be honest (perfectly valid). I thought that is what you indicated above. ---
**Author:** ![nazar-pc](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.autonomys.xyz/nazar-pc/32/6_2.png) [@nazar-pc](https://forum.autonomys.xyz/u/nazar-pc)\ **Post date:** [June 24, 2023, 12:20am UTC](https://forum.autonomys.xyz/t/forks-in-time-the-optimistic-verification-case/1540/6 "2023-06-24T00:20:31Z")
I see, then proof should be clearly marked as belonging to a particular fork, otherwise it can’t be challenged at all. ---
**Author:** ![dariolina](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.autonomys.xyz/dariolina/32/743_2.png) [@dariolina](https://forum.autonomys.xyz/u/dariolina)\ **Post date:** [June 27, 2023, 12:36pm UTC](https://forum.autonomys.xyz/t/forks-in-time-the-optimistic-verification-case/1540/7 "2023-06-27T12:36:36Z")
Wouldn’t the fact that we include the latest injected block hash implicitly mark the fork we’re building on? If not, what could we use for that?