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.

Sign up for GitHub

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

Jump to bottom

Update ECBP 1076 "Miner Signaling" with latest options #339

Closed
wants to merge 1 commit into from
Closed

Update ECBP 1076 "Miner Signaling" with latest options #339

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
72 changes: 20 additions & 52 deletions _specs/ecip-1076.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
lang: en
ecip: 1076
title: Mining Algorithm Change Process
title: Mining Algorithm Signaling Process
author: Talha Cross (@soc1c)
discussions-to: https://github.com/ethereumclassic/ECIPs/issues/174
status: Draft
Expand All @@ -11,84 +11,52 @@ created: 2019-11-16
---

### Abstract
This meta document is agnostic to any mining algorithm. Its sole purpose is specifying a process how to openly determine and select a mining algorithm for Ethereum Classic.
This meta document is agnostic to any mining algorithm. Its sole purpose is specifying a process for miners to signal their preferred mining algorithm for Ethereum Classic.

### Motivation
The decision to change the Ethereum Classic mining algorithm - or to keep it as is - is not an easy one to make. It should be done by broad consensus with all stakeholders involved - miners, investors, application and core developers, and anyone else who feels they have a stake in ETC. This meta document proposes a process of how to facilitate the potential change of the mining algorithm and parameters.
The decision to change the Ethereum Classic mining algorithm - or to keep it as is - is not an easy one to make. It should be done by broad consensus with all stakeholders involved - miners, investors, application and core developers, and anyone else who feels they have a stake in ETC. This meta document proposes a process of how miners could signal in favor of one potential change of the mining algorithm and parameters.

### Available Options
Currently, the following options are debatable.

