1 / 61

Summary

Blockchain technology as a decentralized value transfer system was first

proposed by an unknown person named Satoshi Nakamoto and

applied to Bitcoin. In the Bitcoin system, Nakamoto creatively proposed

the scripting mechanism for the complex transaction. But if developers

want to achieve more functions by the scripts of Bitcoin, which often

subject to many restrictions. For this reason, Vitalik Buterin proposed

Ethereum that uses Turing's complete smart contract and EVM.

Ethereum brings the possibility of application development based on

blockchain technology, and it has been praised by the industry as

"Blockchain 2.0". But both Bitcoin and Ethereum are facing the problem

of expandability and transaction delay because of the rapid growth of

users and transactions data. The root reason is the single-chain structure

on these systems, which caused many excellent projects lack of enough

flexibility. Even the IoT that fits well with the blockchain is also hard to

develop.

To solve these problems and better combine the IoT with blockchain,

we propose the tree-based blockchain system called "BigBang Core"

after continuous exploration and demonstration. BigBang Core is a tree

structure of "primary-chain + multi-application fork chains". Through

the infinite expansion of branched chain, it solves the problem of

2 / 61

transaction extensibility and high concurrency which can not be solved

by single-chain structure. As the basic part of the IoT, BigBang Core will

establish the mutual trust and data exchange between devices in

heterogeneous environments. BigBang Core will build a stable

technological foundation for more complex business models of the IoT

in the future.

This paper will focus on BigBang Core's technical architecture and key

technology.

01. System Overview

1.1 Basic Introduction

BigBang Core is a block system on the peer-to-peer network. Similar to

the popular peer-to-peer digital currency, the transparent ledger is

maintained in a decentralized way, and then achieve autonomous

secure management and efficient flow of digital assets. BigBang Core is

designed for the IoT(Internet of Things) data requirement.

Use blockchain technology to provide decentralized security

management platform, and achieve the performance requirement such

as high concurrency and low latency for IoT systems.

BigBang Core packages users' transactions through security consensus

and produces data blocks in chronological order. Unlike the single-chain

3 / 61

systems such as Bitcoin, BigBang Core uses tree-based structure to link

and store blocks, so there are multiple forks according to business types

and data load. Blocks between forks are independent, and the new

block is only related to the fork it belongs. Because data can be

distributed to the blocks of multiple forks, the scalability and high

concurrency generated by multiple forks are the basic performance of

the IoT system. The multi-fork structure consists of the unique security

primary chain and many application forks. The security primary chain

supports the global consensus mechanism, and application forks are

used in real business. The application forks can provide low-latency

transaction confirmation with a minimum of 2 seconds, so users can pay

corresponding transaction fees to achieve low delay business.

4 / 61

1.2 Consensus Introduction

As everyone knows, according to CAP, decentralization often means

inefficient TPS. The huge data in IoT is the difficulty of consensus. So

what is the right consensus in the field of blockchain and IoT, let's talk

about the evolution of consensus algorithms.

Proof of X is the popular consensus in the public chain. Proof of

Work(PoW) was first applied, but it has some disadvantages, such as

waste of resources, the concentration of computing power, lack of

finality and poor performance.

Proof of Stake(PoS) avoids waste of resources, relying on the center

mine pool, reducing the possibility of the 51% attack. But it also has

some disadvantages, such as difficult to determine the number of

accounting nodes, unexpected centralization problem, nothing at stake

problem.

To solve the above disadvantages, there are many mixed consensuses

now. They want to combine the advantages of both, and also avoid

some of the drawbacks, including PoW + PoS, DPoS + BFT and so on.

Therefore, the mixed consensus mechanism may be a develope

direction in the future for public chain.

5 / 61

1.2.1 Proof of Work(PoW)

PoW(Proof of Work) distributes digital currency according to the

workload of miners. The higher the performance and the more the

number of the mining machine, the greater the workload, the more

digital currency will be distributed.

Bitcoin is a typical example of using the PoW scheme. Miner gets the

right of packaging through mining that solved a mathematical problem.

If successful, the miner receives bitcoin reward because of costing

computing power. To control the currency rule, mining is set to a more

complex model. Because the possibility of solving the problem by one

miner depends on his calculating power, the difficulty of mining is

determined by the sum of all the calculating power in the system.

For the cryptocurrency of PoW, miners confirm transactions by

competing to solve a mathematical problem. The first miner solved

6 / 61

mathematical problem receives the reward. The complexity of the

problem is designed to control the currency rule.

This method solved the Byzantine general problem very well, but it was

criticized by others as inefficient due to the waste of resources. At the

same time, the only PoW consensus also faces security problems such

as the 51% attack.

With the development of the BTC and blockchain industry, the

disadvantages of PoW are also exposed. For example, the currency

owner cannot participate in any decision-making, and rights

concentrated on miners. This runs counter to the idea of

decentralization that decision-making right is concentrated on a few

miners.

1.2.2 Delegated Proof of Stake(DPoS)

DPoS is a new consensus algorithm to guarantee the security of the

digital currency network based on PoW and PoS. It can not only solve

the problem of excessive energy consumption caused by PoW in the

mining process but also avoid the problem of "trust balance" of PoS.

Then, DPoS has become the representative of consensus 3.0. DPoS

allows many users to participate in mining, which means that each

currency owner can vote. And then generate some delegates of the

same rights which understood as some nodes or pools. Their rights to

7 / 61

each other are exactly equal. Currency owners can change these

delegates at any time by voting to maintain the “long purity” of the chain

system.

1.2.3 EDPoS+CPoW

CPoW (ContinuityProof of Work) and EDPoS (Extensible Delegated

Proof of Stake) came into being to prevent the entire ecological

operation stopping from the collapse of a single consensus node, and

