January 2023 GMC Call for Grant Applications - Deadline is January 15th

[Patches]

=== Project ===

What is the work being proposed?

• The Rocket Rescue Node - a collection of BN/CC pairs running in a guarded environment which Node Operators can use as a fallback in emergencies and during maintenance.

  • Tech Spec: Rocket Pool Rescue Node - Tech Spec · GitHub
  • Draft grant proposal, for records keeping: Click Here
  • Some older discussion, for records keeping: Click Here

Is there any related work this builds off of?

@poupas has a functional proof-of-concept which has been running since the merge. This upgraded version adds features and addresses some of the limitations of the prototype.

Will the results of this project be entirely open source? If not, which parts will not be, why, and under what license will they be published?

Development is nearing completion, and several components are already open sourced:

• Click Here for github
  • credentials library released under GNU AGPL copy-left license
  • rescue-proxy application released under the same
  • rescue-api application still unreleased, but will be released under the same
  • rescue-ui application still in development, but will be released under the same
  • infrastructure repository to remain private for the near term

It is our goal to open source as much as possible without compromising the security of the rescue node, so it’s likely all of the above projects will eventually be open sourced. I’d expect the infrastructure one to be open sourced last, as it is sort of the least re-usable anyway.

=== Benefits ===

How does this help people looking to stake ETH for rETH?

A theoretical pool staker with concerns about the performance of a non-professional staker may have their doubts assuaged by the knowledge that they have recourse for outages in the form of the rescue node.

How does this help rETH holders?

The rescue node provides additional financial security for rETH holders by improving the overall performance of the token. Simply, the rescue node facilitates better uptime for node operators, and since penalties for missed attestations are socialized across rETH holders as well as the node operator, there is a direct financial benefit to rETH holders.

Cost/benefit analysis will follow below.

How does this help people looking to run a Rocket Pool node for the first time?

The main benefit is in the form of added confidence. A potential node operator who is concerned about their ability to administer their own node may, similar to the theoretical pool staker above, find assurance in the availability of the rescue node to cover “worst-case” scenarios.

How does this help people already running a Rocket Pool node?

Following the merge, certain client combinations popular with Rocket Pool node operators became unreliable, and many node operators used the rescue node to either wait for bugfixes from client teams or change clients and resync without suffering downtime.

Since then, several more node operators have used the rescue node to resync after their chaindata became corrupt, or to switch clients due to ongoing reliability issues.

How does this help the Rocket Pool community?

Beyond the benefits listed above, the rescue node would be an exemplar of community members building services and tools to help one another.

How does this help RPL holders?

Tangentially, at best- improving other elements of the protocol adds value to its token.

What other non-RPL protocols, DAOs, projects, or individuals, would stand to benefit from this grant?

We’re pursuing some ways to grant access to solo stakers, which would help the people keeping Ethereum decentralized by running their own validators.

Will the resulting project be open source?

Yes, see above

=== Team ===

Who is doing the work?

• @poupas - Prototype, rescue-api, design, infrastructure + security
• @Patches - rescue-proxy, credentials library, design, general administrative stuff
• @hanniabu - rescue-ui
• @sleety - logo
• @ken - continuity insurance / bus factor mitigation
  Pull Requests from the broader community are encouraged

What is the background of the person(s) doing the work? What experience do they have with such projects in the past?

• @Patches - see my oDAO application for a full CV: Click Here
• @poupas - built and ran the prototype all on his lonesome
• @hanniabu - Several community projects with Ξther αlpha
• Sleety/Ken - Satellite roles for the project, so I won’t go into detail on the backgrounds, but you know who they are

What is the breakdown of the proposed work, in terms of milestones and/or deadlines?

We’re already running the prototype, and development on the other components is very close to completion. I expect we’ll be in beta before the proposal deadline, and launch quickly from there.

How is the work being tested? Is testing included in the schedule?

We’ve been testing the rescue-proxy on prater for a few weeks now. The credentials library and rescue-api application have unit tests, and we will manually do Large testing when each component is ready.

How will the work be maintained after delivery?

Maintenance will fall under the purview of the rocket scientists who feel technical enough to contribute. @ken will play a role in determining which rocket scientists have direct access to the nodes.

Due to certain trust assumptions, the list of maintainers will be made public to the degree that the maintainers are willing to identify themselves. We will try to keep the list short to minimize theft vectors.

=== Payment and Verification ===

What are the acceptance criteria?

A service fulfilling the above Tech Spec, with a website to issue authentication tokens and provide information and instructions to node operators who wish to use the Rescue Node.

What is the proposed payment schedule for the grant? How much RPL and over what period of time is the applicant requesting?

We’d like to be paid for a few categories:

1. Past costs - optional, but it’d sure be nice to be reimbursed

• Poupas has provided €172.15 out of pocket for the prototype, from before the merge until now
• Patches and Poupas have each provided $452.08 out of pocket for the lease for the proposed service, paid through January 31st, 2023

2. Development - time spent creating the service
   It’s hard to value one’s own time. In my draft, I requested 50 RPL to be split between myself and Poupas for putting in the engineering time. Now we’ve picked up hanniabu and asked sleety to make a logo, so I’ll amend the request to:
   • 25 RPL each for Patches/Poupas (about a month and a half of work, part time, each)
   • 15 RPL for hanniabu (Admittedly, this is just a finger in the wind)
   • 7.5 RPL for Sleety (Again, I don’t know how to price a logo design for a public good)
