Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exodus: put up or shut up on-chain protocol for legitimizing hark forks #52

Open
lirazsiri opened this issue Apr 8, 2019 · 1 comment

Comments

@lirazsiri
Copy link

lirazsiri commented Apr 8, 2019

The problem

Deciding on Hard Forks have historically been contentious and expensive, being largely based on social capital as carried out through an implicit and offchain signaling (Telegram, Twitter, Gitter, Reddit, blogs, Zoom, events).

As an alternative, we propose an on-chain protocol for deciding and legitimizing hard fork decisions using an Exodus contract, which functions somewhat like a prediction market in which supporters of a hard fork swap their tokens with non-supporters of a hard fork.

Voters in the Exodus protocol are betting that their staked tokens will be more valuable on the new chain or the old chain. They are rewarded in proportion to their risk. Their risk of being wrong is higher the earlier they stake and the fewer the other token holders that agree with them, either by disagreeing explicitly or abstaining.

The innovation is theater minimization by providing strong incentives to participate in the hard fork social consensus process in an incentive compatible way. Instead of theater you put your money where your mouth is. The community decides to only seriously give attention to a hard fork proposal when it goes through a process that forces supporters to use the costliest most fake resistant signals

When trolling is cheap we get more trolling, which dilutes our attention span for serious proposals that have been very carefully considered. Transparency delay and vetting in a fake resistant way that transfers the risk of bad signaling to the fakers.

The solution:

  • Put up or shut up: Voting for a hard fork requires staking one's ETH into an Exodus contract, which is used to signal expensively for or against a hard fork. The signalling is a binary choice, no nesting of signals is allowed.

  • On new chain: Loser ETH get redistributed to winners

  • On old chain: Winner ETH gets redistributed to Losers.

Age factor: Token (re)distribution is based on age and size of the stake, thus, favoring early bets. Early votes has risk risk and high return. Something like Vitalik’s “quadratic coin lock voting” where N coins let you make N * k votes by locking up those coins for a time period of k². This aligns incentives over time: more voting power requires living with your decisions for longer

  • There is no ultimate arbitrator of which chain "won" the hard fork but social consensus as reflected by the price of the old and new chain tokens on secondary markets comes the closest.

  • Explicitly: Separation is favored over Integration. Implicitly: More rewarding to integrate over separate, thus, falsifying the separation-integration dichotomy

Fictional example

  • Share the loot to coordinate scaling Ethereum politics: in a campaign of FUD around "lack of transparency" at the EF a fake "core dev" (who is hoping to avoid transparency for his own misconduct) proposes to divert inflation treasury funds into an untested on-chain DAO that will divide the loot between his political supporters and secure more funding for the hard problem of scaling Ethereum politics.

  • The community tells him to put or or shut up by creating an Exodus contract and trying to convince his supporters to join him.

  • What is published within the Exodus contract: new rules of consensus (e.g., commit hash of new rules) that diverts inflation treasury to a loot DAO and the voting period (e.g., May 1st to May 31 2019)

On June 1st 2019, there are now two chains, one running the old "no loot" rules of consensus and the other running the new "yes loot" rules.

Let's say 5% of tokens voted for loot, 1% voted against loot, the rest don't care / abstain.

  • On old "no loot" chain: 5% of tokens who voted "yes loot" are redistributed to 1% of tokens holders who voted "no loot". On the "no loot" chain the supporters of loot have donated their tokens to their opponents.

  • On loot chain: 1% of tokens who voted "no loot" are redistributed to 5% of token holders that voted "yes loot".

The "yes loot" voters have more tokens on the "loot" chain. This is only a win if the market values "yes loot" tokens. If the market sees through the "yes loot" proposal then the sum of their tokens be worth so little that there won't even support an incentive to mine the chain and the would-be looters have just suicided themselves out of the game.

Exodus could be generalized as a protocol for upgrading/forking any opt in consensus system including possibly dapps.

The problem of abstainers: a large percentage of abstainers reduce the legitimacy of a successful hard fork proposal. In an alternative variation of Exodus a strong incentive for participation could be created by penalizing abstaining tokens with dilution. On the new chain a copy of the abstaining tokens would be minted and redistributed to the hard fork supporters.

Example on a chain with 6 tokens total:

  • 3 voted yes, 2 no, 1 silent
  • New chain: 2 nos gets rewarded to yes’ers, copy of silent token is minted and distributed to yes. Total tokens on new chain is 7.
  • Old chain: 3 yes go to no’ers, silent unchanged

Afterthoughts

Applying Albert Hirschman’s classic “voice or exit” paradigm for affecting change in a system

  • voice is governance (coin voting)
  • weak exit is selling your coins (delegated voting)
  • and strong exit is forking (absentee)

Co-authorship credits: many thanks to Anuj Dasgupta. We brainstormed Exodus in a rustic tavern in the old city of Jerusalem. This final version is my own.

@lrettig
Copy link
Collaborator

lrettig commented Apr 25, 2019

I think this is cool and worth experimenting with - it strikes me as an implementation of futarchy. I would also call it a "forced fork" mechanism. Two thoughts:

  1. This seems to violate the existing norm in the Ethereum community of avoiding forks and favoring cohesiveness - so it seems like it would be more likely to work on another network
  2. I think all of the criticisms of futarchy apply here as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants