Technical White Paper of Hyperchain

Version 0.3  2019.1.21


Hyperchain is a brand new Blockchain technology designed to achieve higher performance and data compatibility. It enhances the limitation of Blockchain, namely, low efficiency in generating blocks, serious consumption of computing power and transaction-oriented. Although Blockchain technology has been widely accepted as the next generation of Internet infrastructure, these flaws are still the major obstacles for this technology to become world-wide.The goal of Hyperchain is to remove these stumbling blocks in the way. We propose the CAP time-segment consistency in the distributed system and a new algorithm called Buddy Consensus algorithm based on this theory. This algorithm offers three entirely new features: parallel block generating, disposing of discrete data and running virtual chain. Other secondary features, like built-in cross-chain interoperation and customizable consensus can be directly invoked from application layer. All of these features greatly widen the application scope of Blockchain. Hyperchain also can support all common features provided by existing Blockchain, such as transaction, smart contract but it will be more efficient.


1 Introduction.

1.1  What is Hyperchain.

1.2 The Background and Vision.

2 The Concept and Theory

2.1The Definition of Blockchain

2.2The Design Objectives

2.3 The Basic Principle

2.4 Comparison to Common Blockchains.

3 The Technical Solution.

3.1 The Architecture.

3.2 The P2P layer

3.3 The Data Layer

3.4 The Interoperation Layer

3.5 The Consensus Layer

3.6 The Application Layer

4 Deployment and Run.

4.1 Initialization and Node Establishment

4.2 Consensus and Anti-Cheating.

4.3 Data Submission and Query.

5 Summary.

6 Terms and Abbreviations.

7 Attachments.

7.1 Application and Business Scenario.

7.2 Application: Copyright Claim and Authentication.

7.3 Application: Crypto-Currency and Ledger

8 Reference.

1 Introduction

1.1 What is Hyperchain

Hyperchain is a new kind of Blockchain technology characterized by following features:

  • Parallel chain architecture
  • Consensus algorithm supporting parallel block generating
  • Customization for the consensus in application layer; coexistence of multiple consensus
  • Fully open and customizable on-chain data structure
  • No base currency, no unified ledger, supporting various cryptocurrencies and ledgers
  • Supporting virtual chain and built-in cross-chain interoperation mechanism.
  • Totally decentralized (distinguished from pseudo-decentralized and semi-decentralized Blockchain)

Hyperchain adopts highly parallel infrastructure and algorithms from the  beginning, making full use of the performance of the nodes in distributed system to achieve high efficiency. Hyperchain provides greater flexibility for both data and consensus. On-chain data is not transaction-oriented.It can provide better support to discrete data (inconsistent data, big data) and it is more open. While implementing these new features, Hyperchain can fully support all technical features of existing Blockchain (such as microchannel, smart contract etc.). Hyperchain is suitable for public Blockchain, consortium Blockchain and private Blockchain as well as financial and non-financial scenarios.

1.2 Background and Prospect

Blockchain technology has been successfully proved by the great experiment of Bitcoin. It is now well accepted as a critical technology potentially to be the next generation infrastructure of the Internet[iii]. In fact, as an experimental crypto-currency, Bitcoin has not touched any demands on wider area out of currency system[iv]. On the contrary, Bitcoin has exposed several fatal flaws, such as inadequate capacity, insufficient performance and so on. Anyway, Bitcoin is worthy of being respected for its contribution to provide a successful example and an undebated proof for the availability and stability of Blockchain technology. However, when we reassess it from the aspect of Internet fundamental infrastructure and application scenario across all industries, we find that Blockchain technology is still in a preliminary stage so far. Now most Blockchain systems are specifically designed for crypto-currency and transaction. They can neither process non-financial process or data, nor providing sufficient system performance.

