-
Notifications
You must be signed in to change notification settings - Fork 4
Questions
Daejun Park edited this page Jun 25, 2019
·
6 revisions
- When a validator creates an attestation
\alpha
, does he explicitly specify the source epoch (i.e.,LJ(\alpha)
)? - Does
view(B)
consider all of the attestations included in the blocks in the ascending chain fromB
, even if some of them attest other blocks not in the chain? Also,view(B)
does not consider attestations that were arrived but not included in those blocks, right? - (In Section "A Four-Case Finalization Rule") For "the attestations
\alpha
that justified B3",LJ(\alpha)
is unique?- How to guarantee
LJ(\alpha)
is equal toold_previous_justified_epoch
?
- How to guarantee
- Which part of the spec corresponds to Section "Modified LMD GHOST Fork Choice Rule, Time-Delayed Version"?
- In Section 3 "Enabling Dynamic Validator Sets" of the Casper FFG paper, the notion of "dynasty" and "forward/rear validator sets" are introduced. Are they incorporated in the Phase 0 spec?
- is it possible for a block B to contain an attestation that attests to B?
- a block proposer is supposed to explicitly attest? if so, how? if not, would the implicit attestation considered when counting the votes?
- why
>= 2/3
instead of> 2/3
when checking majority votes? (in BFT,> 2/3
is required, and why different here?) - why should block contain the hash of the post-state of the block, instead of the pre-state (i.e., post-state of parent block)?
- is the new finalization rule still safe? (especially when an epoch n, n+1, n+2 are justified and n is the source of n+2, but not of n+1.)
- why >50%?
- e.g., suppose validators: a,b,c,d,e,f. {abcd} attests b1, {ef} attests b2. b1 justified. but {abc} votes e1, {def} votes e2. e2 as eth1 node. then eht1 node is voted from minority of majority.