distributed-validator-specs
distributed-validator-specs copied to clipboard
ethereum
Ethereum Distributed Validator Specifications
Use plural Specifications. This matches the repo name which is plural distributed-validator-specs (as well as other repo README such as the consensus-specs).
To allow a better mapping between the Python code and the actual BN APIs, I suggest modifying the `bn_get_genesis_validators_root()` function to return the entire dataset returned by the `/eth/v1/beacon/genesis` API...
I have a question about the term co-validator @adiasg, here are some excerpts that I don't think are consistent. ### from glossary.md ```markdown **Co-Validator**: A threshold BLS public key participating...
This PR builds on PR #17 and is alternative to PR #18. This PR uses that [nagini specification langauge](https://github.com/marcoeilers/nagini/wiki) to express some of the postconditions for the `consensus_on_*` functions.
Currently, the consensus module of a node is expected to communicate with the BN to retrieve the data to propose when the node becomes the leader of the current consensus...
The [Anti-Slashing Measures at the DVC](https://github.com/ethereum/distributed-validator-specs/blob/dev/src/dvspec/README.md#anti-slashing-measures-at-the-dvc) section of the [Ethereum Distributed Validator Specification](https://github.com/ethereum/distributed-validator-specs/blob/dev/src/dvspec/README.md) requires that DVCs initialises its anti-slashing DB to the VC's anti-slashing DB. Currently, the specification is open...
If [nagini](https://github.com/marcoeilers/nagini) is eventually adopted to express pre and postconditions (see PR #20 ), then the documentation must indicate that nagini has been used for specification purposes only. The spec...