NIP-6_Proposal for adding random number support to NULS main network

 NIP: 6
 Title: Proposal for adding random number support to NULS main network
 Author: Niels Wang <>
 Status: Accepted
 Type: Core
 Created: 2019/01/21


As DAPP becomes more and more popular with developers, more and more DAPPs are running on block chains.Inevitably, some problems emerge.For example, in many lottery, game, lottery, password application projects, although they flaunt their de-centralization characteristics, but is it really safe, fair and not 100% guarantee?The core problem is the de-centralized random number problem. At present, most of them are used in DAPP of random number. The random number used can not guarantee fairness, but also can not allow hackers to predict the random results in advance according to the random process.For this reason, most members of the NULS core team, after studying and discussing, hope to add a mechanism in the NULS consensus to solve the problem of seed generation of decentralized random numbers.

NULS adopts POC consensus mechanism. Nodes participating in the consensus are continuously participating in the block (network maintenance) on the premise of meeting the conditions, and most of the nodes participating in the block are honest and credible.We can use this advantage to develop a random seed generation mechanism to serve the DAPP built on NULS.This random seed needs to satisfy the randomness and unpredictability to ensure fairness and prevent hackers from predicting or controlling random results in advance according to the random process.


This design is based on the POC consensus of the two-stage submission of random seed generation mechanism.That is, each node generates a random seed at the same time as the production block.The random seed is encrypted,And include the generated ciphertext in the block header.At the same time, the random seeds generated in the last production block of the node are obtained.The plaintext of the seed is included in the block head.In this way, the random seeds generated by each node are confirmed by the previous block produced by itself,Make sure it is not tampered with.The way to generate the final random seeds can be obtained by different algorithms, which can collect the random seeds in multiple blocks, thus ensuring randomness and security.


In order to solve the security and fairness problems of distributed random numbers, the core functions of block chain network are optimized, and random number seed acquisition mechanism is provided for DAPP developers to use.


  • Business process change content

    1. Changing the Block Header Creation Process
      Adding data to the block for the final generation of random seeds.
    2. Change the new block storage process
      Random seeds are parsed from block heads and stored according to height
    3. Increase access to random seed interfaces
      RPC interface and SDK interface are added to obtain random seeds for applications.

1. Add 40 bytes of data to the field ‘extend’ of the block head. The specific data structure is as follows:

Length Field Data Type Remark
32 seed byte[32] Random seeds provided by this block
8 nextSeedHash byte[8] The next block will provide the intercepted values of SHA256-tiwce results of random seeds for validation.

[^Note]: nextSeedHash:sha3-256(sha3-256(nextSeed)) ,The last eight bytes of the result

2. Processing Logic of Node in the First Production Block

When a node first produces a block, seed is set to 0 by default, which means that no new random seed is generated this time.

3. Processing Logic of NextSeed Node Loss

When a node loses seed due to restart, power outage, server migration and other reasons, seed can be set to 0, representing the loss of random seeds in the current block.。

4. Processing Logic When One Node Produces Two Blocks Continuously

When a node continuously produces blocks at a certain time, the random seeds in the second block are discarded. The reason for this is to make sure that random seeds are uncontrollable as much as possible.