prevent the block network as a whole is not available from the collective

stopping of DPoS nodes. BigBang Core's security consensus mechanism

is EDPoS + CPoW. Block reward is the mining reward plus the total

transaction fee of block transactions. Voting for an EDPoS node by

token can increase the probability of the node packaging. Then Voters

share the block reward by vote. The node needs to raise more than 2%

of the total Token supply to become an EDPoS node.

8 / 61

CPoW is the supplement to EDPoS. Each round of EDPoS consensus has

a certain probability to decide to package by CPoW consensus. The

fewer token involved in the EDPoS process, the lower the security and

reliability of the EDPoS, and the higher the probability of packaging by

CPoW. Hybrid CPoW and EDPoS will enhance system security and

reliability.

In BigBang Core's tree-based structure, except for the security primary,

other forks are equal and independent. EDPoS nodes jointly establish a

packaging sequence through secure computing and generate a true

random number beacon. According to the principle of Byzantine fault-

tolerance, less than 1/3 of bad nodes will not be disturbed during the

entire secure computing process. If chose reasonable negotiation

algorithm and parameters, the safe computing process will not be

controlled unless the 51% attack. The consensus can achieve higher

consistency in BigBang Core, and systemic forks are very rare. So three-

9 / 61

block confirmations ensure that the historical data of the primary chain

is not rollable when the number of bad nodes token is less than 50%.

1.3 Network Introduction

The BigBang Core network is a P2P network composed of nodes that

running BigBang Core software. BigBang Core network architecture can

be divided into three layers: the node network layer, terminal service

layer, and IoT terminal layer.

The Node network is composed of nodes that running BigBang core

program, which synchronously checks blocks and transactions, at the

same time, making consensus.

The terminal service network as a distributed terminal backend to

provide access services for IoT(Internet of Things) terminals.

In order to support the huge IoT (Internet of Things) service, the node

network and the terminal service network constitute the BigBang Core

service platform together.

The IoT terminal layer includes intelligent sensors, controllers and

mobile terminals. A light client program which saves the private key to

complete transaction construction and verification is embedded in the

IoT terminal.

10 / 61

1.4 Software System Design

The BigBang Core software system can better support multiple

application scenarios in the IoT complex environment, while ensuring

the reliable operation of the blockchain service and the needs of

ordinary users. The design of the BigBang Core system software consists

of five parts: the core wallet program, the light wallet service system, the

mobile light wallet program, the embedded system light wallet SDK and

the online block browser.

11 / 61

1.4.1 Core Wallet

The core wallet program is used for backbone network nodes and

common users. It has certain requirements for the running

environment and hardware, and can completely use all the functional

modules of the blockchain system.

1.4.2 Light Wallet Service

LWS is an acronym for "light wallet service", which connects the BigBang

Core blockchain backbone network with terminal of data acquisition

sensor. Through it, blocks and transactions of BigBang Core wallet are

updated and cached in time to LWS high-speed memory database and

local database.

12 / 61

Based on these data, it calculates the latest UTXO of the public key

address corresponding to the private key saved on different terminal

devices and publishes this information to the Amazon cloud through

the MQTT connection with AWS's IoT Core. The message broker

forwards it to the terminal devices subscribed. Correspondingly, the

terminal devices will package the monitoring and collecting data into a

transaction according to the UTXO list, and publish it to the Amazon IoT

Core through MQTT.

The transactions are forwarded to the LWS that has subscribed topics

of these devices via the Amazon IoT Core's message broker. LWS will

verify these transactions. If successful, the transactions will be forwarded

to the BigBang Core wallet through the Socket API. After the BigBang

Core wallet receives these transactions, it broadcasts them to the

BigBang Core network through the P2P network interface. The

13 / 61

producing node collects these transactions and packages them into

blocks.

LWS uses the persistent-connected, two-way pub/sub message broker

provided by AWS to decouple the huge number of connections with

devices, which solves the high concurrency and high scalability of the

devices. LWS uses AWS's Amazon DynamoDB service to store the key-

value pairs, such as blocks, transactions, and UTXO data.

Due to the massive transaction data, packaged block data and UTXO

data generated by the high-concurrency TPS on the multi-fork of the

BigBang Core, Amazon DynamoDB that uses AWS's ms-level response-

delay storage service can create a block database and a UTXO database

for each application fork, thereby speed up the retrieval of data.

While LWS synchronizes the blockchain data of the BigBang Core,

caches huge block files to Amazon S3's highly scalable, highly persistent,

and highly available distributed data storage using high-throughput

and resilient Amazon Kinesis services. After collecting and processing

block real-time data, it can be used by other LWS in the neighborhood

of local physical addresses, and even provide retrieval services to LWS

worldwide. On the other hand, when the LWS occur synchronization

error with the core wallet or data, it can be quickly recovered from S3.

In addition, LWS uses AWS's rules engine to convert information, and

then use Kinesis services or Lambda services to divert data to different

14 / 61

AWS services. There can also use AWS's CloudFront service to provide

CDN-like functionality in an unstable network environment.

Use structured PB-level Amazon Redshift relational databases to store

structured blockchain data. It can be used for BigBang Core blockchain

web browsers, smart device wallet apps, and the data views that

BigBang Core developers and testers debug on running program.

LWS is developed by the high-concurrency language golang. The

program uses goroutine and channel to ensure that a large number of

concurrent device-side sending transactions can be processed in a

timely and efficient manner, thus achieving the packaging of massive

transactions.

1.4.3 Mobile-Side Light Wallet

The mobile light wallet program can make the terminal node not run

the full wallet program. It is also possible to verify transactions. It is

mainly used for IOS and Android mobile terminals, providing users with

secure wallet services in case of limited network bandwidth and

hardware performance.

