* Avoid abbreviations
* Use `branch` as a more suggestive variable name than `ret`
* Cleanup spacing after comma
* Avoid having two index variables (`index` and `idx`)—Does this break anything?
The spec as written is not valid python -- the generator of the list
comprehension must be iterable.
It looks like the author simply meant to `range` over the intended length.
This commit fixes the missing `range` operator
The beacon chain expects a `uint64` in part to avoid big-int computation.
This commit updates the `Deposit` log so that it broadcasts data of the
appropriate size.
BLS is the name of the signature scheme and BLS12-381 is the name of the
curve that it is defined over. So it is more correct to talk about a
"BLS signature/pubkey" rather than a "BLS12-381 signature/pubkey".
There is an order based on the Vyper deposit contract which should be maintained
here. There is also a reference to it when processing `Deposit` messages.
This commit corrects the order here so all serializations will match.
1. The order of the `deposit_data` serialization does not match the current
Vyper contract. The description now matches that serialization.
2. The `deposit.merkle_tree_index` was not being used (at least explicitly) so
the text now reflects which inputs are to be used for which parameters in the
pseudocode spec that follows.
3. There seems to be a bug where we want the initial leaf to be the `hash` of
the `DepositData`, not the data itself. The text now reflects this requirement.
Returns the Merkle branch for the leaf at index `index`. This getter provides
an alternative way for beacon chain proposers to access the Merkle tree of
deposits rather than being Ethereum 1.0 light clients. The method can be
called on a trusted Ethereum 1.0 archive node at specific past block numbers
to retrieve the Merkle branch needed to register a validator.
The variable name 'slot' in the for-loop in 'get_shuffling' conflicts with the get_shuffling argument name 'slot'. Renames 'slot' in for-loop to 'slot_num'.
In keeping with the rest of the code in this document we adhere to valid Python
where possible.
The custom comparator keyword argument for `sorted` is `key` so this commit
updates its usage when sorting validators by exit order.
This code determines the order in which the next branch element and the
current value should be hashed to produce the parent node in the Merkle tree.
The existing code fails to verify branches constructed in the standard way.
This patch fixes the spec code so that it works properly by using an appropriate
parity calculation.
Example code here to illustrate it working:
https://gist.github.com/ralexstokes/9d82e188bd3286ff74a1fa1dcb5068e0
`EJECTION_BALANCE` is in units of ETH.
`state.validator_balances[index]` is in units of Gwei.
For the ejection computation to work as desired, we need to convert the
`EJECTION_BALANCE` constant from ETH to Gwei.
There should be a correspondence here but referring to the slot is more
explicit, especially for those who are not as familiar with the
details of FFG finalization.
* Make RANDAO into a hash chain (this makes it easy for applications to prove the intermediate RANDAO reveals).
* Include `state.slot` when shuffle to avoid stale shuffles with skip slots
* Cleanup comments related to custody
* Rename "Miscellaneous" to "Custody" in the table of contents
* Use `INITIAL_SLOT_NUMBER` instead of `0` for initial custody slots
* (typo) Fix `second_latest_custody_reseed_slot` => `penultimate_custody_reseed_slot`
* `processed_deposit_root` => `latest_deposit_root`
* `receipt_root` => `deposit_root`
* `receipt_tree` => `deposit_tree`
* Emphasize that deposits are Ethereum 1.0 deposits in text in various places
* `Eth1Deposit` => `Deposit` for consistency (Also happy sticking with `Eth1Deposit` and replacing `deposit_` with `eth1_deposit_` everywhere. This may be unnecessary since Ethereum 2.0 deposits can be distinguished with the `shard_` prefix, e.g. `ShardDeposit` and `shard_deposit`.)
* Clarify `withdrawal_credentials`.
* Clarify that multiple Ethereum 1.0 blocks can have the same deposit root.
Cleanups
* (typo) Remove `get_new_validator_registry_delta_chain_tip` from table of contents
* (typo) Update "Routines for updating validator status" in table of contents
* Update `FAR_FUTURE_SLOT` from `2**63` to `2**64 - 1`
* Put more constants in "Initial values", homogenise
* Cleanup note formatting
* Remove `ZERO_BALANCE_VALIDATOR_TTL` logic (to be possibly reintroduced in phase 2).
* Cleanup `min_empty_validator_index`
* Rename `deposit` to `amount` in `process_deposit` and `DepositData`.
* (typo) Remove new line under `process_penalties_and_exits`
* (typo) "Status codes" => "Status flags" in the table of contents
* (typo) `(state.slot - EPOCH_LENGTH) % LATEST_RANDAO_MIXES_LENGTH` => Use `SEED_LOOKAHEAD` instead.
* Put `state.validator_registry_latest_change_slot = state.slot` in `update_validator_registry`.
* Use `GENESIS_SLOT` for `last_poc_change_slot=0` and `second_last_poc_change_slot=0`.
Bugfixes
* (typo) `validator_exit` => `exit.validator_index`
* Separate initial deposits and initial activations to avoid double activations
* Replace `proposer.status != EXITED_WITH_PENALTY` with `validator.penalized_slot > state.slot` in two different places.
* Replace `status == EXITED_WITH_PENALTY` with `validator.penalized_slot <= state.slot` (and validator active) in two different places.
* Added `activation_slot`, `exit_slot`, `penalized_slot`, `withdrawal_slot`, use these to determine if a validator is active
* Universal min activation/exit delay of 256 slots
* Min exit time of ~1 day, but penalization delays this to ~18 days
* Penalty calculation period of `[time penalized - 18 days, time penalized + 18 days]`; made the total penalties array fixed size and wraparound to make calculation more fine-grained
* Processes withdrawals in all epochs, not just dynasty-changing epochs
* Change `get_shuffling` function to take slot as argument
Not yet done:
* Removed `shard_committees` from the state
* Removed persistent committees from the state
Added `latest_vdf_outputs` in `state` initialised to an array of `ZERO_HASH` of length `LATEST_RANDAO_MIXES_LENGTH // EPOCH_LENGTH`. (There's one VDF output per epoch. The VDF input is the RANDAO mix at the epoch boundary.)
Further changes to activate VDFs (in a future phase):
* Add a new beacon "VDF output and proof" transaction, e.g. with `MAX_VDF_OUTPUT_AND_PROOF := 1`.
* Adjust the `MAX_SEED_LOOKAHEAD` constant, e.g. to `2**4 * EPOCH_LENGTH`. (The `2**4` parameter is essentially `A_max`.)
* Add a `process_vdf_output_and_proof` helper function in the per-block processing:
* Verify the VDF input hasn't already been processed (check the corresponding `state.latest_vdf_outputs` entry is not `ZERO_HASH`.)
* Verify the proof is correct, i.e. matches the VDF input and output
* Save the VDF output to `state.latest_vdf_outputs`
* In the per-epoch processing set the corresponding entry in `state.latest_vdf_outputs` to `ZERO_HASH`.
* Use a VDF output for the shuffling seed.
* Fixes parameters and makes clear that the inactivity leak is on a per-epoch basis (before the leak was technically 64 times too weak as it was calculated per-slot but applied per-epoch)
* Adds a `// 2` to the inactivity leak to compensate for it being applied twice
* Changes how it is calculated (no inactivity leak for not being part of the head, only basic leak)
* Separates out early inclusion incentives into a separate incentive component rather than being multiplicative with everything else
Slight simplification. Only substantive change is that if the validator registry stays constant, we don't reshuffle 3 epochs after the last reshuffling (ie. before the reshufflings happened after 1, 2, 3, 4, 8, 16... epochs, now it's just 1, 2, 4, 8, 16...)
Justin
Ben Edgington
vbuterin
Danny Ryan
jonny rhea
Alex Stokes
terence tsao
Jim Posen
Hsiao-Wei Wang
Akhila Raju
Cayman
Nishant Das
Joseph Delong
Chih Cheng Liang