e20f64b21a
## Issue Addressed resolves #2129 resolves #2099 addresses some of #1712 unblocks #2076 unblocks #2153 ## Proposed Changes - Updates all the dependencies mentioned in #2129, except for web3. They haven't merged their tokio 1.0 update because they are waiting on some dependencies of their own. Since we only use web3 in tests, I think updating it in a separate issue is fine. If they are able to merge soon though, I can update in this PR. - Updates `tokio_util` to 0.6.2 and `bytes` to 1.0.1. - We haven't made a discv5 release since merging tokio 1.0 updates so I'm using a commit rather than release atm. **Edit:** I think we should merge an update of `tokio_util` to 0.6.2 into discv5 before this release because it has panic fixes in `DelayQueue` --> PR in discv5: https://github.com/sigp/discv5/pull/58 ## Additional Info tokio 1.0 changes that required some changes in lighthouse: - `interval.next().await.is_some()` -> `interval.tick().await` - `sleep` future is now `!Unpin` -> https://github.com/tokio-rs/tokio/issues/3028 - `try_recv` has been temporarily removed from `mpsc` -> https://github.com/tokio-rs/tokio/issues/3350 - stream features have moved to `tokio-stream` and `broadcast::Receiver::into_stream()` has been temporarily removed -> `https://github.com/tokio-rs/tokio/issues/2870 - I've copied over the `BroadcastStream` wrapper from this PR, but can update to use `tokio-stream` once it's merged https://github.com/tokio-rs/tokio/pull/3384 Co-authored-by: realbigsean <seananderson33@gmail.com> |
||
---|---|---|
.. | ||
backend | ||
client | ||
src | ||
tests | ||
Cargo.toml | ||
README.md |
Remote BLS Signer
Overview
Simple HTTP BLS signer service.
This service is designed to be consumed by Ethereum 2.0 clients, looking for a more secure avenue to store their BLS12-381 secret keys, while running their validators in more permisive and/or scalable environments.
One goal of this package is to be standard compliant. There is a current draft for an Ethereum Improvement Proposal (EIP) in progress. Please refer to the roadmap for a list of advanced features.
API
Standard
GET /upcheck
Responses
Success | |
---|---|
Code | 200 |
Content | {"status": "OK"} |
GET /keys
Returns the identifiers of the keys available to the signer.
Responses
Success | |
---|---|
Code | 200 |
Content | {"keys": "[identifier]"} |
POST /sign/:identifier
URL Parameter | |
---|---|
:identifier |
public_key_hex_string_without_0x |
Request
JSON Body | ||
---|---|---|
bls_domain |
Required | The BLS Signature domain. As defined in the specification, in lowercase, omitting the domain prefix.Supporting beacon_proposer , beacon_attester , and randao . |
data |
Required | The data to be signed. As defined in the specifications for block, attestation, and epoch. |
fork |
Required | A Fork object containing previous and current versions.As defined in the specification |
genesis_validators_root |
Required | A Hash256 for domain separation and chain versioning. |
Optional | Any other field will be ignored by the signer |
Responses
Success | |
---|---|
Code | 200 |
Content | {"signature": "<signature_hex_string>"} |
or
Error | |
---|---|
Code | 400 |
Content | {"error": "<Bad Request Error Message>"} |
or
Error | |
---|---|
Code | 404 |
Content | {"error": "Key not found: <identifier>"} |
Build instructions
- Get Rust.
- Go to the root directory of this repository.
- Execute
make
- The binary
lighthouse
will most likely be found in./target/release
. - Run it as
lighthouse remote_signer
orlighthouse rs
.
Running the signer
Storing the secret keys as raw files
- Steps to store a secret key
- Choose an empty directory, as the backend will parse every file looking for keys.
- Create a file named after the hex representation of the public key without 0x.
- Write the hex representation of the secret key without 0x.
- Store the file in your chosen directory.
- Use this directory as a command line parameter (
--storage-raw-dir
)
Command line flags
USAGE:
lighthouse remote_signer [OPTIONS]
FLAGS:
-h, --help Prints help information
-V, --version Prints version information
OPTIONS:
--debug-level <LEVEL> The verbosity level for emitting logs. [default: info] [possible values:
info, debug, trace, warn, error, crit]
--listen-address <ADDRESS> The address to listen for TCP connections. [default: 0.0.0.0]
--log-format <FORMAT> Specifies the format used for logging. [possible values: JSON]
--logfile <FILE> File path where output will be written.
--port <PORT> The TCP port to listen on. [default: 9000]
--spec <TITLE> Specifies the default eth2 spec type. [default: mainnet] [possible values:
mainnet, minimal, interop]
--storage-raw-dir <DIR> Data directory for secret keys in raw files.
Roadmap
- EIP standard compliant
- Metrics
- Benchmarking & Profiling
- Release management
- Architecture builds
- Support EIP-2335, BLS12-381 keystore
- Support storage in AWS Cloud HSM
- Route with the
warp
library - Slashing protection pipeline
- TLS/SSL support for requests
- Authentication by HTTP Header support
- Confidential computing support (e.g. Intel SGX)
LICENSE
- Apache 2.0.