Add Verifiable Random Function and test cases #2470
Conversation
I already did, will commit soon after I fully test it. |
update all related test cases add `GetRandom` contract runtime interface.
|
What do we use as the input of VRF? |
The hash value of the previous block, that value is well known to the public, so the primary could not cheat on this. The random number is generated through VRF, the primary can only calculate it but can not determine the value, nor can the primary modify it. |
|
There is a small problem here. The consensus node of the previous block can control the hash of the block. And if the consensus node of the current block fails, the consensus node of the previous block will generate the current block. In this way, the consensus node has the possibility of temporarily control the random numbers. |
Should not the previous block already being published? No matter who generates the random number, he can not determine the vrf value with a publicly known value as input. |
remove exception in VRF verify function
| @@ -238,7 +238,7 @@ protected internal int GetInvocationCounter() | |||
| /// <summary> | |||
| /// The implementation of System.Runtime.GetRandom. | |||
| /// Gets the random number genrated form the VRF | |||
| /// Primary geterates this random number with `prevHash`, the hash of the prevuous block | |||
| /// Primary geterates this random number with `prevHash`, the hash of the previous (validators.Length/3 + 1) block | |||
There was a problem hiding this comment.
What's the difference?
As you mentioned before, if we use the previous Block hash value as the feed, the primary might be able to control the value if the current consensus occurs view change, therefore, we should use the hash value of a block that is far away from the current index to make sure the dishonest primary could not know what the future Blockchain status is gonna be when it generates that hash value. https://github.com/neo-project/neo-modules/blob/f14c1a9d214bbdff43bb37ab33a09d76fc8c16d5/src/DBFTPlugin/ConsensusService.cs#L433
There was a problem hiding this comment.
But the previous (validators.Length/3 + 1) block also has the opportunity to have the problem.
There was a problem hiding this comment.
We should look backwards for the nearest block with a different primaryIndex.
There was a problem hiding this comment.
We should look backwards for the nearest block with a different
primaryIndex.
Now I use the hash of the previous 1000th Block. In this way, no primary could know what the future status would be when it generates Block.
|
Miss click sorry |
|
The changes to the master branch have been reverted. @Liaojinghui Can you create a new PR for it? |
|
Created a new pr in #2476 |
Implemented the class of VRF based on draft-irtf-cfrg-vrf-08 at https://tools.ietf.org/pdf/draft-irtf-cfrg-vrf-08.pdf.