MIGRATION OF COMPUTATIONAL UNITS IN DISTRIBUTED NETWORKS

According to an embodiment of a first aspect of the invention, there is provided a computer-implemented method for operating a distributed network. The distributed network comprises a plurality of subnets embodied as replicated computing clusters. The method further comprises migrating a computational unit from a first subnet of the plurality of subnets to a second subnet of the plurality of subnets. The migrating comprises signalling to the first and the second subnet a computational unit of the first subnet as migrant computational unit that shall be migrated. The migrating further comprises transferring the migrant computational unit from the first subnet to the second subnet, installing the migrant computational unit on the second subnet and activating and running the migrant computational unit on the second subnet. Further aspects of the invention relate to a corresponding distributed network, a node, a computer program product and a software architecture.

TECHNICAL FIELD

The present invention pertains to a method for operating a distributed network, the distributed network comprising a plurality of subnets. Each subnet comprises a plurality of nodes.

Further aspects relate to a corresponding distributed network, a node of a distributed network, a corresponding computer program product and a software architecture encoded on a non-transitory medium.

BACKGROUND ART

In distributed networks a plurality of nodes are arranged in a distributed fashion. In distributed networks computing, software and data are spread out across the plurality of nodes. The nodes establish computing resources and the distributed networks may use distributed computing techniques.

An example of distributed networks are blockchain networks. Blockchain networks are consensus-based, electronic ledgers based on blocks. Each block comprises transactions and other information. Furthermore, each block contains a hash of the previous block so that blocks become chained together to create a permanent, unalterable record of all transactions which have been written to the blockchain. Transactions may contain small programs known e.g. as smart contracts.

In order for a transaction to be written to the blockchain, it must be “validated” by the network. In other words, the network nodes have to gain consent on blocks to be written to the blockchain. Such consent may be achieved by various consensus protocols.

One type of consensus protocols are proof-of-work consensus protocols. A proof-of-work consensus protocol generally requires some work from the parties that participate in the consensus protocol, usually corresponding to processing time by a computer. Proof-of-work-based cryptocurrency systems such as Bitcoin involve the solving of computationally intensive puzzles to validate transactions and to create new blocks.

Another type of consensus protocols are proof-of-stake-consensus protocols. Such proof-of-stake protocols have the advantage that they do not require time-consuming and energy-intensive computing. In proof-of-stake based blockchain networks e.g. the creator of the next block is chosen via combinations of random selection as well as the stake of the respective node in the network.

Apart from cryptocurrencies, distributed networks may be used for various other applications. In particular, they may be used for providing decentralized and distributed computing capabilities and services.

Accordingly, there is a need for distributed networks with enhanced functionalities.

DISCLOSURE OF THE INVENTION

Accordingly, one object of an aspect of the invention is to provide a distributed network with enhanced functionalities.

According to an embodiment of a first aspect of the invention, a computer-implemented method for operating a distributed network is provided. The distributed network comprises a plurality of subnets, wherein each of the plurality of subnets comprises one or more assigned nodes. The method comprises steps of running a set of computational units, assigning each of the computational units to one of the plurality of subnets according to a subnet-assignment. This creates an assigned subset of the set of computational units for each of the subnets. The method further comprises running on each node of the plurality of subnets the assigned subset of the computational units and executing, by the nodes of the plurality of subnets, computations in a deterministic and replicated manner across the subnets, thereby traversing a chain of execution states. The method further comprises migrating a computational unit from a first subnet of the plurality of subnets to a second subnet of the plurality of subnets. The migrating comprises signalling to the first and the second subnet a computational unit of the first subnet as migrant computational unit that shall be migrated. The migrating further comprises transferring the migrant computational unit from the first subnet to the second subnet, installing the migrant computational unit on the second subnet and activating and running the migrant computational unit on the second subnet.

Such an embodied method offers enhanced operation flexibility for distributed networks which operate subnets in a replicated manner. According to embodiments, the subnets may also be denoted as replicated computing clusters. In such replicated computing cluster the computational units that have been assigned to a respective subnet are run on each node of the subnet and are hence replicated across the subnet, thereby traversing the same chain of execution states.

Methods according to embodiments of the invention allow the migration of computational units from one subnet to another subnet. This improves the flexibility of the network, in particular in terms of load and capacity management of the subnets and their assigned nodes.

Such a migration of computational units may on the first sight be observed as counterintuitive in such a replicated setting as the execution states of such a distributed network may be considered as immutable as they cannot be removed anymore once they have been agreed upon by the nodes of a subnet.

Nevertheless, the inventors of the present invention have overcome such a prejudice and have designed a distributed network with subnets that form replicated computing clusters which nevertheless allow the migration of the computational units between the replicated computing clusters/subnets.

According to an embodiment, the method further comprises preparing, by the first subnet, the migrant computational unit for migration.

According to further embodiments the method, in particular the step of preparing the migrant computational unit for migration may comprise a step of scheduling a migration time. The migration time may be scheduled in various ways. According to some embodiments, it may be scheduled by a central control unit. According to other embodiments, the central control unit may just signal to the respective subnets, in particular to the first and the second subnet, that a computational unit has to be migrated. According to embodiments, the central control unit may make an update in a central registry. Then the first subnet, e.g. a computational unit manager of the first subnet, may observe the change in the registry and may schedule the corresponding migration time. The migration time defines in particular the point in time for stopping to accept messages for the migrant computational unit and for stopping to execute the migrant computational unit and/or to modify the unit state of the migrant computational unit after the migration time. In other words, after the migration time the unit state of the respective computational unit is fixed or in other words frozen and will not be modified anymore. And as it is fixed, the computational unit including its state is also ready for migration.

According to an embodiment, the plurality of subnets are configured to execute blocks in a consecutive manner and the migration time is a block height defining the last block that is to be processed by the first subnet. It should be noted that according to embodiments the blocks may be processed in an asynchronous manner and that hence the block height does not define in advance a specific calendar time as migration time, but rather the time in terms of a specific block height. In this respect the term migration time shall be understood in a broad sense.