- **ECBP-1076-A**: _"Ethash Status Quo."_ The mining algorithm will be untouched as it is since genesis, as **Ethash** function with a statically **increasing DAG**.
- **ECBP-1076-B**: _"Ethash Limited DAG."_ The mining algorithm will be untouched as it is since genesis, as **Ethash** function. However, the **DAG size will be limited** as specified in [ECIP-1043](https://ecips.ethereumclassic.org/ECIPs/ecip-1043).
- **ECBP-1076-C**: _"Keccak256 (SHA3)."_ The mining algorithm will be **changed to Keccak256** as specified in [ECIP-1049](https://ecips.ethereumclassic.org/ECIPs/ecip-1049).
- **ECBP-1076-D**: _"ProgPoW."_ The mining algorithm will be **changed to ProgPow** as specified in [ECIP-1070](https://ecips.ethereumclassic.org/ECIPs/ecip-1070).
- ~~ECBP-1076-D: "ProgPoW." The mining algorithm will be changed to ProgPow as specified in [ECIP-1070](https://ecips.ethereumclassic.org/ECIPs/ecip-1070).~~ This proposal has been [rejected by the community on Nov 20th, 2019](https://github.com/ethereumclassic/ECIPs/issues/174).
- **ECBP-1076-E**: _"RandomX."_ The mining algorithm will be **changed to RandomX** as specified in [ECIP-1093](https://ecips.ethereumclassic.org/ECIPs/ecip-1093).

Eventually, the community has to decide on one.
Eventually, the miners have to signal in favor of one option.

### Process
The following process facilitates all stakeholders in various stages.
### Signaling Process
Solo miners, mining farms, and mining pools can signal support by adjusting their mining node to signal in favor of one of the proposals that was promoted to "Last Call" state in the previous stage. Details on the signaling can be found in the subsequent subsections.

1. _"Tech Stage."_ Core and application developers meet in regular calls to evaluate the feasibility of the Ethash status quo, the limited DAG size proposal (ECIP-1043), the Keccak256 proposal (ECIP-1049), and the ProgPoW proposal (ECIP-1070).
The signaling process shall be considered finished once more than **70% of the last 100_000 blocks** (_> two weeks_) were signed with a signal in favor of one proposal.

If there is no technical objection to each of the proposals, the proposals can be **moved to "Last Call"** state, regardless of whether they will be considered in future or not. As a result, none, one, or many competing proposals can be in "Last Call" state at the same time.

This stage is finished once all proposals are either in "Last Call," "Withdrawn," or "Rejected" state.

2. _"Miner Stage."_ Solo miners, mining farms, and mining pools can signal support by adjusting their mining node to signal in favor of one of the proposals that was promoted to "Last Call" state in the previous stage. Details on the signaling can be found in the subsequent section.

This stage is finished once more than **70% of the last 100_000 blocks** were signed with a signal in favor of one proposal.
3. _"Decision Stage."_ The proposal that passed the technical stage to "Last Call" state and received 70% approval by the miner community, **shall be considered as "Accepted,"** all other competing proposals shall be considered as "Rejected." The EIP Editors are responsible to facilitate this status update to the proposals according to this process definition.

The block number where the 70% threshold is breached the first time is called the `threshold_blocknumber`. It automatically defines the `activation_blocknumber` which is:

```
activation_blocknumber = threshold_blocknumber + 1_000_000
```

That gives clients a six months window of activating releases with the ECBP-1076 activation block number.

In case none of the proposals reaches the defined threshold, the status quo will remain indefinitely until either one of the proposals reaches the 70% majority or until this process is entirely rejected by the community.

### Miner Signaling
The miner stage is specified as follows.

The miner prepend the miner's extra data with 5 bytes of signaling data which shall be recorded in the Ethereum Classic block headers. The 5 bytes contain the following:
##### Miner Extradata Prefix
The miner signaling is specified as follows: The miner prepend the miner's extra data with 5 bytes of signaling data which shall be recorded in the Ethereum Classic block headers. The 5 bytes contain the following:

1. Two start bytes that indicate a signal in terms of ECBP-1076, namely `76` (`0x37 0x36`)
2. One option byte that favors one of the proposals:
- `A` (`0x41`): ECBP-1076-A _(optional)_
- `A` (`0x41`): ECBP-1076-A
- `B` (`0x42`): ECBP-1076-B
- `C` (`0x43`): ECBP-1076-C
- `D` (`0x44`): ECBP-1076-D
3. Two numeric bytes that vote on the default gas limit as specified in [ECIP-1047](https://ecips.ethereumclassic.org/ECIPs/ecip-1047).
- `00` (`0x30 0x30`): abstain / don't care _(optional)_
- `01` (`0x30 0x31`): support ECIP-1047 client defaults with 1 million gas block gas limit
- `08` (`0x30 0x38`): reject ECIP-1047 client defaults, explicitly supporting the 8 million gas block gas limit defaults
- `99` (`0x39 0x39`): any other number between `00` and `99` suggests a competing default block gas limit
- ~~`D` (`0x44`): ECBP-1076-D~~
- `E` (`0x45`): ECBP-1076-E

In addition to the numeric vote on the gas limit with the extra data field, mining nodes are encouraged to utilize block gas target limit voting with the suitable configuration flags for their mining nodes.
Given the circumstances, no signaling abstains from voting and shall not be regarded as favoring the status quo.

No signaling favors the status quo (ECBP-1076-A) and effectively rejects ECIPs 1041, 1043, 1047, 1049, and 1070.

### Mining Node Configuration Examples
##### Mining Node Configuration Examples
The following configuration examples do not favor one option over another and only serve the purpose of demonstration.

A Parity Ethereum node configured to vote for Keccak256 (ECBP-1076-C) not caring about the block gas limit:

```
parity --extra-data "76C00 Happy Trigger Farm" [OPTIONS]
```

A Multi-Geth node configured to vote for Ethash with DAG size limit (ECBP-1076-B) and a 1 million block gas limit (ECIP-1047):
A Core-Geth node configured to vote for Keccak256 (ECBP-1076-C):

```
geth --miner.extradata "76B01 Funny Classic Pool" --miner.gaslimit 1000000 [OPTIONS]
geth --miner.extradata "76C Funny Classic Pool" [OPTIONS]
```
A Besu node configured to vote for ProgPoW (ECBP-1076-D) and an increase of the block gas limit:
A Hyperledger Besu node configured to vote for RandomX (ECBP-1076-E):

```
besu --miner-extra-data="76D15 LOL-lonely Miner 1337" --target-gas-limit=15000000 [OPTIONS]
besu --miner-extra-data="76E LOL-lonely Miner 1337" [OPTIONS]
```

### Implementation
Expand Down