Hi Core developers, I strongly suspect this is an issue we need to investigate though I do not have solid evidence for this. Please see the picture below, in which I patched some lines to indicate which miner contributed to the blocks mined. What interesting is: the mining rate of each miner is normal by May 18, i.e. a miner's mining rate is likely depending on the proved power as expected, but after that time, it is getting worse, especially when the miner with ID t2hzrt4gppoehzb35ilsget5oqofnqbtsyuapka2a mined >90% blocks with only about 5%~7.7% proven power in recent two days. To me, it might mean two things: 1) the miner which mined the previous block have some preference on the new one; 2) there is a bug in the consensus implementation. If you check tipsets in the chain, you could see non-skipped blockes mined by this lucky miner for many tipsets. Any opinion?
Hi Core developers, I strongly suspect this is an issue we need to investigate though I do not have solid evidence for this.
@xiedapao hey @Steven thanks for pointing this out. This is something we've noticed since the 0.2.x release. go-filecoin is a prototype without a complete consensus protocol and currently block time is not enforced during validation. When we pick up focus on the consensus protocol again there are two measures in the consensus protocol spec to prevent this (1) timestamp rules and (2) VDF generation / checking during mining / validation.
Depending on how badly this impacts devnet useability we may throw in basic time stamp checking with the next release.
Also cool graph thanks for sharing that.
@xiedapao Looking back at your original hypothesis, idea 1) (that miners who mine a block gain preference in the next) is not true. Eliminating this phenomenon (typically called grinding as you likely know) is a major motivator of our existing design. Your idea 2) is true as noted above.
@xiedapao This is likely caused by this: https://github.com/filecoin-project/specs/issues/290
#290 Clarify use of BLS signatures for election proofs
The EC spec mentions that the Election Proof is the output of a VRF, and we mention that we use a signature to implement the VRF, but we don't specify which signature algorithm to use. Since this has not been made clear, and since specs for BLS signatures have not yet landed, go-filecoin has moved forward using secp256k1. This is not great as ECDSA signatures are not deterministic, and miners can just keep generating different signatures until they find a winning election proof.
@xiedapao @zenground0: Depending on how badly this impacts devnet useability we may throw in basic time stamp checking with the next release. My opinion: on one hand, this is a good thing, that someone in this network playing as a malicious miner(s), which is a very good test case, will make the network stronger eventually; on the other hand, as you may know, this could be used in marketing promotion from business point of view to mislead investors. So, I do not think this will badly impact devnet useability, however, it might badly impact the ecosystem. It's better to handler this earlier.