According to an embodiment, the step of obtaining the migrant computational unit comprises joining, by the nodes of the second subnet, the first subnet. This may include running, by the nodes of the second subnet, the computational units of the first subnet. By joining the first subnet the nodes of the second subnet may observe the unit states/execution states of the computational units of the first subnet, in particular of the migrant computational unit. The joining may take place in particular before the migration time. By this the nodes of the second subnet may gain in advance trust in the unit state of the migrant computational unit. Furthermore, they may start to obtain parts of the state of the migrant computational unit in advance to reduce downtime. This facilitates an efficient transfer.

According to an embodiment the nodes of the second subnet may join the first subnet passively in a listening mode. The listening mode may comprise in particular verifying all artefacts of the first subnet, but not producing any artefacts itself. In this respect an artefact may be any information that is exchanged between the nodes of the first subnet. According to an embodiment the nodes of the second subnet may perform only a subset of the tasks for this second subnet. As an example, they may e.g. not participate in the proposal and notarization of blocks, but they may verify each block and execute it in case it is valid.

According to an embodiment the step of transferring the migrant computational unit from the first subnet to the second subnet comprises performing a node internal transfer of the migrant computational unit between a replica of the first subnet and a replica of the second subnet, wherein the replica of the first subnet and the replica of the second subnet run on the same node.

A replica is formed by a set of computational units that runs on a node and are assigned to the same subnet.

According to such an embodiment the nodes of the second subnet that have joined the first subnet run two replicas, namely a first replica for the first subnet and a second replica for the second subnet. As both replicas run on the same node, they are in the same trust domain and as the first replica, which may be in particular a passive replica, observes the states of the computational units of the first subnet including the state of the migrant computational unit, this state of the migrant computational unit may be transferred within the node and hence within the same trust domain from the first replica to the second replica and accordingly from the first subnet to the second subnet.

According to an embodiment, the step of transferring the migrant computational unit comprises obtaining, by each node of the second subnet, the migrant computational unit from a node of the first subnet via a messaging protocol.

According to such an embodiment the nodes of the second subnet are not part of the first subnet or in other words have not joined the first subnet. After the migration height has been reached, the first subnet prepares the migrant computational unit for migration. This may include in particular to perform e.g. a joint signature on the migrant computational unit by the nodes of the first subnet, thereby certifying the state of the migrant computational unit at the migration block height. The certified migrant computational unit may then be sent to the nodes of the second subnet via the messaging protocol.

According to an embodiment the step of transferring the computational unit via a messaging protocol comprises splitting, by the nodes of the first subnet, the migrant computational unit into one or more chunks and transferring the one or more chunks of the migrant computational unit via the messaging protocol from the first subnet to the second subnet. This may facilitate an efficient transfer, in particular in terms of bandwidth.

According to an embodiment the messaging protocol may include a state synchronisation protocol for synchronizing the states between the migrant computational unit on the nodes of the first subnet and a corresponding migrant computational unit that has been installed on the nodes of the second subnet.

According to an embodiment the first subnet may reject after the migration time/migration block height messages for the migrant computational unit. This facilitating a re-routing of the respective messages by the sender of the messages.

According to an embodiment, the nodes of the second subnet may agree, in particular by performing a consensus protocol, on the activating of the migrant computational unit. Such a step may ensure that a sufficient number of nodes of the second subnet has the computational unit available and that therefore the computational unit can become operational after agreement. Furthermore, this may ensure that the corresponding nodes start to execute the migrant computational unit at the same time to facilitate a deterministic processing.

According to an embodiment of a second aspect of the invention, another computer-implemented method for operating a distributed network is provided. The distributed network comprises a plurality of subnets, wherein each of the plurality of subnets comprises one or more assigned nodes. The method comprises running a set of computational units and assigning each of the computational units to one of the plurality of subnets according to a subnet-assignment, thereby creating an assigned subset of the set of computational units for each of the subnets. The method further comprises running on each node of the plurality of subnets the assigned subset of the computational units and executing, by the nodes of the plurality of subnets, computations in a deterministic and replicated manner across the subnets. The computer-implemented method comprises migrating a computational unit from a first subnet of the plurality of subnets to a second subnet of the plurality of subnets. According to this embodiment, the second subnet is not pre-existing, i.e. the second subnet has to be newly created. The migrating comprises steps of signalling to the first subnet a computational unit of the first subnet as migrant computational unit that shall be migrated. In response to the signalling the nodes of the first subnet create and start the new second subnet. Then the migrant computational unit is transferred from the first subnet to the second subnet internally, i.e. within the respective nodes between the replicas. This has the advantage that this transfer happens within the same trust domain of the respective nodes.

Further steps include installing, by the nodes of the first subnet and the second subnet, the migrant computational unit on the second subnet and activating and running, by the nodes of the first subnet and the second subnet, the migrant computational unit on the second subnet.

Before activating and running the migrant computational unit a step of agreeing on the activating, in particular by a consensus protocol, may be performed.

According to a further embodiment of the second aspect additional nodes may be added to the second subnet that are not part of the first subnet. These additional nodes are fresh nodes which may catch up with the states of the migrant computational unit e.g. via a Resumability or state recovery protocol.

A further step may comprise removing the nodes of the first subnet from the second subnet.

By this, the migrant computational unit has been completely migrated from the nodes of the first subnet to another new set of nodes.

According to embodiments a plurality of computational units may be migrated from a first subnet to a second subnet in one go with the methods as described above and below.

According to an embodiment of another aspect of the invention, a distributed network is provided which is configured to perform the method steps of the first aspect of the invention.

According to an embodiment of another aspect of the invention, a distributed network is provided which is configured to perform the method steps of the second aspect of the invention.

According to an embodiment of another aspect of the invention, a node of a distributed network is provided.

According to an embodiment of another aspect of the invention, a computer program product for operating a distributed network is provided. The computer program product comprises a computer readable storage medium having program instructions embodied therewith, the program instructions executable by one or more of a plurality of nodes of the distributed network to cause the one or more of the plurality of nodes to perform steps of the method aspects of the invention.

According to an embodiment of another aspect of the invention, a computer program product for operating a node of a distributed network is provided.

According to an embodiment of another aspect of the invention, a software architecture encoded on a non-transitory computer readable medium is provided. The software architecture is configured to operate one or more nodes of a distributed network. The encoded software architecture comprises program instructions executable by one or more of the plurality of nodes to cause the one or more of the plurality of nodes to perform a method comprising steps of the method aspects of the invention.