1.4.4 Embedded System Light Wallet

The embedded system light wallet SDK provides a light wallet API for

IoT smart hardware that can be accessed through the terminal server to

15 / 61

the BigBang Core network. Instead of local block synchronization and

block data storage, focus on business-related transaction data

construction and authentication.

1.4.5 Online Blockchain Browser

The online block browser cooperates with the wallet node to display the

status of the block system in real time, and queries historical blocks and

transactions data.

1.5 System Features

Tree-Based

Unlike traditional single-chain systems such as Bitcoin, BigBang Core

uses a tree structure to represent and store block data.

Hight Scalability

For the massive data transactions of IoT, the horizontal expansion of

system is achieved by the infinitely forked tree structure.

High Concurrency

The TPS(Transaction Per Second) of each application fork can reach

5,200. A transaction can be packaged as soon as 2S. This can satisfy the

characteristics of frequent transactions and low latency in the IoT.

16 / 61

Fast Data Reception

With a good system design, stable interfaces and backend services are

provided for both streaming data and persistent data.

Data Notarization

The BigBang Core chain stores data identification and transfers records.

Data identification can't be changed once it is packaged, providing

consistency proof and notarization data to both the demander and the

provider.

IoT Value Circulation Platform

As the underlying infrastructure of the IoT technology, it provides a

stable and reliable technology platform for data transmission and value

transfer on the IoT.

02. Tree-Based Block Structure

In common block-chain projects now, all transactions are stored in

single-chain. The lack of flexibility in the system in the face of growing

transaction scale. In BigBang Core, the primary chain data is separated

from the application data. Block data is stored in a tree-based structure

of "security primary chain + multiple application fork".

17 / 61

The security primary chain mainly stores transactions and security

consensus related data. The application forks organize and store the

data related to the application business by forking from any chain. As

the expansion of the transaction scale, the fork can continue to create

child forks. Similar to vertical partition, it avoids the disadvantage of

filling all transactions in the primary chain in the traditional single-chain

structure and achieves the horizontal expansion of the whole system.

The more forks on BigBang Core, the more TPS (Transaction Per Second)

the system can support. With enough forks, BigBang Core can carry tens

of millions or even billions of TPS loads as a whole.

2.1 Fork Identity

The blocks of the BigBang Core system are connected in chronological

order to form a tree structure with multiple forks. In BigBang Core, the

security primary chain and application fork are collectively referred to as

18 / 61

"fork". Each fork will have a unique fork identifier for marking. The

security primary chain uses the genesis block hash as the fork ID, and

the application fork uses the hash of the first block after fork as the fork

ID. Before the fork point, the parent chain and the application fork have

the same chain structure and transaction; the fork points are

independent of each other and do not interfere with each other. The

same Token that appears before the fork point can create different

transactions in the parent chain and the fork after the fork point to send

to different addresses; The block data before the fork point can also be

used in the parent chain and the fork chain. The user needs to specify

an anchor block when creating the transaction, and all branches that

are calibrated after this block are valid. In Figure 2.1, if the anchor block

is set to Block n-1, the created transaction will be included in two forks;

If set to Block n, the transaction is only valid in the parent chain, and a

new transaction can be created in the fork to send the Token to another

address.

19 / 61

2.2 Security Primary Chain

The security primary chain is the main chain of BigBang Core tree

structure, and all its forks are its "descendants", which are used to

support the security and consensus of the whole block system. In P2P

network, the priority of synchronous broadcast message forwarding of

the main chain is higher than that of the application fork. In addition to

recording Token transfer of the main chain, the security primary chain

also retains the data of key process negotiation of EDPoS nodes.

Security primary chain blocks can not be inserted between sub-blocks,

can only according to the given block interval growth. As a considerable

part of the capacity records consensus negotiation process data (take

23 EDPoS nodes as an example, negotiation data will occupy about

115KB of each block), the transaction capacity of the security primary

20 / 61

chain is lower than that of the application branch chain. The security

primary chain starts from the block system creation block and generates

the block through the EDPoS+CPoW consensus sequence. The security

primary chain is used to support the security and consensus of the

whole block system. All application fork nodes need to synchronize and

verify the block header information of the main chain. After the new

node is connected to the network, the main chain synchronization is

completed first, and then the corresponding application fork

synchronization is started.

2.2.1 Main Chain Special Transaction Type

In the security primary chain, there are three types of consensus-related

transactions that are unique to the security primary chain in view of the

particularity of functions: EDPoS node voting transaction; EDPoS node

registers transactions; CPoW block bonus trading.

1. EDPoS Node Voting Transaction

The EDPoS node generates a Delegate template address. For the first

time, it needs to send Token to this address to finish publishing Delegate

address on the chain. The user uses the same parameters as the EDPoS

node to create Delegate address, and stores Token in the Delegate

address to complete Token voting. An EDPoS node can participate in

21 / 61

the EDPoS negotiation process using a Delegate address vote as a

weight. When a user deposits a Delegate address to vote, the ownership

of the coin remains with the user and can be removed at any time, but

once removed, the number of votes of the corresponding node is

subtracted.

2. EDPoS Node Registers Transactions

In each round of negotiation, EDPoS node needs to raise enough Token

votes to create a registered transaction to register and publish its initial

negotiation parameters on the chain in advance, Only the node that

completes the registration before the negotiation round (more than 2%

of the total votes) is allowed to enter the negotiation process and obtain

the right to give blocks.

3. CPoW Block Bonus Trading

By default, CPoW consensus is only used for main chain consensus to

create block, and the block reward is provided to participants through

such transactions. The transaction is similar to the coinbase transaction

in Bitcoin.

22 / 61

2.2.2 The Parameters Of Main Chain

2.3 Application Fork

In BigBang Core, a user can creates an application fork by sending a