Based on above prospects and existing problems, Blockchain industry has emerged many positive improvements. Impressive features, for example turing complete smart contract and patches, such as micro channels, were brought into this technology. Besides POW, consensus algorithms also have evolved several different solutions such as POS, DPOS, xBFT, POET and so on. These algorithms have fixed some of the problems more or less[v][vi]but all of them are designed for crypto-currencies or are too inclined to transaction-oriented which leads to their application scenarios are narrowed. Some derived consensus algorithms seriously destroy the decentralized trait of Blockchain so that their architectures downgrade to centralized or multiple centralized systems. Some technical improvements, such as Colored Coins and Lightening Network, are trying to solve problems with off-chain system extension but these tricky methods do not solve the problem of Blockchain its own. If Blockchain were difficult to carry on today’s financial system, how could possibly this technology become a next fundamental infrastructure of the Internet?

Hyperchain shares the same vision with Blockchain industry pioneers. However, we are eager to take a further step. We have done a major improvement to solve existing problems. From the perspective of Internet service, we believe that Blockchain should no longer bind to transaction-oriented crypto-currency or finance scenarios. It should support more data types, should improve performance weakness by equipping with parallel data structure and algorithms and should be a real decentralized architecture in order to bear the future of the Internet.

2 Concept and Theory

2.1 Definition of Blockchain

By decoupling Blockchain technique from cryptocurrency and untying it from distributed ledger, Hyperchain proposes a brand new definition of Blockchain technology :

Blockchain is a distributed data consolidation technology which processes and stores consensus.

The following 3 key factors compose the necessary and sufficient condition of Blockchain, a kind of distributed data solidification technique which can depose and store consensus .

  • Decentralized distribution system.
  • All nodes are equal in processing and storing consensus.
  • Forward dependent data structure.


Processing and storing consensus is the key feature of Blockchain and it differentiates itself from other existing technologies. Decentralization prevents data and system from possibly biased manipulating by privileged node. “All nodes are equal” is an essential criterion of Blockchain system. “Consensus” is a publicly agreed result reaching via specific rules and algorithms without any control from specific nodes. It is quite different from the prejudged, biased or mandatory “consistency” in traditional distribution systems. Forward dependency can guarantee the integrity and traceability using specific data structure by way of mathematical and cryptography methods. These three key factors jointly ensure the consensus could be produced, consolidated and irrevocable stored.

A Blockchain system will be regarded flawed in capability if it can not satisfy all these 3 key factors at the same time. For example, without decentralization, the system will degrade into traditional distribution storage system; Without forward-dependent data structure, it will fall into a common P2P network; Without a consensus mechanism, it will downgrade to an ordinary fault-tolerant distribution system.

2.2 Design Objectives of Hyperchian

The goal of Hyperchain is to bring forth a high performance, application friendly, open and customizable Blockchain technology so that it can be good enough to support Internet applications in wider areas. This architecture is designed to fix the fatal flaws in common Blockchain technology as mentioned earlier,namely, low efficiency, transaction-oriented, predefined data type, weak decentralization etc.

The technical objectives of Hyperchain are as follows:

  • Adequate parallelized data structure and algorithm to provide higher performance.
  • A Peer-to-Peer network, truly
  • Better support for discrete data (i.e. inconsistent or unstructured data).
  • Neither rely on any particular base currency, nor limited to any specific
  • Support built-in smart contract, cross-chain interoperation and other features
  • Open architecture, support customizable consensus on application layer and customizable data on the chain.
  • Support virtualization on the chain.

2.3 Basic Principle

Aimed for higher parallelism, Hyperchain can achieve high improvement on chain structure and propose a brand new parallel structure ( For more details, please read data structure section), because now the data structure of common Blockchain is serial and this rigid restriction becomes a main bottleneck of Blockchain. This change could take full advantage of the natural superiority of parallelism in distributed network and can highly improve block generating efficiency.

Simply change to a parallel data structure may not promote system efficiency because most of existing consensus algorithms are based on ledgers, they can not support parallel structure. Hyperchain designs a brand new parallel consensus algorithm (For more details, please read consensus algorithm section)which makes a high improvement on the basis of Paxos algorithm theory (a kind of distributed system fault-tolerant algorithm ). It adopts reciprocal inter-attestation principle and extends local consensus to global consensus.

