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.

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 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.

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.

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.
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.

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 next week.

 BigBang Core Cross Fork Transaction

Cross-branch transactions can be used to implement synchronous value exchange between BigBang Core fork without trust.In practical pplications, 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, crossbranch 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.

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.

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.

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.

BASE32Encode uses the Crockford scheme character set, but does not
carry out the symbols check process in this scheme.

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 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.

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.
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.

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
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.

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. 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 arecompletely isolated.

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.

• 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 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.

• 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.

• 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.

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 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.

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 "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.

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". 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.

The System Features of BigBang Core

• 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.

• 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.

The Introduction of BigBang Core wallet (Part 2)

• 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.
 

• 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 the BigBang Core network. Instead of local block synchronization and block data storage, focus on business-related
transaction data construction and authentication.

• 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.

The introduction of Wallet in BigBang Core （Part 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.

• 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. 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 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 multifork of the BigBang Core, Amazon DynamoDB that uses AWS's mslevel 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 highthroughput 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 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.

System software composition

To better support multiple application scenarios in the complex IoT environment, while ensuring the reliability of blockchain services
operation and usage requirements of ordinary users. The overall design of BigBang Core system software includes five part: core wallet program, light wallet background service system, mobile light wallet program, embedded system light wallet SDK and online block explorer.