https://github.com/ethereum/research/blob/master/papers/casper/casper_basic_structure.pdf
2 Likes
I recommend Google Docs (or similar) for authoring/feedback as it allows people to comment in-line rather than having to do what I’m about to do. 
Section 2, paragraph 2 has “An epoch is a period of 100 epcochs”. I’m assuming this is a typo, but if not please come up with better variable names rather than using the same name to represent two things (1 epoch and 100 epochs).
Unfortunately google docs doesn’t do PDFs well: https://docs.google.com/document/d/152epW9cQ2sZ1ZBjCS1L8mwADXiZkMnm-75Xzb-tKDAg/edit?usp=sharing
Would definitely welcome other suggestions. And yes, you are correct about the typo, will fix.
I’d read it as “epoch is a period of 100 blocks”.
What are you using to create the pdf? Are you writing it in Latex? If so you can just put the source code into a repo or a doc.
Page 5 “During epoch n, validators are expected to send prepare and commit
messages with e = n and h equal to a checkpoint of epoch n”
But checkpoints are defined in the paper as the last block of an epoch, so it seems impossible to prepare and commit the checkpoint hash in advance, or did I miss something?
Yes, that was a mistake and should be changed. Should be:
“During epoch n+1, validators are expected to send prepare and commit
messages with e = n and h equal to a checkpoint of epoch n”
Next question: Is this argument correct:
When there are holes in the justified checkpoint list because not enough votes for the same hash came together, the specific Epoch is not secured by Casper and it is just secured by PoW?
Question on figure 1 in section 3: the right-hand side of the diagram shows two conflicting checkpoints, but they are at different block heights. Given that checkpoints are at a pre-determined block height how would this situation occur?
In section 2 you state:
During epoch n, validators are expected to send prepare and commit
messages with e = n and h equal to a checkpoint of epoch n. Prepare
messages may specify as h* a checkpoint for any previous epoch (preferably
the preceding checkpoint) of h , and which is justified (see below), and the
e* is expected to be the epoch of that checkpoint.
This clashes with your definition of h* above in the same section, which specifies h* as
h* the most recent justified hash
Something that is unclear from the paper is what happens if a checkpoint is not finalised during the following epoch. I would assume that prepare/commit carries on in to the next epoch, but then that could cause h* to change during an epoch and result in there not being enough prepares to finalise a checkpoint so perhaps I’m wrong with that assumption.
Yes, there can be holes in the justified checkpoint list as currently written. However, that specific epoch becomes also secured by Casper later on once a descendant is finalized, as finalizing anything in a hash chain necessarily implies finalizing everything before it.
No. If a checkpoint is not finalized during an epoch, the process is abandoned for that checkpoint, and starts again for its child.
So (prepare, commit) are always in the same epoch. 2/3 prepare, 2/3 commit and then it’s fine. Otherwise it restarts for the next epoch. I don’t understand what problem commit does solve then, Can’t we just “justify” with prepare?
Read the safety proof in the paper. The safety proof breaks down if commits are removed. There may well be ways to make a prepare for epoch N+1 do double-duty as a commit for epoch N, but this would just shuffle the complexity into a different place.
1 Like
In section 5.1 (Long Range Attacks) :
- You assert: If clients hear about two conflicting finalized checkpoints C_1 & C_2 where, from the point of view of all clients, T_2 > T_1, they all choose C_2 over C_1. Why is this true?
In my old neuroscience research group the way we would do edits of the .tex in Google Docs. This is what I suggest here.
1 Like