Also, parallel chain structure somehow exists traceable uncertainties (Backtracking pointer is not nonuniqueness). We introduce a periodical data structure called Hyper Block to remove the uncertainty and guarantee that the chain structure has the same capability of keeping continuous consistency like the common Blockchain.

There is no hard limit to Hyperchain data structure which makes Hyperchain become a kind of fully open Blockchain technology.

Hyperchain supports smart contract and other application features in the same way as the common Blockchain does.

Hyperchain satisfies the 3 key factors of common Blockchain technology. It uses reciprocal consensus and is truly decentralized and forward consistent.

Hyperchain is totally different from those serialized and transaction-oriented Blockchain commonly used today. It is a parallel chain system which can be applicable for more wider application scenarios.

2.3.1 Data Structure

The blocks of Hyperchain can be divided into two types : Local Block and Hyper Block. Local Block structure is similar to the common Blockchain structure, namely, a forward dependent chain structure.The topology structure consists of Header and Body.

The data structure of Local Block consists of Body, Payloads and Script. Payloads contains all types of data from other nodes. Header includes block mark \(LID\), the hash of former block\(Hash_{LID-1}\), the value of Hyper Block\(HHash\), the \(root\) value of Merkle Tree,the hash value of data block \(Hash_{self}\) and the timestamp\(Time\)。 \(Body=f_{Body}(data_1,…,data_N,Script_1,…,Script_N)\)Thereinto,  \( data_1,…,data_N \) is the collected data,\(Script_1,…,Script_N\) is the corresponding script;
Thereinto,,\( root=f_{MerkleTree}(Hash_{(data_1,Script_1)},..,Hash_{(data_1,Script_N)}) \)
\( Hash_{self}=f_{hash}(LID,Hash_{LID-1},HHash,root,Body,Time) \)
\(Hash_{data_x}=f_{hash}(data_x,Script_x), x=1,…,N \)

The assembling process of Local Block is as follows:


Figure 1  Local Block Data Structure

Hyper Block is invented to resolve the consistency contradiction between parallelism and traceability. It is also a forward consistent data structure and can record Local Block information.

Figure 2  Hyper Block Data Structure

Between periodical Hyper Blocks, Local Blocks are parallel generated and together with Hyper Chain they form a kind of chain structure as below.

The data structure of Hyper Block consists of \(Body\),\( Payloads\) and \(Script\). \(Payloads\) contains the mark \(Hash_{local}\) of other nodes from other subchains。Header includes block mark \(HID\) ,the hash of former block \(Hash_{HID-1}\),the\( root\) value of Merkle Tree ,the hash value of data block \(Hash_{self}\),and the timestamp \(Time\)。\(Body=f_{Body}(data_1,…,data_N,Script_1,…,Script_N)\)         Thereinto, \(data_1,…,data_N\) are the hash from selected subchains,,\(Script_1,…,Script_N\) are the corresponding scripts for data ;\(Header=f_{Header}(HID,Hash_{HID-1},root,Hash_{self},Time) \) Thereinto, \(root=f_{MerkleTree}(Hash(data_1,Script_1),..,Hash_(data_1,Script_N))\)

\(Hash_{self}=f_{hash}(HID,Hash_{HID-1},root,Body,Time)\) \(Hash_{data_x}=f_{hash}(data_x,Script_x),x=1,…,N\)

The assembling process of Hyper Block is as follows:

Figure 3 Hyperchian Parallel Structure

The Local Block and the Hyper Block will be generated based on the former hash. Different subchains adopts \(Layer2 consensus\) to further increase the degree of the difficulty and realize the high consistency of the entire data structure.

2.3.2 Consensus Algorithm

Hyperchain’s consensus algorithm is designed to answer the question of data consensus under the parallel situation. Meanwhile it needs to support inconsistent data. Except for POW, all other existing consensus algorithms only can execute consensus on specific consistent data, they can not be used under such condition. So we create a new algorithm based on reciprocal inter-attestation principle. This algorithm takes Paxos as reference but makes  great progress in avoiding implicit centralization and achieves a totally decentralized parallel consensus algorithm called Buddy Consensus Algorithm.

