documentation, benchmark update, and contract interfaces #9
Conversation
| therefore, the proving/verifying keys are deterministic given a configuration. | ||
| The parameters are stored in "./kzg_params" and the generated contracts in "./contracts". | ||
| The option `-s` splits the verifier contract and verifying key contract so that the verifier contract | ||
| stays the same for different (t,n) values. The verifying key contract needs to be changed when (t,n) changes. |
There was a problem hiding this comment.
can we add a small note here: that the current contracts implementation sets t/n to (3,5)
| Instead, a lower bound $m$ with threshold < m <= number_of_members can be set to accept the NI-DKG process. | ||
| For example, m = (2/3) * number_of_members. If at least m members submit valid $(pp_i, zkp_i)$, then the NI-DKG can be considered successfully. | ||
| The members that do not submit will still be able to obtain a secret/verification key pair (in the following steps) as long as their member public keys are included. | ||
| These members can be allowed or banned from participating in the randomness generation process. |
There was a problem hiding this comment.
can we also add a note here, that the current implementation of contracts still expect submission from each member? (which will be changed in the future)
| ``` | ||
| $ RUST_LOG=info ./target/release/client rand verify-final <INPUT> | ||
| ``` | ||
| This command reads pseudorandom from "./data/random/pseudo.json". |
There was a problem hiding this comment.
Can we add another section for #Running Tests and #Deploying Contracts ? Otherwise, I could add them too after this is merged!
There was a problem hiding this comment.
Please add that section.
| roundToRandom[currentRoundNum] = keccak256(abi.encodePacked(sigma.X, sigma.Y)); | ||
| require(IPseudoRand(pseudoRand).verifyPseudoRand(bytes(roundInput[currentRoundNum]), pseudo.proof, gpkVal), "Incorrect random submitted"); | ||
| bytes32 value = keccak256(abi.encodePacked(pseudo.proof.x, pseudo.proof.y)); | ||
| require(pseudo.value == value, "Incorrect pseudorandom value"); |
There was a problem hiding this comment.
why do we want to take this as an user input and compare? instead of assigning the value directly. (gas savings)
There was a problem hiding this comment.
It is actually useful to avoid bugs/inconsistence. I just found out that the keccak hash in rust produces different value than the one in the contract due to some data format difference.
| } | ||
|
|
||
| currentRoundNum++; | ||
| uint256 currentTimestamp = block.timestamp; | ||
| roundInput[currentRoundNum] = currentTimestamp.toString(); | ||
| } | ||
|
|
||
| function submitPartialEval(Pairing.G1Point memory pEval, IPseudoRand.PartialEvalProof memory proof) public { | ||
| function submitPartialEval(IPseudoRand.PartialEval memory pEval) public { |
There was a problem hiding this comment.
is storing the proof on the contract useful?
There was a problem hiding this comment.
In the future, if we implement lazy verification, the proof won't be verified immediately when it is sent onchain.
No description provided.