Cross-chain between a Parent Chain and Multiple Side Chains

Guangsheng Yu¹, Xu Wang², Ren Ping Liu²
¹Data61 CSIRO, Sydney, Australia
²Global Big Data Technologies Centre, University of Technology Sydney, Australia

Abstract

In certain Blockchain systems, multiple Blockchains are required to operate cooperatively for security, performance, and capacity considerations. This invention defines a cross-chain mechanism where a main Blockchain issues the tokens, which can then be transferred and used in multiple side Blockchains to drive their operations. A set of witnesses are created to securely manage the token exchange across the main chain and multiple side chains. The system decouples the consensus algorithms between the main chain and side chains. We also discuss the coexistence of the main tokens and the native tokens in the side chains.

Keywords— blockchain, cross-chain, Internet-of-Things

1 Introduction

Blockchain, featured with its decentralized tamper-resistance, has been an active research topic to address the security issue of centralization, and has been widely adopted in many scenarios such as Internet-of-Things (IoT) [1, 2, 3, 4, 5, 6] in order to achieve distributed trust [7]. A public Blockchain, often referred to as Token Chain, can accomplish a decentralized tokenomics. Since Token Chains are usually public, they require decentralized consensus algorithms, such as Proof-of-X (PoX) [8, 9]. Additionally, blockchain governance plays a crucial role in the effective management and operation of decentralized systems, guiding the decision-making processes within the network [10, 11, 12, 13]. However, a decentralized consensus algorithm entails the comparatively low performance and efficiency, implying that those delay-sensitive applications or applications with massive deployment and data, such as IoT applications, cannot operate on Token Chains properly. For such applications, consortium chains are proposed with partially decentralized and more efficient consensus algorithms, such as Byzantine Faulty Tolerance (BFT) [14]. It is important to note that blockchain scalability solutions such as sharding, which operates at layer-1, differ from cross-chain techniques, a layer-2 solution. While sharding divides the network into smaller parts to increase throughput, cross-chain solutions enable communication between different blockchains, providing additional flexibility and scalability [15, 16, 17]. However, Side Chains have no economic value, which prevents the trading of IoT data.

We propose a cross-chain architecture consisting of a public Token Chain and multiple associated consortium Side Chains. In the cross-chain system, the Token Chain issues the main tokens and maintains the official token ledger for the cryptocurrency ecosystem, while a number of Side Chains import the tokens from the Token Chain for the management of the massive records and transactions for applications, such as IoT. The key challenge is the design of cross-chain interactions, including token exchange between the Token Chain and its associated Side Chains. A set of nodes are defined as Witnesses in the genesis block of each Side Chain. These Witnesses are responsible for the exchange of tokens between the Token Chain and the Side Chains.
The cross-chain system provides the flexibility to meet various capacity demands of heterogeneous applications, including but not limited to IoT applications. It achieves modularity in that the Side Chains are decoupled from the Token Chain through the design of Witnesses. This system is not limited to Ethereum platform, and has no limitations on the number of IoT Chains. ¹¹1The theoretical maximum number of IoT chains is $16^{40}\approx 1.46\times 10^{48}$ based on the 20-byte address. It is a quite large number to exceed in practice.

2 Related Works

There exist several cross-chain technologies, mainly classified into Relay, Hash-Lock and Notaries.

•
Relay: Chain $A$ can prove the facts and behaviors on Chain $B$ . Technologies using Relay are including but not limited to, the following solutions:
- –
  
  BTC-Relay [18]. It is a technology that can inter-operate between Bitcoin and Ethereum. A light client that introduces Simple Payment Verfication (SPV) is implemented by a smart contract in Ethereum so that facts on Bitcoin can be proved in Ethereum. However, it also implies that Ethereum needs to store all headers of Bitcoin, which is quite expensive.
- –
  
  Non-Interactive Proof of PoW [19]. Combined with Monte Carlo method and Bisection method, this proof tries to calculate the probability that a chosen puzzle with a high difficulty falls into a specific interval. As such the PoW on Chain $B$ can be proved by including this proof of PoW on Chain $A$ . However, currently this method is not general and strictly dependent from PoW consensus.
•

