Idena hard fork announcement: Mining delegation and oracle voting

Dear Idena community,

We plan to release a new version of the Idena node on March 22, 2021. It will be a seamless hard fork update.

Most of the introduced changes address the mining pools issue (see Phase 1 of the pools roadmap that was suggested). Mining delegation will reduce the cost of maintaining multiple nodes for large pools and motivate them to reveal their pool structure. Pool’s participants will keep their mining rewards but their votes will be counted as one. This will mitigate the concentration of voting power and at the same time to use pools’ strengths growing the network. Phase 2 of the mining pools roadmap will be considered based on the results of the network’s use of the delegation mechanism.

There are the following changes planned.

Mining delegation

1. Any validated identity can delegate mining to another address, which in this case will act as a pool. This will allow you to keep only one node per family or a company of friends instead of several and save mining costs.
2. The pool can terminate any identity that has delegated mining to it.
3. Leaving the pool is allowed no more than once per epoch. It is not allowed to leave the pool during the same epoch when mining was delegated.
4. The pool can turn on and off its online mining status. Pool rewards for block mining will be equal to those of a single identity. However, a pool can be selected as a block proposer or a committee member to validate a block more often than a regular identity in proportion to its size.
5. Identities included in a pool cannot mine coins by themselves. Mining income is automatically credited to the pool address, excluding the stake. The stake is credited to each address included in the pool.
6. All validation rewards are also credited to the pool address.
7. Offline penalties for a pool are applied in proportion to the size of the pool.

Motivation

Delegation motivates participants to unite in groups onchain. Such grouping will reduce the cost of maintaining multiple nodes. For mining, it will be enough to support only one node. In this case, pool members can be validated through one shared node using the Idena web client.

After delegation, the total mining and validation rewards remain exactly the same as if delegation is not used. Likewise, all oracle voting rewards remain the same. However, when voting, all the pool participants are counted as one.

Oracle voting and delegation

1. Pool members can participate in Oracle voting as independent identities. Their vote will be taken into account in rewards distribution. Only the participants who voted in the majority will receive rewards.
2. The votes of all the participants in the pool will be counted as one. The last vote sent from any address included in the pool is accepted as the pool vote.

Motivation

The delegation mechanism does not reduce voting rewards. However, votes of addresses included in the pool will not be able to collude in order to influence the outcome of the voting.

More changes in oracle voting

1. Preventing the disclosure of secret votes when the vote is prolonged

• Nodes will not automatically send transactions to reveal their vote if the quorum is not reached during the vote.
• The quorum will take into account secret votes. Counting of voting results will be calculated by revealed votes.

Motivation: To improve the security of voting when they are prolonged due to high quorum requirements

2. Preventing endless voting

Votes for which a quorum is not reached and the number of votes grows by less than 10% during three consecutive prolongings can be terminated.

Motivation: To unblock coins of the owners of the votes for which wrong parameters have been set or there is no activity

3. Protection against attacks on voting deposits

• Voting deposits of those participants who did not disclose their vote will be distributed to the participants who voted in the majority.
• The minimum counting period is 100 blocks.

Motivation: To prevent a potential attack that allows the oracle voting owner to steal voting deposits when the votes counting period is too short to prevent participants from revealing their secret votes.

4. Terminating expired votings

If a voting is not started in 30 days after the planned oracle voting start date, it can be terminated to unblock the stake.

Motivation: To unlock stakes of mistakenly created contracts that have not been voted on.

Increased flip rewards

Flip rewards are increased and rewards for unissued invites are canceled.

• Flip rewards fund will be increased from 32% to 40% of the Total reward fund.
• Invite rewards fund will be decreased from 32% to 24% of the Total reward fund.
• No rewards will be paid for the saved invitations.

Motivation: Increasing payment for the effort of creating flips (+25%). Increasing the number of submitted extra flips. Increasing rewards for flip reporting (+25%). Invitation rewards for the successful invitations will not drop significantly since lottery rewards will not be paid to other users. Total rewards for those categories of users who cannot issue invites (newbies) will increase.

Bug fix

Fixing the OracleLock smart contract bug that prevented unlocking coins.

How the hard fork will be activated

1. The new node version will support both the current blockchain protocol and the upcoming protocol changes.

2. Running the new version of the node means that the validated address is voting for the upcoming protocol changes. A node with an active mining status will be automatically publishing signals about the hard fork readiness.

3. The hard fork update will be activated only when the following voting criteria are met:

• more than 80% of online mining nodes support the upcoming changes
• more than 66.6% of validated addresses support the upcoming changes

4. The hard fork update will be activated no earlier than March 24. It will be activated anytime after March 24, once the voting criteria are met. Otherwise, the hard fork update will be blocked on March 28.