The new spec of algorithms are here: Dilithium PoT Specification

A Proof-of-Time is a proof that a sequential function was executed a certain predefined number of times. The inherent sequentiality of the PoT function means that the evaluator (timelord) cannot just add more computational power and parallelism to speed up the PoT function and block production. Therefore we assume that computing a PoT requires real (wall clock) time to elapse.

Time Evaluation Tiers

1. Local Evaluation (no liveness or incentive assumptions): Every consensus node runs its local Time evaluator (static hardware assumption) — similar to David Tse’s PoSaT Paper
2. Pessimistic Verification with Altruistic Liveness: Only a handful of nodes run the PoT evaluator and provide a check-pointed proof that all nodes must verify before applying and solving. This is the same network security model assumption as Chia (altruistic time lords) Po-Time Evaluators have an implicit incentive because the blockchain would stall if no one ran the PoT chain.
3. Optimistic Verification with Incentivized Liveness: Explicitly incentivize operators to produce PoT and only commit to the checkpoints while slashing operators who produce invalid PoT. Farmers eventually verify only fraud proofs.

Plan for Mainnet

Given our strict timeframe, I suggest the following outline as “minimum viable PoT”, corresponding to Tier-2:

Who runs PoT?

• Only some nodes with powerful hardware run the PoT evaluation and provide check-pointed proofs in every slot.
• Farmers are generally not expected to run PoT evaluations.
• Subspace will run some evaluator nodes on the highest-end consumer hardware.
• Domain operators are expected to run PoT aren’t (yet) incentivized to do so.
• PoT evaluation can be a cli flag for node setup

How are PoT outputs propagated?

• Via a gossip unsigned*.*
• If a node sees a PoT message that doesn’t extend a PoT chain known to them (e.g seed is consistent with previous known PoT, + accounted for injection), they ignore it and do not regossip.
• If a node sees a PoT message that is too far in the past or future, they ignore it and do not regossip.

How are PoT outputs stored on-chain?

• When a farmer produces a block, they should include alongside PoS, the PoT for all the “time” passed since the last block with a certain predefined (TBD) number of checkpoints (independent of time passed, bounded in size).