Hash-Lock [18]. It acts as a personal trading platform. Fair and secure assets exchange can be accomplished with the aid of a time-out mechanism. However, it does not support assets portability and it is unfriendly to the interoperation between a public chain and a consortium chain because of the possible different token-scheme on this consortium chain.
•
Notaries [20]. It is also known as Witnesses. Our invention belongs to this type. In words, there exist some nodes which run clients on both Chain $A$ and $B$ . Messages (Assets) exchanged is conducted through these nodes with a necessary consensus process. Notaries is the most frequently used technology so far. There are a number of Blockchain projects announcing their schemes, including but not limited to,
- –
  
  Hcash. It is a typical design of Notaries-liked cross-chain technology. It collectively features most of the advantages of Notaries from other similar projects. We believe that comparing our invention with Hcash will be sufficiently significant to differential our invention with other similar designs. In our opinion, notaries act as a set of nodes running on both chains, as if multiple personal trading platforms exist with a necessary consensus process. The On/Off-chain multi-signature wallet takes critical responsibilities when assets exchanging. However, this design does require users to have assets prior to the process of exchanging, which implies that similar to Hash-Lock, it does not support consortium chain very well either. Hcash does not provide the solutions to address the implications of the native gas-oriented account-balance on the consortium chain, and to generate exchangeable token for a consortium chain with the native gas-oriented account-balance.
- –
  
  Walton Chain. Notaries are a set of nodes only running on the local chain. The request of generating a new side chain is executed by a smart contract by sending a transaction. In other words, notaries are the bridge to exchange the messages of the most external layer to the internal layer with a necessary consensus process. It implies that a side chain is only an abstractive structure in Walton Chain. Link structure is maintained on smart contracts in which the data storage is simplified as the state-oriented data to be stored in the local database. Such a design is not only strongly restricted by the throughput of the most external chain but also extremely increases the loading of the entire network.

There appears an existing national patent (CN 106447309 A) in China that is similar to our invention. Their patent implements the third-party chain that pegs to both the main chain and the side chain with a certain address on each chain as if an accessible API connects the main chain and the side chain. It implies that these APIs have an offline information relaying between the certain address on either the main chain or the side chain, and its third-party chain, which they did not precisely point out. In addition, the existence of the third-party chain exposes the issue of data privacy. It also makes no sense that the third-party is eligible to maintain multiple side chains due to the data privacy, centralization and scalability. Therefore, we can conclude that our invention is more general and outplays their patent.

Our invention is targeting at such a case that multiple IoT Chains with different consensus algorithms, a high throughput and a high volume are anchored with a Token Chain. Therein each IoT Chain has its own business groups charged with the audition of cross-chain process. One IoT Chain can be totally a black-box for the others. Likewise, any behaviors on an IoT Chain can be also a black-box for the Token Chain apart from the amount of token exchanged. Either an IoT Chain without the native gas or an IoT Chain withe the native gas can be registered to the Token Chain whenever a user requires token involved and afterwards provides the sufficient assets and proofs on the Token Chain. In words, we believe that our invention can be a better solution to the separation between the financial-layer and data-layer in order for a more data-friendly and healthy Blockchain system.

3 Brief Description of the Drawings

The description of each step and module are shown in the following drawings.

1.

Figure 1 shows the flow diagram for the entire architecture of our invention. It combines the rest of the Figures into a whole to elaborate the entire flow of the procedure.
2.

Figure 2 shows the flow diagram for the pre-defined parameters required to be setup prior to the registration to Token Chain for an IoT Chain without the native gas.
3.

Figure 3 shows the flow diagram for the first time registration to Token Chain for an IoT Chain without the native gas from the perspective of Token Chain.
4.

Figure 4 shows the flow diagram for the first time registration to Token Chain for an IoT Chain without the native gas from the perspective of IoT Chain.
5.

Figure 5 shows the flow diagram for transferring consumable token from IoT Chain back to Token Chain from the perspective of IoT Chain.
6.

Figure 6 shows the flow diagram for transferring consumable token from IoT Chain back to Token Chain from the perspective of Token Chain.
7.

Figure 7 shows the flow diagram for subsequently transferring from Token Chain to IoT Chain that has been registered from the perspective of Token Chain.
8.

Figure 8 shows the flow diagram for subsequently transferring from Token Chain to IoT Chain that has been registered from the perspective of IoT Chain.
9.

Figure 9 shows the flow diagram for transferring between Token Chain and an IoT Chain with the native gas.

4 Brief Description of the Smart Contracts and Witnesses

•

SC_A: A dedicated cross-chain smart contract for an IoT Chain {A}, deployed on Token Chain. It locks/unlocks the assets transferred. It introduces the consensus for the Validation of registration from witnesses, as well as the consensus for the assets transferred back to Token Chain.
•

SC_ID: It is deployed on Token Chain. A Token Chain can only have one SC_ID and it offers 2-of-2 Mulsig (Note that it can be a n-of-m Mulsig that has been claimed in the last section. For the rest of place using Mulsig, 2-of-2 is implemented in order for the simple elaboration). It records the $Chain\_ID$ of IoT Chains that have been successfully registered. It $Updates$ the list of $Chain\_ID$ once the consensus for the Validation of registration from witnesses gets passed and emits an event of $ExistOrNot$ .
•

