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

Grants / Bounties
3

NB: This is a renewal

I’m using my draft template from: Draft Grant Renewal Application Template

What grant is being renewed?

Rocket Rescue Node - January 2023 GMC Call for Grant Applications - Deadline is January 15th - #3 by Patches

What work from the previous proposal was completed?

The original tech spec (https://gist.github.com/jshufro/a22724f06702c8342b5d1b29ee0a6190) was completed in full, and the Rescue Node launched on mainnet 2023-02-28

Additionally, from the Nice-To-Haves section of the tech spec, we have implemented the following:

  • Monitoring
  • Frontend

What work from the previous proposal is ongoing or pending?

None of the minimum viable requirements were left ongoing or pending. These remaining nice-to-haves are not completed:

  • Checkpoint Sync
    • Honestly, it fell off our radar, as there are so many checkpointz endpoints readily available.
    • I think I personally would prefer to move this to non-requirement, as there is some complexity with how prysm handles checkpoint urls.
  • Treegen
    • The original motivation was to automate preview generation, which was accomplished in a separate project (sprocketpool).
  • Non-mev-boost solo validator credential piggy-backing
    • Some research went into this. It should be feasible in certain circumstances, and will potentially be added in the future.

What work was not originally planned, but completed, if any?

What work is newly slated since the previous proposal?

I have tentative plans to add support for solo validators. This may manifest as a separate bounty proposal, as it would not change ongoing costs, but I’m also not sure what the scope of the work is, and if there is an appetite to do the development pro bono. Early research suggests changes across three of the github projects- rescue-ui, rescue-api, and rescue-proxy.

Are the results of this project entirely open source (MIT, GPL, Apache, CC BY license or similar)? If not, which parts are not, and why not?

  • AGPLv3
    • rescue-proxy
    • guarded-beacon-proxy
    • rescue-api
  • MIT
    • rescue-ui
  • Closed Source
    • infrastructure
    • secrets

Our infrastructure library remains closed source. Initially this was to make sure we didn’t create an attack vector, but I think we’re satisfied that we could open source it if there was a strong desire to do so. It provides little benefit to do so, except perhaps as a form of continuity planning.

Our secrets repo is closed-source and encrypted, and will remain so, for existential security reasons.

Benefits - enter N/A where appropriate

What metrics can you share on the success of the project?

Since launch, the rescue node has been used quite a bit to help node operators out of sticky situations. We haven’t retained a full history of metrics, however, there is 7 days available at https://stats.rescuenode.com

In less specific terms, how has this project improved the Rocket Pool ecosystem or benefited the Ethereum ecosystem?

We believe we’ve delivered on improving the node operator experience and protecting the rETH downside. We’ve seen marketing resources circulate touting the rescue node as a reason to join the Rocket Pool ecosystem, and our usage metrics support the narrative of its utility.

Team

Who has done the work, and have there been any changes to the team?

No changes have been made to the team:

  1. @ken is our general manager, and a ‘maintainer’
  2. @poupas is a ‘developer’ and ‘maintainer’
  3. @Patches is a ‘developer’ and ‘maintainer’
  4. @hanniabu is a ‘developer’
  5. @sleety still tolerates our antics, and has contributed to marketing materials pertaining to the rescue node since the original grant.
  • ‘developer’ here means someone who contributed code
  • ‘maintainer’ here means someone who has SSH access to the rescue nodes (i.e. a trusted party with regards to mev theft).

Poupas and I have handled the maintenance tasks pertaining to the infrastructure, and Ken contributes to the non-infra administrative side.

How have the individual constituents of the team been compensated?

Our original grant included a retroactive portion that was overpaid by the GMC. We were grateful for the vote of confidence. The funds were first used to compensate costs for poupas and myself that were incurred before the grant, and the remaining amount of the retroactive sum was split proportionate to the breakdown in the original request.

The ongoing portion of the grant has been held in a multisig and used to reimburse ongoing costs only. We are compensated more than the real cost of the infrastructure, so we carry a balance in this multisig, but intend to return it to the GMC when either the project winds down or we’ve established a healthy runway.

Here’s a full breakdown:

  • Retroactive Development:
    • Poupas - 86.49 RPL
    • Patches - 86.49 RPL
    • Hanniabu - 51.90 RPL
    • Sleety - 25.95 RPL
  • Retroactive reimbursement
    • Poupas - 15.29 RPL
    • Patches - 10.88 RPL
  • Ongoing infrastructure costs
    • Our only infrastructure provider that doesn’t give us a free plan is OVH. We have 5 baremetals and 1 VPS with them to run the client pairs and api/ui respectively.
    • Patches pays the bills
      • 2023-4-1 $418.90 - 9.57 RPL
      • 2023-5-1 $418.90 - 8.98 RPL
      • 2023-6-1 $508.90 - 10.41 RPL
      • 2023-7-1 $616.90 - 16.90 RPL*
    • The rising USD-denominated infra costs are due to the addition of lodestar and the VPS used for the api/ui
    • The fluctuations in RPL-denominated costs are due to the fluctuation in the RPL/USD price and the rising infrastructure cost as we’ve added features.

* EDIT 7/7: OVH just emailed us saying they overbilled us by $90 in July, which in retrospect makes sense. The 2023-7-1 bill should have been $526.90 and we received a credit. Ongoing costs will actually be $520 a month, as July’s invoice also contained a small proration amount.

The multisig (0x685bD857797306D030d53920C321d4d117aE3137) has 19.64 RPL and 1,524.45 USDC remaining as of this writing, which provides us with a 3-4 month runway, at today’s prices/costs.

How has maintenance been performed since the delivery of the project?

  • We perform the sysadmin tasks pro bono
  • Development has been pro bono since the retroactive payments, and will continue to be unless superceded by a bounty. We’ll avoid RAs so this can be an ongoing discussion.

Payment and Verification

Have the acceptance criteria been met?

Yes, we believe so. The criterion provided by the GMC was “Evidence of upkeep of rescue node”, and we believe we have been extremely transparent. See @rescue_node on twitter for historical insights.

What is the proposed payment schedule for the grant? How much RPL and over what period of time is the applicant requesting? Does this differ from the original approved amount?

We would like to keep the parameters the same- Originally we were approved for $900 in RPL (23.66 RPL) per month, and that has given us the necessary discretion to improve the infrastructure as needed.

Is there a measurable Return on Investment for the project?

Using the previous grant application’s cost modeling, we found that the protocol breaks even when at least 1-2 validators are connected. As of this writing, there are 175 validators connected, and anecdotally, I’ve seen as many as 400 and as few as 10, which puts the ROI in the range of 5x → 200x. That is to say, for every RPL spent on the rescue node so far, somewhere between 5 RPL and 200 RPL in value has been retained by the protocol instead of lost due to validator inactivity leak. NB, this includes the node operator share.

What is the breakdown of spending on development for the original grant vs. maintenance?

100% of ongoing funds are put towards reimbursing costs. Development originally cost 250.83 RPL, and maintenance (retroactive and ongoing) has cost 72.6 RPL.

With the launch out of the way, we can reasonably expect the costs of maintenance to be the majority of future spend, barring additional bounties.

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 serves on the GMC. He does not stand to benefit financially from this grant, and has not benefited financially from the rescue node at any point.

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?

No, we continue to treat maintenance pro bono and only spend RPL as reimbursement for infrastructure costs.

2 Likes