5. Providing multiple interfaces for access to random seeds for intelligent contracts

  • Design of Native Interface for Intelligent Contract

    • Call method: Utils. getRandomSeed (param, param1)
    • Description of parameters:
    Parameter Data type Required Remark
    Height Long True Corresponding Height of Seed Acquisition
    SeedsCount Integer True Number of seeds sought forward from this height
    algorithm String False Algorithmic identification, interface can support a variety of random seed generation methods

    [^Note1]:SeedsCount has constraints and the allowable interval is 1-128.
    [^Note2]:When the random seed value in the block is 0, it means that the block failed to generate random seeds successfully.
    [^Note3]:Assuming that the input parameters are: height: 1000, seedsCount: 10. Represents searching seeds forward from 1000 blocks until the number of seeds meets 10. If within 20 blocks (seedsCount * 2) (between 1000 and 981 blocks), not enough 10 seeds, then the random seed acquisition fails.
    [^Note4]:algorithm:Various algorithms can be implemented subsequently, as “SHA-256”,“SHA-256 tiwce”,“Merkle Root”,Xor,“RIPEMD-160”,Specific identification strings are based on the final implementation.

    • Return Values:

      Field Data type Remark
      success boolean Successful acquisition of random seeds,Success: true, failure: false
      seed BigInteger Random seed
      algorithm String Algorithm id
    • Random Seed Computing Method

      1. Splicing all block seeds in order of height
      2. Computing the spliced byte array with SHA3-256
      3. Make another calculation of SHA3-256
      4. Return the result of calculation
  • RPC interface

    • Call method: GET:/random Seed
    • Description of parameters:
    Parameter Data type Required Remark
    Height Long True Corresponding Height of Seed Acquisition
    SeedsCount Integer True Number of block seeds sought forward from this height
    algorithm String False Algorithmic id, the bottom can support a variety of random seed generation methods
    • Return values:

      Field Data type Remark
      success boolean Successful acquisition of random seeds,Success: true, failure: false
      seed String Random seed
      algorithm String Algorithm id


At present, the main ways of generating block chain random numbers are as follows:

  1. Generate future data on the chain, such as future block Hash, etc.

  2. Combined with external data generation, this method is quite diverse, such as centralized random number generation service, two-stage submission of random number generation by users and so on.

The first approach has one drawback.That is, block producers can control the generation of random numbers.It is difficult to guarantee fairness when random numbers have a great impact on interests.The second is that although there are many ways to achieve it, it either goes against the original intention of decentralization or does not have a good user experience or they can’t be very safe and unpredictable.

In view of this situation, we propose a solution of NULS by combining two ways of generating random numbers.It uses the data in future blocks to be random, but the data in future blocks have been published Hash in the early stage, and can not be tampered with any more.At the same time, the generation of each random seed can be combined by seeds in multiple blocks.Every seed producer can’t know the seeds of the front block, which can make the producer lose the possibility of controlling the random number.

The advantages of this scheme are as follows:

  1. Fairer, based on the realization of the bottom consensus, all consensus nodes participate, and it is difficult to connect in series.
  2. It is safer to submit seeds Hash and plaintext seeds in two stages. When submitting Hash, the results can not be calculated and the results can not be tampered with. The bottom layer directly provides the interface to obtain random seeds, which can be verified according to the parameters at any time.
  3. More flexible, random seed computing method supports many kinds of algorithms, increases the complexity of random algorithm, and increases the cost of doing evil.
  4. It is more convenient. The bottom layer directly provides the interface to obtain random seeds. The application end is convenient to obtain, safe and efficient. While providing SDK interface of intelligent contract, it also provides access mode of RPC interface, which does not restrict application scenarios.

Risk points:

​ 1. If an application specifies a future height to generate a random number seed, the producer at that height can know the random seed 10 seconds ahead of time (block interval).If the producer finds the random seeds of his block ahead of time and has a very bad effect on his own results in an application, he can choose not to submit the random seeds of the block.

For this risk point, it is suggested that when the future block height is specified when the random number is generated, it is not too close to the block, such as lottery application. If the lottery is awarded in one block after stopping the betting, this risk will occur, but if the height is set more, it can be avoided.Although the cost of perpetrators can be increased by consensus punishment, the invasion of consensus is too large, and when this situation occurs, only when the random number is calculated by a node can it be effective, and the choice must be made within 10 seconds, and the choice space is only submitted and not submitted, with less impact.So most applications can ignore this risk point. A small number of applications that need to be handled strictly can write logic in applications:When the selected height block itself does not submit a random seed, it waits for the next random seed to be generated and regenerated into a random number.

Backwards Compatibility

  • Backward incompatibility

    Because a new Native interface is added, when an intelligent contract calls the interface, there will be an exception in the historical version, which will lead to network bifurcation.

    This modification can be achieved by protocol upgrade. After 90% updates of all out-of-block nodes, 30,000 blocks are delayed for the new protocol to come into effect, and new versions are vigorously promoted in the community to guide users to upgrade their wallets.

Test Cases

To be supplemented