1 Introduction

Bitcoin is a cryptocurrency with decentralized controls that was created in 2009. The blockchain technology it is based on is now widely accepted and used in many industries. Apart from becoming an internationally recognized currency, people are now hoping that this shared value system will enable the development of decentralized applications (Dapp) in each industry based on blockchain technology.

In addition to its use in cryptocurrency transactions, the advantages of blockchains, such as decentralized information verification and resistance to tampering, have been noted by various fields. Key applications include value registry, value web, and value ecosystem services. Industries with related applications include logistics, financial systems, medical records, the collection and verification of data in the Internet of Things (IoT), supply chain management, stocks or options trading, social networking software, electronic patient records, micropayment/mobile payment systems, asset transactions, and distribution of digital products. People are hoping that blockchains will be able to play the role of trusted machines in the operation of such systems. Keeping a detailed record of related information and solving information asymmetry problems will enable a trusted record to be established. In the use cases mentioned above, large amounts of information will need to be recorded on the blockchain.

Nevertheless, blockchain technology has encountered bottlenecks in the course of its development. If these cannot be overcome, it will be difficult for the blockchain to be fully implemented in the different application scenarios mentioned above. Each of these problems will be explained below.

The first problem is insufficient blockchain bandwidth. Blockchain’s decentralized operation is dependent on Internet users worldwide for its maintenance and use. Any user can therefore use block transactions to exchange cryptocurrency, write smart contracts, or record information. Bitcoin and Ethereum are, however, limited to no more than 7 and 25 transactions per second (TPS) [1], respectively. If no technology available can place large numbers of transactions on the blockchain, it will simply not be practical to solve information asymmetry by storing transactions on the blockchain.

Public blockchains are generally considered to have a global consensusFootnote 1. As shown in Fig. 1, the decentralized operation of the blockchain basically uses a consensus protocol such as Proof of Work (PoW) or Proof of Stake (PoS) to obtain or select a block producer from participating nodes. The block producer then collects transactions through a Peer-to-Peer (P2P) network and records these transactions in a single block within the blockchain using electronic signatures and a hash function. All nodes in the public blockchain participating in the consensus protocol must continuously update any changes to the data in the blockchain as well as obtain transactions that ordinary users want to place on the blockchain. Large amounts of information must therefore be exchanged over P2P networks, thus making it impossible to increase transaction bandwidth.

Fig. 1.
figure 1

A public blockchain

Full size image

A “private blockchain” or “consortium blockchain” is a method that attempts to solve the problem of insufficient transaction bandwidth. The number of participating blockchain nodes is limited to facilitate rapid propagation and the use of special consensus protocols (e.g., all types of PoS, BFT, and PoA), which contribute to speeding up the selection of block producers. There is obviously a big credibility gap between private blockchains and public blockchains. The core philosophy of a decentralized system is to reduce the access threshold and remove restrictions on participating nodes so that no monopoly on trust machines can be formed. In a private chain, the smaller number of nodes increases vulnerability to 51% attacksFootnote 2 and prevents global consensus.

Some public chain developments intend to increase speed by adopting an architecture with a smaller number of nodes, but that leaves them vulnerable to 51% attacks as well as Distributed Denial-of-Service Attack (DDoS) attacks that result in the stoppage of the entire blockchain.

The second problem is insufficient blockchain payload space. As described previously, in each type of system the public blockchain plays the role of the trust machine. As large amounts of transaction records are pushed onto the blockchain, the amount of data on the blockchain will rapidly increase within a short amount of time. Depending on the consensus model, full nodes of the blockchain must store every block on the blockchain and the transactions they contain. The consensus protocol of Bitcoin, for example, restricts the growth in blockchain capacity to around 70 GB per year. In the absence of such restrictions, the propagation and storage of blocks becomes a major problem. This situation is also known as “blockchain bloat.” VISA reported that it generated a total of 92.064 million payment transactions in 2015. If translated into the data structure used for Bitcoin transactions, it would amount to around 2,900 transactions per second and 47 TB of storage space. This already far exceeds the hard drive space on an ordinary computer.

