Design Inflation DAO

[owocki]

apparently Moloch is not a fit for this. we should build a MolochV2 @ameensol

[owocki]

cc @brianethier who is interested in this deisgn challenge per https://twitter.com/Brian_Ethier/status/1103343634601164800

[ameensol]

(cross posting from our twitter convo)

Yea, Moloch is not a fit for this, primarily because there is a 1:1 relationship between votes and claims on the pooled capital, but also because it was designed with "planned obsolesce" in mind, not to be a steady state equilibrium:

• no upgrade mechanism
• no changing config params
• no forcing others to ragequit
• weak spam prevention
• single proposal queue (no batching)

It could serve as a useful starting point in designing a v2 for this though. If you haven't already, check out the mechanism design / code here: https://github.com/molochventures/moloch

[ameensol]

We could get some useful context for this design by first evaluating the functionality of other blockchain DAOs:

• DASH
• Decred
• Tezos
• Polkadot
• etc... (please list more)

[owocki]

more further examples to flesh out https://twitter.com/mattbeckman/status/1103359757233020928

[owocki]

some design goals:

• impactful
• decentralized
• accountable to community
• secure
• sustainable
• predictable
• consensus driven
• transparent
• impactful

[owocki]

main concerns are who decides disbursement, how to avoid perpetually elite fund faucet managers / difficulties associated

https://twitter.com/trent_vanepps/status/1103724486405300224

[GregTheGreek]

@owocki I believe my previous comments applies, not sure where that issue went

[owocki]

@GregTheGreek this one? https://github.com/ethereum/EIPs/issues/1789#issuecomment-468966353

[GregTheGreek]

@owocki yep, thanks!

Quoting myself from ethereum/EIPs#1789 -- some of the below may not be relevant anymore but I see value in porting it over.

NOTE: I'm going AFK and will add to this further tomorrow.

I'm elaborating on a twitter thread as I think it adds useful context to this:

Basically, there exists a networking issue that needs to be solved.

Issue: How do we broadcast and validate that the actual values (above) are correct, while allowing for the > values to be dynamic?

A few conditions:

We assume that you can dynamically change the address that the funds want to be sent to. We assume you can dynamically change the % that you want to send A barebones example:

In ETH1.x we could have the miner could sign a message (with their private key) stating the address > to send to and the allocation amount. This could be stored in the extra_data field, and we could > > reserve a key for it, perhaps something like:

redirect: { to: ...., alloc: .... } Where to is a valid eth address and alloc is a percentage of the block reward. The computation could occur during the rewards portion in the clients. For example, in Geth I would assume we would do the calculations in the accumulateRewards() found in consensus/ethash/consensus.go. Reading out the extra_data field, validating the signature and then allocating rewards accordingly.

In Eth2.x we could follow a similar pattern although we need to further spec out how our messaging will look. I believe the recent Wire protocol should help with that.

[GregTheGreek]

NOTE: I just realized this is the wrong part for discussion of this buuuut I spent so much time thinking and writing this, so im going to keep this for now :(

I'm happy to actually dive deep into the technical challenges on the node client side (I have a strong understanding of Geth).

This is also a very good use case for the extra_data field which alternatively could be spun out into its own EIP if we choose too. I say this because currently extra_data is not being used on mainnet, but the Clique POA consensus uses it for the authority signing.

Potential complimentary EIP:

Currently the extra_data field is being used by miners to identify who mined it. example: Extra Data: PPYE ethermine-eu1-8 (Hex:0x505059452065746865726d696e652d6575312d38))

Alternatively, a data structure can be used, a byte array?, to store information. Naively:

{
   miner: '....',
   redirect: '02000x1...', // Where the first 4 digits are the percent: <hundreds, tens, singles, decimal> 0200 == 20% and after the first 4 digits represent an ethereum address.
}

So we could continue to add additional fields to this in the future should we chose to.

NOTE 1 :: Theres an obvious issue of the length of the extra data field, its quite small. Need to get creative with this somehow.

EDIT 1 - Added Note 1 EDIT 2 - Comment further down addresses a few issues with this concept

[tvanepps]

my man @GregTheGreek flexing with his Geth understanding haha

