WO2019200461A1

WO2019200461A1 - Method and system for performing an action requested by a blockchain

Info

Publication number: WO2019200461A1
Application number: PCT/CA2019/050454
Authority: WO
Inventors: Thomas Thompson
Original assignee: Interbit Ltd.
Priority date: 2018-04-21
Filing date: 2019-04-12
Publication date: 2019-10-24
Also published as: CN110730959A

Abstract

Methods, systems, and techniques for performing an action, or side effect, requested using a blockchain. The blockchain instructs one or more nodes comprising part of the blockchain to perform the action. Performance of the action does not require consensus. Each of the one or more nodes that performs the action returns an interim result. A final result is determined from that interim result. Consensus is then used to add that interim result as a final result to a block on the blockchain.

Description

METHOD AND SYSTEM FOR PERFORMING AN ACTION REQUESTED BY A

BLOCKCHAIN

TECHNICAL FIELD

[0001] The present disclosure is directed at methods, systems, and techniques for performing an action requested by a blockchain.

BACKGROUND

[0002] A blockchain is a database and/or application execution engine that is distributed on computer nodes and that is inherently resistant to corruption and tampering. While initially used for bitcoin, blockchain has applications that extend significantly beyond bitcoin and the financial services industry generally.

SUMMARY

[0003] According to a first aspect, there is provided a method for performing an action requested using a blockchain, the method comprising: using the blockchain to instruct one or more nodes comprising part of the blockchain to perform the action, wherein performance of the action is done without the blockchain achieving consensus; and adding, to a block on the blockchain, a final result of the action performed by the one or more nodes.

[0004] The one or more nodes may comprise a first master node that performs the action and returns the result of the action to the blockchain, wherein the first master node returns an interim result of the action to the blockchain, and may further comprise determining the final result from the interim result.

[0005] The method may further comprise determining, during block formation of the blockchain, whether the master node has returned the interim result. [0006] The master node may return the result as part of a data structure, the data structure may further comprise a digital signature of the master node, a task identifier identifying the action, a chain identifier identifying the blockchain, and a hash of a block of the blockchain that instructed the master node to perform the action. [0007] The method may further comprise determining whether the digital signature, the chain identifier, the task identifier, a format of the result, and a status of the master node are valid; and when the digital signature, the chain identifier, the task identifier, the format of the result, and the status of the master node are all valid, flagging the result as valid. [0008] Determining whether the status of the master node is valid may comprise any one or more of determining whether the master node is capable of generating the result, the master node has an active heartbeat, and the master node remains selected by the first blockchain as the master node.

[0009] The method may further comprise determining whether the master node returns the result within at least one of a set period of time and a set number of blocks since the master node was instructed to perform the action; and accepting the result only when the master node returns the result within the at least one of the set period of time and the set number of blocks.

[0010] The method may further comprise: when the result is not flagged as valid: ignoring the result returned by the first master node; selecting another of the nodes comprising part of the blockchain as a second master node; and instructing the new master node to perform the action.

[0011] The method may further comprise prior to using the blockchain to instruct the master node: receiving from at least two of the nodes comprising part of the blockchain a signal that the at least two of the nodes are to be considered for selection as the first master node; and selecting one of the at least two of the nodes as the first master node. [0012] The one or more nodes may comprise multiple swarm nodes, wherein each of the swarm nodes performs the action and returns an interim result of the action to the blockchain, and the method may further comprise determining the final result as an average of at least some of the interim results returned by the swarm nodes. [0013] The method may further comprise determining, during block formation of the blockchain and for each of the swarm nodes, whether the swarm node has returned the interim result.

[0014] Each of the swarm nodes may return the interim result as part of a data structure, and the data structure may further comprise a digital signature of the swarm node, a task identifier identifying the action, a chain identifier identifying the blockchain, and a hash of a block of the blockchain that instructed the swarm node to perform the action.

[0015] The method may further comprise, for each of the interim results: determining whether the digital signature and a status of the swarm node that returned the interim result is valid; determining whether a format of the interim result is valid; and when the digital signature and the status of the swarm node that returned the interim result, and the format of the interim result are all valid, flagging the interim result as valid.

[0016] Determining whether the status of the swarm node that returned the interim result is valid may comprise any one or more of determining that the swarm node that returned the interim result is capable of generating the result, the swarm node that returned the interim result has an active heartbeat, and the swarm node that returned the interim result remains selected by the first blockchain as a swarm node.

[0017] The method may further comprise for each of the interim results: determining whether the swarm node that returned the interim result returned the interim result within at least one of a set period of time and a set number of blocks since the swarm node that returned the interim result was instructed to perform the action; and accepting the interim result only when the swarm node that returned the interim result returns the interim result within the at least one of the set period of time and the set number of blocks. [0018] The method may further comprise, excluding each of the interim results not flagged as valid from the average.

[0019] The method may further comprise, prior to using the blockchain to instruct the swarm nodes: receiving from multiple nodes comprising part of the blockchain a signal that the at least two of the nodes are to be considered for selection as the swarm nodes; and selecting at least two of the nodes as the swarm nodes.

[0020] The action may comprise a first action requiring a first set of resources and a second action requiring a second set of resources different from the first set of resources, the one or more nodes may comprise a first node qualified to perform the first action and a second node qualified to perform the second action, using the blockchain to instruct the one or more nodes may comprise instructing the first node to perform the first action and instructing the second node to perform the second action, and the final result may comprise a first final result determined from a first interim result returned by the first node and a second interim result returned by the second node.

[0021] The blockchain may instruct the first node to perform the first action at a first block height of the blockchain, and may instruct the second node to perform the second action at a second block height of the blockchain that differs from the first block height.

[0022] According to another aspect, there is provided a system for performing an action requested using a blockchain, the system comprising a first node comprising part of the blockchain, the first node comprising: network interface hardware for interfacing with at least one other node that performs the action; a data store having stored on it the blockchain; a processor communicatively coupled to the data store and network interface hardware; and a memory communicatively coupled to the processor and having stored on it computer program code that is executable by the processor and that when executed by the processor causes the processor to perform the method of any of the foregoing aspects or suitable combinations thereof. [0023] According to another aspect, there is provided a non-transitory computer readable medium have stored thereon computer program code that is executable by a processor and that when executed by the processor causes the processor to perform the method of any of the foregoing aspects or suitable combinations thereof. [0024] This summary does not necessarily describe the entire scope of all aspects.

Other aspects, features and advantages will be apparent to those of ordinary skill in the art upon review of the following description of specific embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In the accompanying drawings, which illustrate one or more example embodiments:

[0026] FIG. 1 depicts a system for facilitating data transfer between blockchains, according to one example embodiment.

[0027] FIG. 2 depicts a software stack comprising part of the system of FIG. 1.

[0028] FIG. 3 depicts a physical network topology for the system of FIG. 1. [0029] FIG. 4 depicts a flow diagram showing performance of an action to affect system state using a reducer and consensus being achieved for a blockchain, according to the system of FIG. 1.

[0030] FIGS. 5A and 5B depict a UML sequence diagram showing how two blockchains perform a readjoin, according to the system of FIG. 1. [0031] FIG. 6 depicts a block diagram showing how two blockchains perform a write join, according to the system of FIG. 1.

[0032] FIGS. 7A to 7C depict a UML sequence diagram showing how two blockchains perform a write join, according to the block diagram of FIG. 6. [0033] FIG. 8A depicts a system for facilitating data transfer between blockchains, according to another example embodiment.

[0034] FIG. 8B depicts a block diagram of a hypervisor and the various blockchains running thereon, according to the system of FIG. 8 A. [0035] FIGS. 9 and 10 depict methods for performing an action requested using a blockchain, according to additional example embodiments.

DETAILED DESCRIPTION

[0036] A blockchain’ s physical layer comprises computer nodes on which is collectively stored a distributed database. The database is stored as a generally linear chain of“blocks”, with each subsequent block in the chain directly linked in a cryptographically secure manner to the immediately preceding block in the chain. New blocks added to the blockchain are referred to as being“higher” in the blockchain than the blocks added to the blockchain prior to it. The first, or lowest, block in the blockchain is referred to as the “genesis block”. Because each block in the blockchain is directly linked to its immediately preceding block, any block in the blockchain can, directly or indirectly, be traced back to the genesis block. This is one way in which any one of the nodes can check the validity of the blockchain.