The third problem is lack of privacy protection. All the transactions stored in a public blockchain are replicated in nodes from all over the world. At the moment, privacy protection in blockchains consists mainly of using a mechanism similar to money-laundering to conceal information about cryptocurrency transactions. There are two main methods: (1) Cryptography accumulators [2], used by Zerocoin, and (2) CoinJoin [3], used by SharedCoins, Dark Wallet, CoinShuffle, the PrivateSend feature of Dash, and JoinMarket. Cryptocurrency transaction information recorded on the blockchain gives no indication of the sender.

The two methods above can only be used for cryptocurrency transactions and so cannot be used for other general transactions or contracts. The popularity of Ethereum’s smart contract is due to its ability to handle general transactions or contracts, not just cryptocurrency transactions. These include asset transactions and patent licensing as well as contract, document, and information records. Smart contracts for non-cryptocurrency transactions cannot make use of cryptocurrency’s privacy protection technology, thus limiting the system’s scope of application.

The fourth problem is that the blockchain currently has limited application scenarios. The concept of decentralization has gained acceptance in some circles: the forging and trading of cryptocurrencies, for example, can now be completely implemented using a decentralized model. However, human economic activities are influenced by law, habit, legacy systems, and interpersonal relationships. Dispensing completely with centralized operations is impossible. Industries with related applications, such as: logistics, financial systems, medical records, the collection and verification of data in the Internet of Things (IoT), supply chain management, share or rights transactions, social networking software, electronic patient records, micropayment/mobile payment systems, asset transactions, and distribution of digital products—nearly all of these applications still require a centralized agent or intermediary. If the public blockchain cannot be integrated with industries that have similar centralized operations, the use of the blockchain as a trust machine will be greatly limited.

The following example uses digital product distribution to explain why that is the case. For digital products such as e-books, music, movie rentals, and electronic tickets, the widespread use of the Internet and larger bandwidth has popularized sales over online platforms. To expand their sales channels, the rights-holder will usually commission agents to make sales over the agent’s network platform. The agent collects payments from users and maintains a record of accounts. The accounts are then provided to the rights-holder at fixed intervals with details on downloads and corresponding royalties. However, since the accounts are recorded and maintained by the agent, the rights-holder is unable to verify their authenticity. For example, the agent’s records may contain accidental omissions or other errors due to bugs in the system. Or the agent may deliberately forge or modify the records to reduce the amount of royalties payable to the rights-holder.

Based on the explanations above, we can now give a summary of the current problems to be solved:

Problem P1: Blockchain transaction speeds are too slow. How can the blockchain handle a large number of transactions in a short period of time?

Problem P2: How can blockchain bloat be avoided when storing large numbers of transaction records on the blockchain?

Problem P3: How can the privacy of involved parties be protected when records for transactions other than cryptocurrencies are written to the blockchain?

Problem P4: In the real world, the division of labor in the commercial environment means that intermediaries (or agents) cannot be easily replaced. They may also form a wall between digital asset publishers and consumers. So how can we retain a system with many intermediaries while providing transparent, reliable, and verifiable consumption records?

These four problems are tightly interrelated. For example, if Problem P1 is solved and blockchain’s transaction bandwidth is greatly expanded, then Problem P2 seems inevitable. Large numbers of transaction records on the blockchain will lead to excessive data storage. If Problem P3 is solved, the privacy of the transaction parties will be protected and third parties will not be able to obtain transaction details, but then Problem P4, that of dishonest agents, may become even worse.

In this paper, we propose a multi-chain architecture to completely solve all of these problems. Transactions are first processed outside the main blockchain. A hash value which can be considered as a condensed fingerprint of these processed transactions is first recorded in a contactFootnote 3 of the main blockchain after the end of these transactions. Then, we apply a scheme called “distributed auditing” in which all participants examine their own transactions according to the uploaded fingerprint in the contact. In case there is anything wrong, such as incorrect or missing transactions, a participant can generate a small-sized cryptographic proof which can be sent to the contact to issue an objection (or even prove fraud). The pre-arranged function in the contact accepts the cryptographic proof and can then perform specific actions, such as paying bonds to the participant.

