# Validating From Hardware Enclaves By [Ladislaus](https://paragraph.com/@ladislaus) · 2023-09-12 --- _Special thanks to_ [_Jason_](https://twitter.com/jasnoodle) _&_ [_Amir_](https://twitter.com/AmirOnchain) _from Puffer for review and discussion_ In the following, we will take a closer look at _secure-signer_, a remote-signing tool protecting validator keys and adding a slashing protection fence inside trusted hardware. We will also go through setting up a validator using secure-signer on [ephemery testnet](https://mirror.xyz/ladislaus.eth/KbQE16HYc0U-_m7ZuAhCBqbyrEyGTThQ9pr_NeMHiVw). * * * `UPDATE: Here’s a 15min devconnect2023 TL;DR of this blogpost` [![]({{DOMAIN}}/editor/youtube/play.png)](https://www.youtube.com/watch?v=kwkLTnXEApU) * * * ### **Quick recap: What to protect against? And how to protect validator keys?** Node operators protect their validator keys with the aim to mitigate [slashing risks](https://eth2book.info/capella/part2/incentives/slashing/#slashing), possibly occurring in cases like: * accidentally running the same keys simultaneously in two places * a compromised host/node (or the accessing client) * a bug in a consensus client implementation * physical node theft * a rogue cloud provider or staking service employee → and subsequent [ransom attacks](https://www.reddit.com/r/ethereum/comments/14vpyb3/comment/jre5i06/) Most common **protection schemes** can be categorised as follows: ![src: https://www.attestant.io/posts/protecting-validator-keys/ - slightly modified](https://storage.googleapis.com/papyrus_images/ec6f7dbe32961ea881fa1c742a5ee31a8c6e3081e40676d063c72b3d3554e35d.png) src: https://www.attestant.io/posts/protecting-validator-keys/ - slightly modified * Distributed key generation & threshold signing, e.g. [Dirk](https://www.attestant.io/posts/introducing-dirk/) / [Vouch](https://www.attestant.io/posts/introducing-vouch/) [in a geographically distributed multi-region setup](https://github.com/CryptoManufaktur-io/vouchdirk-docker) or similarly: Distributed Validator Technology (DVT), e.g. [Obol’s](https://dvt.obol.tech/) * Remote-signing with [web3signer](https://docs.web3signer.consensys.net/), i.e. separating validator keys from the validator client, often hosted in cloud-based secure vaults like AWS or Azure; or rather exotic at-home setups with a [dual-lan port NUC connected to an “offline” Raspberry Pi](https://dankradfeist.de/ethereum/2020/11/20/staking-on-raspi.html) holding the validator keystore * Remote passphrase: fully or partially encrypted internal or [external](https://github.com/htimsk/SecureKey) hard drives storing the keystore decryption passphrase * Local encryption: air-gapped generated keystore file + decryption passphrase stored “hot” on disk / in memory - usually the default setup for at-home staking * Validator keys generated and stored in hardware enclaves with secure-signer, i.e. not on drive, but in encrypted memory **What does validating from hardware enclaves even mean?** ---------------------------------------------------------- > “\[...\] staking via trusted hardware \[is a method\], where your staking key would be within a system that is very difficult to exfiltrate keys from \[...\]” - [Vitalik](https://www.reddit.com/r/ethereum/comments/14vpyb3/ama_we_are_ef_research_pt_10_12_july_2023/jrnyaei) Essentially, a hardware enclave **mimics hardware wallet functionality** in order to protect validator keys at rest, but on top of that makes it even “smarter” in the sense that it adds anti-slashing protection at runtime. One of the core primitives is the **generation of validator keys within a hardware enclave**, from which they cannot be extracted, but from which validators can perform their consensus duties. By contrast to resource intensive privacy-enhancing computational techniques like _multi party computation_ (e.g. for DVT) or _fully homomorphic encryption_, hardware enclaves are capable of **arbitrary, inexpensive computation** almost at the speed of the native CPU. This provides significant **performance advantages**, particularly low latency. The initial concept for staking from secure enclaves stems from Justin Drake’s ethresear.ch post, proposing to use trusted hardware for trustless staking pools: [ Liquid solo validating ---------------------- Special thanks to @vbuterin, @fradamt for design ideas and to @djrtwo, @timbeiko, Vasiliy Shapovalov, Isidoros Passadis, Kelly Olson for feedback. TLDR: We propose a fungible and governance-free liquid staking derivative (LSD) compatible with solo validating. The LSD is secured via hardware-based slashing protection and enjoys higher capital efficiency than Lido's stETH. https://ethresear.ch ![](https://storage.googleapis.com/papyrus_images/ec5c5091f327fc5bba77649a771a3043bbcf2e031d786512fb3d08ee7a883eaa.png) ](https://ethresear.ch/t/liquid-solo-validating/12779) **What is secure-signer?** -------------------------- [Secure-Signer](https://github.com/PufferFinance/secure-signer) is an **open-source validator remote-signing tool** built by the [Puffer team](https://www.puffer.fi/). It was originally [supported by an Ethereum Foundation grant](https://blog.ethereum.org/2023/02/22/allocation-update-q4-22). [Secure-Signer](https://www.youtube.com/live/aFk0WymgAo8?feature=shared&t=14502) functions as an independent implementation of [Consensys' Web3Signer](https://github.com/Consensys/web3signer) that shifts validator key management and signing logic to hardware enclaves, separating them from the consensus/validator client. ![secure-signer in a nutshell](https://storage.googleapis.com/papyrus_images/0594ba4a68604b83ec8f30280b29d94195d22e702d302bc94fe39824bcc0fb7a.png) secure-signer in a nutshell This means that **validator keys are generated and stored within SGX's encrypted enclave memory** (see below). Also, the hardware enclave provides guarantees that it will not sign a slashable offense [by maintaining an integrity-protected database](https://docs.puffer.fi/tech/securesigner#how-does-it-prevent-slashing) of previously signed messages. **What is SGX / TEE / Remote Attestation?** ------------------------------------------- Intel’s _Software Guard Extension_ (SGX) is a technology built into certain Intel processors allowing users to encrypt their data on an isolated and protected portion in memory (called an **enclave**). The enclave ensures that the **code is executed as expected without tampering** and that the **data remains encrypted**, not leaving the underlying CPU’s memory - not even being accessible to the OS or the system administrator. The **physical hardware ensures that these properties hold**. More broadly speaking and in essence, such _trusted execution environments_ (TEEs) provide confidentiality and integrity guarantees on program code and data. * * * Secure hardware elements can be found in most modern smartphones or hardware wallets, they generally however do not support verifiable `remote attestations`: Validators _can_ make use of Intel **attesting** to the fact that only secure-signer - the program - is running within an Intel manufactured hardware enclave, and thus the validator key and slashing-protection logic & database. The untrusted host ([or potentially other third parties](https://docs.puffer.fi/tech/rave)) interacting with the enclave subsequently **verifies** Intel’s attestation in order to gain trust in the enclave. This so-called _remote attestation_ feature by Intel is **not strictly necessary** when setting up secure-signer in SGX as long as node operators trust themselves when interacting with the enclave. Nevertheless, it serves as a useful sanity check and proof, gaining increased confidence that the latest version of secure-signer indeed runs correctly in an SGX enclave with up-to-date firmware [Liquid solo-staking pools](https://ethresear.ch/t/liquid-solo-validating/12779), as one of several examples by contrast, necessarily require these (publicly) verifiable _remote attestations_ in order to gain trust in node operators. * * * **What is secure about hardware enclaves anyways?** --------------------------------------------------- From a blockchain purist's perspective, there are arguments against relying on a centralised entity like Intel for highest-grade security. For one, users trust Intel’s technology which itself is **proprietary and closed source**. Furthermore, SGX has been [subject to vulnerabilities in the past](https://arxiv.org/abs/2006.13598). Its reputation is not necessarily the best. [![User Avatar](https://storage.googleapis.com/papyrus_images/30df49e04158a8ac9b79914398e88d58f93466b7d0df5fb31dc5ebd666ae9025.jpg)](https://twitter.com/gakonst) [Georgios Konstantopoulos](https://twitter.com/gakonst) [@gakonst](https://twitter.com/gakonst) [![Twitter Logo](https://paragraph.com/editor/twitter/logo.png)](https://twitter.com/gakonst/status/1698068083716608449) sgx pilled, once you get over the setup, intuiting i/o and how to run a simple workload on a box things seem doable/can start imagining what are use cases people are excited about with confidential compute? non crypto also ok [![Like Icon](https://paragraph.com/editor/twitter/heart.png) 109](https://twitter.com/gakonst/status/1698068083716608449)[ 3:19 PM • Sep 2, 2023 ](https://twitter.com/gakonst/status/1698068083716608449) Nonetheless, it can be argued that the use of SGX may serve as a **purely additive security layer** to existing staking setups. SGX is **widely available**, a tool **at hand today**, that can expand the validator key protection design space and increase remote-signing software diversity, ultimately benefiting the network as a whole. > At the end of the day, stakers need to define their individual **threat models** and make trust assumptions with regards to the technologies they use, see for example [the Ledger firmware debate](https://www.coindesk.com/business/2023/05/18/ledger-continues-to-defend-recovery-system-says-its-always-technically-possible-to-extract-users-keys/) earlier this year. It is also worth pointing out other **SGX use cases** in the blockchain context such as [the secret network](https://scrt.network/), [encrypted mempools like SUAVE](https://www.youtube.com/watch?v=DhsDFKnHPa0), [running Geth](https://github.com/flashbots/geth-sgx-gramine) / [Reth](https://github.com/gakonst/sgx-revm/) / a [block builder](https://writings.flashbots.net/block-building-inside-sgx) inside SGX, [permissionless (re-)staking pools](https://docs.puffer.fi/tech/rave) as well as [multi-proving](https://ethresear.ch/t/2fa-zk-rollups-using-sgx/14462) and [\-verifying](https://www.youtube.com/watch?v=3kQzZ0ZhfVg) systems, e.g. for zkRollups. **How could node operators benefit from validating with secure-signer?** ------------------------------------------------------------------------ Because it runs in an isolated, tamper-resistant hardware enclave, secure-signer provides security enhancements with regards to avoiding slashable offenses and hence adds **extra levels of defense** **against** risks such as: * accidentally **running the same keys twice**, i.e. equivocations (keys only ever exist once within one unique enclave) * due to **physical theft** of the hardware/node/enclave (s.o.) * a **critical consensus client bug** (secure-signer makes use of a dedicated, anti-tamperable slashing-protection database managed within the enclave) * a directly **compromised host**/node (e.g. in case of a hack, OS 0-days or kernel-level malwares) * a **compromised client** accessing/SSH-ing into the host/node (e.g. because of parallel usage for browsing/e-mail/entertainment activities) → and subsequent [ransom attacks](https://www.reddit.com/r/ethereum/comments/14vpyb3/comment/jre5i06/) All in all, secure-signer not only protects against hackers, but also against accidental key leakage or rogue system administrators as well as potential ransom attacks. It is also **at-home staking friendly**, since it can be run on [consumer grade hardware (NUCs)](https://github.com/ayeks/SGX-hardware) or Xeon servers, reducing dependency on cloud solutions. The remote attestation feature moreover increases trust in solo-stakers by third parties, **expanding the design options for permissionless (re-)staking pools**. Last but not least, the more validator keys run in TEEs, the lower the risk of equivocations and thus a highly correlated mass-slashing event, benefitting the **health of the network**. **What is on the roadmap for secure-signer?** --------------------------------------------- → The secure-signer **codebase** has recently been released and is **still in alpha**. It **needs review & audit**. → Currently only Intel’s SGX enclave technology is supported, but [AMD SEV](https://www.amd.com/de/developer/sev.html) support and similar solutions like AWS Nitro Enclaves are in the works. _Note: since_ [_Intel deprecated SGX support in its consumer product line_](https://hardenedvault.net/blog/2022-01-15-sgx-deprecated/) _in 2021, the spectrum of available at-home hardware becomes more limited_ → As staking from TEEs is complimentary with DVT, the **integration with DVT providers** is a work-in-progress. → Secure-Signer UI/UX in its current form is not best suited for mass key-management (feel free to report issues and/or get involved) * * * **How to run a validator with secure-signer on ephemery testnet?** ------------------------------------------------------------------ This guide mainly follows the official secure-signer [setup documentation](https://pufferfinance.github.io/secure-signer/getting-started/). However, we make some specific adjustments for: * running secure-signer on **at-home hardware** (NUC) - no cloud! * adapting the networking configuration for [ephemery testnet](https://mirror.xyz/ladislaus.eth/KbQE16HYc0U-_m7ZuAhCBqbyrEyGTThQ9pr_NeMHiVw), because we want to **sync the node within minutes** and have access to **easily obtainable testnetETH** * running the full node stack (execution + consensus + validator client & secure-signer) in docker compose on **one machine** (ephemery requires < 1GB of disk space) ![](https://storage.googleapis.com/papyrus_images/281032d00346f72ec2b2d273e5903fa47ff8e04d81db45234804ecb99e265137.png) _For the very basics you may want to take a look at the_ [_fundamentals of running a node in Docker_](https://mirror.xyz/ladislaus.eth/O5bW3rDnKITHlCXE9K_0IwiEwDrc6qw-y3MpX0EUcew) _first._ ### Prerequisites * Ubuntu 22.04 + Docker Compose for software orchestration (generally no necessity!) * [SGX capable hardware](https://pufferfinance.github.io/secure-signer/installation/#prereqs): **This guide has been tested on a 4-core NUC7CJYH** (Celeron J4005) which is capable of SGX (and FLC), averaging a decent 5w (TDP10) power consumption. * _Occlum LibOS_, a framework enabling applications to run on SGX -currently used by secure-signer- requires SGX-related [Flexible Launch Control (FLC)](https://www.intel.com/content/www/us/en/support/articles/000057420/software/intel-security-products.html) technology _note: this guide has also been unsuccessfully tested on a given NUC10, because it was lacking FLC_ alternatively: testing may happen [on Azure Cloud](https://pufferfinance.github.io/secure-signer/getting-started/) (Although defeating the purpose and hence not part of this guide: you can test secure-signer as a pure Rust app with non-sgx-compatible hardware) * **SGX activated in BIOS**/UEFI settings * 128MB isolated memory proves to be sufficient in order to run secure-signer & the validator key(s) + the slashing-protection database * [Installed SGX drivers](https://pufferfinance.github.io/secure-signer/installation/#installing-sgx-drivers) (for Linux served as Kernel module)containing Intel’s Platform software, providing the runtime environment for enclaves - named Architectural Enclave Service Manager (AESM) ![NUC-7PJYHN (manufactured in 2022) + 8GB RAM + 256 GB 2,5” SATA SSD](https://storage.googleapis.com/papyrus_images/daf8e307ac073deb5c139f391390604435c12c1377d24fe6e92496a94298a9ee.png) NUC-7PJYHN (manufactured in 2022) + 8GB RAM + 256 GB 2,5” SATA SSD ### Some SGX Vocabulary Without going too deep down the [SGX rabbit hole](https://sgx101.gitbook.io/sgx101/), the following SGX vocabulary should be noted: * [MRENCLAVE](https://sidsbits.com/Intel-SGX-Attestation-Part-1/) = hash value of the program binary in the enclave - to us representing the **identity of the SGX enclave** * verifying this value assures us to run only the correct version of secure-signer on SGX, and provide it to the `client CLI`**,** the user interface for secure-signer when interacting with the enclave * the value may change depending on the used version of secure-signer; cross-checking MRENCLAVE can either be done via self-building or by comparing with developer-signed and -published values, e.g. on-chain or GitHub * [MRSIGNER](https://www.intel.com/content/www/us/en/developer/articles/technical/introduction-to-intel-sgx-sealing.html) = hash value representing the **identity of the author**/creator of the SGX enclave * * * ### Setting up an ephemery node In our `/home` directory we create a project folder `/ephemery` with subfolders: mkdir -p ephemery/{geth,lighthouse-bn,lighthouse-vc,JWT,testnet-all} **Generate a JasonWebToken** (JWT) so that the execution and consensus client can communicate securely: openssl rand -hex 32 | tr -d "\n" > "$(pwd)/JWT/jwtsecret" **Obtain and extract the necessary testnet files** (genesis info, boot nodes, etc) for the current ephemery iteration (at the time of writing #92): (We hope for client team’s support of “_–network=ephemery”_ in the future.) cd ephemery/testnet-all wget https://github.com/ephemery-testnet/ephemery-genesis/releases/download/ephemery-92/testnet-all.tar.gz tar -xzf testnet-all.tar.gz * * * ### Preparations for testing on ephemery We test on ephemery, because the hardware requirements are comparably low, allowing us to run a full node on a slightly underpowered SGX-capable NUC7 for easier demonstration purposes. It is moreover extremely **easy to obtain testnetETH**. Limited state and block history will allow for **syncing the full node within minutes**. However, secure-signer currently lacks out-of-the-box support for ephemery. We thus need to **create a network configuration file** `ephemery_network_config.json` which we will manually import into the secure-signer container at a later stage: { "network_name": "ephemery", "deposit_cli_version": "2.3.0", "fork_info": { "fork": { "previous_version": "0x1000101b", "current_version": "0x1000101b", "epoch": "0" }, "genesis_validators_root": "0x9c11ae92a2ddfc3122ffcc1e6c19297b6767ea6436e45a85c80cc8bf48646bab" } } > Note: Ephemery’s _GENESIS\_FORK\_VERSION_ is static (0x1000101b), but the _GENESIS\_VALIDATORS\_ROOT_ changes every iteration. Retrieve the [latest iteration](https://github.com/ephemery-testnet/ephemery-genesis/releases)'s value either per “GET /eth/v1/beacon/genesis” RPC-call or as part of the `nodevars_env.txt` in the `~/ephemery/testnet-all` directory downloaded earlier. * * * ### Running the node We find below a generic `docker-compose.yaml` which we download in our project directory, opting for Geth as execution client, Lighthouse as consensus & validator client and secure-signer as remote-signer: version: "3.4" volumes: Secure-Signer-Backup: services: secure-signer: image: pufferfinance/secure_signer:latest network_mode: host container_name: secsigner restart: on-failure devices: - /dev/sgx/enclave:/dev/sgx/enclave - /dev/sgx/provision:/dev/sgx/provision volumes: - Secure-Signer-Backup:/Secure-Signer - /var/run/aesmd:/var/run/aesmd command: > /bin/bash -c "occlum run /bin/secure-signer 9001" validator: image: sigp/lighthouse:latest network_mode: host container_name: vc restart: on-failure volumes: - ./lighthouse-vc:/root/.lighthouse - ./testnet-all:/ephemery command: > lighthouse --testnet-dir ephemery validator --beacon-nodes http://localhost:5052 --suggested-fee-recipient 0x0000000000000000000000000000000000000000 --init-slashing-protection consensus: image: sigp/lighthouse:latest network_mode: host container_name: lighthouse restart: on-failure volumes: - ./lighthouse-bn:/root/.lighthouse - ./JWT:/JWT - ./testnet-all:/ephemery command: > lighthouse --testnet-dir ephemery beacon_node --datadir /root/.lighthouse --eth1 --http --validator-monitor-auto --execution-endpoints http://localhost:8551 --execution-jwt /JWT/jwtsecret --boot-nodes enr:-Iq4QNMYHuJGbnXyBj6FPS2UkOQ-hnxT-mIdNMMr7evR9UYtLemaluorL6J10RoUG1V4iTPTEbl3huijSNs5_ssBWFiGAYhBNHOzgmlkgnY0gmlwhIlKy_CJc2VjcDI1NmsxoQNULnJBzD8Sakd9EufSXhM4rQTIkhKBBTmWVJUtLCp8KoN1ZHCCIyk,enr:-Iq4QIc297-de1P6hznMX2cIdVsQkve9BD9NUsJ7vVQa7eh5UpekA9rLid5A-yLiS3gZwOGugYZPi58x76zNs2cEQFCGAYhBJlTYgmlkgnY0gmlwhEFtmi6Jc2VjcDI1NmsxoQJDyix-IHa_mVwLBEN9NeG8I-RUjNQK_MGxk9OqRQUAtIN1ZHCCIyg # --checkpoint-sync-url https://checkpointz.bordel.wtf/ execution: image: ethereum/client-go:stable network_mode: host container_name: geth restart: on-failure volumes: - ./geth:/root/.ethereum - ./JWT:/JWT command: > --datadir /root/.ethereum --http --authrpc.jwtsecret /JWT/jwtsecret --networkid 39438092 --syncmode full --bootnodes enode://0f2c301a9a3f9fa2ccfa362b79552c052905d8c2982f707f46cd29ece5a9e1c14ecd06f4ac951b228f059a43c6284a1a14fce709e8976cac93b50345218bf2e9@135.181.140.168:30343 > Make sure to adjust Geth’s `networkID` to the current ephemery iteration ([find the number here](https://github.com/ephemery-testnet/ephemery-resources#meta-network-info), _or_ look for _chainId_ in `~/ephemery/testnet-all/genesis.json`) > > For `bootnodes` look in `~/ephemery/testnet-all/boot_enr.txt` * * * We then **provide Geth with ephemery’s genesis state** (note: prompt from this from the project directory): docker run -it -v $(pwd)/geth:/root/.ethereum -v $(pwd)/testnet-all/genesis.json:/genesis.json ethereum/client-go:stable --datadir /root/.ethereum init genesis.json Afterwards, **start the execution & consensus client** and sync ephemery: docker compose up -d execution docker compose up -d consensus * * * ### Starting secure-signer We **start the secure-signer container**, automatically creating a **persistent docker volume** which permanently stores encrypted enclave data (e.g. for the purpose of re-instantiating the enclave after a reboot). This command also **initiates the hardware enclave** via _Occlum library OS_ which is part of the secure-signer docker image. The started [secure-signer http-server](https://pufferfinance.github.io/secure-signer-api-docs/redoc-static.html) will later communicate with the validator client (VC): docker compose up -d secsigner Afterwards, retrieve (and verify) the “enclave ID” (MRENCLAVE value) in order to make sure the [enclave indeed runs secure-signer](https://pufferfinance.github.io/secure-signer/running/client#getting-secure-signer-enclave-measurements): docker exec secsigner /bin/bash -c "cat MRENCLAVE" > Currently, a version upgrade of secure-signer would require a withdrawal/re-deposit since the enclave creation policy in SGX ties the program version to the enclave ID (MRENCLAVE). It is intended to switch this policy to the _author_ of an enclave (MRSIGNER) so that stakers can upgrade/patch secure-signer without losing access to the enclave/their keys. Next, **import** the `ephemery_network_config.json` created earlier into the secure-signer container: docker cp ephemery_network_config.json secsigner:/home/conf * * * ### Generating a validator key in secure-signer Via the `client CLI` we may now [generate a new validator keypair](https://pufferfinance.github.io/secure-signer/running/client#breaking-down-what-happened-1) together with a slashing protection database and perform remote attestation: docker exec -w /home secsigner /bin/bash -c "./client --bls-keygen --mrenclave ecd4d348d97cebb93ebc6b65bd7675e2861ddcb0f7ad9178b903600672561594" ![by default Intel attests to the key generation](https://storage.googleapis.com/papyrus_images/610f7bd48cb0956ae68cbf9c0ad1d5da667ed63c959e86c8d907365ce022fafd.png) by default Intel attests to the key generation Afterwards, **list and review the freshly generated key**(s) secure-signer is safeguarding: curl http://localhost:9001/eth/v1/keystores * * * ### Generating deposit data The deposit data is generated within the enclave following the [consensus specs](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md) and is signed with the specified validator key. Next, we extract the output file `deposit_data.json` to our project directory and inspect it. Note that the _\--execution-addr_ needs to be a regular ETH-address: docker exec -w /home secsigner /bin/bash -c "./client --deposit --config conf/ephemery_network_config.json --validator-pk-hex 0xa5...58bd --execution-addr 0xd8...6045" docker exec -w /home secsigner /bin/bash -c "cat ss_out/deposit_data.json" > ~/ephemery/deposit_data.json cat ~/ephemery/deposit_data.json * * * ### Depositing to the beacon chain **Obtain EphETH** from [one of the faucets](https://github.com/ephemery-testnet/ephemery-resources#faucets). Go to the [ephemery launchpad](https://ephemery.launchpad.remyroy.com/en/) and drop the generated `deposit_data.json`. > Note: it will take just about ~7h for your deposit to be processed (because ephemery comes with an adjusted [ETH1 follow distance](https://eth2book.info/capella/part3/config/configuration/#eth1_follow_distance)) * * * ### Configure the validator client While we await activation we make the Lighthouse-VC aware of secure-signer by configuring its [validator\_definitions.yml](https://lighthouse-book.sigmaprime.io/validator-web3signer.html#usage) (following the web3signer specification): --- - enabled: true voting_public_key: 0xa5...58bd type: web3signer url: "http://localhost:9001" > We point at the _localhost_ since the VC and secure-signer share the same host. (This process step has also been tested with a Teku-VC, also without TLS/SSL communication) Note: initially, the Lighthouse-VC might be run with the _–init-slashing-protection_ flag * * * ### Start the validator client We then start the VC and further await the activation of the validator: docker compose up -d validator → Et voilà: we should by now be validating from a hardware enclave > _suggestion: modify the setup and test pointing the VC to a remote BN, i.e. not on the same machine, e.g. on Goerli or Holesky testnet_ * * * ### Coda: generating a voluntary exit message It should be considered **best practice to pre-sign** [**voluntary exit messages**](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs) in case you ever lose access to the enclave. docker exec -w /home secsigner /bin/bash -c "./client --withdraw --config conf/ephemery_network_config.json --validator-pk-hex 0xa5...58bd --epoch 123 --validator-index 4567" > _–epoch_ representing the earliest epoch when the voluntary exit can be processed, and _–index_ the validator index Finally, we extract the output file `voluntary_exit_message.json` to our project directory and inspect it: docker exec -w /home secsigner /bin/bash -c "cat ss_out/voluntary_exit_message.json" > ~/ephemery/voluntary_exit_message.json cat ~/ephemery/voluntary_exit_message.json * * * ### **Current caveats** * As mentioned above, in the context of solo-staking it seems reasonable to add/switch the enclave instantiation policy to **allow for upgrading**/patching secure-signer without losing access to an existing enclave * [Importing keys](https://pufferfinance.github.io/secure-signer/running/client#importing-a-validator-key) into secure-signer is currently [buggy](https://github.com/PufferFinance/secure-signer/issues/36) * A feature to **enable TLS/SSL-communication** between the VC and secure-signer may be added in the future (http is the default as of now) * note: in the above setup, we are neither exposing the VC nor secure-signer to the internet * By default, secure-signer listens on 127.0.0.1 (hard-coded into the enclave binary), which is why we set the Docker network mode to _host_, as opposed to e.g. a _bridge_ network listening on all interfaces (0.0.0.0). This can be edited directly in the source code but requires recompiling the enclave following the [developer instructions](https://pufferfinance.github.io/secure-signer/developers/) (which seems unpractical) * **Support for other testnets** apart from Goerli, i.e. Holesky & Ephemery, is not natively integrated yet * * * \*\*\*\* _Please keep in mind this is a testnet guide that may contain mistakes and that takes shortcuts which come with trade-offs. It could quickly become outdated as it’s subject to ever evolving network and software changes._ --- *Originally published on [Ladislaus](https://paragraph.com/@ladislaus/validating-from-hardware-enclaves)*