# Connecting Secure-Signer with a Validator Client

This document is supposed to be a brief annotation of [the official setup documentation](https://docs.puffer.fi/nodes/setup) for becoming a Puffer node operator on Holesky testnet (1ETH bond requirement)

> *...but may very well be adapted for testing/running a full, native validator (32ETH) on the beacon chain from inside a SGX-enclave.*

We'll be **zooming in** on [connecting the hardware enclave with the consensus client](https://docs.puffer.fi/nodes/registration#step-6-prepare-your-validator), specifically the validator client (VC).

Depending on the consensus client of choice, the VC may be a separate binary. It manages validators using data obtained from the consensus/beacon client via a HTTP API.

Consequently, VCs are very lightweight pieces of software, well-suited to be run on low-powered devices.

## (1) Prerequisites

This guide assumes

- A fully synced holesky node (consensus & execution client)
- [Secure-Signer](https://docs.puffer.fi/technology/secure-signer) running inside an [instantiated SGX enclave](https://docs.puffer.fi/nodes/setup#setup-validator-enclave-optional)
- [Generated validator key(s)](https://docs.puffer.fi/nodes/registration#with-enclave) inside the enclave + submitted `registration.json` files (aka. 'deposit-data') on the [Puffer launchpad](https://puffer-launchpad.vercel.app/Setup)

## (2) Potential Setup Overview
The whole node stack either runs on a single host [as illustrated in this tutorial](https://mirror.xyz/ladislaus.eth/joTqwZ1sBLxlJayV4pIYxCkwl4RWheM_xipU_OCp9MM), or at least the combination of the VC and Secure-Signer runs on the same host (see image below). In the latter case, the VC [mandates additional transport layer security](https://lighthouse-book.sigmaprime.io/api-vc.html#security) for the connection to a consensus client & execution client combo on a different host.


### Security Considerations
:::info
It is highly recommended to run the VC and Secure-Signer on the same host.
:::

This is due to the fact that Secure-Signer currently does not expose a TLS/SSL-secured *https* endpoint for secure communication between the VC and Secure-Signer. This feature shall be added in the future (*http* is the default as of now).

-------

## (3) Secure-Signer as Remote-Signing Tool

- [Secure-Signer](https://docs.puffer.fi/technology/secure-signer) is Puffer's independent implementation of [Consensys' Web3Signer](https://docs.web3signer.consensys.net/), a remote-signing tool separating validator keys from the VC. VCs across all consensus clients follow the [Web3Signer API specifications](https://consensys.github.io/web3signer/web3signer-eth2.html).
- Remote-signers are often hosted in cloud-based secure vaults like AWS or Azure, also for high-availability reasons. In Puffer's case this might be due to easy access to cloud-based SGX-compatible hardware. [But other options exist as well](https://hackmd.io/@Ladislaus/Sy9m77ebA).
- Configuring the VC may be done while awaiting activation of the validator on the beacon chain.
- In the given example, a [Lighthouse VC](https://github.com/sigp/lighthouse) will be made aware of securely generated & stored validator keys by Secure-Signer (which is running inside a TEE/enclave and may thus be considered untamperable).

## (4) Identifying Validator Keys Inside an Enclave

By contrast to ordinary/non-enclave keystores, the enclave key(s) remain encrypted and securely isolated at all times.
Secure-Signer will prompt a list of all keys which have been generated inside the enclave when the user calls the Secure-Signer HTTP API via

curl -X GET http://localhost:9001/api/v1/eth2/publicKeys
from the host of the enclave.

>One of the listed keys should match the public key which is part of the `registration.json` file. Puffer node operators may check for their validator activation status by searching for their respective public key on a [testnet block explorer](https://holesky.beaconcha.in/).

## (5) Configuring the Validator Client

### Adding the Enclave Validator Key to the Validator Client

In order to [add enclave-based Secure-Signer validator key(s)](https://lighthouse-book.sigmaprime.io/validator-web3signer.html?highlight=web3signer#usage) to the Lighthouse VC, the `validator_definitions.yml` file in the `~/lighthouse/holesky/validators/` directory needs to be edited as follows (in this example **two** keys will be added):

---
- enabled: true
voting_public_key: "0xa5c3...58bd"
type: web3signer
url: "http://localhost:9001"
suggested_fee_recipient: "0x9cc2...8df5"
- enabled: true
voting_public_key: "0xd4ad...ca23"
type: web3signer
url: "http://localhost:9001"
suggested_fee_recipient: "0x9cc2...8df5"

:::success
Note the `type` of keystore here is *web3signer*.
Alternatively, non-enclave based keys `type` would refer to [*local_keystore*](https://lighthouse-book.sigmaprime.io/validator-management.html#example), a respective directory and a keystore decryption password.
:::

The `voting_public_key` is one of the listed keys identified in the prior step, respectively.

The `suggested_fee_recipient` is a `0x`address controlled by the Puffer node operator.

The `URL` points at Secure-Signer's HTTP API on the *localhost* since the VC and Secure-Signer share the same host.
*(This process step has also been tested with a [Teku-VC](https://docs.teku.consensys.io/how-to/use-external-signer/use-web3signer) - also without TLS/SSL communication)*

----

The VC can be [started](https://lighthouse-book.sigmaprime.io/mainnet-validator.html#step-4-start-lighthouse-validator-client) afterwards.

>Note: Initially, the Lighthouse VC may need to be started with the `–init-slashing-protection` flag set.

The Lighthouse VC logs should look like this:

vc  | Apr 10 10:14:38.321 INFO Lighthouse started                      version: Lighthouse/v5.1.3-3058b96
vc  | Apr 10 10:14:38.322 INFO Configured for network                  name: holesky
vc  | Apr 10 10:14:38.327 INFO Starting validator client               validator_dir: "/root/.lighthouse/holesky/validators", beacon_nodes: ["http://yourbeacon:5052/"]
vc  | Apr 10 10:14:38.327 INFO HTTP metrics server is disabled
vc  | Apr 10 10:14:38.335 INFO Completed validator discovery           new_validators: 1
vc  | Apr 10 10:14:42.545 INFO Enabled validator                       voting_pubkey: 0xa5c3...58bd, signing_method: remote_signer