This paper is organized as follows. Section 2 shows the multi-chain architecture of InfiniteChain, including how we perform fraud proof in sidechains in index Merkle trees and distributed computing. In Sect. 3 we discuss how problems P1, P2, P3, and P4 are solved according to the proposed InfiniteChain technology. The implementation details and experimental results are presented in Sect. 4 and conclusions are drawn in Sect. 5.

2 A Multi-chain Architecture

The architecture of the proposed multi-chain blockchain is shown in Fig. 2. A multi-chain is a joint operating model consisting of the main blockchain and several sidechains. Generally speaking, transactions that do not need to be processed quickly, such as cryptocurrency transactions or individual contract records, are first sent directly into the P2P network and then linked to the main chain by nodes that have become block producers.

Fig. 2.
figure 2

The multi-chain architecture

Full size image

High-volume transactions, or those that require centralized matchmaking, however, are first processed on a sidechain. A hash value for the transactions is then generated and sent to a node in the P2P network and linked to the main chain. The sidechain runs at a high speed and accumulates a large number of transactions after a certain amount of time. The auditing node responsible for the decentralized operation of the sidechain then generates a hash value and corresponding identification code, which is then sent to the main chain.

The maintenance and operation of the main chain is the same as the operation and management of ordinary public blockchains. Sidechain operations are initiated by industry applications (e.g., transaction agent platforms, professional brokers, investment banks, securities companies, auditors, appraisers, lawyers, toolkit developers). For market and business development, different sidechains are managed and operated for individual business types. Sidechains must regularly synchronize their information with the main chain to avoid counterfeiting or tampering of data.

2.1 Existing Sidechain Technologies

There are several techniques for running transactions outside of the main chain before adding them to the main chain. After explaining each of these techniques, we will look at how InfiniteChain’s sidechains are different. The first technique uses “relay-based” sidechains. Assets are transferred between the main chain and sidechain before the transaction is conducted on the sidechain [4, 5]. The assets are transferred back to the main chain after a certain time. This reduces the number of transactions that take place on the main blockchain. Implementations of this system include BTC-Relay [6] and Rootstock [7]. The problem of the relay-based technique is implementing a 2-way peg protocol. For example, the blockchain of Bitcoin is impossible to establish such a relayer.

Another type is “channel-based” and usually referred to as “off-chain.” Lightning-network [8] and Raiden [9], for example, use off-chain transactions to increase their TPS. In this method, there is no need to use nodes to obtain consensus about transactions produced in sidechains. A payment channel is created in advance on the main chain and all the participants in the transactions made over this channel exchange electronically signed information outside of the main chain to indicate that transactions have taken place. A summary of these transactions are then written back to the main chain. Both of the above methods only offer a solution for high-frequency transfer of cryptocurrency or tokens and cannot be applied directly to contract records and other non-cryptocurrency transactions. In addition, this approach requires a prepayment in the channel and the Internet connection in real time to avoid receiving transactions from others, conditions that can be difficult to apply.

InfiniteChain uses an agent type (Proxy-Based) system for its sidechains. In this type of scenario, the user will commission a platform or agent to assist them in chaining the transaction and submitting non-defective modifications into the consensus system. Thus, the effectiveness of the application is achieved by the underlying data structure. An unlimited number of lower sidechains can be generated at any time when needed, making InfiniteChain suitable for solving the problems of real-world scenarios interfacing with the blockchain. In InfiniteChain we employ index Merkle trees and invent a scheme called distributed auditing to have the main chain’s block producers perform fraud proofs for sidechain transactions.

2.2 Sidechain Fraud Proof Performed by Nodes of Main Chain

In the multi-chain operation of InfiniteChain, the main chain is a public blockchain and so can obtain global consensus. It effectively validates the operating of agents which manifest the transactions in sidechains. Our idea is for block producers to perform fraud proof of transactions in sidechains. The multi-chain architecture of InfiniteChain can therefore solve all of the problems outlined in Sect. 1.

For fraud proof of transactions in sidechains, we propose a process of distributed auditing which is based on our index Merkle tree data structure.

