gnosis/lighthouse
1
0
Fork 0
mirror of https://github.com/sigp/lighthouse.git synced 2026-05-01 03:33:47 +00:00
Code Issues Packages Projects Releases Wiki Activity

Interop chain start strategies (#479)

Browse Source 
* Implement more flexible beacon chain genesis

* Fix compile issues from rebase on master

* Rename CLI flag

* Adds initial documentation for TOML files

* Update docs readme

* Add first version of cli_util

* Dont write cache fields in serde

* Tidy cli_util

* Add code to load genesis YAML file

* Move serde_utils out of tests in `types`

* Update logging text

* Fix serde YAML for Fork

* Make yaml hex decoding more strict

* Update deterministic key generate for interop

* Set deposit count on testing genesis state

* Make some fixes for deposit count

* Remove code fragements

* Large restructure of docs

* Tidy docs

* Fix readme link

* Add interop docs

* Tidy README
This commit is contained in:
Paul Hauner
2019-08-06 13:29:27 +10:00
committed by GitHub
parent 0374e31907
commit 845f336a59
31 changed files with 835 additions and 439 deletions
Download Patch File Download Diff File Expand all files Collapse all files

69
docs/README.md Normal file
View File

@@ -0,0 +1,69 @@
# Lighthouse Documentation
_Lighthouse is a work-in-progress. Instructions are provided for running the
client, however these instructions are designed for developers and researchers
working on the project. We do not (yet) provide user-facing functionality._
## Introduction
- [Overview of Ethereum 2.0](serenity.md)
- [Development Environment Setup](env.md)
For client implementers looking to inter-op, see the [Inter-Op
Docs](interop.md).
## Command-line Interface
With the [development environment](env.md) configured, run `cargo build --all
--release` (this can take several minutes on the first build). Then,
navigate to the `target/release/` directory and read the CLI documentation
using:
```
$ ./beacon_node -h
```
The main [`README.md`](../README.md#simple-local-testnet) provides instructions
for running a small, local testnet.
## REST API
The beacon node provides a RESTful HTTP API which serves information about the
Beacon Chain, the P2P network and more.
This API is documented in the [`rest_oapi.yaml`](rest_oapi.yaml) Swagger YAML
file. There's an interactive version hosted on
[SwaggerHub](https://app.swaggerhub.com/apis/spble/lighthouse_rest_api/0.1.0).
The implementation of the Swagger API in Lighthouse is incomplete, we do not
(yet) guarantee that all routes are implemented.
## Configuration Files
Lighthouse uses [TOML](https://github.com/toml-lang/toml) files for
configuration. The following binaries use the following config files (they are
generated from defaults if they don't already exist):
- [Beacon Node](/beacon_node)
- [`~/.lighthouse/beacon_node.toml`](#beacon-nodetoml): the primary
configuration file for a beacon node.
- `~/.lighthouse/eth2-spec.toml`: defines chain-specific "constants" that
define an Ethereum 2.0 network.
- [Validator Client](/validator_client)
- `~/.lighthouse/validator_client.toml`: the primary configuration file for
a validator client.
- `~/.lighthouse/eth2-spec.toml`: defines chain-specific "constants" that
define an Ethereum 2.0 network.
_Note: default directories are shown, CLI flags can be used to override these
defaults._
#### `beacon-node.toml`
A TOML configuration file that defines the behaviour of the beacon node
runtime.
- Located in the `datadir` (default `~/.lighthouse`) as `beacon-node.toml`.
- Created from defaults if not present.
See the [example](config_examples/beacon-node.toml) for more information.

98
docs/config_examples/beacon-node.toml Normal file
View File

@@ -0,0 +1,98 @@
#
# Beacon Node TOML configuration file.
#
# Defines the runtime configuration of a Lighthouse Beacon Node.
#
# The directory where beacon-node specific files will be placed. Includes the
# database and configuration files.
data_dir = ".lighthouse"
# The type of database used. Can be either:
#
# - "disk": LevelDB (almost always desired).
# - "memory": an in-memory hashmap (only used for testing).
db_type = "disk"
# The name of the LevelDB database directory, if any.
db_name = "chain_db"
# If specified, all logs will be written to this file.
log_file = ""
# Defines the Ethereum 2.0 specification set to be used:
#
# - "mainnet": parameters expected to be used for Eth2 mainnet.
# - "minimal": smaller, more efficient parameters used for testing.
spec_constants = "minimal"
#
# The "genesis_state" object defines how the genesis state should be created.
#
# The "RecentGenesis" type assumes that genesis started at the beginning of the
# most-recent 30 minute window (e.g., 08:00, 08:30, 09:00, ...).
[genesis_state]
type = "RecentGenesis"
validator_count = 16
# "Generated" is the same as "RecentGenesis", however allows for manual
# specification of the genesis_time.
#
# [genesis_state]
# type = "Generated"
# validator_count = 16
# genesis_time = 1564620118
# "Yaml" loads a full genesis state from YAML file.
#
# [genesis_state]
# type = "Yaml"
# file = "~/genesis_state.yaml"
#
# P2P networking configuration.
#
[network]
# The directory for storing p2p network related files. E.g., p2p keys, peer
# lists, etc.
network_dir = "/home/paul/.lighthouse/network"
# The address that libp2p should use for incoming connections.
listen_address = "127.0.0.1"
# The port that libp2p should use for incoming connections.
libp2p_port = 9000
# The address that should listen for UDP peer-discovery.
discovery_address = "127.0.0.1"
# The port that should listen for UDP peer-discovery.
discovery_port = 9000
# Maximum number of libp2p peers.
max_peers = 10
# Boot nodes for initial peer discovery.
boot_nodes = []
# The client version, may be customized.
client_version = "Lighthouse/v0.1.0-unstable/x86_64-linux"
# A list of libp2p topics. Purpose unknown.
topics = []
#
# gRPC configuration. To be removed.
#
[rpc]
enabled = false
listen_address = "127.0.0.1"
port = 5051
#
# Legacy HTTP server configuration. To be removed.
#
[http]
enabled = false
listen_address = "127.0.0.1"
listen_port = "5052"
#
# RESTful HTTP API server configuration.
#
[rest_api]
# Set to `true` to enable the gRPC server.
enabled = true
# The listen port for the HTTP server.
listen_address = "127.0.0.1"
# The listen port for the HTTP server.
port = 1248

52
docs/env.md Normal file
View File

@@ -0,0 +1,52 @@
# Development Environment Setup
_This document describes how to setup a development environment. It is intended
for software developers and researchers who wish to contribute to development._
Lighthouse is a Rust project and [`cargo`](https://doc.rust-lang.org/cargo/) is
used extensively. As such, you'll need to install Rust in order to build the
project. Generally, Rust is installed using the
[rustup](https://www.rust-lang.org/tools/install) tool-chain manager.
## Steps
A fully-featured development environment can be achieved with the following
steps:
1. Install [rustup](https://rustup.rs/).
1. Use the command `rustup show` to get information about the Rust
installation. You should see that the active tool-chain is the stable
version.
- Updates can be performed using` rustup update`, Lighthouse generally
requires a recent version of Rust.
1. Install build dependencies (Arch packages are listed here, your
distribution will likely be similar):
- `clang`: required by RocksDB.
- `protobuf`: required for protobuf serialization (gRPC).
- `cmake`: required for building protobuf
- `git-lfs`: The Git extension for [Large File
Support](https://git-lfs.github.com/) (required for Ethereum Foundation
test vectors).
1. Clone the repository with submodules: `git clone --recursive
https://github.com/sigp/lighthouse`. If you're already cloned the repo,
ensure testing submodules are present: `$ git submodule init; git
submodule update`
1. Change directory to the root of the repository.
1. Run the test suite with `cargo test --all --release`. The build and test
process can take several minutes. If you experience any failures on
`master`, please raise an
[issue](https://github.com/sigp/lighthouse/issues).
## Notes:
Lighthouse targets Rust `stable` but generally runs on `nightly` too.
### Note for Windows users:
Perl may also be required to build lighthouse. You can install [Strawberry
Perl](http://strawberryperl.com/), or alternatively use a choco install command
`choco install strawberryperl`.
Additionally, the dependency `protoc-grpcio v0.3.1` is reported to have issues
compiling in Windows. You can specify a known working version by editing
version in `protos/Cargo.toml` section to `protoc-grpcio = "<=0.3.0"`.

40
docs/installation.md
View File

@@ -1,40 +0,0 @@
# Development Environment Setup
A few basic steps are needed to get set up (skip to #5 if you already have Rust
installed):
1. Install [rustup](https://rustup.rs/). It's a toolchain manager for Rust (Linux | macOS | Windows). For installation, download the script with `$ curl -f https://sh.rustup.rs > rustup.sh`, review its content (e.g. `$ less ./rustup.sh`) and run the script `$ ./rustup.sh` (you may need to change the permissions to allow execution, i.e. `$ chmod +x rustup.sh`)
2. (Linux & MacOS) To configure your current shell run: `$ source $HOME/.cargo/env`
3. Use the command `rustup show` to get information about the Rust installation. You should see that the
active toolchain is the stable version.
4. Run `rustc --version` to check the installation and version of rust.
- Updates can be performed using` rustup update` .
5. Install build dependencies (Arch packages are listed here, your distribution will likely be similar):
- `clang`: required by RocksDB.
- `protobuf`: required for protobuf serialization (gRPC).
- `cmake`: required for building protobuf
- `git-lfs`: The Git extension for [Large File Support](https://git-lfs.github.com/) (required for EF tests submodule).
6. If you haven't already, clone the repository with submodules: `git clone --recursive https://github.com/sigp/lighthouse`.
Alternatively, run `git submodule init; git submodule update` in a repository which was cloned without submodules.
7. Change directory to the root of the repository.
8. Run the test by using command `cargo test --all --release`. By running, it will pass all the required test cases.
If you are doing it for the first time, then you can grab a coffee in the meantime. Usually, it takes time
to build, compile and pass all test cases. If there is no error then it means everything is working properly
and it's time to get your hands dirty.
In case, if there is an error, then please raise the [issue](https://github.com/sigp/lighthouse/issues).
We will help you.
9. As an alternative to, or instead of the above step, you may also run benchmarks by using
the command `cargo bench --all`
## Notes:
Lighthouse targets Rust `stable` but _should_ run on `nightly`.
### Note for Windows users:
Perl may also be required to build lighthouse. You can install [Strawberry Perl](http://strawberryperl.com/),
or alternatively use a choco install command `choco install strawberryperl`.
Additionally, the dependency `protoc-grpcio v0.3.1` is reported to have issues compiling in Windows. You can specify
a known working version by editing version in protos/Cargo.toml's "build-dependencies" section to
`protoc-grpcio = "<=0.3.0"`.

109
docs/interop.md Normal file
View File

@@ -0,0 +1,109 @@
# Lighthouse Inter-Op Docs
_These documents are intended for a highly technical audience, specifically
Ethereum 2.0 implementers._
This document provides details on how to use Lighthouse for inter-op testing.
## Steps
_Note: binaries are compiled into the `target/release` directory of the
repository. In this example, we run binaries assuming the user is in this
directory. E.g., running the beacon node binary can be achieved with
`$ ./target/release/beacon_node`. Those familiar with `cargo` may use the
equivalent (and more-convenient) `cargo run --release --` commands._
1. Setup a Lighthouse [development environment](env.md).
1. Build all the binaries using `cargo build --all --release`
1. Create default configuration files by running `$ ./beacon_node` and pressing
Ctrl+C after the node has started.
1. Follow the steps in [Genesis](#genesis) to configure the genesis state.
1. Follow the steps in [Networking](#networking) to launch a node with
appropriate networking parameters.
## Genesis
Lighthouse supports the following methods for generating a genesis state:
- [`Yaml`](#yaml): loads the genesis state from some YAML file (recommended
method).
- [`Generated`](#generated): generates a state given a `(validator_count,
genesis_time)`
tuple. _Note: this method is not yet fully specified and the state
generated is almost certainly not identical to other implementations._
- [`RecentGenesis`](#recentgenesis): identical to `Generated`, however the
`genesis_time` is set
to the previous 30-minute window. For example, if a state is generated at
`0845`, the genesis time will be `0830`.
You may configure a `beacon_node` to use one of these methods using the
[`beacon_node.toml`](README.md#beacon-nodetoml). There is a [documented
example](config_examples/) configuration file which includes an example for
each of these methods (see the `genesis_state` object).
### Yaml
This method involves loading a `BeaconState` from a YAML file. We provide
instructions for generating that YAML file and starting from it. If starting
from a pre-existing YAML file, simply skip the generation steps.
#### Generating a YAML file
The [cli_util](/tests/cli_util) generate YAML genesis state files. You can run
`$ ./cli_util genesis_yaml -h` to see documentation. We provide an example to
generate a YAML file with the following properties:
- 10 initial validators, each with [deterministic
keypairs](https://github.com/ethereum/eth2.0-pm/issues/60#issuecomment-512157915).
- The genesis file is stored in `~/.lighthouse/`, the default data directory
(an absolute path must be supplied).
- Genesis time is set to the time when the command is run (it can be customized
with the `-g` flag).
```
$ ./cli_util genesis_yaml -n 10 -f /home/user/.lighthouse/genesis_state.yaml
```
#### Configuring the Beacon Node
Modify the [`beacon-node.toml`](README.md#beacon-nodetoml) file to have the
following `genesiss_state` object (choosing the `file`):
```
[genesis_state]
type = "Yaml"
file = "/home/user/.lighthouse/genesis_state.yaml"
```
### Generated
Modify the [`beacon-node.toml`](README.md#beacon-nodetoml) file to have the
following `genesis_state` object (choosing the `validator_count` and
`genesis_time`):
```
[genesis_state]
type = "Generated"
validator_count = 16
genesis_time = 1564620118
```
### RecentGenesis
Modify the [`beacon-node.toml`](README.md#beacon-nodetoml) file to have the
following `genesis_state` object (choosing the `validator_count`):
```
[genesis_state]
type = "RecentGenesis"
validator_count = 16
```
## Networking
_TODO: provide details on config required to connect to some IP address._
## References
The BLS key generation method used should be identical to [this
implementation](https://github.com/ethereum/eth2.0-pm/issues/60#issuecomment-512157915).

83
docs/lighthouse.md
View File

@@ -1,83 +0,0 @@
# About Lighthouse
## Goals
The purpose of this project is to work alongside the Ethereum community to
implement a secure, trustworthy, open-source Ethereum Serenity client in Rust.
* **Security**: Lighthouse's main goal is to implement everything with a
security-first mindset. The goal is to ensure that all components of lighthouse
are thoroughly tested, checked and secure.
* **Trust** : As Ethereum Serenity is a Proof-of-Stake system, which
involves the interaction of the Ethereum protocol and user funds. Thus, a goal
of Lighthouse is to provide a client that is trustworthy.
All code can be tested and verified the goal of Lighthouse is to provide code
that is trusted.
* **Transparency**: Lighthouse aims at being as transparent as possible. This
goal is for Lighthouse to embrace the open-source community and allow for all
to understand the decisions, direction and changes in all aspects.
* **Error Resilience**: As Lighthouse embraces the "never `panic`" mindset, the
goal is to be resilient to errors that may occur. Providing a client that has
tolerance against errors provides further properties for a secure, trustworthy
client that Lighthouse aims to provide.
In addition to implementing a new client, the project seeks to maintain and
improve the Ethereum protocol wherever possible.
## Ideology
### Never Panic
Lighthouse will be the gateway interacting with the Proof-of-Stake system
employed by Ethereum. This requires the validation and proposal of blocks
and extremely timely responses. As part of this, Lighthouse aims to ensure
the most uptime as possible, meaning minimising the amount of
exceptions and gracefully handling any issues.
Rust's `panic` provides the ability to throw an exception and exit, this
will terminate the running processes. Thus, Lighthouse aims to use `panic`
as little as possible to minimise the possible termination cases.
### Security First Mindset
Lighthouse aims to provide a safe, secure Serenity client for the Ethereum
ecosystem. At each step of development, the aim is to have a security-first
mindset and always ensure you are following the safe, secure mindset. When
contributing to any part of the Lighthouse client, through any development,
always ensure you understand each aspect thoroughly and cover all potential
security considerations of your code.
### Functions aren't completed until they are tested
As part of the Security First mindset, we want to aim to cover as many distinct
cases. A function being developed is not considered "completed" until tests
exist for that function. The tests not only help show the correctness of the
function, but also provide a way for new developers to understand how the
function is to be called and how it works.
## Engineering Ethos
Lighthouse aims to produce many small easily-tested components, each separated
into individual crates wherever possible.
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. Particularly 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 against regression (accidentally breaking things) and to
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 write-access to the repository). This helps to ensure bugs are
detected, consistency is maintained, and responsibility of errors is dispersed.
Discussion must be respectful and intellectual. Have fun and make jokes, but
always respect the limits of other people.

233
docs/onboarding.md
View File

@@ -1,233 +0,0 @@
# Contributing to Lighthouse
[![Gitter](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/sigp/lighthouse?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)
Lighthouse is an open-source Ethereum Serenity client built in
[Rust](https://www.rust-lang.org/).
Lighthouse welcomes all contributions with open arms. If you are interested in
contributing to the Ethereum ecosystem, and you want to learn Rust, Lighthouse
is a great project to work on.
This documentation aims to provide a smooth on-boarding for all who wish to
help contribute to Lighthouse. Whether it is helping with the mountain of
documentation, writing extra tests or developing components, all help is
appreciated and your contributions will help not only the community but all
the contributors.
We've bundled up our Goals, Ethos and Ideology into one document for you to
read through, please read our [About Lighthouse](lighthouse.md) docs. :smile:
Layer-1 infrastructure is a critical component for the ecosystem and relies
heavily on contributions from the community. Building Ethereum Serenity is a
huge task and we refuse to conduct an inappropriate ICO or charge licensing
fees. Instead, we fund development through grants and support from Sigma
Prime.
If you have any additional questions, please feel free to jump on the
[gitter](https://gitter.im/sigp/lighthouse) and have a chat with all of us.
**Pre-reading Materials:**
* [About Lighthouse](lighthouse.md)
* [Ethereum Serenity](serenity.md)
**Repository**
If you'd like to contribute, try having a look through the [open
issues](https://github.com/sigp/lighthouse/issues) (tip: look for the [good
first
issue](https://github.com/sigp/lighthouse/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)
tag) and ping us on the [gitter](https://gitter.im/sigp/lighthouse) channel. We need
your support!
## Understanding Serenity
Ethereum's Serenity is based on a Proof-of-Stake based sharded beacon chain.
(*If you don't know what that is, don't `panic`, that's what this documentation
is for!* :smile:)
Read through our [Understanding
Serenity](https://github.com/sigp/lighthouse/blob/master/docs/serenity.md) docs
to learn more! :smile: (*unless you've already read it.*)
The document explains the necessary fundamentals for understanding Ethereum,
Proof-of-Stake and the Serenity we are working towards.
## Development Onboarding
If you would like to contribute and develop Lighthouse, there are only a few
things to go through (and then you're on your way!).
### Understanding Rust
Rust is an extremely powerful, low-level programming language that provides
freedom and performance to create powerful projects. The [Rust
Book](https://doc.rust-lang.org/stable/book/) provides insight into the Rust
language and some of the coding style to follow (As well as acting as a great
introduction and tutorial for the language.)
Rust has a steep learning curve, but there are many resources to help you!
* [Rust Book](https://doc.rust-lang.org/stable/book/)
* [Rust by example](https://doc.rust-lang.org/stable/rust-by-example/)
* [Learning Rust With Entirely Too Many Linked Lists](http://cglab.ca/~abeinges/blah/too-many-lists/book/)
* [Rustlings](https://github.com/rustlings/rustlings)
* [Rust Exercism](https://exercism.io/tracks/rust)
* [Learn X in Y minutes - Rust](https://learnxinyminutes.com/docs/rust/)
#### Getting Started and installing Rust
We recommend installing Rust using [**rustup**](https://rustup.rs/). Rustup
allows you to easily install versions of rust.
**Linux/Unix/Mac:**
```
$ curl https://sh.rustup.rs -sSf | sh
```
**Windows (You need a bit more):**
* Install the Visual Studio 2015 with C++ support
* Install Rustup using: https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-msvc/rustup-init.exe
* You can then use the ``VS2015 x64 Native Tools Command Prompt`` and run:
```
rustup default stable-x86-64-pc-windows-msvc
```
#### Getting ready with Cargo
[Cargo](https://doc.rust-lang.org/cargo/) is the package manager for Rust, and
allows to extend to a number of packages and external libraries. It's also extremely
handy for handling dependencies and helping to modularise your project better.
*Note: If you've installed rust through rustup, you should have ``cargo``
installed.*
#### Rust Terminology
When developing rust, you'll come across some terminology that differs to
other programming languages you may have used.
* **Trait**: A trait is a collection of methods defined for a type, they can be
implemented for any data type.
* **Struct**: A custom data type that lets us name and package together
multiple related values that make a meaningful group.
* **Crate**: A crate is synonymous with a *library* or *package* in other
languages. They can produce an executable or library depending on the
project.
* **Module**: A collection of items: functions, structs, traits, and even other
modules. Modules allow you to hierarchically split code into logical units
and manage visibility.
* **Attribute**: Metadata applied to some module, crate or item.
* **Macros**: Macros are powerful meta-programming statements that get expanded
into source code that gets compiled with the rest of the code (Unlike `C`
macros that are pre-processed, Rust macros form an Abstract Syntax Tree).
Other good appendix resources:
* [Keywords](https://doc.rust-lang.org/book/appendix-01-keywords.html)
* [Operators/Symbols](https://doc.rust-lang.org/book/appendix-02-operators.html)
* [Traits](https://doc.rust-lang.org/book/appendix-03-derivable-traits.html)
### Understanding the Git Workflow
Lighthouse utilises git as the primary open-source development tool. To help
with your contributions, it is great to understand the processes used to ensure
everything remains in sync and there's as little conflict as possible when
working on similar files.
Lighthouse uses the **feature branch** workflow, where each issue, or each
feature, is developed on its own branch and then merged in via a pull-request.
* [Feature Branch Tutorial](https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow)
## Code Conventions/Styleguide and Ethos
### Ethos
**Pull Requests**
Pull requests should be reviewed by **at least** one "*core developer*"
(someone with write-access to the repo). This should ensure bugs are caught and
the code is kept in a consistent state that follows all conventions and style.
All discussion (whether in PRs or Issues or in the Gitter) should be respectful
and intellectual. Have fun, but always respect the limits of other people.
**Testing**
*"A function is not considered complete until tests exist for it."*
Generally, tests can be self-contained in the same file. Integration tests
should be added into the ``tests/`` directory in the crate's **root**.
Large line-count tests should be in a separate file.
### Rust StyleGuide
Lighthouse adheres to Rust code conventions as outlined in the [**Rust
Styleguide**](https://github.com/rust-dev-tools/fmt-rfcs/blob/master/guide/guide.md).
Ensure you use [Clippy](https://github.com/rust-lang/rust-clippy) to lint and
check your code.
| Code Aspect | Guideline Format |
|:--------------------|:-------------------------------|
| Types | ``UpperCamelCase`` |
| Enums/Enum Variants | ``UpperCamelCase`` |
| Struct Fields | ``snake_case`` |
| Function / Method | ``snake_case`` |
| Macro Names | ``snake_case`` |
| Constants | ``SCREAMING_SNAKE_CASE`` |
| Forbidden name | Trailing Underscore: ``name_`` |
Other general rust docs:
* [Rust Other Style Advice](https://github.com/rust-dev-tools/fmt-rfcs/blob/master/guide/advice.md)
* [Cargo.toml Conventions](https://github.com/rust-dev-tools/fmt-rfcs/blob/master/guide/cargo.md)
### TODOs
All `TODO` statements should be accompanied by a GitHub issue.
```rust
pub fn my_function(&mut self, _something &[u8]) -> Result<String, Error> {
// TODO: something_here
// https://github.com/sigp/lighthouse/issues/XX
}
```
### Comments
**General Comments**
* Prefer line (``//``) comments to block comments (``/* ... */``)
* Comments can appear on the line prior to the item or after a trailing space.
```rust
// Comment for this struct
struct Lighthouse {}
fn make_blockchain() {} // A comment on the same line after a space
```
**Doc Comments**
* The ``///`` is used to generate comments for Docs.
* The comments should come before attributes.
```rust
/// Stores the core configuration for this Lighthouse instance.
/// This struct is general, other components may implement more
/// specialized config structs.
#[derive(Clone)]
pub struct LighthouseConfig {
pub data_dir: PathBuf,
pub p2p_listen_port: u16,
}
```