Finding Compatability with Restaking Cloud

Governance
1

Background

Restaking Cloud is a restaking ecosystem that allows all validators to restake their ETH without unstaking. This intuitively includes Rocket Pool validators which are the beacon of decentralization for Ethereum. Restaking with Restaking Cloud will increase rewards for Rocket Pool node operators while not increasing the risk to the underlying principle of the validator.

There has been considerable outreach from Rocket Pool node operators to the Restaking Cloud team for guidance. This is not something that Restaking Cloud can decide. Due to Restaking Cloud’s compatibility with all validators, nothing is preventing Rocket Pool Node Operators from joining Restaking Cloud today beyond social consensus.

Key Links

Abstract

This proposal will outline methods and solutions to enable Rocket Pool stakers to restake with Restaking Cloud. There are a couple of solutions, and none will hinder Rocket Pool’s node operators’ autonomy. In Restaking Cloud, rewards are distributed via points as well as kETH (always redeemable for ETH) and other tokens. All of these are ERC20. Because Rocket Pool does not accept ERC20, a DAO consensus is required.

Relevant Restaking Cloud Info

  • rETH holders can restake their tokens once the LST route becomes available. This post will focus on node operators and RPL holders.
  • Restaking Cloud has two protocols K2 and Node Cloud.
  • Restaking Cloud has its own K2 payout address.
  • To restake, RP operators need to run a lightweight sidecar on their node called MEV Plus with a module called Native Delegation. It takes 10-20 minutes.
  • Restaking Cloud is built for compatibility with all Ethereum validators and node operations including Rocket Pool.
  • The principal stake of validators is protected in Restaking Cloud via K2 Protocol’s automated stake management for availed restaking markets.
  • K2 Protocol is the default route for restaking ETH in Restaking Cloud.
  • K2 does not require any additional software because not all networks that require restaked ETH security require a node operator. Node operators are still compensated for providing their ETH at stake.
  • Networks that require node operators can use Node Cloud (another protocol within Restaking Cloud). All restaked services and node operations in Node Cloud are actively tracked and reported using a proprietary ZK gadget.
  • Restaking Cloud’s K2 Protocol is in a Private Mainnet and Node Cloud is in a private testnet. Both protocols are built and functional.
  • Find an FAQ on Restaking Cloud risks here: https://blog.restaking.cloud/the-risks-of-restaking-faq-22a6d8121fed

Benefits for Rocket Pool

Restaking Cloud’s K2 protocol tracks all slashings and payouts in realtime. It maintains a full ledger of validator opt-ins and monitors all restaked services. Due to the ability to track all participants in realtime, it can eject networks and middleware for coordinated degradation and keeps validators protected at all times. Any network and middleware that wants to access Restaking Cloud does so as a paid for service paying continual interest thus providing restakers with a more stable yield in kETH.

  • Principle protected restaking deposits
  • Yield without running additional services for protocols (there is an option for additional work and additional rewards)
  • Baseline yield is in kETH
  • Fully compatible with Eigenlayer
  • Outsized weightage of points during Private Mainnet

Risks

Restaking Cloud restakers do not encounter the same risks as other restaking protocols. This is because the whole restaked ledger is actively managed by K2 protocol for its slashing and payouts in realtime. All restaked services are monitored via the K2 reporter; It ejects any network when effectiveness causes correlated degradation >30%. This prevents any long range attack and contagion to the principle stake. The maximum downside for a restaker is that they may not yield anything from K2 in the short term until the global yield pool recuperates.

Mitigation of smart contract risk is addressed by keeping a detached state replicated validator registry of active validator stake balances of those who opted in for restaking from the consensus layer. It stays in an async checkpointed reconciliation for yield claims. Service flow (Restaking Cloud yield) is only claimable for active validators on the consensus layer. If they exit, it will reduce the claim in sync with the Beacon chain<>execution layer clock.

The concept of reusing a validator’s security while maintaining it as a safe asset was brought to the public eye back in 2022 by Blockswap Labs CEO Matt Shams at an Ethereum Foundation event at Devconnect.

