lighthouse-pulse/remote_signer
realbigsean e20f64b21a Update to tokio 1.1 (#2172)
## 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>
2021-02-10 23:29:49 +00:00
..
backend Fix clippy errors on tests (#2160) 2021-01-28 23:31:06 +00:00
client Update to tokio 1.1 (#2172) 2021-02-10 23:29:49 +00:00
src [Remote signer] Fold signer into Lighthouse repository (#1852) 2020-11-06 06:17:11 +00:00
tests [Remote signer] Fold signer into Lighthouse repository (#1852) 2020-11-06 06:17:11 +00:00
Cargo.toml [Remote signer] Fold signer into Lighthouse repository (#1852) 2020-11-06 06:17:11 +00:00
README.md Update remote signer README (#1870) 2020-11-07 03:06:17 +00:00

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

  1. Get Rust.
  2. Go to the root directory of this repository.
  3. Execute make
  4. The binary lighthouse will most likely be found in ./target/release.
  5. Run it as lighthouse remote_signer or lighthouse 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.