SC_Register: A unique dedicated cross-chain smart contract for the first time registration, deployed on an IoT Chain. It introduces the consensus for the $entrancefee$ transferred to the IoT Chain. Its balance is hardcoded and will be run out after the success of registration and commits suicide afterwards by the agreement of Mulsig.
•

SC_Inter: A unique dedicated cross-chain smart contract for the assets transferring back to Token Chain as well as the subsequent assets transferred to IoT Chain with a consensus process, deployed on IoT Chain. It dedicates the assets unlocking to SC_Bank after the success of consensus. It forwards the assets transferred from users’ accounts to SC_Bank for assets locking in the case of IoT-Chain-to-Token-Chain.
•

SC_Bank: A unique dedicated cross-chain smart contract for assets locking/unlocking, deployed on IoT Chain. The balance of SC_Bank that equals to the total amount of the upper bound of the potential assets trading on IoT Chain is hardcoded in the genesis block. The corresponding amount of token is unlocked and transferred to the destination address with the delegation from SC_Inter. It receives and locks the assets transferred from users’ accounts to SC_Bank for assets locking in the case of IoT-Chain-to-Token-Chain.
•

SC_Consensus: A unique dedicated cross-chain smart contract for both registration and consensus in the context of an IoT Chain with the native gas.
•

SC_Trading: A unique dedicated cross-chain smart contract that records the balance for all accounts that have ever been involved in a cross-chain transaction and dynamically maintains a ledger. Both intra-transactions and inter-transactions associated with real business must be manipulated via SC_Trading. In other words, the token value is generated and destroyed with SC_Trading running on an IoT Chain with the native gas. The amount of consumable assets is precisely defined even though its native account-balance tends to be infinite.
•
Witnesses: A set of nodes that bridge the information exchanged between Token Chain and a specific IoT Chain. Information exchanged needs to be verified by the consensus on both Token Chain and the IoT Chain. Witnesses retrieve events from:
1. 1.
  
  SC_ID: if the $Chain\_ID$ has been appended in the list;
2. 2.
  
  SC_A: if some numbers of cross-chain transactions have arrived;
3. 3.
  
  SC_Bank: if the assets has been successfully locked in the context of IoT-Chain-to-Token-Chain;
4. 4.
  
  SC_Consensus: if some numbers of cross-chain transactions have arrived.

5 Detailed Description

A set of pre-defined Witnesses exchange the cross chain messages as if a bridge connects Token Chain and an IoT Chain. Remark that multiple IoT Chains can be implemented along with their own pre-defined Witnesses. All IoT Chains are pegged to Token Chain, which provides an individual channel for each IoT Chain to exchange token. IoT Chains do not interact with each other directly.

In addition, businesses tend to customized their own IoT Chains regardless of a specific type of consensus algorithm or even the existence of native gas, i.e. either of an IoT Chain with native gas or an IoT Chain without native gas. Note that the native gas refers to the native gas-oriented account-balance. Also note that the native gas-oriented account-balance is firstly implemented in Ethereum platform. It is often used to restrict the malicious transactions flooding among the network. The difference between them is shown as follows,

•

IoT Chain without the native gas: an IoT Chain has no native gas-oriented account-balance. Nodes on such an IoT Chain cannot send transactions without the imported gas transferred from the corresponding Token Chain, where the imported gas, in fact, is consuming the main tokens. In other words, the main tokens are responsible for both sending a transaction and dealing with a business issue.
•

IoT Chain with the native gas: an IoT Chain has the native gas-oriented account-balance. Nodes on such an IoT Chain can send transactions (uploading the IoT messages) without the imported gas transferred from the corresponding Token Chain. However, any transactions associated with the business issue must come along with the imported gas.

IoT Chains are free to be customized with low restrictions in terms of the consensus algorithm and the existence of native gas. All tokens on IoT Chains are originated from Token Chain, referring to the main tokens. In other words, IoT Chains have no original token value regardless of the presence of the native gas. Note that IoT Chain is allowed to have its own account-balance mechanism to maintain the whole system running fluently with a necessary access control and a flow control. This account-balance is meant to be a sufficiently large amount of value that can be automatically recharged by administrators, which implies that only the token originated from Token Chain that is strictly differentiated from the native account-balance on IoT Chains, has the real economical value. Thus users can choose to either registering an IoT Chain without the native gas in which only the token originated from Token Chain dominates the system, or an IoT Chain with the native gas in which its own account-balance mechanism is in charge of its self-driven processing, which are both independent to the consensus algorithm.

