1/71...1/71 summary blockchaintechnologyasadecentralizedvaluetransfersystemwas...
TRANSCRIPT
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.