Go to file
Michael Sproul 371c216ac3 Use read_recursive locks in database (#2417)
## Issue Addressed

Closes #2245

## Proposed Changes

Replace all calls to `RwLock::read` in the `store` crate with `RwLock::read_recursive`.

## Additional Info

* Unfortunately we can't run the deadlock detector on CI because it's pinned to an old Rust 1.51.0 nightly which cannot compile Lighthouse (one of our deps uses `ptr::addr_of!` which is too new). A fun side-project at some point might be to update the deadlock detector.
* The reason I think we haven't seen this deadlock (at all?) in practice is that _writes_ to the database's split point are quite infrequent, and a concurrent write is required to trigger the deadlock. The split point is only written when finalization advances, which is once per epoch (every ~6 minutes), and state reads are also quite sporadic. Perhaps we've just been incredibly lucky, or there's something about the timing of state reads vs database migration that protects us.
* I wrote a few small programs to demo the deadlock, and the effectiveness of the `read_recursive` fix: https://github.com/michaelsproul/relock_deadlock_mvp
* [The docs for `read_recursive`](https://docs.rs/lock_api/0.4.2/lock_api/struct.RwLock.html#method.read_recursive) warn of starvation for writers. I think in order for starvation to occur the database would have to be spammed with so many state reads that it's unable to ever clear them all and find time for a write, in which case migration of states to the freezer would cease. If an attack could be performed to trigger this starvation then it would likely trigger a deadlock in the current code, and I think ceasing migration is preferable to deadlocking in this extreme situation. In practice neither should occur due to protection from spammy peers at the network layer. Nevertheless, it would be prudent to run this change on the testnet nodes to check that it doesn't cause accidental starvation.
2021-07-12 07:31:26 +00:00
.github Altair consensus changes and refactors (#2279) 2021-07-09 06:15:32 +00:00
account_manager Adjust beacon node timeouts for validator client HTTP requests (#2352) 2021-07-12 01:47:48 +00:00
beacon_node Use read_recursive locks in database (#2417) 2021-07-12 07:31:26 +00:00
book Update testnet-validator.md (#2432) 2021-07-09 04:44:56 +00:00
boot_node Altair consensus changes and refactors (#2279) 2021-07-09 06:15:32 +00:00
common Adjust beacon node timeouts for validator client HTTP requests (#2352) 2021-07-12 01:47:48 +00:00
consensus Altair consensus changes and refactors (#2279) 2021-07-09 06:15:32 +00:00
crypto Altair consensus changes and refactors (#2279) 2021-07-09 06:15:32 +00:00
lcli Altair consensus changes and refactors (#2279) 2021-07-09 06:15:32 +00:00
lighthouse Adjust beacon node timeouts for validator client HTTP requests (#2352) 2021-07-12 01:47:48 +00:00
remote_signer Altair consensus changes and refactors (#2279) 2021-07-09 06:15:32 +00:00
scripts Altair consensus changes and refactors (#2279) 2021-07-09 06:15:32 +00:00
slasher rust 1.53.0 updates (#2411) 2021-06-18 05:58:01 +00:00
testing Adjust beacon node timeouts for validator client HTTP requests (#2352) 2021-07-12 01:47:48 +00:00
validator_client Adjust beacon node timeouts for validator client HTTP requests (#2352) 2021-07-12 01:47:48 +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 Add Windows to Bors config (#2358) 2021-05-20 00:23:08 +00:00
Cargo.lock Altair consensus changes and refactors (#2279) 2021-07-09 06:15:32 +00:00
Cargo.toml Improve compilation error on 32-bit (#2424) 2021-06-30 04:56:22 +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 Update outdated dependencies (#2425) 2021-07-05 00:54:17 +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 Altair consensus changes and refactors (#2279) 2021-07-09 06:15:32 +00:00
README.md Fix readme typo (#2312) 2021-04-14 02:30: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 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. 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).