[0037] A blockchain can be implemented in a variety of ways. In one example implementation of blockchain used for bitcoin, each block of a blockchain comprises that block’s size, in bytes; a block header; a transaction counter, representing the number of different bitcoin transactions stored in that block; and transaction data, which are the stored transactions. In the same example implementation, the block header for each block comprises version information; a previous block hash, which is a reference to the hash of the block immediately preceding that block; a Merkle root, which is a hash of the Merkle tree root of the transactions stored in that block; a timestamp, which is when the block was created; a difficulty target, which is the minimum difficulty that had to be satisfied when perfonning a proof-of-work operation during block creation; and a nonce, resulting from the proof-of-work.

[0038] In a conventional blockchain implementation, different nodes comprising part of the blockchain compete to generate new blocks by performing a proof-of-work operation that satisfies at least the difficulty target specified in each of the new blocks’ headers. Once generated, a new block is disseminated to, and its authenticity is independently verified by, other nodes in the blockchain by using the previous block hash (to confirm that new block’s lineage) and Merkle root (to confirm the validity of the transactions stored in that new block). Once a new block has been verified, it is added to the top of the blockchain. The blockchain at any given time is typically the chain having blocks resulting from the highest possible cumulative proof-of-work. The nodes are said to have arrived at“consensus” when they agree as to which block is to be added to the top of the blockchain. While the blockchain may fork from time-to-time, resulting in temporarily competing versions of the blockchain, the fact that each block is cryptographically linked to its immediately preceding block means that blocks far from the top of the blockchain are, for practical purposes, immutable.

[0039] The distributed and peer-to-peer nature of blockchain described above is also associated with some drawbacks. For example, a byproduct of blockchain’ s distributed nature is that all nodes comprising part of a blockchain have access to all the data stored on that blockchain, making privacy protection difficult. While certain non-header data on a blockchain may be encrypted, encryption introduces technical overhead and also inhibits what can be done, such as implementing applications as smart contracts, with the data. Furthermore, as a single node scales and is concurrently a node for an increasing number of blockchains, the computational resources required of that node also scale upwards linearly, impeding the ability of that node to efficiently be a member of a high number of blockchains.

[0040] The embodiments described herein are described at methods, systems, and techniques to mitigate at least one of the foregoing problems. For example, in at least some of the embodiments described below data may be securely shared between blockchains by a process referred to herein as“chain joining”. Using joining, a first blockchain may securely share with a second blockchain a proper subset of non-header data stored on the first blockchain; this is in contrast to being forced to share all of the data stored on the first blockchain, as is required between all the nodes comprising the first blockchain. In at least one of the depicted embodiments herein, the non-header data replaces the transaction data stored on a blockchain when the blockchain is used to implement bitcoin. For example, in at least some of the example embodiments, the non-header data comprises an action that is performed by an application implemented as a smart contract also stored on the blockchain, and data representing the resulting application state that follows from performing that action. Each action in the embodiments depicted herein comprises a JSON object, although in different embodiments an action may comprise a different data structure. Sending, from a first blockchain, the application state data and the action whose performance by the first blockchain results in the application state allows a second blockchain to independently determine whether the state it receives from the first blockchain is accurate.

[0041] In at least some example embodiments, the non-header data of a blockchain comprises application data, which is data related to an application stored in the blockchain, such as the applications itself or application state data. For example, in an application configured to store a list of contacts, application state data may comprise a list of those contacts, and a proper subset of application state data may comprise a single entry in that list. In some other example embodiments, the non-header data may not be related to any particular application may comprise a JSON object or binary files.

[0042] Furthermore, in at least some of the embodiments described below any one or more nodes may use a hypervisor to virtualize (either fully or using paravirtualization) one or more blockchains while routing system operations through a host controller running on each of those one or more nodes. The host controller may itself be a blockchain (“host blockchain”). The host controller allocates at least some hardware resources of the node on which it runs in response to requests from one or more blockchains running on the hypervisor; each of those chains is referred to interchangeably herein as a“guest blockchain”. The host controller performs resource allocation based on, for example, resource availability and task priority. This permits the different blockchains to efficiently share that node’s hardware resources, thereby facilitating scaling. Furthermore, in embodiments comprising the host blockchain, the computer program code for at least one of the guest blockchains may be stored in the host blockchain. This permits the host blockchain to store a list of all of those guest blockchains’ application state changes, thereby permitting a user to easily to change the state of those applications to any previous state stored in the host blockchain. This may in particular be useful for at least one of debugging and auditing the activities of that node. In embodiments comprising the host blockchain, one or more of the guest blockchains may be stored in the host blockchain, while a different one or more of the guest blockchains may be stored outside of the host blockchain; all guest blockchains may nonetheless have resources allocated for them by the host blockchain, thereby facilitating scalability. [0043] Referring now to FIG. 1, there is shown a system 100 for facilitating data transfer between blockchains, according to one example embodiment. The system 100 comprises first through twelfth nodes l04a-l (generally,“nodes 104”), each of which comprises part of one or more blockchains l02a-g (generally,“blockchains” or“chains” 102). A first blockchain l02a comprises the first through fourth nodes l04a-d; a second blockchain l02b comprises the fifth through eighth nodes l04e-h; and a third blockchain comprises the ninth through twelfth nodes 104Ϊ-1.

[0044] As discussed in further detail below, the first blockchain l02a is“joined” to a fourth blockchain l02d (via the second node l04b) and to a fifth blockchain l02e (via the third node l04c): this permits all or some of the data stored on the first blockchain l02a to be securely shared with the fourth and fifth blockchains l02d,e, respectively. The second blockchain l02b is analogously joined to the fourth blockchain l02e (via the sixth node l04f) and the sixth blockchain l02f (via the seventh node 104g), and the third blockchain l02c is analogously joined to the sixth blockchain l02f (via the tenth node l04j) and the fifth blockchain l02e (via the eleventh node 104k).

[0045] Also as discussed in further detail below, as the fourth blockchain l02d is joined to the first and second blockchains l02a,b, the first and second blockchains l02a,b may read and write data from and to each other via the fourth blockchain l02d. Analogously, the second and third blockchains l02b,c may read and write data from and to each other via the sixth blockchain l02f, and the first and third blockchains l02a,c may read and write data from and to each other via the fifth blockchain 102e. The fourth through sixth blockchains l02d-f are accordingly interchangeably referred to herein as“transfer blockchains” as they facilitate the selective transfer of data between the first through third blockchains l02a-c.

[0046] The eighth blockchain l02g in the system 100 is a“directory blockchain” on which is stored data to be freely accessible by the first through third blockchains l02a- c. [0047] While in a conventional bitcoin implementation, generating new blocks comprises applying a proof-of-work, in the depicted embodiments consensus is achieved without applying proof-of-work. For example, the depicted embodiments herein, consensus is determined in accordance with the method as described in the thesis of Ethan Buchman, June 2016, University of Guelph, https://atrium.lib.uoguelph.ca/xmlui/handle/l02l4/9769. In different embodiments (not depicted), consensus may be determined using proof-of-work, proof-of-stake, or a different method.

[0048] The structure of the second node l04b is highlighted in FIG. 1. The other nodes l04a,c-l in the system 100 share analogous structures, although in different embodiments (not depicted) any one or more of the nodes 104 may differ in structure from each other. [0049] Referring now to FIG. 3, there is shown a physical network topology for the system 100 of FIG. 1. The system 100 comprises first through third local area networks (“LANs”) 306a-c, each protected by a respective firewall 304a-c. The LANs 306a-c are communicatively coupled together via a wide area network (“WAN”) 302, such as the Internet. The first through third blockchains l02a-c are respectively local to the first through third LANs 306a-c; each of the fourth through seventh blockchains l02d-g communicate through at least two of the firewalls 304a-c and the WAN 302.

[0050] Referring back to FIG. 1, the second node l04b comprises a processor 106 that controls the node’s l04b overall operation. The processor 106 is communicatively coupled to and controls several subsystems. These subsystems comprise user input devices 108, which may comprise, for example, any one or more of a keyboard, mouse, touch screen, voice control; random access memory (“RAM”) 110, which stores computer program code for execution at runtime by the processor 106; non-volatile storage 112, which stores the computer program code executed by the RAM 110 at runtime and which also stores the blockchains l02a,d of which the second node l04b is a part, as discussed in further detail in respect of FIG. 2; a display controller 114, which is communicatively coupled to and controls a display 116; and a network controller 118, which facilitates network communications with the other nodes l04a,c-l.

