After the latest issues with the oDAO and sparked by Greywizard’s oDAO dashboard, #trading had a discussion about how to better address the oDAO participation risk. We mainly talked about improving the ability to monitor oDAO performance and creating incentives for performance to improve. This is my and Valdorff’s attempt at a summary of the main ideas developed.
(In)ability of the Community/pDAO to Act
We discussed how any changes to the oDAO need to be enacted and enforced by the oDAO. Since it is autonomous, the pDAO is not able to act and its governance process does not apply here. The community is only able to make suggestions and we need the oDAO and the team to pick it up.
Monitoring
Heartbeat
We need something to tell us that an oDAO member is actively doing their duties. One possibility is requiring everyone to participate in all votes to establish a heartbeat.
Spoiler
jcrtp:
- The need for a heartbeat is still there, that hasn’t changed - the “how do we do it” has since the last time we had a conversation around it though
Langers likes the idea of making everyone submit balances on mainnet, regardless of whether or not consensus is reached, as a heartbeat that captures both the ruleset version each member is using (indirectly, since it only gauges changes that affect the rETH staker portion) and whether or not they’re actually alive. We might be able to get it into Atlas, which is good, but then we’re running without an adequate heartbeat system for a few months so we have to weigh the risks there.
He also is starting to come around to the idea of having a separate contract on Prater that the oDAO submit something to every time they submitted a balances update on mainnet. Contents would be a string with their Smartnode version, and the values they got for their balance submission. He’s not there yet because of added node op complexity / requirements, though the ability to “just use Infura / Alchemy for Prater” did seem like a selling point. We want to revisit this particular one next year when everyone’s back from vacations and stuff.
Subcommittee Submission Scheme
An alternative/improvement would be to have expected subcommittees submit each vote. This would give us a slightly sparser heartbeat, but has the advantage of zero smart contract changes and no increased gas costs.
Spoiler
poupas came up with this:
i’m thinking about a way to check for oDAO member liveness without needing new contracts and with 0 gas. the main idea would be something like:
note: this code would run on the smartnode/watchower. nothing is on-chain, except for the entropy source (0 gas cost)
- for each duty (e.g. price submission) calculate the members that must vote, using “some on-chain entropy source”[note: could also be round-robin or some other fair and reproducable algorithm]. also calculate a backup committee.
- wait for the main comittee to vote (x mins/hours/wtv).
- if no quorum can be reached, the backup committee members should vote.
potential benefits:
- we would detect inactive oDAO members (or members providing wrong info)
- gas costs should be smoothed amongst oDAO members
- this is done on the smartnode stack so it should be faster to implement
a35u: if the committees were different for submit prices and balances couldn’t you get almost all every day?
knoshua: you could get all, with one or two nodes submitting two tx each day, right? for example nodes 1-8 would submit prices and 8 - 15 would submit balances
Smartnode Version Tracking
Both heartbeat variants above work, but they only check for liveness, not proper version. An alternative would be to add some way to post messages on-chain that can include the current version
Spoiler
peteris:
what about
- we create and deploy a RocketNodeTrustedHeartbeat contract that’s just keeps a list of messages
- we create an add-on that calls the contract with the smartnode version every day (it’d be very cheap)
- we get butta and phiz and yorick to use them
- prominent heartbeat dashboard on rocketscan
- other odao members are pressured/shamed into enabling the addon as well
Note: instead of add-on and opt-in, it could be part of smartnode directly
Invis deployed a smart contract that allows oDAO members to emit events with data: https://etherscan.io/address/0xcf8df4ec8e06f9355d4f2db48d2625d2b0431774
~35k gas for that event
Incentives
Rewards linked to successfully contributing to consensus
It may make sense to align incentives with performance of duties. Care is needed to encourage “good” participation, without incentivizing cutting corners to “win” the most rewards.
Spoiler
knoshua: that’s the question, yeah. should someone that does only half the tx of someone else get half the rewards? my concern with that would be that submitting balances and such turns into a race for rewards and that could lead to behavior that is not desirable. Like optimizing for performance instead of reliability and decentralization. Or copying the first submission instead of calculating values yourself…
Valdorff: Yep - pass/fail metric with a time limit, rather than a race
Strike System
Spoiler
Honestly… More than reduced rewards, I’d prefer some kind of “strike” system leading to ejection
The key goals are reliability on oracle duties, and due diligence on contract upgrades
If someone is down one week every two months, I don’t think a 12% reduction in rewards is hitting the mark
Note: there would need to be discussion around what a strike is, how long a strike stays on record, and how many strikes results in a kick.
Communication with oDAO
We also talked about how there is no way for the community to communicate with many of the oDAO members. The expectation is not that every oDAO member hangs out in #trading. But we feel that the community should be able to reach every oDAO member. This could be discord, the dao forum or a different platform. Butta brought the idea of calls with the oDAO up again.