Ergo's EIP 37, a tweak to its mining difficulty adjustment algorithm

The Ergo foundation has been working on a proposal, EIP 37, which would make its mining difficulty to stabilize. The need for such a change became apparent due to huge mining difficulty fluctuations observed recently. During the just concluded Ethereum merge, there was a large inflow of mining hashrate to Ergo for several epochs.

IEP 37 proposes to make 3 main adjustments 👇

We propose to make current difficulty readjustment more reactive and smoother by shortening epoch length, amplifying weight of the last epoch and put some limits on difficulty change as follows.

1. Changing epoch length from 16 blocks to 128 blocks
2. Calculate predictive difficulty according to 8 epochs, 128 blocks each, and classic difficulty as done in Bitcoin (averaged)
3. Set mining difficulty change per epoch at <= 50%

A pull request to implement and activate this proposal has already been submitted on GitHub. Members of the Ergo community have been invited to review the PR.

Simulation test results

Assuming block generation time = difficulty * c / price, the team behind EIP 37, run simulation tests.

Thus we made playground simulating random price walking in uptrend or downtrend. In a simulation, a blockchain is being mined by rational hashpower only. Hashrate is looking at current price and diffuculty. We assume that price and difficulty are changed at the same time, and then hashrate is moving in or out, which is affecting average block generation time t. We may assume then that t = d * c / p, so average block generation time t is proportinal to difficulty d and inversely proportional to price p. Fixing t (which is set to target block generation time, so 2 minutes), d and p at the beginning of the experiment, we can evaluate c. Then on each step we are randomly changing p and, according to difficulty from the previous epoch, we can get average block generation time for the new epoch. To have a trend in price, we are changing p by adding (or subtracting) a random value with fixed average, and also adding a random fluctuation.

TE: Total error - This represents a sum of differences between observed block generation time and target (120 s). The less total error, the better.

MD: Maximum delay

DAA: Difficulty Adjustment Algorithm

Additional simulation tests were conducted under unique conditions:

EIP 37 voting process

Miners are requested to take up their governance role and vote for or against the proposal. For the proposal to pass, at least 90% of Ergo miners have to vote in favor of the update. Just like before, voting will remain 1024 blocks.

The Ergo Foundation doesn't and will not participate in the vote, as they are a neutral party. Ergo developers set the voting options and the miners vote.

Voting configuration

Miners can use Ergo Protocol Reference Clients 4.0.100 to vote manually. Use 4.0.101 or 4.0.103 to auto-vote respectively.

While using version 4.0.100, a miner ought to set their config as follows:

1ergo {
2...
3  voting {
4    6 = 2400 #vote for EIP-37
5  }
6}

Alternatively, by updating their node to version 4.0.101, a miner doesn't need to change their config for voting. The upgrade itself suffices as a vote in favor of EIP 37.

Reference client 4.0.103 allows miners to vote for EIP-37 activation even if first block in a voting epoch is not proposing it. Miners should remove voting (ergo { voting ...) section completely from the config if they wish to auto-vote for EIP-37, lest the voting section overrides the default one!

Mining pools and solo miners are requested to update their nodes to reflect the way they wish to vote. Individuals who are pool mining should direct their hashpower to a pool that reflects the way they wish to vote. This table list shows how mining pools are voting.

The ergo Foundation twitter account tweeted on September 30th:

⚠️ Attention all #Ergo node operators!
In preparation for EIP-37, please update your node to version 4.0.100 or later ~ @ergoplatformorg

In layman's terms this means:

Ergo is going to fork for new difficulty adjustment algorithm/EIP-37. If you're running node versions other than 4.0.1xx your node will fork from the main chain when this occurs, so please update to stay in sync with correct chain! ~ TypoDaPsycho1

Mining pools' EIP 37 voting direction

The voting period will span the time between blocks 843,776 and 942,081.

For EIP 37 activation, 232 or more votes for activation are required in the last 256 blocks.