Forks in time, the optimistic verification case

Research
1

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.

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.

1 Like
2

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.

3

By full verification I mean verification of proofs of time as well. In the optimistic verification case farmers don’t verify it.

4

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.

5

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.

6

I see, then proof should be clearly marked as belonging to a particular fork, otherwise it can’t be challenged at all.

7

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?