special type of transaction in the parent chain -- a fork transaction. The

block generation interval of the branch chain should be consistent with

the security primary chain. Other main parameters can be configured

by the creator in the process of branch creation initialization.

23 / 61

Configurable parameters include the total amount and the distribution

of tokens, block reward and additional issuance.

The first block of the newly created branch chain (the branch starting

block) is saved in the fork trade.

The Token distribution of forked chains can be defined by the creator

in three ways:

1. Create an independent fork, and reset the total Token amount and

allocation method of the fork starting block;

2. Complete inheritance of fork point Token distribution;

3. Inherit the distribution of fork points Token, and make additional

issuance on this basis. The distribution mode of additional issuance

is defined in the fork starting block.

Since the forking point, the forked chain Token and the parent chain are

completely isolated.

2.3.2 Mortgage Mechanism

In order to prevent the resource loss caused by high frequency forking

to the parent chain by malicious personnel, the parent chain Token

should be used for collateral in each fork chain establishment, and the

Token used for collateral in the forking transaction is sent to a special

address for freezing. The Token is thawed in stages according to the

difference between the height of the parent chain block and the initial

24 / 61

height of the parent chain block. The Token required to create a branch

chain decreases with the difference between the height of the block and

the initial height, and is completed in half every 525,600 blocks. Where

the cardinality N of the pledged Token is determined by the initial Token

supply of the parent chain.

2.3.3 Applation Fork To Make Block

The security of the fork chain is dependent on the consensus

mechanism of the security primary chain. In BigBang Core, there are

three main ways to apply branch chain:

1) block of EDPoS node.

This mode can not set up block nodes, and the EDPoS node can

generate new blocks for forks while obtaining the block right of the main

chain. This mode corresponds to the open business model.

2) block from the set up node.

The application side can also set up the block node in the application

fork chain and use the random beacon generated by the security

primary chain to set up the block mechanism of the fork. This approach

corresponds to a closed business model.

3) custom consensus mechanism.

25 / 61

In addition to the above two block-making methods, the application

side can also customize the consensus mechanism, which can be used

for the generation of application fork chain blocks and sub-blocks.

Application fork chain compared to the security primary chain, in

addition to the production of normal fork chain blocks, in the normal

every minute of the block interval, which can also produce sub-blocks,

for low delay transaction on the chain.

Sub-blocks are not less than 2 seconds apart, And no empty blocks can

be generated. The nodes that generate sub-blocks are determined by

independent random beacons of blocks of the same height of the

security main chain. Sub-blocks have no additional block reward, but

can obtain high transaction fee income.

Considering the sub-blocks in the application branch chain, the

transaction capacity of each application branch chain can be increased

by 30 times and the TPS can reach 5200. When data services require

higher transaction capacity and concurrency, multiple branch chains can

be created for the current application branch chain to achieve high

order TPS.

2.3.4 Application Fork Empty Block

In BigBang Core, the block height of the application fork chain is in sync

with the block height of the security primary chain, used to support the

26 / 61

application fork across the fork transactions and convenient fork block

reference to the main chain of the same height of the consensus results,

reduce the number of convenient query. Therefore, in order to maintain

high consistency, the application fork may produce empty blocks. And

between the empty block and the next fork block, no sub-block can be

generated.

When the fork is applied to select the EDPoS node of the main chain to

release the block, the EDPoS node of the main chain will take the Token

value of the fork as the priority reference, and independently choose

the supporting application fork.Lower value application fork may be part

of the main chain EDPoS node excluded from the block list.

In order to maintain the high synchronization of the main chain, the fork

chain will automatically fill an empty block.

2.3.5 Fork Chain Parameters

Using fork to carry the actual business transaction data, the size of sub-

block and fork block and primary block is the same. The TPS of fork is

expanded by reducing the block spacing of subblocks. The basic

parameters of applying fork are as follows:

27 / 61

03. User Key And Address

There are two types of addresses for BigBang Core: public key addresses

and template addresses, which correspond to specific public keys and

templates respectively.

The address length is fixed at 33 bytes, and the encoded address is used

as input/output parameter in the interactive interface.

28 / 61

BASE32Encode uses the Crockford scheme character set, but does not

carry out the symbols check process in this scheme.

3.1 Key And Public Key Addresses

BigBang Core system uses curve25519 as the basic security algorithm,

the user's private key and public key are both 32 bytes, and the private

key signature is 64 bytes. The security of curve25519 is the same as that

of P256, which is the most efficient asymmetric security algorithm at

present. Take the type prefix + public key as the wallet public key

address.

In order to ensure the security of the user's private key, chacha20 and

poly1305 algorithm is adopted to encrypt the local storage, and users

need to input the password before signing with the private key.

3.2 Template Address

The template address consists of the type prefix + template ID. The

template ID consists of 2 byte template type + 30 byte Hash parameter.

For example, a 3-5 multi-signature template:

29 / 61

3.3 Parametric Template

The popular blockchain system can provide scripts or intelligent

contracts running on different VMS (Virtual Machines), which can

expand the basic ledger of the block system with powerful and flexible

functions. However, so far, it seems that the VM module in the block

system is still in the initial stage. In addition to inherent security

vulnerabilities, operating efficiency and usage rate also limit the

application scope of intelligent contract to some extent. BigBang Core

system does not provide scripts and intelligent contract systems, but

uses parametric process templates to implement commonly used scripts

and intelligent contract functions. Use the corresponding template

address to provide function calls for users. BigBang Core system

provides the following templates:

30 / 61

04. Blocks And Transactions

4.1 Block

The structure design of BigBang Core block is as follows:

31 / 61

Description:

· the current block version is 0x0001.

· the time stamp is in seconds in UTC.

