Since we are talking roadmaps, here are a few things that I’ve been thinking about. Please overlook my ignorance if I’m suggesting the impossible. Positive and negative feedback equally appreciated.
1). Mitigating isolated slashing risks in LEBs:
When the incentives for ETH staking were formulated, isolated (<1% validators) slashings were felt to be a slap on the wrist; enough to discourage carelessness, but not enough to scare folks from staking. Worst case scenario was just over 1 ETH, or ~3.25% of stake. At genesis, that represented about 2 months staking rewards; now it’s about 6 months staking rewards.
Rocket pool and other leveraged platforms amplify this particular risk. with a 16E minipool, an isolated slashing is up to 6.5% of stake, or ~11 months of staking. With LEB8, this is 13% of stake, or 1.5 years of staking. With LEB4 (assuming similar commission structure, maybe 12%), this will be 26% of stake, or 2.5 years of staking rewards. In a year or two, the staking rewards are expected to go down significantly with more validators, so probably double whatever breakeven timeframe (~5 years for LEB4).
Isolated slashings are usually caused by foolish behavior of some sort (ie, either double attestation with some sort of duplicate setup, or allowing malicious access to the node or SSH that allows for a griefing attack). These are almost invariably the fault of the node operator.
However… since we are trying to broaden the base of NOs to include less technologically saavy and even the theoretically saavy get hacked (sorry RP team oDAO nodes), does it make sense to idiot proof by:
a) increase documentation regarding the leveraged risks for isolated slashing in LEB8/4 (eg, the font should be 3x-7x as big as in Somer Esat’s guide), and increase documentation on hardening the node/SSH/client machine.
b) look into native doppelganger protection within the smartnode, to prevent double attestations across clients or machines (or clients that don’t do doppelganger protection).
c) Enact a killswitch for the smartnode that stops submitting attestations/proposals for all validators after a slashing is detected on any of the node’s validators, until manually restarted.
d) look into ways to decrease access to the validator key (ie partitioned SSD or something) from the command line in case of compromised node.
e) other way unspecified
2). Protecting rETH value from isolated slashings:
Isolated slashing (~1 ETH penalty) is almost always the fault of the NO, and should be borne by the NO. However, there is an easy way to stick rETH holders with the bill: keep more consensus rewards without distributing. If you keep > 1 eth consensus rewards without distribution, the loss can be largely subsidized by rETH holders; ironically this subsidization is more pronounced the lower the LEB (LEB16=43%, LEB 8=65%, LEB4=77%). This is particularly galling as correlated slashing will be far less subsidized, even though it is (theoretically) usually not the fault of the slashee.
The best solution I can think of is low tech and doesn’t require SC changes: A grant guarantee through the GMC to reimburse gas costs + (some minor bonus) for whoever first calls ‘distribute balance’ on the slashee, plus maybe a limited release POAP to commemorate it.
3). *withdrawn; thanks patches!*
Current scheme: changing withdrawal address requires a transaction from the old withdrawal address (specifying the new withdrawal address) and the new withdrawal address.
Problem: A compromised withdrawal wallet allows malicious actors to change the withdrawal address irreversibly, resulting in total loss of stake.
Solution: An opt in toggle for smartnode users to require a transaction from the node wallet (with new withdrawal address), the old withdrawal address (with new withdrawal address), and the new withdrawal address (simple approval) in order to change the address.
The possible scenarios that could come up are: A) withdrawal address compromised. B) withdrawal address key forgotten. C) node wallet compromised. D) node wallet key forgotten. E) node hard drive wiped. F) fat-finger the wrong but valid address (ie jared from subway’s) as the new withdrawal address.
IF A, then the new process allows recovery of 100% of stake, the old process ensures ~100% loss of stake.
IF F, chance of incorrectly putting the same wrong address twice is markedly reduced in the new process.
IF B, AC, or DE, both solutions have total loss
IF C, both solutions allow griefing slash, but funds otherwise safe.
IF none of the scenarios are true (ie safe node and withdrawal addresses, but you want to change withdrawal address for some reason), an extra transaction is required in the new process.