Abstract
Hyperchain is a brand new Blockchain Technology with higher performance and hybrid data compliance. So far, there are several well-known problems of Blockchain techniques, such as low efficient in generating blocks, black-hole of computation power[i][ii] and application bind to transaction-oriented Architecture. Although Blockchain technology has been widely accepted as the next generation infrastructure of the Internet, these flaws still are the major obstacle for the technology to become a world-wide network protocol. The goal of Hyperchain is to remove these stumbling blocks in the way and create a unified ownership layer of the Internet. We propose a new method to provide time-slicing CAP consistency of distributed system and we design a new algorithm called Buddy Consensus based on this theory. Three new primary technical features are brought in – a parallel architecture of block generating, the hybrid data compliance, and a chain-in-chain virtualization context. Some other secondary features, like a built-in cross-chain interoperation environment, a customizable consensus mechanism, and so on, are created and can be directly invoked from the application layer. These features widen the application scope of Blockchain much more and open a more promising future of it. Unquestioning, Hyperchain also support all common features provided by existing Blockchain technology, such as transaction, Smart Contract but with a much higher efficiency.
Content
1.2 The Background and Vision.
2.1 The Definition of Blockchain.
2.4 Comparison to Common Blockchains.
4.1 Initialization and Node Establishment
4.2 Consensus and Anti-Cheating.
4.3 Data Submission and Query.
7.1 Application and Business Scenario.
7.2 Application: Copyright Claim and Authentication.
7.3 Application: Crypto-Currency and Ledger
1 Introduction
1.1 What is Hyperchain
Hyperchain is a brand new Blockchain technology with following technical characteristics:
- A parallel chain architecture
- A consensus algorithm supporting parallel block generating.
- Support application layer consensus customization and hybrid consensus compliance.
- Fully open on-chain data structure and customizable.
- No base currency, No unitary ledger, but built-in multiple crypto-currencies and ledgers support.
- Support chain-in-chain virtualization, built-in cross-chain interoperation support.
- Real decentralized architecture (no like those pseudo-decentralized, fake-decentralized Blockchain)
1.2 The Background and Vision
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 a currency system[iv]. On the contrary, BitCoin itself has exposed several fatal flaws, such as inadequate capacity, insufficient performance, and so on, after 7 years operating[ii]. Anyway, BitCoin is respect worthy for its contribution to provide a successful example and an undebated proof of the availability and stability of Blockchain Technology. However, when we turn to discussing a greater topic of constructing the new infrastructure layer of the Internet, and broaden the applicable scenarios to the extent of across industries, we would find that Blockchain technique is quite a crude system yet so far. Most of Blockchain systems are designed specific to crypto-currency and transaction-oriented user scenarios. They can neither handle non-financial process or data, nor provide sufficient system performance.
Start from the beautiful vision and existing problems above. The Blockchain industry have emerged many positive improvements. Some impressive features, for example Smart Contract based on Turing Complete Context, and some patches, such as Micro Channels, were brought into the technology. Except for POW, the consensus algorithms also have evolved several different solutions such as POS, DPOS, xBFT, POET and so on. these algorithms have fixed part of problems more or less[v][vi]but all of them are designed for crypto-currencies or are transaction-oriented for financial services so that their application scenarios are narrowed. Some derived consensus algorithms seriously destroys the decentralization trait of Blockchain so that their architectures downgrade to centralized or multiple centralized systems. Some technical improvements, such as Colored Coins and Lightening Network, trying work around the problems with off-chain system extension but these tricky methods does 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 generation fundamental technology of the Internet?
Hyperchain share the same vision with those Blockchain industry pioneers. However, we are eager to take a further step forward. We have done a major improvement to solve the existing problems. From a perspective of Internet service, we believe that Blockchain should no longer bind to transaction-oriented crypto-currency or finance scenarios. It should support more types of data, should improve the weakness in performance by equipping parallel data structure and algorithms, and should be a real decentralized architecture in order to carry the future of the Internet.
2 The Concept and Theory
2.1 The Definition of Blockchain
By decoupled Blockchain technique from cryptocurrency itself and untied it from distributed ledger we bring out a brand new definition of Blockchain technology as below.
Blockchain is a distributed data consolidation technology which process and store consensus.
The following 3 key factors compose the necessary and sufficient condition of a technique can be classified as Blockchain.
- Decentralized distribution system.
- All nodes are equal in processing and storing consensus.
- Forward dependent data structure.
Explanation
Processing and storing consensus is the key feature of Blockchain and differentiate it from other existing technologies. The decentralization trait prevents data and system from possibly biased manipulating by privileged node. All nodes are in equal is an essential criterion of Blockchain system. ”Consensus” is a publicly agreed result arrived from specific rules or algorithms without any control from specific nodes. It is quite different from the prejudged, biased or mandatory “consistency” in traditional distribution systems. Forward dependent means the technology should provide the data structure with data integrity and traceability by means of mathematical and cryptography methods. The 3 key factors together ensure a consensus may be produced, consolidated and irrevocable stored.
Any Blockchain system is flawed in capability if not satisfy all the 3 key factors at the same time. For example, without decentralization, the system degraded into traditional distribution storage system. Without forward-dependent data structure, it fell into a common P2P network. Without a consensus method, it downgrade to an ordinary fault-tolerant distribution system.
2.2 The Design Objectives
The goal of Hyperchain is to bring forth a high performance, application friendly, open and customizable Blockchain Technology so that the technology is good enough to support Internet applications in broaden area. the architecture is designed to fix the fatal flaws now in common Blockchain technology as mentioned earlier, low efficiency, transaction-oriented limitation, predefined data types, weak decentralized consensus, and so on.
The Hyperchain design objectives, technically to say, are
- Adequate parallelized data structure and algorithm to provide higher performance.
- A Peer-to-Peer network, real decentralized.
- Good compliance support to hybrid data (i.e. unstructured data).
- Neither rely on any preset base currency, nor is anchored to a unitary ledger.
- Built-in smart contract, cross-chain interoperation support
- Open architecture, support consensus customizable at application layer and customizable on-chain data structure.
- Support chain-in-chain virtualization.
2.3 The Basic Principle
Parallelized higher performance is one design objective of Hyperchain. Comparably so far the data structure of common Blockchain techniques are all in serialized schemes. This hard limit of serialized data scheme is a critical bottle-neck of performance. We aggressively evolve the on-chain data structure to a new parallelized scheme (please view detail in section the Data Structure). The evolvement may full utilize the built-in parallel computing capability of distribution network so that the chain system may produce blocks with much higher efficiency.
Simply change to a parallel data structure may not promote the system to higher efficiency because most of existing consensus algorithms are based on ledgers without parallel computing support. Based on the theory of Paxos, a fault-tolerant distribution system algorithm. We design a brand new parallel consensus algorithm to boost the performance (please view detail in section the Consensus Algorithm). The algorithm consolidate Local consensus into a global consensus based on our Peer-Mutual Witness theory.
Also, parallel chain structure somehow exists uncertainty of backtracking, technically say, multiple back reference pointers. We introduce a periodically data structure called Hyper Block to remove the uncertainty and guarantee the chain structure has the same capability of keeping continuously consistency as common Blockchain.
There is no hard constraints of Hyperchain data structure. It makes Hyperchain a full open Blockchain technique.
Hyperchain supports Smart Contract in the same way as common Blockchain.
Hyperchain satisfies the 3 key factors of Blockchain technology. It is real decentralized, consensus Peer-to-Peer and forward consistent.
Hyperchain is quite different from those serialized and transaction-oriented Blockchain techniques commonly used today. It is a parallel chain system fit for broaden application scenarios.
2.3.1 The Data Structure
The Hyperchain block contains Local Block and Hyper Block, Local Block structure is similar to common Blockchain block, technically say, a forward dependent consistency chain structure.
Figure 1 the Hyper Block Structure
Hyper Block is invented to resolve the contradiction between parallelized capability and traceability on continuous consistency. The block is also a forward consistent data structure and record information of Local Blocks.
Figure 2 the Local Block Structure
Between the periodically chained Hyper Blocks, Local Blocks are generating paralleled and consolidating with Hyper Block into a chain structure as below.
Figure 3 the chain Structure
2.3.2 The Consensus Algorithm
Hyperchain consensus algorithm is designed to answer the question of data consensus under a parallel context. Meanwhile it should support hybrid data types. Except for POW, all other existing consensus algorithms, only can execute consensus on specific consistent data, may not be used under such condition. So we create a new algorithm based on the Peer-Mutual Witness theory. The algorithm refers to Paxos but aggressively evolved in order to fix its flaw of implicit centralization, and finally we have arrived our real centralized and paralleled consensus – the Buddy Consensus Algorithm.
In Paxos, there are four roles Proposer, Acceptor, Client, and Learner[vii]. The algorithm was designed to implement fault-tolerant distribution system. Node in Paxos network is not peer to each other. In Hyperchain network, we combine these roles into two, Proposer and Acceptor. That is, every Proposer works as client and every Acceptor plays Learner. The standing point of the combination comes from the thought of every node is both server and client. Each client may access to its counterpart service only under the condition of providing service to the counterpart. We call such relationship as Buddy.
The Buddy Consensus procedure divides into two phases – Local Consensus and Global Consensus. Local Consensus starts from a pair of nodes which intend to log their data onto Blockchain. They broadcast their consensus protocol to discover each other and then request to join a Local Consensus. Now they both play Proposer’s role. Some while after any Acceptor replied, the Proposer will choose one Acceptor as Buddy by predefined consensus scripts. Then this Buddy node pair begin to assemble consensus data by the scripts. The system accepts such consensual data as initial Local Chain data the Buddy nodes both own. Next, the node pair works as a new Proposer, repeats the steps like before, increases the Local Chain in an exponential growth rate of 2n, until the chain reach the predefined length in the scripts. Such procedure is parallel executing thus there will be multiple Local Chains growing in the system at the same time.
The global consensus is periodically executing. The global process will consolidate the information of the multiple Local Chains into a new Hyper Block. Thus bring out the parallel chains structure. The consensus is executed by delegate nodes of the Local Chains. The delegate node is elected by all Local Chain participants running the activated Local Consensus scripts. There are various ways to elect a delegate. By default, we set the rear node of a Local Chain to execute the global consensus. Then the delegate node executes the global consensus scripts predefined for Hyper Block, like the steps of building a Local Chain, to produce a new Hyper Block. After all participating nodes accepts the Hyper Block, the global consensus is accomplished. At this point of time, all nodes on-chain data are in a consistent state and it is the start point of time of next round of consensus. The new consensus campaign should embed in the digital fingerprint of the latest Hyper Block as a basis.
What should be put more emphasis is that the Global or Local Consensus themselves are also parallel executed. Although the Global Consensus itself should run periodically and serially, it should never block any execution of Local Consensus.
2.4 Comparison to Common Blockchains
The Hyperchain basic architecture design has removed the hard limit of serialized data structure. The architecture allow Hyperchain process consensus in parallel to get rid of the existing bottlenecks of common Blockchain technology. These bottlenecks include poor performance in a serialized executing context, Non-extensible of consensus algorithm due to fixed on-chain data structure binding, few data types and difficult to extend, heavy waste of computation power, pseudo-decentralization, and so on.
Hyperchain obsolete the common transaction-oriented design, bring in a layered mechanism to handle broader industrial data types of the Internet services. The Chain layer and Application Layer will never block each execution. Hyperchain has no base currency, not rely on a specific ledger, do not penetrate into user data and leave them to be fully explained by application. With such design, Hyperchain provide greater flexibility of data processing for higher layers. Furthermore, the chain support customizable consensus script to user data at application layer. Thus the on-chain data are no longer confined to specific ledger structure or transaction record of crypto-currency. They are equally important to the system and supporting multiple crypto-currencies and ledgers is possible now. When application is processing currency system or ledger, Hyperchain keeps the reliability to the same level as running crypto-currency or ledger on existing Blockchain systems. If application level consensus script were executed correctly, a common Blockchain system could be virtually running on Hyperchain.
Hyperchain is a real decentralized network. The Buddy consensus algorithm determines this particular trait. In contrast, the POW algorithm is a perfect decentralized method except for its heavy waste of computation power. POS family algorithms do not have the power waste problem but in fact give some nodes excessive power which would put notable negative impact on the equality trait of Blockchain network[viii] . The BFT series are simple and high efficient. However, they have severely destroyed the decentralized characteristic of Blockchain, downgrade to multiple centralized or even a common centralized system. Additionally, they were designed to maintain a strong consistency under fault-tolerant context. The semantics of strong consistency is much different from the concept of consensus in Blockchain. We have classified the prejudged strong constituency into the concept of centralized fault-tolerant scenario, not into the domain of decentralized consensus system. The strong consistency concept clearly runs in opposite direction to the concept of decentralization and equality. The idea of Buddy Consensus in Hyperchain likes Paxos, but we have done a major improvement to remove the possibility of prejudged strong consistency in the algorithm so that guarantee the real equality in all participating nodes.
Hyperchain is a Blockchain designed to run in parallel context. Meanwhile it got flexibility of consensus customizing on by layered consensus architecture. Because of this, we may run various kinds of consensus on Local Chains at the same time to support multiple crypto-currencies and ledgers. This feature have brought a natural convenience of cross-chain trading. Cross-chain interoperations can be serialized and consolidated to provide additional creditable evidences. Hyperchain build in a cross-chain processing engine for direct invocation from application layer and its operation directives can be extended at any time to meet the needs of multiple Blockchain interoperation.
3 The Technical Solution
3.1 The Architecture
3.2 The P2P layer
Hyperchain utilize P2P techniques to build a decentralized peer-to-peer network. Guarantee all nodes are equal in the network layer.
3.3 The Data Layer
Above the P2P layer, Hyperchain creates a virtualized chain space maintained by all nodes. A node does not necessarily maintain the whole chain data but only preserve the parts of data concern to itself. We provide a solution of redundantly storage of the whole chain data by the help of all the nodes in the network.
3.4 The Interoperation Layer
The layer provide functionalities of supporting nodes interoperation, local data encapsulating and processing, certified information handling, and so on.
3.5 The Consensus Layer
This is the driver layer of generating blocks. Whereas any node request to log data onto the chain, it should join a Local and then a Global Consensus through this layer. The layer ensures all nodes are equal and independent when processing data in a consensus, and finally arrives a consistent result in all nodes.
3.6 The Application Layer
This Layer include Modules such as on-chain extensions, Application Programming Interface, Node Information and Remote Control Management, etc.
4 Deployment and Run
4.1 Initialization and Node Establishment
Any node start running Hyperchain software will broadcast itself to discover and establish connection to Hyperchain Bootstrap Servers and thereafter try to connect to other Hyperchain node. It will identify the nodes hold the valid genesis block by verifying factors in the received response packets. Next, it requests chain space information from the identified nodes and compares the received information to determine the peers with valid chain data. After the node has initialized the local chain space cache through these steps, the node initialization is accomplished and it gets ready to join a consensus process and generating blocks at any time.
4.2 Consensus and Anti-Cheating
Hyperchain node join a consensus on the demand of registering its data onto the chain. The registering behavior might possibly come from node itself or is a kind of delegation action. The Consensus process at chain layer does not penetrate into or explain the user data. These data are encapsulated as payload in a data package waiting for consensus processing. Such package is a local data block storing certified information such as consensus scripts, public keys and so on. This data block should be validated and accepted by at least one other node peer or peers group in order to join a Local Chain consensus process later. The validating process will check the consensus script and certified information between the peers. The successful execution of the consensus script make the two peers into a Buddy and the new Buddy start to participating in a Local Chain consensus. In a Local Chain consensus process, every time the Local Chain extend itself by successful executing the Local Consensus scripts which have reached a less Local Consensus. The scripts will validate the user data by user defined rules to ensure the data satisfy the requirement of the consensus. Such validating process is executed by node itself independently. Any other node can pulse no impact on it. A Local Consensus becomes acceptable only under the condition of over N/2+1 nodes have accepted the consensus result. (N is the number of nodes joined in the Local Chain consensus). The Local Chain is grown on the exponential rate of 2n to increase the consensus scale. This bring in a higher efficiency in detecting malicious node and invalid data to ensure the reliability of the Local Chain. The consensus scripts contain both Hyperchain default scripts and user defined scripts so that a user may freely choose the data validation methods as need during a consensus. Algorithms like POW, POS, BFT and so on may provide additional validation information to reinforce data validation by brought in computational difficulty or authorization methods. However, by default without any additional validation information, Hyperchain still may defend itself from the 51% attack of malicious nodes.
4.3 Data Submission and Query
User data can be recorded on-chain through join the Hyperchain consensus process. The data can be a ledger, transaction record, certificate fingerprints and even any other type of data. User data are validated and consolidated by consensus scripts in a consensus processes. Then they are distributed stored in all participated nodes. All of them form a virtualized chain space which stores all chain data. The chain data can be requested and queried by any node. Also these data may be searched and explored with Hyperchain Browser.
5 Summary
A whole new architecture design has been done on Hyperchain. It provides parallel capability and flexible data type support, removes the bottleneck of performance and limitation of transaction oriented design. Hyperchain not only fully satisfies the 3 key factors, decentralization, Peer-to-Peer and forward dependency, but also provides a higher performance and a more open architecture – both on-chain data and consensus algorithms support user customization and extension and even more exciting technical features such as built-in cross-chain interoperation and chain-in-chain virtualization by default. These features help Hyperchain support broaden scenarios with higher performance, stronger configurability and fully compliance to existing common Blockchain applications, for example, Crypto-Currencies and Unitary Ledgers.
Hyperchain taps in new area of Blockchain technology and there are still some weaknesses need to strengthen. For example, the Buddy consensus algorithm has designed for lowering the waste of computation power and guaranteeing a good decentralization characteristic at a cost of higher network traffic and this would cause system performance downgraded if network connection went worse. Also, the characteristic of open data types would help garbage data avoid censoring much easier to occupy the precious chain storage. However, we believe these weakness would never possibly become non-fatal flaws by the help of further technical advance in network connection and data storage. We also will continue researching into these topics and improve them in further development work.
6 Terms and Abbreviations
7 Attachments
7.1 Application and Business Scenario
Claiming of right or licensing
- Digital copy right registration
- Ownership self-service
- Prove of existence of Intellectual Property before publishment
IOT Infrastructure, Applications and M2M Network
- Resource exchange between equipments
- Automated Process Tracking
- Self-organized group service
- Decentralized track and trace
Enterprise System
- Trusted Data Source
- Cross Business Integration
- Configuration Management
- Automated Certifying
Cross-Chain Trading of Crypto-currencies
Cross-border Trade
Decentralized Autonomous Organization (DAO)
Private securities, Peer Finance
7.2 Application: Copyright Claim and Authentication
7.3 Application: Crypto-Currency and Ledger
8 Reference
[i] . Kyle Croman. On Scaling Decentralized Blo ckchains. J. Clark e t al. (Eds.): FC 2016 Workshops, LNCS 9604, pp. 106–125, 2016.
[ii] . TradeBlock. Bitcoin network capacity analysis. https://tradeblock.com/blog/bitcoin-network-capacity-analysis-part-1-macro-block-trends
[iii] . European Union, Futurium, Next Generation Internet 2016-11: https://ec.europa.eu/futurium/en/content/bitcoin-blockchain-and-future-internet
[iv] . https://www.bitcoin.com/info/bitcoin-what-is-it-and-why-is-it-important
[v] .Sunny King, Scott Nadal(2012), PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake
[vi] .Marko Vukolic, IBM Research – Zurich, The Quest for Scalable Blockchain Fabric:Proof-of-Work vs. BFT Replication. iNetSec 2015.
[vii] .Lamport, Leslie (2001). Paxos Made Simple ACM SIGACT News (Distributed Computing Column) 32, 4 (Whole Number 121, December 2001) 51-58.
[viii] .Andrew Poelstra. “Distributed Consensus from Proof of Stake is Impossible”, https://download.wpsoftware.net/bitcoin/pos.pdf