Features and advantages of one aspect of the invention may be applied to the other aspects of the invention as appropriate.

Other advantageous embodiments are listed in the dependent claims as well as in the description below.

MODES FOR CARRYING OUT THE INVENTION

At first, some general aspects and terms of embodiments of the invention will be introduced.

According to embodiments, a distributed network comprises a plurality of nodes that are arranged in a distributed fashion. In such a distributed network computing, software and data is distributed across the plurality of nodes. The nodes establish computing resources and the distributed network may use in particular distributed computing techniques.

According to embodiments, distributed networks may be in particular embodied as blockchain networks. The term “blockchain” shall include all forms of electronic, computer-based, distributed ledgers. According to some embodiments, the blockchain network may be embodied as proof-of-work blockchain network. According to other embodiments, the blockchain network may be embodied as proof-of-stake blockchain network.

A computational unit may be defined as a piece of software that is running on a node of the distributed network and which has its own unit state. The unit state may also be denoted as execution state.

Each of the subnets is configured to replicate the set of computational units, in particular the states of the computational units, across the subnet. As a result, the computational units of a respective traverse always the same chain of unit/execution states, provided they behave honestly. A computational unit comprises the code of the computational unit and the unit state/execution state of the computational unit.

A messaging protocol may be defined as a protocol that manages the exchange of unit-to-unit messages. In particular, the messaging protocol may be configured to route the unit-to-unit messages from a sending subnet to a receiving subnet. For this, the messaging protocol uses the respective subnet-assignment. The subnet-assignment indicates to the messaging protocol the respective location/subnet of the computational units of the respective communication.

FIG.1shows an exemplary block diagram of a distributed network100according to an embodiment of the invention.

The distributed network100comprises a plurality of nodes10, which may also be denoted as network nodes10. The plurality of nodes10are distributed over a plurality of subnets11. In the example ofFIG.1, four subnets11denoted with SNA, SNB, SNC and SND are provided.

Each of the plurality of subnets11is configured to run a set of computational units on each node10of the respective subnet11. According to embodiments a computational unit shall be understood as a piece of software, in particular as a piece of software that comprises or has its own unit state or in other words execution state.

The network100comprises communication links12for intra-subnet communication within the respective subnet11, in particular for intra-subnet unit-to-unit messages to be exchanged between computational units assigned to the same subnet.

Furthermore, the network100comprises communication links13for inter-subnet communication between different ones of the subnets11, in particular for inter-subnet unit-to-unit messages to be exchanged between computational units assigned to different subnets.

Accordingly, the communication links12may also be denoted as intra-subnet or Peer-to-Peer (P2P) communications links and the communication links13may also be denoted as inter-subnet or Subnet-to-Subnet (SN2SN) communications links.

According to embodiments, a unit state shall be understood as all the data or information that is used by the computational unit, in particular the data that the computational unit stores in variables, but also data the computational units get from remote calls. The unit state may represent in particular storage locations in the respective memory locations of the respective node. The contents of these memory locations, at any given point in the execution of the computational units, is called the unit state according to embodiments. The computational units may be in particular embodied as stateful computational units, i.e. the computational units are designed according to embodiments to remember preceding events or user interactions.

According to embodiments of the invention the subnets11are configured to replicate the set of computational units across the respective subnet11. More particularly, the subnets11are configured to replicate the unit state of the computational units across the respective subnet11.

The network100may be in particular a proof-of-stake blockchain network.

Proof-of-stake (PoS) describes a method by which a blockchain network reaches distributed consensus about which node is allowed to create the next block of the blockchain. PoS-methods may use a weighted random selection, whereby the weights of the individual nodes may be determined in particular in dependence on the assets (the “stake”) of the respective node.

FIG.2illustrates in a more detailed way computational units15running on nodes10of the network100. The network100is configured to assign each of the computational units which are running on the network100to one of the plurality of subnets, in this example to one of the subnets SNA, SNB, SNC or SND according to a subnet-assignment. The subnet-assignment of the distributed network100creates an assigned subset of the whole set of computational units for each of the subnets SNA, SNB, SNC and SND.

More particularly,FIG.2shows on the left side201a node10of the subnet SNA ofFIG.1. The subnet assignment of the distributed network100has assigned a subset of four computational units15to the subnet SNA more particularly the subset of computational units CUA1, CUA2, CUA3and CUA4. The assigned subset of computational units CUA1, CUA2, CUA3and CUA4runs on each node10of the subnet SNA. Furthermore, the assigned subset of computational units CUA1, CUA2, CUA3and CUA4is replicated across the whole subnet SNA such that each of the computational units CUA1, CUA2, CUA3and CUA4traverses the same chain of unit states. This may be implemented in particular by performing an active replication in space of the unit state of the computational units CUA1, CUA2, CUA3and CUA4on each of the nodes10of the subnet SNA.

Furthermore,FIG.2shows on the right side202a node10of the subnet SNB ofFIG.1. The subnet assignment of the distributed network100has assigned a subset of 2 computational units15to the subnet SNB, more particularly the assigned subset of computational units CUB1and CUB2. The assigned subset of computational units CUB1and CUB2runs on each node10of the subnet SNB. Furthermore, the assigned subset of computational units CUB1and CUB2is replicated across the whole subnet SNB such that each of the computational units CUB1and CUB2traverses the same unit states/execution states, e.g. by performing an active replication in space of the unit states as mentioned above.

FIG.2illustrates a general example of a migration of a computational unit between the subnet SNA and the subnet SNB. More particularly, as the nodes of the subnet SNA already have to run 4 computational units, while the subnet SNB has only 2 computational units, the distributed network may decide to migrate the computational unit CUA4from the subnet SNA to the subnet SNB, e.g. for load balancing or other reasons.

As shown inFIG.1, the distributed network100comprises a central control unit CCU,20. The central control unit20may comprise a central registry21to provide network control information to the nodes of the network. The central control unit20may trigger the migration of the migrant computational CUA4that shall be migrated. This may be done e.g. by performing an update in the central registry21and setting the migrant computational unit CUA4to a migrating state. A computational unit manager (not explicitly shown) of the subnets SNA, SNB, SNC and SND may observe such registry change in the central registry21and trigger the migration of the computational unit CUA4.

According to embodiments, the central control unit may be established by a subnet.

