WIP: WIP-0009
Layer: Consensus (hard fork)
Title: Adjust mining probability
Authors: Mario Cao
Gorka Irazoqui
Discussions-To: `#dev-general` channel on Witnet Community's Discord server
Status: Final
Type: Standards Track
Created: 2021-01-26
License: BSD-2-Clause
This proposal adjusts the mining algorithm to limit the probability of non-reputed and non-active identities for mining a block.
The goal of this proposal is to mitigate potential network abuses that could be carried out by malicious users controlling a large number of nodes, as this could pose a serious threat to the network availability and security.
After more than 3 months since the Witnet mainnet launch, the network has faced episodes where transaction latency was higher than expected. During periods with a mempool full of transactions, blocks not using the complete block space appeared in the Witnet block chain. This reduces the throughput of the system, thus indirectly increasing the transaction latency perceived by users. Under a more critical scenario, may a large number of malicious nodes intentionally mine empty blocks, this problem could pose an availability threat in terms of a denial-of-service attack or even endanger the network stability by affecting internal network metrics (e.g. Active Reputation Set). For instance, malicious attackers may propose empty blocks to prevent transactions from being accepted. In the following paragraphs, this attack is referred to as a "censorship attack".
A thorough investigation concluded that most, if not all, these blocks were produced by non-reputed and non-active identities (i.e. newcomers to the network). Regardless of whether this is an intentional or accidental behavior, these blocks were appearing in a much higher number than it is to be expected from the newcomer mining probability as provided by the protocol.
The current mining algorithm can be summarized as follows:
- Each miner builds a block candidate.
- Each miner computes its own eligibility with the VRF-based RandPoE algorithm by using the ARS size as the difficulty parameter (labelled as
N). - May a miner be eligible, and had it not received a better block candidate, it will broadcast its own candidate.
Upon reception of multiple candidates, the winner is selected as follows:
- Block candidates are prioritized by VRF sections as described in RandPoE.
- Block candidates signed by reputed identities are prioritized over those from non-reputed identities.
- If there are still multiple candidates, the one with the lowest VRF value is chosen.
- If there are still multiple candidates, the one with the lowest block hash is chosen.
The main problem with the described algorithm is that the eligibility is computed using the ARS as a census, but the prioritization is only taking into account the reputed nodes. This misalignment leads to the increase of the newcomer mining probability. For example, on the 18th of January the newcomer mining probability would be close to 37%, as computed from the following network conditions:
TRS(Total Reputation Set) = 2000 nodes
ARS(Active Reputation Set) = 6000 nodes
RF(Replication Factor) = 3
P(non-reputed identity mines a block) = P(no reputed identity mines a block) = P(single reputed identity does not mine a block)^TRS = (1- P(single reputed identity mines a block))^TRS = (1 - RF/ARS)^TRS ~= 37%
In the initial mining algorithm design, DoS attacks were carefully taken into account. An upper bound for the probability of an attacker censoring blocks was set to approximately 2%. However, at a certain point before the mainnet launch some mining parameters were changed to achieve a fairer distribution of block rewards. This change assumed that the reputation expiration would be slower compared to the reputation activity period—which has a big influence in considering whether an identity belongs in the ARS. This assumption did not hold in mainnet as seen in the example above. This mistake led to a significant increase in the newcomer mining probability.
Summing up, there is a need for adjusting the newcomer mining probability to mitigate the impact of potential DoS attacks that may endanger the availability and the security of the Witnet network.
Following entry into force of this proposal, the same census must be used for the computation of eligibility and the prioritization of block candidates, as initially designed. The new block candidate selection algorithm will be as follows:
Upon reception of multiple candidates:
- Block candidates from reputed identities are prioritized over those from non-reputed identities.
- Block candidates from active identities are prioritized over those from non-active identities.
- If there are still multiple candidates, the one with the lowest VRF value is chosen.
With these proposed changes to the block candidate selection algorithm, the newcomer mining probability is now bounded as initially designed in RandPoe while the fair distribution among those identities that have proven some contribution to the network's service and security still applies. As an illustrative example using the same network conditions as in the previous section, with the new validation rules in place the newcomer mining probability would go down to almost 5%.
This proposal introduces a significant change in the block candidate selection algorithm. Therefore there is enough evidence to assert that it is not backward compatible from the consensus perspective and that no cooperative chain construction would be possible among two nodes from which one adopted these changes while the other did not.
As it is considered best practice in such situations, an Adoption Plan is hereby proposed.
The algorithm affected by this proposal is internal to the block chain protocol, and it does not trigger any update on existing examples or documentation.
The algorithm affected by this proposal is internal to the block chain protocol, and it does not require any update on existing libraries or clients.
The business logic described in the specification has been implemented in witnet-rust by pull request #1829.
Initially, the activation was announced and proposed by pull request #1829 for March 16 2021 at 9am UTC. However, the adoption was later delayed due to the network disruptions occurred on February 20 2021.
A new activation date is proposed for April 28 2021 at 9am UTC, in expectation that the protocol improvements described herein jointly enter into force with the related WIP-0011 and WIP-0012.
This proposal has been cooperatively discussed and devised by many individuals from the Witnet development community witnet/witnet-rust#1827.
Special thanks to Luis Rubio for the reference implementation in Rust.