For the rest of this section we extend the description to a deeper extent shown as follows,

•
Section 5.1 refers to Figure 2, 3, 4, 5, 6, 7 and 8.
- –
  
  Section 5.1.1 refers to Figure 2.
- –
  
  Section 5.1.2 refers to Figure 3 and 4.
- –
  
  Section 5.1.3 refers to Figure 7 and 8.
- –
  
  Section 5.1.4 refers to Figure 5 and 6.
•

Section 5.2 refers to Figure 9;
•

Section 5.3 describes the mechanism of the reverting and resending process of our invention when the consensus fails.

Note that the entire flow chart refers to Figure 1.

5.1 Bridging a Side Blockchain without the native gas

Bridging a side Blockchain without the native gas includes the following steps,

1.

pre-definition of necessary parameters;
2.

registration of the chain;
3.
subsequent assets transferring:
- •
  
  transferring from IoT Chain back to Token Chain;
- •
  
  transferring from Token Chain to IoT Chain after the registration.

5.1.1 Pre-definition

A set of Witnesses run as intermediaries to bridge Token Chain and an specific IoT Chain. These Witnesses have valid accounts on both Token Chain and the IoT Chain. The interactions between Token Chain and the IoT Chain are secured by Blockchain. Only interactions verified and recorded in the form of transactions are accepted and performed on both sides. Smart contracts implement the interactions between Token Chain and the IoT Chain.

The genesis block of the IoT Chain has a pre-defined form. The genesis block defines the account states and the interaction parameters of the IoT Chain. In the genesis block, all accounts on the IoT chains have no balance when the IoT Chain initializes, except that two pre-defined smart contracts created by the creator of the IoT Chain stating the balance of these smart contracts and promises to lock some fee (shown below) from these addresses, respectively. Each of them is verified by the signature of its own key.

1.

the first kind of fee is assigned as the entrance fee that is the minimum amount of token required to initialize an interactive IoT Chain for the registration phase. Note that the entrance fee should be minimum-bounded to prevent from maliciously frequent registration requests;
2.

the second kind of fee is assigned as the reserved assets from which the subsequent assets can be unlocked.

The IoT Chain predefines $N$ Witnesses in the genesis block of the IoT Chain. These $N$ Witnesses should have valid accounts on Token Chain. In other words, a valid genesis block of an interactive IoT Chain without the native gas has the following fields:

•

$Chain\_ID$ : The Chain ID of the IoT Chain;
•

$SC\_Register$ : An interactive smart contract on the IoT Chain which enables transfer function between the IoT Chain and Token Chain.
•

$Bal\_Resv$ : The amount of token that the creator reserves in $SC\_Register$ for the IoT Chain;
•

$SC\_Inter$ : A smart contract on the IoT Chain, used for subsequent transferring from Token Chain to the IoT Chain and transferring from the IoT Chain back to Token Chain;
•

$SC\_Bank$ : A smart contract on the IoT Chain which enables the subsequent token locking and unlocking. There is a strict access control upon this smart contract, i.e. the only address who can interact with $SC\_Bank$ is the address of $SC\_Inter$ .
•

$Bal\_Bank$ : The amount of token that the creator reserves in $SC\_Bank$ for the IoT Chain; Note that $Bal\_Resv+Bal\_Bank\equiv$ total amount of token on Token Chain including those unmined token;
•

$Wit\_Addr\_List$ : The addresses of Witnesses for the IoT Chain, which is hardcoded in both $SC\_Register$ and $SC\_Inter$ .

The creator creates and broadcasts the genesis block in the IoT network and await the other nodes being launched and ready for the the new IoT Chain within an expected period. Note that any transactions with a source address of one of the Witnesses and a destination address of SC_Register or SC_Inter can pay a zero gasprice. Meanwhile, any transactions with a source address of either SC_Register, SC_Inter or SC_Bank can also pay a zero gasprice.

5.1.2 Registration

After all Witnesses have been ready (All Witnesses should then be able to send transactions to and retrieving events from any targeted addresses. Meanwhile, they all are able to fetch the json files of both of the genesis blocks of the IoT Chain and Token Chain), the creator on Token Chain sends a request of registration in the form of a transaction to SC_A, where the following contents are included in the invoked event,

•

all token that is contained in this transaction sent to SC_A subtracting the compensation fee for both SC_A and Witnesses providing the transferring service. It guarantees that SC_A and Witnesses have sufficient fund to send transactions on Token Chain;
•

$Chain\_ID$ of the IoT Chain that the creator proposes.

