Bityuan is a simple, stable and expandable public chain network. In December 2013, BitYuan was born. Initially, it was produced by the pre-mining airdrop + POW consensus mechanism. In 2015, the BitYuan consensus mechanism was updated to POS. After more than four years of design and research, on May 17, 2018, BitYuan Blockchain 3.0 was developed and tested, the main network was launched, and it was upgraded to: SPOS (Safe POS), that is, a secure POS consensus mechanism that optimizes random numbers . More than 6 months later, on December 07, 2018, Bitcoin (BTY) was officially open-sourced on Github.
The research and development of Bityuan adopts the underlying technology of Hangzhou Complex Beauty Chain33, which is a public chain project with a multi-chain (parallel public chain) architecture that has been implemented and implemented. Multiple parallel public chains can be developed on the Bityuan blockchain. Each parallel public chain not only has diverse and independent blockchain ecological construction and DAPP development, but also can realize cross-chain exchange functions between multiple chains. The application fields of parallel public chain projects include: stable currency, red envelopes, social networking, e-commerce, asset on-chain, debt on-chain, certificate deposit, and games.

Storage methods supported by the project

The BitYuan blockchain took the lead in innovatively implementing MVCCKVDB (multi-version KV data storage). Traditional blockchains store data in the form of merkle trees or MPT trees. Every time the data changes,< br> The tree will be refactored once, which is relatively inefficient. For example, for a 20-layer Merkle tree, querying the data of a leaf node requires 20 read operations to complete, resulting in the efficiency of data query is only 1/20 of the query efficiency of ordinary databases, which can be completed per second A system with 100,000 read operations can only read data of 5,000 transactions per second, which greatly limits the read performance of the system. When writing data, it is also necessary to load the data of multiple nodes on the tree branch, and finally write it to the disk after updating. The operation consumption in this is also relatively large. BitYuan draws on the MVCC concept (Multi-Version Concurrency Control) in database design, and designs an original KVMVCC data storage format to improve the inefficiency of MAVL or MPT structures. Satisfy the need to maintain high data read and write performance after the blockchain data grows to a certain scale.
Hash calculation:
statehash=hash (prevstatehash, KVSet, height), which contains the state Hash information of the previous block, the state data KVSet information of this block, and the current block height information (that is, version information).
The following correspondence will be stored in the database of each node:
hash->height(version)
height(version)->hash
key:height(version)->value
lastest:key->value
Data query:
The corresponding height (version) can be found according to the statehash, and when the corresponding height can be found according to the height, the specific key value corresponds to The value value.
Data verification:
For a KVSet with a specific height, Hash operations can be performed according to the hash values ​​prevstatehash, KVSet, and height of the previous block. If the hash values ​​match, the data has not been Tampering, otherwise, the data is changed or the data is wrong (the height is wrong, or the KVSet data is wrong).
Maintenance of the latest version of data:
In particular, when storing the key and value of the latest block, at the same time keep (new key) or update (already have history Version key) key:latest->value mapping relationship is stored in the local key-value database. When you need to obtain the latest batch data, you can query the latest data in batches according to the latest prefix (can be customized). Since the usual key-value database can well support prefix matching queries, the query efficiency will be relatively high, much higher than the query of the Merkle tree storage structure.

Project super node

In order to improve the performance of the blockchain, the parallel public chain generally adopts the DPOS (Share Authorization Proof Mechanism) consensus, that is, several super nodes are selected on the chain to pay computing power and broadband support.
The transaction information must be packaged into the block, and the block information is broadcast to other nodes, and the transaction information is stored on the block to play the function of jointly governing the community.
Whether a public chain is successful or not, one of the key metrics is the number of nodes on the chain. The super node mechanism can help the parallel public chain to quickly establish an ecology on the chain, and rely on the operation and maintenance of each super node to promote the prosperity of the parallel public chain ecology and realize a more stable, powerful and decentralized area Blockchain system.
At the same time, the parallel public chain operator can set up a parallel chain foundation to promote the initiative and enthusiasm of super nodes through various token incentive mechanisms and operating methods of the foundation for super nodes, and through the repurchase of tokens, transaction procedures To promote the healthy and sustainable development of the parallel public chain.

The project supports oracle function

The oracle machine realizes the link between the blockchain and the real world. The oracle machine is a trusted entity that introduces information about the state of the external world through signatures, thereby allowing deterministic smart contracts to determine the uncertain
The outside world reacts. The oracle machine has the characteristics of non-tamperable, stable service, and auditable.
The oracle contract release data is divided into three steps:
(1) Release data release event (notify the whole network that the result of an event will be announced in the future, and assign a unique event ID, if the event is not occurred and can be undone).
(2) Pre-release results (the data provider pre-releases the time results, if the results are found to be problematic by the audit, they can be revoked).
(3) Publish the results (after the pre-release results are audited, they will finally be released on the entire network, which cannot be tampered with and can be audited and traced).
Other contracts (such as guessing contracts) can use the event ID and specific events in the above step 1 to carry out (guessing) activities. When the results of step 3 are announced, the guessing contract will trigger the contract to complete the guessing settlement according to the result corresponding to the event ID , to achieve an objective, credible, auditable, and traceable fair guessing without human intervention.