Slashing is the fundamental security mechanism safeguarding the consensus process on Ethereum and many other chains, including all the new protocols being built on EigenLayer. Slashing ensures rational adversaries will choose to behave in a way that drives consensus because doing anything else is economically worse. In other words, slashing is used to punish malicious validators that (try to) lie about the state of the chain—by slashing the capital they put at stake.<br> <br> In practice, though, honest validators get slashed for many reasons. If we look at Ethereum slashing events over the years, we can attribute slashing to:<br> <br> - **Risk 1: Operational mistakes.** To run highly-available, scalable infrastructure, operators typically have fallback clusters they switch to when their primary cluster goes down (e.g., because of an outage). They similarly move validators across machines to balance the load across their cluster(s). Unfortunately, moving validators across machines or clusters introduces a huge risk: the same keys could be online simultaneously in two (or more) places—and sign conflicting, slashable messages for the same block. In practice, this happens and multiple validators have gotten slashed because of this.<br> <br> - **Risk 2: Misconfigurations.** By default, using an off-the-shelf validator client with a local keystore or <a href="https://eips.ethereum.org/EIPS/eip-3076" target="_blank">EIP-3076</a> style remote-signer like Web3Signer forces operators to make a trade off: give up on performance or reconfigure the defaults and risk getting slashed. In practice, <a href="https://www.dlnews.com/articles/defi/ethereum-stakers-fearful-of-getting-slashed/" target="_blank">multiple node operators have gotten slashed</a> because they misconfigured their anti-slashing database, unsafely optimized Web3Signer's anti-slashing database, or turned off anti-slashing to improve performance.<br> <br> - **Risk 3: Bugs in validator clients:** Bugs in validator clients have similarly resulted in slashing. In <a href="https://research.lido.fi/t/slashing-incident-involving-rocklogic-gmbh-validators-april-13-2023/4399" target="_blank">April 2023</a>, for example, a LIDO operator experienced a power outage that forced them to move validators from one machine to another. They properly deleted all the migrated keys from the validator client instances, and even confirmed that those keys had been deleted. Unfortunately, a bug in the Prysm validator client meant that the confirmation was false: those _keys hadn't actually been deleted_. When the operator re-started the buggy client, it re-imported the supposedly deleted keys and started signing slashable messages.<br> <br> While at the surface these risks seem like operational risks, in reality they are security risks—the security of a protocol depends on running secure validators. And these are not the only risks:<br> <br> - **Risk 4: Insider threats and hackers:** An adversary that breaches a node operator's infrastructure (e.g., as was the case with <a href="https://research.lido.fi/t/lido-on-ethereum-node-operator-infstones-platform-vulnerability-investigation-november-22-2023/6001" target="_blank">another LIDO operator in November 2023</a>) could potentially slash (or exit) all their validators. They can do this even if they can't extract the keys—e.g., by subtly altering a configuration, spinning up a backup cluster, or kicking off a failover.<br> <br> ## Restaking inherently increases the slashing risk<br> <br> Operators can _restake_ their ETH (or LST) to receive extra compensation for providing crypto-economic security to new protocols—AVSes—built on top of EigenLayer. This is a two step process:<br> <br> 1. **Restaking:** When staking a new validator on the Ethereum Beacon chain the operator deposits 32ETH and sets the withdrawal addresses to an EigenLayer pod, instead of the address of a key they own. In doing so, they place their (staked) ETH as collateral—and if they misbehave (once slashing goes live on EigenLayer), they will not be able to withdraw their ETH, i.e., they will be slashed.<br> <br> 2. **Validation:** Operators choose the AVSes they wish to serve by explicitly opting in and running those AVSes' execution containers alongside their normal Ethereum validator client. These containers are effectively new validator clients that implement the corresponding AVS's protocol.<br> <br> Like Ethereum and similar proof-of-stake protocols, AVSes define their own slashing conditions (e.g., no double signing) and enforce these conditions objectively on-chain, i.e., honest operators provide evidence of misbehaving validators (e.g., signatures of two different messages at the same block height by the same validator) to the AVS contract which then slashes the misbehaving validator (by denying its ability to withdraw the ETH it restaked).<br> <br> Like with Ethereum, it's impossible to distinguish between a malicious behavior and an honest mistake. This means honest validators can get slashed because of operational mistakes, misconfigurations, and bugs in the validator client (the AVS software). The opportunity for mistakes and misconfigurations scales with the number of AVSes an operator opts into: the more configurations and the more complex a devops setup they need to run, the more likely it is that things will go wrong—and that they will get slashed. There are some additional risks beyond this:<br> <br> - **Risk 5: Lack of client diversity.** Unlike Ethereum, where operators have multiple validator clients to choose from, most AVSes will—at least for a while—only have a single option. This means a critical vulnerability or bug in the AVS client could be catastrophic. This is inherent to any new protocol, and over time we will likely see different client implementations for successful AVSes that will allow operators to diversify their risk. The reason the lack of client diversity is worth highlighting though is because slashing events are not isolated and some slashing conditions are not compatible with anti-slashers.<br> <br> - **Risk 6: Slashing events are contagious.** If an honest validator opts-in to validate for multiple AVSes, getting slashed by a single AVS (e.g., because of a bug in the AVS container or a mistake migrating the validator) means they are no longer providing security for any of the other protocols either—and this includes Ethereum. In other words, getting slashed by one AVS is the same as getting slashed on all protocols. This means a bug in one AVS client impacts others AVSes too. It also means misconfigurations and operational mistakes, which inevitably scale with the complexity and number of AVSes an operator runs, are considerably more serious. <br> <br> - **Risk 7: Slashing conditions can be incompatible with anti-slashing.** Ethereum's slashing conditions are compatible with anti-slashing, i.e., Ethereum's slashing conditions can be efficiently approximated and enforced off-chain (e.g., as described in EIP-3076), ensuring that validators never sign slashable messages. Other slashing conditions can be similarly compatible with anti-slashing. For example, to prevent double signing it is sufficient for the anti-slasher to record, for each key, the latest block height and signature they produced and refuse to sign messages at lower heights or different messages at the latest height. Not all slashing conditions can be approximated and enforced using anti-slashers though. Unfortunately, this means operators have to trade off between their validators' performance (availability) on such anti-slashing incompatible AVSes and the security (slashing) of these validators across all the AVSes they opted into.<br> <br> ## Reducing slashing risks with CubeSigner<br> <br> CubeSigner is a scalable and highly-available key manager platform we built to exactly eliminate the security—and especially slashing—risks validators face. It does this in two steps:<br> <br> 1. **Safeguarding validator keys in secure hardware.** (specifically, <a href="https://aws.amazon.com/kms/" target="_blank">HSM</a>-sealed <a href="https://aws.amazon.com/ec2/nitro/nitro-enclaves/" target="_blank">Nitro enclaves</a> in AWS). Validator keys stay in secure hardware from generation to signing—and since this hardware is designed to prevent key extraction, no one—not Cubist, the node operators, nor an attacker—can see (and thus copy) the validator keys. This means there can't ever be two copies of a key that could potentially double sign. It also means both CubeSigner and the node operators can enforce strong policies on keys (e.g., from anti-slashing, to ensuring a set of keys can only be accessed from a particular cluster, and restricting validation to a particular set of AVSes).<br> <br> 2. **Automatically applying an anti-slashing policy to every validator key.** This policy—the anti-slasher—records information about the history of each key, e.g., the most recent signature that the validator key has produced. On every signature request it receives, CubeSigner then uses the anti-slasher to check (against the history of the key) if signing the message is safe, i.e., if signing the message would result in the validator getting slashed. If the message is slashable, CubeSigner will refuse to produce a signature. Since the slashing conditions are chain-specific, the <a href="https://www.securestakingalliance.org/" target="_blank">Secure Staking Alliance</a> is collaborating on writing anti-slashing specifications like Ethereum's EIP-3076 for different AVSes.<br> <br> Unlike other remote signers like Web3Signer, the CubeSigner anti-slashing policy is globally enforced (by default) and cannot be disabled. And because keys never leave hardware, this means that even if an attacker compromises the node operator's infrastructure, they cannot sign slashable messages. A corollary to this:<br> <br> - **Operators can make mistakes.** Migrating validators across machines (e.g., during regular maintenance) and clusters (e.g., during failover) doesn't introduce slashing risk. The global anti-slasher ensures that even if there are multiple clients configured to use the same keys they cannot double sign.<br> <br> - **Misconfigurations are not fatal.** Because the anti-slashing policy is decoupled from the node operator's infrastructure and cannot be disabled, validator clients can be misconfigured without slashing risk.<br> <br> - **Bugs in validator clients and AVSes won't result in slashing.** Bugs in validator clients and AVSes similarly cannot result in slashing. The anti-slash policy is specific to the chain, not a particular client implementation—so even if the client tries to sign bogus messages, the validator doesn't risk getting slashed. This also means the lack of client diversity is less of a risk: node operators can opt-into an AVS early, when there is no client diversity, without having to worry about a catastrophic bug in the client slashing potentially thousands of their validators.<br> <br> - **Slashing risks do not scale with the number (or complexity) of AVSes.** Without anti-slashers, the risk of getting slashed scales with the number of AVSes a validator opts into—and the risk is fatal. With anti-slashing, the risk is in getting the anti-slashing policies right. Since policies are orders of magnitude smaller than, for example, the corresponding AVS software and only need to be written once (whereas clients need to be updated regularly), this risk is considerably smaller—and operators can run redundant anti-slashers (that ideally ship with the AVS containers) locally to further minimize this risk.<br> <br> All slashing events on Ethereum would have been prevented by using CubeSigner. As we onboard new protocols, implementing their anti-slashing policies much like that for Ethereum (and opting-out of AVSes whose slashing conditions are not enforceable as such) can similarly minimize slashing risk when restaking. This, in turn, minimizes the trust users need to place in restaking. Learn more about CubeSigner’s architecture and design points in this blog <a href="https://aws.amazon.com/blogs/database/use-aws-nitro-enclaves-to-build-cubist-cubesigner-a-secure-and-highly-reliable-key-management-platform-for-ethereum-validators-and-beyond/" target="_blank">post co-authored by AWS</a>.<br> <br>