Note that SC_A is a smart contract deployed on Token Chain with no balance initially, which is a dedicated cross-chain service relay and created by the service provider in the form of open source. As such the process of validation on Witnesses gets called by retrieving the events invoked by this requesting transaction. It validates the genesis block according to Alg. 1 from which the output is sent to SC_A. In other words, once a Witness validates the genesis block, it accepts the registration request of the new IoT Chain and sends a “Confirm” transaction to the smart contract, SC_A, on Token Chain. When SC_A receives “Confirm” transactions from more than $N/2$ Witnesses (Note that for any smart contracts on which a consensus process is being conducted, a parameter $round$ must be used to prevent from out-of-order message. The minimum faulty tolerance is $N/2$ ), the smart contract SC_A reserves $Bal\_Resv$ on Token Chain from the account of the creator, triggers the smart contract SC_ID to register the IoT Chain with its $Chain\_ID$ . Note that Alg. 1 has ensured that the $Chain\_ID$ for each chain is unique in the entire system. A signal indicating whether the registration has succeeded or not is contained in the event invoked by $Chain\_ID$ that Witnesses are listening to. If and only if a “True” is received, a Witness sends a “Transferring” transaction to the smart contract $SC\_Register$ on the IoT Chain. If $SC\_Register$ receives “Transferring” transaction from more than $N/2$ Witnesses, the same amount (this amount should now exactly equal to the total balance of $SC\_Register$ , ensuring that the balance of $SC\_Register$ will be zero after unlocking) of token are unlocked from $SC\_Register$ on IoT Chain.

$SC\_Register$ commits suicide by the owners after the owners both (2-of-2 Mulsigs) have retrieved the event of success of adding the $Chain\_ID$ in $SC\_ID$ .

After the IoT Chain is created and registered, the IoT Chain will be able to work properly and generate blocks based on its consensus protocol. Note that there is no block rewards on the IoT Chain.

5.1.3 Token Chain to IoT Chain after Registration

$SC\_Inter$ is responsible for any subsequent “Transferring” transactions sent from Token Chain to a specific IoT Chain, plus those sent from the IoT Chain back to Token Chain. If a subsequent “Transferring” transaction sent to $SC\_Inter$ is detected, $SC\_Inter$ delegates the burden to $SC\_Bank$ along with $to$ and $value$ of each cross-chain transaction after the success of $N/2$ consensus. This process succeeds if and only if it passes the validation that the current balance of $SC\_Bank$ + the entrance fee + the amount of token that is requested for this specific “Transferring” transaction $\equiv$ total amount of token on Token Chain including those unmined token. The owners of $SC\_Bank$ add the address of $SC\_Inter$ in $SC\_Bank$ and the corresponding amount of token can be unlocked if and only if both owners agree. Note that it is none of business of $SC\_ID$ for a subsequent cross-chain transferring. Witnesses do not listen to the events invoked by $SC\_ID$ . Instead, events of $SC\_A$ are listened.

5.1.4 IoT Chain to Token Chain after Registration

Suppose the aforementioned IoT Chain is still discussed, there are two types of transactions on the IoT Chain: one records the IoT events and does not interact with Token Chain; the other one records the interactions with Token Chain. Any transaction that is associated with $SC\_Inter$ belongs to Interaction transactions. Suppose that a user on the IoT Chain sends a request of transferring token back to Token Chain in the form of a transaction sent to $SC\_Inter$ with an arbitrary amount of token $\leq$ (total amount of token on the Token Chain including those unmined token $-$ the balance of $SC\_Bank$ ). $SC\_Inter$ then becomes the relay and transfers the token to $SC\_Bank$ for the further locking. Each of the Witnesses retrieves the events and sends a “Transferring” transaction to $SC\_A$ on Token Chain. If $SC\_A$ receives a “Transferring” transaction from more than $N/2$ Witnesses, the same amount (this amount should $\leq$ the balance of $SC\_A$ ) of token is unlocked from $SC\_A$ on Token Chain.

Input:

Hash(Genesis)

: the hash of the IoT genesis block.

Balance_{request}

: the total balance that the creator reserves for the IoT chain.

Balance_{json}

: the total balance that the json file of the IoT chain is showing.

ChainID_{request}

: the chain ID that the creator proposes for the IoT chain.

ChainID_{json}

: the chain ID that the json file of the IoT chain is showing.

ChainID_{token}

: the chain ID of the token chain.

SmartContract_{ChainID}

: a list of all chain IDs that have been successfully registered already.

Output: True or False

1The witnesses assert the following conditions:

2Confirm the integrity of the Genesis Block:

GetHash(Genesis)

Hash(Genesis)

;

4Confirm it is a request to generate a new IoT Chain:

GetHeight()

= 0;