In Paxos, there are four roles: Proposer, Acceptor, Client, and Learner[vii]. This algorithm was designed to implement distributed consistency and fault-tolerance. Node relation is not equal in Paxos. In the totally equal scenario of Hyperchain network, we merge them into two roles: Proposer and Acceptor, namely, every Proposer works as Client and every Acceptor plays the role of Learner. The standing point of this combination comes from the thought that every node is both a Server and a Client; Each Client can access to its service only under the condition of providing Server service to its counterpart. We title such relationship Buddy.

The figure below is the description based on finite state machine theory. As mentioned before, there are two states for participated nodes : “Adviser” and “Buddy Partner”. “ Acceptor ” is also a “Buddy Partner”. There are 4 different responses. When a node joins the network in the state of “Adviser”, if it fails to be recorded on the blockchain, the node is still in a state of “Adviser”. If its its request is accepted by other nodes, its status turns to “Buddy Partner”. If the communication appears to be abnormal, its status will revert back to  “Adviser”.

Figure 4 Finite State Machine of Buddy Consensus Algorithm

Buddy Consensus algorithm divides consensus into two phases: Local Consensus and Global Consensus. Local Consensus starts from a pair of nodes which intends to log their data onto the Blockchain. It broadcasts its consensus protocol to discover other nodes and proposes a request. At this moment, the role of the node is Proposer. When it receives a reply from Acceptor, Proposer will decide which Acceptor could be the Buddy according to predefined consensus scrip and assemble consensus data in the light of consensus scrip. And this consensus data is regarded that the initial Local Chain is possessed by these two nodes. Next, the node pair works as new Proposer, repeats the same steps like before and makes Local Chain increase in an exponential growth rate of 2n, until the chain reaches the predefined length in the script. This procedure is parallel, thus there will be multiple Local Chains in the system at the same time.

The execution of global consensus is periodical. Global consensus process will consolidate related information of parallel co-existing multiple Local Chain into Hyper Block and form a parallel chain structure which is specifically possessed by Hyper Chain. Global consensus is executed by Local Chain  representative nodes. These representative nodes are generated by participating nodes of Local Chain according to the consensus scrip of Local Chain. So, there will be various ways to produce representative nodes. By default, they are executed by tail nodes. Representative nodes adopt the same method used in Local Chain, calculating Hyper Chain in accordance with the consensus script defined by Hyper Chain and reach consensus between nodes.

At this point, Global Consensus process is completed, the data on the chain become consistent and new round of consensus starts. New round of consensus will consider the digital print of the latest Hyper Block as the basis of consensus.

It should be noted that Global Consensus and Local Consensus are also parallel executed. Besides periodicity and sequentiality, Global Consensus will  never block any of Local Consensus execution.

2.4 Technical Features and Advantages

The design of Hyperchain fundamental infrastructure removes the hard limit of serialized data structure, uses parallel methods to solve consensus issues of the Blockchain and solves several bottleneck problems of existing Blockchain technology, including performance issues caused by serialization, consensus algorithm extension limitation caused by data on the chain, limited data types and extension difficulties, computing power consumption problem, pseudo-decentralization etc.

Hyperchain obsoletes the common transaction-oriented design, but adopts a layered mechanism which is widely used in more extensive processing procedure in Internet industry data. Chain Layer and Application Layer will never block each other’s execution. Hyperchain has no base currency, does not rely on any specific ledger, will not penetrate user’s data but to leave them to be fully processed by Application Layer. With such design, Hyperchain provides higher flexibility to data processing. Furthermore, it allows Application Layer itself to define the consensus scrip based on user’s data.

Thus on-chain data is no longer confined to specific ledger structure or any base currency transaction record. On-chain data status is more fair and it  allows multiple ledgers to coexist. If applications use Hyperchain technology to create currency or ledger, it can maintain the same reliability as that on other Blockchain. When adopting a appropriate consensus scrip in Application Layer, you can even virtually run a kind of traditional Blockchain on Hyperchain.