Referring now toFIG.10, a timing diagram of such a migration of a computational unit according to embodiments of the invention is illustrated.

At first, the central control unit20may set the respective migrant computational unit to a migrating state in the registry21.

At a point in time tN, which corresponds to a block height N, the first subnet SNA, e.g. a computational unit manager of the first subnet SNA, may observe the changes in the central registry21which indicate/signal that the computational unit CUA4shall be migrated.

Then the computational unit manager may schedule/trigger a migration time/migration block height, in this example the migration block height N+K corresponding to a migration time tN+K.

The migration time defines the block height of the last block that is to be processed by the first subnet SNA with the migrant computational unit still being part of the first subnet SNA.

Referring back toFIG.1, the network100is configured to exchange unit-to-unit messages between the computational units of the network via a messaging protocol based on the subnet-assignment.

According to embodiments, the distributed network may be in particular configured to exchange inter-subnet messages16between the subnets SNA, SNB, SNC and SND via a messaging protocol. The inter-subnet messages16may be in particular embodied as inter-subnet unit-to-unit messages16ato be exchanged between computational units that have been assigned to different subnets according to the subnet-assignment. As an example, the distributed network100may be configured to exchange a unit-to-unit message M1,16abetween the computational unit CUA1as sending computational unit running on the subnet SNA and the computational unit CUB2as receiving computational unit running on the subnet SNB. In addition, the inter-subnet messages16may be embodied as signalling messages16b.The signalling messages16bmay encompass acknowledgement messages (ACK) adapted to acknowledge an acceptance or receipt of the unit-to-unit messages or non-acknowledgement messages(NACK) adapted to not-acknowledge an acceptance (corresponding to a rejection) of the unit-to-unit messages, e.g. to indicate a transmission failure.

The network100may be in particular configured to store the subnet-assignment of the computational units10as network configuration data, e.g. in the networking component1200as shown inFIG.12, in particular in the crossnet component1230. This information may also be stored in the central registry.

According to further embodiments, the network100may be configured to exchange the inter-subnet messages16via a messaging protocol and a consensus protocol. The consensus protocol may be configured to reach a consensus on the selection and/or processing order of the inter-subnet messages16at the respective receiving subnet.

Referring e.g. to the subnet SNB, it receives inter-subnet messages16from the subnets SNA, SNC and SND. The consensus protocol receives and processes these inter-subnet messages16and performs a predefined consensus algorithm or consensus mechanism to reach a consensus on the selection and/or processing order of the received inter-subnet messages16.

Referring now toFIGS.3ato3d, a computer-implemented method for migrating a computational unit from a first subnet to a second subnet will be explained.

More particularly,FIGS.3ato3dshow a number of nodes N1, N2and N3of a first subnet SNA and a number of nodes N4, N5and N6of a second subnet SNB. The first subnet SNA is configured to run an assigned subset of 4 computational units, more particularly the computational units CUA1, CUA2, CUA3and CUA4and the second subnet SNB is configured to run an assigned subset of 2 computational units, more particularly the computational units CUB1and CUB2. The respective set of assigned computational units that runs on a node forms a replica of the subset on the respective node, namely a replica SNA,310on the nodes N1, N2and N3and a replica SNB,320on the nodes N4, N5and N6. Such a replica may be considered as a partition for the assigned subset of computational units on the nodes of the subnet. In other words, a replica is formed by a set of computational units that runs on a node and is assigned to the same subnet.

In the example ofFIG.3ait is assumed that the subnet SNA operates at a block height N. The subnet SNB may operate at a different block height which is not shown inFIGS.3ato3efor ease of illustration. In the example ofFIGS.3ato3dit is assumed that the underlying distributed network migrates the computational unit CUA4from the first subnet SNA to the second subnet SNB for load balancing reasons. To start the migration process, the central control unit20signals the intended migration to the first subnet SNA and the second subnet SNB, e.g. by a registry update which sets the computational unit CUA4to a migrating state.

Then, once observed, the computational unit manager of the subnet SNA may schedule a migration time/migration block height. In this example the migration block height is the block height N+K, wherein N is the height where the first subnet/source subnet SNA observes the registry change. The number K may be chosen in dependence on the respective configuration of the distributed network and may be adapted to the needs of the respective distributed network. As an example, K may be e.g. 10, 100 or even 1000 or more block heights. The higher K, the higher is the respective lead time for the involved subnets to prepare the transfer of the computational unit CUA4.

FIG.3bshows the nodes of the subnets SNA and SNB at an intermediate block height N+X of the subnet SNA, wherein X<K, i.e. the migration block height N+K has not been reached and the computational unit CUA4is still going to be processed by the subnet SNA.

In the meantime, the nodes N4, N5and N6of the second subnet SNB have joined the first subnet SNA and have started to run the computational units CUA1, CUA2, CUA3and CUA4as local replicas330. In other words, the nodes N4, N5and N6have created a new partition which is now used to run the computational units of the subnet SNA.

The nodes of the second subnet SNB may run the replicas310of the subnet SNA in particular as passive replicas. In other words, they do not fully participate in the subnet SNA, but perform only a limited set of operations of the subnet SNA. In particular, the replicas310may be configured to mainly observe the unit states/execution states of the computational units CUA1, CUA2, CUA3and CUA4in order to be up to date with the states of the computational units CUA1, CUA2, CUA3and CUA4. This passive joining may be in particular used to create an internal trust domain for the unit states of the computational unit CUA4. In other words, by observing and partly participating in the subnet SNA, the nodes N4, N5and N6use the lead time between the signalling height N and the migration height N+K to pre-transfer already the state of the computational unit CUA4in a trusted manner to their own internal and trusted domain so that they later on only need to keep up with the execution of valid blocks to reach the state at migration height.

FIG.3cillustrates the nodes of the subnets SNA and SNB at the block height N+K+1 of the subnet SNA. In order to take over the processing of the migrant computational CUA4, the nodes N4, N5and N6may internally transfer the final state of the computational unit CUA4at the migration block height N+K which is available in the passive replicas330. More particularly, the passive replicas330may be stopped and the final state of the computational unit CUA4at the block height N+K may be transferred to an internal storage space, e.g. to a directory340of the nodes N4, N5and N6which is assigned for inbound computational units.