6Verify the balance of the creator:

Balance_{request}

Balance_{json}

8Validate the Chain ID:

ChainID_{request}

ChainID_{json}

ChainID_{request}

\neq

ChainID_{token}

ChainID_{request}

\notin

SmartContract_{ChainID}

If ALL above conditions are satisfied, the output is “TRUE”, which indicates the witness validates the registration request; or else the output is “FALSE”, which indicates the witness refuses the registration request.

Algorithm 1 Verify the Request of Registering an IoT Chain

5.2 Bridging a Side Blockchain with the native gas

Comparing with bridging an IoT Chain without the native gas, there are only a few tiny changes to bridge an IoT Chain with the native gas, which is shown as follows,

1.

SC_Register and SC_Inter merge into one smart contract, SC_Consensus, since there is no need to transfer token itself. Instead, the only thing needs to do is to update the balance in SC_Trading. SC_Consensus has two hardcoded owners, offering 2-of-2 MultiSig;
2.

A set of Witnesses is still needed to be organized and written in SC_Consensus. Note that there is no need to predefine SC_Consensus in the genesis block as long as it provides sufficient native account-balance for self-driven processing. Also, there is no need to set an entrance fee in SC_Consensus;
3.

SC_Bank can be deprecated;
4.

It is still required to have a smart contract running on Token Chain, SC_A created by the service provider in the form of open source. However, the events fetched by Witnesses for the Validation only contain the information of how much is transferred and the Chain_ID. Accordingly, Witnesses only validate the Chain_ID part in Algorithm 1 regardless of the height and balance of the IoT Chain;
5.

As if a trading platform manipulate the financial trading, SC_Trading records the balance for all accounts that have ever been involved in an arbitrary cross-chain transaction and dynamically maintains a ledger based on the historical balance. Both intra-transactions and inter-transactions associated with real business must be manipulated via SC_Trading. In other words, the token value is generated and destroyed with SC_Trading running on an IoT Chain with the native gas. In the context of high throughput of the IoT Chain along with its native account-balance mechanism, it is believed that SC_Trading is able to handle the transactions in a high volume. Note that the following statement must be satisfied,

$\left(\sum_{i=0}^{N}Bal_{i}\right)_{ChainID}=Asset_{ChainID},$

where the total amount of token that is being locked in SC_A with a certain $Chain\_ID$ must equal to the sum of the balance of all accounts recorded in SC_Trading on an IoT Chain with the same $Chain\_ID$ . It has two hardcoded owners, offering 2-of-2 MultiSig.
6.
Either of SC_Consensus or SC_Trading can be pre-defined in the genesis block without having the owners and offering the Mulsig if the r IoT Chain with the native gas is at the height of zero when initializing. As such a valid genesis block of an IoT Chain with the native gas has the following fields:
- •
  
  $Chain\_ID$ : The Chain ID of the IoT Chain;
- •
  
  $SC\_Register$ : An interactive smart contract on the IoT Chain which enables transfer function between the IoT Chain and the Token Chain;
- •
  
  $SC\_Trading$ : An smart contract on the IoT Chain which records the balance for all accounts that have ever been involved in an arbitrary cross-chain transaction and dynamically maintains a ledger based on the historical balance;
- •
  
  $Wit\_Addr\_List$ : The addresses of Witnesses for the IoT Chain, which is hardcoded in both $SC\_Register$ and $SC\_Inter$ .

5.3 Process of Reverting and Resending

Note that there exist multiple solutions to the failure of consensus, such as $Revert$ or $Resend$ . In this documentation, we also provide our mechanism shown as follows.

•

Registration: if the consensus of $N/2$ on $SC\_A$ fails to be reached within a period of $t$ (can instead use block height $h$ ), the token is reverted to the account of the creator on Token Chain, with a certain amount of compensation fee paid to $SC\_A$ and Witnesses.
•