Hyperchain is totally decentralized and is determined by its consensus algorithm. By contrast, POW algorithm is a perfectly decentralized, however, its computing power cost is quite considerable; POS family algorithms do not have power waste problem, however, in fact, they give some nodes excessive power which will exert notable negative influence on the equality trait of Blockchain network[viii] . BFT family algorithms are simple and efficient. But, they severely destroy the decentralized characteristic of Blockchain and downgrade to it multiple centralized or even a common centralized system. Additionally, they were designed to maintain a strong “consistency” under a “fault-tolerant” scenario. This is quite different from the genuine meaning of the word “consensus” in Blockchain. We consider that prejudged “strong consistency” is a sort of centralized fault-tolerance concept, not a consensus in a decentralized scenario and it is totally opposite to “decentralization”and “equality”. The ideology of Buddy Consensus of Hyperchain is similar to Paxos algorithm, but we have made a great improvement to remove the possibility of prejudged “strong consistency” in Paxos algorithm to guarantee the entire equality in all participating nodes.

Hyperchain is designed abiding by parallel principle. Meanwhile it achieves consensus algorithm extendibility by using different layers to manage consensus, therefore it can run multiple consensus on Local Chain at the same time and can support various digital currencies and ledgers as well. This feature provides a natural convenience for cross-chain operation. Cross-chain operation itself could be consolidated and serialized and can also provide a extra proof of credit. Hyperchain has a build-in cross-chain processing engine which can directly call data from Application Layer and it can extends these operations at any time to accommodate more Blockchain interoperation.

3 Technical Solution

3.1 Overall Architecture

3.2 P2P Layer

Hyperchain utilizes P2P technique to build a decentralized peer-to-peer network which can guarantee the peer-to-peer operation in network layer.

3.3 Data Layer

Virtual chain space established based on P2P layer is jointly maintained by all nodes. Nodes do not need to maintain all the chain data, but only to preserve the part of data which concerns itself. We can achieve chain data redundant storage through the help of all nodes in the network.

3.4 Interoperation Layer

This layer mainly provides interoperation between nodes, local data encapsulating and processing, certified information handling etc.

3.5 Consensus Layer

This is the driver layer of Hyperchain block generating operation. If any node has the request of recording data on the chain, it can join Local Consensus and Global Consensus via this layer and ensure that the nodes can process data independently and equally in consensus and achieve a consistent result.

3.6 Application Layer

This Layer includes Modules such as on-chain extensions, Application Programming Interface, Node Information and Remote Control Management etc.

4 Application Running and Deployment

4.1 Initialization and Node Establishment

After running Hyperchain application, nodes will try to detect and connect Bootstrap Server and other Hyperchain nodes via broadcast and inquire the nodes which accords with essential elements of genesis bloc in the received response packet. And the nodes will further request chain space information and confirm legal chain data and correspondent nodes by comparing the chain space information of different nodes sending back. When nodes accomplish the initialization of local chain space cache through above pressures, namely, node initialization is completed and nodes can start to join consensus block generating process at any time.


4.2 Consensus and Anti-Cheating

Based on the request of registering data on the chain Hyperchain joins the consensus. This behavior could be the self-need of a node or a certain agent behavior. The chain layer consensus process of Hyperchain do not explain user data, user data will be encapsulated as payload in a data package waiting for consensus processing. These data are encapsulated as payload in a data package waiting for consensus processing. As local data block, such data structure includes certified information including consensus script, public key etc. This local data block needs at least one other node peer( or peer group) to validate in order to join a Local Chain consensus process. The validating process will check the consensus script and certified information between peers. The successful execution of the consensus script makes the two peers into a Buddy and the new Buddy starts to participate in a Local Chain consensus. After the Local Chain increases, it will execute the consensus script which has reached a Local Consensus. The scripts will validate users’ data by  their customizable rules to ensure that the data will satisfy the consensus requirement. Such validating process will execute independently and it will not be impacted by any other nodes. A Local Consensus becomes acceptable only under the condition that over N/2+1 nodes have accepted this consensus. (N is the number of nodes joining the Local Chain consensus). Local Chain grows on the exponential rate of 2n to increase the consensus scale and this will bring in a higher efficiency in detecting malicious nodes and invalid data to ensure the reliability of the Local Chain. Consensus script contains both Hyperchain default script and user defined script so that a user can freely choose the data validation methods according to user’s need in consensus process. POW, POS, BFT and other algorithms can provide additional validation information to reinforce data validation by bringing in computational difficulty or authorization methods. However, without any additional validation information, Hyperchain still can protect itself from the “51% attack of malicious nodes”.