[0051] Referring now to FIG. 2, there is shown a software stack 200 comprising part of the system 100 of FIG. 1. The software stack 200 may be expressed as computer program code and stored in the non-volatile storage 112, and the processor 106 may load some or all of that computer program code into the RAM 110 as desired at runtime. The software stack 200 is based on Node.js and accordingly uses JavaScript 202 and, in particular, the JavaScript Express 204, Redux 206, and React 208 libraries. JavaScript 202 is used to implement the blockchain. JavaScript Express 204, Redux 206, React 208, and HTML and CSS 210 are used as a framework for application development. While JavaScript 202 and its associated libraries 204,206,208 are used in this example embodiment, in different example embodiments (not depicted) any one or more of them may not be used for implementation. For example, in certain different embodiments, even if none of the JavaScript Express 204, Redux 206, and React 208 libraries are used, application state may still be tracked using a cryptographically verifiable JSON object.

[0052] An application is run as a smart contract on any one of the blockchains 102 in the system 100. FIG. 4 depicts a flow diagram 400 showing performance of an action by the system 100 to affect system state using a reducer and consensus being achieved for any one of the blockchains 102 by applying consensus as described above, according to the system 100 of FIG. 1. In the system 100, a Redux 206 store stores the application’s state tree and accordingly is analogous to RAM for the application. An action is created in the user space at block 402, for example in response to user input via one of the user input devices 108, and is dispatched using an asynchronous variant of Redux’s 206 dispatch() method at block 404 to the blockchain fabric (i.e., automatically to the other nodes 104 comprising the blockchain 102 by virtue of blockchain’ s peer-to-peer nature). The action transitions from the user space to the blockchain fabric at block 406 and propagates through the nodes 104 comprising the blockchain 102 at block 408. Each of the nodes 104 of the blockchain 102 consequently eventually receives a copy of the action at block 410, and each of the nodes 104 independently evaluates the effect of that action on the current state of the application, which it retrieves at block 412, by performing the action with a reducer at block 414. Once the node 104 performs the action at block 414, the blockchain 102 achieves consensus at block 416 as to the blockchain’ s 102 next state. The next state that results from that consensus is accepted by the nodes 104 as the correct next state at block 418, and is sent to the user space at block 420.

[0053] FIG. 8 A depicts another example embodiment of the system 100 for facilitating data transfer between blockchains 102. The system 100 of FIG. 8 A comprises a thirteenth node l04m, which is concurrently a member of six blockchains l02h-m: a host blockchain l02h, and eighth through twelfth blockchains l02i-m. The eighth through twelfth blockchains l02i-m also respectively comprise additional nodes l04n-r. Each of the blockchains l02h-m is paravirtualized on the thirteenth node l04m, although in different embodiments (not depicted) the blockchains l02h-m may be fully virtualized or, as discussed in further detail below, neither fully virtualized nor paravirtualized. FIG. 8B depicts a hypervisor 800 used for that paravirtualization, and shows the blockchains l02h- m running on the hypervisor 800. [0054] In FIG. 8B, the eighth, eleventh, and twelfth blockchains l02i,l,m are nested within the host blockchain l02h, and the ninth and tenth blockchains l02j,k are nested within the eighth blockchain l02i (and consequently also within the host blockchain l02h). One blockchain 102 is“nested” within another blockchain 102 (the“parent blockchain 102”) when the parent blockchain 102 executes an application to create the nested blockchain 102, and when the parent blockchain 102 accordingly can terminate the nested blockchain 102. In the depicted embodiment, the parent and nested blockchains 102 are otherwise equivalent.

[0055] The hypervisor 800 interfaces with the physical world 804 via computer hardware responsible for input/output operations (“I/O hardware”), such as the user input devices 108 that provide user input to the hypervisor 800, and disk access and network interface hardware 808 that perform disk access and network communication functions. The hardware 808 interfaces with various third party components 806 such as servers that provide external services, application programming interfaces, and databases.

[0056] The hypervisor 800 is implemented in JavaScript 202 and comprises an action queue 816, a router 818, and various operating environments for the blockchains l02h-m. The router 818 is communicatively coupled to first through sixth dispatch modules 820a-f in series, and the first through sixth dispatch modules 820a-f are in turn communicatively coupled to the blockchains l02h-m, respectively. The blockchains l02h- m each respectively comprises a store 8l2a-f for an application, with each store 8l2a-f effectively acting as RAM for an application on that blockchain l02h-m. In at least some example embodiments, an application stored on the blockchain comprises more than a smart contract. For example, an application may comprise a smart contract, which represents a function that returns a value; a saga, which performs actions other than returning a value, such as interactions with hardware; and the actions that interact with the smart contract and the saga. The actions that the saga performs, which are requested using the blockchain and the actual performance of which are performed without the blockchain achieving consensus, are herein referred to as“side effects”. While the actual performance of the side effect or action is not subject to consensus, the determination made by the blockchain to perform the side effect is subject to consensus, and the determination made by the blockchain to accept the result of the side effect is also subject to consensus. Each of the applications in the stores 8l2a-f comprises a reducer that performs actions to determine blockchain state. Additionally, side effects, such as interactions between a blockchain 102 and hardware, that may result from the reducer performing that action are handled by side effect managers 8l4a-f for the stores 8l2a-f, respectively.

[0057] In one example embodiment, the method of FIG. 4 may be implemented using the hypervisor 800 of FIG. 8B, as follows. A user who creates an action by providing input via one of the user devices 108 generates an action at block 402, which is placed in the action queue 816. The action queue 816 also receives actions from the side effect managers 8l4a-f. The action queue 816 eventually dispatches the user generated action to the router 818, which routes it to the blockchains l02i-m relevant to that action; for the purposes of this example, the eighth blockchain l02i is the only blockchain 102 affected by the action. The router 818 routes the action directly to the third dispatch module 820c. This corresponds to block 406 in FIG. 4. The host blockchain l02h captures the action as soon as it is converted from hardware to an action; the I/O hardware (whether the user input device 108 or hardware 808) interacts with the host blockchain l02h and the action is consequently recorded in the host blockchain l02h before the action is even sent to the action queue 816. The router 818 routes actions in the action queue 816 to the appropriate dispatch module 8l2a-f. The router 818 sends actions to any given one of the chains l02i- m in the order in which those actions are placed in the action queue 816; however actions for different blockchains l02i-m may be sent to the dispatch modules 8l2a-f for those blockchains l02i-m out of order. For example, if the action queue 816 receives a first action for the eighth blockchain l02i, then a second action for the ninth blockchain l02j, and then a third action again for the eighth blockchain l02i, the router 818 may send the first and third actions to the eighth blockchain l02i before sending the second action to the ninth blockchain l02j . However, the router may not send the third action to the eighth blockchain l02i before the first action. [0058] Once the action arrives at the eighth blockchain l02i, the thirteenth node l04m broadcasts the action to any other nodes 104 comprising part of that blockchain l02i, which as shown in FIG. 8 A comprises the additional node 104h; this corresponds to blocks 408 and 410 in FIG. 4. The thirteenth node l04m communicates via the host blockchain l02h, which interfaces with the disk access and network interface hardware 808 as necessary to communicate with that additional node 104h. The additional node 104h eventually receives and performs the action at its reducer at block 414. Back at the thirteenth node l04m, the reducer comprising part of the second store 8l2b performs the action, and again via the host blockchain l02h shares the new state it determines to the additional node 104h. The eighth blockchain l02i eventually reaches consensus, which corresponds to block 416 of FIG. 4, with communication involving the node l04m on which the hypervisor 800 runs occurring again via the host blockchain l02h. Once consensus is reached, the eighth blockchain l02i settles on its new state at block 418, and relays this new state to the user again via the host blockchain l02h via the user input hardware 108, which corresponds to block 420. [0059] A side effect in the form of a hardware operation may be required when a reducer performs an action. Any hardware operation is performed by the hypervisor 800 in response to an instruction from the host blockchain l08h; the host blockchain l08h consequently is aware of and records all hardware operations and related actions in its blocks. The host blockchain l08h also records the result of performing that action, which is the new application state for the blockchain 102 that received the action. Each blockchain 108 also returns a“success” or“failure” indicator after an action is performed, indicating whether the action was successfully performed, which the host blockchain l08h also records. [0060] In the depicted example embodiment, the host blockchain l08h also monitors and handles resource allocation for compute operations (operations that do not use the I/O hardware but that do require the node’s l04m processor) that satisfy at least one of a processor time and processor intensity threshold. This permits the host blockchain l08h to allocate and store processor resources for particularly computationally intensive tasks, such as certain cryptographic tasks.

