O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Governance for public Blockchains and DAOs - by Vitalik Buterin

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio

Confira estes a seguir

1 de 30 Anúncio
Anúncio

Mais Conteúdo rRelacionado

Semelhante a Governance for public Blockchains and DAOs - by Vitalik Buterin (20)

Anúncio

Mais recentes (20)

Governance for public Blockchains and DAOs - by Vitalik Buterin

  1. 1. Governance for Public Blockchains and DAOs It looks like an open source project, it quacks like a corporation, it walks like a genetic algorithm, it smells like a political party... what is it?
  2. 2. What we're covering ● What is the right model to use to look at public blockchain projects? ● Voice and exit ● Differences between standalone projects and dependent projects (and hybrids) ● From cryptoeconomics to crypto- political science ● Schelling: brinksmanship as probabilistic punishment (and other insights from mutually assured destruction theory)
  3. 3. The Old Model ● Public blockchains have a static protocol ● It is guaranteed that “honest” users will follow this protocol forever, the only risk is attacks ● No governance challenges whatsoever (It's all algorithmic! Non- political money!!!1!)
  4. 4. Is this person describing... A) The traditional banking system B) Regulators C) The shiny newfangled thing that's supposed to be nimbler and faster than the above? “It's a system that has been designed to resist change” https://www.reddit.com/r/Bitcoin/comments/4946ku/its_a_system_that_has_bee n_designed_to_resist/
  5. 5. A Taxonomy of Forks ● Soft fork: valid messages under new rules a strict subset of valid messages under old rules ● Kinda hard fork: valid messages under new rules a strict superset of valid messages under old rules ● Maximally hard fork: arbitrary new rules
  6. 6. Forks depend on... ● Soft fork: miners ● Kinda hard fork: miners and developers/users ● Maximally hard fork: developers/users
  7. 7. Failure modes ● Soft fork: – Developers/users sign up but not most miners: chain split (hence 75%+ threshold) – Miners sign up but not developers/users: success ● Kinda hard fork: – Developers/users sign up but not miners: no change – Miners sign up but not developers/users: chain split (hence adequate warning time required)
  8. 8. Failure modes ● Hard fork: – Miners don't matter at all (except in so far as they are users) – Some users sign up but not others: chain split (hence social consensus required)
  9. 9. Reminder: Schelling Points ● Two prisoners in separate rooms are shown the following numbers: 162 281 296 1000 1209 1612 1728 1837 ● If both give the same answer, they are freed, otherwise both are tortured to death ● Which do you choose?
  10. 10. Hard fork decision-making ● In this model, the choice is whether or not to install a software package choosing to fork ● If you are on the same chain as everyone else, all is good ● Otherwise, you suffer inconvenience ● What's the schelling point?
  11. 11. The pre-game ● Each side's incentive is to “puff itself up”, make its victory seem inevitable ● If a Schelling point exists, try to manipulate it ● Examples from Core/Classic dispute
  12. 12. The pre-game ● What if no Schelling point is agreed? ● Controversial hard forks are dangerous (maybe, will return to this later) ● But they are a highly useful negotiating tactic (for both sides) – Brinksmanship as probabilistic “tit for tat” in prisoner's dilemma
  13. 13. Non-convergent post-game (maximally hard forks only!) ● 1-4 hours: community realizes that a split is occurring, neither side willing to back down (main battlefield: Reddit) ● 1-2 days: quickest exchanges start trading “BTC-A” and “BTC-B” ● 1-7 days: businesses make a decision to support one or neither or both ● 1-2 weeks – (option I): one of the two is clearly ahead, the other dies – (option II): both chains soft-fork (or one chain hard- forks) to ensure transactions are bound to one chain ● Is total market cap higher or lower than original?
  14. 14. Network effects and anti- network-effects ● Positive: currency acceptance and liquidity ● Positive: developer mindshare (may be cross-protocol!) ● Positive: economic security (hashpower, size of deposits, etc) ● Negative: blockchain congestion (transaction fees, full node costs) ● Negative: political infighting ● Negative: bigger applications invite bigger attackers
  15. 15. Firm theory ● Left-side failures (everyone is a contractor): underproduced public goods, lack of coordination, transaction costs (eg. bureaucratic costs, high cognitive overhead, costs of gaining trust) ● Right-side failures (everyone works for one giant corporation): see, North Korea ● There is a balance
  16. 16. Firm theory in Blockchains ● Left-side failures (everyone has their own currency): low liquidity, high cognitive overhead, developer confusion ● Right-side failures (one currency to rule them all): failure to satisfy differing views, loss of cohesion, fighting rather than coexistence
  17. 17. Blockchains vs other governance ● Open-source projects: forking often used (only some developer network effect lost) ● Countries/corporations: forking not possible at all, only exit – Secession exists, but in case of countries requires camps to be geographically localized – Puzzle: why don't we see corporate secession? Is it because exit is too easy? ● Blockchains are somewhere in the middle
  18. 18. DAOs ● DAOs on Ethereum are, at least to some degree, dependent projects ● They sit on an underlying layer that provides “ground truth”, so truth no longer subjective ● This makes DAO governance much more like governance of corporations
  19. 19. So, how do DAOs decide? ● Naive answer: we vote! ● Problem: voting is not incentive- compatible ● Rational ignorance/irrationality (see Caplan etc) – Less of a problem for DAOs/corporations than countries ● 51% attacks ● Voter bribery
  20. 20. 51% Attacks ● 51% of shareholders move all assets into new DAO, expropriate the other 49% ● If DAO assets are primarily social capital / goodwill, then grim trigger argument discourages this ● Otherwise... this is why we need shareholder regulations!
  21. 21. Subjectivocracy ● DAO should only hold assets that are defined by itself ● In the event of a disagreement, the DAO can “fork” on the chain – Users free to follow whichever fork they wish – Indifferent users check market price to determine to gauge which fork is more popular
  22. 22. DAO splitting ● If the DAO holds externally defined assets (eg. ETH, digix gold, assets defined by other DAOs), then there is a “splitting” protocol where these assets are proportionately split ● No need to specify minimum percentage, but force costs of a split on the minority to prevent spam
  23. 23. DAO splitting ● Challenge: what about non-fungible assets? ● Option 1: probabilistic distribution (problems: imposes risk, requires secure RNG) ● Option 2: cut-and-choose protocols (problem: distribution may not be perfectly fair) ● Option 3: cut-and-choose plus compensation payments (problem: bilateral monopoly negotiation is not Pareto-efficient)
  24. 24. DAO splitting ● Ethereum-specific challenge: how do we maximally generally split all positions that the DAO might have in all other contracts ● Split by address, “mother” contract does two-way forwarding for children? – But then, how do we address cases where positions can be proportionately split?
  25. 25. Futarchy ● General principle: pick easily measurable objective function, have “conditional prediction markets” on objective function if: – action is made – action is not made ● Common objective: share price vs. base asset (eg. ETH) ● Perform the action only if the conditional share price if the action is made exceeds the conditional share price if the action is note made
  26. 26. Futarchy: Implementation ● Let people convert 1 DAO share into 1 yes-share and 1 no-share ● Let people convert 1 ETH into 1 yes-ETH and 1 no-ETH ● Let yes-ETH trade against yes- shares and no-ETH against no- Shares, watch prices
  27. 27. Futarchy: Manipulation ● What if the action only slightly affects the share price? ● Then, yes proponents may try to buy up yes-shares ● If you have accurate information about the effect of the decision, you cannot easily trade on that knowledge without assuming secondary risk of DAO price; hence, pool of counter-trades limited
  28. 28. Futarchy: Manipulation ● “Limits to arbitrage” argument / capital limitations can make shorting harder ● Solution 1: use futarchy for “big decisions” only ● Solution 2: bet on log(price) instead of price; log(price) practically capped at ~30 so capital is limited
  29. 29. Futarchy as Backstop ● If minority unhappy with voting decision, they may “file a complaint” ● Futarchy resolves whether or not the motion goes through ● Expropriators pushing up price of yes-shares not a problem (!!) as it lets no proponents “cash out” gracefully
  30. 30. Governing blockchains like DAOs? ● Problem: no “base asset” to make markets against – Difficulty futures could substitute, but only in PoW blockchains – Schelling-USD could substitute, but introduces stronger economic assumptions into base protocol ● Voting can be done... miners do it already ● Blockchain splitting can be done... it's called a hard fork

×