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
I support this
I don’t support this
Undecided on the general concept
Waiting on a concrete RPIP
0voters
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.
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).
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 .
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.
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… . 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.
@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.
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!
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.