Strongly Connected Topology Model and Confirmation-based Propagation Method for Cross-chain Interaction
JJOURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 1
Strongly Connected Topology Model andConfirmation-based Propagation Method forCross-chain Interaction
Hong Su, Bing Guo, Yan Shen, Tao Li
Abstract —Cross-chain interaction is among differentblockchains. When the number of blockchains increases, itis difficult for blockchains to form a single star topology ora fully connected topology. Meanwhile, different from legacynetworks, the propagation method is required to keep thedata validity. Thus, the blockchain topology and associatedpropagation methods are two key issues, which should beensured during the propagation. In this paper, we first proposethe confirmation-based propagation method to keep the validityof the cross-chain data. The confirmation method is to seal thecross-chain transaction synchronized from other blockchains.Second, we point out that a valid topology requires blockchainsto be strongly connected. With this requirement, we proposeseveral topologies, which match different connection scenarios.The simulation results show that the proposed methods cansecurely propagate the cross-chain data and the connection wayis flexible.
Index Terms —blockchain topology, strongly connected topol-ogy, transaction propagation, cross-chain interaction.
I. I
NTRODUCTION B LOCKCHAIN has been successfully applied to Bitcoininitially [1], and then applied to more digital currencyareas [2] [3]. Besides the digital currency, blockchain has alsobeen used in other aspects [4], including exchanging digitalassets [5], and improving the supply or delivery system [6][7].To interact with different blockchains, cross-chain technolo-gies [9] [10] [11] are introduced, which either transfers digitalassets or shares transaction status among blockchains. Typicalcross-chain interaction methods include the notary mechanism,sidechain, and hash-locking [12].Cross-chain interaction can occur among more than twoblockchains [13] [14]. Take an e-shopping system as anexample. This system includes three sub-systems, an electronicmarketplace, a payment system, and a delivery system, whichare based on different blockchains. A customer uses digitalcoins to buy goods from the electronic marketplace; the sellerdelivers the goods, and the shipping information of the goodsis recorded in the delivery system. When the delivery systemshows the goods have been received by the customer, the digi-tal coin pre-paid by the customer is given to the seller. Figure tx p ) in the payment blockchain depends on thetransaction (notated as tx em ) on the electronic marketplaceblockchain and the transaction (notated as tx d ) on the deliv-ery blockchain. Transactions of tx em and tx d also dependon transaction tx p .As cross-chain transactions are dependent, it requires toshare the cross-chain data among blockchains. Blockchain 1gives the payment to the seller when blockchain 1 gets theinformation that (1) there is an order in blockchain 2 betweenthe customer and the seller, and that (2) the correspondinggoods have been delivered to the customer. Then, associatedtransactions need to share among those blockchains. One wayto share transaction information is to propagate them amongdifferent blockchains [13] [15] [14].When the propagation is among several blockchains, thereare two aspects that should be considered. They aim topropagate the cross-chain transactions to other associatedblockchains effectively.(1) The blockchain topology. It is the way how blockchainsconnect (instead of how nodes connect within a blockchain).The blockchain topology should be a flexible one. Flexibilityrefers to the amount of work that is required to add or change ablockchain in a topology. Less work is required, more flexibleit is.Currently, the blockchain topology is not obviously ex-plored. There are two major kinds of blockchain connection a r X i v : . [ c s . D C ] F e b OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 2
Fig. 2. Star (centered) blockchain topology lacks scalability. ways. The first one is among two special blockchains (suchas the pegged sidechain), which forms either a mutuallyconnected topology or a star topology. The second one is toexchange data among blockchains by a blockchain router [15][14], which connects other blockchains.However, there are issues for the star (router) topology.In work [15], a single node from each blockchain forms anew router blockchain to communicate with other blockchains,which is flexible for scalability, while it has some potentialissues. The node, which represents a blockchain, is the trustcenter for that blockchain. However, we cannot trust a singlenode, as the consensus algorithm does not depend on one node.Work [14] proposes to confirm cross-chain transactionsduring the propagation process, while it may have the issue ofscalability. Suppose, there are two blockchain networks (star1and star2), shown in Figure 2. In star1, all blockchains connectto router blockchain r1; and similarly, in star2, all blockchainsconnect to router blockchain r2. Which topology should bechosen when trying to connect star1 and star2? If the startopology is still chosen (such as r1 as the center), there arestill two obvious issues. One is that all blockchains, whichconnect to r2, have to disconnect from r2 and switch to r1. It isa big change as all r2-connected blockchains are involved. Thesecond is that all cross-chain data go through router blockchainr1, whose network flow increases. If the network burden of r1is heavy enough, r1 has high network overload risk when r2-connected blockchains connect to it. A better way is to adopta flexible topology to connect those two blockchain networks.(2) How to keep the data validity during the propagation. Ifone blockchain only propagates the data without keeping thedata validity, its successive blockchains cannot trust this data,and it has no difference to propagate data on legacy networks.This paper proposes a cross-chain solution concerning both the scalability and data validation. We propose a stronglyconnect topology model, which guides to choose the possibletopologies instead of providing a fixed topology. Based onthe topology, we propose the method to keep the data validitybetween connected blockchains. The main contributions of thispaper are as follows.(1) We point out that a blockchain topology requires corre-sponding blockchains to form a strongly connected graph. Thestrongly connected topology provides the path for the cross-chain data to propagate among associated blockchains. Basedon this requirement, we propose some topologies to choosefrom when blockchains connect.(2) We propose a flexible propagation method to keep thevalidity of cross-chain data and to transform its data format.This method is done between directly connected neighbors anditerates to other neighbors. It only requires to transform andkeep the validity of the cross-chain data from its neighbor.The rest of the paper is organized as follows.Section 2describes the topology model and several topology instances.Section 3 discusses the propagation method based on theblockchain topology. Section 4 shows the verification results.Section 5 describes cross-chain related work. And section 6gives a brief conclusion of this paper.II. S
TRONGLY C ONNECTED T OPOLOGY M ODEL
The topology of blockchains describes how one blockchainconnects to other blockchains. The topology model aims toprovide a flexible connection way.We first describe the connection types between twoblockchains as it can be used to analyze the blockchaintopology among several blockchains.
A. Assumption
In this paper, we have the following three assumptions.Notice, the notation of ’blockchain’ can be the name of ablockchain or its chain of blocks; we use the term ’chain ofblocks’ as the chained blocks of a blockchain in confusingsituations.(1) Associated blockchains are based on P2P methods.Nodes of a blockchain connect to a certain number of othernodes to get and receive blockchain data (transactions andblocks) of this blockchain.(2) Chain of blocks of a blockchain can be continuously gotby other nodes, which may belong to the same blockchain orother blockchain(s). Public blockchains match this condition.For permissioned blockchain, it is required to add permissionsfor nodes of associated blockchain to access the blockchaindata (no need to grant the access to do its consensus).(3) If a blockchain (suppose blockchain A ) wants to connectto another blockchain (suppose blockchain B ), blockchain A knows how to verify whether a block is correct or not bythe consensus algorithm of blockchain B . This helps nodes ofblockchain A to make sure that information from B is correctand keep the data validity. The simplest implementation wayis that nodes of A act as the verification nodes (instead ofmining nodes) of B . OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 3
B. Connection Types between Two Blockchains
The connection of two blockchains is divided into threetypes: directly connected, indirectly connected, or not con-nected. We only describe the first two cases in which twoblockchains can exchange transaction information.
1) Directly Connected: (Blockchain) A directly connects to(blockchain) B when they match the following conditions.(1) Synchronization blockchain data from the directly con-nected blockchain. Nodes of A get blockchain data (chain ofblocks and transactions) from nodes of B by P2P method. A has a copy of the whole blockchain data of B . We also sayblockchain A gets information from B .(2) Verification of blockchain data in the directly connectedblockchain. Nodes of A follows B ’s consensus algorithm tochoose the main chain of B when there are forks in B , andto verify whether a specific transaction is correct or not.(3) Sealing cross-chain transactions into its own blockchain.If the blockchain data of B contains a cross-chain transaction,miners of A try to transform and seal it. It is the same as tomine transactions of blockchain A , except that transactionsfrom B are marked as cross-chain transactions. An extrareward for the miner is used to encourage miners to syn-chronize and seal the cross-chain transactions from associatedblockchains.One direct connection has its direction. A directly connectsto B does not mean that B also directly connects to A if nodesof B do not get the chain of blocks from nodes of A or do notfollow A ’s consensus algorithm. Figure 3 shows an example,in which A directly connects to B and C while B or C doesnot directly connect to A . For simplification, Figure 3 can bereformed into Figure 4, in which we hide details of nodes. Fig. 3. Directly connected blockchains. Blockchain A directly connects toblockchain B and C , in which nodes of blockchain A connect to certainnumber of nodes of blockchain B (solid arrow) and blockchain C (dottedarrow).
2) Indirectly Connected: (Blockchain) A indirectly con-nects to (blockchain) B when it matches the following condi-tions.(1) Nodes of A does not get the blockchain data from nodesof blockchain B .(2) Or nodes of A does not follow the consensus ofblockchain B to validate the blockchain data of B . Fig. 4. Simplified diagram for directly connected blockchains. (3) However, blockchain A still connects to blockchain B . Nodes of blockchain A gets cross-chain transactions ofblockchain B through other blockchains. C. Strongly Connected Topology
To describe the topology of blockchains, we use the directedgraph. If (blockchain) A directly connects to (blockchain) B ,we use a directed edge to stand for the relationship, pointingfrom A to B . All edges consist of a directed graph.The essential characteristics of blockchain topology requireconnected blockchains to form a strongly connected graph, inwhich blockchain data can be exchanged. Figure 5 shows ablockchain topology with all blockchains directly connected.Why the topology graph is strongly connected? We brieflyprove this by reduction to absurdity. If the graph is not stronglyconnected and then at least one node (one blockchain) cannotbe reached. Assume that node is node N. It means no othernodes can get blockchain data from N, and then cross-chaintransactions on this blockchain cannot propagate to otherblockchains. Thus, no blockchain should be unreachable. Thetopology graph of corresponding blockchains is a stronglyconnected graph.Now we describe some typical topology models.Fully connected topology is a topology in which allblockchains are directly connected. Figure 5 is one example;each blockchain connects to all other blockchains. However,the connection is complicated, and the number of connectionsincreases when the number of blockchain increases. Suppose,each node of a blockchain needs to connect at least k nodesof another blockchain. If there are j blockchains, each nodeneeds to connect k ∗ ( j − nodes of other blockchains.Star topology is a topology in which associated blockchainscommunicate through a center blockchain (the routerblockchain). This kind of topology is also called the routertopology. Figure 6 shows an example. In the left part,blockchain 3 acts as the center node; blockchain 1 andblockchain 2 communicate through blockchain 3; in the rightpart, blockchain 3 acts as the center nodes of all otherblockchains.The star topology has a center blockchain, which may causesome potential issues. (1) The center blockchain has a heavycommunication burden; (2) it is relatively big work to mergetwo star topologies as discussed in the introduction section.Now we describe another topology of blockchains whichonly requires one blockchain directly connects to one anotherblockchain, called the ring topology. OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 4
Fig. 5. Fully connected topology example.Fig. 6. Star topology example
D. Ring Topology – An kind of Strongly Connected Topology
As it only requires the blockchain topology to form astrongly connected graph, the fully connected topology can besimplified. One simplified method is that a blockchain onlydirectly connects to another one. This kind of topology iscalled the ring topology.In the graph of the ring topology, each blockchain (as anode) has an outgoing edge (pointing to other nodes) and in-coming edge (pointing to this node). Both edges are necessary.If a node has only one of the two edges, it cannot exchangeblockchain data with other blockchains. In this way, all nodesform a strongly connected graph. Figure 7 shows an example,in which each blockchain connects to another one and thosefive blockchains form a ring topology.
Fig. 7. Ring topology example.
1) Bridge Blockchain:
In a blockchain topology, someblockchains only help to propagate the cross-chain data forother indirectly connected blockchains. Those blockchains arecalled bridge blockchains. They do not have their own cross-chain transactions and only participate in the propagation ofthe cross-chain interaction.Figure 8 shows one example, in which blockchain from 1to 5 have their associated transactions (named from
T x to T x separately). There is no cross-chain transactions fromblockchain 6. It acts as the bridge blockchain, which makesother blockchains strongly connected. Fig. 8. An example of the bridge blockchain (blockchain 6).
E. Connecting to New Blockchain
To form or join a blockchain topology, a blockchain is re-quired to connect to other blockchain(s). We propose a specialkind of transaction (the topology proposal transaction) that isused to initialize the proposal for the connection to anotherblockchain. It is sent from specific accounts, namely topologyselection accounts. Those accounts can be pre-configured inthe source code or match some conditions (such as accountswho have the top maximum number of assets).After a topology proposal transaction is put into theblockchain, topology selection accounts send another kind oftransaction (the agreement transaction) if they agree with theproposal. Agreement transactions aim to avoid error sendingof the topology proposal transaction. Certain portion insteadof all those accounts are required to agree, as some topologyselection accounts may be inactive.There are some limitations to the connection proposal. Themaximum number of directly connected blockchains shouldbe limited, aiming to restrict the number of external nodes toconnect. Meanwhile, some aspects of a target blockchain areevaluated for the connection; if the target blockchain does notmatch, the new connection is still not carried out.III. C
ONFIRMATION - BASED P ROPAGATION M ETHOD
In this section, we describe the proposed cross-chaindata propagation method, the confirmation-based propagationmethod (CBT), which aims to keep data validity during thepropagation.
OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 5
A. Confirmation-based Propagation Process
Different from legacy networks, data validity should be con-firmed in its directly connected blockchain. If one blockchainonly propagates the data without confirmation, its successiveblockchains cannot trust this data, and it does not havemuch difference to propagate the transaction data on a legacynetwork.The confirmation process is similar to the process for aninternal transaction. The validity of an internal transactionis kept by sealing it to the blockchain with the consensusalgorithm. Then for a cross-chain transaction, it can still beachieved by sealing it into associated blockchains. We selectthe ring topology as an example to analyze.After a blockchain gets cross-chain transactions from itsdirectly connected blockchain, its miners process to confirmthose transactions into its own blockchain. This is called theconfirmation-based propagation process. It can be divided intotwo steps. In the first step, corresponding nodes transform theformat of cross-chain transactions, which will be described in“Format Transformation of Cross-chain Data”. In the secondstep, miners of target blockchain try to seal transformed cross-chain transactions to its own blockchain.Algorithm 1 is the algorithm for the above process (thesynchronization process is also included), which is betweentwo directly connected blockchains. Line 1 synchronizes theblockchain data, and line 2 checks the validation of theblockchain data. Lines from 5 to 9 are the second steps, inwhich new cross-chain transactions are selected and trans-formed. Lines from 10 to 17 are the third steps, in whichthe cross-chain data is sent to miner for sealing.We use Figure 9 to explain this process, in which blockchainM directly connects to blockchain M+1. Nodes of blockchainM synchronize the blockchain data from their connected nodesof blockchain M+1 periodically – arrow marked with ’(1)synchronize’. The cross-chain transaction is selected, and itsformat is transformed into the format of blockchain M –marked with ’(2) transformation’. Miners of blockchain M tryto seal this transaction into its own blockchain – marked with’(3) seal’.
Fig. 9. The process to synchronize and seal cross-chain transaction fromdirectly connected blockchain.
Algorithm 1
To retrieve and seal the cross-chain data fromdirectly connected blockchain.
Require: blockchain dcb is the directly connected blockchain of thecurrent blockchain. Transactions are sealed in blocks forsimplification.
Ensure: cross-chain transactions in dcb is sealed into the currentblockchain copiedBlockchain = synchronize chain of blocks fromdirectly connected blockchain dcb if copiedBlockchain is invalid then return; end if transactionList = get transaction list from new blocksof copiedBlockchain for each transaction t in transactionList if t instanceof Cross-chainTransaction then //transform different data format between directly con-nected blockchains newT ransaction = transform the format of t ; // other nodes may seal first, then we judge whether ithas already been put into this blockchain or not if newT ransaction does not exist in currentblockchain then // Let miner to seal this transaction if mining node then try to seal newT ransaction into blockchain; end if end if end if
1) Propagation Between Indirectly Connected Blockchains:
The above is the propagation process between directly con-nected blockchains, which iterates to propagate data to indi-rectly connected blockchains.We use a function (
P rop ) to describe the iterative propaga-tion process. This function is the abstract of propagation stepsbetween directly connected blockchains X and Y . It indicatesthat transaction CrT x X on blockchain X is propagated toblockchain Y as transaction CrT x Y , referring to (1).
CrT x Y = P rop ( CrT x X ) , where CrT x X is a cross − chain data in blockchain X, and CrT x Y is the cross − chain data in blockchain Y after one propagation . (1)Now suppose there are three blockchains, M -1, M , and M +1. M -1 directly connects to M , and M directly connectsto M +1. Then we get propagation description as in (2) (3)(4). CrT x M = P rop ( CrT x M + 1) (2)
CrT x M − P rop ( CrT x M ) (3) OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 6
CrT x M − P rop ( CrT x M ) (4) = P rop ( P rop ( CrT x M + 1))
From (4), we see the cross-chain data
CrT x M +1 in M +1has been propagated to its indirectly connected neighbor M -1. Data validity is kept during this propagation process, andit has even been enhanced as all associated blockchains havesealed the cross-chain data.For any indirectly connected blockchain M and N , there isat least one directed path from M to N . CrT x M propagatesalong one of those paths to N . Suppose the path is M − >. . . − > N +1 − > N , then we get the propagation as in (5). CrT x N = P ro ( CrT x M )= P ro ( P ro ( CrT x M )) (5) = P ro ( ... ( P ro ( CrT x M )))
This process is shown in Figure 10. Cross-chain transaction(
CrT x M +1) is put to blockchain M +1 (left part of Figure10). Then this transaction data propagates to its directlyconnected neighbor M (the middle part of Figure 10). Atlast, blockchain M propagates this transaction to its directlyconnected neighbor M -1 (right part of Figure 10). Thus, CrT x M +1 propagates from blockchain M +1 to its indirectlyconnected blockchain M -1. Fig. 10. The transaction propagation to indirectly connected blockchains.
B. Format Transformation of Cross-chain Data
The data structures of transactions may be different amongblockchains. If we transform data format between all possibleblockchain pairs, the number of transformations is the squareof the number of blockchains.There are two possible ways to handle the transformationof the cross-chain data. One is to unify the format of the crosstransaction within all blockchains – the unified way; anotherone is to translate the cross-chain date of directly connectedblockchains – the translation way.There are some related works on the unified way [14]. Inthe unified way, each blockchain has a unified transaction datastructure instead of its own transaction structure. While it stillneeds to transform the data format between the cross-chaintransaction and the local transaction; it requires all blockchainsto adopt the unified cross-chain transaction data format. Inthis paper, we introduce the translation way between directlyconnected blockchains.
1) Translation Way:
In this way, we should consider howto eliminate the number of the required transformations. In ourproposed way, each blockchain transforms the cross-chain dataof directly connected blockchains. This process is repeated inall directly connected blockchains. It reduces transformationsrequired for indirectly connected blockchains. Figure 11 showsthis process.
Fig. 11. Blockchain data transformation process.
This process is similar to the propagation process and isdone in the propagation steps. In Figure 11, one transaction(
CRT X ) of blockchain M +1 is in original format ’M+1’;its directly connected neighbor (blockchain M ) gets thistransaction information and translates it from format ’M+1’ toformat ’M’ ( CRT X (cid:48) ) which is the format used in blockchain M . Blockchain M -1 knows how to transform format ’M-1’and it translates format from ’M’ to ’M-1’.From the transformation point of view, we say blockchain A directly connects to blockchain B refers to that (1) blockchain A translates the transaction format of blockchain B , and (2)seals the transformed transaction into its own blockchain. Weintroduce a transformation function T ransf to give a formaldescription of the transformation process. The transformationfrom f n to f m is expressed as (6), which is between directlyconnected blockchains. f m = T ransf n m ( f n ) , where f n is the original format and f m is the formatafter transformation; T ransf n m is the function totransform transaction from format f n to f m . (6)Now we begin to describe the transformation process in thepropagation path. Suppose there is a blockchain sequence ina ring topology as in (7). [ bc , bc , ..., bc n ] (7)Then the associated formats are also in a sequence, whichis in formula (8). [ f , f , ..., f n ] , where f n is the blockchain data format in blockchain n. (8)The transformation process is described as in (9). OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 7 f = T ransf n ( f n ) f = T ransf ( f ) ...f n = T ransf n − n ( f n − ) (9)In this transformation sequence, we see each blockchainonly needs to know how to transform the data of the directlyconnected blockchain and has only one transformation func-tion T ransf n m . The total number of the transformation is n which is linear to the number of blockchains while the dataformat can be transformed between any blockchain pairs. C. Security Analysis
In the propagation process, there are two security en-hancement processes for the directly connected blockchains.Suppose (blockchain) A directly connects to (blockchain) B .First, nodes of A check the validity of cross-chain transactionsfrom B by the consensus algorithm of B . And then minersof A seal those cross-chain transactions by its own consensusalgorithm. Then a cross-chain transaction of B is confirmedtwice. The final consensus process ( consensus f ) can be seenas in (10). consensus f = consensus A ( consensus B ( T x )) , where T x is a cross − chain transaction , consensus B and consensus A are consensus algorithm of blockchain B and A respectively . (10)Then possible combinations of PoS and PoW are, P oS ( P oW ( T x )) , P oW ( P oW ( T x )) , P oW ( P oS ( T x )) , and P oS ( P oS ( T x )) .Suppose, p i is the possibility to fake a transaction onblockchain i . Thus, a successful fake of a cross-chain transac-tion requires to fake associated transactions in all associatedblockchains. Then the possibility ( pb ) to fake a cross-chaintransaction is as in (11). pb = p ∗ . . . ∗ p i ∗ . . . ∗ p n (11)From (11), we know the possibility to fake a cross-chaintransaction in associated blockchains is far less than thepossibility to fake in a blockchain. This can also be understoodby the propagation process of the cross-chain transaction.Suppose a node n m on blockchain m fetches the data of atransaction tx n on blockchain n , and seals it as a copy tx m onblockchain m . Their validation methods are independent. tx m is validated by the consensus algorithm of blockchain m , and tx n is validated by the consensus algorithm of blockchain n .They are independent and then an adversary has to break twosystems to achieve the cheating purpose. When more copies ofthis transaction have been sealed in other indirectly connectedblockchains, it is even more difficult to break all correspondingblockchains.If an adversary only breaks some blockchains, we can detectthis as transaction copies are different among blockchains. Wedefine a new variety ( pf ) as the possibility to detect that across-chain transaction has been changed. pf is the opposite of the possibility that states of a transaction in all blockchains arethe same, which includes cases that all blockchains have beenchanged or none of the blockchains has not been changed, asin (12). pf = 1 − (1 − p )( . . . )(1 − p i )( . . . )(1 − p n )– pb, where 1 − p i is the possibility that a blockchainhas not been broken . (12)Then with the confirmation in its directly and indirectlyconnected blockchains, the inconsistency of data can be de-tected. This brings new features of the security of a cross-chaintransaction. IV. V ERIFICATION
In this section, we describe and analyze the verificationresult, with the aim to show the flexibility of the proposedmethods and how the data validity is kept during the propa-gation. It has three subsections. The first subsection describesthe environment. The second subsection compares the stronglyconnected topology with the router topology (a star topology),and the third subsection verifies different connection way ofthe proposed methods.
A. Verification Environment
We set up four blockchains for cross-chain verifica-tions, blockchain 1, 2, 3 and 4. Each blockchain has itsown blockchain configuration, including its mining config-uration, genesis block, and a unique blockchain number(blockchain identification number or simply blockchain id).Those blockchains are deployed on virtual machines. Differentblockchains have different numbers of nodes, and resources ofnodes are also different (CPU, 1, 2, or 4 vCPU; memory, 1G,2G, 4G or 8G; hard disk, 32G or 64G).The blockchain data has been divided into two types,internal blockchain data, and (external) cross-chain blockchaindata. A blockchain has its own flag to identify a cross-chain transaction. This flag is used for miners of its directlyconnected blockchain to process cross-chain transactions.The blockchain data transfers by the P2P method. Weimplement it by corresponding Java socket APIs. The nodes ofdirectly connected blockchains are pre-configured in a file forsimplification. Nodes of a blockchain (suppose A ) connect tonodes of its directly connected blockchain (suppose B ), andget the chain of blocks from B periodically (every 1 secondin our verifications). After a synchronization, miners of A tryto pick the cross-chain transactions, transform, and seal theminto A ’s chain of blocks. Then those transactions are in A ’sown blockchain and are synchronized among internal peers ofblockchain A .Nodes of a blockchain act as verification nodes of itsdirectly connected blockchain. Those nodes only run theverification code of the target blockchain, and they only dothe consensus algorithm for its own blockchain.There are two different consensus algorithms in the verifica-tions, PoW and PoS. For the PoW algorithm, miners try to finda random number (nounce) to match the target difficulty, which OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 8 requires that the hash of a block starts with a certain numberof zeroes (6 zeros in the verifications). For simplification, thedifficulty is fixed during the test process, and does not changeto adjust the mining time.For the PoS algorithm, we use (PoS) weight to select theaccount to seal a block. If an account has maximum weight, itseals the next block. PoS weight is a number and is calculatedconcerning the amount of an account’s asset. Its initial valueis mapped linearly to the account of an account’s asset. At theconstruction stage, we initiate a certain number of accounts(16 accounts) with different numbers of assets. If one accounthas sealed a block, a certain amount of weight is substratedfrom it. To avoid possible mining conflicts, an account is onlymounted to one node. The block is sealed on that node if thecorresponding account is selected.
B. Network Load Comparison among Router Topology andRing Topology
In this subsection, we compare the router topology (thestar topology) and the proposed strongly connected topology(a ring topology). We adopt the network load to reflect thetopology structure. The network flow refers to the amountof blockchain data exchanged among blockchains. In therouter topology, all other blockchains connect to a routerblockchain, and then their blockchain data go through therouter blockchain. The ring topology is one kind of thestrongly connected topology, in which the network load ofa blockchain only goes to its directly connected blockchain.There are three blockchains in the verifications, blockchain1, 2, and 3. In the router topology, blockchain 1 behaves asthe router blockchain, which directly connects to blockchain 2and 3. Blockchain 2 and 3 also directly connect to blockchain1. The router topology is depicted in Figure 12. In the ringtopology, blockchain 1, 2, and 3 directly connect to anotherone, shown in Figure 13.
Fig. 12. The router topology.Fig. 13. The ring topology.
There are two subtype verifications, S1 and S2, with respectto different consensus algorithms of those blockchains. In S1, consensus algorithms of all blockchains are PoW. In S2,consensus algorithms of blockchain 1 and 2 are PoW, and thatof blockchain 3 is PoS. We test different consensus to showcross-chain data can be also confirmed when the consensusalgorithms are different. PoW and PoS are selected, as theyare the most widely used consensus currently.To send transactions continuously, we use scripts to sendout cross-chain transactions, and one node of each blockchainis selected to run those scripts. The transaction sending rateis from 150 transactions per minute to 5000 transactions perminute. There are two ways to adjust the rate. (1) Manual way.This way aims to reduce the big difference of the network loadamong blockchains – to make sure there is no blockchainwhose network flow is ten times of other blockchains. (2)Automatical way. The sending node automatically processesanother transaction after the previous transaction is pre-processed; pre-processing includes to parse transaction data,to check the balance of the sender, and to send to othernodes. The higher the average pre-processing speed is, themore transactions one node process.The network flow of a blockchain is the sum of the networkflow from all nodes of a blockchain. If we only fetch networkflow from partial of its nodes, it cannot reflect the outgoingnetwork flow of the whole blockchain, as its directly connectedblockchain may get the blockchain information from othernodes. A counter to measure the network flow of a nodeis added when socket APIs are invoked to send or receivepackages to external blockchain nodes. The counter outputsnetwork flow per second.The network flow of S1 is shown in Figure 14, in whichthe left part is for the router topology and the right is for thering topology.In the left part of Figure 14 (the network flow of the ringtopology), we see that those three blockchains have almost thesame network flow over time. The exchange of cross-chaindata occurs among directly connected blockchains instead ofa centered blockchain. The network flow of each blockchainhas no big difference as (1) the transaction sending rate isapproximately the same, and (2) the mining difficulty is thesame (6 zeros) for those three blockchains.The right part of Figure 14 shows the network flow of therouter topology. Blockchain 1 has far more network flow thanthe other two blockchains do. For example, at 350 seconds, thenetwork flow of blockchain 1 is 1,842,757 bytes per second,881,557 and 961,200 bytes per second for blockchain 2 andblockchain 3 accordingly. This indicates that the network flowof the router blockchain is heavier than any of its connectedblockchain.To further see the relationship of the router blockchain andits connected blockchains, we show the sum and the differenceof network flow of router-blockchain-connected blockchains inFigure 15.There are two interesting points in Figure 15. The firstone is that the sum of the network flow of blockchain2 and blockchain 3 is very close to that of the routerblockchain (blockchain 1). At 360 seconds, the networkflow of blockchain 1, blockchain 2, and blockchain 3 are1,871,229bytes, 881,557 bytes , and 989,672 bytes in a second
OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 9 time (seconds) ne t w o r k f l o w ( b y t e s ) × router topology blockchain 1blockchain 2blockchain 3 time (seconds) ne t w o r k f l o w ( b y t e s ) × ring topology blockchain 1blockchain 2blockchain 3 Fig. 14. The network flow of S1. The left is for the router topology, and the right is for the ring topology. time (seconds) -505101520 ne t w o r k f l o w ( b y t e s ) × router topology blockchain 1blockchain 2 - blockchain 3blockchain 2 + blockchain 3 Fig. 15. The network flow comparison of S1 for router topology. Notationof ’blockchain 2 - blockchain 3’ means the difference of the networkflow between blockchain 2 and blockchain 3; notation of ’blockchain 2 +blockchain 3’ means their sum. We skip that for ring topology as eachblockchain’s network flow is almost the same. respectively. The network flow of blockchain 1 is equal tothe sum of blockchain 2 and blockchain 3. It indicates thatall cross-chain data are through router blockchain. We canpredict that if the number of blockchains connecting to therouter increase, the network flow increase greatly.The second one is that the difference in the network flowamong blockchain 2 and blockchain 3 is not obvious (referringto the curve of ’blockchain2-blockchain3’ in Figure 15). Thedifference has no obvious tendency; there are minus or positivevalues of the difference interactively. This is due to that thosetwo blockchains have the same mining difficulty (6 zeros) andthe cross-chain transaction sending speed is the approximatelysame (around 3000 transactions per minute).The network flow of S2 in the ring topology and the routertopology are shown in Figure 16.The left part of Figure 16 is the network flow of the ringtopology. There is a little difference for the ring topologycomparing to the S1 case. The network flow of blockchain 1 isless than × bytes, which is similar to that in S1. However,those of blockchain 2 and 3 increase several times (maximumvalue approximate to × bytes), compared to the network flow in S1. The reason is that blockchain 3, which runs thePoS algorithm, has no need to use CPU to calculate a hashand has a higher capacity to process other tasks (including thetransaction pre-processing task and the synchronization task).Its periodic tasks, which synchronize the blockchain data fromits directly connected blockchain (blockchain 2), have morechances to be scheduled and to finish in time.Another interesting point of the left part of Figure 16 is thatthe sum of the network flow of blockchain 2 and 3 is morethan the maximum network flow (of blockchain 1). It provesindirectly that no blockchain acts as the center to exchangenetwork flow of all blockchains. This kind of topology hasthe potential to separate the network flow to each blockchain,which makes the scalability of this topology more flexible.From the right part of Figure 16, we see the network flowof the router topology has almost the same tendency as inthe S1 case. The network flow of blockchain 1 (the routerblockchain) is the sum of another two blockchains. The sumand difference of blockchain 2 and blockchain 3 are shown inFigure 17.Figure 17 also shows the same tendencies as in the S1 case.The sum of the network flow of blockchain 1 and 2 is closeor equal to that of router blockchain. The difference fromS1 is the network flow difference among blockchain 1 andblockchain 2. The curve increases almost in a linearly way(in the result of a linear regression between the difference ofnetwork flow and the time, ‘multiple R’ is 0.9979, and ‘RSquare’ is 0.9957).In both S1 and S2 cases, we see different network flowdistribution among the router topology and the router topology.In the router topology, the network flow is through the routerblockchain. With the increase of connected blockchains, theburden of the router blockchain increases. However, the ringtopology can dispatch the network flow to its directly con-nected blockchains, which indicates that it is a more flexibletopology.In the following sections, we try to verify the impact ofdifferent connection ways on the strongly connected topologyand how the data validity is confirmed during the propagationprocess. OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 10 time (seconds) ne t w o r k f l o w ( b y t e s ) × router topology blockchain 1blockchain 2blockchain 3 time (seconds) ne t w o r k f l o w ( b y t e s ) × ring topology blockchain 1blockchain 2blockchain 3 Fig. 16. The network flow of S2. The left is for the ring topology, and the right is for the router topology. time (seconds) -1-0.500.511.522.5 ne t w o r k f l o w ( b y t e s ) × router topology blockchain 1blockchain 2 - blockchain 3blockchain 2 + blockchain 3 Fig. 17. The network flow comparison of S2 for the router topology.Notation of ’blockchain 2 - blockchain 3’ means the difference of the networkflow between blockchain 2 and blockchain 3; notation of ’blockchain 2 +blockchain 3’ means their sum. We skip that for ring topology as eachblockchain’s network flow is almost the same.Fig. 18. The topology of two indirectly connected blockchains.
C. Different Connection Way
In this verification scenario, we describe the verificationresult with respect to how the cross-chain transactions areconfirmed in the different connection ways, such as directlyconnected or indirectly connected. The consensus is PoW, asthe result for PoS is similar, and we skip the result for PoW to save space.
1) Cross-chain Interaction with Bridge Blockchains:
Ifthe cross-chain interaction is among partial blockchains, thepropagation among those blockchains needs the help of bridgeblockchains. Bridge blockchains may occur in different po-sitions, which causes other blockchains to form differentconnection ways, either directly connected or indirectly con-nected.(1)Indirectly ConnectThis verification is in a ring topology among blockchainsfrom 1 to 4 (those blockchains are different from blockchainsin the previous verification section as we reconstructed them),shown in Figure 18. We want to verify the cross-chain dataconfirmation process among blockchain 1 and 3, which areindirectly connected through bridge blockchain 2 and 4. Twocross-chain transactions (
CRT X and CRT X ) are used inthe verification. CRT X is sent out in blockchain 3 and CRT X is sent out in blockchain 1. They are associatedcross-chain transactions, which means the receiver of onetransaction gets the asset when another transaction has beenpropagated into the former transaction’s blockchain.Figure 19 shows the propagation result. Both transactionsare carried out at almost the same time. As the mining periodsare similar, both are sealed into its own blockchain at 11:44(the time format is hh:mm, and the same is in the following).However, CRT X propagates more quickly as it is in adifferent propagation path. At 11:45, CRT X propagates toblockchain 2, and at 14:46 CRT X has been propagated toall blockchains. CRT X only propagates to blockchain 4at 14:46. Finally, at time 14:47 CRT X propagates to allblockchains. Then, both transactions have been propagatedto all blockchains no matter they are directly or indirectlyconnected.We also show the balance change process during the propa-gation. The asset of a transaction transfers to its receiver whenits required cross-chain transaction has been confirmed andpropagated to the target blockchain. For example, if CRT X has been propagated to blockchain 1, the sender of CRT X can confirm that CRT X is in blockchain 3 and the asset istransferred to the receiver of CRT X .The balances of all accounts are dumped when any user’s OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 11 blockchain t r an s a c t i on CRTX 1CRTX 2 blockchain t r an s a c t i on CRTX 1CRTX 2 blockchain t r an s a c t i on CRTX 1CRTX 2 blockchain t r an s a c t i on CRTX 1CRTX 2
Fig. 19. Ring topology with target transactions in indirectly connected blockchains. The time format is hh:mm, and this is the same in the following diagrams. time/minutes ba l an c e sender in blockchain 1 receiver in blockchain 1 14:44 14:45 14:46 14:47 time/minutes ba l an c e sender in blockchain 3 receiver in blockchain 311:49 11:50 11:51 11:52 11:53 time/minutes ba l an c e sender in blockchain 1 receiver in blockchain 1 11:49 11:50 11:51 11:52 11:53 time/minutes ba l an c e sender in blockchain 2 receiver in blockchain 2 Fig. 20. The balance of change process of the indirect case (diagrams at the upper part of this diagram) and the direct case (diagrams at the lower part ofthis diagram). balance has been changed. The balance change process isshown in the upper two parts of Figure 20. Balances ofsenders in blockchain 1 and 3 are subtracted at time 14:44.Receivers get their assets at 11:46 and 11:47 separatelywhen the associated transaction reaches. The time of re-ceiver in blockchain 3 and 1 who receives the asset at adifferent time as the propagation is in different paths; one is blockchain − > blockchain − > blockchain , and anotheris blockchain − > blockchain − > blockchain .(2) Cross-chain Interaction without Bridge BlockchainsIn this verification, there are four cross-chain transactions CRT X , CRT X , CRT X , and CRT X . Each transactionis sent in one blockchain, and thus there are no bridgeblockchains. Figure 21 shows the topology of the blockchainconnection which blockchain associated transactions.The propagation result is shown in Figure 22. Two interest-ing points are here. The first one is that at 02:44 both CRT x and CRT x are sealed into blockchain 3. After we dump theblockchain data, both transactions are sealed into one block.This indicates that some transactions may be accumulated toone block due to different mining time and different mining Fig. 21. The topology of all directly connected blockchains. overload.The second issue is that blockchain 3 has the weakestcalculation power. Its mining period is average longer thanothers, although the mining difficulties of all blockchains arethe same (a newly mined block hash starts with 6 zeros).
OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 12 blockchain t r an s a c t i on CRTX 1CRTX 2 blockchain t r an s a c t i on CRTX 1CRTX 2 blockchain t r an s a c t i on CRTX 1CRTX 2 blockchain t r an s a c t i on CRTX 1CRTX 2 blockchain t r an s a c t i on CRTX 1CRTX 2
Fig. 22. Ring topology with one target transaction in directly connected blockchains. blockchain a v e r age m i n i ng t i m e / s e c ond s Fig. 23. The average mining time of blockchain from 1 to 4
After checking the resources of its nodes, they are gener-ally the weakest calculation resources (the fewest nodes andCPUs) for calculation. Figure 23 shows a comparison of thoseblockchain’s block mining time (in seconds).V. R
ELATED W ORK
Cross-chain interactions aim to keep cross-chain exchangesatomic [10] [16], which ensures that associated transactionsare valid or invalid together. Current methods used to ensureatom swap include notary method, relay chain, or hash-locking[12]. Those methods check whether some target transactionsare sealed in a specific blockchain or not. Cross-chain data isrequired to propagate in many cross-chain cases.At the early stage, special topology is used in cross-chaininteractions, such as in methods of relay-chain and peggedsidechain. The relay-chain method aims to solve the issue ofextensibility and scalability of blockchains, and provide a scal-able, heterogeneous multi-chain protocol [17]. This method isbased on a star topology, in which the relay-chain connectsall other parachains. Pegged sidechain originated from Bitcoinblockchain, and it enables the main chain (such as Bitcoin) andother blockchains (sidechain) to transfer assets among them[18]. The topology is among the main chain and its pegged chains. If there is one sidechain, it forms a mutually connectedtopology. If there are several sidechains, it is a star topology.Later on, some works [15] [14] propose the blockchainrouter, which aims to behave as the router of the Internet.It has a center ‘hub’ blockchain which connects all otherblockchains. With the help of the center blockchain, otherblockchains can exchange blockchain data. However, it alsohas disadvantaged as other blockchains are required to registerand communicate with the center blockchain. It may burdenthe center blockchain with a heavy network flow, as all otherblockchains communicate through it. Meanwhile, if we wantto connect two centered blockchain networks to a new centeredone, it requires all blockchains to connect to this new one.For propagation methods, some methods rely on specificroles (such as validator, connector, surveillant, and nominatorin [15]) or special accounts (such as escrow address in [14])to keep the transactions atomic or data validity. In [14], itadopts three-phase commit to synchronize the transaction stateamong blockchains. However, this method depends on a singlenode to communicate among blockchains, and it lacks a strongmethod to ensure data validation. Work [15] overcomes thedisadvantages in which the validity of cross-chain data is notensured. It adopts a special consensus algorithm (DS-PBFT)to confirm and keep the validity of cross-chain transactions.The transaction format is also an interesting point. Forheterogeneous blockchain, work [14] adopts a way to usethe standard transaction data format [14]. Blockchains caninteract with each other with this standard transaction format.The disadvantage is that all blockchains must adapt to thisunified format, which is difficult when the account of associ-ated blockchains are huge. For pegged blockchains [11], thepaired transactions appear in associated blockchains during thetwo-way peg process, in which a hidden transaction formattransformation is done.VI. C
ONCLUSIONS
In this paper, we analyze the topology and the correspondingpropagation method for the cross-chain transaction. It aims toprovide a flexible blockchain topology with the data validityis ensured during the propagation. We point out the topology
OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 13 of blockchain is a strongly connected graph, and based on thisprinciple we propose several topology instances for flexibility.Especially a ring topology model, which only requires ablockchain to connect to another one blockchain directly. Itreduces the number of required neighbors. The propagationmethod is between directly connected neighbors, and it iteratesto propagate the data among indirectly connected neighbors.With the proposed topology and propagation methods, thepropagation of cross-chain transactions can be based on aflexible topology, and the data validity is kept. Future worksinclude cross-chain interactions based on the propagated cross-chain transactions. A
PPENDIX A CKNOWLEDGMENT