4.3 Data Submission and Query

User data can be recorded on the Blockchain through joining Hyperchain consensus process. The data can be ledger, transaction record, certificate fingerprints or any other types of data. These data can be validated and consolidated by consensus scripts in the consensus process. Then they are distributedly stored in all participated nodes, form a virtual chain space in the whole network and store all chain data. The chain data can be requested and queried by any node and could be searched and explored via Hyperchain Browser.

5 Conclusion

Hyperchain uses a brand new design in technical infrastructure, provides a kind of parallel capability and flexible data type support and breaks through the design limitation of Blockchain technology, namely, performance bottleneck and transaction-oriented. Besides decentralization, peer-to-peer and data structure forward dependency, Hyperchain can offer higher and more open structure. On-chain data and consensus algorithm support user customization and extension and they have more exciting new features : built-in cross-chain operation, chain virtualization etc. These features can make Hyper Chain have higher performance, better customizable capacity and more applied scenarios. At the same time, it is totally compatible with existing Blockchain applications ( such as digital currency and unitary ledger ).

Hyperchain is a innovation in Blockchain technology, so it still has a lot of room in improvement. Hyperchain consensus algorithm may consume more communication cost in order to decrease computing power and maintain decentralized.This will reduce system performance when the Internet is in poor condition. The openness of Hyperchain data may make the garbage data more easily to occupy the precious chain storage by avoiding censoring. However, we believe that these issues are not fatal with the increasing improvement on network connection and storage technology. And, we will continue to upgrade in later development process.

6 Terminology

7 Appendix

7.1 Application and Business Scenario

Copyright Claim and Permission

  • Digital Copyright Confirmation
  • Ownership Self-service Management
  • Pre-consolidation of Intellectual Property Right, Proof of Existence

IOT Infrastructure, Iot Application, M2M Network

  • Resource Exchange between Equipment
  • Equipment Process Automated Tracking
  • Self-organized Service
  • Decentralization Traceability

Enterprise System

  • Trusted Data Source
  • Cross-department Business Integration
  • Configuration Management
  • Automated Certifying


  • Crypto-currencies Cross-Chain Transaction
  • Legal Tender Cross-border Trade and Settlement
  • Decentralized Autonomous Organization (DAO)
  • Private Securities, Peer2Peer Finance

7.2 Application: Copyright Confirmation and Authentication

7.3 Application : Crypto-Currency and Ledger


[1] . Kyle Croman. On Scaling Decentralized Blo ckchains. J. Clark e t al. (Eds.): FC 2016 Workshops, LNCS 9604, pp. 106–125, 2016.

[2] . TradeBlock. Bitcoin network capacity analysis.

[3] .  European Union, Futurium, Next Generation Internet. 2016-11.

[4] .

[5] .Sunny King, Scott Nadal(2012), PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake

[6] .Marko Vukolic, IBM Research – Zurich, The Quest for Scalable Blockchain Fabric:Proof-of-Work vs. BFT Replication. iNetSec 2015.

[7] .Lamport, Leslie (2001). Paxos Made Simple ACM SIGACT News (Distributed Computing Column) 32, 4 (Whole Number 121, December 2001) 51-58.

[8] .Andrew Poelstra. “Distributed Consensus from Proof of Stake is Impossible”,