Index Merkle Tree

The transactions conducted in a sidechain of InfiniteChain are stored in an index Merkle tree, which is not only a binary tree but also a hash tree. A Merkle tree is a tree of hashes in which the leaves are hash values and the top of the tree is occupied by a root hash. A root hash, which represents a fingerprint of transactions stored in the corresponding Merkle tree, and a slice of Merkle tree are sufficient to prove the existence of a transaction in a Merkle tree. The hash value of a transaction is stored in one of the leaf nodes in the Merkle tree. Further up the tree, an internal node stores a hash value that is the hash of the concatenation of all the hash values of its child nodes.

Figure 3 shows a Merkle tree with a height of four and eight leaf nodes and Fig. 4 shows a slice of a Merkle tree that is nine nodes high. If we would like to prove a transaction does not exist in a Merkle tree, we have to scan all the transactions in a Merkle tree. A Merkle tree is therefore not sufficient in the fraud proof of a sidechain, because block producers can only execute functions in contract with small-sized parametersFootnote 4. We will employ the index Merkle tree proposed in [10]Footnote 5 as a data structure to store transactions in a sidechain.

Fig. 3.
figure 3

A binary Merkle tree with a height of four

Full size image
Fig. 4.
figure 4

A slice of an FBHTree that is nine nodes high

Full size image

The hash value of a transaction is stored in one of the leaf nodes of the index Merkle tree according to the index function \( \Gamma \). If a Merkle tree is a full binary tree, it has 2N−1 leaf nodes if its height is N. The index function \( \Gamma \) returns the ID of a leaf node. In this paper, we propose the index function \( \Gamma \) to be:

\( \Gamma \)(Transaction ID) = SHA–256Footnote 6 (Transaction ID) mod 2N−1

That is, \( \Gamma \) returns 0 to 2N−1 if the height of the index Merkle tree is N. Hash values of different transactions may be stored in the same leaf node due to a collision of the \( \Gamma \) function. In addition to proof of existence of a transaction in an index Merkle tree, proof of inexistence can also be easily applied with a small-sized cryptographic proof. Given a transaction with an ID of t and root hash R of an index Merkle tree, if \( \Gamma \left( t \right) = x \), then we obtain the slice of the node whose ID is x and check if t exists according to this slice, because the protocol of operating an index Merkle tree has each transaction stored in a fixed slice. For the details of the index Merkle tree, refer to [10]. With index Merkle trees, we invent a form of distributed auditing that can do fraud proof for transactions in sidechains.

Distributed Auditing

The operation of a single sidechain is divided into multiple stages. Each stage contains the execution and auditing of some transactions. There is a corresponding contact of the sidechain in the main chain that keeps necessary information and functions for the sidechain’s operation. An index Merkle tree will be generated in each stage. That agent is responsible for keeping and maintaining it. Its root hash will be put into the contact. Refer to Fig. 5 for steps involved in a stage.

Fig. 5.
figure 5

A sidechain with distributed auditing

Full size image
Step (1)::

The agent responsible for initiating a stage starts by conducting a series of transactions with participants (or consumers).

Step (2)::

After a certain period of time, the agent sends processed transactions ∑ from Step (1) to the audit node.

Step (3)::

The audit node uses transactions ∑ to generate an indexed Merkle tree (IMT). The IMT is also used to generate a root hash value R. R and the corresponding identification tag, such as its stage number, are sent to its contact in the main chain for storing. All participants can use the identification tag from the contact in the main chain to obtain R.

Step (4)::

Participants are responsible for auditing their own transactions to see if they were correctly placed in the IMT:

  • The given root hash value R is used to ask the auditing node to return the corresponding slices of the participant’s own transactions, with each slice representing one such transaction. Since R is anchored to the main chain, an audit of the slice that does not turn up a particular transaction is cryptographic proof that the agent did not put their own transaction into the IMT.

Step (5)::

If the participant’s audit finds that the agent provided missing or incorrect data, the associated information is signed and then sent to a node for arbitration by block producers by calling an arbitration function in the contact. If arbitration finds that the agent made an error, then the participant receives a share of the bond which was previously stored in the contact.

