Hi everybody,
I wanted to formalize a discussion that’s been happening on and off in the Discord into a post here. It kind of blurs the lines between Smartnode releases, project governance, Oracle DAO duties and responsibilities, and protocol DAO voting so I’m not really sure where to put it but this seems like a good place to start. As usual, I’ll provide a little background context at the beginning for people who are just catching up to the conversation before going into the details.
Context
Protocol upgrades for Rocket Pool involve upgrading the Smart Contracts on the Execution layer. Generally these upgrades are very large events that take months to coordinate, develop, test, audit, and finally deploy. As an example, Redstone was the first example of one such protocol upgrade - development on it began in January, and it was finally deployed to Mainnet in August. That’s seven months start-to-finish. Development on Atlas has reached its first feature freeze and we’re preparing to enter the audit phase; while its start-to-finish time will be shorter than Redstone, it will still be on the order of months.
That being said, our node operators typically don’t interact with the contracts directly by hand (barring a few special examples of highly-technical community members). They use our Smartnode software to do that interaction instead. The Smartnode has enjoyed a much different, much faster release cadence than the contracts. As another example: in times of high churn such as what we saw during the weeks leaading up to the Merge, I would push Smartnode updates once or twice per week to ensure everyone’s configuration was as Merge-ready as possible. In terms of node operators, this cadence is important: node operators need to have up-to-date setups and up-to-date client versions regularly, and they need breaking Smartnode bugs fixed quickly so they can run their nodes correctly.
However, the Smartnode fulfills a second duty that has been brought to the spotlight in recent weeks: it runs the “watchtower”, which is the container that handles all of the Oracle DAO responsibilities such as shuttling information from the Beacon Chain to the Execution Layer, checking for the Withdrawal Credential Exploit, and (more recently) generating and pushing the Redstone Rewards Merkle Tree artifacts.
Process Changes
Now that the Oracle DAO is expanding and is responsible for the calculation of rewards off-chain, the community has expressed a desire to apply the same kind of due diligence to the watchtower’s functionality as the contracts receive. That means:
-
Governance discussions, proposals, and votes around major changes to the rewards tree’s structure and how it is calculated.
-
Sufficient time to allow for multiple independent implementations to test those changes and ensure parity with each other.
-
Longer periods between watchtower update announcement and activation to give the community and Oracle DAO members time to assess changes, submit suggestions or pull requests for adjustments.
We think this is the correct way to go as well. However, we want to balance this in a way that doesn’t conflict with the regular cadence of updates and releases that regular node operators have come to expect. In the medium term it probably makes the most sense to spin the watchtower out of the Smartnode entirely and have a completely separate container / binary just for Oracle DAO duties so we can do both of the above things at the same time, but in the short term where this separation isn’t technically feasible we’d like to take the following approach:
-
Smartnode releases will continue as normal.
-
Watchtower-specific changes, instead of going live immediately with new Smartnode updates, will now obey predefined specific target slots for enacting those changes.
-
This is analogous to the way the Ethereum core devs specify target blocks for protocol-level hardforks, and client developers provide clients that have both pre-and-post behaviors built-in along with the block / slot to switch over.
-
This is notably aimed at breaking changes to the rewards specification (and all other watchtower duties / submissions) that would cause the watchtower to disagree with earlier versions, or to fundamental changes in the watchtower duties.
-
It would not apply to simple bug fixes that don’t cause the generated artifacts / submissions to disagree with previous versions. Those would be delivered with new Smartnode releases as they are done today.
-
The changes would be first presented in a post here and relayed in our Discord to allow for a proper discussion. If contentious, they should be run through our usual Snapshot voting process.
-
When due diligence has been done (whether it goes to a vote or not), we will select a target slot for making them go live and apply it to future Smartnode releases accordingly.
Next Steps
This process is an amalgamation of a few sources, so I’d like to get everyone’s feedback first before making it canon. If it looks like there’s general agreeance without any major blockers, I’ll put together the post for the first of these major changes: rewards tree specification v2 (which has admittedly already been developed and tested by @Peteris and myself, but not deployed because we want it to go through the above process first if that’s what everyone lands on).
Note that this post is not about the rewards spec changes; this is about whether or not the process described is sufficient to have a conversation about rewards spec v2. Please keep your thoughts focused on the process for now.
Thanks everyone!
