Genesis protocol V0.2 - community work group


#1

The first version of a Holographic Consensus (HC) protocol — the Genesis Protocol V0.1— has been specified and implemented (in Alchemy: http://alchemy.daostack.io) some months ago. We’re now ready to move to Genesis Protocol V0.2, and it’s going to be a community project :slight_smile:

For introductory materials about HC please check out these three articles:

For current work status please see this working draft (in progress):

https://medium.com/@matanfield/holographic-consensus-part-2-7137e40674a

and the early spec of the Genesis protocol implemented in Alchemy:


(for the less-accurate version but which is written in ordinary language)


(for the precise version implemented right now in code; for wherever there’s mismatch with the one above, this is the one that’s in code right now)

Finally, this is a working document for the upcoming Genesis V0.2 upgrade:

Anyone is warmly invited to take part in this community research program, this week (Tuesday 13 Nov - Sunday 18 Nov) will be an intensive research week at the end of which we’d like to close the specification for the first Genesis upgrade (V0.2). Further (and broader) research will continue afterwards.

Generous bounties will be offered for any real contribution to this program (such as ideas we haven’t thought about, identification of issues not identified, solutions to existing issues not suggested already - even partial ones, working out full solutions from initial ideas, etc). Exact bounties are still to be defined, hopefully in the coming days. Over time (possibly soon, depending on level of engagement), this program itself will turn into a Research DAO on otop of Alchemy. More on this in another thread (or on this one) later.

Please write on this thread any questions about this process. We’ll create a new thread for each identified issue (in the above G-doc link) for further questions, comments and suggestions on that issue. New identified issues, or new ideas, should have their own new threads. If you’re not sure if your idea is worth of a new thread please ask on this main one.
Also general questions on HC or the Genesis protocol are welcome over here.

Please come with any suggestion for the improvement of the process of this work group, we’ll evolve it over time. The current format includes:

  • Telegram supergroup for real-time operational questions: https://t.me/joinchat/AUo-qA7EQURSFhru0WqvVg . Possibly migrating to Discord at some point.

  • This forum for all scientific discussions. (We’ll see over time if we also need a real-time scientific channel; could possibly use the Telegram or Discord for that.)

  • Google doc (link above) and linked issues therein for continuous work status. Please DM (here or on Telegram: @MatanField) for editing permissions.

Any other ideas? Github repo+issues?

Feel free to reach out to me with any questions.

Looking forward to collaborate on this this!


The Predictor's Bias Problem
The Problem of Voting Rewards
Predictions Affecting Proposal Passing Chances
#2

Here’s a somewhat overarching observation that might (or might not) identify as an issue:

I suspect that, in any given DAO using Genesis v.01, there is a bias towards passing proposals. Both stakers and voters arguably fall for an optimism bias where wishful thinking leads to wrong (or not necessarily right) conclusions from a given proposal.

Stakers may overspend by falling for the sunk-cost fallacy when evaluating a proposal. This means that once they have evaluated a proposal and conclude with mixed feelings, they feel pressured to stake at least something so that their time evaluating the proposal was not for nothing (this echoes issue #3: Gain-loss game for predictors).

Voters adapt to such over-staking and, in turn, are incentivised to upvote as many un-proposals as they can in order to receive a pay-out once they become boosted and (due to optimism bias, more often than not) pass.

Any thoughts on this? Worth an extra thread?


#3

@theobtl, these are good points which need to be expanded over. I don’t see it as a critical failure mode, but it does worth the discussion (and possibly resolution), either here or over a distinct thread (if the discussion deepens).

More specifically,

  • I’m not 100% convinced by the sunk-cost argument —you could have said the same about every trader / investor: once they’ve made the due-diligence over a company they’d be pressured to invest in it. Hmmm… not sure. If they do so they’d obviously run into bad decision making, and you can say that those who’d be able of anti-acting against this “natural” tendency would simply win over those who won’t, and thus, economic-evolutionarily, take over.

  • Even if stakers are biased as described (which I’m not sure about), I also don’t see why voters are incentivized to follow this bias. Voters will get paid-out for any proposals boosted, and (exponentially) more and more so the more proposals are in boosting at a given time, and thus have the incentive to boost as many proposals as possible. But once they’ve boosted they get paid irrespective if they’re passing, so why are they incentivized to upvote?

Please expand over your thoughts if I’m missing anything. And if you do so and feels the discussion is going to deepen let’s have it then on another thread.


#4

Potential Issue: The Boosting Threshold Condition only prices collective attention according to the demand for the Dao’s attention and fails to consider its supply .

The exponential curve is only dependent on the number of already-boosted proposals: the more proposals in the boosted set, the harder it is to add to the set. But this fails to take into account that a Dao’s bandwidth will vary across contexts and over time.

  • Consider a situation where there are 2 proposals in the queue but each is incredibly complex and requires a lot of due diligence (e.g. governance upgrades) vs. having 20 proposals that are each trivial to evaluate (new pollinator request for REP).

  • Or consider a period of time during which a significant proportion of Dao members observe the same holiday vs. a time of year when most members are diligently working. We would expect the supply of collective attention to be lower in the former and higher in the latter.

“Number of proposals in the boosted set” does not capture these sorts of variations in the Dao’s bandwidth– which, in holographic consensus, would roughly equate to the average capacity for due diligence of a single REP holder. In other words, the equation assumes a perfectly inelastic supply of collective attention.

To address this issue, the curve should be able to shift to the right or left depending on the Dao’s bandwidth. This would allow the boosting threshold to respond to the supply of a Dao’s collective attention in addition to the demand for it.

This could be achieved by replacing the constant factors ( A and/or B ) with some sort of proxy for bandwidth or by adding a second term which does so. Bandwidth could be gaged by voter participation rates, such as the moving average of % of total REP staked towards the last 10 boosted proposals, i.e [sum of REP staked towards the last 10 proposals[ / (10 * [total supply of REP]).


Not sure if this is a critical failure mode to address in V0.2, but it seems like a problem worth bringing up. Thoughts?


#5

You’re very right @orishim !

The two reasons why focusing on the demand of the DAO collective attention and not its supply are:

a) The demand may vary much more significantly and rapidly
b) It’s much easier to measure the demand (=number of boosted proposals) rather than the supply (=collective attention).

It’d be very important to iterate on the protocol and add the consideration of the DAO’s supply of attention on a following iteration (but also agree it’s not critical perhaps for this version).

It’s not clear to me how you can measure DAO’s available attention, and whether that would be correctly reflected by voters participation rates. Rates can go down, for example, just for the reason that a decision is more professional and majority of voters do not have an opinion. But it may be a good starting point.

In this regard I have very (very) preliminary thoughts about some sort of “voting market”, along the lines of the way miners in blockchain decide whether to process your transaction or not (that you can improve by raising your gas price), but I don’t know yet how (and if at all) one can make sense of it.


#6

Hey Theo! I think these are great points and IMO could certainly be another thread.

For me, I think maybe it’s okay to have some optimism bias (especially in non-boosted proposals). We need DAOs to at minimum boost and vote on some proposals – otherwise nothing will happen. If they at least do that, perhaps they can learn and start heading in a better direction, even if the proposals aren’t great. There is a counterbalance in that you do get punished for incorrect staking and non-boosted voting. It doesn’t seem grossly unbalanced to me, anyhow.


#7

This is a super cool point, Ori!

Another thing obscuring the measurement of collective attention supply is that people may choose not to vote on boosted proposals because the proposals are already passing/failing in the direction they want to.

Here’s an idea, though: what about simple web traffic statistics? Number of visitors who have reputation and how long on average they spend on the Alchemy page daily?

There is a concern that this would be a deadly positive feedback loop: attention supply goes down, making boosting more expensive, meaning fewer boosted proposals, and in turn attention supply goes further down since there is less to pay attention to. “This kills the DAO”? And of course, the other question: is this change needed?


#8

Re: pricing collective attention.

Another approach is to define a “boosting difficulty” that is determined by a moving average targeting some average “boosted proposal success rate”. If too many boosted proposals are passing, the difficulty increases. For example, the Dao decides it would like to target a 50% success rate for boosted proposals. As the actual success rate deviates above and below 50%, the difficulty adjusts up and down (respectively) in proportion to the variance.

Define a difficulty factor, d , as actual_success_rate – targeted_success_rate . When d < 0 the BTS curve shifts to the left, making it easier to pass proposals, and vice versa. d could be incorporated into either the A or B constants to achieve something to this effect:


or

I’m still not sure if I would consider variance between targeted and actual success rate as a proxy for collective attention but it feels like a step in the right direction.


#9

Here’s the proposed Genesis.2:

There’s still a dilemma between min upstake and min fee and thus the two versions. (In principle both are viable protocols and may fit different use cases; the dilemma is which is more suitable for the upcoming use cases on Alchemy and with which to start first).

There’s also the rep allocation for successful proposer that needs to be improved a bit.

But it’s pretty much it and I think we’ve finally solved all major issues without complicating too much the protocol. Would love for feedbacks!

Planning to write much more in the coming weeks, wanting:

  • to document all of the insights and considerations discovered in the past two weeks of intensive research.
  • to raise and start working on new issues / avenues for research,
  • and to accredit the work and contribution made by people in the research community (and offer corresponding bounties).