Field of Invention

The present invention relates to methods and apparatus for enabling and facilitating interaction between blockchains. In embodiments, the present invention enables a verifiable transfer of assets to take place remotely from a ledger of record.

Background of Invention

A blockchain is a continuously growing list of records, called blocks, which are linked and secured using cryptographic processes. Each block contains a link to a previous block and data, such as transaction data - it may also contain other data such as a timestamp. A key advantage of blockchain design is that blockchains are inherently resistant to modification of the data, rendering blockchains particularly suitable for making records public while providing a basis for trust that the record data is accurate. A blockchain can for example serve as an open, distributed ledger that can record transactions between parties efficiently and in a verifiable and permanent way. For such use, a blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for validating new blocks. Once recorded, the data in any given block cannot be altered retroactively without the alteration of all subsequent blocks, which needs a collusion of the network majority - this is achieved by mechanisms such as the inclusion of a signed hash of one block in the block that follows it.

If blockchains become large, related processes such as creation and validation of new blocks can become slow. Under such circumstances, it may be desirable for multiple blockchains to exist and grow in parallel. It may also be desirable for blockchains managed by different parties to interact. Existing blockchain technology lacks effective mechanisms to support

development of parallel, interacting blockchains, though blockchain interaction has been considered in some systems. The Cosmos Network has developed an Inter-blockchain Communication protocol— Cosmos IBC for short - to support communication and crypto-asset transfers across a network of siloed blockchains (discussed

5855aaf183fe). Plasma (described

technique for conducting off-chain transactions while relying on the underlying Ethereum blockchain to ground its security. There are nonetheless challenges in providing a simple and effective solution.

Summary of Invention

In a first aspect, the invention provides a method implemented on a computing system of enabling an asset held on a ledger recorded on a first blockchain to be transacted on a ledger recorded on a second blockchain, the method comprising: preparing an interledger transaction to transfer the asset from the first blockchain to the second blockchain; preparing a transaction list of transactions linking the first blockchain to other blockchains, the transaction list comprising the

interledger transaction, and signing the transaction list; writing the interledger transaction and the transaction list to a block of the first blockchain; and obtaining from the block of the first blockchain a second ledger transaction to record the asset on the second blockchain using the interledger transaction and the transaction list.

Preferably, the method further comprises writing a transaction to the second blockchain comprising parameters of the first blockchain. These parameters may comprise signatory parties for the first blockchain, or block height for the first blockchain, or both.

Advantageously, the transaction list is signed by signatory parties validating the block of the first blockchain. In embodiments, obtaining from the block of the first blockchain a second ledger transaction may comprise a witness node inspecting the block of the first blockchain and preparing a cross-chain transaction package for writing to a block of the second blockchain. This cross-chain transaction package may be prepared for writing to blocks of any blockchain identified in the cross-chain transaction package other than the first blockchain.

In embodiments, the second blockchain may verify the second ledger transaction before writing the second ledger transaction to a block of the second blockchain. Verifying the second ledger transaction may comprise determining that the second ledger transaction does not relate to an already processed block of the first blockchain, may also comprise determining that the second ledger transaction comprises all required transactions, and may also comprise determining that the signatory parties are as expected.

In a second aspect, the invention provides a computer implemented method of transacting in an asset with respect to a secondary ledger comprising a second blockchain away from a ledger of record comprising a first blockchain, comprising: transferring the asset from the ledger of record to the secondary ledger using the method as described above; transacting the asset in a second blockchain transaction; and reconciling the second blockchain transaction with the first blockchain.

The second blockchain transaction may transfer the asset to a third blockchain, in which case reconciling the second blockchain transaction with the first blockchain may comprise the third blockchain interacting with the first blockchain to novate management of the asset from the second blockchain to the third blockchain.

Brief Description of Figures

Embodiments of the invention will now be described, by way of example, with reference to the accompanying Figures, of which:

Figure 1 shows a physical architecture for a computing apparatus for supporting a blockchain architecture in which embodiments of the invention are employed;

Figure 2 shows schematically a blockchain architecture in which embodiments of the invention are employed;

Figure 3 shows an approach to establishing a link between blockchains according to an embodiment of the invention;

Figure 4 shows a blockchain consensus process adapted in accordance with embodiments of the invention;

Figure 5 describes derivation of a cross-chain package in accordance with embodiments of the invention;

Figure 6 processing of the cross-chain package of Figure 5 by a blockchain in accordance with embodiments of the invention;

Figure 7 illustrates a ledger according to an embodiment of the invention;

Figure 8 illustrates inter ledger holdings for ledgers of the type shown in Figure 6;

Figure 9 illustrates a transaction between two private ledgers relating to an asset shown on a ledger of record of the type shown in Figure 7; and

Figure 10 illustrates a novation transaction to record the transaction of Figure 9 on the ledger of record.

Description of Specific Embodiments

Figure 1 illustrates a physical computing architecture suitable for implementing embodiments of the invention. A first computing system 10 comprises a processing capability 101 and memory 102 - while represented as a single unit here and may be implemented as a single server, it may also be implemented as a collection of networked servers and storage apparatus. The first computing system 10 has the capability to perform cryptographic operations and to maintain associated secrets securely - this is represented here by a cryptographic processing capability 103, though in embodiments this functionality may be implemented by the main processing capability 101 and memory 102. The main computing system 10 is adapted to maintain a ledger of record implemented using blockchain technology - as discussed below, in embodiments this may involve maintenance of a plurality of blockchains.

A plurality of other computing systems 20, 30 are shown interacting with main computing 10 over a computing network 40, which may be a private network, a public network such as the public internet, or may be implemented as a combination of the two. Each such computing system has its own processing capability 201 , 301 and memory 202, 302, and may also require cryptographic capability 201. A second type of computing system 20 forms an active part of the blockchain ecosystem - such a system may for example play a role in a blockchain voting mechanism, or may itself maintain blockchains. Where only certain nodes are allowed to perform certain actions, this is termed a

permissioned blockchain (as opposed to a public blockchain in which any node can perform a full node role). In embodiments of the invention, the first computing system 10 and the second computing systems 20 may operate as peers, each maintaining copies of a ledger. A third type of computing system 30 interacts with the main computing system 10 - for example, by submitting transactions for entry on to the ledger, or by inspecting the ledger - but does not itself play an active role in any mechanism that develops the blockchain.

Figure 2 illustrates a logical architecture for providing a ledger of record for recording asset holdings and asset transfers and adapted to implement embodiments of the invention. The (or each) ledger holder 1 maintains a ledger of record using, in this case, a plurality of blockchains 21 - the ledger holder 1 receives transaction details 25 from another party 4 for entry on to a blockchain 21. Determination of a block of a blockchain requires multiple signatories who vote to accept a new block and then sign it - signatory parties 3 are also in communication with the ledger holder 1. As shown, in embodiments of the invention there is provided a signature list 23 for a blockchain 21 in respect of transactions that relate to other blockchains. As will be described below, for transfer of an asset - or management of an asset - to another blockchain 22, witness nodes 5 are also involved. In the arrangement shown, the second blockchain 22 is maintained by another party 2 and the witness nodes 5 are separate entities - however, in other embodiments, the second blockchain 22 and the witness nodes 5 may all be located part of a common computer system with the ledger holder 1. System elements described here are those relevant to the ledger of record held by the ledger holder 1 and comprising blockchains 21 - a different set of witness nodes 5 may be used, say, for transactions between blockchain 22 and other blockchains, and a different set of signatory parties 3 may also be used for establishing blocks in blockchain 22.

Transactions between a first and a second blockchain to allow management of an asset to be moved“off-chain” according to embodiments of the present invention will now be described with reference to Figures 3 to 6. This set of transactions allows an asset represented in a ledger recorded on the first blockchain to be transacted with respect to a ledger recorded on the second blockchain. A worked example to show how this mechanism is used to support an off-chain transaction is then illustrated with reference to Figures 7 to 10. The worked example shows how this transaction is then reconciled with the ledger of record.

A blockchain comprises a plurality of blocks. Each block contains a number of records - in the embodiments discussed below, individual records are

transactions. Individual records will contain sufficient information to constitute a proof of a particular transaction and may involve, for example, digital signatures from parties to the transaction or from parties trusted by them. Transactions may be provided by any party involved in the process to a transaction pool, from which they are then included in a block if they meet requirements for inclusion. When a block is complete, parties with voting privileges in respect of the blockchain vote to determine whether the block can be included. If the block can be included, the block is completed by the normal steps required in a blockchain (such as inclusion of a hash of the preceding block) and signed by the voting parties.

Embodiments of the present invention allow one blockchain to have knowledge of the consensus process of another blockchain so that it can accept the results of this consensus process. This is used to establish a link between blockchains.

The consensus process is extended to the new blockchain by use of additional signatures. In addition to creating signature sets as normal during consensus to establish a new block, a further set of signatures is created designed expressly for consumption by linked chains. This set of signatures is bound to the proposed block.

These second signatures are used to confirm those transactions which the consensus agree are to be passed off-chain, so that when the second chain is presented with a set of transactions and these signatures it can confirm that the transactions that it has been given are individually valid and have been verified by the consensus process of the first chain.

Each blockchain maintains an independent record of the signing power on linked chains and is thus able to verify by itself that consensus has been reached without reference to any additional trusted party.

Prior to establishment of a connection between two blockchains, a trust relationship should be established between them, unless this already exists because of the way that the blockchains have been created (for example, if they use a common protocol and transactions are verified by the same set of nodes). Establishment of such a trust relationship may involve, for example, a setup phase where policies and credentials are authenticated between the blockchains through appropriate nodes.

The first step in the process of actual cross-chain interaction is the establishment of a link between two blockchains. This is illustrated in Figure 3. A transaction (Add_xChain’ )TX 31 is established to give knowledge of a first chain (Chain A)

21 to a second chain (Chain B) 22. The transaction provides Chain B with a snapshot of the block height and the signing powers (as can be seen in the details of the Add xChain transaction 31 ) of Chain A. This forms part of a set of cross-chain data that will be maintained and kept current as part of an overall cross-chain management process.

The application of this to block completion is shown in Figure 4. Should there be cross-chain links defined on any given blockchain in the manner shown in Figure 3, the normal consensus algorithm is supplemented to produce an additional signature set. The new consensus process 40 comprises signing of a proposed block 41 as would be done conventionally, with a signed block hash 41 , but there is also an analysis of the block 41 to determine if there are cross-chain transactions. A list of cross-chain transactions is compiled and this list is separately signed 43 in the process of establishing the block. The signed cross- chain transaction list 43 is thus comprised in a confirmed block 41 in addition to the normal consensus signatures 42.

At this point the original blockchain has been augmented with a new confirmed block but other linked chains have not been augmented with the cross-chain transactions. This process is carried out by the witness nodes 5 that sit between linked block chains. Witness nodes 5 are agents that do not themselves participate in the consensus process of any chain, but which monitor activity in the blockchain network (or environment). When a witness node 5 identifies that a new block has been established in its area of responsibility, it takes that block and derives a package of cross-chain transactions which it then submits as a transaction to other linked blockchains. In this case, a newly confirmed block 51 of Chain A (Height 100 block) is analysed by the witness node which derives a cross-chain package 52 using the signed cross-chain transaction list associated with that block. This is submitted to other linked blockchains - in this case, to the second chain (Chain B) 53 for processing as a transaction in respect of that blockchain.

For inclusion in a block of a further blockchain, the cross-chain package 52 is treated as a normal part of the blockchain consensus process. Even though it is a specialised type of transaction, it is verified and released to the transaction pool for that blockchain for inclusion in the next block.

There is however a difference in the verification process to that used for a conventional transaction. In this case, the cross-chain package transaction is not signed by a single address, but instead relies on the cross-chain signature set created by the originating chain and forwarded by the witness node as a part of the transaction. The verification process comprises three separate elements, as shown in Figure 6. One aspect - indicated (1 ) - is to establish that the cross- chain package does not relate to a block height already processed. In the Figure 6 case, this is correct - the cross-chain package relates to block height 100, wherein the“known blockchain” data relates to block height 99, indicating that this is a new block for consideration. A second aspect - indicated (2) - is to establish that all required transactions are included - this can be done by matching transaction data against the signed cross-chain transaction list. A third aspect - indicated (3) is to ensure that the signatory parties are as expected, which can be done by matching the signatories for the signed cross-chain list against those identified in the“known blockchain” data to establish that the list has been signed by a valid majority on Chain A. Individual signatures will also be checked for validity.

Figures 7 to 10 illustrate how an off-chain transaction can be performed and reconciled using this approach. Figure 7 shows a ledger of record (SETL

Ledger) in which an asset holding is recorded - in this case, the asset is a quantity of 1000 of Asset 1 (this may be 1000 shares, a value of 1000 of a currency unit, or any other commodity - for convenience of reference,“shares” will be used for the remainder of the specification as an example). Here, this represents 1000 shares issued by the Issuer, with 400 shares held by Holder 1 and 600 shares held by Holder 2 - the Issuer, Holder 1 and Holder 2 are all represented by a different address.

Figure 8 shows how this asset holding is transferred to a private ledger. Using the processes described above with reference to Figures 4 to 7, the asset holding is transferred for management on a second ledger, Ledger 2 - this is not the ledger of record, and in this case is a private ledger maintained by a commercial bank. In this process, an inter ledger address is established for each ledger in respect of the other ledger. On Ledger 1 , an interledger address for Ledger 2 is established with a balance of 1000 shares representing the shares transferred to Ledger 2, so Ledger 1 now balances. On Ledger 2, an interledger address for Ledger 1 is established with a negative balance of 1000 shares (mirroring the original position of the Issuer on Ledger 1 ). The holdings of Holder 1 and Holder 2 are unaffected.

Figure 9 shows the transfer of the holding of Holder 2 from Ledger 2 to another ledger, Ledger 3 - in this case, a further commercial ledger. This is therefore an off-chain transaction in respect of the ledger of record, Ledger 1. The

mechanism is the same as previously described, and two new interledger addresses are established - an interledger address for Ledger 3 credited on Ledger 2, and an interledger address for Ledger 2 debited on Ledger 3. The asset balance here is 600 shares, representing only the holding for Holder 2, as only this holding has been transferred to Ledger 3.

At this point, although there are provable records of the transaction, this is not explicitly present on the ledger of record. It is desirable for this to be done so that the ledger of record provides a full record of the asset holding, and this can be done by a novation transaction. This has the further benefit that interledger exposure can be removed.

Such a novation process is illustrated in Figure 10. There are three separate elements to this process, each involving an interaction between two of the three ledgers involved in the process. In respect of Ledger 1 and Ledger 2, the respective holdings associated with the interledger addresses are adjusted from 1000 shares to 400 shares as the 600 share holding of Holder 2 is no longer managed on Ledger 2. In respect of Ledger 1 and Ledger 3, interledger addresses are established in respect of the 600 share holding of Holder 2, with the interledger address of Ledger 1 in respect of Ledger 3 taking an equivalent role to the Issuer on Ledger 3 in respect of the Holder 2 holding. These actions expunge the relationship between Ledger 2 and Ledger 3 in respect of this holding, so the interledger addresses between Ledger 2 and Ledger 3 are no longer required and can be deleted.

After this process, Ledger 1 as the ledger of record now correctly reflects that the holding of Holder 1 is managed through Ledger 2 and the holding of Holder 2 is managed through Ledger 3. Any further transfer can be processed in the same manner.

The skilled person will appreciate that the embodiments described here are exemplary, and that modifications may be made and alternative embodiments provided that fall within the scope of the claims.