ECIP-1024: A CarbonVote and MinerVote Contract for Consensus Soft and Hard Forks

[sorpaas]

(Rendered)

See also ECIP-1023/ECIP-1022, which provides the same functionality as ECIP-1024.

This ECIP proposes a way to use solely smart contracts for all miners and stake holder voting. However, as miners are required to add a new transaction at every block they mined, this may result in discouragement in adopting new hard forks from miners' side (as it affects the block-level gasLimit).

[sorpaas]

Wow gosh, seems that I accidentally commit something that does not belong to here. Will remove.

[sorpaas]

Any way we can push this forward? @splix

I can remove the exact contract and only leave the interface. But the general idea is to allow both miners and coin owners to vote. So we basically have four functions: minerYes, minerNo (executed on every new block mined), and coinYes, coinNo.

Besides exchanges and big coin owners, CarbonVote has another downside that is vulnerable for attack, though. Consider a hard fork that miners all want to vote No but coin owners all want to vote Yes. Miners can jointly selectively not including any coinYes transactions into their blocks. This makes it as if nobody supports the hard fork, despite coin owners who are supporting it.

Not all ETC clients will need to implement this protocol. After the voting period, the proposal becomes active. At that time, there will be a known block number for the proposal to be in force. Those clients that wish to stay using hard-coded block numbers for simplicity can just insert that block number then, given we have a sufficiently long locked-in period.

I suggest we continue on with this by a simple test run -- a supposed hard fork that does not actually hard fork.

[Dexaran]

Is here a source code of Vote contract somewhere on github?

[sorpaas]

@Dexaran You can always refer to the classic but controversial CarbonVote (https://github.com/consenlabs/carbonvote).

[splix]

My suggestions just to leave interface required for a node implementation. The voting process is unrelated to a process of activation by a node.

What I mean is that we have to write a code for Geth that will real a contract every X block and update activation flag for a chain config. For example for Geth it could be:

"chainConfig": {
   "forks": [
       {
          "name": "FooBarFork",
          "activate": {
              "type": "ecip1024",
              "contract": "0xe5ad04a036612f493dd5fed1ff394b4eb2b89156"
          }
          "features": [{....}]
      }
   ]
}

Basically by such ECIP we should describe how a node could use such way to activate a fork. Which method it expects from a contract, what value it can return and what a node should interpret/react to this value. So by reading this ecip 1) a node developer can write code for activation 2) a fork developer can write a contract with interface that can be processed by a node

Different implementations of a fork contract and voting process are out of the scope, should be discussed only within a particular fork implementation. It may make sense to give an example, but it should not limit developers. And you correctly noticed that a particular implementation can have vulnerabilities, so better to move implementation out of the scope of ECIP.