We’re excited to announce the open sourcing of our first public good, Secure-Signer. In this article, we’ll dive into how it works and our goals for open-sourcing it.
What is Secure-Signer?
Secure-Signer is an independent implementation of ConsenSys’ Web3Signer remote-signing tool. A remote-signer is a module in the validator stack that allows key management and signing logic to be moved outside of the consensus client.
Secure-Signer is implemented on top of Intel SGX to give the validator stronger key security and slash protection guarantees. At a high level, equipping your validator setup with Secure-Signer is like upgrading to a hardware wallet and will significantly reduce your validator’s operational risk!
Secure-Signer is designed to protect against two types of failures that could lead to slashing:
- User error: by preventing validator private key access (even to the validator operator), slashable offenses resulting from poor key management can be avoided entirely.
- Client bugs: if the validator’s consensus client is compromised or suffers from a bug that leads to slashing, Secure-Signer acts as a backstop since the final signing operation is executed within the secure and isolated enclave.
How does it work?
SGX is designed to provide confidentiality and integrity for the data it secures and the code it executes at the hardware level.
Validator keys are generated and stored within SGX’s encrypted enclave memory. The goal is that the validator should not even know their own BLS private key but can still perform all their validator duties. However, as a precaution, we recommend to pre-sign VoluntaryExit messages in case you ever lose access to your Secure-Signer instance.
Slashing penalties occur when a validator equivocates, which can happen if they double propose, double vote, or surround vote blocks. Equivocation is avoidable if the validator remains self-consistent with previously signed blocks and attestations. In practice, this is accomplished by maintaining a database of previously signed material.
Secure-Signer maintains a slash-protection database within enclave memory that adheres to EIP-3076’s interchange format. Whenever block or attestation signatures are requested, the enclave first verifies with the database that the message-to-be-signed is non-slashable. Upon success, the database is updated for future requests. SGX’s integrity and confidentiality properties strictly enhance the security of these essential validator operations compared to running them unprotected.
For example, assume the five major consensus clients are equally used across the validator set with a 20% allocation each. If a black swan bug unilaterally affected every validator running
client A, those validators would be slashed
1 + 3 * 20% * 32 = 19.2 ETH. If a quarter of those validators had protected themselves via Secure-Signer, the slashing penalty is reduced to
1 + 3 * 20% * 75% * 32 = 15.4 ETH. In this example, the participating validators prevented a 15.4 ETH loss to themselves and helped reduce the penalty of others by 19.8%.
This sounds amazing, but it assumes that the Secure-Signer implementation is flawless. If Secure-Signer reaches significant adoption, it can become a point of failure itself, effectively undoing its effectiveness at reducing the correlation penalty amount. A bug in Secure-Signer could similarly lead to a correlated slashing event. In the same example, if
client D had 50% Secure-Signer usage, a bug could cause a penalty of
1 + 3 * (20% * 75% + 20% * 50%) * 32 = 25 ETH. Bug bounties, code audits, and formal verification are mitigations, but ultimately the solution is to reduce correlation, and the best way to do this is to open-source Secure-Signer and allow the community to implement their versions.
Just like it is extremely important for Ethereum’s robustness to have multiple implementations of execution and consensus clients, we think it is equally important to diversify remote-signer implementations. Our goal with Secure-Signer is to define a new standard for secure validator key management and encourage the community to fork and implement their versions. This is the only way the entire validator set can leverage this technology without introducing a point of failure.
Web3Signer accomplished the initial heavy lifting by defining the remote-signing specs that the many amazing consensus client teams support. We hope that our contribution makes it easy for future teams to implement forked versions of Secure-Signer in different languages (beyond Java and Rust), enclave SDKs (Teaclave, Occlum, Gramine), and even hardware platforms (SGX, AMD SEV).
Increasing the number of hardware-based remote-signer implementations helps reduce the impact of a correlated slashing event if any implementation has a catastrophic bug. This allows all validators to enjoy lower risk validating and ultimately reduces the amount of equivocation on the network, providing a more robust and secure Ethereum.
Start using, forking, or contributing to Secure-Signer today! If you’re interested in working with us, we’re hiring 🐡! This work is funded by an Ethereum Foundation grant, and the team at Puffer Finance will continue to push technological solutions to reduce centralization pressures on Ethereum. Stay tuned for updates on the Testnet launch for our permissionless and decentralized liquid staking protocol.
About Puffer Finance:
Puffer is defining a new industry standard for secure validator operations with the primary objective of preserving decentralization. Puffer’s Anti-Slashing technologies are designed to minimize the chance of slashing events. Our Secure-Signer technology is released as a public good to help protect solo stakers and the wider staking industry from correlated slashing penalties. Our Secure-Aggregator technology provides the foundation to build a secure, scalable, and performant liquid staking protocol. Allowing permissionless and capital-efficient Node Operator participation allows anyone to join the PufferPool to help preserve Ethereum’s decentralization. Learn more: www.puffer.fi