The Enhanced Random Number Generator for smartBCH

In the article "Light-weighted Manipulation-proof Random Number Generator for smartBCH", we introduced an enclave-guarded random number generator (RNG), which generates VRF outputs for smartBCH's block hashes, using a secp256k1 key that can only be accessed from within the enclave.

When using this RNG, the smart contract must fetch the block hash of a given height using the BLOCKHASH(0x40) bytecode and then verify the VRF output against this block hash with a proof that also comes from the enclave. The EVM specification limits that only recent 256 blocks can be queried for their hashes and the BLOCKHASH bytecode just returns zero for the old blocks.

This limitation causes inconvenience to DApp developers. When you want to submit the VRF output on chain as a fair random number, the corresponding block may be too old to be accessed by BLOCKHASH.

To solve this problem, EIP-2935 is proposed but it is unlikely to be accepted in the near future. So we decide to choose another solution: making the RNG endorse the relationship between the block height and the VRF of the block hash, with the enclave-protected secp256k1 key.

In the remainder of this article, we will introduce the light client concept and how the new RNG works.

Light Client

Light Clients, also known as Light Nodes or Thin Clients, are pared-down versions of full nodes. They do not download the entire blockchain but rather rely on block headers to validate transactions and world states.

RPC providers such as Infura and Quicknodes may cheat you if they turn evil. But light clients are always trustworthy as long as the blockchain's basic security assumption holds: for a PoW chain, it means more than 1/2 of the hash power is controlled by honest miners, and for a PoS chain, it means more than 2/3 of the validators are honest.

Light clients usually use a two-step scheme: validate the block headers; and prove the existence or non-existence of transactions or states against the Merkle roots contained in block headers.

Block hashes are actually block headers' hashes. So only the first step is needed for RNG.

The New RNG for smartBCH

The new RNG's workflow is as below:

1. Once it is started in an enclave, it gets a secp256k1 private key from EGVM's keygrantor and protects it in the enclave.

2. Get smartBCH's block headers from external helpers and validate them using light client technology

3. For a validated header, compute its hash which is also the block hash

4. Read the block height from the header

5. Compute block hash's VRF output using the enclave-protected secp256k1 private key

6. Generate a signature to endorse the relationship between the block height and the VRF output, using the same private key

The VRF outputs are generated in exactly the same way as the old RNG. So the DApps that rely on the old RNG can work just fine without modification. New DApps can use the signature to validate the VRF of blockhash at a given height, thus the BLOCKHASH bytecode is no longer needed.

The DApps know the EVM address computed from the RNG's secp256k1 private key. This address is determined by the RNG's binary code. If the code is changed, the enclave will generate a different private key and the DApps can discover this mismatch easily.

Reference

1. Light-weighted Manipulation-proof Random Number Generator for smartBCH https://read.cash/@SmartBCH/light-weighted-manipulation-proof-random-number-generator-for-smartbch-79ac7d36

2. EIP-2935 https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2935.md

3. The Ultimate Guide to Blockchain Light Clients https://www.nervos.org/knowledge-base/ultimate_guide_to_light_clients