genuinely curious what changed your mind from a few days ago on this idea when you thought it might be invasive / cause political issues (which I don't disagree with - it will without a doubt be contentious and require a lot of wrangling)

interested just for the technical challenge of it?

[GregTheGreek]

genuinely curious what changed your mind from a few days ago on this idea when you thought it might be invasive / cause political issues (which I don't disagree with - it will without a doubt be contentious and require a lot of wrangling)

interested just for the technical challenge of it?

Mmm my position hasn't changed much, still super political, but I've learned theres no reason to bicker.... I also know some of the identified risks so might as well just explain them. More interested in the complexities of this problem. I'm also playing around with the extra_data field right now, so it's relevant.

I think the idea of this being at the core protocol is strange, probably doesn't belong BUT the thought of redistribution to whatever or whoever you want is neat. Could also bring unique efficiencies to the mining pools.

It's a fairly invasive PR -- requires a hardfork because it can break consensus. So it won't be considered until September (cross your fingers).

[chrisfranko]

I know y’all want this on ETH but a smaller eth fork like exp could serve as a great testbed. I know we would be willing to work with y’all on it.

[owocki]

here is some useful signal on how DASHs inflation funding has gone => https://twitter.com/sambarboza/status/1105162106553405445

[lrettig]

@GregTheGreek I don't understand your reference to extra_data here - could you explain how this could be used?

I want to say upfront: I support the idea of inflation funding 100%. I want to see this EIP go into Istanbul. But I think the custody/governance/disposal of those funds has to be absolutely dead simple to start. It cannot be DAO-ified from the get-go. Governance of funds is a hard, hard problem and we can't presume that we're going to solve it in a few months' time. To do so would be extraordinarily hubristic. This is the beginning of an exciting, ongoing effort. Lots of people have thought a lot about this problem, both inside and outside our space -- Web3/Polkadot, Aragon, DaoStack, DxDao, Moloch, Colony, etc., plus of course many academics -- and we should learn from their work rather than try to reinvent the wheel here.

[GregTheGreek]

@lrettig The idea was to come up with a way to introduce it to protocol level without having to add an additional TX to the block. The problem I identified was thats we need to be able to verify that the amount to be transferred is correct. I've been going through what i wrote and it adds a huge state size overhead, an extra ~115.2kb / day (i believe), which is a bit counterintuitive to the goal.

Also -- to address the DAO issue, my idea is baked into the concept that every miner has the option of where to send it to. That way they can choose the individual or DAO of choice.

Anyway I thought to add something along the lines of the amount (as a percentage), to_address and a signed_msg consisting of hash(percentage, to_address, block_header). So the first byte would be the percentage, the following 20 bytes would be the to_address and the last would be the signed_msg. But the extra_data field is currently 32 bytes which means we would need to expand it and that probably imposes a lot more issues than it needs.

Basically took some of the logic from the Clique implementation.

[tvanepps]

I want to say upfront: I support the idea of inflation funding 100%. I want to see this EIP go into Istanbul.

@lrettig I hear where you're coming from but to get a social consensus before mid may is going to be near impossible. It has only just recently been broached as a possibility. There is a not-insignificant of hard money folks who also believe in Ethereum. Consider it as part of the initial social contract, for better or worse.

Agree that it would need to be dead simple. And definitely not controlled by the Foundation. they have enough trouble disbursing funds as it is.

[lrettig]

to get a social consensus before mid may is going to be near impossible

You may be right. We shouldn't rush. But having targets, however optimistic or unrealistic, is helpful :)

[owocki]

@lrettig I hear where you're coming from but to get a social consensus before mid may is going to be near impossible. It has only just recently been broached as a possibility. There is a not-insignificant of hard money folks who also believe in Ethereum. Consider it as part of the initial social contract, for better or worse.

We should decouple (a) putting the code that can issue inflated funds to an address (b) actually raising the inflation rate to be non-zero, from each other.

[lrettig]

We should decouple (a) putting the code that can issue inflated funds to an address (b) actually raising the inflation rate to be non-zero, from each other.

Yes, this is precisely the point of starting with zero. I don't think getting the code changes into the clients, with the rate set to zero, is an unrealistic goal for Istanbul.

[owocki]

in addition to looking into DASH/Decred, we should look into:

I agree with everything as well, (basically it’s a universal good and services tax) but inflation funding becomes inherently political if not handled correctly, determining where money should go etc is a hard design challenge. It’s stuff that is completely ruined the Elastos Blockchain Cyber Republic initiative which I was contributing to.

[owocki]

meta-dao idea https://github.com/gitcoinco/ERC-1789/issues/25

[owocki]

feedback on time-delimited funding idea https://twitter.com/owocki/status/1108228802386104320

[djosey]

^copied from the thread above

Does it make sense to limit funds of this inflation/tax to subsidizing development only? There's another category of important centralized utilities like @infura_io that provide value to the ecosystem and could do so for free more easily with a subsidy to cover cloud costs etc.

[kronosapiens]

This seems like the right place for this comment, so I'll mention that Colony has designed a decentralized inflation funding mechanism for supporting Colony-specific projects: https://blog.colony.io/introducing-budgetbox/

It could be a good candidate here since it meets a lot of the criteria I see listed, with the main difference being that in the Colony use-case, we can leverage Colony's reputation system to provide a sybil-resistant vote-weighing mechanism. To port the mechanism to Ethereum writ large we'd need a different sybil-resistance mechanism, and from what I understand having votes weighed by ETH holdings (the naive option) is a non-starter. Dash's approach which is to have master nodes vote (after putting up a large stake) might be the next place to look?

This issue in Eth Magicians may prove relevant: https://ethereum-magicians.org/t/ideation-session-reasonably-fair-algorithm-to-measure-current-contribution/2962/9

[owocki]

digix has some interesting example options for DAO governance https://medium.com/digix/digixdao-user-guide-voting-a4acfed40ae3

[owocki]

decred too :) https://twitter.com/zen_bacon/status/1124824117545324545?s=12