mirror/lighthouse-pulse
1
0
Fork 0
mirror of https://gitlab.com/pulsechaincom/lighthouse-pulse.git synced 2024-12-22 11:41:28 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
c1ec46ef85
lighthouse-pulse/README.md
Paul Hauner c1ec46ef85
First pass of docs update
2019-02-13 16:04:10 +11:00

6.6 KiB
Raw Blame History

Lighthouse: an Ethereum Serenity client

Build Status Gitter

A work-in-progress, open-source implementation of the Serenity Beacon Chain, maintained by Sigma Prime.

The "Serenity" project is also known as "Ethereum 2.0" or "Shasper".

Project Structure

The Lighthouse project is managed across four Github repositories:

  • sigp/lighthouse (this repo): The "integration" repository which provides:
    • Project-wide documentation
    • A sub-module for each of the following repos.
    • A landing-page for users and contributors.
    • A triage point for issues.
    • In the future, various other integration tests and orchestration suites.
  • sigp/lighthouse-libs: Contains Rust crates common to the entire Lighthouse project, including:
    • Pure specification logic (e.g., state transitions, etc)
    • SSZ (SimpleSerialize)
    • BLS Signature libraries
  • sigp/lighthouse-beacon: The beacon node binary, responsible for connection to peers across the network and maintaining a view of the Beacon Chain.
  • sigp/lighthouse-validator: The validator client binary, which connects to a beacon node and fulfils the duties of a staked validator (producing and attesting to blocks).

Contributing

We welcome new contributors and greatly appreciate the efforts from existing contributors.

If you'd like to contribute to development on Lighthouse, we'd recommend checking for issues on the lighthouse-libs repo first, then checking the other repositories.

If you don't find anything there, please reach out on the gitter channel.

Additional resources:

Project Summary

Lighthouse is an open-source Ethereum Serenity client that is currently under development. Designed as a Serenity-only client, Lighthouse will not re-implement the existing proof-of-work protocol. Maintaining a forward-focus on Ethereum Serenity ensures that Lighthouse avoids reproducing the high-quality work already undertaken by existing projects. As such, Lighthouse will connect to existing clients, such as Geth or Parity-Ethereum, via RPC to enable present-Ethereum functionality.

Components

The following list describes some of the components actively under development by the team:

  • BLS cryptography: Lighthouse presently use the Apache Milagro cryptography library to create and verify BLS aggregate signatures. BLS signatures are core to Serenity as they allow the signatures of many validators to be compressed into a constant 96 bytes and efficiently verified. The Lighthouse project is presently maintaining its own BLS aggregates library, gratefully forked from @lovesh.
  • DoS-resistant block pre-processing: Processing blocks in proof-of-stake is more resource intensive than proof-of-work. As such, clients need to ensure that bad blocks can be rejected as efficiently as possible. At present, blocks having 10 million ETH staked can be processed in 0.006 seconds, and invalid blocks are rejected even more quickly. See issue #103 on ethereum/beacon_chain.
  • P2P networking: Serenity will likely use the libp2p framework. Lighthouse is working alongside Parity to ensure libp2p-rust is fit-for-purpose.
  • Validator duties : The project involves development of "validator services" for users who wish to stake ETH. To fulfill their duties, validators require a consistent view of the chain and the ability to vote upon blocks from both shard and beacon chains.
  • New serialization formats: Lighthouse is working alongside researchers from the Ethereum Foundation to develop simpleserialize (SSZ), a purpose-built serialization format for sending information across a network. Check out the SSZ implementation and this research on serialization formats for more information.
  • Fork-choice: The current fork choice rule is LMD Ghost, which effectively takes the latest messages and forms the canonical chain using the GHOST mechanism.
  • Efficient state transition logic: State transition logic governs updates to the validator set as validators log in/out, penalizes/rewards validators, rotates validators across shards, and implements other core tasks.
  • Fuzzing and testing environments: Implementation of lab environments with continuous integration (CI) workflows, providing automated security analysis.

In addition to these components we are also working on database schemas, RPC frameworks, specification development, database optimizations (e.g., bloom-filters), and tons of other interesting stuff (at least we think so).

Contact

The best place for discussion is the sigp/lighthouse gitter. Ping @paulhauner or @AgeManning to get the quickest response.

If you'd like some background on Sigma Prime, please see the Lighthouse Update #00 blog post or the company website.

Donations

We accept donations at the following Ethereum address. All donations go towards funding development of Ethereum 2.0.

0x25c4a76E7d118705e7Ea2e9b7d8C59930d8aCD3b

Alternatively, you can contribute via Gitcoin Grant.

We appreciate all contributions to the project.