How does Nervos Network tackle the problem of randomness acquisition within the network?


Dfinity has native randomness within its consensus protocol by threshold signatures; Cardano uses their commit-reveal and secret sharing protocol to obtain randomness in their PoS consensus; Ethereum seems to try to use VDF as their solution.

So what is Nervos’ plan? Do you plan to obtain randomness in CKB or leave this tricky problem to the layer 2?


Imo the role of Nervos is to be a verifier, doing verifications (instead of some general computations), in which case I think randomness is not necessary.

However I think it’s perfect for CKB to be the verifier for an external randomness source.
E.g. take the role of Ethereum in the case of RANDAO


CKB uses PoW so PoW is the random beacon. Dapps can use upper layer randomness such as RANDAO if they need additional randomness. Randomness at an upper layer is more flexible because it’s not bound with consensus requirements, such as block interval.


Yes it’s true that CKB doesn’t not HAVE to provide unbiased randomness beacon. But according to almost all the known projects, there is no unbiased publicly verifiable randomness beacon can be built merely in the layer 2 regarding layer 1 solution as a black box. Besides, RANDAO is a feasible solution, but it’s still vulnerable to the censorship attack. More over, RANDAO contract cannot be deployed regardless of the underlying consensus procedure. Besides, can you explain more about how can CKB serve as a verifier in the randomness protocol.


Taking CKB’s PoW as the random beacon, can it be more robust than Bitcoin’s PoW when some miners (less than 50%) are corrupt?

I think such flexibility may be not so meaningful. Of cause we can put the randomness beacon into layer 2 as an application, and it seems that we can set the random number generating rate arbitrarily high. But I don’t know any solution can always hold unbiased under this circumstance.



But it’s another story if you ask if this is good, because it depends on the goal of a blockchain. If you want to build a blockchain whose solely purpose is to provide randomness, than you would need a design choice different from CKB.

CKB is not designed to be a perfect random beacon. CKB is designed to be a secure custody layer for crypto-assets.


We could use VRFs on CKB since it supports user defined crypto algorithm at a lower cost. Image a lottery scenario,

  1. User deposits token with pubkey on chain;
  2. N blocks later, every user sign the block hash with their secret key;
  3. The user with smallest signature wins the lottery.

This solution is better than RANDAO. Because it wouldn’t fail if someone refuse to reveal his/her commitment.


But this solution is less secure than RANDAO. It’s not unbiased. The miner can easily change the block hash and manipulate the random number. Even though there is no one trying to manipulate the result, the result is still not uniformly distributed. Smaller result has much more probability to emerge.


Yes. I agree on you.


Actually not, a miner must follow the PoW rules to generate a block, which limits the attempt times. Even a miner gets such as 10 times to change block hash at specific block height (means the miner has wasted 10 times PoW computing power), the miner still can’t manipulate the random number, because the miner cannot predict other user’s VRF output.

You could add a Hash function to the signature result to get an uniform distributed number?


Yes it’s true that miners must follow the PoW rules, but they don’t need to know others’ VRF results. They can just compare the 10 different results and choose the smallest one. Even this strategy is weaker than the one with others’ results known, the miner can still get significantly higher possibility than other users.

Another problem is I am not sure what the deposit uses for? If only the winner gets all the deposits, then this solution is not a purely randomness beacon. It’s bonded with some specific gambling game. It cannot be compared with RANDAO.

Yes, but we still can know what results are more likely to emerge, because a hash function is deterministic.