Announcing a Request for Proposal (RfP) for a Lighthouse User Interface

Introduction

Sigma Prime Pty Ltd is a technical consultancy who specialise in information security and are mostly based out of Sydney, Australia.

The primary focus of Sigma Prime is to help secure distributed systems through in-depth security assessments of decentralised projects, while concurrently researching and developing core Blockchain infrastructure.

Sigma Prime is the founder and maintainer of the Lighthouse project, an open-source implementation of the Ethereum 2.0 specification, written in Rust. Lighthouse is one of the leading Ethereum 2.0 client implementations and has a particular focus on performance and security. This project has been funded since 2018 by several parties including the Ethereum Foundation, ConsenSys, and Vitalik Buterin.

Sigma Prime is initiating a Request for Proposal (RfP) for an an open source, minimal User Interface which can be connected to the validator client and beacon node components of the Lighthouse client.

This proposal contains a rough outline of the project, a suggested timeline, expected deliverables and a guideline of vendor selection criteria.

Project Overview

Lighthouse is a Rust-based Ethereum 2.0 client implementation which focuses on speed and security.

Through Lighthouse, Sigma Prime helps to realise a scalable and efficient Ethereum platform. The Lighthouse GitHub repository can be found at https://github.com/sigp/lighthouse.

The Lighthouse client is currently CLI-based, which we see as a hurdle for new users to join and participate in the Ethereum 2.0 ecosystem. This RfP aims to alleviate this hurdle by designing and developing a minimal User Interface (UI) which connects to one or more beacon nodes and optionally a validator client via their predefined HTTP endpoints.

The UI will show basic statistics and metrics that are exposed on the beacon node and validator client endpoints. Additionally, it will allow for some minimal user interaction, such as creating validator key-pairs, interacting with the Eth1 deposit contract, starting, stopping and exiting a validator.

The UI will be a static webpage served via a local HTTP server, although should be constructed such that at a later stage can be converted to an Electron app. We have a strong preference for a React implementation.

User Interface Specifications

As the UI will be connecting to the beacon node and validator client services (REST APIs), all core logic will be handled by these endpoints. In most circumstances the UI will simply create HTTP requests to the relevant services to either update statistics and metrics, or perform basic user tasks.

Beacon Node Enpoints

The current Beacon node accessible HTTP endpoints are documented at the following location:

• https://lighthouse-book.sigmaprime.io/http.html

Note that if the UI requires additional endpoints, the Lighthouse development team will be able to build these in.

Main Beacon Node UI Features

For each beacon node the main information that should be relayed to the user (using these endpoints) are:

• The client version and fork version of the connected Beacon node (the relevant API endpoint is currently under development and will be provided)
• The syncing state, i.e. whether the connected Beacon node is syncing, up-to-date and potentially a progress bar during sync indicating syncing speed (slot/second) and estimated time to completion (additional API endpoints will be added to assist with this)
• Network information: Connected peers: (/network/peers), peer_id: (/network/peer_id), Ethereum Node Records: (/network/enr)
• Standard metrics: Disk usage, network bandwidth, cpu usage (ideally in graph form)

Validator Client Endpoints

Validator clients are the gatekeepers of validator keys and as such, their HTTP API is required to be authenticated.

When a validator client is initialised (or launched with a special flag), it will output a session-key which will be used to encrypt and authenticate the connection with the web interface. Users will be required to input this key into the UI before the UI can connect and access the validator client. The UI should store this as a session key to be reused until the session expires.

Below is a list of validator client API endpoints which we envisage the UI will interact with: These endpoints are not currently built, but will be soon. Additional endpoints can be created on request

• GET /validators
  • Returns a list of validators known to the validator client
• POST /validators
  • Create a new validator
• POST /validators/<pubkey>/remove
  • Removes a validator from the list of known validators (does not actually delete related keys)
• POST /validators/<pubkey>/stop
  • Stops the validator client from proposing/attesting for the given validator
• POST /validators/<pubkey>/start
  • Starts proposing/attesting for the given validator. The validator must already be known by the validator client
• POST /validators/<pubkey>/exit
  • Creates a signed Validator Exit message and posts it to a Beacon node
• POST /validators/<pubkey>/withdraw
  • Creates a signed Validator Withdraw message and posts it to a Beacon node. (Disabled for the time being as phase0 does not support this)
• GET /status/beacon_node
  • Gets the validator client to perform a check that it can connect to the Beacon node and perhaps make some judgement about whether or not that Beacon node is synced.

Main Validator Client UI Features

For a connected validator client, the main UI features will be:

• A list of validators, their balances, recent past, current and future duties. (/validators)
• Ability to create a new validator (/validators)
• Ability to submit deposits to the Eth1 deposit contract via the MetaMask browser extension
• Ability to start/stop/remove validators from the validator client

Engagement Timeline

This project is expected to be delivered following the timeline outlined below:

Indemnification & Fee Structure

The chosen vendor will be expected to submit three invoices:

• A first invoice of 20% of the total engagement fee at the start of the engagement
• A second invoice of 60% of the total engagement fee at the delivery of the basic prototype
• A third and final invoice of 20% of the total engagement fee after the completed, final UI has been delivered

The vendor will be given the option to be paid via bank transfer or in the following crypto-currencies (or Digital Tokens):

• Ether (ETH)
• Dai (DAI)
• Bitcoin (BTC)

The value of Digital Token described under the agreement will be the value of that Digital Token in Fiat Money at 9am AEST on the due date for payment as described at https://www.coinbase.com/price.

Selection Criteria

The vendor selected by Sigma Prime will have significant expertise in the areas necessary to meet the needs and requirements set forth in this RfP. Particularly:

• Experience with design, UX and UI development
• Experience with the React framework
• Basic understanding/experience with Blockchain technology/Ethereum

Additional information, such as engagement team CVs and third party references, may be requested by Sigma Prime.

Bidding Instructions

Upon reception of this Request for Proposal, vendors are expected to confirm receipt and intention to bid on the engagement.

Proposals must be returned by bidders before January 31st, 2020 9pm AEST.

Proposals must be sent in PDF format to the following email address: rfp@sigmaprime.io

This PGP key can be used to encrypt the proposal (optional).

Vendors can request more information via email (rfp@sigmaprime.io). Pre-bid meetings with vendors can also be arranged if required.