witnet-rust
witnet-rust copied to clipboard
witnet
Assesment: Remove or not remove backup factor in mining blocks
Backup factor in mining was planned to avoid empty epochs (aka epochs with no blocks) increasing the probability of the miners to create a block upon the replication factor. And it is used to calculate the mining slots.
According with the current state of the mainnet, there are much more nodes running than the protocol is able to count (as active nodes), so it means that there are much more candidates in each epoch, so only candidates in slot 1 have been consolidated. Due to this, the backup factor is only used to increase the number of valid candidates that are flowing in the net, so maybe could useful to remove this field and only use the replication factor, removing also the slots comparison.
Right now there are indeed a lot of nodes outside the ARS, which makes for a lot of block proposals. However, unless there is an active problem with the replication factor (maybe it causes forks because there are so many valid blocks which do not reach all edges of the network?), I would say it can still serve as a useful fallback factor? If one or more big miners would fall away due to machine trouble or is upgrading his nodes, it could result in no blocks being proposed for an epoch? I think it's better to have too many blocks proposed than epochs without blocks.
Just some figures about the current situation, today there was an average of 25 block candidates per epoch (derived from block #230700 to block #231099 with at least 2 rollbacks during this period).
Just some figures about the current situation, today there was an average of 25 block candidates per epoch (derived from block #230700 to block #231099 with at least 2 rollbacks during this period).
Is this an average number derived from one or multiple nodes? If it's just from one node, there are likely significantly more since many nodes will have dropped inferior candidates? Do you observe significant outliers (for example, could it be that rollbacks correlate to spikes in proposed blocks)?
I was curious if I could repeat your experiment @mariocao. I started 4 local nodes on the same machine (guaranteeing a diverse set of peers) and logging the seen_candidates over night per epoch. I'm arriving at an average of only 7 candidates per epoch with relatively few significant outliers. My nodes are mostly seeing the same candidates (luckily). How did you measure the block candidates? Perhaps I'm seeing less candidates because I have little to no inbound peers?
Interestingly, there were three rollbacks during my measurements and 2 of them coincided with an abnormal high spike in block candidates on the epoch before the chain was restored:
| Date | Epoch before rollback | Epoch after rollback |
|---|---|---|
| 2021-02-12 | 231709 | 231732 |
| 2021-02-12 | 231789 | 231811 |
| 2021-02-12 | 231879 | 231902 |
I see a spike in blocks proposed at epoch 231731 (52 block candidates) and 231901 (28 block candidates). For the second rollback I observe no spikes.
Here's a plot of the proposed blocks per epoch, per node (and total) over time: proposed_blocks.pdf
I just extracted the numbers from the logs of a node by grepping the received block log. Maybe the difference lies in the fact that the node has been up for a long time and is listed as a bootstrap node. It should have a "good" representation (as it can be) of the network. :smile: