Proposal: Bomb 2.0

[vbuterin]

NOTE: This proposal, like many others posted here, is intended for discussion as one possibility among many; this proposal does not signify the author's belief that this approach is necessarily superior to all others (or to the baseline of doing nothing).

For blocks where block.number >= METROPOLIS_FORK_BLKNUM, remove the "ice age" component of the difficulty adjustment algorithm (ie. the part that adds a fixed sum exponentially growing with block.number // 100000). At the start of processing block METROPOLIS_FORK_BLKNUM, place 10**18 ether into the contract at address BOMB_ADDR.

The contract at BOMB_ADDR should have the following logic. Anyone can deposit ether using either a depositYes() or depositNo() function, and withdraw deposited ether using a withdraw() function. The contract keeps track of the total amount of ether currently deposited through depositYes (call this value Y), as well as the total amount of ether currently deposited through depositNo (call this value N). When depositYes is called, the contract also checks whether or not Y - 2 * N >= 5000000 ether. If this is the case, then it starts a 60-day countdown timer, after which the withdraw function will send everyone an additional 1000 ether per call.

If a hard fork is made to shut off the gadget, the fork should (i) transfer the 10**18 ETH to a new gadget with a new address, (ii) shut off the 1000 ether free withdraws and (iii) lock down the gadget so that those who deposited using depositYes could only withdraw one week after the fork (the logic for (ii) and (iii) could be implemented in-contract via the contract checking its own balance, so the fork code itself would only include a balance transfer). Hence, voting yes requires voters to be willing to bear ETH price movements for one week after the fork, incorporating an element of coin lock voting.

Rationale

The purpose of this is to substitute the ice age with a more general "governance gadget" for hard forks. The intention is that people will start sending ether into the contract with depositYes when a hard fork is proposed and they want to approve; once enough people approve, the blockchain turns on a "self-destruct timer" that essentially forces a hard fork to take place. Those opposing a hard forked backed by these majority votes are free to adopt a hard fork to shut down the timer other than the "dominant" hard fork, but they would need to congregate around a specific proposal rather than just the no-action default.

The 5 million number was selected for two reasons. First, it is roughly the same as the cost of a 51% attack against the Ethereum network (estimate justification: 6x R390’s ($300 each) + Supporting hardware (mobo +psu, etc $400) =~ $2,200 for 0.165 Gh/s, ethereum network is at 3868 GH/s so the total cost is $51570000, or 4940000 ETH, or 2470000 ETH if you are attacking by buying hardware from existing miners). Hence, this proposal does not enable an avenue for breaking the blockchain cheaper than what is already available and so does not reduce the level of "immutability" that the protocol has in practice, and furthermore it sets a rough lower bound on the scale of event or technical need that justifies a fork - and a scale similar to the scale at which 51% attacks become feasible seems as good a schelling point as any.

Second, it is within the range of voter participation empirically observed in stakeholder voting systems (DAO carbonvote, DAO proposals and Bitshares voting all saw 5-10% participation), meaning that a large amount of consensus gathering is needed to pass a fork through but not one that is too large. Note that 5 million is only a lower bound assuming perfect consensus; if there is only 90% assent, then Y - 2 * N = 5 million is only reached when 7.14 million ETH vote in total (6.24 million in favor - 2 * 0.7 million against = 5 million), at 80% assent 12.5 million ETH must vote, and at 70% assent an unrealistic 50 million ETH must vote; below 67% support the gadget cannot be activated no matter the level of participation.

[tscs37]

So the essential purpose is that stakeholders can vote on a fork and once that is activated, the chain which voted on the fork is essentially deprecated by flooding the market with it's coins?

This would mean that anyone not agreeing with the fork would have to fork to regain original properties.

I'm kinda torn about this, for one it enables definite consensus on a fork, once enabled there is no going back.

On the other hand, this means if the contract is successfully attacked and voted for yes, then the chain must fork.

Additionally, this gives most voting power to whales and not the small ones. Though I guess it is very hard to allow everyone equally to vote.

[Smithgift]

In-chain systems like this are vulnerable to soft-fork censorship attacks, not unlike the theoretical ones that would have sunk the DAO soft-fork. Namely, pro-fork partisan miners censor transactions that would aid their cause, and anti-fork partisans do the opposite. This does not necessarily mean only "Censor transactions that are in favor". It could also be "Censor anyone who changes their mind and tries to get out of against."

A simpler version of such forks would be a fork-choice rule like this: Given two chains, the one with the better final vote-tally for our side is chosen. If this was followed absolutely, without regard to difficulty, then an anti-fork chain would inevitably survive.

Even with more moderate rules ("scoring" both difficulty and vote count), it's not impossible that the network would be destabilized by reorganizations as the two sides attempted censorship of each other, and honest miners switched between chains as the normal fork-choice rule instructed. If the miners on each side vary in power (due to attacks, bugs, people changing their minds) the instability might be even greater.

/soapbox on

But my biggest complaint with this system is that voting by ETH is unjust. As @tscs37 says, this gives more power to whales. One user with 1000 ETH ought not make to decisions over the wills of 500 users with 1 ETH. (Whales are even more advantaged, because they have the ETH to leave locked for voting, while the average user does not have so much to spare.)

Simply because we have a technology does not mean we ought to use it. Forking is an inherently social process, involving the actions of rational beings and the judgement of immeasurable qualities. The EVM knows nothing but mindless code and values of no more than thirty-two bytes at a time. An in-protocol gadget might alter the game-theoretical situation for we intelligent creatures, but invariably it will be gamed, as has been every political institution.

Mind you, I don't believe that in-protocol systems are useless, only that they are limited.

/soapbox off

[tscs37]

Well, as we've seen with the DAO softfork, it is incredibly hard to create a softfork that does not open the miner to severe DOS attacks at zero gas cost.

An alternative suggestion;

Modify the contract such that it is voted with block hashes. If the blockhash is even, it is a yay-vote, if it is uneven, it is a nay-vote. This is a simple comparison on the last bit of the hash.

This means that the default position of the network is a 50/50 vote split.

Miners who want to weigh in any direction will have to expend additional resources at the cost of income to mine blocks specifically with uneven or even hashes.

Edit: Appendix

To achieve this in a softfork resistant manner, the state-transition for this contract would become part of consensus, since it's call will be predictable for every client.

This means every node will execute this voting contract on the block but not as part of the block, miners won't have to include a tx in the block to vote. All they need to do is mine even or uneven hashes.

In theory, to achieve a +10% yay over the 50/50 split, the yes votes need 20% more hashpower than all no votes.

Thusly the actual voting consensus can be calculated as V = ( Y/T - N/T ) where V is the voting consensu, Y is the Yay Votes, N is the Nay Votes and T is total blocks included. A negative number is anti-fork, a positive number is pro fork.

Ideally on average V will be idling around 0.5, with some spikes up and down, due to randomness.

Edit: Appendix B

Likelyhood of Random Forks.

Because such a mechanism relies on randomness, we must consider that a fork can be accidentally engaged due to randomness.

If the fork-delay is 30 days then in that time, we will have around 185140 blocks (rounded down).

The probability for the last bit being 0 or 1 is 0.5, The probability for two consecutive zeroes in a perfect random system is therefore 0.25 = 0.5 * 0.5 = 0.5^2.

This means the probability for a fork to have a 90% consensus, ie 0.95/0.05 voting, 0.95 percent of zeroes within the voting span must be uneven, trailing 1.

This means of the 185140 blocks, 175883 must be with a trailing 1. This has a probability of 10^(-52947) or about 2^(-175886), assuming distribution is truly random, if no miner is voting at all.

[Smithgift]

Would not miners have their effective hashpower halved if they voted? They would be theoretically discarding half their valid blocks. If everyone voted, then the network itself would eventually compensate by decreasing the difficulty. Anyone who didn't vote would have apparently double hash power for it.

It may be simpler to have a contract that only listens to the coinbase address, once per block, to count votes.

A censorship soft-fork could still attack a block-based scheme, with the same tally-counting rule. In a blockhash scheme, voters have the additional woes that their chains are going to be shorter (from less hashpower) and ergo easier to overtake by the other side.

[tscs37]

It is part of the function that it effectively halves the hashrate.

In theory this means that miners have an incentive to only and *only* vote when they think it will be profitable for them or if they are altruistic and vote for their ideology.

Since now everyone who is not voting gets their hashpower double, the network will actively fight forks as part of the proper fork protocol without any miner but the voters taking action until the fork is resolved.

The interesting part is that all miners that are solely mining for profit and are not interested in the network have no interest in voting, they're operating at loss, only miners that participate in the network and want a fork or are against it will actually vote.

The final outcome would be that a fork now has a measurable cost in form of lost block rewards to miners, additionally the network passively fighting forks by natural hashrate/difficulty evolution and being by default on status-quo.

It may be simpler to have a contract that only listens to the coinbase address, once per block, to count votes.

That is the intended function. It only works if every mined block counts as a vote.

[vbuterin]

I'm kinda torn about this, for one it enables definite consensus on a fork, once enabled there is no going back. On the other hand, this means if the contract is successfully attacked and voted for yes, then the chain must fork.

Yep exactly. But that's fine; if it's a clear attack, then the attackers will have to hold ETH while the price goes down, and the chain can just fork. It's basically just another kind of 51% attack vulnerability which is more expensive to exploit than the 51% attack vulnerability that already exists and which has imo less disruptive consequences.

But my biggest complaint with this system is that voting by ETH is unjust. As @tscs37 says, this gives more power to whales. One user with 1000 ETH ought not make to decisions over the wills of 500 users with 1 ETH.

The problem is that we have to choose from a set of actually available alternatives, and all of them give some people much more weight than others. "The market", which is in some sense the baseline governance mechanism that exists in the absence of all others, also gives 1000 ETH 1000 times more weight than 1 ETH. Social determination sounds nice and fluffy, but also leads to inevitable concerns about conflicts of interest, "cheap talk", etc, and even in a socially determined model some people have 1000x more influence than others. I would also note that this particular ETH-voting approach is still a bicameral model: a fork requires consent from both holders and devs because devs have to find the fork acceptable enough to be willing to write up the code, and I like the idea that large changes should require some form of assent from multiple constituencies.

One possible way of mitigating this is to come up with a reliable one-per-person system, and have independent (non-binding) polls on top of it. This would be viewed purely as an independent gadget to assist with social consensus formation.

Modify the contract such that it is voted with block hashes. If the blockhash is even, it is a yay-vote, if it is uneven, it is a nay-vote. This is a simple comparison on the last bit of the hash.

Personally I do not like miner voting. Miners are much less representative of the broad ethereum community than ETH holders, and should be viewed as employees of the network, not as a chamber of governance. If you want to have a form of "costly voting", then personally I like my/Avsa's coin lock approaches the most; it's a form of cost that also has a secondary effect of aligning incentives, and being much cheaper for genuine ethereum stakeholders than it is for attackers (who would have to deal with exposure to an asset they don't even like).

[taoteh1221]

One possible way of mitigating this is to come up with a reliable one-per-person system, and have independent (non-binding) polls on top of it. This would be viewed purely as an independent gadget to assist with social consensus formation.

This surely would help in alleviating questions / frustrations among average end-user community members, being able to participate in and compare a community voting contract to any hard fork contract voting results. Great idea.

[Smithgift]

I don't think a just forking system is impossible. The current "gadget" (i.e. the difficulty bomb) doesn't care about the money anyone has, it just forces the community to decide something.

A bicameral (polycameral?) model would be superior, though I don't think it would be a place to stop.

Brainstorm: Have a bomb that automatically explodes every $TIME_PERIOD, and the community therefore has to agree on a "fork" (quite likely keep the status quo). The social contract would be that if there's any argument for a fork, it would have to be done at the bombing. (There's flaws with this idea, I know, but I'm brainstorming here.)

In, re: democracies, it's true that some have more influence, particularly in the Republic, the stable form. Nonetheless, there's a significant difference between someone having effective more power, due to wealth, popularity, or the like, and someone actually being treated as more important by the legal system. A senator has more power because of the will of the people, but hopefully not because of the will of the rich.

I do realize the contradiction in disagreeing with ETH-voting and supporting PoS. It is something of which I am still unsure myself.

[realcodywburns]

Does the BOMB_ADDR contract sit idle all the time or will it require an arming code from the owner? I understand voting would only count once a hard fork was proposed but couldn't it theoretically be primed with no proposal suggested? With the understanding it would take ~$5m +1 to prime from zero (a cost > 51% attack) and some amount less than that as Y approaches Y +1 = 5m +2N.

Will there be a 'voting window'; a set time from which a hard fork is proposed & voted on and BOMB-ADDR either does or does not arm? By this I mean after a proposal is put forth, and voting begins, how long will voting be allowed to stay below the 67% support level before the gadget decides the 'nays' have the vote. Is the impetus on the voter to monitor the fork vote and decide on their own the time frame they are comfortable with to call withdraw() effectively reversing their vote.

Also, Is the arming sequence envisioned as a "foot fall" or will there be a minimum amount of time where Y - 2*N >= 5 million would have to be true before the 60 day clock started?

[vbuterin]

A bicameral (polycameral?) model would be superior, though I don't think it would be a place to stop.

IMO the model is already implicitly bicameral. ETH holders have to approve a fork, devs have to code it. If the holders approve a fork but there's no code, then the schelling point will be a maximally simple fork to disable the bomb.

I do realize the contradiction in disagreeing with ETH-voting and supporting PoS. It is something of which I am still unsure myself.

IMO this is totally reasonable and not a contradiction. Ethereum uses PoW, but I don't like miner voting. Consensus validators are employees of the network, voting is a governance process; it's ok to trust a stakeholder set with one role but not the other.

Does the BOMB_ADDR contract sit idle all the time or will it require an arming code from the owner?

In my proposal the bomb has no "owner". Anyone can arm it. Even if there is no hard fork proposed, if some crazies want to throw in 5m eth (and if no one opposes them) they can trigger it.

Also, Is the arming sequence envisioned as a "foot fall" or will there be a minimum amount of time where Y - 2*N >= 5 million would have to be true before the 60 day clock started?

I suppose a foot fall would be too risky; perhaps a 48 hour minimum may make sense, as if some crazies do throw 5m eth in, then everyone else will have time to rally to vote against them and thereby resolve the situation more cleanly than a hard fork would allow.

[mrbenfraser]

Would we be relying on this process for upgrade forks or just for state change forks? I doubt there is enough incentive to vote for the the former (in general; switch to PoS would be an exception!) given the liquidity loss and perceived credit risk post-DaO.

For the same reasons I think 5m+ majority is a very ambitious target for state change forks... but maybe that's desirable.

[tscs37]

Hardforks to upgrade Ethereum can rely on this contract, but like any other hardfork, no code on the network can prevent a hardfork.

The code proposed here simply prevents running a chain once it has successfully forked without a hardfork itself.

[larspensjo]

The code proposed here simply prevents running a chain once it has successfully forked without a hardfork itself.

It also serves as a voting mechanism. That is better than the semi informal carbon vote that was used.

I think it is a good thing to prevent the old fork from remaining. It is good to keep away pure speculation (which can be very detrimental to the community). If there is genuin interest in keeping the old fork alive, a simple hardfork can fix it.

For the same reasons I think 5m+ majority is a very ambitious target for state change forks... but maybe that's desirable.

That is a good point. My own opinion is that POS should be enable with a smaller majority.

[Smithgift]

I've been thinking about a proto-proposal. It's missing a rather important component, but I'm (proto)-proposing it here.

Suppose we have some endogamic measure of network health. (As an arbitrary measure, gas used per block, (or lack thereof)) Say that, if things are going wrong by that measure, "Heat" is produced. Sufficient quantities of Heat start the bomb process.

In this case, I don't think it's bad that Heat can be gamed in whatever way. Essentially total Heat is network metrics + people's efforts to signal they're unhappy with the situation.

Option 1: When some threshold of total or continuing Heat is reached, the bomb starts an arming process, which may be more voting, or coinlock voting such that people who vote one way or the other are stuck on the chain they're in favor of.

Option 2: The Bomb starts with so much Ice, and Heat slowly but irreversibly decreases it. When the Bomb is out of Ice, a vote is forced, which may simply be to reset the Bomb. This system is both the current inevitable bomb, with hopefully network metrics added, but also triggerable if one sufficiently large side wishes to force the issue.

EDIT: By "vote" I mean that people signal which chain they prefer. The Bomb will explode anyway on the original chain.

Two philosophical premises here: (A) I'm OK with coin voting as a method of economic signaling, which is quite valuable in a potential fork. (B) I think forking where both parties survive is desirable. We have the potential for a web3 world where users can pick whatever blockchain or tech they prefer, and all the linkages and kludges make it work together behind the scenes.

Aside: Is there a reason the protocol-level rule could simply be: "A block is invalid if in the state the Bomb is triggered."? There's effectively no difference between stopping the blockchain and making everything on the blockchain worthless. In either case, a party on the no-change fork would make some trivial change to stop the Bomb. In the former, there's less grossness with a gajillion ether out of nowhere. (I assume the average node would, in any situation, yell at the user to fix things and refuse to work if the Bomb went off.)

[Smithgift]

Addendum: Whatever method there is (official or unofficial) of gaming Heat, it has to burn (ha) resources. Otherwise, a troll whale could keep activating the bomb over and over again. (Albeit that a Bomb system that's abusable is in and of itself a (meta-)crisis requiring a hardfork.)

I find the concept of a pure Heat system interesting. Essentially, there's naturally only 1 Heat per block, and the total necessary to activate the Bomb is (X years / blocktime). However, through some official burning method, Heat increases. There's then no need to try to figure out what metric creates Heat, since inevitably (inevitably!) there will be some crisis that does not influence that metric.

For all bombs, in a world where the block transition function is actually a contract, the Bomb could simply sets some flag which makes the contract return without doing anything. Again, same effect in the end as hyperinflation.

[larspensjo]

Otherwise, a troll whale could keep activating the bomb over and over again.

I don't see how that would be possible. You have to have a considerable amount of ether to trigger the bomb. And if it is a troll, you can count on people voting against. That would virtually make it impossible. Possibly from voting apathy.

What is the incentive for anyone to do this?

[Smithgift]

I was referring to a system where the Bomb explodes, no matter how people vote, and voting is merely method of signalling which chain one prefers.

[Smithgift]

I have come to peace with a coinlock voting system for a Bomb, provided it is presented as a signaling, not a governance mechanism. Sufficiently aggrieved parties can hardfork the blockchain at any time, with or without the economic ability to activate the Bomb. Similarly, even a pod of EVIL WHALES can only trigger it, they cannot force everyone to actually stay on some self-serving fork. It is useful to both sides of a hardfork to know who plans to be on what side.

This is not an endorsement of this Bomb proposal per se, but I find it less objectionable now.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.