File formatting change, fixing long lines and adding minor adjustments.
This commit is contained in:
parent
d55448946f
commit
9cefeadef1
140
README.md
140
README.md
@ -2,8 +2,8 @@
|
|||||||
|
|
||||||
[](https://travis-ci.org/sigp/lighthouse) [](https://gitter.im/sigp/lighthouse?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)
|
[](https://travis-ci.org/sigp/lighthouse) [](https://gitter.im/sigp/lighthouse?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)
|
||||||
|
|
||||||
A work-in-progress, open-source implementation of the Ethereum 2.0 Beacon Chain, maintained
|
A work-in-progress, open-source implementation of the Ethereum 2.0 Beacon
|
||||||
by Sigma Prime.
|
Chain, maintained by Sigma Prime.
|
||||||
|
|
||||||
## Introduction
|
## Introduction
|
||||||
|
|
||||||
@ -19,24 +19,24 @@ If you'd like some background on Sigma Prime, please see the [Lighthouse Update
|
|||||||
|
|
||||||
## Lighthouse Client
|
## Lighthouse Client
|
||||||
|
|
||||||
Lighthouse is an open-source Ethereum 2.0 client that is currently under development.
|
Lighthouse is an open-source Ethereum 2.0 client that is currently under
|
||||||
Designed as an Ethereum 2.0-only client, Lighthouse will not re-implement the existing
|
development. Designed as an Ethereum 2.0-only client, Lighthouse will not
|
||||||
proof-of-work protocol. Maintaining a forward-focus on Ethereum 2.0 ensures
|
re-implement the existing proof-of-work protocol. Maintaining a forward-focus
|
||||||
that Lighthouse avoids reproducing the high-quality work already undertaken
|
on Ethereum 2.0 ensures that Lighthouse avoids reproducing the high-quality
|
||||||
by existing projects. As such, Lighthouse will
|
work already undertaken by existing projects. As such, Lighthouse will connect
|
||||||
connect to existing clients, such as
|
to existing clients, such as
|
||||||
[Geth](https://github.com/ethereum/go-ethereum) or
|
[Geth](https://github.com/ethereum/go-ethereum) or
|
||||||
[Parity-Ethereum](https://github.com/paritytech/parity-ethereum), via RPC to enable
|
[Parity-Ethereum](https://github.com/paritytech/parity-ethereum), via RPC to enable
|
||||||
present-Ethereum functionality.
|
present-Ethereum functionality.
|
||||||
|
|
||||||
### Goals
|
### Goals
|
||||||
|
|
||||||
The purpose of this project is to further research and development towards a secure,
|
The purpose of this project is to further research and development towards a
|
||||||
efficient, and decentralized Ethereum protocol, facilitated by a new open-source
|
secure, efficient, and decentralized Ethereum protocol, facilitated by a new
|
||||||
Ethereum 2.0 client.
|
open-source Ethereum 2.0 client.
|
||||||
|
|
||||||
In addition to implementing a new client, the project seeks to maintain and improve
|
In addition to implementing a new client, the project seeks to maintain and
|
||||||
the Ethereum protocol wherever possible.
|
improve the Ethereum protocol wherever possible.
|
||||||
|
|
||||||
### Components
|
### Components
|
||||||
|
|
||||||
@ -45,30 +45,32 @@ by the team:
|
|||||||
|
|
||||||
- **BLS cryptography**: Lighthouse presently use the [Apache
|
- **BLS cryptography**: Lighthouse presently use the [Apache
|
||||||
Milagro](https://milagro.apache.org/) cryptography library to create and
|
Milagro](https://milagro.apache.org/) cryptography library to create and
|
||||||
verify BLS aggregate signatures. BLS signatures are core to Eth 2.0 as they
|
verify BLS aggregate signatures. BLS signatures are core to Eth 2.0 as they
|
||||||
allow the signatures of many validators to be compressed into a constant 96
|
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
|
bytes and efficiently verified. The Lighthouse project is presently
|
||||||
aggregates library](https://github.com/sigp/signature-schemes), gratefully
|
maintaining its own [BLS aggregates
|
||||||
forked from [@lovesh](https://github.com/lovesh).
|
library](https://github.com/sigp/signature-schemes), gratefully forked from
|
||||||
|
[@lovesh](https://github.com/lovesh).
|
||||||
- **DoS-resistant block pre-processing**: Processing blocks in proof-of-stake
|
- **DoS-resistant block pre-processing**: Processing blocks in proof-of-stake
|
||||||
is more resource intensive than proof-of-work. As such, clients need to
|
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,
|
ensure that bad blocks can be rejected as efficiently as possible. At
|
||||||
blocks having 10 million ETH staked can be processed in 0.006 seconds, and
|
present, blocks having 10 million ETH staked can be processed in 0.006
|
||||||
invalid blocks are rejected even more quickly. See
|
seconds, and invalid blocks are rejected even more quickly. See [issue
|
||||||
[issue #103](https://github.com/ethereum/beacon_chain/issues/103) on
|
#103](https://github.com/ethereum/beacon_chain/issues/103) on
|
||||||
[ethereum/beacon_chain](https://github.com/ethereum/beacon_chain).
|
[ethereum/beacon_chain](https://github.com/ethereum/beacon_chain).
|
||||||
.
|
.
|
||||||
- **P2P networking**: Eth 2.0 will likely use the [libp2p
|
- **P2P networking**: Eth 2.0 will likely use the [libp2p
|
||||||
framework](https://libp2p.io/). Lighthouse aims to work alongside
|
framework](https://libp2p.io/). Lighthouse aims to work alongside
|
||||||
[Parity](https://www.parity.io/) to ensure
|
[Parity](https://www.parity.io/) to ensure
|
||||||
[libp2p-rust](https://github.com/libp2p/rust-libp2p) is fit-for-purpose.
|
[libp2p-rust](https://github.com/libp2p/rust-libp2p) is fit-for-purpose.
|
||||||
- **Validator duties** : The project involves development of "validator
|
- **Validator duties** : The project involves development of "validator
|
||||||
services" for users who wish to stake ETH. To fulfill their duties, validators
|
services" for users who wish to stake ETH. To fulfill their duties,
|
||||||
require a consistent view of the chain and the ability to vote upon blocks from both shard
|
validators require a consistent view of the chain and the ability to vote
|
||||||
and beacon chains.
|
upon blocks from both shard and beacon chains.
|
||||||
- **New serialization formats**: Lighthouse is working alongside researchers from the Ethereum Foundation
|
- **New serialization formats**: Lighthouse is working alongside researchers
|
||||||
to develop *simpleserialize*, a purpose-built serialization format for sending
|
from the Ethereum Foundation to develop *simpleserialize* (SSZ), a
|
||||||
information across a network. Check out the [SSZ
|
purpose-built serialization format for sending information across a network.
|
||||||
|
Check out the [SSZ
|
||||||
implementation](https://github.com/sigp/lighthouse/tree/master/beacon_chain/utils/ssz)
|
implementation](https://github.com/sigp/lighthouse/tree/master/beacon_chain/utils/ssz)
|
||||||
and this
|
and this
|
||||||
[research](https://github.com/sigp/serialization_sandbox/blob/report/report/serialization_report.md)
|
[research](https://github.com/sigp/serialization_sandbox/blob/report/report/serialization_report.md)
|
||||||
@ -79,8 +81,8 @@ select a canonical chain in the case of a fork.
|
|||||||
- **Efficient state transition logic**: State transition logic governs
|
- **Efficient state transition logic**: State transition logic governs
|
||||||
updates to the validator set as validators log in/out, penalizes/rewards
|
updates to the validator set as validators log in/out, penalizes/rewards
|
||||||
validators, rotates validators across shards, and implements other core tasks.
|
validators, rotates validators across shards, and implements other core tasks.
|
||||||
- **Fuzzing and testing environments**: Implementation of lab
|
- **Fuzzing and testing environments**: Implementation of lab environments with
|
||||||
environments with continuous integration (CI) workflows, providing automated security analysis.
|
continuous integration (CI) workflows, providing automated security analysis.
|
||||||
|
|
||||||
In addition to these components we are also working on database schemas, RPC
|
In addition to these components we are also working on database schemas, RPC
|
||||||
frameworks, specification development, database optimizations (e.g.,
|
frameworks, specification development, database optimizations (e.g.,
|
||||||
@ -91,9 +93,9 @@ bloom-filters), and tons of other interesting stuff (at least we think so).
|
|||||||
**Lighthouse welcomes contributors with open-arms.**
|
**Lighthouse welcomes contributors with open-arms.**
|
||||||
|
|
||||||
Layer-1 infrastructure is a critical component for the ecosystem and relies
|
Layer-1 infrastructure is a critical component for the ecosystem and relies
|
||||||
heavily on contributions from the community. Building Ethereum 2.0 is a huge task and we
|
heavily on contributions from the community. Building Ethereum 2.0 is a huge
|
||||||
refuse to conduct an inappropriate ICO or charge licensing fees. Instead, we
|
task and we refuse to conduct an inappropriate ICO or charge licensing fees.
|
||||||
fund development through grants and support from Sigma Prime.
|
Instead, we fund development through grants and support from Sigma Prime.
|
||||||
|
|
||||||
If you would like to learn more about Ethereum 2.0 and/or
|
If you would like to learn more about Ethereum 2.0 and/or
|
||||||
[Rust](https://www.rust-lang.org/), we are more than happy to on-board you
|
[Rust](https://www.rust-lang.org/), we are more than happy to on-board you
|
||||||
@ -117,9 +119,9 @@ your support!
|
|||||||
**NOTE: The cryptography libraries used in this implementation are
|
**NOTE: The cryptography libraries used in this implementation are
|
||||||
experimental. As such all cryptography is assumed to be insecure.**
|
experimental. As such all cryptography is assumed to be insecure.**
|
||||||
|
|
||||||
This code-base is still very much under-development and does not provide any user-facing
|
This code-base is still very much under-development and does not provide any
|
||||||
functionality. For developers and researchers, there are several tests and benchmarks
|
user-facing functionality. For developers and researchers, there are several
|
||||||
which may be of interest.
|
tests and benchmarks which may be of interest.
|
||||||
|
|
||||||
To run tests, use:
|
To run tests, use:
|
||||||
|
|
||||||
@ -142,16 +144,18 @@ Lighthouse aims to produce many small easily-tested components, each separated
|
|||||||
into individual crates wherever possible.
|
into individual crates wherever possible.
|
||||||
|
|
||||||
Generally, tests can be kept in the same file, as is typical in Rust.
|
Generally, tests can be kept in the same file, as is typical in Rust.
|
||||||
Integration tests should be placed in the `tests` directory in the crate's root.
|
Integration tests should be placed in the `tests` directory in the crate's
|
||||||
Particularity large (line-count) tests should be placed into a separate file.
|
root. Particularity large (line-count) tests should be placed into a separate
|
||||||
|
file.
|
||||||
|
|
||||||
A function is not considered complete until a test exists for it. We produce tests to protect
|
A function is not considered complete until a test exists for it. We produce
|
||||||
against regression (accidentally breaking things) and to provide examples that
|
tests to protect against regression (accidentally breaking things) and to
|
||||||
help readers of the code base understand how functions should (or should not) be used.
|
provide examples that help readers of the code base understand how functions
|
||||||
|
should (or should not) be used.
|
||||||
|
|
||||||
Each pull request is to be reviewed by at least one "core developer" (i.e., someone with
|
Each pull request is to be reviewed by at least one "core developer" (i.e.,
|
||||||
write-access to the repository). This helps to ensure bugs are detected, consistency is maintained,
|
someone with write-access to the repository). This helps to ensure bugs are
|
||||||
and responsibility of errors is dispersed.
|
detected, consistency is maintained, and responsibility of errors is dispersed.
|
||||||
|
|
||||||
Discussion must be respectful and intellectual. Have fun and make jokes, but
|
Discussion must be respectful and intellectual. Have fun and make jokes, but
|
||||||
always respect the limits of other people.
|
always respect the limits of other people.
|
||||||
@ -174,19 +178,20 @@ Ping @paulhauner or @AgeManning to get the quickest response.
|
|||||||
|
|
||||||
# What is Ethereum 2.0
|
# What is Ethereum 2.0
|
||||||
|
|
||||||
Ethereum 2.0 refers to a new blockchain system currently under development
|
Ethereum 2.0 refers to a new blockchain system currently under development by
|
||||||
by the Ethereum Foundation and the Ethereum community. The Ethereum 2.0 blockchain
|
the Ethereum Foundation and the Ethereum community. The Ethereum 2.0 blockchain
|
||||||
consists of 1,025 proof-of-stake blockchains. This includes the "beacon chain" and 1,024
|
consists of 1,025 proof-of-stake blockchains. This includes the "beacon chain"
|
||||||
"shard chains".
|
and 1,024 "shard chains".
|
||||||
|
|
||||||
## Beacon Chain
|
## Beacon Chain
|
||||||
|
|
||||||
The concept of a beacon chain differs from existing blockchains, such as Bitcoin and
|
The concept of a beacon chain differs from existing blockchains, such as
|
||||||
Ethereum, in that it doesn't process transactions per se. Instead, it
|
Bitcoin and Ethereum, in that it doesn't process transactions per se. Instead,
|
||||||
maintains a set of bonded (staked) validators and coordinates these to provide
|
it maintains a set of bonded (staked) validators and coordinates these to
|
||||||
services to a static set of *sub-blockchains* (i.e. shards). Each of these shard blockchains
|
provide services to a static set of *sub-blockchains* (i.e. shards). Each of
|
||||||
processes normal transactions (e.g. "Transfer 5 ETH from A to B") in parallel whilst deferring
|
these shard blockchains processes normal transactions (e.g. "Transfer 5 ETH
|
||||||
consensus mechanisms to the beacon chain.
|
from A to B") in parallel whilst deferring consensus mechanisms to the beacon
|
||||||
|
chain.
|
||||||
|
|
||||||
Major services provided by the beacon chain to its shards include the following:
|
Major services provided by the beacon chain to its shards include the following:
|
||||||
|
|
||||||
@ -202,19 +207,20 @@ Major services provided by the beacon chain to its shards include the following:
|
|||||||
|
|
||||||
Shards are analogous to CPU cores - they're a resource where transactions can
|
Shards are analogous to CPU cores - they're a resource where transactions can
|
||||||
execute in series (one-after-another). Presently, Ethereum is single-core and
|
execute in series (one-after-another). Presently, Ethereum is single-core and
|
||||||
can only _fully_ process one transaction at a time. Sharding allows processing of multiple
|
can only _fully_ process one transaction at a time. Sharding allows processing
|
||||||
transactions simultaneously, greatly increasing the per-second
|
of multiple transactions simultaneously, greatly increasing the per-second
|
||||||
transaction capacity of Ethereum.
|
transaction capacity of Ethereum.
|
||||||
|
|
||||||
Each shard uses a proof-of-stake consensus mechanism and shares its validators (stakers) with other
|
Each shard uses a proof-of-stake consensus mechanism and shares its validators
|
||||||
shards. The beacon chain rotates validators pseudo-randomly between different shards.
|
(stakers) with other shards. The beacon chain rotates validators
|
||||||
Shards will likely be the basis of layer-2 transaction
|
pseudo-randomly between different shards. Shards will likely be the basis of
|
||||||
processing schemes, however, that is not in scope of this discussion.
|
layer-2 transaction processing schemes, however, that is not in scope of this
|
||||||
|
discussion.
|
||||||
|
|
||||||
## The Proof-of-Work Chain
|
## The Proof-of-Work Chain
|
||||||
|
|
||||||
The present-Ethereum proof-of-work (PoW) chain will host a smart contract that enables accounts to deposit 32
|
The present-Ethereum proof-of-work (PoW) chain will host a smart contract that
|
||||||
ETH, a BLS public key, and some [other
|
enables accounts to deposit 32 ETH, a BLS public key, and some [other
|
||||||
parameters](https://github.com/ethereum/eth2.0-specs/blob/master/specs/casper_sharding_v2.1.md#pow-chain-changes),
|
parameters](https://github.com/ethereum/eth2.0-specs/blob/master/specs/casper_sharding_v2.1.md#pow-chain-changes),
|
||||||
allowing them to become beacon chain validators. Each beacon chain will
|
allowing them to become beacon chain validators. Each beacon chain will
|
||||||
reference a PoW block hash allowing PoW clients to use the beacon chain as a
|
reference a PoW block hash allowing PoW clients to use the beacon chain as a
|
||||||
@ -226,10 +232,10 @@ an active topic of research and their details are yet to be confirmed.
|
|||||||
|
|
||||||
## Ethereum 2.0 Progress
|
## Ethereum 2.0 Progress
|
||||||
|
|
||||||
Ethereum 2.0 is not fully specified and a working implementation does not yet exist. Some
|
Ethereum 2.0 is not fully specified and a working implementation does not yet
|
||||||
teams have demos available which indicate progress, but do not constitute a complete product.
|
exist. Some teams have demos available which indicate progress, but do not
|
||||||
We look forward to providing user functionality once we are ready to provide a
|
constitute a complete product. We look forward to providing user functionality
|
||||||
minimum-viable user experience.
|
once we are ready to provide a minimum-viable user experience.
|
||||||
|
|
||||||
The work-in-progress Eth 2.0 specification lives
|
The work-in-progress Eth 2.0 specification lives
|
||||||
[here](https://github.com/ethereum/eth2.0-specs/blob/master/specs/casper_sharding_v2.1.md)
|
[here](https://github.com/ethereum/eth2.0-specs/blob/master/specs/casper_sharding_v2.1.md)
|
||||||
|
Loading…
Reference in New Issue
Block a user