Add intro + mining docs #5
Conversation
lrettig
changed the title
to line up with the language in other docs in this series.
as in last commit
lrettig
changed the title
Includes image and formatting tweak to PoST
Factoring in more of Barak's helpful feedback
Factoring in Moshe's helpful feedback
Based on Barak feedback. While it's true that in Spacemesh the prover (i.e., a miner) generates their own commitment, rather than "receiving" it, it's also tied to their specific ID and cannot be used by anyone else. Let's leave Spacemesh-specific implementation details out of _this_ doc.
mining/03-poet.md
Outdated
|
|
||
|
|
||
|
|
||
| 1. All parties, provers and anyone who will independently verify generated proofs, agree on set of shared security parameters, including the designated period of time, _t,_ the number of layers in the graph, and the number of leaves to be included in a proof |
There was a problem hiding this comment.
Why not keeping the single prover-verifier description here?
There was a problem hiding this comment.
Here's the current wording: "All parties, including anyone who will independently verify generated proofs"
The idea is that there is no single verifier, since in practice any party synchronizing the blockmesh/validating transactions can act as a verifier.
There was a problem hiding this comment.
Indeed, but this is true for most protocols, but a single prover-verifier description is still used, no?
There was a problem hiding this comment.
I don't know. I think this is part of the same question we've been debating here: is this doc intended to document the platonic, theoretical PoET protocol, in which case it might make sense to discuss a single prover-verifier? Or is it intended to discuss the Spacemesh implementation of PoET, in practice, in which case there is no single prover-verifier?
I think which one we pick is less important than that we maintain consistency. I've been thinking more along the lines of the latter: the practical Spacemesh implementation, since these docs are geared towards devs, not researchers. My opinion is that people can refer to the original academic papers if they want pure theory.
Expand a few things, make things clearer, based on feedback from Barak and Moshe. Refer to "miners" not "provers" to make it clear that the miner is not the one doing the PoET proving.
Based on Shababo's helpful feedback. Make intro clearer about the context of this doc relative to the previous ones in the series. Remove full description of ATX contents/data structure. Opened a new task (#12) to track adding this somewhere else.
Based on helpful feedback from Shababo and Barak. Harmonize references to the "statement" ("piece of information"). Collapse description of the protocol into just the non-interactive case. Be clearer about how we talk about _t_ and time in general. Improve "further details" section.
Per Barak's feedback
Be clearer about the distinction between activation and PoST per Shababo
| @@ -0,0 +1,62 @@ | |||
| # Mining - Proof of Elapsed Time | |||
|
|
|||
| Proof of Elapsed Time, or PoET, is a cryptographic primitive used to prove that a specific amount of real (clock) time has elapsed. Elapsed time is measured by iterating a sequential work cycle that takes a set amount of time to execute. The algorithm provides a proof that it has worked sequentially for a predetermined number of cycles, and thus proves that the period of time determined by its parameters has elapsed during its entire execution. By committing to knowledge of some information (known as a "statement") as input to the proof-generation algorithm, a prover can assert cryptographically that they had knowledge of that information as of a given point in time. | |||
There was a problem hiding this comment.
What is the aim of the last sentence? It sounds to me like the "statement" has some significance beyond being just part of the construction.
There was a problem hiding this comment.
It explains the purpose of the PoET construction and puts it into context. The purpose isn't merely to prove that time has elapsed: it's to prove that time has elapsed since the prover had knowledge of the statement.
| <a name="algorithm"></a> | ||
| ### Non-interactive protocol | ||
|
|
||
| 1. All parties, including anyone who will independently verify generated proofs, agree on set of shared parameters, including the designated period of time, _t_ (i.e., the depth of the graph), and the number of leaves to be included in a proof |
There was a problem hiding this comment.
I don't like that why this is presented. If the construction is non-interactive, then there is no "pre-agreement". It is solely the prover who chooses the parameters.
There was a problem hiding this comment.
That's true in theory, but not in practice, in the way the algorithm is implemented in Spacemesh. Again it's the question of theory vs. practice :) When in doubt I've been erring on the side of practice since the intended audience here is devs not researchers; those who want theory can follow the links to the academic papers.
| ### Non-interactive protocol | ||
|
|
||
| 1. All parties, including anyone who will independently verify generated proofs, agree on set of shared parameters, including the designated period of time, _t_ (i.e., the depth of the graph), and the number of leaves to be included in a proof | ||
| 2. Prover receives a statement, then using the statement as input runs the hash function for _t_ time, i.e., generates a graph of a specified depth, calculates a commitment to that graph (Merkle root), derives the challenge from the commitment (using the [Fiat-Shamir heuristic](https://en.wikipedia.org/wiki/Fiat%E2%80%93Shamir_heuristic)), generates a proof (a set of labels and Merkle paths corresponding to the derived challenge). Publishes statement, Merkle root, and proof. |
There was a problem hiding this comment.
Here it sounds like the sequential work is to run the statement through the hash function for t time. The way that we use the statement is just to define a new hash function, that we will use to create the graph with.
There was a problem hiding this comment.
In practice how is this different than "using the statement as input runs the hash function for t time"?
Tighten language on PoET service based on latest feedback from Shababo and Barak
Based on Barak feedback
Remove for the sake of readability and clarity (I already added a simplified description above). As discussed with Shababo and Barak, we can add these back later when we publish more on the specifics of the data structures and the implementation.
|
From my perspective, this is ready to be merged. @avive please have a look and feel free to pull the trigger. I'll convert all outstanding to do items and questions into issues. CC @moshababo @barakshani |
|
Finished copying outstanding TODO items over to new tasks. |
Still need to add other docs and fill in placeholder links to them.