[0061] While in FIGS. 8A and 8B the thirteenth node l04m is described as communicating with the additional nodes l04n-r via the disk access and network interface hardware 808, in different embodiments (not depicted) communication may be between blockchains 102 that are hosted on the same node 104 and even running on the same hypervisor 800. In those example embodiments, communication between blockchains 102 can be done with lower latency and a lower transmission time than when communication need be done through the hardware 808.

[0062] The applications on the blockchains l02h-m are configured such that all hardware interactions with any of the blockchains l02i-m occur via the host blockchain l02h. For example, all network communications, which occur via the disk access and network interface hardware 808, and user interactions, which occur via the user input devices 108, are performed by the eighth through twelfth blockchains l02i-m via the host blockchain l02h. The host blockchain l08h accordingly is configured to interact with all hardware as instructed by any of the blockchains l08i-m nested therein. The host blockchain l02h records in its blocks all hardware operations (requests and responses, and user inputs conveyed via hardware) and application states of the applications running on each of those nested blockchains l02i-m. In some different embodiments (not depicted), the host blockchain l02h may record some and not all of the operations involving the I/O hardware. The host blockchain l02h also records all actions that are routed to the blockchains l02i-m at least by virtue of those actions being routed through the router 818 and, if those actions require I/O hardware usage, by virtue of that as well. This permits a user access to the entire state history and hardware operations of all of those nested blockchains l02i-m. That user accordingly is able to revert to a previous application state of any of the blockchains l02i-m and adjust the order of actions in the action queue 816 to simulate how the hypervisor 800 and blockchains l02i-m would have reacted had the actions arrived in a different order than the original order they were in fact received; in one example use case, this is done when an application throws a fault. This permits the system 100 to be thoroughly tested by virtue of allowing simulation of different timing errors that the system 100 may experience. The blocks of each of the nested blockchains l02i-m for a subset of the data contained within the blocks of the host blockchain l02h. During debugging or testing, a user may select any action from the action queue 816 for routing to the blockchains 102i-m via the router 818, regardless of the order in which the action queue

818 received the actions. The input/output operations are made to be procedural and deterministic; consequently, the hardware responds to an action in the same manner regardless of when it receives that action, which facilitates changing the order of actions during debugging or testing. [0063] Another node may connect to the host blockchain l08h, and the reverting of the application to an earlier state may be done in response to input from that other node. This other node may, for example, be that of a third provider providing technical support.

[0064] While the depicted example embodiment shows the blockchains l02h-m as paravirtualized on the hypervisor 800, in different embodiments (not depicted) neither fully virtualization nor paravirtualization need be used. In some of those different embodiments, some of the nodes 104 fully virtualize or paravirtualize the blockchains l02h-m using the hypervisor 800 while others do not. Additionally, in some of those different embodiments in which at least one of the nodes 104 uses the hypervisor 800 for fully virtualization or paravirtualization, some or all of the blockchains l02h-m may be fully virtualized or paravirtualized. For example, while the flow diagram 400 of FIG. 4 may be implemented using the hypervisor 800 of FIG. 8B, in different embodiments (not depicted) virtualization need not be used for its implementation.

Chain Joining [0065] While all of the nodes 104 on any given one of the blockchains 102 have access to all the data stored on the blockchain 102, different blockchains 102 do not by default share data between each other. The method of chain joining, described below, permits data to be shared between different blockchains 102. [0066] FIGS. 5A and 5B depict a UML sequence diagram 500 showing how two blockchains l02a,b perform a readjoin, according to the system 100 of FIG. 1. While the first and second blockchains l02a,b are used in the diagram 500, a read join may be performed between any two blockchains 102. For example, while the first and second blockchains l02a,b do not share any nodes 104, a read join may be performed between blockchains 102 that share nodes 104 and, in some example embodiments, that are virtualized (fully or paravirtualized) on at least some of the same nodes 104 using, for example, the hypervisor 800.

[0067] In the diagram 500, the second blockchain l02b reads data from the first blockchain l02a; for the purposes of the diagram 500, the second blockchain l02b is accordingly interchangeably referred to as the“consumer chain l02b” and the first blockchain is accordingly interchangeably referred to as the“provider chain l02a”.

[0068] At operation 502, the provider chain l02a updates its join management routine. A user commences this by providing input via one of the user input devices 108 of one of the nodes l04a-d comprising the provider chain l02a. The user input is dispatched as an action (“@@CHAIN_SHARE_STATE”) by the router 818 to the provider chain l02a on that node 104 for performance by that chain’s l02a reducer. The action’s payload is digitally signed so that it is cryptographically verifiable (i.e., any tampering can be detected). The action’s payload comprises a chain identifier of the consumer chain l02b (“<chainID>”), a path identifying the proper subset of the state data of the provider chain l02a to be read by the consumer chain l02b (“statePath: 7foo/’”), and an alias identifying this particular chain join (“joinName:‘fooJoin’”). In the diagram 500, the state information available to the provider chain l02a is represented using a directory tree. The root of the tree having path

represents all the state data available to the provider chain l02a; and subdirectories, such as“/foo /”, represent a proper subset or“slice” of that state data.

[0069] The chain identifier is unique and is generating by digitally signing a value comprising the provider chain’s l02a genesis block modified to contain a random seed. The random seed ensures uniqueness. At any time during the read join, the provider chain l02a may confirm the identity of the consumer chain l02b using the chain identifier and only send the slice of state data to the consumer chain l02b when the attempt to confirm that identity is successful.

[0070] At operation 504, the same or a different user provides input via one of the user input devices 108 of one of the nodes l04e-h comprising the consumer chain l02b. The user input is dispatched as an action (“@@CHAIN_READ_STATE”) by the router 818 to the consumer chain l02b on that node 104 for performance by that chain’s l02b reducer. The action’s payload is a cryptographically secure chain identifier of the provider chain l02a (“<chain ID>”), a path identifying where the state data is to be stored (“mount: Vmnt/foo’”, with the state data that is read by the consumer chain l02b is stored using the model of a mounted filesystem), an alias identifying this particular chain join (“joinName: ‘fooJoin’”), and various options for the read join. Example options comprise a data age limit, which requires data being transmitted via the read join to be less than a certain age to be usable for all or some actions; a frequency threshold, which defines how quickly the readjoin is to repeat to update the state data on the consumer chain l02b; and a maximum size limit, which sets a flag if the data transmitted by the read join exceeds a maximum limit.

[0071] Once operations 502 and 504 have been performed, the read join is initialized. Operations 502 and 504 may be performed concurrently or one of the operations 502,504 may be performed before the other of the operations 502,504.

[0072] Once the read join is initialized, the provider chain l02a enters into a loop comprising operations 506 and 508 that it performs for each block on the chain l02a. An action (“@@CHAIN_BLOCK_CREATED”) is generated each time a new block is added to the provider chain l02a. New block creation comprises the provider chain l02a application deciding to create a block, which triggers a side effect, which when the hypervisor 800 is used is handled by the side effect manager 814. The action’s payload is the block height for that new block (“currentBlockHeight: 1234”), the hash of that new block’s header (“currentBlockHash: blockl234Hash”), and a timestamp identifying when that block was created (“currentBlockTime: 12374433543”). In some example embodiments, the timestamp is omitted. At operation 508, the provider chain l02a sends an update in the form of the @@CHAIN_BLOCK_CREATED action to the consumer chain l02b, notifying the consumer chain l02b that a new block has been created. The update comprises the height and header hash of that new block. The consumer chain l02b may choose to accept and receive a copy of the slice of the state data stored by the newly created block, or skip the update.

