ACTS Blog Selection
We use machine learning technology to do auto-translation. Click "English" on top navigation bar to check Chinese version.
Amazon Web Services Nitro Enclaves for running Ethereum validators – Part 1
In this series of posts, we provide prescriptive guidance in secure operation of Ethereum validator keys using
In this post (Part 1), we explain why
In the code sample
In
Ethereum proof-of-stake and validators
Public blockchains differ in their protocol and consensus design, implementation language, and smart contract capabilities.
Determining how external participants can be incentivized to join a network and run their own node is key in economic design principles rooted in game theory, where you’re designing the network to be more decentralized while improving robustness.
Ethereum transitioned its consensus mechanism from proof-of-work to proof-of-stake in
To ensure that validators behave honestly, each validator must stake 32
There are multiple ways for users to participate in Ethereum staking:
-
- Run their own validator nodes – Users run and maintain validator nodes and have 32 ETH per validator to deposit as collateral. The user has full control of the node and the validator key.
- Use a staking-as-a-service provider – Users still provide 32 ETH per validator, but offload the operational aspects to a node provider who runs the validator nodes, and maintains the validator keys for the user.
- Join a staking pool – Users can stake any amount of ETH. The ETH staked by the users are pooled and validator nodes are run by an entrusted third party. This option is attractive to users who don’t have 32 ETH or are not comfortable staking that amount.
In the first scenario, the user realizes all of the rewards, whereas in the other two scenarios, the providers may take a percentage of the rewards as payment for their services.
Importance of securing validator keys
Running Ethereum validator nodes is crucial for the health of the Ethereum network but poses a potential security risk. The validator keys (the public and private keys) are used to collect and withdraw the 32 ETH collateral and any rewards that have been collected. The withdrawal feature is available in Ethereum’s
You can use services like
Due to the
The following solution is primarily aimed at node operators who provide staking pools and staking-as-a-service. Individual stakers can also adopt the solution, but might find the cost of running the solution prohibitive if they only stake the minimum amount of ETH.
Solution overview
The following diagram illustrates the architecture for our Nitro Enclaves-based validator signing service.
Nitro Enclaves use the
The hypervisor isolates the CPU and memory of the enclave from the parent instance and just exposes a secure local channel (
Every 12 seconds, a new block is proposed to the Ethereum network. This is referred to as a
Web3Signer will sign
In our architecture, Web3Signer runs in the Nitro Enclave. It’s important to point out that in terms of security, the Web3Signer runtime is provided by a Nitro Enclave and therefore is protected from attacks or risks like memory dumps or insufficient file system privileges. Nevertheless, by exposing Web3Signer’s HTTPS REST API via vsocket to the VPC, new potential attack vectors are being introduced associated with the application itself, which can’t be mitigated by a secure runtime environment like Nitro Enclaves. These attack vectors require a different set of measurements, like preventing public API access or advanced authentication mechanisms like
The next section in this post provides details on how the private keys are decrypted and loaded into Web3Signer in Nitro Enclave.
To ensure high availability, the Web3Signer Amazon Elastic Compute Cloud (Amazon EC2) instances are deployed in an Auto Scaling group across multiple Availability Zones. These instances load the same validator keys from DynamoDB. A Network Load Balancer (NLB) forwards the signing request to one of the instances. Multiple validator clients can connect to the same NLB.
EC2 instances hosting Nitro Enclaves should not be publicly accessible and therefore are located in private subnets. EC2 instances have secure outbound internet access via a NAT gateway to download operating system updates and other packages. In a production environment, updates and other dependencies can be provided by custom
Communication with Amazon Web Services services like Amazon Web Services KMS or DynamoDB should not traverse the internet and therefore is kept private via
Also, the provided
Bootstrapping and signing flow
The following diagram depicts the components deployed inside the EC2 instances and the general communication flow with external Amazon Web Services services like DynamoDB and Amazon Web Services KMS.
In general, there are two prerequisites:
- One or more Ethereum validator keys have been encrypted and stored inside DynamoDB. To securely generate and encrypt Ethereum validator keys, refer to
Securely generate Ethereum validator keys at low cost using a serverless architecture on Amazon Web Services . For testing purposes, a similar functionality is provided in the walkthrough section of the accompanying Amazon Web Services CDK code. - A TLS key-pair for Web3Signer has been encrypted and stored inside DynamoDB. Instructions on how to generate the TLS keypair are provided in the README section of the accompanying
Amazon Web Services CDK code .
The following steps explain at a high level how Ethereum
- If all config artifacts are present, the enclave can start.
- All artifacts are passed into the enclave in encrypted fashion.
-
kmstool-enclave-cli , a tool provided by the Nitro Enclave service team, is used from inside the enclave to decrypt the config artifacts usingcryptographic attestation . - The decrypt request augmented with the cryptographic attestation document is routed to Amazon Web Services KMS via
vsock-proxy provided by Amazon Web Services. - All decrypted config artifacts are stored on the enclaves in memory file system.
- The Web3Signer process starts. After the enclave has successfully been bootstrapped with the provided TLS keypair and the Ethereum 2 private key,
https_proxy
will act as an HTTPS endpoint for Web3Signer running inside the enclave. - The Web3Signer API endpoint is now exposed to outside of the EC2 instance and able to process incoming signing requests, for example, originating from an Ethereum 2 validator node.
- Signing requests are forwarded inside the enclave via the vsock connection, in an encrypted way. The TLS connection between the validation client and Web3Signer is stopped inside the enclave, resulting in an end-to-end encrypted transport.
Additional details about the HTTPS over vsocks tunnel and the bootstrapping process can be found in
In terms of configuration, you shouldn’t configure more than one validator client to the same validator keys. Doing so poses a high risk of signing attestations for different block proposals, or proposing different blocks in the same slot. These activities will lead to
Conclusion
In this post, we provided a high-level introduction to Nitro Enclaves and explained why Nitro is well suited to run Ethereum validators. We also explained the high-level bootstrapping and signing process using Nitro Enclave.
You can deploy the solution by following the instructions in the end-to-end walkthrough located in the
About the Authors
David-Paul Dornseifer is a Blockchain Architect with the Amazon Web Services Worldwide Specialist Solutions Architect organization. He focuses on helping customers design, deploy, and scale end-to-end blockchain solutions.
Aldred Halim is a Solutions Architect with the Amazon Web Services Worldwide Specialist Solutions Architect organization. He works closely with customers in designing architectures and building components to ensure success in running blockchain workloads on Amazon Web Services.