Replace cycles with epochs #149
Conversation
Also adjusted constants to keep interest rates and the quadratic leak period the same. Also, did some simplifications of the cycle calculation procedure. Make the decision to remove automatic registration of a validator as a proposer when they join, because that can just happen on its own due to the reshuffling procedure.
Suppose B1, B2, B3, B4 are consecutive blocks and we are now processing the end of the cycle containing B4. * If B4 is justified using source B3, then B3 is finalized. * If B4 is justified using source B2, and B3 has been justified, then B2 is finalized. * If B3 is justified using source B1, and B1 has been justified, then B1 is finalized.
* Added rewards for proposers * Added declining rewards for greater inclusion distance
|
Looking forward to having this PR merged :) One suggestion is to split |
specs/core/0_beacon-chain.md
Outdated
| @@ -1003,11 +1057,39 @@ If `last_state_recalculation_slot % POW_RECEIPT_ROOT_VOTING_PERIOD == 0`, then: | |||
| * If for any `x` in `state.candidate_pow_receipt_root`, `x.votes * 2 >= POW_RECEIPT_ROOT_VOTING_PERIOD` set `state.processed_pow_receipt_root = x.receipt_root`. | |||
| * Set `state.candidate_pow_receipt_roots = []`. | |||
|
|
|||
| ### Validator set change | |||
| #### Proposer reshuffling | |||
There was a problem hiding this comment.
Aah, I think my goal was to move it out of the then-overloaded "Finally" section. We could move it to happen right before Finally if desired. I'm not sure what order is best.
There was a problem hiding this comment.
The order doesn't particularly matter (I think).
The only reason I noticed was -- if we have it before the change validator section then it might produce some ShardReassignmentRecords that immediately get wiped out when removing validators in change_validators.
Again... not a pressing concern
There was a problem hiding this comment.
OK I set the order back to how it was.
|
Not quite ready @JustinDrake ! |
|
@djrtwo Yeah, a bunch of cleanup is required but want to avoid merge conflicts :) |
|
I've been keeping it up to date with master :) |
Co-Authored-By: vbuterin <v@buterin.com>
Co-Authored-By: vbuterin <v@buterin.com>
Co-Authored-By: vbuterin <v@buterin.com>
Co-Authored-By: vbuterin <v@buterin.com>
Co-Authored-By: vbuterin <v@buterin.com>
Co-Authored-By: vbuterin <v@buterin.com>
Co-Authored-By: vbuterin <v@buterin.com>
… objects Makes the code cleaner this way; returning an object that then gets mutated is confusing.
specs/core/0_beacon-chain.md
Outdated
| # Slot of last justified beacon block | ||
| 'justified_slot': 'uint64', | ||
| # Hash of last justified beacon block | ||
| 'justified_block_hash': 'hash32', |
| # Signed data | ||
| 'data': AttestationSignedData, | ||
| # Attester participation bitfield (2 bits per attester) | ||
| 'attester_bitfield': 'bytes', |
There was a problem hiding this comment.
There are two bitfields, attester_bitfield and poc_bitfield. More modular that way 😄
There was a problem hiding this comment.
Ah I sorry, I mean the comment:
# Attester participation bitfield (2 bits per attester)
'attester_bitfield': 'bytes',
# Proof of custody bitfield
'poc_bitfield': 'bytes',Maybe just say "Attester participation bitfield" for attester_bitfield:
# Attester participation bitfield
'attester_bitfield': 'bytes',
# Proof of custody bitfield
'poc_bitfield': 'bytes',
Co-Authored-By: vbuterin <v@buterin.com>
Co-Authored-By: vbuterin <v@buterin.com>
Co-Authored-By: vbuterin <v@buterin.com>
| The following is a function that determines the validators that participated in an attestation: | ||
|
|
||
| ```python | ||
| def get_attestation_participants(state: State, |
Also adjusted constants to keep interest rates and the quadratic leak period the same.
Also, did some simplifications of the cycle calculation procedure. Make the decision to remove automatic registration of a validator as a proposer when they join, because that can just happen on its own due to the reshuffling procedure.