more updates

Signed-off-by: Matt Nelson <[email protected]>

docs/get-started/key-best-practices.md

@@ -3,3 +3,17 @@ title: Private Key Management Best Practices
 description: Apply best practices to keep keys and Web3Signer secure.
 sidebar_position: 5
 ---
+
+When running Web3Signer, there are several best practices to be aware of for proper key management. 
+
+- Generate secure BLS keys
+- Store keys in a vault or HSM - Ideally this should be encrypted which can’t be done right now
+- Use environment authentication rather than password and token authentication where possible with vaults or HSMs
+- Only expose the validator signing API on the necessary network interface
+- Enable TLS authentication between the validator client and web3signer
+- Restrict host access to Web3Signer with `--http-host-allowlist`
+- Disable the key manager API
+    - Alternatively, restrict access to the API entirely
+- Configure the Postgres database with TLS authentication
+- Restrict access to the key config, limiting read access to Web3Signer
+- Run web3signer in a secure enclave e.g. https://aws.amazon.com/blogs/database/aws-nitro-enclaves-for-running-ethereum-validators-part-2

docs/how-to/run-at-scale.md

@@ -9,11 +9,11 @@ import TabItem from '@theme/TabItem';
 
 # Running Web3Signer at Scale
 
-There are a few key things to be aware of when running Web3Signer at scale. If you are managing hundreds or thousdands of keys, these can help with attestation performance on your validators. 
+There are a few key things to be aware of when running Web3Signer at scale. If you are managing hundreds or thousands of keys, these can help with attestation performance on your validators. 
 
 ![architecture-diagram](../../static/img/transparent_background_diagram.png)*Credit: Kiln. Architecture diagram of Web3Signer at scale*
 
-Horizontal scale helps with request latency on Web3Signer. Connecting these instances to the same slashing database will ensure low signing latency with high safety, but there are some things to consider when configuring your environment.
+Horizontal scale helps with request latency on Web3Signer. Connecting these instances to the same slashing database will ensure low signing latency with high safety, but there are some things to consider when configuring your environment. The majority of cost is bared at startup, with more keys causing Web3Signer to take longer to start up. This is a one time cost (per restart).
 
 ## Database Proximity
 
@@ -39,3 +39,12 @@ At scale, you will likely need multiple instances of Web3Signer connected to a l
 
 Credit to our friends at [Kiln](https://www.kiln.fi/) for this [helpful article](https://www.kiln.fi/post/learnings-from-running-web3signer-at-scale-on-holesky).
 
+## Hardware Recommendations
+
+We test our nodes with 10k keys on various testnets like Goerli. In an example, we use a single cloud VM instance running Besu, Teku, and Web3Signer on an Azure Standard D8as v5 (8 vCPUs, 32 GiB memory). This may be more than needed, depending on your usage (see the example dashboard below).
+
+![Dashboard for Web3Signer](../../static/img/dashboard_hw.png)
+
+The Web3Signer process alone, with 10K keys uses < 2GB of JVM heap.
+
+Here we have assumed only one validator client connecting to Web3Signer. Multiple VCs may change requirements, although the number of requests should be the same if it's the same 10K keys partitioned across multiple clients.