ECIP-1023: Combined CarbonVote and MinerVote for Consensus Soft and Hard Forks

[sorpaas]

(Rendered)

This is an upgrade of ECIP-1022, and tries to take the opinions of both miners and coin holders during a hard fork. For a hard fork to pass, in addition to miners voting to pass (as defined in ECIP-1022), it also requires that a sufficient portion of coin holders to vote YES using Carbon Vote.

Motivation

In addition to the motivation provided in ECIP-1022:

ETC coin holders are important. Holders of coins should also have sayings about whether a hard fork should occur. CarbonVote, if it can be enforced, is a good way to do this.

Minimal cost for miners to emit support. The cost for miners to emit support should be minimal.

Implementation

See ECIP-1022 for how miners vote for a hard fork, and see this ECIP rendered for how coin holders vote using Carbon Vote. Basically, it requires both miner vote and carbon vote to pass for a hard fork to take effect.

Also note that unlike miner vote, carbon vote does not have the block window period. The coin holder vote is valid for the whole start..(start + timeout) range and the voting result is checked each time a window period ends.

[sjmackenzie]

So bill gates can spawn off a million accounts and sway a vote. This proposal doesn't pay enough attention to bad actors.

[splix]

I think voting contract should not propose a specific implementation and voting process, only an interface is important there

[sorpaas]

@sjmackenzie Each address, when voted, is weighted by its ETC balance. So even if someone creates a billion accounts but if those accounts have zero balance, it would still be weighted zero.

[sjmackenzie]

There is a reason I said 'bill gates'.

[sorpaas]

@splix Can you be more specific about what you mean? The contract is only used to log YES and NO vote, just like how the current Ethereum CarbonVote works. Parameterize the specification would make it less confusing for end users, and it also simplifies the implementation -- we only need one implementation for ECIP-1023 in geth and it would work for all the hard forks onward.

[splix]

We discussed it today (together with #62), just putting my thoughts here:

1. extraData voting works for miners, doesn't take users and business into account
2. we have contracts, it provides a lot of possibilities for such kind of decisions, and we can get votes from both miners and users
3. a fork can propose a voting contract deployed to an address, decision made in that contract will control fork.
4. we just need a method like areWeAllAgreedNow(), specific voting process/rules/timeframe/etc could be different. it can be vote by special tokens, vote by committee, based on some oracle input, or anything. there is no reason to limit it to some specific implementation just from beginning
5. transaction fees for voting is not really important factor. it's a serious decision, it costs money for all parties, so transactions fees seems to be insignificant there

[sorpaas]

@splix I agree with 1-3. Some comments with 4 and 5:

• An areWeAllAgreedNow() function is unfortunately, not possible right now for all possible cases. EVM can only refer back to the previous 256 blocks and this is a serious limit. A voting period is definitely longer than that.
• Transaction is not an important factor when the network is not full, but it will become an important factor when we scale. Just consider what has recently happened in Ethereum, pending transactions become so much that the network is basically unusable. Even one more transaction would become a burden, let alone one additional transaction needed per block. Some emergency forks might need to happen when the network is under DDoS attack, and we need to be extremely careful to make sure that miners do not need extra cost to vote YES on a hard fork.

[splix]

4. why you would want to look back there? any use case for that?
5. miners can put any transaction in front of others. and can do that for free (put 0 for gas cost), even fees they are paying to themselves.

[sorpaas]

Hmm okay @splix, I forgot that putting 0 for gas cost. But if the miner puts 0 for gas cost, wouldn't the transaction fails and no state of the voting contract will be mutated?

[splix]

will work :) have them on testnet.

But the point that it can be small amount, not necessary 0. Miners don't really want to set it to 0, because it affects average price of gas, which is against their business. Also fees are paid to themselves, so they don't really care about their own transactions

I've made some calculations, using existing gas price and other metrics. It could cost $3000-$4000 per month for transaction fees, if every block has a voting transaction. This is about 0.02% of miner earnings for that period. Can be easily dropped to $1000/mo with a contract optimization and lower transaction fees (not zero, just say 10Mwei)

[sorpaas]

Thanks @splix.

But if the fee is not zero, the problem is that it is calculated into the block-level gas limit. Recently Ethereum scale problem tells me that this is a serious problem. If you think this is not that severe, what would be the reason?

Also, just created a draft of the contract-only version of the hard fork voting (https://github.com/ethereumproject/ECIPs/blob/ecip1024/init/ECIPs/ECIP-1024.md). I would be really interested to see how we can modify the minerYes() function so that the gas cost is low enough to be ignored. (I think it should be 0, or it will be a problem...)

[splix]

You just put transaction in front of others, it's not a problem there

[splix]

also, block limits gas amount, not gas price.

[sorpaas]

@splix but even if I just put a transaction to myself, I know it wouldn't cost anything for me, but it would use some amount of the block gasLimit, right? Yep I know it limits only gas amount, but it is still deducted and this costs. Recently Ethereum network failed to increase their block gasLimit, and this results a large amount of pending transactions, because extra transactions use block gasLimit but the block gasLimit has been used up. So I think any non-zero gas limit transaction for minerVote() would be a serious problem. No?

[splix]

Yes, every transaction costs something. That's how ethereum is designed, that's normal behaviour.

Are we trying to fix network scale or fork decision by this ECIP?

[sorpaas]

My worry is that if it costs, miners would rather not take it. This would make it the case that even when a hard fork is considered okay by most of the community, some miners would still not emit minerYes() for the blocks they mined, because it costs. Consider we have a emergency hard fork that deals with a DDoS attack on the network, that DDoS attack just emits thousands of transactions every seconds that used up all the block gasLimit. And if miner vote are contract based, the network will basically stop functioning because many miners will fail to emit the minerYes() vote and the network will not be able to hard fork. So my arguments are:

• Using extraData block header is safer because it has minimal cost for miners.
• ECIP-1022 plus ECIP-1023 has the same functionality as ECIP-1024.
• Use purely a smart contract does not have advantage in terms of simplicity, but potentially it causes trouble.

[splix]

@sorpaas that's up to you, I just said in that discussion that I don't think extraData is perfect and suggested to discuss alternative way with contracts. It doesn't mean I'm forcing you to change your ECIP to something you don't agree with.

[realcodywburns]

I like the general idea i think.

Carbon vote has some limitations. I do not think contracts or exchanges should be allowed to "vote". It could be possible to have a "voter registration" period every n blocks (first 100k blocks per million) in which someone wanting to vote, y, registers to vote on any upcoming issues. When the registration period closes, registered voters can make proposals. Issues needing voting could be addressed and voted on by a quorum of registered voters. The registration period would limit the effect of spontaneous sybil attacks. Voting can be handled by a bool vote to limit cost.

Any issues passed by the community vote could then be issued as a miner vote.