Then the replicas320of the subnet SNB may receive or get the state of the computational unit CUA4from the internal directory340via some internal and trusted communication mechanism350. Then the replicas320may agree on activating the computational unit CUA4and start to run the computational unit CUA4on the subnet SNB, in particular on the corresponding replicas320of the nodes N4, N5and N6for the subnet SNB.

During some transition time, the nodes of the first subnet SNA may still comprise a copy of the computational unit CUA4. The copy may be just a passive copy, i.e. the computational unit CUA4is not actively run anymore by the replicas SNA of the nodes N1, N2and N3. This is indicated by the dotted lines of the computational unit CUA4inFIG.3c.

FIG.3dillustrates the nodes of the subnets SNA and SNB at the block height N+K+2.

Now the nodes of the first subnet SNA have completely deleted the computational unit CUA4and only run the replicas SNA,310of the subnet SNA with the computational units CUA1, CUA2and CUA3.

Furthermore, the computational unit CUA4has been fully integrated in the subnet SNB and is run by the replicas SNB,320of the nodes N4, N5and N6. The migrant computational unit is denoted inFIG.3dwith CUB3/A4to indicate that the former computational unit CUA4is now run on subnet SNB as third computational unit.

Referring now toFIG.3e, another mechanism to transfer the migrant computational unit CUA4is explained. The example illustrated inFIG.3estarts from the initial setting as shown inFIG.3a.FIG.3eshows the nodes N1-N6at the block height N+K+1. After the block N+K has been processed by the nodes N1, N2and N3, the migrant computational unit CUA4and its corresponding final state is transferred within the nodes N1, N2and N3from the replicas SNA,310to a dedicated storage space, e.g. to a directory360of the nodes N1, N2and N3which is assigned for outbound computational units.

Then the replicas320of the subnet SNB may receive or get the state of the computational unit CUA4from the directory360via a messaging protocol370which establishes an inter-subnet communication mechanism between the subnets SNA and SNB. According to such an embodiment the nodes N4, N5and N6of the second subnet SNB have not joined the first subnet. After the migration height N+K has been reached, the first subnet SNA has prepared the migrant computational unit CUA4for migration and placed it in the directory360. According to embodiments the computational unit CUA4at the migration block height N+K that is placed in the directory360may be certified by the nodes N1, N2and N3, e.g. by a joint signature. After having received the certified computational unit CUA4, the replicas320may agree on the activation and start to run the computational unit CUA4on the subnet SNB. As a result, the nodes N4, N5and N6may process the computational unit CUB3/A4as part of their subnet SNB.

Referring now toFIGS.4ato4g, a computer-implemented method for migrating a computational unit from a first subnet to a second subnet according to another embodiment of the invention will be explained.

FIG.4ashows a number of nodes N1, N2and N3of a first subnet SNA. The first subnet SNA is configured to run an assigned subset of 3 computational units, more particularly the computational units CUA1, CUA2, and CUA3.

According to the embodiment illustrated inFIGS.4ato4g, the distributed network is operated to migrate the computational unit CUA3of the first subnet SNA to a subnet SNB that is not pre-existing, i.e. to a subnet SNB that has to be newly created.

To start the migration process, the central control unit20signals the intended migration to the first subnet SNA, e.g. by a registry update which sets the computational unit CUA3to a migrating state. Accordingly, the computational unit CUA3may be again denoted as migrant computational unit. Furthermore, e.g. the central control unit20or the computational unit manager of the subnet SNA or another entity or mechanism schedules the migration time/migration block height.

Then, and as illustrated inFIG.4b, the nodes N1, N2and N3of the first subnet SNA create a new second subnet SNB and start to run the new second subnet SNB. This comprises to create a new partition on the Nodes N1, N2and N3for the second subnet SNB. Accordingly, each of the nodes N1, N2and N3have created a new replica SNB,420for the subnet SNB. Then the nodes N1, N2and N3may stop to run the migrant computational unit on the first subnet SNA.

As a next step, as shown inFIG.4c, the nodes N1, N2and N3agree to activate the migrant computational unit CUA3/B1and start to run the migrant computational unit CUA3/B1of the first subnet SNA which shall be transferred to the new subnet SNB as first computational unit. Accordingly, the migrant computational unit is denoted in the following as CUA3/B1.

As the nodes N1, N2and N3run both subnets SNA and SNB, the state of the computational unit CUA3may be transferred internally to the computational unit CUA3/B1within the same node and hence within the same trust domain from the replica SNA,410to the replica SNB,420.

As both replicas SNA and SNB run on the same node, the replica SNB has according to embodiments only to wait until the first replica SNA has agreed on a final state of the computational unit CUA3at the migration block height N+K. Then the replica SNB may receive this state of the computational unit CUA3from the first replica SNA of the same node via a node-internal communication mechanism430. As an example, the replica SNA may put the computational unit CUA3in a dedicated directory of the file system of the respective node where it can be picked up by the replica SNB. Once the migrant computational unit CUA3/B1has been transferred via the internal communication or transfer mechanism430, the nodes N1, N2and N3may install, agree to activate, activate and run the migrant computational unit CUA3/B1on the newly created second subnet SNB.

FIG.4dillustrates a transitioning period during which the computational unit CUA3is still held by the replica SNA,410in an inactive mode, while at the same time the migrated computational unit CUA3/B1is already run on the new replica SNB,420.

FIG.4eillustrates the nodes N1, N2and N3, wherein the migrant computational unit CUA3has been removed from the replica SNA, while the migrant computational unit CUA3/B1is run on the new replica SNB on the nodes N1, N2and N3.

FIG.4fillustrates a new set of nodes comprising additional or fresh nodes N4, N5and N6which have been added to the second subnet SNB and which have started to run the migrant computational unit CUA3/B1on respective replicas SNB of the second subnet SNB. The new or fresh nodes N4, N5and N6may receive the migrant computational unit CUA3/B1via a transfer mechanism450from the nodes N1, N2and N3. This transfer of the migrant computational unit may be performed by some messaging protocol between the nodes, e.g. a state synchronisations protocol. As this transfer of the computational unit CUA3/B1takes place between different nodes, i.e. between two different trust domains, the state of the computational unit CUA3/B1is transferred in a certified way, e.g. with a joint signature of the nodes N1, N2and N3.