Matt Shams — ETH as a long term collateral for rollup centric future (ETHconomics @ Devconnect 2022) https://youtu.be/6FmiXi1L1Z0?si=932nEfJhPJjV8fwP

There is an FAQ on risks that can be found at the link below.

https://blog.restaking.cloud/the-risks-of-restaking-faq-22a6d8121fed

The module for restaking that needs to be run as an additional client on the validator is called MEV Plus - native delegation module. It is similar to MEVBoost and can not touch the balances of your validator. It is available to view under and open source MIT license.

Ongoing Eigenlayer Efforts

It is understood that the DAO has a potential research grant for a solution for RP built directly on Eignelayer. This document is not intended to derail those efforts as Restaking Cloud is fully compatible with Eigenlayer validators. It could be in the DAOs best interest to pursue multiple restaking protocols wherever possible. Restaking Cloud is designed to be futureproof with compatibility for various restaking protocol designs.

Many staking validators might be participating in other staking protocols such as Eigenlayer etc, this is 100% compatible with Restaking Cloud. Restaking Cloud is a compliment for all ETH stakers. The only criteria is that the underlying validator has an active status on the consensus layer.

Articulating a path for the DAO to integrate with Restaking Cloud should be fairly quick.

Two Options

There are two clear paths available for the Rocket Pool community to consider when Rocket Pool node operators participate in Restaking Cloud. It is possible to start with Option #1 and work towards Option #2. Both of these are entirely compatible with all other DAO efforts including working with Eigenlayer.

Option #1

In Rocket Pool there are two withdrawal addresses - Protocol withdrawal credential (smart contract) and user withdrawal address (EOA / smart wallet). Rocket Pool node operators could point all Restaking Cloud yield they earn to the user withdrawal credential.

Pros

This is a simple solution and doesn’t require any changes to protocol operations. Rocket Pool node operators who opt in are rewarded, while those who do not will not receive any rewards.

Cons

RPL holders would not see points or yield from Restaking Cloud via Native Delegations from Rocket Pool nodes.

Option #2

Rocket Pool DAO provides an EOA or smart wallet address (SAFE) for Rocket Pool node operators to direct all rewards and points to, by setting it as the K2 payout address.

Pros

All rewards will be distributed to the set address and can be redistributed as the DAO decides.

Cons

Those who do not restake could receive restaking rewards. A fund splitter may be required to reconcile the registered validator BLS Key and operator addresses along with the joining time. The Restaking Cloud team could provide this if there is sufficient demand and interest from the community.

Looking Ahead

Restaking is becoming a large part of the Ethereum ecosystem and Rocket Pool can utilize both Restaking Cloud and Eigenlayer to generate additional revenue. It is up to the DAO to determine the best path forward. Restaking Cloud is inclusive to all validators on Ethereum that have an active validator status. The Restaking Cloud team is happy to give a technical presentation or provide supplemental materials to the Rocket Pool community.

2 Likes
2

Thanks for bringing this opportunity to the RP community. I look forward to hearing what others think about this proposal.

For Restaking rewards, there seems to be less risk than with Eigenlayer since there is no need to change the Withdrawal address.

A question… with the proposed Option #1, how could RP NOs test this out? aka for Rocket Pool NOs to point all Restaking Cloud yield to their withdrawal credentials?

3

If anyone else is wondering how this works, here’s what I learned after reading the post and links:

  • you run their software called MEV Plus in addition to CL/EL/MEV-boost
  • you don’t change your withdrawal address to their address
  • you don’t change the fee recipient to their address
  • they slash your unclaimed restaking rewards if you misbehave
3 Likes
4

Thanks for translating.

How do they extract value from you in order to even give you rewards in the first place? Does mev-plus steal your mev?

2 Likes
5

you can simply point K2 payout address to your user withdrawal address (EOA / smart wallet), or any Ethereum mainnet address. This can be changed anytime. The cons of this are specified in the proposal above.

