* 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.
Anton Nashatyrev
Danny Ryan
Hsiao-Wei Wang
terence tsao
Justin
Stan Drozd
Ben Edgington
vbuterin
jonny rhea
Alex Stokes
Jim Posen