According to embodiments this mechanism of adding fresh nodes may rely on a protocol for joining a subnet and for catching up with the whole state of the subnet.

FIG.4gillustrates the nodes N1, N2and N3, wherein the migrant computational unit CUA3has been removed from the replica SNA, while the migrant computational unit CUA3/B1is now only run on the new replicas SNB of the additional or fresh nodes N4, N5and N6.

The mechanism as explained with reference toFIGS.4ato4guses a kind of “spin-off” approach for migrating a migrant computational unit. First the nodes that initially run the migrant computational unit start themselves a new subnet as separate partition. Then they transfer the migrant computational unit internally within the nodes to the newly created partition which establishes a newly created subnet. This transfer takes place within the same trust domain. Then new nodes may be added to the newly created second subnet and may subsequently take over the operation of the newly created second subnet, while the former nodes of the first subnet may leave the second subnet. This approach has the advantage that the initial transfer of the migrant computational unit from the first subnet to the second subnet take place internally within the corresponding nodes and hence within the same trust domain. Furthermore, only the migrant computational unit CUA3/B1has to be transferred via the transfer mechanism450between different nodes over the network. This may facilitate a smooth, efficient and quick transfer of the migrant computational unit.

FIG.5illustrates main processes which may be run on each node10of the network100according to an embodiment of the invention. A network client of networks according to embodiments of the invention is the set of protocol components that are necessary for a node10to participate in the network. According to embodiments, each node10is a member of a mainnet. Furthermore, each node may be a member of one or more subnets.

A node manager50is configured to start, restart and update a mainnet protocol client51, a subnet protocol client52and a security application53. According to other embodiments, the central control unit20may be used instead of the mainnet protocol client (seeFIG.1). According to embodiments several subnet protocol clients may be used, thereby implementing several replicas.

According to embodiments, each of the plurality of subnets11is configured to run a separate subnet protocol client52on its corresponding nodes10. The mainnet protocol client51is in particular configured to distribute configuration data to and between the plurality of subnets11. The mainnet protocol client51may be in particular configured to run only system computational units, but not any user-provided computational units. The mainnet protocol client51is the local client of the mainnet and the subnet protocol client52is the local client of the subnet.

The security application53stores secret keys of the nodes10and performs corresponding operations with them.

The node manager50may monitor e.g. the registry21of the control unit20, it may instruct the nodes to participate in a subnet, it may move a computational unit to a partition of the node which participates in the second subnet and/or it may instruct the nodes to stop participation in a subnet.

FIG.6shows a schematic block diagram of protocol components600of a subnet protocol client, e.g. of the subnet protocol client52ofFIG.5.

Full arrows inFIG.6are related to unit-to-unit messages and ingress messages. Dashed arrows relate to system information.

The protocol components600comprise a messaging component61which is configured to run the messaging protocol and an execution component62configured to run an execution protocol for executing execution messages, in particular for executing unit-to-unit messages and/or ingress messages. The protocol components600further comprise a consensus component63configured to run a consensus protocol, a networking component64configured to run a networking protocol, a state manager component65configured to run a state manager protocol, an X-Net component66configured to run a cross-subnet transfer protocol and an ingress message handler component67configured to handle ingress message received from an external user of the network. The protocol components600comprise in addition a crypto-component68. The crypto-component68co-operates with a security component611, which may be e.g. embodied as the security application53as described with reference toFIG.5. Furthermore, the subnet-protocol client52may cooperate with a reader component610, which may be a part of the mainnet protocol client51as described with reference toFIG.5. The reader component610may provide information that is stored and distributed by the mainnet to the respective subnet protocol client52. This includes the assignment of nodes to subnets, node public keys, assignment of computational units to subnets etc.

The messaging component61and the execution component62are configured such that all computation, data and state in these components is identically replicated across all nodes of the respective subnet, more particularly all honest nodes of the respective subnet. This is indicated by the wave-pattern background of these components.

Such an identical replication is achieved according to embodiments on the one hand by virtue of the consensus component63that ensures that the stream of inputs to the messaging component61is agreed upon by the respective subnet and thus identical for all nodes, more particularly by all honest nodes. On the other hand, this is achieved by the fact that the messaging component61and the execution component62are configured to perform a deterministic and replicated computation.

The X-Net Transfer component66sends message streams to other subnets and receives message streams from other subnets.

Most components will access the crypto component68to execute cryptographic algorithms and the mainnet reader70for reading configuration information.

The execution component62receives from the messaging component61a unit state of the computational unit and an incoming message for the computational unit, and returns an outgoing message and the updated unit state of the computational unit. While performing the execution, it may also measure a gas consumption of the processed message (query).

The messaging component61is clocked by the input blocks received from the consensus component63. That is, for each input block, the messaging component61performs steps as follows. It parses the respective input blocks to obtain the messages for its computational units. Furthermore, it routes the messages to the respective input queues of the different computational units and schedules messages to be executed according to the capacity each computational unit got assigned. Then it uses the execution component62to process a message by the corresponding computational unit, resulting in messages to be sent being added to an output queue of the respective computational unit. However, when the message is destined to a computational unit on the same subnet it may be put directly in the input queue of the corresponding computational unit. The messaging component61finally routes the messages of the output queues of the computational units into message streams for subnets on which the receiving computational units are located and forwards these message streams to the state manager component65to be certified, i.e., signed by the respective subnet.

The state manager component65comprises a certification component65a.The certification component65ais configured to certify the output streams of the respective subnet. This may be performed e.g. by a threshold-signature, a multi-signature or a collection of individual signatures of the computational units of the respective subnet.

FIG.7shows an exemplary visualization of a workflow700of the messaging protocol and the consensus protocol and the associated components, e.g. of the messaging component61and the consensus component63ofFIG.6. More particularly,FIG.7visualizes the workflow of inter-subnet messages exchanged between a subnet SNB and subnets SNA and SNC. Furthermore, the subnet SNB exchanges ingress messages with a plurality of user U.

Starting from the bottom right ofFIG.7, a plurality of input streams701,702and703is received by a consensus component63. The consensus component63is a subnet consensus component that is run by a subnet client of the subnet SNB. The input stream701comprises inter-subnet messages711from the subnet SNA to the Subnet SNB. The input stream702comprises inter-subnet messages712from the subnet SNC to the Subnet SNB. The input stream703comprises ingress messages713from the plurality of users U to the subnet SNB.

