mirror/lighthouse-pulse
1
0
Fork 0
mirror of https://gitlab.com/pulsechaincom/lighthouse-pulse.git synced 2024-12-22 03:30:38 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
015ab7d0a7
lighthouse-pulse/account_manager
History
Paul Hauner 015ab7d0a7 Optimize validator duties (#2243) 
## Issue Addressed

Closes #2052

## Proposed Changes

- Refactor the attester/proposer duties endpoints in the BN
    - Performance improvements
    - Fixes some potential inconsistencies with the dependent root fields.
    - Removes `http_api::beacon_proposer_cache` and just uses the one on the `BeaconChain` instead.
    - Move the code for the proposer/attester duties endpoints into separate files, for readability.
- Refactor the `DutiesService` in the VC
    - Required to reduce the delay on broadcasting new blocks.
    - Gets rid of the `ValidatorDuty` shim struct that came about when we adopted the standard API.
    - Separate block/attestation duty tasks so that they don't block each other when one is slow.
- In the VC, use `PublicKeyBytes` to represent validators instead of `PublicKey`. `PublicKey` is a legit crypto object whilst `PublicKeyBytes` is just a byte-array, it's much faster to clone/hash `PublicKeyBytes` and this change has had a significant impact on runtimes.
    - Unfortunately this has created lots of dust changes.
 - In the BN, store `PublicKeyBytes` in the `beacon_proposer_cache` and allow access to them. The HTTP API always sends `PublicKeyBytes` over the wire and the conversion from `PublicKey` -> `PublickeyBytes` is non-trivial, especially when queries have 100s/1000s of validators (like Pyrmont).
 - Add the `state_processing::state_advance` mod which dedups a lot of the "apply `n` skip slots to the state" code.
    - This also fixes a bug with some functions which were failing to include a state root as per [this comment](072695284f/consensus/state_processing/src/state_advance.rs (L69-L74)). I couldn't find any instance of this bug that resulted in anything more severe than keying a shuffling cache by the wrong block root.
 - Swap the VC block service to use `mpsc` from `tokio` instead of `futures`. This is consistent with the rest of the code base.
    
~~This PR *reduces* the size of the codebase 🎉~~ It *used* to reduce the size of the code base before I added more comments. 

## Observations on Prymont

- Proposer duties times down from peaks of 450ms to consistent <1ms.
- Current epoch attester duties times down from >1s peaks to a consistent 20-30ms.
- Block production down from +600ms to 100-200ms.

## Additional Info

- ~~Blocked on #2241~~
- ~~Blocked on #2234~~

## TODO

- [x] ~~Refactor this into some smaller PRs?~~ Leaving this as-is for now.
- [x] Address `per_slot_processing` roots.
- [x] Investigate slow next epoch times. Not getting added to cache on block processing?
- [x] Consider [this](072695284f/beacon_node/store/src/hot_cold_store.rs (L811-L812)) in the scenario of replacing the state roots


Co-authored-by: pawan <pawandhananjay@gmail.com>
Co-authored-by: Michael Sproul <michael@sigmaprime.io>
2021-03-17 05:09:57 +00:00
..
src Optimize validator duties (#2243) 2021-03-17 05:09:57 +00:00
Cargo.toml Update to tokio 1.1 (#2172) 2021-02-10 23:29:49 +00:00
README.md Added deterministic keypair generation. 2019-04-08 15:02:11 +10:00

README.md

Lighthouse Account Manager

The account manager (AM) is a stand-alone binary which allows users to generate and manage the cryptographic keys necessary to interact with Ethereum Serenity.

Roles

The AM is responsible for the following tasks:

  • Generation of cryptographic key pairs
    • Must acquire sufficient entropy to ensure keys are generated securely (TBD)
  • Secure storage of private keys
    • Keys must be encrypted while at rest on the disk (TBD)
    • The format is compatible with the validator client
  • Produces messages and transactions necessary to initiate staking on Ethereum 1.x (TPD)

Implementation

The AM is not a service, and does not run continuously, nor does it interact with any running services. It is intended to be executed separately from other Lighthouse binaries and produce files which can be consumed by them.&

Usage

Simply run ./account_manager generate to generate a new random private key, which will be automatically saved to the correct directory.

If you prefer to use our "deterministic" keys for testing purposes, simply run ./accounts_manager generate_deterministic -i <index>, where index is the validator index for the key. This will reliably produce the same key each time and save it to the directory.