· vchProof includes serialized data of legitimacy proof, including

calculation results of EDPoS node broadcast (including signatures of

each node) in the security primary chain, and workload proof

parameters in the CPoW block;

In the application fork chain, the hash and consensus calculation results

of the main chain block with the same height are included.

· txMint does not sign, and the signature field is empty.

· block signature vchSig uses txMint output address to sign, and the

signature data segment contains all fields except vchSig.

32 / 61

4.2 Transaction

BigBang Core uses the UTXO model to record transactions, including

the following data:

Description:

· the current transaction version is 0x0001.

· hashAnchor is used to indicate the valid starting block and

corresponding fork of the current transaction.

· pre-order transactions in the input list requires the same output

address.

· the transaction consists of two outputs, one is listed in the table

(addrTo/nAmount), the other is the implicit change output, the address

33 / 61

is the same as the input address, and the amount is (Total Input -

nAmount - nTxFee).

· unified address of transaction signature with input list, signature data

segment contains all fields except vchSig.

4.3 BigBang Core Cross Fork Transaction

Cross-branch transactions can be used to implement synchronous value

exchange between BigBang Core fork without trust.In practical

applications, business can often be divided into multiple branches

according to business process, equipment type, spatial region and other

relevant factors.Devices with frequent interactions usually have the

same fork Token for data transaction in the same fork.But as a business

as a whole, the needs to interact with Token devices holding other forks

also exists objectively. In this case, cross-fork transaction can be realized

the Token exchange between branch chains. On the one hand, cross-

branch transactions can be completed in the case of no trust, and the

fairness of both parties is guaranteed by using technical principles. On

the other hand, cross-fork transactions enter the block synchronously

between two fork chains to ensure high efficiency and effectiveness.This

provides a good technical support for the application of decentralized

exchange and Token exchange gateway.

34 / 61

05. Consensus Mechanism

As mentioned above, the consensus mechanism adopted by BigBang

Core system is EDPoS+CPoW, which is dominated by EDPoS to

determine the node that gets the right of block next time or indicate

that the next block is generated by the consensus of workload proof.

When the EDPoS mechanism is not established effectively, such as in

the initial stage, CPoW becomes the only consensus mechanism.

The consensus mechanism is described in detail below.

5.1 EDPoS Node Negotiation Process

The number of Token votes held by the EDPoS node is used as the

weight of the block, and the fixed block node series is generated by

random number calculation. After the establishment of EDPoS

mechanism, random Numbers are generated through negotiation

between EDPoS nodes. The negotiation process takes place once a

minute, and fair random calculations are made through weighted

verifiable key sharing (VSS) and Byzantine fault tolerance.

Each round of consultation includes the following procedures: 1. Node

registration; 2. Encrypted sharding data distribution;3. Secret Footage

released; 4. Data reconstruction and random beacon calculation.

35 / 61

Before each round of negotiation, each EDPoS super node needs to use

ECC algorithm to generate a set of private keys: {a0,a1...,at-1}, and the

corresponding public key: {A0, A1..., At-1}, satisfies Ai = aiG, (i = 0,1...,t -

1). t is the threshold value of reconstructed data, and the maximum value

of t is 50 according to the effective EDPoS super node.

1. Node Registration

EDPoS super node will broadcast the registration information on the

chain before the round of negotiation for the 16 blocks of the standard

block, including the encrypted polynomial coefficient {A0,A1..., At-1}, A0

as the public key for node negotiation.

2. Encrypted Data Distribution

Distribution starts before the negotiation of bidding block and 16 blocks

end in the previous block. At the beginning of the distribution process,

the serial number is calculated according to the order of registered

nodes and weight allocation. The number of assigned serial Numbers

for each node can be calculated as follows:

Node i creates the common key Kij according to the negotiation public

key issued by other node j, and broadcasts the secret sharding sij to the

whole network after Kij encryption. The corresponding node j can verify

the sij with the registration information of node I after

decryption. Where Sij is calculated as follows:

36 / 61

Because the encrypted public key of node i {A0,A1..., At-1} has been

announced in the registration process, and node j is verified by the

following formula:

If the above equation is true, node i sends the correct secret sharding.

3. Secret Footage Released

After the current block broadcast, each node will broadcast all secret

sharding through the verification of the whole network. After collecting

the decrypted node sharding, the whole network node can also verify

through the above formula, and the effective data will be calculated

after eliminating the malicious node data.

4. Data Reconstruction and random beacon calculation

The whole network node can reconstruct {a0, a1, ..., at-1} by Lagrangian

equation by collecting t secret fragments of node i, and can not collect

t nodes that pass the verification secret fragment will be excluding, can

not enter the next phase of computing. By repeating the above

calculation process, all valid node data can be obtained finally. In this

process, the results of all reliable nodes will be consistent, and the

consistent random beacons will be obtained through combined

37 / 61

calculation. Since the data used for calculation are provided randomly

by each EDPoS node, the data of other nodes cannot be known before

the last step of calculation. Cheating nodes will be eliminated in the

check and reconstruction stage. Without considering the 51% attack, no

node can control the final calculation result, so it can be considered that

the generated random beacon has true random property.

5.2 Block weight distribution

In the case that the EDPoS mechanism is not effectively established, the

current block is generated by the CPoW consensus. When the EDPoS

negotiation is successfully completed, random beacon will be used to

roll dice. Suppose the Token vote of EDPoS super node i is Vi, and the

total EDPoS vote Vd = V0+V1+...+Vn, total Token supply is S.

The CPoW equivalent vote is Vwork = S * (1-Vd/S)^3

Probability of node i obtaining block weight Pi = Vi/(Vd +Vwork)

CPoW obtains the probability of block weight Pwork= Vwork/(Vd

+Vwork)