The inter-subnet messages711and712comprise inter-subnet unit-to-unit messages to be exchanged between the computational units of the different subnets as well as signalling messages. The signalling messages are used to acknowledge or not acknowledge an acceptance of unit-to-unit messages. The messaging component61is configured to send the signalling messages from a receiving subnet to a corresponding sending subnet, i.e. in this example from the subnet SNB to the subnets SNA and SNC. The messaging component61is according to this example configured to store the sent inter-subnet unit-to-unit messages until an acknowledgement message has been received for the respective unit-to-unit message. This provides a guaranteed delivery.

The consensus component63is configured to receive and process the inter-subnet messages711,712of the subnets SNA, SNC and the ingress messages713of the users U and to generate a queue of input blocks720from the inter-subnet messages711,712and the ingress messages713according to a predefined consensus mechanism that is executed by the corresponding consensus protocol. Each input block720produced by consensus contains a set of ingress messages713, a set of inter-subnet messages711,712and execution parameters714, EP. The execution parameters714, EP may include in particular a random seed, a designated execution time and/or a height index. The consensus component63may also vary the number of messages in every input block based on the current load of the subnet.

The consensus component63provides the queue of input blocks720then to the messaging component61which is configured to execute the messaging protocol and to process the input blocks720.

The messaging protocol and the messaging component61are clocked by the input blocks720received from the consensus component63.

Before processing the received input blocks, the messaging component61may perform one or more preprocessing steps including one or more input checks. The input checks may be performed by an input check component740.

If the input checks have been passed successfully, the messages of the respective input block720may be further processed by the messaging component61and the corresponding messages may be appended to a corresponding queue in an induction pool of an induction pool component731. The induction pool component731of the messaging component61receives input blocks and input messages that have been successfully passed the input check component740and have accordingly been accepted by the messaging component61for further processing.

In general, the messaging component61preprocesses the input blocks720by placing ingress messages, signalling messages and inter-subnet messages into the induction pool component731as appropriate. Signalling messages in the subnet streams are treated as acknowledgements of messages of the output queues which can be purged.

Following these pre-processing steps, the messaging component61invokes the execution component62(seeFIG.6) to execute as much of the induction pool as is feasible during a single execution cycle, providing the designated execution time and the random seed as additional inputs. Following the execution cycle, a resulting output queue of messages, which may also be denoted as output messages, is fed to an output queue component733. Initially the output queue component733comprises unit-to-unit and unit-to-user output queues, in this example the unit-to-unit output queues B1-A1, B1-C2, B2-A2and B2-C3and the unit-to-user output queues B1-U1and B2-U4. As an example, the messages B1-A1denote output messages from the computational unit B1of subnet SNB to the computational unit A1of subnet SNA. As another example, the messages B1-U1denote output messages from the computational unit B1of subnet SNB to the user U1.

The output queue component733post-processes the resulting output queue of the output messages by forming a set of per-subnet output streams to be certified, e.g. by the certification component65aas shown inFIG.6, and disseminated by other components. In this example, the per-subnet output streams SNB-SNA, SNB-SNC and SNB-U are provided.

Hence the messaging component61further comprises a state storage component732that is configured to store the state/unit state of the computational units of the respective subnet, in this example the states of the computational units B1and B2of the subnet SNB. The corresponding unit state is the working memory of each computational unit.

The messaging component61revolves around mutating certain pieces of system state deterministically. In each round, the execution component61will execute certain messages from the induction pool by reading and updating the state of the respective computational unit and return any outgoing messages the executed computational unit wants to send. These outgoing messages or in other words output messages go into the output queue component733, which initially contains unit-to unit messages between computational units of the network. While intra-subnet messages between computational units of the same subnet may be routed and distributed internally within the respective subnet, inter-subnet messages are routed into output streams sorted by subnet-destinations.

In addition, two pieces of state may be maintained according to embodiments to inform the rest of the system about which messages have been processed. A first piece may be maintained for inter-subnet messages and a second piece of state for ingress messages.

In the following the interactions between the mainnet protocol clients51and the subnet protocol clients52is described in more detail (seeFIG.5). The mainnet protocol clients51manages a number of registries that contain configuration information for the subnets. These registries are implemented by computational units on the mainnet. As mentioned according to other embodiments the central registry may be used instead of the mainnet.

FIG.8shows a layer model800illustrating main layers which are involved in the exchange of inter-subnet and intra-subnet messages. The layer model800comprises a messaging layer81which is configured to serve as an upper layer for the inter-subnet communication. More particularly, the messaging layer81is configured to route inter subnet messages between computational units of different subnets. Furthermore, the messaging layer81is configured to route ingress messages from users of the network to computational units of the network.

The layer model800further comprises a plurality of consensus layers82which are configured to receive inter-subnet messages from different subnets as well as ingress messages and to organize them, in particular by agreeing on a processing order, in a sequence of input blocks which are then further processed by the respective subnet. In addition, the layer model800comprises a peer-to-peer (P2P) layer that is configured to organize and drive communication between the nodes of a single subnet.

According to embodiments, the network may comprise a plurality of further layers, in particular an execution layer which is configured to execute execution messages on the computational units of the network.

Referring now toFIG.9, the creation of blocks in distributed networks according to embodiments of the invention is illustrated. The blocks may be in particular the input blocks720shown inFIG.7which are created by the consensus component63that runs the consensus protocol, in particular a local subnet consensus protocol.

In this exemplary embodiment three input blocks901,902and903are illustrated. Block901comprises a plurality of transactions, namely the transactions tx1.1, tx1.2and possibly further transactions indicated with dots. Block902comprises also a plurality of transactions, namely the transactions tx2.1, tx2.2and possibly further transactions indicated with dots. Block903also comprises a plurality of transactions, namely the transactions tx3.1, tx3.2and possibly further transactions indicated with dots. The input blocks901,902and903are chained together. More particularly, each of the blocks comprises a block hash of the previous block. This cryptographically ties the current block to the previous block(s).

According to embodiments the transactions may be inter-subnet messages, ingress messages and signalling messages.

According to embodiments, the input blocks901,902and903may be created by a proof-of-stake consensus-protocol.

