Protocol Development - Q2 2024

Governance
1

Hello everyone!

This is a rather delayed quarterly roadmap update - so deepest apologies for that.

This is the roadmap update for Q2 2024.

Houston
Houston smart contracts have undergone rigorous auditing, and the reports are now live on our website at https://rocketpool.net/protocol/security. We’ve also developed and deployed new Houston features on the website. A successful beta testing phase was conducted in collaboration with our community, incorporating valuable feedback and bug fixes into our smart node. Additionally, our team has prioritised and resolved an important bug bounty issue in the Houston code.

We’re excited that Houston is set to launch on June 17th! For more information, please read Dave’s Medium article at https://medium.com/rocket-pool/rocket-pool-houston-launch-b056ca1a6c10. As of now, the smart contracts have been deployed, and we’re in the process of voting on the ODAO upgrade proposal.

Furthermore, we’ve worked to merge our current Snapshot voting system with our new on-chain voting mechanism. This unified approach combines the benefits of gasless voting on Snapshot with the direct power of on-chain voting. A detailed Medium article is coming soon, giving you a heads-up on what to expect.

RPIP-28 and RPIP-30
These RPIPs have been ratified by the pDAO for inclusion in the protocol but unfortunately they were ratified after the Houston feature cutoff.

  • RPIP-28 Deposit Under the Minimum - allows creating a new minipool even when under the minimum by supporting an atomic RPL stake and node deposit
  • RPIP-30 RPL Staking Rework - aligns RPL reward spend with rETH capacity created.

Initially, we planned to roll out an intermediate update between Houston and Saturn to deliver these enhancements. However, our focus on Saturn has intensified, and it now appears more likely that these features will be included in the Saturn release rather than being deployed beforehand.

Saturn
Saturn has come through ideation with the community Rapid Research Incubation process (Rapid Research Incubation Begins!). The community have invested significant time in research and analysis and are drafting Rocket Pool Improvement proposals: Tokenomics Rework | Rocket Pool Improvement Proposals. The team have engaged RPIP authors to ensure feasibility and technical considerations.

The team have been breaking down the draft RPIPs: assessing how they affect technical design; and determining the scope of changes to the protocol.

From a development perspective we have been focused on Megapools, a crucial component of Saturn. Recently, we’ve had to adapt to the upcoming Ethereum EIP ‘Increased Max Effective Balance (EIP-7251)’. We’ve carefully reviewed how this EIP will impact Rocket Pool overall and specifically if it affects our Megapool implementation. As part of this effort, we’ve provided feedback to Ethereum researchers on EIP-7251. Meanwhile, we’ve been refining our initial Megapool prototype to bring it up to production-ready standards.

v2 Smart Node
A notable mention is the Smart Node Version 2, a ground-up redesign aimed at significantly improving performance, maintainability, interoperability, and the overall experience for node operators. The v2 beta testing phase is currently underway, with a formal release planned following the Houston launch.

Please let me know if you have any question or concerns.

11 Likes
2

Thank you for the update!

My understanding is some parts of Saturn require Pectra and some don’t. Is the plan to wait for Pectra and then ship, or to cut it into Saturn 1 and 2, one pre and one post Pectra?

With the rough assumption that Pectra lands in a year, Q2/3 2025.

4 Likes
3

So it depends. We are locking down a key decision, whether Megapool relies on MaxEB or not. If it relies on MaxEB then Saturn 1 would have to be after Pectra.

That said, we haven’t made that call yet and we are conscious that Pectra is a moving target.

4

I strongly favor avoiding this dependence. Time to market vs competing solutions is likely to be quite important and have a lasting impact. I do understand that the team believe this would simplify megapool implementation appreciably.

As you note Pectra is a moving target.

EIP-7251 doesn’t seem like it’s finished either. Notably, it talks about setting custom ceilings, but has no related specification. If that’s controlled from the withdrawal credential, we’re still ok, but if it’s controlled from the validator credential, I don’t think RP would be compatible. I suspect that it is intended to be from the withdrawal credential like the partial withdrawal requests in EIP-7002, but I’m not sure. I’m guessing this would be reliant on EIP-7685, which is also under review.

Some other tradeoffs in using MaxEB off the top of my head:

  • The current ongoing nature helps protect rETH holders; once funds are skimmed, they are no longer subject to loss by suboptimal node operation. For MaxEB 0x02 credentials, partial withdrawals will not be ongoing and will cost gas. Since our methodology simply looks at “amount over principal”, this means if an NO operates well for months until time t and then badly for a month they will lose less (and thus rETH will lose more) if funds have not been skimmed recently. This issue is exacerbated for small bond size.
  • Elsewhere the benefit of compounding was called out. This is only a benefit when rETH demand is high. When rETH demand is low and folks want exit liquidity, compound prevents any rewards from reaching the exit.
  • We’d need to rewrite a fair number of things to support MaxEB; I don’t think it’d be toooo hard if we incremented the ceiling by steps of 32 ETH (where it was easy the spec was written about deposits rather than validators, but would still have changes). If we allowed compounding, I think this would take quite a lot of thought/work.

TL; DR – I don’t think it’s a freebie. I think it requires serious thought in a number of places. There are multiple unfinalized items and an uncertain timeline.

2 Likes