[0073] When the consumer chain l02b chooses to receive an update from the provider chain l02a, operations 510, 512, 514, and 516 are performed for each update. At block 510, the consumer chain l02b generates an action (“@@READ_JOIN_DIFF_REQ”) having a payload of the starting block height of the provider chain l02a for which the data transfer is to begin (“startBlockHeight: 1200”), which the consumer chain l02b knows from operation 504 (the last time it was set) and which the consumer chain l02b will update at operation 516 as discussed below; a hash of the header of the block at the starting block height (not shown in FIG. 5B) and the alias for the join (“joinNames: [fooJoin]”). At operation 512, the consumer chain l02b requests the updated slice of state data from the provider chain l02a by sending the @@READ_JOIN_DIF_REQ action to the provider chain l02a. [0074] In response to the request, the provider chain l02a performs an action

(“@@READ_JOIN_DIFF_RESP”) to generate the response to the request. In response to the action, the provider chain l02a retrieves a header for each of the blocks (regardless of whether a slice of state data is sent from that block, as the headers are used to verify lineage) (blocks 1200 to 1234). Each header comprises a hash of the header of the immediately preceding block in the chain l02a (“previousBlockHash:‘blockl l99Hash’”); a hash of that block’ s entre application state, even though only a slice of that state data is to be transmitted (“payloadHash:‘payloadHash’”); a sufficient number of digital signatures of the nodes of the first blockchain to establish that consensus was reached for that block; and a flag indicating whether an aspect of the chain configuration has changed (i.e., when an aspect that affects the ability to verify block lineage changes), such as when an encryption method (e.g., the type of hash) has changed, when the list of nodes that is entitled to vote for consensus changes, when the digital signature(s) used changes, and when header format changes (“configChanged: false”). The action also generates a hash of the block header (“blockHash:‘ block l200Elash”), which does not comprise part of the header itself. The chain l02a also determines a difference in the state data from the starting block height (1200) to the current block height (1234) (“stateDiff: {//Provider creates diff from 1200 to 1234}”), so as to avoid sending unnecessary data to the consumer chain l02b. The provider chain l02a also determines a Merkle proof (“merkleProof’), which comprises one or more hash values selected to permit the consumer chain l02b to determine a Merkle path from a hash of the application data sent to the second blockchain to a Merkle root, which in this example is in the payloadHash field. The provider chain l02a sends the data generated in response to the @@READ_JOIN_DIFF_RESP action to the consumer chain l02b at operation 514.

[0075] In this example embodiment, the hash of the application data is a Merkle root and comprises all actions used to make the block and the last state resulting from the application performing all of those actions in order. In a different example embodiment, the block may store each state that results from performing each of the actions, or a subset of those states. For each block being transmitted, the hash of that block and of the header of a block immediately below that block, the hash of that block’s application data, and the hash of the digital signatures collectively represent one example of lineage verification data that the consumer chain l02b may use to verify the lineage of that block back to the genesis block of the chain. [0076] In this example embodiment, the merkleProof field is one example of validity verification data, which permits the consumer chain l02b to verify validity of the application data it receives from the provider chain l02a. While Merkle trees are used in this example, Merkle trees are only one example form of cryptographic proof. Other possible ways exist. The proof mechanism allows a single root hash, and a series of other hashes used in some structure, to allow verification of a piece of data by relating it back to the root hash without disclosing any of the other data that was not intended to be shared. Other data structures that may be used, for example, comprise Patricia Trees, Radix Trees, and chunked concatenations. [0077] The consumer chain l02b subsequently verifies the authenticity of the data it receives at operation 516. More specifically, it verifies the transmitted block’s lineage using the lineage verification data, the validity of the proper subset of state data it received using the validity verification data, and adds a new block to the consumer chain l02b. More specifically, the consumer chain l02b verifies the provider chain’s l02a digital signature; verifies each transmitted block’s lineage using the hashed header information; checks the validity of the transmitted state data using the data’s Merkle tree; verifies the type of consensus method used, which may be changed using the configChange field as described above; verifies that a sufficient number of nodes 104 have contributed to the consensus of the block by checking the signatures of the nodes that voted in favor of consensus; and verifies the cryptographic validity of the block in accordance with the cryptographic method used by the chain l02a.

[0078] The consumer chain l02b then updates the mounted directory where it stores state information (/mnt/foo), which itself comprises the consumer chain l02b adding a new block to itself with the non-header data of that new block comprising the data received from the provider chain l02a (i.e., the lineage verification data, proper subset of state data, and validity verification data). [0079] In summary, the readjoin permits a user of the consumer chain l02b to read a slice of state data stored on the provider chain l02a as though that data were mounted locally on the consumer chain l02b.

[0080] Referring now to FIG. 6, there is depicted a block diagram 600 showing how two blockchains perform a write join, according to the system 100 of FIG. 1. As with FIGS. 5 A and 5B, while the first and second blockchains l02a,b are used in the example of FIG. 6, a write join may be performed between any two blockchains 102 regardless of whether they have overlapping nodes 104 and regardless of whether any nodes are virtualizing chains using the hypervisor 800. In FIG. 6, the first blockchain l02a writes data to the second blockchain l02b; the first blockchain l02a is accordingly interchangeably referred to as the“sender chain” l02a and the second blockchain l02b is accordingly interchangeably referred to as the“receiver chain” l02b.

[0081] The sender chain l02a comprises a dispatch module 802a, which dispatches actions to a reducer 602a. As discussed in further detail below in respect of FIGS. 7A to 7C, the reducer 602a delegates performance of certain actions to a join manager 604b, which controls which actions are queued in a pending actions queue 606a for transmission to the receiver chain l02b. The actions are sent to the receiver chain l02b via a read join. The sender chain l02a also comprises an action status queue 608a that reads, via a read join, a list of which actions have been completed by the receiver chain l02b. [0082] The receiver chain l02b analogously comprises a pending actions queue

606b that receives the actions via the read join from the sender chain’s l02a pending actions queue 606a. The received actions are sent to a join manager 604b, which forwards them to a dispatch module 820b and updates an action status queue 608b to indicate that the action is pending. The dispatch module 820b forwards those actions to a reducer 602b, which performs them, thereby changing the receiver chain’ s 102b state data and performing a write operation. The join manager 604b also, after the reducer 602b performs the action, updates the action status queue 608b to indicate that the action has been completed. The statuses in the action status queue 608b are sent to the sender chain’s l02a action status queue via a readjoin. The write join of FIG. 6 accordingly is implemented using two read joins.

[0083] FIGS. 7A to 7C depict a UML sequence diagram 700 showing how two blockchains l02a,b perform a write join, according to the block diagram 600 system of FIG. 6. The objects in the diagram are the sender and receiver chains l02a,b, the sender chain’s 102b join manager 604a, and the receiver chain’s l02b join manager 604b. While the join managers 604a, b are shown as being objects distinct from the chains l02a,b, this is done for convenience only and the managers 604a, b comprise part of the application logic performed by the chains l02a,b. [0084] At operation 702, the receiver chain’s 102b join manager 604b performs an action (“@@CHAIN_AUTHORIZE_ACTIONS”) having a payload comprising a cryptographically secure chain identifier identifying the sender chain l02a (“sender: <senderChainID>”) and enumerating the actions that the sender chain l02a is permitted to have the receiver chain l02b perform (“permittedActions: [‘CREATE FOO’; ‘CREATE BAR’]”). The cryptographically secure chain identifier is generated in a manner analogous to the chain identifiers for FIG. 5 A. Following this, the receiver chain’s l02b pending actions queue 606b is able to read actions from the sender chain’s l02a pending actions queue 606a, and the sender chain’s l02a action status queue 608a is able to read the status of actions from the receiver chain’s l02b action status queue 608b. After the queues 606a, b and 608a, b are able to communicate, the write join is setup. In the depicted embodiment, the sender chain l02a is by default authorized to perform certain actions received from the receiver chain l02b, so authorization is not explicitly shown in FIGS. 7 A to 7C.

[0085] For each action the sender chain l02a wishes to send to the receiver chain 102, the sender chain l02a performs operations 704 and 706. For each action, the sender chain l02a creates an action of one of the permitted enumerated types (“type: ‘CREATE FOO’”). The action created by the reducer 602a may or may not be identical to the action that was dispatched to it. The reducer 602a then delegates the action at operation 704 to the join manager 604a, following which the join manager 604a generates an identifier for that action and places it in the pending actions queue 606a at operation 706. That action is transmitted, via a read join, from the sender chain’s l02a pending actions queue 606a to the receiver chain’s l02b pending actions queue 606b at operation 708.

[0086] In order to make efficient use of the overhead accompanying each readjoin, such as that required for cryptographic checks and consensus, multiple actions may be queued in the sender chain’s l02a pending actions queue 606a and transmitted via a single read join.

[0087] For each action that the receiver chain l02b receives, it performs operations

710, 711, 712, 714, and 716. At operation 710, the receiver chain’s l02b join manager 604b removes the pending action from the pending actions queue 606b, dispatches the action to the reducer 602b at operation 711, and updates the action status queue 608b to indicate that the action is in process. The reducer 602b performs the action, informs the join manager 604b at operation 714, and the join manager 604b updates the action status queue 608b to indicate that the action is completed at operation 716.

[0088] At operation 717, the sender chain’s l02a action status queue 608a is updated to correspond to the receiver chain’s l02b action status queue 608b via a readjoin.

[0089] For each updated action status, the sender chain l02a performs operations

718, 720, and 722. At operation 718, the join manager 604a compares the action’s status in the action status queue 608a to the action’s previous status. At operation 720 it updates the dispatch that originally dispatched the action to the reducer 602a, returning to the user any information that is to be returned following completion of the action (e.g., a notification to the user indicating that the action has been completed). The join manager 604a then removes the completed action from the pending actions queue 606a at operation 722.

[0090] At operation 724, the pending action queues 606a, b of the chains l02a,b are synchronized using a read join, following which the receiver chain’s l02b join manager 604b removes the action from the pending action queue 606b. After the action is removed, the action status queues 608a, b are synchronized using a readjoin at operation 728.

[0091] The sender chain l02a receives actions from the receiver chain l02b via readjoins that the action is pending at the receiver chain l02b (operation 717) and that the action has been performed by the receiver chain l02b (operation 728). For each readjoin, the sender chain l02a also receives lineage verification data and validity verification data analogous to that described above for FIGS. 5 A and 5B.

[0092] The diagrams 500,700 of FIGS. 5A-7C depict actions being transmitted between chains 102. Although not expressly illustrated in those figures, each action is sent in a block for which the first chain 102 has reached consensus, so that a second chain 102, which receives the action, can verify that the action in fact comes from the first chain and has not been tampered with.

Side Effects

[0093] In at least some example embodiments, an application stored on the blockchain comprises more than a smart contract. For example, an application may comprise a smart contract, which represents a function that returns a value; a saga, which performs actions other than returning a value, such as interactions with hardware; and the actions that interact with the smart contract and the saga. The actions that the saga performs, which are requested using the blockchain and the actual performance of which are performed without the blockchain achieving consensus, are herein referred to as“side effects”. While the actual performance of the side effect or action is not subject to consensus, the determination made by the blockchain to perform the side effect is subject to consensus, and the determination made by the blockchain to accept the result of the side effect is also subject to consensus. [0094] One manner in which the blockchain 102 may perform a side effect is to set a flag on the blockchain 102, and to have a particular one of the blockchain’ s 102 nodes 104 monitor the blockchain 102 to detect whether that flag has been set. If that node 104 detects the flag, it performs the associated action and returns the result to the blockchain. One problem with this method, however, is that if the particular node 104 that has been selected to perform actions fails, that results in a general inability of the blockchain 102 to perform actions. [0095] Accordingly, in at least some example embodiments herein, the blockchain

102 selects and instructs one or more of its nodes 104 to perform an action and stores as a final result on the blockchain the result of the action as determined by those one or more modes. The action may be performed in either a“master mode” or a“swarm mode”. In master mode, for which an example embodiment is depicted in FIG. 9, the blockchain 102 selects a single one of its nodes 104 to perform the action and, if that node is unable to timely return an interim result that the blockchain 102 determines is valid, the blockchain 102 in at least some example embodiments is able to select a different one of its nodes 104. A timely and valid interim result that the master node returns is stored on the blockchain 102 as the final result. In swarm mode, for which an example embodiment is depicted in FIG. 10, the blockchain 102 selects multiple of its nodes 104 to perform the action and averages the valid interim results that those nodes timely return. The average of those interim results is stored on the blockchain 102 as the final result. As with master mode, if any one of the swarm nodes is unable to return a timely and valid result, the blockchain 102 in at least some example embodiments is able to select a replacement node. [0096] Referring now to FIGS. 9 and 10, there are depicted methods 900,1000 for performing an action requested using a blockchain 102, according to additional example embodiments. In FIG. 9, the first blockchain l02a is used as an example blockchain, and the first node l04a is used as an example master node. Similarly, in FIG. 10, the first blockchain l02a is also used as an example blockchain and the first through fourth nodes l04a-d are used as example swarm nodes. However, in different example embodiments, blockchains and nodes other than these may be used to implement the methods 900,1000 of FIGS. 9 and 10. Each of the methods 900,1000 may be expressed as computer program code and stored on a non-transitory computer readable medium, such as the non-volatile storage 112, for execution by a node’s 104 processor 106. More particularly, in at least some example embodiments the computer program code may be stored or referenced on the blockchain l02a, and a reference to the blockchain l02a performing an action results from the processor 106 executing at least a portion of that computer program code. A blockchain is said to“store” code when the code actually comprises part of the blockchain, and is said to“reference” code when the blockchain stores a reference to the code that is stored off the blockchain. In at least some example embodiments in which the blockchain only references code, that code may nonetheless be stored on the nodes that comprise that blockchain without comprising part of that blockchain. In at least some example embodiments, a reference to code is a cryptographically secure reference.

[0097] As mentioned above, the method 900 of FIG. 9 depicts an example of

“master mode”. The method 900 begins at block 902 and proceeds to block 904 where the blockchain l02a selects a particular one of the nodes l04a-d to act as the master node. The blockchain l02a may apply any suitable selection method to determine which of the nodes l04a-d is to act as the master node. For example, at least two of the nodes l04a-d may send a signal to the blockchain l02a that each wishes to be considered for selection as the master node, and the selection method may comprise randomly selecting any one of the nodes l04a-d that sent that signal. Additionally or alternatively, the different nodes l04a-d may be configured to be able to perform different types of actions; for example, the first node l04a may be able to communicate at a higher transmission rate than the other nodes l04b- d, and the blockchain l02a may consequently select the first node l04a as the master node because the action to be performed requires relatively high bandwidth. For the purposes of describing blocks 906-916 of the method 900, it is presumed that the blockchain l02a selects the first node l04a as the master node as block 904 the first time it performs the method 900. In this example embodiment, the first node l04a is a node that is able to vote when the first blockchain l02a is determining whether it has achieved consensus; however, in at least some different example embodiments, the node that is selected to perform an action, whether in master or swarm mode, need not have the right to vote. As discussed in further detail below, different nodes l04a-d may be configured to perform different actions requiring different hardware resources, software resources, or both, and the blockchain l02a may select from the nodes l04a-d multiple master nodes of which each performs actions requiring that node’s specific resources.

[0098] Regardless of the selection method, once the blockchain l02a selects the first node l04a as the master node it proceeds to block 906 where it instructs the first node l04a to perform the action. As discussed above, the action’s performance is not subject to the blockchain’ s l02a requirement for consensus; examples of an action comprise contacting an external system, such as a web service; any interaction with the physical world, such as displaying an image on the display 116 or emitting a sound; and any kind of communication using the network controller 118.

[0099] After receiving the action, the first node l04a performs the action and determines at block 908 whether the first node l04a has returned a timely action result to the blockchain l02a. The result returned at this stage of the method 900 is an“interim” result in that it has not yet been validated or verified as timely received by the blockchain l02a. In order to determine whether the first node l04a has returned an interim result, the blockchain l02a checks every potential block during the block formation process and prior to consensus being achieved for that potential block to determine if the first node l04a has added the result to the blockchain l02a, until the blockchain l02a determines that the interim result has in fact been returned. In at least some example embodiments, such as the embodiment of FIG. 9, the first blockchain l02a waits for the interim result for only a set period of time or a set number of blocks since it instructed the first node l04a to perform the action. If the first node l04a returns the interim result within this number of blocks or this time period, the method 900 accepts the interim result and proceeds to block 910 where the interim result’s validity is evaluated. If no interim result is received within this number of blocks or this time period, the method 900 proceeds to block 912 where the first node l04a is de-selected as master node, and the method 900 subsequently ends at block 916. On a subsequent iteration of the method 900, the blockchain l02a may use the information that the first node l04a was unable to timely return an interim result to select a different node l04b-d as the master node when performing block 904.

[0100] At block 910, the blockchain l02a determines whether the timely interim result that was received is valid. In at least the example embodiment and as discussed above, the first node l04a returns the interim result in the form of a JSON object data structure; in different example embodiments, however, the result may comprise part of a different data structure. The JSON object also comprises a digital signature of the first node l04a; a task identifier, which may be numeric, identifying the action performed; a chain identifier identifying the first blockchain l02a; and a hash of the block of the first blockchain l02a that stored the computer program code that was executed to cause the blockchain l02a to request the action’s performance. To determine the result’s validity, the first blockchain 102a determines whether the digital signature of the first node 104a is valid (e.g., using public key cryptography, token-based cryptography, or any other suitable means of cryptography); whether the task identifier is valid (e.g., whether it corresponds to the task identifier that the first blockchain 102a assigned to the action prior to sending it to the first node l04a for execution); whether the chain identifier is valid (e.g., whether it matches the first blockchain’ s l02a chain identifier; in at least some example embodiments the chain identifier of a blockchain is the hash of that blockchain’ s genesis block, although in different example embodiments the chain identifier may take a different form); whether a format of the result is valid (e.g., whether it matches an expected format); and whether a status of the first node l04a is valid. In determining whether the status of the first node l04a is valid, the first blockchain l02a determines whether the first node l04a is capable of generating the interim result (e.g., whether the first node l04a has access to the hardware resources, software resources, or both to generate the interim result) and the first node l04a has an active heartbeat. The first blockchain l02a also determines whether the first node l04a remains selected by the first blockchain l02a as the master node; that is, from the time when the first blockchain l02a requested that the first node l04a perform the action, the first blockchain l02a may have selected another of the nodes l04b-d to become the master node. For example, the first node l04a may not have returned the interim result in a timely fashion at block 908, and upon performing a subsequent iteration of the method 900 the first blockchain l02a may have selected the second node l04b to be the master node at block 904.

[0101] When any of the digital signature, the chain identifier, the task identifier, the format of the result, and the status of the master node is not valid, the interim result is not flagged as valid and is consequently ignored. The first blockchain l02a proceeds to block 912 and de-selects the first node l02a as the master node. The method 900 then ends at block 916. As discussed above, on a subsequent iteration of the method 900 the first blockchain l02a may select another of the nodes l04b-d to act as a new master node, and instruct that new master node to perform the same or a different action.

[0102] When the digital signature, the chain identifier, the task identifier, the format of the result, and the status of the master node are all valid, the interim result is flagged as valid and the method 900 proceeds to block 914 where the interim result is treated as the final result of the action and is used to update the blockchain’ s l02a state by being subjected to and passing consensus.

[0103] Referring now to FIG. 10 and as mentioned above, the method 1000 of FIG.

10 depicts an example of“swarm mode”. The method 1000 begins at block 1002 and proceeds to block 1004, where the first blockchain l02a selects the swarm nodes. Similar to block 904 of FIG. 9, at block 1004 the first blockchain 102a applies any suitable selection method to determine which of the nodes l04a-d are to act as swarm nodes. For example, at least two of the nodes l04a-d may send a signal to the blockchain l02a that each wishes to be considered for selection as a swarm node, and the selection method may comprise selecting all of the nodes l04a-d that send that signal, or randomly selecting at least two of those nodes l04a-d. As described at block 904, selection may additionally or alternatively be based on the types of actions the nodes l04a-d are able to perform, and the nodes l04a- d that are selected may or may not have the right to vote when the first blockchain l02a is attempting to achieve consensus. [0104] Regardless of the selection method, once the blockchain l02a selects the first through fourth nodes l04a-d as the swarm nodes, it proceeds to block 1006 where it instructs each of the nodes l04a-d to perform the action. Each of the nodes l04a-d then performs the action in a manner analogous to that described in respect of block 906. [0105] As in master mode, the result that each swarm node returns is referred to as an“interim result”. For each swarm node, the blockchain l02a determines whether the interim result is timely received at block 1008, in a manner analogous to how the blockchain l02a makes this determination for the master node at block 908; and whether, for timely received interim results, the result is valid at block 1010, in a manner analogous to how the blockchain l02a makes this determination for the master mode at block 910. For swarm nodes that either do not return a timely interim result or return an invalid interim result, the blockchain l02a de-selects that swarm node at block 1012, in a manner analogous to how the blockchain l02a de-selects the master node at block 912. As in master mode, on subsequent iterations of the method 1000 any swarm node that is de-selected at block 1012 may apply to be a swarm node again prior to block 1004.

[0106] Swarm mode is non-analogous to master mode at block 1014. At block

1014, the blockchain l02a averages all the interim results that the blockchain l02a determined were valid at block 1010. An average may be the mean, mode, or median, for example, depending on the embodiment. In example embodiments in which the interim results are numeric (e.g., each interim result is an expected weather temperature resulting from accessing a weather web service), the average may be any of the mean, mode, and median of the valid interim results. In example embodiments in which the interim results are non-numeric (e.g., each interim result is weather pattern), the average may be the median or mode. [0107] Once the average is determined at block 1014, the blockchain’s l02a state is updated using that average value at block 1016 in a manner analogous to block 914 for master mode, and the method 1000 then ends at block 1018. [0108] In at least some example embodiments, regardless of whether master mode or swarm mode is being used, the first blockchain l02a may switch between at least two of the nodes l04a-d when performing actions. As the blockchain l02a performs the instructions stored or referenced as computer program code on each of its blocks, the blockchain l02a may assign different types of actions to different types of nodes l04a-d, and switch between the different nodes l04a-d in accordance with the different types of actions. For example, in master mode the blockchain l02a may send a first type of action requiring a first type of resources (hardware, software, or both) to a first one of the nodes l04a-d that has access to those resources, and send a second type of action requiring a second type of resources (hardware, software, or both) to a second one of the nodes l04a- d that has access to those resources. And for example in swarm mode, the blockchain l02a may send a first type of action requiring a first type of resources (hardware, software, or both) to at least two of the nodes l04a-d that has access to those resources, and send a second type of action requiring a second type of resources (hardware, software, or both) to at least two of the nodes l04a-d that has access to those resources. A node is said to be “qualified” to perform an action if that node has access to the resources required to perform that action.

[0109] For example, one type of action may require a node to have network access

(e.g., the third node l04c), while another type of action may require a node to have a minimum amount of computational power (e.g., the fourth node l04d). A first block at a first height of the blockchain l02a may request a first action requiring the third node’s l04c network access; a second block at a second height of the blockchain l02a that is higher than the first height may subsequently request a second action requiring the third node’s l04c network access; a third block at a third height of the blockchain l02a that is higher than the second height may subsequently request a third action requiring the fourth node’s l04c computational power; and a fourth block at a fourth height of the blockchain l02a that is higher than the third height may subsequently request a fourth action again requiring the third node’s l04c network access. In this example, the blockchain l02a switches to the third node l04c by at least the first block, and the third node l04c performs the first action. Before reaching the second block, the blockchain l02a switches to the fourth node l04d. When the blockchain l02a reaches the second block, the fourth node l04d does not perform the second action because the fourth node l04d is not qualified to perform the second action (i.e., it does not have network access). When the blockchain l02a reaches the third block, the fourth node l04d is qualified to perform, and consequently performs, the third action. When the blockchain l02a reaches the fourth block, it switches back to the third node l04c and the third node l04c performs all actions it is qualified to perform that are present on the blockchain l02a between the block corresponding to the time it was last being used by the blockchain l02a to perform actions and the current block height. In this example, the third node l04c performs the second action at the second block, does not perform the third action because it is not qualified to do so, and then performs the fourth action. While in this example, the first through fourth actions are at four different block heights, in different examples any single block at a particular height may comprise many actions, and different ones of those actions may be sent to different nodes that have access to different resources; that is, switching may be done within a single block.

[0110] The embodiments have been described above with reference to flow, sequence, and block diagrams of methods, apparatuses, systems, and computer program products. In this regard, the depicted flow, sequence, and block diagrams illustrate the architecture, functionality, and operation of implementations of various embodiments. For instance, each block of the flow and block diagrams and operation in the sequence diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified action(s). In some alternative embodiments, the action(s) noted in that block or operation may occur out of the order noted in those figures. For example, two blocks or operations shown in succession may, in some embodiments, be executed substantially concurrently, or the blocks or operations may sometimes be executed in the reverse order, depending upon the functionality involved. Some specific examples of the foregoing have been noted above but those noted examples are not necessarily the only examples. Each block of the flow and block diagrams and operation of the sequence diagrams, and combinations of those blocks and operations, may be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0111] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. Accordingly, as used herein, the singular forms“a”,“an”, and“the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and“comprising”, when used in this specification, specify the presence of one or more stated features, integers, steps, operations, elements, and components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and groups. Directional terms such as“top”,“bottom”,“upwards”, “downwards”,“vertically”, and“laterally” are used in the following description for the purpose of providing relative reference only, and are not intended to suggest any limitations on how any article is to be positioned during use, or to be mounted in an assembly or relative to an environment. Additionally, the term“couple” and variants of it such as “coupled”,“couples”, and“coupling” as used in this description are intended to include indirect and direct connections unless otherwise indicated. For example, if a first device is coupled to a second device, that coupling may be through a direct connection or through an indirect connection via other devices and connections. Similarly, if the first device is communicatively coupled to the second device, communication may be through a direct connection or through an indirect connection via other devices and connections.

[0112] Where any or all of the terms“comprise”,“comprises”,“comprised”, or

“comprising” are used in this specification (including the claims) they are to be interpreted as specifying the presence of the stated features, integers, steps, or components, but not precluding the presence of one or more other features, integers, steps, or components.

[0113] It is contemplated that any part of any aspect or embodiment discussed in this specification can be implemented or combined with any part of any other aspect or embodiment discussed in this specification. [0114] In construing the claims, it is to be understood that the use of computer equipment, such as a processor, to implement the embodiments described herein is essential at least where the presence or use of that computer equipment is positively recited in the claims. It is also to be understood that implementing a blockchain inherently requires computer equipment, such as a processor for creating and authenticating new blocks, storage for storing the blockchain, and a network interface for allowing communication between nodes, which is required for consensus.

[0115] One or more example embodiments have been described by way of illustration only. This description is been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the form disclosed. It will be apparent to persons skilled in the art that a number of variations and modifications can be made without departing from the scope of the claims.

Claims

1. A method for performing an action requested using a blockchain, the method comprising:

(a) using the blockchain to instruct one or more nodes comprising part of the blockchain to perform the action, wherein performance of the action is done without the blockchain achieving consensus; and

(b) adding, to a block on the blockchain, a final result of the action performed by the one or more nodes.

2. The method of claim 1, wherein the one or more nodes comprises a first master node that performs the action and returns the result of the action to the blockchain, wherein the first master node returns an interim result of the action to the blockchain, and further comprising determining the final result from the interim result.

3. The method of claim 2, further comprising determining, during block formation of the blockchain, whether the master node has returned the interim result.

4. The method of claim 3, wherein the master node returns the result as part of a data structure, the data structure further comprising a digital signature of the master node, a task identifier identifying the action, a chain identifier identifying the blockchain, and a hash of a block of the blockchain that instructed the master node to perform the action.

5. The method of claim 4, further comprising:

(a) determining whether the digital signature, the chain identifier, the task identifier, a format of the result, and a status of the master node are valid; and (b) when the digital signature, the chain identifier, the task identifier, the format of the result, and the status of the master node are all valid, flagging the result as valid.

6 The method of claim 5, wherein determining whether the status of the master node is valid comprises determining whether the master node is capable of generating the result, the master node has an active heartbeat, and the master node remains selected by the first blockchain as the master node.

7. The method of any one of claims 2 to 6, further comprising:

(a) determining whether the master node returns the result within at least one of a set period of time and a set number of blocks since the master node was instructed to perform the action; and

(b) accepting the result only when the master node returns the result within the at least one of the set period of time and the set number of blocks.

8 The method of claim 5 or 6, further comprising, when the result is not flagged as valid:

(a) ignoring the result returned by the first master node;

(b) selecting another of the nodes comprising part of the blockchain as a second master node; and

(c) instructing the new master node to perform the action.

9. The method of any one of claims 2 to 8, further comprising, prior to using the blockchain to instruct the master node:

(a) receiving from at least two of the nodes comprising part of the blockchain a signal that the at least two of the nodes are to be considered for selection as the first master node; and (b) selecting one of the at least two of the nodes as the first master node.

10. The method of claim 1, wherein the one or more nodes comprises multiple swarm nodes, wherein each of the swarm nodes performs the action and returns an interim result of the action to the blockchain, and further comprising determining the final result as an average of at least some of the interim results returned by the swarm nodes.

11. The method of claim 10, further comprising determining, during block formation of the blockchain and for each of the swarm nodes, whether the swarm node has returned the interim result.

12. The method of claim 11, wherein each of the swarm nodes returns the interim result as part of a data structure, the data structure further comprising a digital signature of the swarm node, a task identifier identifying the action, a chain identifier identifying the blockchain, and a hash of a block of the blockchain that instructed the swarm node to perform the action.

13. The method of claim 12, further comprising, for each of the interim results:

(a) determining whether the digital signature and a status of the swarm node that returned the interim result is valid;

(b) determining whether a format of the interim result is valid; and

(c) when the digital signature and the status of the swarm node that returned the interim result, and the format of the interim result are all valid, flagging the interim result as valid.

14. The method of claim 13, wherein determining whether the status of the swarm node that returned the interim result is valid comprises determining that the swarm node that returned the interim result is capable of generating the result, the swarm node that returned the interim result has an active heartbeat, and the swarm node that returned the interim result remains selected by the first blockchain as a swarm node.

15. The method of any one of claims 10 to 14, further comprising for each of the interim results: (a) determining whether the swarm node that returned the interim result returned the interim result within at least one of a set period of time and a set number of blocks since the swarm node that returned the interim result was instructed to perform the action; and

(b) accepting the interim result only when the swarm node that returned the interim result returns the interim result within the at least one of the set period of time and the set number of blocks.

16. The method of claim 13 or 14, further comprising, excluding each of the interim results not flagged as valid from the average.

17. The method of any one of claims 10 to 16, further comprising, prior to using the blockchain to instruct the swarm nodes:

(a) receiving from multiple nodes comprising part of the blockchain a signal that the at least two of the nodes are to be considered for selection as the swarm nodes; and

(b) selecting at least two of the nodes as the swarm nodes.

18. The method of claim 1, wherein the action comprises a first action requiring a first set of resources and a second action requiring a second set of resources different from the first set of resources, wherein the one or more nodes comprises a first node qualified to perform the first action and a second node qualified to perform the second action, wherein using the blockchain to instruct the one or more nodes comprises instructing the first node to perform the first action and instructing the second node to perform the second action, and wherein the final result comprises a first final result determined from a first interim result returned by the first node and a second interim result returned by the second node.

19. The method of claim 18, wherein the blockchain instructs the first node to perform the first action at a first block height of the blockchain, and instructs the second node to perform the second action at a second block height of the blockchain that differs from the first block height.

20. A system for performing an action requested using a blockchain, the system comprising a first node comprising part of the blockchain, the first node comprising:

(a) network interface hardware for interfacing with at least one other node that performs the action;

(b) a data store having stored on it the blockchain;

(c) a processor communicatively coupled to the data store and network interface hardware; and

(d) a memory communicatively coupled to the processor and having stored on it computer program code that is executable by the processor and that when executed by the processor causes the processor to perform the method of any one of claims 1 to 19.

21. A non-transitory computer readable medium have stored thereon computer program code that is executable by a processor and that when executed by the processor causes the processor to perform the method of any one of claims 1 to 19.