Transferring: suppose that $h_{l}$ denotes the height of the current latest block and $\omega$ denotes the unconfirmation window size (a public chain needs such a window size to determine the sufficiently high confidence interval of a block not being reverted by the chain-reorganization). If it is the first time of transferring, each of Witnesses waits until $h_{l}-2\omega+1\geq 0$ , and collects all events associated with the transactions whose destination address is $SC\_A$ , $SC\_Register$ or $SC\_Inter$ from block of $h_{l}-2\omega+1$ to $h_{l}-\omega$ , which is assigned as the data of a “Transferring” transaction for the following consensus. If the consensus of $N/2$ in $SC\_Register$ , $SC\_Inter$ or $SC\_A$ fails to be reached within a period of $t$ (can instead use block height $h$ ), each of Witnesses sleeps for $T$ (now we let $h_{l2}$ denotes the latest block) and afterwards starts to resend the blocks getting stuck with the height from $h_{l}-2\omega+1$ to $h_{l}-\omega$ (totally $\omega$ blocks). This process of resending is iterated until the consensus of $N/2$ is reached ( $h_{l2}$ updates per iteration). Note that a process of resending indicates that it is not the first time of transferring. In this case, each of Witnesses finds its $h_{l2}$ and checks whether $h_{l2}\geq h_{l}-\omega+2\omega$ . If not, each of Witnesses sleeps for $T$ and starts over. Otherwise, each of Witnesses collects the corresponding events from the blocks with height from $h_{l}-\omega+1$ to $h_{l}$ and sends the cross-chain message to $SC\_Register$ , $SC\_Inter$ or $SC\_A$ for the following consensus. Also note that each of Witnesses listens to the event invoked by the corresponding consensus of $N/2$ in order for the awareness of the result.

6 Claims

What is claimed is:

1.
A method for transferring assets from a parent chain to multiple side chains and backwards, the method comprising:
- •
  
  pre-defining, for a new side chain without the native gas, a set of parameters must be set prior to every other step in order for the later validation;
- •
  
  registering, via the Validation and Consensus by Witnesses, the information of the side chain gets recorded by an open smart contract on the parent chain;
- •
  
  first time sending, which represents the first time transferring from the parent chain to the side chain. A certain amount of token being locked in another open smart contract on the parent chain and the same amount of token is unlocked and released by an open smart contract on the side chain;
- •
  
  reversely sending, which represents the transferring from the side chain back to the parent chain. A certain amount of token is locked on the side chain, and the same amount of token is unlocked on the parent chain if the consensus is passes;
- •
  subsequent sending, which represents the subsequent transferring from the parent chain to the side chain. It differs from the first time transferring in that,
  - –
    
    Witnesses listen to the events from the smart contract that locks the assets but not the smart contract that records the Chain ID of side chains;
  - –
    
    the smart contract that releases and unlocks the assets on the side chain in the first time transferring now instead delegates this to an open smart contract that locks all the rest of the potential assets.
- •
  
  reverting and resending, by the consensus whose result Witnesses keeps listening to. Revert is implemented in the consensus of registration while Resend is implemented in the other consensuses;
- •
  
  trading, by an open smart contract on a new side chain with the native gas. All transactions associated with cross-chain require to be manipulated by this smart contract.
2.

The method of claim 1, wherein users can choose to either registering a side Blockchain without the native gas in which only the token originated from Token Chain dominates the system, or a side Blockchain with the native gas in which its own account-balance mechanism is in charge of its self-driven processing. A side Blockchain without the native gas must be at a height of zero when registering, while a side Blockchain without the native gas can be either a new one or an existing one.
3.

The method of claim 1, wherein the MulSig is not limited to 2-of-2, can be n-of-m instead.
4.

The method of claim 1, wherein the Mulsig of SC_Register is for suicide. The Mulsig of SC_Bank is for adding the address of SC_Inter and subsequent assets locking and unlocking.
5.

The method of claim 1, wherein either SC_Consensus or SC_Trading can be pre-defined in the genesis block instead of offering Mulsig if the side chain with the native gas is at the height of zero.
6.

The method of claim 1, wherein the native gas is not limited to Ethereum platform. All Ethereum-based platforms or other platforms that are self-driven by some kinds of native account-balance are also compatible.
7.

The method of claim 1, wherein the faulty tolerance of consensus can be set to any number greater than N/2.
8.

The method of claim 1, wherein the entrance fee is minimum-bounded to prevent from maliciously frequent registration requests.
9.

The method of claim 1, wherein the format of data by which Witnesses validate the validity of a new side chain is not limited to json file.
10.

The method of claim 1, wherein there is no need to pay fee for block generator for any cross-chain-related smart contracts and each of Witnesses sending a transaction with a destination address of a cross-chain-related smart contract.
11.

The method of claim 1, wherein the cross-chain-related smart contract initializes with no balance on the parent chain.
12.

The method of claim 1, wherein for any smart contracts on which a consensus process is being conducted, a parameter round is used to prevent from out-of-order messages.
13.

The method of claim 1, wherein there is no block rewards on the side chain.

References