Step (6)::

The agent pays royalties to the rights-holder. A rights-holder can use R and the IMT to verify that a royalty paymentFootnote 7 is free from error.

The integrity of transactions generated by sidechain operations is maintained by all participants. Participants and the agent both electronically sign their transaction information to realize mutual non-repudiation. In Step (4), multiple participants are involved in auditing the existence and integrity of transactions on the sidechain. Any omissions or errors found in an agent’s transactions are arbitrated by nodes on the main chain by calling a function in the contact. If arbitration is passed, then the bond is automatically shared among the participants who issued the arbitration; if not, it is refunded to the agentFootnote 8. This boosts the incentive for participants to take part in an audit.

3 Why Are Problems P1, P2, P3, and P4 Solved?

An InfiniteChain will contain many sidechains. Transactions are conducted in different sidechains. A single transaction agent is usually responsible for all transactions from a matchmaking service. Transactions processed by a sidechain agent do not need to be immediately placed on the blockchain. The hash value for a ledger containing N transactions is eventually placed on the blockchain: the equivalent of placing N transactions on the blockchain all at once. In practice, placing the hash value of a transaction ledger on the blockchain only takes up the bandwidth of a single transaction. In this manner, the transaction bandwidth of the blockchain can therefore be expanded almost indefinitely. The number of transactions per second is no longer constrained by the limitations of the main chain. Not having a limit of transactions per second means that fast speeds can be attained.

Since public blockchains can currently handle dozens of transactions per second, the speed of an InfiniteChain blockchain can now be easily increased to tens of millions of transactions per second, as shown in the following formula:

$$ \begin{aligned} {\text{Transactions}}\;{\text{per}}\;{\text{second}} & = ({\text{Average}}\;{\text{number}}\;{\text{of}}\;{\text{blocks}}\;{\text{generated}}\;{\text{per}}\;{\text{second}}) \\ & \quad \times \,({\text{Average}}\;{\text{number}}\;{\text{of}}\;{\text{transactions}}\;{\text{per}}\;{\text{block}}) \\ & \quad \times \,({\text{Average}}\;{\text{number}}\;{\text{of}}\;{\text{transactions}}\;{\text{per}}\;{\text{InfiniteChain}}\;{\text{ledger}}) \\ \end{aligned} $$

If we set the main chain’s transactions per second to 10, then the entire blockchain’s transactions per second =10 × 1,000,000 = 10,000,000 TPS. We can therefore achieve 10 million TPS with ease. This technique elevates the practicality of the blockchain to a whole new level. Problem P1 has now been solved.

InfiniteChain’s approach is to let the agent conduct transactions. We refer to this as a sidechain operation. After a certain amount of time, the root hash of this sidechain is placed on the main chain. Since the transaction ledger formed by the sidechain does not need to be stored on the main chain, Problem P2, namely information bloat, does not exist on the main chain, nor does InfiniteChain’s fix for Problem P1 create Problem P2. The details of all sidechain transactions are in the safekeeping of the responsible agent. Since its root hash and identification tag have already been placed on the main chain, they cannot be altered by the agent.

During sidechain operations, all transactions are stored securely in index Merkle trees. Transaction details are also encrypted with the public keys of the participant and digital asset provider. Only the participant and digital asset provider can use their private keys to validate their own transactions. The privacies of the participant and digital asset provider are therefore protected. Problem P3 has now been solved.

Since only hash values of index Merkle trees are published, participants and digital asset providers can use the index function to immediately pinpoint the leaf node for a particular transaction in the index Merkle tree. When a participant wishes to audit their own transaction and see if it was correctly stored in the transaction ledger, the participant can submit a transaction audit request to the agent. As the participant already has the transaction serial number (the completed transaction is electronically signed by the agent and so cannot be repudiated by the agent), the agent must then present the slice for the transaction. The participants can then use the root hash of the ledger and the slice for the transaction to verify the integrity of the transaction and whether it exists in the transaction ledger. Problem P4 has now been solved.

4 Experimental Results

