Ethereum consensus client in Rust
Go to file
Paul Hauner b06559ae97 Disallow attestation production earlier than head (#2130)
## Issue Addressed

The non-finality period on Pyrmont between epochs [`9114`](https://pyrmont.beaconcha.in/epoch/9114) and [`9182`](https://pyrmont.beaconcha.in/epoch/9182) was contributed to by all the `lighthouse_team` validators going down. The nodes saw excessive CPU and RAM usage, resulting in the system to kill the `lighthouse bn` process. The `Restart=on-failure` directive for `systemd` caused the process to bounce in ~10-30m intervals.

Diagnosis with `heaptrack` showed that the `BeaconChain::produce_unaggregated_attestation` function was calling `store::beacon_state::get_full_state` and sometimes resulting in a tree hash cache allocation. These allocations were approximately the size of the hosts physical memory and still allocated when `lighthouse bn` was killed by the OS.

There was no CPU analysis (e.g., `perf`), but the `BeaconChain::produce_unaggregated_attestation` is very CPU-heavy so it is reasonable to assume it is the cause of the excessive CPU usage, too.

## Proposed Changes

`BeaconChain::produce_unaggregated_attestation` has two paths:

1. Fast path: attesting to the head slot or later.
2. Slow path: attesting to a slot earlier than the head block.

Path (2) is the only path that calls `store::beacon_state::get_full_state`, therefore it is the path causing this excessive CPU/RAM usage.

This PR removes the current functionality of path (2) and replaces it with a static error (`BeaconChainError::AttestingPriorToHead`).

This change reduces the generality of `BeaconChain::produce_unaggregated_attestation` (and therefore [`/eth/v1/validator/attestation_data`](https://ethereum.github.io/eth2.0-APIs/#/Validator/produceAttestationData)), but I argue that this functionality is an edge-case and arguably a violation of the [Honest Validator spec](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/validator.md).

It's possible that a validator goes back to a prior slot to "catch up" and submit some missed attestations. This change would prevent such behaviour, returning an error. My concerns with this catch-up behaviour is that it is:

- Not specified as "honest validator" attesting behaviour.
- Is behaviour that is risky for slashing (although, all validator clients *should* have slashing protection and will eventually fail if they do not).
- It disguises clock-sync issues between a BN and VC.

## Additional Info

It's likely feasible to implement path (2) if we implement some sort of caching mechanism. This would be a multi-week task and this PR gets the issue patched in the short term. I haven't created an issue to add path (2), instead I think we should implement it if we get user-demand.
2021-01-20 06:52:37 +00:00
.github Automate docker version tag (#2150) 2021-01-19 03:50:10 +00:00
account_manager Represent slots in secs instead of millisecs (#2163) 2021-01-19 09:39:51 +00:00
beacon_node Disallow attestation production earlier than head (#2130) 2021-01-20 06:52:37 +00:00
book Update docs: Change --beacon-node to --beacon-nodes (#2145) 2021-01-19 03:50:08 +00:00
boot_node Version v1.0.6 (#2126) 2020-12-28 23:38:02 +00:00
common Represent slots in secs instead of millisecs (#2163) 2021-01-19 09:39:51 +00:00
consensus Represent slots in secs instead of millisecs (#2163) 2021-01-19 09:39:51 +00:00
crypto Clippy 1.49.0 updates and dht persistence test fix (#2156) 2021-01-19 00:34:28 +00:00
lcli Add lcli command to replace state pubkeys (#1999) 2021-01-19 08:42:30 +00:00
lighthouse Represent slots in secs instead of millisecs (#2163) 2021-01-19 09:39:51 +00:00
remote_signer replace tempdir by tempfile (#2143) 2021-01-06 06:36:11 +00:00
scripts Release v0.3.4 (#1894) 2020-11-13 06:06:35 +00:00
slasher Clippy 1.49.0 updates and dht persistence test fix (#2156) 2021-01-19 00:34:28 +00:00
testing Represent slots in secs instead of millisecs (#2163) 2021-01-19 09:39:51 +00:00
validator_client Represent slots in secs instead of millisecs (#2163) 2021-01-19 09:39:51 +00:00
.dockerignore Use OS file locks in validator client (#1958) 2020-11-26 11:25:46 +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 Remove macos tests (#1687) 2020-09-30 01:27:36 +00:00
Cargo.lock Represent slots in secs instead of millisecs (#2163) 2021-01-19 09:39:51 +00:00
Cargo.toml Add slasher broadcast (#2079) 2020-12-16 03:44:01 +00:00
CONTRIBUTING.md Update CONTRIBUTING.md (#751) 2020-01-03 10:45:53 +11:00
Cross.toml Ensure RUSTFLAGS is passed through on cross compile (#1529) 2020-08-17 10:06:06 +00:00
Dockerfile Improve compile time (#1989) 2020-12-09 01:34:58 +00:00
Dockerfile.cross Multiarch docker GitHub actions (#2065) 2020-12-09 06:06:37 +00:00
LICENSE Update License to Apache 2.0 2019-04-15 16:47:35 +10:00
Makefile Remove audit ignore ws server (#2051) 2020-12-06 23:35:51 +00:00
README.md Update PGP key in README (#1986) 2020-11-30 09:28:54 +00:00

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 thier 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. Alternatively, you may use the sigp/lighthouse gitter.

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).