Title
A short title that conveys the idea.
Why is this important for RP?
This grant would pay a dev or multiple devs for developing a smart contract solution that would solve node scaling in the absence of new node operators joining the pool or spinning up new minipools to ensure optimal utilization of the pool’s ETH to get the target APY for rETH holders.
Full Description
Rocketpool is currently facing growing pains due to a lack of new node operators to begin putting the ETH sitting in the pool to work on their own minipools. As a result, it’s hurting the annual returns of rETH and since the pool is sitting at the cap, it also means that the demand for additional rETH can not currently be met.
This grant would set a clear goal to establish a smart contract system that would allow users to deposit ETH, which some ETH would be converted to RPL and the rest used to deposit for a minipool and would launch nodes and minipools on multiple cloud providers (scaling decision/planning TBD) to avoid centralization. The pool would, if operated by rocketpool’s parent co., only launch a new minipool or node to meed capped supply of ETH in the pool (or above a safety threshold).
Since the pool would be operated autonomously by the protocol, there would be no owners and all rewards would be deposited straight back into rocketpool, including RPL rewards (if elected to collateralize higher than 10%) that would be converted back into ETH to be used to increase the APY on rETH.
Digital Ocean, Amazon Web Services, Microsoft Azure, and Google Compute Engine (henceforth referred to as “cloud providers”) have facilities to automatically create accounts and fund paying for accounts. Some of the rewards generated from the automated system would go towards paying respective cloud providers monthly operational bills. The bills for these services can also be set up to reserve capacity for time duration either with “all-upfront”, “partial”, or “no upfront” (that’s how AWS is set up, but the others are similar) for various durations which result in sizeable cost savings of that infrastructure.
After withdrawals are enabled, the pool can spin up and down these resources fungibly as new node operators come online and enter the staging pool. When there is a lack of ETH available to launch a new minipool and there are nodes running in the automatic pool, the automatic pool can spin down the node and have all ETH returned to the pool for the new operator to help encourage new operators and further/better decentralization. Also, these accounts from cloud providers can be operated without any ownership aside from an email address and a payment method. The payment method could be automated by something like bitpay or similar service that crosses the tradfi and crypto ecosystems and allows some of the rewards to be converted to pay these bills and still retain sizeable rewards.
Also, I do not believe this would inhibit or prevent a professional node operator from creating their own similar business and obtaining investors in said business or creating their own token and protocol on top to manage an SaaS offering to clients that would like to get increased yield through a similar strategy over rETH (I have a plan for a similar business product to do this already, but have not begun working on it yet and one that I think a lot of professional NOs are looking to roughly do on their own soon).
Given the general requirements needed for a node (4 cores (or 2-cores + SMT/HT), 8GB RAM, and 2TB), the cost to run a single node per month using aws nodes as a baseline would result in a rough cost of:
~$250/mo per node.
A collateralization of ~40% would more than cover those costs, but that’s before building a properly scaled system. A properly scaled system could be reduced in cost as the primary cost per month is for the storage requirements (which would grow over time). Also, that’s just the AWS estimate.
A proper scalable design would have an ETH1 client, ETH2 client, and validator client all separated out from one another. Thus, the storage requirements would be drastically reduced as you get to 2+ minipools spread across multiple nodes (for redundancy and better scaling). It could also leverage other technologies to reduce cost on the validator client side (such as using container services from the cloud providers) to further improve cost-efficiency. As you add more validator clients, you wouldn’t need to add more ETH1 and ETH2 clients, you would just need a new validator.
Also, most of the cloud providers have systems to give out credits/grants for various projects, which could further help reduce costs if rocketpool applied for these (though, they’re typically limited in the term they’re granted, but could reduce/eliminate start-up cost on the platform to allow the first month of RPL rewards to roll and get converted to fiat and pay for the bill automatically.
In the end, with an amount of minipools of 2 or more with an RPL stake at the current average (around 60% collateralization), it would pay for the infra and have a bit left over as buffer to increase the APY going back into the rocket pool or be held in kind to help smooth out monthly bills on the cloud providers.
A simple HA infrastructure would be 3 nodes per cloud provider in different regions/zones in case of outages and would then have a minimum of 3 providers to reduce offline risks for one cloud provider going offline due to issues with their services.
Concerns/Risks
- If such a thing were highly popular, it could potentially eclipse rETH itself and create shortages in one pool or another depending on the exact implementation.
- The main contracts would need to be upgraded, which would require an audit.
- It adds more complexity to the protocol, which could in-turn result in higher fees, lower returns, or vulnerabilities.
- Could result in centralization.
- Could misbehave and result in draining the ETH from the pool and launching lots of nodes, if an error exists in the contract(s).
Estimated cost (denominated in RPL)
This is going to need some serious discussion, because I think this is going to be a fairly substantial project. It may even just need to be an enhancement on rocketpool all-together and may not be appropriate for a grant, but needs to be handled by core devs. I would suspect it would need to be about 1500-1600 RPL (probably on the low side of what it should actually be).
Feel free to add additional concerns/risks that I may have missed.