Repeat the process, and you can get the determined block sequence.

According to the block out sequence, the corresponding node

completes the current block out, and records the calculation process of

38 / 61

the last step of the negotiation after decryption into the block, self-

verifying the legitimacy of the block.

After the negotiation of EDPoS, the determined blocks can be calculated

and verified by all nodes in a consistent manner. In addition to

specifying the determined nodes for blocks, CPoW blocks can be

specified with a certain probability.

As shown in the above formula, the probability of CPoW block being

selected is related to the total Token quantity involved in EDPoS

negotiation:

In the initial stage, fewer nodes and tokens participate in EDPoS, and

the consensus mechanism degenerates to CPoW. When more and

more tokens participate in EDPoS, the CPoW block probability will

decrease rapidly.

39 / 61

06. The network unit

6.1 The node in the network

The BigBang Core program is run on network nodes for functions such

as block data generation and data update synchronization between

different nodes. The composition of the core program is shown in the

figure below:

As shown in the figure above, the underlying BigBang Core program

consists of a series of basic libraries and tool classes that provide low-

level API such as data storage, database access, security algorithms,

application frameworks, P2P networks/HTTP, etc.

The middle layer of the BigBang Core includes block data/real-time

transaction management, user wallet, block construction, which are

40 / 61

used to verify the management of block/transaction data in speficifc fork,

user wallet key, user transaction management, EDPoS/CPoW consensus

protocol. The upper P2P network layer implements the node network

protocol, on the one hand, it manages the network connection and data

request of other nodes, and on the other hand, it synchronizes the data

exchange with the middle layer by the data distribution interface.

The Core program of BigBang Core interact with external services

through JSON-RPC and Socket API to provide node control and

functional extension, JSON-RPC is mainly for RPC client programs,

wallet GUI, wallet node management and other human interactive

applications, Socket API Provides high-speed data synchronization

channels for light wallet services. The underlying implementations of

both external interfaces are the portal to functionality by calling the API

of SERVICE module in the core program.

6.2 Light Wallet Service and LWS-Client

The light wallet service, abbreviated as LWS. It is a bridge between the

blockchain of the BigBang Core network and the data acquisition sensor

of IoT device. BigBang Core Wallet's block and transaction data are

updated and cached on time in LWS's own high-speed memory

database and local database via LWS.

41 / 61

It calculates the latest UTXO collection of public key addresses for which

different IoT devices hold keys based on this bunch of data. And sends

(publish) the data to Amazon's cloud facility via a MQTT connection

provided by AWS IoT Core. Broker forwards to the IoT device where the

corresponding subscription (subscribe) has this information.

Accordingly, the IoT device will package the collected data into the

transaction based on these list of UTXO related to itself and publish it

to Amazon IoT Core via MQTT.

Then, the Message Broker of the Amazon service is pushed to LWS,

which subscribes to the sending transaction topic sending these devices,

and LWS verifies these transactions and, if the result of verification is

successful, the LWS forwards this transaction to the BigBang Core Wallet

via the Socket API. After received the transaction, the core program

42 / 61

broadcasts the transaction to the BigBang Core network by the P2P

network interface, and the node that generate block will collect these

transactions, which are eventually completed the process of packaging

these transactions into blocks and permanently stored on the

blockchain.

The LWS client program, as part of the IoT device Firmware, it uses the

CPU and secure computing coprocessor of the IoT device to process

BigBang Core transaction-related calculations including transaction

construction/deconstruction, HASH, ED25519 signature/check, etc. The

device private key is stored in a secure area of the chip and cannot be

read directly.

The MQTT protocol between the LWS and LWS clients enables

synchronization and real-time updates of UTXO list, and LWS responds

to transaction requests sent by the LWS client, which broadcasts the

transaction through the node of the core program connected BigBang

Core P2P network.

The full interaction process between IoT device sending a transaction to

LWS as follows:

⚫ Service Req/Reply

43 / 61

The LWS client initiates a service request, delivering information such as

the protocol version, wallet address, and required forks, the LWS returns

the data used to construct APIKey and supported fork list. The APIKey

is used for subsequent message signatures.

⚫ Sync Req/Reply

The LWS client initiates a synchronization request to pass HASH that

currently records the UTXO list, and LWS compares the HASH of the

UTXO list and pushes the corresponding UTXO list when determining

that the LWS client is out of synchronization.

⚫ Update UTXO

When the Block/Transaction status update (new block generation,

transaction broadcast), the node of core program notifies LWS via the

Socket API, which pushes the status change slot of UTXO to the LWS

client after self-filtering.

⚫ SendTx Req/Reply

The LWS client constructs and signs the transaction based on the

synchronized UTXO list, broadcasts the transaction over the LWS. Finally

the LWS returns the execution state.

44 / 61

6.3 Distributed Supernodes

6.3.1 The primary goal of scheme

The primary goal of distributed supernodes is to solve scalability

problems with the EDPoS nodes of the primary chain. BigBang Core is

a multi-fork blockchain2 system. EDPoS node need to generate block

for all valuable forks. With the increase of the number of fork blockchain,

the stress of the nodes of generating blocks will not meet the

requirement, and the single server can not meet the scalability

requirements of the system itself, so the distributed super node is an

effective solution to this problem.

6.3.2 Introduction to the scheme

In the sechem of the distributed supernodes, the key roles are ROOT

node server and fork node server with the different business.

⚫ ROOT node server

45 / 61

The ROOT node server is mainly responsible for consensus negotiation,

generating block for primary blockchain, main chain data management,

fork node management and other work, the ROOT node server stores

data with block signature key for consensus negotiation and generates

block for primary blockchain, which connected with BigBang Core P2P

network, On the one hand, EDPoS negotiation on the security primary

chain. On the other hand, interacting data with other fork nodes within