3. Ongoing costs - $406.40 a month, currently. We may decide to launch another VPS to host the UI/API components, but it would be quite a small one.

We’ve been thinking about this service as a public good, and since the maintainers will be Rocket Scientists who will receive a portion of the RS oDAO node income, we are not looking for ongoing compensation for maintenance.

Ideally, the GMC will work with us to pay for the ongoing costs, and pay us for development / past costs in a one-time payment after launch.

We intend to have a Donation link on the Rescue Node website, but would like to direct those funds to a wallet that the GMC controls. We’re not interested in receiving more (or less) than the upkeep costs. By directing donations straight to the GMC we avoid tax liability for them.

Full disclosure- @superphiz has provided poupas and patches with 100 and 50 RPL respectively, and the anonymous rpl-benefactor provided each with an additional 10 RPL. Phiz was characteristically vague about what the funds were for, but we used them to fund the initial costs of the rescue node. Due to receiving them when we did, we were able to secure hardware from OVH during their Black Friday sale, which substantially defrayed the infrastructure costs. The GMC is free to interpret this as paying for past and current efforts. It’s my understanding they ultimately originated from Worthalter.

How will the GMC verify that the work’s deliveries match the proposed cadence?

Fortunately the project is nearly complete. However, given the open source nature of the work, progress happens quite transparently. We’re also willing to make regular progress reports on development, and ongoing usage reports to the GMC after delivery.

What alternatives or options have been considered in order to save costs for the proposed project?

We’ve discussed several funding mechanisms, including requesting payment in RPL for access, or trying to fund the node from donations. However, given the nature of the project as a public good, we feel that a grant from the pDAO treasury is most apt.

=== Conflict of Interest ===

Does the person or persons proposing the grant have any conflicts of interest to disclose? (Please disclose here if you are a member of the GMC or if any member of the GMC would benefit directly financially from the grant).

@ken is a member of the GMC. He does not stand to benefit financially from this grant.
@Patches, @poupas and @ken are Rocket Scientists, which makes them members of the oDAO.

Ken’s role on the project is largely for continuity planning. Should poupas or I vanish, Ken has the ability to recover the various accounts used to lease hardware and register domains to ensure that the project continues.

Will the recipient of the grant, or any protocol or project in which the recipient has a vested interest (other than Rocket Pool), benefit financially if the grant is successful?

The recipients of the grant identified above as being compensated for their time/effort will benefit financially rather directly. Other than that, no, I do not believe we will benefit.

=== Addenda ===

Trust Assumptions

The largest security concern with the rescue node stems from tip/mev theft. Please familiarize yourself with this article: Exploring Eth2: Stealing Inclusion Fees from Public Beacon Nodes | Symphonious

In general, any public-facing beacon node has a vulnerability on this front. A bad actor could query the rescue node to set the fee recipients to their own address. As such, the tech spec mitigates this issue by tracking the appropriate fee recipient for any given validator, and rejecting requests to change it. Rocket Pool has a unique advantage in this area, because a valid fee recipient for a given minipool is either the smoothing pool or a fee distributor contract whose address is well-known. However, two areas of trust remain:

1. A node operator using the rescue node is explicitly trusting its maintainers to act in good faith. If one maintainer went rogue, they could feasibly steal tips/mev for any proposals submitted through the rescue node.
2. A node operator using the rescue node who has solo validators, and decides to use the rescue node for their solo validators as well, must have mev-boost enabled. This is because the beacon node specification requires a signed message for the register_validator endpoint, which tells us that the owner of the validator is the one setting the fee recipient, whereas the prepare_beacon_proposer endpoint does not- non-mev-boost validators only call the latter.

Any node operator who uses the rescue node will be asked to acknowledge that they understand and agree to these risks, and additionally to agree that they will not share their rescue node credentials with any third party.

Cost/Benefit Analysis

The main two beneficiaries of the rescue node are node operators and rETH holders, albeit in slightly different ways:

1. rETH holders benefit by improved performance from node operators. The fewer attestations missed by the protocol, the better the APR.
2. Node Operators benefit more directly- the fewer attestations they miss, the more commission they earn and the more rewards they earn on their own staked Ether.

A perhaps overly simplistic cost/benefit model would simply look at the total funds lost by the platform holistically for each missed attestation, and extrapolate to the number of validators such that the cost of the service is equal to the missed funds.

Based on today’s per-attestation reward of 14 Twei and today’s Ether price of $1200, an offline validator misses out on 1.7 cents in rewards per epoch, and incurs a penalty of 1.3 cents, for a total cost of 3 cents per epoch. Per day, an offline validator loses $6.75 (a bit over half in opportunity costs and a bit under half in penalties). The rescue node costs $13.54 per day at $406.40 monthly, so if an average of 2 validators (NB: minipools, not nodes) are using the rescue node, it breaks even holistically.

Now, there are other costs to being offline (missed proposals/mev/tips for example is an immeasurable cost, and I haven’t factored in sync committees, as they are quite rare), so the actual break-even is likely lower than 2 validators. Of course, if Ether appreciates or depreciates, the breakeven shifts, as the infrastructure costs are fixed.

At 455 RPL per inflation period (13 months), this would represent 1.12% of the yearly budget of the GMC.