Update Proof of Time Spec - #69
Conversation
docs/consensus/proof_of_time.md
Outdated
|
|
||
| 1. Retrieve the parent block's PoT parameters and derive the expected PoT input for the current slot. | ||
| 2. Verify that the current block's proof-of-time output is valid according to the parent-derived input and parameters. | ||
| 3. Compare the PoT values in the header to the local view of the PoT chain. |
There was a problem hiding this comment.
I don't understand what this is supposed to mean
docs/consensus/proof_of_time.md
Outdated
|
|
||
| If the proof-of-time included in the block header covers local proofs that have already been verified, the block's PoT passes validation. | ||
|
|
||
| If the proof-of-time is not consistent with local view or the local view is missing some required slots — do necessary verification, including proving. |
There was a problem hiding this comment.
This is a strange way of writing it, what is "not consistent with local view" supposed to mean? The fact that we already have some proofs pre-verified due to them been seen and verified earlier can be though as an important implementation-level optimization, but I wouldn't make it the core part of the workflow.
There was a problem hiding this comment.
I would remove this detail, and sum it up by saying "some proofs may be cached locally" in a note at the end.
| 1. Retrieve the parent block's PoT parameters and derive the expected PoT input for the current slot. | ||
| 2. Verify that the current block's proof-of-time output is valid according to the parent-derived input and parameters. | ||
| 3. If the proof-of-time verification passes, the block's PoT is considered valid. |
There was a problem hiding this comment.
There are two PoT proofs in the block: for block's slot (which I think is what this revision of the text talks about) and future PoT (which is seems to be missing currently). Both need to be valid descendants of the parent block's PoT.
Updates