lighthouse/remote_signer
Age Manning a567f788bd Upgrade to tokio 0.3 (#1839)
## Description

This PR updates Lighthouse to tokio 0.3. It includes a number of dependency updates and some structural changes as to how we create and spawn tasks.

This also brings with it a number of various improvements:

- Discv5 update
- Libp2p update
- Fix for recompilation issues
- Improved UPnP port mapping handling
- Futures dependency update
- Log downgrade to traces for rejecting peers when we've reached our max



Co-authored-by: blacktemplar <blacktemplar@a1.net>
2020-11-28 05:30:57 +00:00
..
backend [Remote signer] Fold signer into Lighthouse repository (#1852) 2020-11-06 06:17:11 +00:00
client Upgrade to tokio 0.3 (#1839) 2020-11-28 05:30:57 +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.