However, it should be noted that the input blocks generated by the consensus component do not need to be chained together according to embodiments. Rather any consensus protocol that reaches some kind of consensus between the nodes of a subnet on the processing order of received messages may be used according to embodiments.

FIG.11shows a more detailed illustration of a computational unit1100according to an embodiment of the invention.

The computational unit1110comprises an input queue1101, an output queue1102, an application state1103and a system state1104.

The computational unit1100generally comprises the code of the computational unit and the unit state/execution state of the computational unit.

FIG.12shows a more detailed view of a networking component1200, which is configured to run a networking protocol. The networking component1200may be e.g. a more detailed embodiment of the networking component64shown inFIG.6. The networking component1200comprises a unicast component1210configured to perform a node-to-node communication, a broadcast component1220configured to perform an intra-subnet communication and a cross-net component1230configured to perform an inter-subnet communication. The cross-net component1230may store the subnet-assignment of the computational units as network configuration data or read it from a central registry.

FIG.13shows a more detailed embodiment of a state manager component1300, e.g. of the state manager component65ofFIG.6.

The state manager component1300comprises a storage component1310, a certification component1320and a synchronization component1330. The storage component1310comprises directories1311,1312,1313and1314for storing the unit state, certified variables of the unit state, inbound migrant computational units and outbound migrant computational units respectively. The state manager component1330may also maintain and certify the output streams.

According to embodiments, the certification component1320is configured to run a threshold-signature or multi-signature algorithm to certify the parts of the storage components1310. In particular, the certification component1320may certify migrant computational units that shall be migrated to another subnet and which are placed in the directory1314for outbound migrant computational units.

FIG.14shows a flow chart1400comprising method steps of a computer-implemented method for running a distributed network comprising a plurality of subnets according to embodiments of the invention. The distributed network may be e.g. embodied as the network100as shown inFIG.1.

At a step1410, each subnet of the plurality of subnets runs a set of computational units on its nodes, wherein each of the computational units comprises its own unit state.

At a step1420, the network replicates the set of computational units across the respective subnet.

FIG.15shows a flow chart1500comprising method steps of a computer-implemented method for migrating a computational unit from a first subnet to a second subnet of a distributed network according to an embodiment of the invention. The distributed network may be e.g. embodied as the network100as shown inFIG.1.

At a step1510, the central control unit20signals to the first and the second subnet SNA, SNB a computational unit of the first subnet as migrant computational unit that shall be migrated.

At a step1520, the first subnet SNA prepares the migrant computational unit for migration.

This step1520may include to schedule a migration time/migration block height, e.g. by a computational unit manager. The step1520may further include that the first subnet SNA stops to accept messages for the migrant computational unit after the migration time/migration block height and that the first subnet SNA stops to execute the migrant computational unit and/or to modify the unit state of the migrant computational unit after the migration time/migration block height.

At a step1530, the migrant computational unit at the migration block height is transferred from the first subnet to the second subnet. This may be performed by various transfer mechanisms as explained e.g. with reference toFIGS.3ato3e.

At a step1540, the nodes of the second subnet SNB install the migrant computational unit.

At a step1550, the nodes of the second subnet SNB agree on the activation of the migrant computational unit. This may be performed in particular by performing a consensus protocol.

Finally, at a step1560, the nodes of the second subnet activate and run the transferred migrant computational unit on the second subnet SNB.

FIG.16shows a flow chart1600comprising method steps of a computer-implemented method for migrating a computational unit from a first subnet to a second subnet of a distributed network according to an embodiment of the invention. The distributed network may be e.g. embodied as the network100as shown inFIG.1.

At a step1610, the central control unit20signals to the first subnet SNA a computational unit of the first subnet as migrant computational unit that shall be migrated to a second subnet that is not existent yet and hence has to be newly created.

At a step1620, the nodes of the first subnet create and start the new second subnet by creating a partition for a new replica on their nodes.

At a step1630, the migrant computational unit is transferred from the first subnet to the second subnet internally, i.e. within the respective nodes of the first subnet SNA. Before the transfer the migrant computational unit may be brought into a migrating state.

At a step1640, the nodes of the first subnet which also run the second subnet install the migrant computational unit on the second subnet.

Then the nodes may perform a step of agreeing on the activation.

At a step1650, the nodes of the first and the second subnet start to activate and run the migrant computational unit on the second subnet.

At a step1660, additional nodes may be added to the second subnet that are not part of the first subnet.

At a step1670, the nodes of the first subnet may be removed from the second subnet. Thereby the migration has been finalized.

Referring now toFIG.17, a more detailed block diagram of a network node10according to embodiments of the invention is shown, e.g. of the network100ofFIG.1. The network node10establishes a computing node that may perform computing functions and may hence be generally embodied as computing system or computer. The network node10may be e.g. a server computer. The network node10may be operational with numerous other general purpose or special purpose computing system environments or configurations.

The network node10may be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. The network node10is shown in the form of a general-purpose computing device. The components of network node10may include, but are not limited to, one or more processors or processing units1715, a system memory1720, and a bus1716that couples various system components including system memory1720to processor1715.

Bus1716represents one or more of any of several types of bus structures.

Network node10typically includes a variety of computer system readable media.

System memory1720can include computer system readable media in the form of volatile memory, such as random access memory (RAM)1721and/or cache memory1722. Network node1710may further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, storage system1723can be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and typically called a “hard drive”). As will be further depicted and described below, memory1720may include at least one computer program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the invention.

Program/utility1730, having a set (at least one) of program modules1731, may be stored in memory1720by way of example, and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Program modules1731generally carry out the functions and/or methodologies of embodiments of the invention as described herein. Program modules1731may carry out in particular one or more steps of a computer-implemented method for operating a distributed network, e.g. of one or more steps of the methods as described above.

Network node10may also communicate with one or more external devices1717such as a keyboard or a pointing device as well as a display1718. Such communication can occur via Input/Output (I/O) interfaces1719. Still yet, network node10can communicate with one or more networks1740such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter1741. According to embodiments the network1740may be in particular a distributed network comprising a plurality of network nodes10, e.g. the network100as shown inFIG.1.

Aspects of the present invention may be embodied as a system, in particular a distributed network comprising a plurality of subnets, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, networks, apparatus (systems), and computer program products according to embodiments of the invention.