cerc-io/lighthouse
16
0
Fork 0
Code Issues 1 Pull Requests Packages Projects Releases Wiki Activity
Ethereum consensus client in Rust
4,356 Commits 2 Branches 0 Tags 125 MiB
Rust 99.5%
Shell 0.2%
Makefile 0.1%
5a0b049049
Go to file
Paul Hauner 5a0b049049 Avoid hogging the fallback status lock in the VC (#3022) 
## Issue Addressed

Addresses https://github.com/sigp/lighthouse/issues/2926

## Proposed Changes

Appropriated from https://github.com/sigp/lighthouse/issues/2926#issuecomment-1039676768:

When a node returns *any* error we call [`CandidateBeaconNode::set_offline`](c3a793fd73/validator_client/src/beacon_node_fallback.rs (L424)) which sets it's `status` to `CandidateError::Offline`. That node will then be ignored until the routine [`fallback_updater_service`](c3a793fd73/validator_client/src/beacon_node_fallback.rs (L44)) manages to reconnect to it.

However, I believe there was an issue in the [`CanidateBeaconNode::refesh_status`](c3a793fd73/validator_client/src/beacon_node_fallback.rs (L157-L178)) method, which is used by the updater service to see if the node has come good again. It was holding a [write lock on the `status` field](c3a793fd73/validator_client/src/beacon_node_fallback.rs (L165)) whilst it polled the node status. This means a long timeout would hog the write lock and starve other processes.

When a VC is trying to access a beacon node for whatever purpose (getting duties, posting blocks, etc), it performs [three passes](c3a793fd73/validator_client/src/beacon_node_fallback.rs (L432-L482)) through the lists of nodes, trying to run some generic `function` (closure, lambda, etc) on each node:

- 1st pass: only try running `function` on all nodes which are both synced and online.
- 2nd pass: try running `function` on all nodes that are online, but not necessarily synced.
- 3rd pass: for each offline node, try refreshing its status and then running `function` on it.

So, it turns out that if the `CanidateBeaconNode::refesh_status` function from the routine update service is hogging the write-lock, the 1st pass gets blocked whilst trying to read the status of the first node. So, nodes that should be left until the 3rd pass are blocking the process of the 1st and 2nd passes, hence the behaviour described in #2926.

## Additional Info

NA
2022-02-22 03:09:00 +00:00
.github Increase Bors timeout, refine target-branch-check (#3035) 2022-02-21 23:21:03 +00:00
account_manager Allow per validator fee recipient via flag or file in validator client (similar to graffiti / graffiti-file) (#2924) 2022-02-08 19:52:20 +00:00
beacon_node Add API to compute block packing efficiency data (#2879) 2022-02-21 23:21:02 +00:00
book Update block reward API docs (#3013) 2022-02-11 11:02:09 +00:00
boot_node v2.1.3 (#3017) 2022-02-11 01:54:33 +00:00
common Add API to compute block packing efficiency data (#2879) 2022-02-21 23:21:02 +00:00
consensus Use SmallVec in Bitfield (#3025) 2022-02-17 23:55:04 +00:00
crypto Lazy hashing for SignedBeaconBlock in sync (#2916) 2022-01-14 07:20:54 +00:00
lcli v2.1.3 (#3017) 2022-02-11 01:54:33 +00:00
lighthouse Engine API v1.0.0.alpha.6 + interop tests (#3024) 2022-02-17 21:47:06 +00:00
scripts local testnet: Fix an error on startup (#2973) 2022-01-31 22:55:06 +00:00
slasher Additional networking metrics (#2549) 2021-12-22 06:17:14 +00:00
testing Engine API v1.0.0.alpha.6 + interop tests (#3024) 2022-02-17 21:47:06 +00:00
validator_client Avoid hogging the fallback status lock in the VC (#3022) 2022-02-22 03:09:00 +00:00
.dockerignore Update spec tests to v1.1.0-beta.4 (#2548) 2021-09-25 05:58:35 +00:00
.editorconfig Add editorconfig template 2019-03-11 15:09:57 +11:00
.gitignore Delete uncompressed genesis states (#2092) 2020-12-16 03:44:05 +00:00
.gitmodules Replace EF tests submodule with a makefile 2019-09-08 04:19:54 +10:00
bors.toml Increase Bors timeout, refine target-branch-check (#3035) 2022-02-21 23:21:03 +00:00
Cargo.lock Add API to compute block packing efficiency data (#2879) 2022-02-21 23:21:02 +00:00
Cargo.toml Engine API v1.0.0.alpha.6 + interop tests (#3024) 2022-02-17 21:47:06 +00:00
CONTRIBUTING.md Update CONTRIBUTING.md (#751) 2020-01-03 10:45:53 +11:00
Cross.toml Optimise slasher DB layout and switch to MDBX (#2776) 2021-12-21 08:23:17 +00:00
Dockerfile Optimized Docker images (#2966) 2022-01-31 22:55:03 +00:00
Dockerfile.cross Update docker images to Ubuntu latest (#2862) 2021-12-15 07:44:44 +00:00
LICENSE Update License to Apache 2.0 2019-04-15 16:47:35 +10:00
Makefile Engine API v1.0.0.alpha.6 + interop tests (#3024) 2022-02-17 21:47:06 +00:00
README.md Remove gitter from readme (#2914) 2022-01-14 04:07:17 +00:00
SECURITY.md Add how users should report security vulnerabilities for this repository (#2562) 2021-09-07 01:54:05 +00:00

README.md

Lighthouse: Ethereum 2.0

An open-source Ethereum 2.0 client, written in Rust and maintained by Sigma Prime.

Build Status Book Status Chat Badge

Documentation

Banner

Overview

Lighthouse is:

  • Ready for use on Eth2 mainnet.
  • Fully open-source, licensed under Apache 2.0.
  • Security-focused. Fuzzing techniques have been continuously applied and several external security reviews have been performed.
  • Built in Rust, a modern language providing unique safety guarantees and excellent performance (comparable to C++).
  • Funded by various organisations, including Sigma Prime, the Ethereum Foundation, ConsenSys, the Decentralization Foundation and private individuals.
  • Actively involved in the specification and security analysis of the Ethereum 2.0 specification.

Eth2 Deposit Contract

The Lighthouse team acknowledges 0x00000000219ab540356cBB839Cbe05303d7705Fa as the canonical Eth2 deposit contract address.

Documentation

The Lighthouse Book contains information for users and developers.

The Lighthouse team maintains a blog at lighthouse.sigmaprime.io which contains periodical progress updates, roadmap insights and interesting findings.

Branches

Lighthouse maintains two permanent branches:

  • stable: Always points to the latest stable release.
    • This is ideal for most users.
  • unstable: Used for development, contains the latest PRs.
    • Developers should base their PRs on this branch.

Contributing

Lighthouse welcomes contributors.

If you are looking to contribute, please head to the Contributing section of the Lighthouse book.

Contact

The best place for discussion is the Lighthouse Discord server.

Sign up to the Lighthouse Development Updates mailing list for email notifications about releases, network status and other important information.

Encrypt sensitive messages using our PGP key.

Donations

Lighthouse is an open-source project and a public good. Funding public goods is hard and we're grateful for the donations we receive from the community via:

  • Gitcoin Grants.
  • Ethereum address: 0x25c4a76E7d118705e7Ea2e9b7d8C59930d8aCD3b (donation.sigmaprime.eth).