6

No- Native delegation module (mev-plus) only deals with K2 protocol and its yield; it cannot interfere with your block fee-related things.

7

If I point my beacon node at a mevboost proxy it most certainly can interfere.

8

You’re saying that NOs do work, AVSes pay for that work, and the protocol passes on some of that payment. But the NO has little incentive to do good work - they are only aligned by “potential future rewards”, which means they may be willing to lie to the AVS for very little money as there’s no principal to slash. In other words, why would an AVS pay for this?

Said another way - what does this have to with staking on a validator at all? Why couldn’t I just run the AVS software standalone? If you can’t slash the validator principal or any validator rewards… what’s the connection? It seems about as relevant as requiring the people running the software to have a red car. So far the only connection seems to be the MEV-boost stuff… which is purely a security hole if you’re saying that the “normal” MEV rewards aren’t meant to be slashable.

image

3 Likes
9

Thanks for all your queries; they are greatly appreciated. Trying to address them below in multiple replies, with a limitation of links in each post:

We have no AVS. However, an AVS can be registered as kNetwork and be served by Node cloud Preferred node operators; market services are composable; the Restaking cloud has a dedicated protocol known as K2 that does all modular restaking management, and payouts for restakers, also manages the restaked services risk in real-time.

  • Restakers: Outsource restaking to K2; in return, K2 monitors and protects the restaker underlying staked ETH and maximizes yield from the restaking market. At the same time, it continuously monitors its health and ejects it from restaked security if it degrades below the threshold. All slashing is honored in real time, registered by reporters, and paid from the global yield pool socialized.

  • Restaked services: Outsource the job of securing enough restaked ETH for a fixed cost for a yearly lease at a very low rate by K2 interest rate. In return, it gets real-time slashing protection in ETH and only pays for the tenure it utilizes the restaked ETH security on a pay-as-you-go basis.

  • Both SBP and Node Cloud are receiving restaked ETH delegations via K2; It’s the unified protocol that protects all restaker and serves the restaking market, similar to how Rocket Pool ensures rETH deposit yields and node operators receive enough delegations from the market at the same time maintaining high performance on the decentralized staking network.

MEV plus (maximal expressive value) is not MEV boost; MEV plus is a separate standalone ecosystem part of PoN open source stack that has many modules, and K2 native delegation is one of them; you can see more on MEV plus presentation: https://youtu.be/NjhLV9A4xbQ?si=-4ZvCh27TNcB21I_

10

There are two types of yield sources in the Restaking Cloud now for restakers:

  • K2 direct restaking market (SBP) yield in ETH, and if there is a respective native token emission from an SBP incentive, those yields are socially prorated to all K2 restakers.
  • Node cloud extended market through Preferred Node Operators delegation yields in associated kNetwork ERC20/altcoins.

Yield comes from restaking market: K2 Partitioned interest rate explains how K2 protocol charges the stake shard (SBP) for each restaking market: https://youtu.be/q4D0M5kyS_s?si=cZKHXpzZZe_iXC-9&t=3070

Node Cloud and PNO walkthrough: https://youtu.be/20L94NAOZ-I?si=Bb1GzwfKv8-EIIsO

11

Key attributes of Restaking Cloud protocols:

  • No Oracle

  • No Veto

  • All slashing and yields are real-time, with no delay

  • Fully autonomous and immutable on smart contracts

  • Ready available Zk gadget for programmable slashing and reporting logic

We have included a Rocket Pool dedicated tutorial for native delegation on our docs for better testing guidelines: Restaking Cloud Docs

1 Like
12
  • it’s Rocket Pool, not Rocketpool
  • it’s minipools, not mini pools
  • it’s the smoothing pool, not the smoothening pool
  • smartnode uses docker, web3signer and mevplus should also run in docker containers
1 Like
13

Since you don’t slash the 32 ETH or the beacon chain rewards or the execution layer rewards (MEV), why does your software need access to my validators?

Can’t I just generate a BLS private-public key pair and participate that way?

2 Likes