the supernode. A ROOT node server and other super node ROOT node

servers are connected via P2P , or with general nodes via P2P

Connection.

The ROOT node server only stores and verifies the data on the security

primary chain, the application fork data is processed by fork node

servers. Fork node servers and ROOT node servers are connected via

the Socket API or MQ, to transmit information such as secure beacons,

management data and so on. Fork node servers are dedicated to

organizing block data for a bunch of forks, each fork node server is

responsible for one or more fork data, and there are no any of two fork

node servers are responsible for the same fork data.

46 / 61

⚫ Fork node server

Fork node servers are connected to the ROOT node server via the

Socket API or MQ to receive and process secure beacons and

management data. The fork node server is connected to the

corresponding fork node of other supernodes via the P2P (the ROOT

node server obtains the connection address of the fork node by shaking

hands with the peer ROOT node server and distributes the connection

address to the fork node). When EDPoS negotiates that the current

ROOT node is selected as a node that generating block, the ROOT node

server constructs a new block of the primary chain and pushes the

context data of the generated block to each fork node server. Fork node

server (the fork node holds the relevant data of generating block

47 / 61

signature key). The fork node broadcast the new block to P2P network

after constructing and signing the new block data of its own fork.

6.3.3 The cascade scheme of supernodes

When the application fork chain load is too large and further upgrade

are required, distributed supernodes can be cascaded to build a cluster

of fork node servers to divert the huge application business stress, as

shown in the following image:

48 / 61

07. The cross-chain template and e-

commerce template

BigBang Core cross-chain template and e-commerce template are

implemented in a way that runs very efficiently compared to smart

contracts and scripts because they do not require VM compilation. At

the same time, BigBang Core trading runs fast, secure, and does not

have VM-like vulnerabilities that can be exploited to prevent tokens

stolen or reduce zero on the chain. However, non-intelligent contracts,

version update process slightly cumbersome, after the release of the

program, need to synchronize updates to each client, the later will add

the template automatic update module.

49 / 61

7.1 The cross-chain template

1. Create a cross-chain template that contains the wallet addresses of

both two parties and the two branch hashs involved in the

transaction, as well as the blocks locked height on the two fork

chains, and generate a transaction template address from this data,

which will change if any of the values of the data change. This

address can be used to receive tokens transferred by any user, but

within the lock height, to transfer tokens under the template address,

both parties' signature data is required to complete. After locked

height of the block , the two parties involved in the transaction can

transfer the Token from their own fork chain.

2. Sign the address of cross-chain transaction template and get the

signature data.

3. Both two parties can verify that the signature data is correct through

the public key provided by the other party and verify that the

signature data is the signature of the corresponding cross-chain

transaction template. Users who require the height of the block that

lower to send their signature results to other firstly.

4. Tokens in the cross-chain transaction template can be transferred

from the cross-chain transaction template through the signature

data provided by the other party and their own signature data, at

that point, the user's wallet is required to be open.

50 / 61

5. If you do not transfer Token within the "Packing Height that trader

first" after the transaction is sent, the third party will intervene in the

packaging block process. The third party can be a normal node or

a super node. It can help package and get a third party package

reward by using From and To address in the template and signature

data.

6. Note: The cross-chain transaction template is a one-time use

template, which can be further upgraded to become a reusable

cross-chain transaction template.

7.2 The E-commerce template

Thereafter, whenever the proof of transaction exceeds its validity period,

the data provider shall update the proof of transaction. Assuming that

both two parties agree to use T as the data settlement cycle, each time

after T interval, the data demander sends the proof of signature as

51 / 61

acknowledgment reply (ack) to the other party; at any time when the

transaction is interrupted or terminated, the data provider extracts the

Token from the corresponding order transaction on the chain with the

final the proof of signature.

When the data provider first extracts Token from the order transaction,

the demander can immediately get back the remaining Token. If the

supplier did not transfer the corresponding Token, the demander can

also get back the Token with a transaction containing a valid proof of

transaction, which will be broadcast but locked by the node that

generate block at 30 block height. If no valid proof of transaction is

included, the height of block 2880 will be locked from the order

exchange in the block. During the lock-in period, if the data provider

has a dispute, it can send its valid transaction to get back Token firstly,

and the disputed transaction will be discarded.

1. The seller sells the goods, the buyer buys the goods, de-centralized

point-to-point transaction, and the buyer refuses to pay the

transaction Token into the fund pool.

2. Transaction costs include transaction amount and security amount,

both of which can be customized. The security amount is used in

the security payment scenario to deal with the situation where the

52 / 61

seller receives Token without delivery or the buyer maliciously

transfers Token into the fund pool.

3. There are three possible situations in the transaction process: normal

completion of the transaction, buyer's failure to confirm after

reaching the block height, and buyer's dissatisfaction.

Complete normally：

When the buyer is satisfied with the goods, the confirmation information

(signature data) is sent to the seller, who uses the signature information

to withdraw the money.

Reach locked block height unconfirmed：

The seller does not need to obtain the signature data of the buyer, but

directly withdraws the money.

The buyer has dissent：

The buyer can transfer Token to the fund pool, but the seller can not

receive Token.

4. If the funds are transferred to the pool deliberately because of the

sins of the nodes, the arbitration template can be initiated by the

third party "arbitrator", both of the winner and loser can be decided

53 / 61

by the node voting. While transferring Token to the winner, a certain

proportion of Token will reward the voters and initiators.

5. During a gold prospectors cycle, gold prospectors can recharge the

value of the pool and obtain dynamic weights. After one gold

prospectors cycle, they can share Token in the pool according to

weights.

The principle is as follows:

⚫ Buyers and sellers create a trading template and trading rules.

⚫ In de-centralized transactions, the buyer with lock-in height of block

