Some random roadmap ideas

Node Operator Experience
1

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.

1 Like
2

This is brilliant. Until such a thing exists formally:

  • I’ll be distributing
  • If it’s not already distributed by 3 days after slashing(s), and you distribute the slashed minipool(s)
    • I’ll send RPL covering the gas
    • I’ll send you a 5 RPL reward
    • Distributes after the first don’t count. If there are multiple minipools and they’re distributed by different ppl, I’ll split the reward.

[updated 5-26 to be much more clear and avoid Val paying out unnecessarily]

3

I agree with Validorff. #2 grant reimbursement for whomever distributes is an easy “yes” vote from me

4

Change withdrawal address process for compromised wallet:

This is unfortunately non-upgradeable, but I like where your head’s at.

1 Like
5

I’m on it for the 3 recent slashings (1 done as a test, 2 at lower gas cuz why not save a bit).

6

I’ve stopped being embarrassed of coming up with bad ideas, so here’s one for a lido vampire attack.
@ramana @Invis if you have time can you look this over and see how feasible the coding aspect is or if there’s a better approach?

problems/allegory
  1. The only way to decrease lido dominance is burning stETH.
  2. Individuals with small amounts of lido staked ETH may want rETH but are effectively trapped by gas fees; however, these small passive holders are still contributing to the centralization problem, even if they send their stETH to the burn address.
  3. Selling on exchanges is gas inefficient for small amounts
    A) 3-4x more expensive than transfers
    B) rETH is almost always at a premium compared to stETH (so slightly more expensive)
    C) stETH->rETH trades raise the premium that ultimately gets arb’ed (ie someone other than the rETH buyer gets another chunk of profit and burns extra gas fees)

Allegory for Americans: gun buyback program. We’ll take your stETH and give you cold hard rETH. We’ll pay the costs of disposing of your stETH. We don’t judge; we don’t care why you have it or what you may have used it for in the past- that’s over now. The important thing is to get all that stETH off the streets before your kids get a hold of it and do something they regret.

Solution w/simple smart contract design:

  1. balance (50?) rETH and the ETH for gas provided by multisig
  2. Function for anyone to deposit <1 stETH and receive rETH based on rETH:ETH oracle value.
  3. Function to initiate stETH to ETH withdrawal via lido when stETH> 31
  4. Function to mint rETH when ETH > 31
  5. Function to empty contract of tokens/ETH to multisig when called to wrap up project
benefits/risks

Benefits:

  1. More gas efficient to transfer stETH to rETH than exchanges
  2. ultimately more rETH is minted (more total users + more rETH per user due to efficiencies)
  3. There’s no way for bots to arb this exchange, since none of the tokens will hit the market.

Downsides:

  1. Someone has to eat the cost of burning/minting. However, since this is for 31 ETH at a time I think gas will be <0.1% of burned amount. I’m sure we can find people to fund it.
  2. The lido withdrawal process is weird, has an NFT, and may take a few days.
  3. Smart contract risk
7

Technically speaking I think this smart contract is feasible and I’d be happy to write it. I won’t comment on the rest of the idea right now.

8

Step 2 in solution is problematic.

If there’s a rETH premium, the user is able to buy rETH more cheaply than market (and then optionally sell on the market). This should create pressure, up to and including minting stETH to swap here. Minor note about mint fee.

If there’s a rETH discount, the user can likely do better buying on the open market.

I think this works better using chainlink oracles instead of primary rates. That said, I’m uncertain if it works at all. Gas costs for uniswap are like 3.5x transfer for the swap + 2x transfer for approval. Here we’ll have 2 transfers, so the budget is 3.5x transfers and we have to cover our gas costs to burn/mint + the lost yield while waiting to swap (or the gas to do the per-depositor accounting of yield). I think I’d need to see some pretty realistic estimation to judge if this is a relevant enough win.

9
valdorff response

So how I’m looking at it: Currently we have arb opportunities, so anyone arbing can already do it, which is why premium/discount is approximately zero. The key points is that this wouldn’t create new premium/arb opportunities, because it’s essentially OTC and won’t change spot price. You could use it to arb with, but it would be very inefficient for an arb bot to go 1 rETH at a time unless the premium rises substantially. But if it rises significantly it still makes more sense to arb 10 or 100 ETH at a time on DEX.
Lost yield of 5 days is negligible. 0.07% or so. The rest of the time it would be sitting in one LSD or another.
I agree, the cost saving is not magnitudes different (I’m hoping for like 40% or so from DEX). But that means that someone who would now swap with 0.1 stETH would do it at 0.06 stETH instead; or would keep 40% of their gas in the form of rETH.
The gas cost for someone (us) to pay for is something, but not crazy. If we were to burn the entire lido stash and mint rETH, we’d see something like (700,000 [total validators] *32 [eth per validator] *.3 [lido share]/31 [stETH burned per transaction] *0.01 [ETH to mint rETH] * 2 [assuming lido burn gas cost about the same] * 1900 [ETH cost] = about 9 million USD to covert every stETH to rETH.