We have performed a series of experiments to demonstrate the feasibility of the proposed architecture. We installed a cloud server as our auditing node: a virtual machine of AWS EC2 r4.xlarge with 4 CPUs. The operating system was Ubuntu 16.04. Node.js 8.6.0 was employed to implement the auditing node. We divided the experiments into three major parts, including measuring the time required to generate an index Merkle tree, the time required to extract slices from an index Merkle tree, and the required gas consumed in the function execution of smart contract in the Ethereum blockchain.

The time and its standard deviation required to generate an index Merkle tree is shown in Table 1. For an index Merkle tree which contains less than 10,000 transactions, we only require about 4.6 s for generation.

Table 1. The time required to generate an index Merkle tree
Full size table

Table 2 lists the time required to extract slices from index Merkle trees, which is the operation of Step (4) in Fig. 5. We store different numbers of transactions with different heights. We only needed less than one millisecond to extract a slice even when an index Merkle tree contained one million transactions.

Table 2. The time required to extract slices from index Merkle trees
Full size table

In the third part of our experiment, we implemented the InfiniteChain in the public blockchain, Ethereum. Ethereum provides a decentralized Turing-complete virtual machine, the Ethereum Virtual Machine (EVM), which can execute scripts using an international network of public nodes. Gas is the internal pricing for running a transaction or contract in Ethereum. Using more computation and storage in Ethereum means that more gas is used (See the yellow paper for a breakdown of operations and respective gas costs [11]). One fundamental reason for metering is that it provides an incentive for miners to operate the contract code [12].

Since computation with global consensus is expensive, transactions have a gas limit field to specify the maximum amount of gas which the sender is willing to buy. If the gas used exceeds this limit during execution, processing is stopped, which protects full nodes from attackers who could make them execute infinity loops without a gas limit. If a transaction would take longer than a block to process, then it would not be included in the block.

A block also has a field called gas limit. It defines the maximum amount of gas all transactions in the whole block combined are allowed to consume. Its purpose is to keep block propagation and processing time low, thereby allowing for a sufficiently decentralized network [13]. Consensus protocol allows the miner of a block to adjust the block gas limit by a factor of 1/1024 (0.0976%) in either direction [14, 15]. Currently, the gas limit is around eight million. Refer to Table 3. In our experiment, the highest gas is 3.7 million, in which the height of the index Merkle tree is 20, for storing one million transactions, with 9 transactions in the leaf node. According to our previous experiments about index Merkle tree, the maximum number of transactions in a leaf node is 8 [10]. The size of cryptographic proof and required gas are therefore small enough to be performed as a function in Ethereum smart contract.

Table 3. Gas consumption in Ethereum blockchain platform. α: Height of the index Merkle tree, β: Number of transactions in the leaf nodes
Full size table

5 Conclusion

Decentralized application systems based on blockchain technologies are just now beginning to enter our everyday lives. However, experts have pointed out some bottlenecks in the basic technology. As noted in Sect. 1, these are Problem P1 (insufficient bandwidth), Problem P2 (blockchain bloat), Problem P3 (difficulty protecting privacy), and Problem P4 (difficulty integrating with centralized scenarios). If any one of these problems remains unsolved, then the dream of blockchains becoming trust machines will be just that, a dream. The blockchain will be limited to a platform for mining and trading cryptocurrency, or will only be used in a limited number of application scenarios.

In this paper we propose a multi-chain architecture which employs distributed auditing to perform fraud proof in the sidechain. An efficient and effective fraud proof solves problems P1, P2, P3, and P4. Experimental results shown in Sect. 4 demonstrate that the index Merkle tree is able to an appropriate data structure for supporting fraud proof. The cryptographic proof generated from an index Merkle tree is small enough to be validated in a contract of public blockchains.

In future work, we are extending distributed auditing to implement a real-time and low-cost cash flow sidechain. A contract published to the main chain is used to control the cash flow exchange of participants in the sidechain. General cash flow does not need to pass through the main chain, which speeds up the main chain. An agent is responsible for accepting and processing the remittance, deposit, and withdrawal requests from participants. The index Merkle tree is still the basis for the agent’s generation of cryptographic proofs for fraud proofs.