can only choose to send signature data to the seller or transfer

Token to the fund pool. After high lock-in block, the seller can

withdraw money freely.

⚫ For safety, set the safe amount, the buyer and seller mortgage the

same amount of Token to ensure the normal completion of the

transaction probability. For example, when the price of a commodity

54 / 61

S is 100 Big, the seller can set the security amount of the mortgage

to 10 Big. Once the template is created, the seller needs to issue the

commodity and pay the mortgage of 10 Big. At this time, the buyer

needs to pay 110 Big to buy the commodity S. After the transaction,

the buyer obtains the commodity S and 10 Big, and the seller obtains

110 Big.

Application examples:

IPFS Storage Market

Seller: Provide IPFS storage space;

Buyer: Purchase IPFS storage space;

Challenger: Challenge by any node at any time in the challenge cycle

(proof of space-time);

Gold digger: All participants who fill the pool with Token.

E-commerce Market

Seller: Provide goods;

Buyer: Buy goods;

Arbitrator: Arbitration shall be initiated by any node within the height of

withdrawal of funds permitted;

Gold digger: All participants who fill the pool with Token.

55 / 61

7.3 The bonus pool template

In a dividend-sharing cycle, gold prospectors transfer to Token in the

bonus pool and get dynamic weights according to the amount of

recharge. With the increase of contract-breaked transactions in

payment templates of e-commerce transactions, more and more

contract-breaked payments into the bonus pool. At the end of a

dividend-sharing cycle, gold prospectors divide up Token in the pool

according to their own weights. There can be multiple pools of bonus

in the system. Token can be recharged at any time, liquidated damages

can be flow in at any time, and dividends can be paid at any time, but

it may be in different dividend-sharing cycle.

The principle is as follows:

⚫ Anyone can create a bonus pool template and set a dividend cycle.

If the dividend cycle is the same, the template address is the same.

⚫ A dividend-sharing cycle can be divided into three stages: recharge

and calculation weight, liquidated damages flowed in and share

dividend

⚫ Gold prospectors transfer to the bonus pool to Token and obtain

dynamic weights. Dynamic weights are calculated according to the

total amount of Token into the fund pool in the recharge phase of

a dividend-sharing cycle.

56 / 61

⚫ At the end of the dividend-sharing cycle, Token is divided according

to the dynamic weight. When dividing up Token, you need to

provide your own proof of earnings (Merkel tree proof) and the

number of Tokens you mortgage.

⚫ At the beginning of the next cycle, gold prospectors need to re-

charge to obtain dynamic weights.

08. Postscript

The white paper provides a basic description of BigBang Core in

technical framework. As technology evolves, BigBang Core will continue

to evolve and update in line with the industry's technological advances

and actual project needs, including this white paper and relevant

technical documentation. In the future, project development process,

57 / 61

BigBang Core will start with the Internet of Things as the starting point,

dedicated to solving the current Internet of Things facing a bunch of

issues, and enhance BigBang Core's industrial base in the Internet of

Things industry. It will also explore in other industries, creating a

ecosystem of BigBang Core's applications in many industries.

09. Terminology

⚫ Tree-based blockchain

With the genesis block of primary chain as the root, the multiple tree

block structure of the branch chain is continuously generated by the

fork.

⚫ Fork

In BigBang Core, any chain can be referred to as a "fork" and each fork

has a separate fork identity.

⚫ Security primary chain

The primary chain in the BigBang Core tree-based structure, all of the

application fork chains are "descendants" of the primary chain. The

primary chain is mainly used to record Token transfer on the primary

chain, as well as data when the security consensus is negotiated.

⚫ Application Fork(Branch)

58 / 61

Application Fork in the BigBang Core tree-based structure, all

application forks can eventually be traced back to the security primary

chain. It mainly used to store the business data of the third party, it is an

important part of blockchain system for scalability

⚫ Hard fork

A permanent divergence in the blockchain, commonly occurs when

non-upgraded nodes can’t validate blocks created by upgraded nodes

that follow newer consensus rule.

⚫ Anchor Block

Used to identify new transactions from subsequent blocks can be

considered valid, and the user specifies when the transaction is created.

If there is more than one application fork after the block, and the

transaction is valid for those forks after the block.

⚫ Consensus Agreement

In the distributed system, in order to maintain the consistency of data

between unreliable nodes, the process of data write proposal between

nodes.

⚫ Subsidiary block

The block used to record public key address transactions for the current

application fork and partial process template address transactions

⚫ Extend block

59 / 61

The block type, which is unique to the application branch chain, it is

generated between two Subsidiary block at intervals of 2 seconds and

is designed to record a bunch of IoT business transactions under the

current application fork.

⚫ Byzantine Fault Tolerance

It is a fault-tolerant algorithm for Byzantine problem that solves how to

achieve consensus between nodes in the event that network

communication is reliable, but nodes may fail

⚫ VSS

Verifiable Secret Sharing, is a security protocol for the secure storage,

transmission, and legitimate application of data. It is composed of two

algorithms, the distribution algorithm of secret share and the secret

recovery algorithm.

⚫ EDPoS

Extensible Delegated Proof of Stake. It is a blockchain consensus

mechanism similar to the board structure. The basic feature is that each

coinholder in the community votes and then selects a specific number

of witnesses, who are responsible for the confirmation of the transaction

and the generation of the blocks.

⚫ CPoW

60 / 61

Continuity Proof of Work. It is a consensus mechanism to seize the right

to booking into the blockchain through competitive means, first applied

by Nakamoto in the Bitcoin system.

⚫ Data node

Running the BigBang Core program, but is not responsible for

generating block, it only synchronizes block data for a specific fork

through the configuration file, and provides data request services for

light clients through the appropriate interface.