[1] G. Yu, X. Zha, X. Wang, W. Ni, K. Yu, P. Yu, J. A. Zhang, R. P. Liu, and Y. J. Guo, “Enabling attribute revocation for fine-grained access control in blockchain-iot systems,” IEEE Transactions on Engineering Management, vol. 67, no. 4, pp. 1213–1230, 2020.
[2] X. Wang, G. Yu, X. Zha, W. Ni, R. P. Liu, Y. J. Guo, K. Zheng, and X. Niu, “Capacity of blockchain based internet-of-things: Testbed and analysis,” Internet of Things, vol. 8, p. 100109, 2019.
[3] G. Yu, L. Zhang, X. Wang, K. Yu, W. Ni, J. A. Zhang, and R. P. Liu, “A novel dual-blockchained structure for contract-theoretic lora-based information systems,” Information Processing & Management, vol. 58, no. 3, p. 102492, 2021.
[4] X. Wang, P. Yu, G. Yu, X. Zha, W. Ni, R. P. Liu, and Y. J. Guo, “A high-performance hybrid blockchain system for traceable iot applications,” in International Conference on Network and System Security. Springer, 2019, pp. 721–728.
[5] G. Yu, “Blockchain meets iot: What needs to be addressed,” Ph.D. dissertation, University of Technology Sydney, 2021.
[6] X. Wang, G. Yu, R. P. Liu, J. Zhang, Q. Wu, S. W. Su, Y. He, Z. Zhang, L. Yu, T. Liu et al., “Blockchain-enabled fish provenance and quality tracking system,” IEEE Internet of Things Journal, vol. 9, no. 11, pp. 8130–8142, 2021.
[7] S. Kit Lo, Y. Liu, G. Yu, Q. Lu, X. Xu, and L. Zhu, “Distributed Trust Through the Lens of Software Architecture,” arXiv e-prints, p. arXiv:2306.08056, May 2023.
[8] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” Decentralized Business Review, p. 21260, 2008.
[9] G. Yu, X. Zha, X. Wang, W. Ni, K. Yu, J. A. Zhang, and R. P. Liu, “A unified analytical model for proof-of-x schemes,” Computers & Security, vol. 96, p. 101934, 2020. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0167404820302108
[10] Y. Liu, Q. Lu, G. Yu, H.-Y. Paik, and L. Zhu, “A pattern-oriented reference architecture for governance-driven blockchain systems,” in 2023 IEEE 20th International Conference on Software Architecture (ICSA), 2023, pp. 23–34.
[11] Y. Liu, Q. Lu, G. Yu, H.-Y. Paik, H. Perera, and L. Zhu, “A pattern language for blockchain governance,” in Proceedings of the 27th European Conference on Pattern Languages of Programs, ser. EuroPLop ’22. New York, NY, USA: Association for Computing Machinery, 2023. [Online]. Available: https://doi.org/10.1145/3551902.3564802
[12] Y. Liu, Q. Lu, G. Yu, H.-Y. Paik, and L. Zhu, “Defining blockchain governance principles: A comprehensive framework,” Information Systems, vol. 109, p. 102090, 2022. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0306437922000758
[13] ——, “Bgra: A reference architecture for blockchain governance,” arXiv preprint arXiv:2211.04811, 2022.
[14] M. Castro, B. Liskov et al., “Practical byzantine fault tolerance,” in OsDI, vol. 99, no. 1999, 1999, pp. 173–186.
[15] G. Yu, X. Wang, K. Yu, W. Ni, J. A. Zhang, and R. P. Liu, “Survey: Sharding in blockchains,” IEEE Access, vol. 8, pp. 14 155–14 181, 2020.
[16] ——, “Scaling-out blockchains with sharding: an extensive survey,” Blockchains for Network Security: Principles, technologies and applications, pp. 225–270, 2020. [Online]. Available: https://digital-library.theiet.org/content/books/10.1049/pbpc029e_ch10
[17] Z. Zhang, X. Wang, G. Yu, W. Ni, R. P. Liu, N. Georgalas, and A. Reeves, “A community detection-based blockchain sharding scheme,” in Blockchain – ICBC 2022, S. Chen, R. K. Shyamasundar, and L.-J. Zhang, Eds. Cham: Springer Nature Switzerland, 2022, pp. 78–91.
[18] S. K. Mohanty and S. Tripathy, “n-htlc: Neo hashed time-lock commitment to defend against wormhole attack in payment channel networks,” Computers & Security, vol. 106, p. 102291, 2021.
[19] A. Kiayias, A. Miller, and D. Zindros, “Non-interactive proofs of proof-of-work,” in International Conference on Financial Cryptography and Data Security. Springer, 2020, pp. 505–522.
[20] S. Lin, Y. Kong, and S. Nie, “Overview of block chain cross chain technology,” in 2021 13th International Conference on Measuring Technology and Mechatronics Automation (ICMTMA). IEEE, 2021, pp. 357–360.

Appendix

Refer to caption — Figure 1: Architecture of the invention