Make oDAO health clearer

Currently voting stops at consensus, which means that if an oDAO node is even marginally slower than the others it may essentially never vote while being perfectly healthy. Or the machine could be off. There’s no way to disambiguate effectively.

If there’s community support I’d like to make an RPIP that says that we SHALL make it possible to track the ability of all oDAO nodes to perform their duties. It will say we SHALL make at least partial progress towards this soon, even if a complete solution requires smart contract changes.

Let’s get a community sentiment poll :bar_chart:

  • I support this
  • I don’t support this
  • Undecided on the general concept
  • Waiting on a concrete RPIP

0 voters

Possible implementation

The RPIP will include example implementations, but it will not require a specific one.

Alternating balance and price duties

This change can be implemented now.

Each oDAO node figures out its own index (eg, sort by join time). On an even update ((current_update_block - first_update_block) / blocks_between updates) % 2 == 0, nodes with even indices submitBalances right away but only submitPrices after waiting X minutes. On an odd update, nodes with odd indices submitBalances right away but only submitPrices after waiting X minutes. Nodes should do the work immediately and hold off on voting, so as to avoid unnecessary delay.

Vote past consensus

This change requires smart contract changes.

Essentially, it would just remove the check that currently exists when voting that consensus hasn’t already been met. It will not change the ability to execute at all, and we should be careful not to “re-execute” once the first execute has occurred.

If the alternating balance/price update change has already been made, this would only be needed for merkle tree root submission.

Preemptive FAQ
  • Don’t we need a little more complexity for the alternating case b/c the sides might not be over 50% to reach consensus?
    • No, they will just execute after the X minute time delay when the remaining folks freely vote.
1 Like

I think this may be somewhat moot. The Atlas watchtower now does reth price updates to the Polygon, Arbitrum, and Optimism messenger contracts on mainnet by the odao members taking turns in a round robin manner. No additional consensus is needed, as the update just reads the current network reth/eth ratio. With 18 members, each odao member will have to do one update to one of those contracts every 6 days or so. This should make it possible to coarsely track the liveliness of the odao nodes.

Maybe we want higher resolution on their liveliness then this can provide, but this should be a good place to start.

I think I’d like the visibility. I know some nodes haven’t done a particular duty for a very long time, eg.

The finding the index and determining turn logic from there should be quite portable to this purpose (can maybe even get functionalized as this would have it used in quite a few places).

1 Like

Price, balance, and rewards tree all exercise the RPC / REST APIs a different way. That one works, doesn’t mean the others do. Ask me how I know :sweat_smile:.

Having a way to track liveness across different types of duties would be helpful. Not least for the oDAO operator, as they can then, as long as a failed duty for reasons other than consensus also creates a metric, alert meaningfully on it and do something about it.

3 Likes

I’ll put my thoughts on these 4 improvements here. the ideas all seem good, I would support them being implemented, my critiques are going to be largely based on protocol and jurisdiction.

1. add a RPL related goal to IMC:

RPL liquidity is a very low priority to me, but i favor “IMC may support RPL liquidity”. Oracle security is somewhat important to me, but I favor “IMC may support RPL/ETH”. I think a broader mandate makes sense for elected positions, so that the IMC retains the flexibility to respond quickly to changing conditions without going through the RPIP process (for instance, i can imagine scenarios where injecting RPL liquidity support WOULD be critical for protocol health, at more than 5% of resources); if the pDAO feels that the IMC is not adequately managing funds, to me the the solution is to choose new members. And we just did that (notably, there are only ~3 community members that aren’t on IMC that have weighed in on this question-suggesting that the pDAO largely wishes to delegate responsibility to their chosen representatives on these matters).

2. Automatic challenge Response:

I think most (on oDAO and pDAO) can agree that automatic challenge responses are inadequate. If i had to choose between this solution or status quo, i would certainly choose this solution. However, to me it makes sense to refine this idea into a more elegant solution, since there isn’t a huge rush. I think there are plenty of reasons that 7 days may not be sufficient time for an manual response to oDAO challenge, particularly if the node is running fine and performing its automated duties; i think allowing randos to force etherscan to mimic obscenities is mildly entertaining but isn’t a good look for us; i think there could be some proactive proof of humanity (for example, whenever an oDAO node loads a new version, the next step is to broadcast an ‘i wuz here 1.9.2’ message, preventing a proof of humanity challenge until the next version upgrade).

3. avoid oDAO vote edge case:

This needs to be fixed, it should be a priority for the team. To me, this doesn’t seem to fall in the pDAO jurisdiction, and seems to make more sense as a community sentiment poll than an RPIP. While there need to be checks and balances, it makes more sense for the oDAO members to push this forward because it is a direct threat to their voting power. If the oDAO, including the rocket pool nodes, as an autonomous organization, feels the status quo is fine, then… :man_shrugging:. Fortunately, the author is on the oDAO too!

4. Make oDAO health clearer:

Again, I think we run into issues of who is subordinate amongst two ostensibly autonomous organizations. To me, this change is in the best interest of MOST oDAO members (the caring, diligent ones); and I think that newer oDAO members would welcome this transparency. However, I think this makes more sense as a community sentiment poll, but not an RPIP, because the oDAO should be governing itself. If they prove incapable of governing themselves, then we can try to step in.

We support changes to how votes submitted after consensus are handled which both:

  1. Provide the oDAO member feedback that they are functioning correctly (currently they see an error)
  2. Provide visibility into whether the oDAO member is online/healthy

We recognize this likely requires a contract upgrade. Ideally accomplishing both goals together limits the need for future changes.

1 Like

Draft RPIP - feedback welcome: RPIPs/RPIP-draft.md at odao_health_clarity · Valdorff/RPIPs · GitHub

Thanks for the oDAO perspectives @yorickdowne and @mike-u410!

@mike-u410 - the RPIP does have some short term suggestions that could be implemented more immediately, but agreed that a final form will need some SC tweaks. :+1:

1 Like

I can get behind the interim measures with the understanding that they are temporary. It requires ~full buy-in from oDAO members and there’s no protocol level enforcement, but definitely seems to accomplish both goals. Thanks very much for proposing it!

Totally support this proposal.

Effectiveness of the ODAO is critical and this proposal provides greater transparency to both the community and the ODAO members themselves.

1 Like

Draft was merged, Kane gave some feedback.

RPIP is under review before finalizing Improved Reference Implentation with Kane's feedback by Valdorff · Pull Request #42 · rocket-pool/RPIPs · GitHub. Last call for comments.

1 Like

The two odao duties I’d really like more insight into are tree generation and vote engagement. Whatever test we devise should involve tree generation as that is the most resource intensive duty. With voting I’d at least like to see all members vote each time, even past quorum. Perhaps we could add a “votepresent()” function if they don’t have a strong opinion on the proposal.

The rpip suggests just that, but with the existing functions instead of extra ones.