Migration of Computing Units in Distributed Networks

Abstract

In an embodiment of a first aspect of the present invention, a computer-implemented method for operating a distributed network is provided. The distributed network includes a plurality of subnets embodied as replicated computing clusters. The method further includes migrating a computing unit from a first subnet of the plurality of subnets to a second subnet of the plurality of subnets. The migrating step includes communicating the computing unit of the first subnet to the first subnet and the second subnet as a migrating computing unit. The migrating step further includes transferring the migrating computing unit from the first subnet to the second subnet, installing the migrating computing unit on the second subnet, and booting and running the migrating computing unit on the second subnet. Further aspects of the present invention relate to corresponding distributed networks, nodes, computer program products, and software architectures.

Description

[Technical Field]

[0001] The present invention relates to a method for operating a distributed network, the distributed network comprising a plurality of subnets, each subnet comprising a plurality of nodes. [Background technology]

[0002] Further aspects relate to a corresponding distributed network, nodes of the distributed network, a corresponding computer program product, and a software architecture encoded on a non-transitory medium.

[0003] In a distributed network, multiple nodes are distributed. In computing on a distributed network, software and data are distributed across multiple nodes. The nodes constitute computing resources, and the distributed network may use distributed computing techniques.

[0004] An example of a distributed network is a blockchain network. A blockchain network is a consensus-based electronic ledger made up of blocks. Each block contains multiple transactions and other information. Furthermore, each block is chained by including the hash of the previous block, creating a permanent, immutable record of all transactions written to the blockchain. Transactions may include, for example, small programs known as smart contracts. Before a transaction can be written to the blockchain, it must be "verified" by the network. In other words, network nodes must agree on the block being written to the blockchain. Such agreement can be achieved through various consensus protocols.

[0005] One form of consensus protocol is the proof-of-work consensus protocol. Generally, proof-of-work consensus protocols require some work, usually equivalent to computer processing time, from the parties participating in the consensus protocol. Proof-of-work-based cryptocurrency systems, such as Bitcoin, validate transactions and create new blocks by solving computationally intensive puzzles. Another form of consensus protocol is the proof-of-stake consensus protocol. Such proof-of-stake protocols have the advantage of not requiring time-consuming, energy-intensive computations. In a proof-of-stake-based blockchain network, for example, the creator of the next block is selected through a combination of random selection and the stake of each node in the network. Aside from cryptocurrencies, distributed networks can be used for a variety of other applications. In particular, they can be used to provide decentralized and distributed computing power and services.

[0006] Thus, there is a need for a distributed network with enhanced capabilities. Summary of the Invention [Means for solving the problem]

[0007] SUMMARY OF THE INVENTION It is therefore an object of the present invention to provide a distributed network with enhanced functionality.

[0008] In a first aspect of the present invention, a computer-implemented method for operating a distributed network is provided. The distributed network comprises a plurality of subnets, each of which includes one or more assigned nodes. The method includes executing a set of computing units and assigning each of the set of computing units to one of the plurality of subnets according to a subnet assignment, thereby generating an assigned subset of computing units for each of the plurality of subnets. The method further includes executing the assigned subset of computing units on each node of the plurality of subnets and executing computations across the subnetwork of the plurality of nodes in a deterministic and replicated manner, thereby passing through a chain of execution states. The method further includes migrating a computing unit from a first subnet of the plurality of subnets to a second subnet of the plurality of subnets. The migrating step includes communicating the computing unit of the first subnet to both the first subnet and the second subnet as a migrated migrating computing unit. The migrating step further includes transferring the migrating computing unit from the first subnet to the second subnet, installing the migrating computing unit in the second subnet, and starting and running the migrating computing unit in the second subnet.

[0009] Such embodied methods improve operational flexibility for distributed networks that operate subnets in a replicated manner. In some embodiments, subnets may also be referred to as replicated compute clusters. In such replicated compute clusters, compute units assigned to each subnet run on each node of the subnet and, by replicating across subnets, go through the same chain of execution states. Methods according to embodiments of the invention enable migration of compute units from one subnet to another. This improves network flexibility, particularly with regard to load and capacity management of subnets and their assigned nodes.

[0010] The execution state of such a distributed network, once agreed upon by multiple nodes of a subnet, can be considered immutable in that it can no longer be deleted. Thus, such migration of computational units may, at first glance, be observed as counterintuitive in such a replicated setting.

[0011] Nevertheless, the inventors of the present invention have overcome such preconceptions and designed a distributed network having replicated computing clusters, or subnets that form replicated computing clusters, that allow migration of computing units between subnets.

[0012] In one embodiment, the method further includes the first subnet preparing a migration computing unit to migrate.

[0013] In further embodiments, the method may, inter alia, include the step of preparing the migrating computing unit to migrate including the step of scheduling a migration time. The migration time may be scheduled in various ways. In some embodiments, it may be scheduled by a central controller. In other embodiments, the central controller may simply communicate to each subnet, particularly the first and second subnets, that the computing unit will be migrated. In some embodiments, the central controller may perform an update in a central registry. The first subnet, e.g., the computing unit manager of the first subnet, may then observe the change in the registry and schedule a corresponding migration time. The migration time may, inter alia, define a time to stop accepting messages intended for the migrating computing unit, to stop execution of the migrating computing unit, and / or to change the unit state of the migrating computing unit after the migration time. In other words, after the migration time, the unit state of each computing unit is fixed, i.e., frozen and no longer changed. The computing unit with its fixed state may then be considered ready for migration.

[0014] In one embodiment, multiple subnets are configured to execute blocks consecutively, and the transition time is the block height that defines the last block that the first subnet processes. Note that in some embodiments, because blocks may be processed in an asynchronous manner, the block height does not predefine a specific time on the calendar as the transition time, but rather defines a time relative to a specific block height. In this regard, the term transition time should be understood to have a broad meaning.

[0015] In one embodiment, the step of acquiring the migrating computing unit includes a step of multiple nodes of the second subnet joining the first subnet. This may include the multiple nodes of the second subnet executing the computing unit of the first subnet. By joining the first subnet, the multiple nodes of the second subnet may observe the unit state or execution state of the computing unit of the first subnet, particularly the migrating computing unit. The joining step may be performed particularly before the migration time. This allows the multiple nodes of the second subnet to gain advance confidence in the unit state of the migrating computing unit. Furthermore, downtime is reduced because they may begin acquiring a portion of the state of the migrating computing unit in advance. This facilitates efficient transfer.

[0016] In one embodiment, the nodes of the second subnet may passively participate in the first subnet in listening mode. Listening mode, among other things, includes verifying all artifacts of the first subnet, but not generating the artifacts themselves. In this regard, an artifact may be any information exchanged between the nodes of the first subnet. In one embodiment, the nodes of the second subnet may perform only a subset of the tasks of the second subnet. As an example, they may not participate in, for example, proposing and notarizing blocks, but may verify and execute each block if it is valid.

[0017] In one embodiment, transferring the migrating computing unit from the first subnet to the second subnet includes performing an intra-node transfer of the migrating computing unit between a replica of the first subnet and a replica of the second subnet, where the replica of the first subnet and the replica of the second subnet are executed on the same node.

[0018] A replica is formed by a set of computational units running on a node and assigned to the same subnet.

[0019] In such an embodiment, nodes in a second subnet that join a first subnet run two replicas: a first replica for the first subnet and a second replica for the second subnet. Because both replicas run on the same node, they are in the same trusted domain and observe the state of the computing units of the first subnet, including the state of the migrating computing unit, as the first replica, which may be a passive replica in particular. This state of the migrating computing unit can then be transferred within the node, i.e., within the same trust domain, from the first replica to the second replica, and thus from the first subnet to the second subnet.

[0020] In one embodiment, transferring the migration computing unit includes each node of the second subnet obtaining the migration computing unit from a node of the first subnet via a messaging protocol.

[0021] In such an embodiment, the nodes of the second subnet are not part of the first subnet. In other words, they are not participating in the first subnet. Upon reaching the transition height, the first subnet prepares the transition computation unit to transition. This may include, among other things, having the nodes of the first subnet perform, for example, joint signing on the transition computation unit, thereby attesting to the state of the transition computation unit at the transition block height. The certified transition computation unit may then be communicated to the nodes of the second subnet via a messaging protocol.

[0022] In one embodiment, transferring the computing unit via the messaging protocol includes a node of the first subnet dividing the migrating computing unit into one or more chunks and transferring the one or more chunks of the migrating computing unit from the first subnet to the second subnet via the messaging protocol, which may facilitate efficient transfer, particularly with respect to bandwidth.

[0023] In one embodiment, the messaging protocol may include a state synchronization protocol that synchronizes state between migration computing units on multiple nodes of a first subnet and corresponding migration computing units installed on multiple nodes of a second subnet.

[0024] In one embodiment, the first subnet may reject the transition computing unit's transition time or transition block height message after the transition time or transition block height message, which makes it easier for the sender of the message to resend the respective message.

[0025] In one embodiment, multiple nodes in the second subnet may agree to activate the migration computing unit, particularly by running a consensus protocol. Such a step may ensure that a sufficient number of nodes in the second subnet have available computing units, so that the computing units can become operational after agreement. Furthermore, this may ensure that corresponding nodes start executing the migration computing units at the same time, facilitating deterministic processing.

[0026] In an embodiment of a second aspect of the present invention, another computer-implemented method for operating a distributed network is provided. The distributed network includes a plurality of subnets, each of the plurality of subnets including one or more assigned nodes. The method includes executing a set of computing units and assigning each of the computing units to one of the plurality of subnets according to a subnet assignment, thereby creating a set of assigned subsets of computing units for each of the subnets. The method further includes executing the assigned subsets of computing units on each node of the plurality of subnets, and nodes of the plurality of subnets performing computations across the plurality of subnets in a deterministic and replicated manner. The computer-implemented method includes migrating a computing unit from a first subnet of the plurality of subnets to a second subnet of the plurality of subnets. In this embodiment, the second subnet does not already exist, i.e., a new second subnet must be created. The migrating step includes communicating the computing unit of the first subnet to the first subnet as a migrating computing unit to be migrated. In response to the communication, the nodes of the first subnet create and initiate a new second subnet. The migration computing unit is then transferred internally from the first subnet to the second subnet, i.e., within each node between replicas. This has the advantage that this transfer occurs within the same trusted domain of each node. Further steps include a step in which multiple nodes in the first subnet and the second subnet install the migration computing unit on the second subnet, and a step in which multiple nodes in the first subnet and the second subnet start and run the migration computing unit on the second subnet. Prior to starting and running the migration computing unit, a consensus protocol may be performed to agree on the start-up, among other steps. In a further embodiment of the second aspect, an additional multiple nodes may be added to the second subnet that is not part of the first subnet.These additional nodes are new nodes that may catch up with the state of the migrating compute unit, for example, via a resumability or state recovery protocol.

[0027] A further step may include removing the plurality of nodes of the first subnet from the second subnet, whereby the migration computing unit is completely migrated from the plurality of nodes of the first subnet to another new set of nodes.

[0028] In some embodiments, multiple computing units may be migrated one by one from a first subnet to a second subnet in the manner described above and below.

[0029] In one embodiment of the other aspect of the present invention, there is provided a distributed network configured to perform the method steps of the first aspect of the present invention.

[0030] In an embodiment of the other aspect of the present invention, there is provided a distributed network configured to perform the method steps of the second aspect of the present invention.

[0031] In one embodiment of another aspect of the present invention, a node of a distributed network is provided.

[0032] In one embodiment of another aspect of the present invention, there is provided a computer program product for operating a distributed network, the computer program product comprising a computer-readable storage medium having program instructions embodied therein, the program instructions being executable on one or more of a plurality of nodes of the distributed network to perform steps of a method aspect of the present invention at one or more of the plurality of nodes.

[0033] In one embodiment of another aspect of the present invention, a computer program product for operating a node of a distributed network is provided.

[0034] In one embodiment of another aspect of the present invention, there is provided a software architecture encoded on a non-transitory computer-readable medium, the software architecture being configured to operate one or more nodes of a distributed network, the encoded software architecture comprising program instructions executable by one or more of the plurality of nodes to perform a method at the one or more of the plurality of nodes comprising steps of a method aspect of the present invention.

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

[0036] Further useful embodiments are listed in the dependent claims and the following description.

[0037] The invention will be better understood and further objects will become apparent from the following detailed description, such description being made with reference to the accompanying drawings. [Brief explanation of the drawings]

[0038] [Figure 1] FIG. 1 is an exemplary block diagram of a distributed network according to one embodiment of the present invention. [Figure 2] FIG. 2 shows in more detail the computational units running on the nodes of the network. [Figure 3a] FIG. 3a illustrates steps of a method for migrating a computing unit from a first subnet to a second subnet. [Figure 3b] FIG. 3b shows a method step for migrating a computing unit from a first subnet to a second subnet. [Figure 3c] FIG. 3c illustrates a method step for migrating a computing unit from a first subnet to a second subnet. [Figure 3d] FIG. 3d illustrates a method step for migrating a computing unit from a first subnet to a second subnet. [Figure 3e]FIG. 3e illustrates another mechanism for migrating a migrating computing unit. [Figure 4a] FIG. 4a illustrates steps of a computer-implemented method for migrating a computing unit from a first subnet to a non-existing second subnet. [Figure 4b] FIG. 4b illustrates steps of a computer-implemented method for migrating a computing unit from a first subnet to a non-existing second subnet. [Figure 4c] FIG. 4c illustrates steps of a computer-implemented method for migrating a computing unit from a first subnet to a non-existing second subnet. [Figure 4d] FIG. 4d illustrates steps of a computer-implemented method for migrating a computing unit from a first subnet to a non-existing second subnet. [Figure 4e] FIG. 4e illustrates steps of a computer-implemented method for migrating a computing unit from a first subnet to a non-existing second subnet. [Figure 4f] FIG. 4f illustrates steps of a computer-implemented method for migrating a computing unit from a first subnet to a non-existing second subnet. [Figure 4g] FIG. 4g illustrates steps of a computer-implemented method for migrating a computing unit from a first subnet to a non-existing second subnet. [Figure 5] FIG. 5 illustrates the main processes executed on each node of the network, according to one embodiment of the present invention. [Figure 6] FIG. 6 is a schematic block diagram of the protocol components of a subnet protocol client. [Figure 7] FIG. 7 is an exemplary visualization of the workflow of the messaging and consensus protocols and associated components. [Figure 8]FIG. 8 is a layer model diagram illustrating the major layers involved in the exchange of inter- and intra-subnet messages. [Figure 9] FIG. 9 is a diagram illustrating the creation of an input block of a consensus component according to an exemplary embodiment of the present invention. [Figure 10] FIG. 10 is a timing diagram of the migration of the computational units. [Figure 11] FIG. 11 is a detailed diagram of the calculation unit. [Figure 12] FIG. 12 shows a more detailed view of the network components. [Figure 13] FIG. 13 illustrates a more detailed embodiment of the state manager component. [Figure 14] FIG. 14 is a flowchart including method steps of a computer-implemented method for implementing a distributed network. [Figure 15] FIG. 15 is a flowchart including method steps of a computer-implemented method for migrating a computing unit from a first subnet to a second subnet. [Figure 16] FIG. 16 is a flowchart including method steps of another computer-implemented method for migrating a computing unit from a first subnet to a second subnet. [Figure 17] FIG. 17 is a diagram illustrating an exemplary embodiment of a node according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0039] First, some general aspects and terminology of embodiments of the present invention are introduced.

[0040] In some embodiments, a distributed network comprises multiple nodes arranged in a distributed manner. In computing on such a distributed network, software and data are distributed across multiple nodes. The multiple nodes constitute computing resources, and the distributed network may use, among other things, distributed computing techniques.

[0041] In some embodiments, the distributed network may be specifically embodied as a blockchain network. The term "blockchain" may include all forms of electronic, computer-based distributed ledgers. In some embodiments, the blockchain network may be embodied as a proof-of-work blockchain network. In other embodiments, the blockchain network may be embodied as a proof-of-stake blockchain network.

[0042] A computation unit may be defined as a piece of software running on a node of the distributed network and having its own unit state. The unit state may also be referred to as an execution state. Each of the multiple subnets is configured to replicate a set of computation units, and in particular their states, across the subnet. As a result, the computation units always go through the same chain of unit states or execution states as long as they behave honestly. A computation unit includes its code and its unit state or execution state.

[0043] A messaging protocol may be defined as a protocol that manages the exchange of inter-unit messages. In particular, the messaging protocol may be configured to route inter-unit messages from a sending subnet to a receiving subnet using respective subnet assignments. The subnet assignments indicate to the messaging protocol the respective locations or subnets of the computing units of each communication.

[0044] FIG. 1 illustrates an exemplary block diagram of a distributed network 100 according to an embodiment of the present invention. The distributed network 100 includes multiple nodes 10, which may also be referred to as network nodes 10. The multiple nodes 10 are distributed across multiple subnets 11. In the example of FIG. 1, four subnets 11, designated SNA, SNB, SNC, and SND, are provided. Each of the multiple subnets 11 is configured to execute a set of computing units on each node 10 of the respective subnet 11. In some embodiments, a computing unit is understood as a piece of software, particularly as a piece of software that includes or has its own unit state, or in other words, as an execution state. The network 100 provides intra-subnet communication within each subnet 11. The network 100 includes a communication link 12 for communicating intra-subnet inter-unit messages, particularly between computing units assigned to the same subnet. The network 100 also includes a communication link 13 for communicating inter-subnet communication between different subnets of the subnets 11. The communication link 13 provides inter-subnet inter-unit messages, particularly between computing units assigned to different subnets. Thus, communication link 12 may also be denoted as an intra-subnet or peer-to-peer (P2P) communication link, and communication link 13 may also be denoted as an inter-subnet or subnet-to-subnet (SN2SN) communication link.

[0045] In some embodiments, the unit state is understood to include all data or information used by the computing unit, particularly data that the computing unit stores in variables, as well as data that the computing unit obtains from remote calls. The unit state may particularly represent storage locations in respective memory locations of respective nodes. In some embodiments, the contents of these memory locations are referred to as the unit state at any given time during the execution of the computing unit. The computing unit may particularly be embodied as a stateful computing unit. That is, the computing unit is designed according to embodiments to remember previous events or user interactions. According to some embodiments of the present invention, the subnetworks 11 are configured to replicate a set of computing units across each subnetwork 11. More specifically, the subnetworks 11 are configured to replicate the unit states of a set of computing units across each subnetwork 11.

[0046] Network 100 may, among other things, be a proof-of-stake blockchain network. Proof-of-stake (PoS) describes a method by which blockchain networks reach a distributed consensus on which nodes are allowed to create the blockchain's next block. PoS methods may use weighted random selection, whereby the weight of individual nodes may be determined depending, among other things, on the respective nodes' assets ("stake").

[0047] FIG. 2 shows details of the computing units 15 executing on node 10 of network 100. Network 100 is configured to assign each of the computing units executing on network 100 to one of a number of subnets, in this example, one of subnets SNA, SNB, SNC, and SND, according to a subnet assignment. The subnet assignment of distributed network 100 creates an assigned subset of the entire set of computing units for each of subnets SNA, SNB, SNC, and SND. More specifically, the left side 201 of FIG. 2 shows node 10 of subnet SNA of FIG. 1. The subnet assignment of distributed network 100 assigns a subset of four computing units 15 to subnet SNA. More specifically, computing units CU A1 , C.U. A2 , C.U. A3 , and C.U. A4 A subset of the computation unit CU is assigned to the A1 , C.U. A2 , C.U. A3 , and C.U. A4 The allocation subset of is executed on each node 10 of the subnet SNA. A1 , C.U. A2 , C.U. A3 , and C.U. A4 The allocated subset of A1 , C.U. A2 , C.U. A3 , and C.U. A4 This is replicated throughout the subnet SNA so that each of the nodes 10 of the subnet SNA passes through the same chain of unit states. A1 , C.U. A2 , C.U. A3 , and C.U. A4 This can be done by actively replicating the state of the unit.

[0048] Furthermore, on the right side 202 of Fig. 2, the nodes 10 of the subnet SNB of Fig. 1 are shown. The subnet allocation of the distributed network 100 allocates the subnet SNB to a subset of two computing units 15, more specifically the computing units CU B1 and C.U. B2 The computation unit CU allocates a subset of the B1 and C.U. B2 The allocation subset of is executed on each node 10 of the subnet SNB. B1 and C.U. B2 The allocation subset of is replicated across the subnets SNB and compute units CU B1 and C.U. B2 Each of the traverses the same unit state or execution state, for example, by actively replicating in the space of unit states as described above.

[0049] Figure 2 shows a typical example of migration of computing units between subnet SNA and subnet SNB. More specifically, several nodes in subnet SNA already require four computing units. However, subnet SNB only has two computing units, and the distributed network may need to migrate the computing units CU, for example, for load balancing or other reasons. A4 may decide to migrate from subnet SNA to subnet SNB.

[0050] 1, the distributed network 100 includes a central control unit CCU 20. The central control unit 20 includes a central registry 21 and can provide network control information to multiple nodes of the network. The central control unit 20 manages the migration computing units CU A4 This can be done, for example, by updating the central registry 21 to A4 The compute unit managers (not explicitly shown) of the subnets SNA, SNB, SNC and SND detect such registry changes in the central registry 21 and set the compute units CU A4In some embodiments, the central controller may be configured by a subnet.

[0051] 10, a timing diagram of such a migration of computing units according to an embodiment of the present invention is shown. First, central controller 20 may set each migrating computing unit to a migration state in registry 21.

[0052] At time tN corresponding to block height N, the first subnet SNA, for example, the calculation unit manager of the first subnet SNA, A4 The computing unit manager may observe a change in the central registry 21 indicating or communicating a migration of the first subnet SNA. The computing unit manager may then schedule or initiate a migration time or migration block height. In this example, migration time tN+K corresponds to migration block height N+K. The migration time defines the block height of the last block processed by the first subnet SNA, while the migration computing unit is still part of the first subnet SNA.

[0053] Returning to FIG. 1 , network 100 is configured to exchange inter-subnet messages between computing units of the network via a messaging protocol based on subnet assignment. According to some embodiments, the distributed network may be configured, among other things, to exchange inter-subnet messages 16 between subnets SNA, SNB, SNC, and SND via a messaging protocol. Inter-subnet messages 16 may be embodied, among other things, as inter-subnet inter-unit messages 16a exchanged between computing units assigned to different subnets according to the subnet assignment. For example, distributed network 100 may include computing unit CU as a transmitting computing unit running on subnet SNA. A1 and a computing unit CU as a receiving computing unit running on the subnet SNB. B2and may be configured to exchange unit-to-unit messages M1, 16a between them. Furthermore, the inter-subnet messages 16 may be embodied as transmission messages 16b. The transmission messages 16b may include acknowledgement messages (ACK) adapted to acknowledge acceptance or receipt of the unit-to-unit message, or non-acknowledgement messages (NACK) adapted to not acknowledge acceptance (corresponding to rejection) of the unit-to-unit message, for example, indicating poor transmission.

[0054] Network 100 may be configured, among other things, to store the subnet assignments of computing units 10 as network configuration data, for example, in networking component 1200 shown in Figure 12, and particularly in cross-net component 1230. This information may also be stored in a central registry.

[0055] In a further embodiment, network 100 may be configured to exchange inter-subnet messages 16 via a messaging protocol and a consensus protocol. The consensus protocol may be configured to reach consensus on the selection and / or processing order of inter-subnet messages 16 in each receiving subnet. For example, with reference to subnet SNB, it receives inter-subnet messages 16 from subnets SNA, SNC, and SND. The consensus protocol receives and processes these inter-subnet messages 16 and achieves agreement on the selection and / or processing order of the received inter-subnet messages 16 by implementing a predefined consensus algorithm or mechanism.

[0056] Next, a computer-implemented method for migrating a computing unit from a first subnet to a second subnet will be described with reference to Figures 3a to 3d. More specifically, Figures 3a to 3d show the number of nodes N1, N2, and N3 in the first subnet SNA and the number of nodes N4, N5, and N6 in the second subnet SNB. The first subnet SNA has an assigned subset of four computing units, more specifically, computing units CU A1 , C.U. A2 , C.U. A3 , and C.U. A4 The second subnet SNB is configured to execute an assigned subset of two computing units, more specifically computing units CU B1 and C.U. B2 The system is configured to execute the following: Each of the assigned set of computing units is executed on a node to form a replica of the subset on the respective node; i.e., replica SNA 310 on multiple nodes N1, N2, and N3, and replica SNB 320 on multiple nodes N4, N5, and N6. Such replicas can be considered as partitions of the assigned subset of computing units on multiple nodes of a subnet. In other words, replicas are formed by a set of computing units running on nodes and assigned to the same subnet. In the example of Figure 3a, it is assumed that subnet SNA operates at block height N. Subnet SNB may operate at a different block height, although this is not shown in Figures 3a to 3e for simplicity of illustration. In Figures 3a to 3d, the underlying distributed network allocates computing units CU for load-balancing reasons. A4 To start the migration process, the central control unit 20 starts, for example, the computing unit CU A4 to the transition state to communicate the intended transition to the first subnet SNA and the second subnet SNB.

[0057] Next, the calculation unit manager of the subnet SNA can schedule the migration time / migration block height. In this example, the height of the migration block is block height N+K, where N is the height at which the first subnet or source subnet SNA observes registry changes. The numerical value K can be selected according to the respective configurations of the distributed network and can conform to the needs of each distributed network. As an example, K can be, for example, 10, 100, or 1000, or even more block heights. The larger K is, A4 the longer the respective lead times in the subnets related to the preparation for the transfer of the calculation unit CU become.

[0058] Figure 3b shows a plurality of nodes of the subnets SNA and SNB at the intermediate block height N+X of the subnet SNA. Here, since X<K, the migration block height N+K has not been reached, and the calculation unit CU A4 is still processed by the subnet SNA.

[0059] On the other hand, a plurality of nodes N4, N5, N6 of the second subnet SNB participate in the first subnet SNA and start executing the calculation units CU A1 、CU A2 、CU A3 、and CU A4 as local replicas 330. In other words, nodes N4, N5, and N6 are creating a new partition currently being used to execute the calculation unit of the subnet SNA.

[0060] A plurality of nodes of the second subnet SNB can execute the replica 310 of the subnet SNA, especially as passive replicas. In other words, they do not fully participate in the subnet SNA and only execute a limited part of the operation of the subnet SNA. In particular, the replica 310 updates the states of the calculation units CU A1 、CU A2 、CU A3 、and CU A4 and, for this purpose, the calculation units CU A1 、CU A2 、CUA3 , and C.U. A4 This passive participation may be particularly A4 In other words, by observing and partially participating in the subnet SNA, multiple nodes N4, N5, and N6 may be able to communicate with the computing unit CU during the lead time between the transmitting height N and the transition height N+K. A4 It reliably transfers the state of the ,into its own internal trusted region in advance, and then only follows the execution of valid blocks to reach the transitional high state.

[0061] Figure 3c shows several nodes of subnets SNA and SNB at block height N+K+1 of subnet SNA. A4 To take over the processing of the block, nodes N4, N5, and N6 allocate a computing unit CU A4 More specifically, the passive replicas 330 are stopped and the final state of the computation units CU at block height N+K is transferred internally. A4 The final state of is transferred to the directory 340 of the nodes N4, N5 and N6, for example, assigned to the inbound computing unit. The replica 320 of the subnet SNB then transfers the state of the inbound computing unit CU from the internal directory 340 via an internal reliable communication mechanism 350. A4 The replica 320 may then receive or acquire the computation unit CU A4 and launches the computation units CU on the subnet SNB, in particular on the corresponding replicas 320 of the nodes N4, N5 and N6 for the subnet SNB. A4 may begin executing.

[0062] During a transition period, the nodes of the first subnet SNA are connected to the computing units CU A4 The copy may still contain a replica of the compute unit CUA4 is no longer actively executed by replica SNA on multiple nodes N1, N2, and N3. A4 is shown by the dotted line.

[0063] Figure 3d shows the nodes of the subnets SNA and SNB at block height N+K+2, where the nodes of the first subnet SNA are computing units CU A4 completely removed and the compute unit CU A1 , C.U. A2 , and C.U. A3 Only the replica SNA 310 of the subnetwork having SNA 310 is executed.

[0064] Furthermore, the computation unit CU A4 is fully integrated into the subnet SNB and is executed by replica SNB 320 in nodes N4, N5, and N6. The migration computation unit is denoted as CU in Fig. 3d. B3 / A4 and the previous calculation unit CU A4 is shown to run on the subnet SNB as the third computational unit.

[0065] Here, the transition calculation unit CU A4 Another mechanism for migrating blocks will be described with reference to Fig. 3e. The example shown in Fig. 3e also starts from the initialization shown in Fig. 3a. Fig. 3e shows nodes N1 to N6 at block height N+K+1. After nodes N1, N2, and N3 process block N+K, the migration computation unit CU A4 The replica SNA 310 transfers the corresponding final state to a dedicated storage space, for example the directory 360 of the nodes N1, N2 and N3 assigned to the outbound computing unit. The replica 320 of the subnet SNB then transfers the state information from the directory 360 to the computing unit CU via a messaging protocol 370 that establishes an inter-subnet communication mechanism between the subnet SNA and the subnet SNB. A4In such an embodiment, the nodes N4, N5, and N6 of the second subnet SNB are not participating in the first subnet. After reaching the transition height N+K, the first subnet SNA may receive or acquire the state of the transition calculation unit CU for the transition. A4 and placed it in directory 360. In some embodiments, the calculation unit CU A4 may be authenticated by nodes N1, N2, and N3, for example by joint signature. A4 Upon receiving , the replica 320 may agree to wake it up and start the computation unit CU on the subnet SNB. A4 In this way, the nodes N4, N5, and N6 execute the calculation units CU B3 / A4 may be treated as part of the subnet SNB.

[0066] Referring now to Figures 4a through 4g, a computer-implemented method for migrating a computing unit from a first subnet to a second subnet according to another embodiment of the present invention will be described.

[0067] Figure 4a shows a number of nodes N1, N2 and N3 of the first subnet SNA. The first subnet SNA comprises three computing units, more specifically computing units CU A1 , C.U. A2 , and C.U. A3 In the embodiment shown in Figures 4a to 4g, the distributed network is configured to perform an allocation subset of the computing units CU of the first subnet SNA. A3 The central control unit 20 operates to migrate the computing units CU to a non-existing subnet SNB, i.e., a newly created subnet SNB. A3 By setting the computing unit CU to the migration state, the intended migration is communicated to the first subnet SNA and the migration process is initiated. A3may be referred to as a migration computing unit. Furthermore, for example, the central control unit 20 or the computing unit manager of the subnet SNA, or some other entity or mechanism, schedules a migration time or migration block height. Then, as shown in FIG. 4b, nodes N1, N2, and N3 of the first subnet SNA create a new second subnet SNB and start running the new second subnet SNB. This involves creating a new partition for the second subnet SNB on nodes N1, N2, and N3. Thus, each of nodes N1, N2, and N3 has created a new replica SNB 420 for the subnet SNB. Then, nodes N1, N2, and N3 may stop running the migration computing unit on the first subnet SNA. Next, as shown in FIG. 4c, nodes N1, N2, and N3 start running the migration computing unit CU. A3 / B1 and transfers the first subnet SNA migration calculation unit CU to the new subnet SNB as the first calculation unit. A3 / B1 Therefore, in the following, we will refer to the transition computation unit as CU A3 / B1 When nodes N1, N2, and N3 run both subnets SNA and SNB, the computing unit CU A3 is the computation unit CU in the same node. A3 / B1 Therefore, it can be transferred internally from replica SNA 410 to replica SNB 420 within the same trust domain. Since both replica SNA and SNB run on the same node, replica SNB can, in some embodiments, transfer the first replica SNA to the compute unit CU at migration block height N+K. A3 Then, the replica SNB receives the first replica SNA of the same node from the computing unit CU via the node-internal communication mechanism 430. A3 For example, the replica SNA may receive this status from the computing unit CU A3 The replica SNB may store the data in a dedicated directory in the file system of each selectable node. A3 / B1Once the CU is transferred via the internal communication or forwarding mechanism 430, the nodes N1, N2 and N3 transfer the migration computation unit CU to the newly created second subnet SNB. A3 / B1 Agree to install and start the migration Compute Unit CU A3 / B1 can be performed.

[0068] FIG. 4d illustrates a transition period, during which replica SNA 410 is A3 still in inactive mode. Meanwhile, the migrated compute unit CU A3 / B1 is already running on the new replica SNB420.

[0069] In Fig. 4e, nodes N1, N2 and N3 are shown, where the transition computation units CU A3 has already been removed from the replica SNA and the migration compute unit CU A3 / B1 is running on the new replica SNB on nodes N1, N2, and N3.

[0070] Figure 4f illustrates the new set of nodes, which comprises additional or new nodes N4, N5, and N6, which are added to the second subnet SNB to implement migration computation units CU on their respective replica SNBs of the second subnet SNB. A3 / B1 The new nodes N4, N5, and N6 have already started to execute the migration computation unit CU from the nodes N1, N2, and N3 via the transfer mechanism 450. A3 / B1 This transfer of the migration computation unit may be performed by some messaging protocol between the nodes, for example, a state synchronization protocol. A3 / B1 Since the transfer of is between different nodes, i.e., between two different trust domains, the computation unit CU A3 / B1The state of N1 is transferred in an authenticated manner, for example, using the joint signature of nodes N1, N2, and N3. In some embodiments, this mechanism for adding new nodes may be delegated to a protocol for joining the subnet and catching up the entire state of the subnet.

[0071] In Figure 4g, the transition calculation unit CU A3 shows nodes N1, N2, and N3 that have already been removed from the replica SNA. Here, the migration computation unit CU A3 / B1 is executed only on the new replica SNBs of the additional or new nodes N4, N5, and N6.

[0072] The mechanism described with reference to Figures 4a to 4g uses a kind of "spin-off" approach to migrating computation units. Nodes that initially execute the migrating computation units first start a new subnet, which is another partition. They then initially transfer the migrating computation units internally to the newly created partition that makes up the newly created subnet. This transfer occurs within the same trust domain. New nodes can then be added to the newly created second subnet and take over the operation of the newly created second subnet. Meanwhile, the previous nodes of the first subnet can be removed from the second subnet. This approach has the advantage that the initial transfer of the migrating computation units from the first subnet to the second subnet occurs internally within the corresponding node, i.e., within the same trust domain. Furthermore, the transfer via the transfer mechanism 450 between different nodes on the network is mandatory because the migrating computation units CU A3 / B1 This can facilitate smooth, efficient and fast migration of the migration computing unit.

[0073] 5 illustrates the major processes that may be performed on each node 10 of network 100, according to one embodiment of the present invention. The network client of the network of some embodiments of the present invention is the set of protocol components required by a node 10 to participate in the network. In some embodiments, each node 10 is a member of a mainnet. Additionally, each node may be a member of one or more subnets.

[0074] Node manager 50 is configured to start, restart, and update mainnet protocol clients 51, subnet protocol clients 52, and security applications 53. In some other embodiments, central controller 20 may be used as a substitute for mainnet protocol clients (see FIG. 1). In some embodiments, several subnet protocol clients may be used to implement several replicas.

[0075] In some embodiments, each of the multiple subnets 11 is configured to run a separate subnet protocol client 52 on the corresponding nodes 10. The mainnet protocol client 51 is specifically configured to distribute configuration data on and among the multiple subnets 11. The mainnet protocol client 51 may be specifically configured to run only system computing units, not user-provided computing units. The mainnet protocol client 51 is a local client of the mainnet, and the subnet protocol client 52 is a local client of the subnet. The security application 53 stores the private keys of the nodes 10 and performs corresponding operations. The node manager 50 may, for example, monitor the registry 21 of the control device 20 and instruct the nodes to join the subnet. It may also move computing units to the partition of the node joining the second subnet and / or instruct the node to stop participating in the subnet.

[0076] FIG. 6 illustrates a schematic block diagram of a protocol component 600 of a subnet protocol client, e.g., subnet protocol client 52 of FIG. 5. Solid arrows in FIG. 6 relate to inter-unit messages and ingress messages. Dashed arrows relate to system information. Protocol component 600 includes a messaging component 61 configured to execute a messaging protocol and an execution component 62 configured to execute an execution protocol. The execution protocol executes execution messages, particularly inter-unit messages and / or ingress messages. Protocol component 600 further includes a consensus component 63 configured to execute a consensus protocol, a networking component 64 configured to execute a networking protocol, a state manager component 65 configured to execute a state manager protocol, an X-Net component 66 configured to execute an inter-subnet forwarding protocol, and an ingress message handler component 67 configured to process ingress messages received from external users of the network. Protocol component 600 further includes a cryptographic component 68. The cryptographic component 68 cooperates with a security component 611, which may be embodied, for example, as security application 53 described with reference to FIG. 5. Additionally, the subnet protocol clients 52 may cooperate with a leader component 610, which may be part of the mainnet protocol clients 51, as described with reference to Figure 5. The leader component 610 may provide information that the mainnet stores and distributes to each subnet protocol client 52, including the assignment of nodes to subnets, node public keys, the assignment of compute units to subnets, etc.

[0077] The messaging component 61 and the execution component 62 are configured such that all computations, data, and state in these components are replicated identically across all nodes in their respective subnets, and more specifically, across all honest nodes in their respective subnets. This is illustrated as a wave pattern in the background of these components. On the one hand, the consensus component 63 ensures that the input stream to the messaging component 61 is agreed upon by each subnet and is therefore identical across all nodes, and more specifically, across all honest nodes, thereby achieving such identical replication in some embodiments. On the other hand, this is achieved by the fact that the messaging component 61 and the execution component 62 are configured to perform deterministic, replicated computations.

[0078] The X-Net forwarding component 66 sends message streams to and receives message streams from other subnets. Most of the components access the crypto component 68 to run cryptographic algorithms and the Mainnet reader 70 to read configuration information.

[0079] The execution component 62 receives the unit status of the computation unit and the incoming messages of the computation unit from the messaging component 61, and returns the outgoing messages of the computation unit and the updated unit status. During execution, the gas consumption of the processing messages (queries) may also be measured. The messaging component 61 is clocked by the input blocks received from the consensus component 63. That is, for each input block, the messaging component 61 performs the following steps: Analyze each input block to obtain messages for that computation unit. Furthermore, messages are sent to the input queues of the different computation units, and messages to be executed are scheduled according to the allocated capacity of each computation unit. Then, the execution component 62 processes the messages by the corresponding computation unit, and adds the resulting messages to be sent to the output queues of the respective computation units. However, when a message is destined for a computation unit on the same subnet, the message may be placed directly in the input queue of the corresponding computation unit. The messaging component 61 finally routes messages in the output queue of the computing unit to the message stream of the subnet in which the receiving computing unit is located and forwards these message streams to the state manager component 65 where they are authenticated, i.e., signed by the respective subnet.

[0080] State manager component 65 includes authentication component 65a, which is configured to authenticate the output stream of each subnet, which may be performed, for example, by threshold signatures, multiple signatures, or a collection of individual signatures of the computing units of each subnet.

[0081] Figure 7 illustrates a workflow 700 of messaging and consensus protocols and associated components, e.g., an exemplary visualization of messaging component 61 and consensus component 63 of Figure 6. More specifically, Figure 7 visualizes the workflow of inter-subnet messages exchanged between a subnet SNB, a subnet SNA, and a subnet SNC. The subnet SNB also exchanges ingress messages with multiple users U.

[0082] Starting from the bottom right of FIG. 7, multiple input streams 701, 702, and 703 are received by consensus component 63. Consensus component 63 is a subnet consensus component executed by a subnet client of subnet SNB. Input stream 701 includes inter-subnet messages 711 from subnet SNA to subnet SNB. Input stream 702 includes inter-subnet messages 712 from subnet SNC to subnet SNB. Input stream 703 includes ingress messages 713 from multiple users U to subnet SNB. Inter-subnet messages 711 and 712 comprise intra-subnet inter-unit messages and propagation messages exchanged between computing units of different subnets. Propagation messages are used to acknowledge or not acknowledge acceptance of inter-unit messages. Messaging component 61 is configured to send propagation messages from the receiving subnet to the corresponding sending subnet, i.e., in this example, from subnet SNB to subnet SNA and subnet SNC. The messaging component 61, in this example, is configured to store inter-unit messages sent between subnets until an acknowledgement message is received for each inter-unit message, which provides a guarantee of delivery.

[0083] The consensus component 63 is configured to receive and process inter-subnet messages 711 and 712 of the subnet SNA and subnet SNC of user U, as well as ingress messages 713 of multiple users U, to generate a queue of input blocks 720 from the inter-subnet messages 711, 712, and ingress messages 713 according to a predetermined consensus mechanism implemented by a corresponding consensus protocol. Each input block 720 generated by consensus includes a set of ingress messages 713, a set of inter-subnet messages 711 and 712, and execution parameters 714 (EP). The execution parameters 714 (EP) may include, among other things, a random seed, a specified execution time, and / or a height index. The consensus component 63 may also modify the number of messages in each input block based on the current load of the subnet.

[0084] The consensus component 63 provides a queue of input blocks 720 to a messaging component 61 configured to execute the messaging protocol and process the input blocks 720. The messaging protocol and messaging component 61 are clocked by the input blocks 720 received from the consensus component 63.

[0085] Before processing a received input block, the messaging component 61 may perform one or more pre-processing steps, including one or more input checks. The input checks may be performed by the input check component 740. When the input checks pass, the message of each input block 720 may be further processed by the messaging component 61. The corresponding message may also be added to a corresponding queue in a directed pool of the directed pool component 731. The directed pool component 731 of the messaging component 61 receives input blocks and input messages that pass the input check component 740 and are accepted by the messaging component 61 for further processing. In general, the messaging component 61 places ingress messages, propagation messages, and inter-subnet messages, as needed, in the directed pool component 731 to perform pre-processing of the input block 720. Propagation messages in the subnet stream are considered acknowledgments of messages in the purgeable output queue. In this example, the directed pool component 731 comprises subnet-to-unit queues SNA-B1, SNC-B1, SNA-B2, and SNC-B2, and user-to-unit queues U-B1 and U-B2.

[0086] Following these preprocessing steps, the messaging component 61 invokes the execution component 62 (see FIG. 6) to execute as many guided pools as possible during a single execution cycle, providing the specified execution time and a random seed as additional inputs. Following the execution cycle, the resulting message output queues, also referred to as output messages, are sent to the output queue component 733. Initially, the output queue component 733 includes inter-unit and unit-to-user output queues, in this example, inter-unit output queues B1-A1, B1-C2, B2-A2, and B2-C3, as well as unit-to-user output queues B1-U1 and B2-U4. As an example, message B1-A1 represents an output message from computing unit B1 of subnet SNB to computing unit A1 of subnet SNA. As another example, message B1-U1 represents an output message from computing unit B1 of subnet SNB to user U1. The output queue component 733 performs post-processing of the resulting output queue of output messages, for example, by forming a series of per-subnet output streams that are authenticated by the authentication component 65a shown in Figure 6 and distributed by other components. In this example, per-subnet output streams SNB-SNA, SNB-SNC, and SNB-U are provided.

[0087] Therefore, the messaging component 61 further comprises a state storage component 732 configured to store the state or unit state of the computing units of each subnet, in this example, the states of computing units B1 and B2 of subnet SNB. The corresponding unit state is the working memory of each computing unit. The messaging component 61 revolves around deterministically changing certain parts of the system state. In each round, the execution component 61 reads and updates the state of each computing unit, executing certain messages from the induced pool and returning any outgoing messages that the executed computing unit wants to send. These outgoing messages, or output messages, are first entered into an output queue component 733, which contains inter-unit messages between computing units of the network. While intra-subnet messages between computing units of the same subnet can be routed and distributed internally within each subnet, inter-subnet messages are routed to output streams separated by subnet destination.

[0088] Additionally, in some embodiments, two pieces of state may be maintained to inform the rest of the system about which messages have been processed: a first part may be maintained for inter-subnet messages and a second part may be maintained for ingress messages.

[0089] In the following, the interaction between the Mainnet Protocol Client 51 and the Subnet Protocol Client 52 is described in more detail (see Figure 5). The Mainnet Protocol Client 51 manages a number of registries containing configuration information for subnets. These registries are implemented by computational units on the Mainnet. According to other embodiments, a central registry can be used as an alternative to the Mainnet.

[0090] FIG. 8 illustrates a layer model 800, depicting the main layers involved in the exchange of inter-subnet and intra-subnet messages. The layer model 800 includes a messaging layer 81 configured to function as an upper layer for inter-subnet communication. More specifically, the messaging layer 81 is configured to send inter-subnet messages between computing units of different subnets. Furthermore, the messaging layer 81 is configured to send ingress messages from users of the network to computing units of the network. The layer model 800 also includes a plurality of consensus layers 82. The consensus layer 82 is configured to receive inter-subnet messages and ingress messages from different subnets and organize them, particularly by agreeing on a processing order, where each subnet is included in the order of input blocks for further processing. The layer model 800 also includes a peer-to-peer (P2P) layer configured to organize and drive communication between nodes of a single subnet. In some embodiments, the network may include multiple additional layers, particularly an execution layer configured to execute messages on computing units of the network.

[0091] Referring to FIG. 9, block generation in a distributed network is illustrated in accordance with an embodiment of the present invention. A block may be, in particular, the input block 720 shown in FIG. 7, which is created by the consensus component 63 running a consensus protocol, specifically the local subnet consensus protocol. In this exemplary embodiment, three input blocks 901, 902, and 903 are illustrated. Block 901 includes multiple transactions, namely, transactions tx1.1, tx1.2, and possibly additional transactions indicated by dots. Block 902 also includes multiple transactions, namely, transactions tx2.1, tx2.2, and possibly additional transactions indicated by dots. Block 903 also includes multiple transactions, namely, transactions tx3.1, tx3.2, and possibly additional transactions indicated by dots. Input blocks 901, 902, and 903 are chained together. More specifically, each of the blocks includes the block hash of the previous block, which cryptographically links the current block to the previous block. In some embodiments, transactions may be inter-subnet messages, ingress messages, and propagation messages. According to some embodiments, input blocks 901, 902, and 903 may be created by a proof-of-stake protocol. Note, however, that the input blocks generated by the consensus component need not be chained together in some embodiments. Rather, in some embodiments, any consensus protocol may be used that reaches some type of consensus among multiple nodes of a subnet regarding the processing order of received messages.

[0092] 11 shows a more detailed diagram of a compute unit 1100 according to an embodiment of the present invention. The compute unit 1110 comprises an input queue 1101, an output queue 1102, an application state 1103, and a system state 1104. The compute unit 1100 generally comprises the code of the compute unit and the unit state or execution state of the compute unit.

[0093] 12 illustrates a more detailed diagram of a networking component 1200 configured to execute a networking protocol. Networking component 1200 may be, for example, a more detailed embodiment of networking component 64 illustrated in FIG. 6. Networking component 1200 includes a unicast component 1210 configured to execute inter-node communications, a broadcast component 1220 configured to execute intra-subnet communications, and a cross-net component 1230 configured to execute inter-subnet communications. Cross-net component 1230 stores the subnet assignments of computing units as network configuration data or can read them from a central registry.

[0094] Figure 13 illustrates a more detailed embodiment of a state manager component 1300, for example, state manager component 65 illustrated in Figure 6. State manager component 1300 includes a storage component 1310, an authentication component 1320, and a synchronization component 1330. Storage component 1310 includes a directory 1311 for storing unit states, a directory 1312 for storing authentication variables for unit states, a directory 1313 for storing inbound transition computation units, and a directory 1314 for storing outbound transition computation units. State manager component 1330 may also maintain and authenticate output streams.

[0095] In some embodiments, authentication component 1320 is configured to perform a threshold signature or multi-signature algorithm to authenticate parts of storage component 1310. In particular, authentication component 1320 may authenticate migration computing units that are migrated to other subnets and placed in directory 1314 as outbound migration computing units.

[0096] 14 shows a flowchart 1400 including method steps of a computer-implemented method for implementing a distributed network including multiple subnets, according to some embodiments of the present invention. The distributed network may be embodied, for example, as network 100 shown in FIG. 1. In step 1410, each subnet of the multiple subnets executes a set of computational units on its nodes, each of which includes its own unit state. In step 1420, the network replicates the set of computational units across each subnet.

[0097] FIG. 15 shows a flowchart 1500 including method steps of a computer-implemented method for migrating a computing unit from a first subnet to a second subnet of a distributed network according to one embodiment of the present invention. The distributed network may be embodied, for example, as the network 100 shown in FIG. 1. In step 1510, the central controller 20 communicates the computing unit of the first subnet to the first subnet SNA and the second subnet SNB as a migrating computing unit to be migrated. In step 1520, the first subnet SNA prepares the migrating computing unit for migration. This step 1520 may include, for example, the computing unit manager scheduling a migration time or a migration block height. Step 1520 may further include the first subnet SNA stopping accepting messages for the migrating computing unit after the migration time or migration block height, the first subnet SNA stopping execution of the migrating computing unit, and / or changing the unit state of the migrating computing unit after the migration time or migration block height.

[0098] In step 1530, the migration computation unit of the migration block height is transferred from the first subnet to the second subnet. This can be performed by various transfer mechanisms, for example, as described with reference to Figures 3a to 3e. In step 1540, the nodes of the second subnet SNB install the migration computation unit. In step 1550, the nodes of the second subnet SNB agree to activate the migration computation unit. This can be done, in particular, by executing a consensus protocol. Finally, in step 1560, the nodes of the second subnet SNB activate and run the transferred migration computation unit on the second subnet SNB.

[0099] 16 illustrates a flowchart 1600 including method steps of a computer-implemented method for migrating a computing unit from a first subnet to a second subnet of a distributed network, according to one embodiment of the present invention. The distributed network may be embodied, for example, as network 100 shown in FIG.

[0100] In step 1610, the central controller 20 notifies the first subnet SNA of the computing unit of the first subnet as a migration computing unit to be migrated to the second subnet. The second subnet does not yet exist, so a new one must be created. In step 1620, the nodes of the first subnet create and start a new second subnet by creating a partition for a new replica on their nodes. In step 1630, the migration computing unit is transferred internally from the first subnet to the second subnet, i.e., within each node of the first subnet SNA. Even before migration, the migration computing unit can be in a migration state.

[0101] In step 1640, the nodes of the first subnet that also run the second subnet install a migration computing unit on the second subnet. The nodes may then perform a step of agreeing to start up. In step 1650, the nodes of the first subnet and the second subnet start up and begin running the migration computing unit on the second subnet. In step 1660, additional nodes that are not part of the first subnet may be added to the second subnet. In step 1670, the nodes of the first subnet may be removed from the second subnet. This completes the migration.

[0102] Referring to FIG. 17, a more detailed block diagram of a network node 10 according to an embodiment of the present invention is shown, for example, in the network 100 of FIG. 1. The network node 10 constitutes a computing node capable of performing computing functions and may therefore be embodied generally as a computing system or computer. The network node 10 may be, for example, a server computer. The network node 10 may operate in numerous other general-purpose or special-purpose computing system environments or configurations. The network node 10 may be described in the general context of computer system-executable instructions, such as program modules, executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The network node 10 is shown in the form of a general-purpose computing device. Components of the network node 10 may include, but are not limited to, one or more processors or processing units 1715, a system memory 1720, and a bus 1716 that couples various system components, including the system memory 1720, to the processor 1715. Bus 1716 represents one or more of any of several types of bus structures. Network node 10 typically includes a variety of computer system-readable media. System memory 1720 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 1721 and / or cache memory 1722. Network node 1710 may further include other removable or non-removable, volatile or non-volatile computer system storage media. By way of example only, storage system 1723 may be configured for reading from and writing to non-removable, non-volatile magnetic media (not shown, commonly referred to as a "hard drive"). As further illustrated and described below, memory 1720 may include at least one computer program product having a series of program modules (e.g., at least one) configured to perform the functions of embodiments of the present invention.The programs or utilities 1730 may include a series of program modules 1731 (at least one), which may be stored in memory 1720, for example, but not limited to, 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 any combination thereof, may comprise an implementation of a networking environment. The program modules 1731 generally perform the functions and / or methods of the embodiments of the invention described herein. The program modules 1731 may, among other things, perform one or more steps of a computer-implemented method of operating a distributed network, e.g., one or more steps of the methods described above. The network node 10 may also communicate with one or more external devices 1717, such as a keyboard or pointing device, and a display 1718. Such communication may occur via an input / output (I / O) interface 1719. Additionally, network node 10 can communicate with one or more networks 1740, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet), through network adapter 1741. In some embodiments, network 1740 may be, among other things, a distributed network comprising multiple network nodes 10, e.g., network 100 shown in FIG.

[0103] Aspects of the present invention may be embodied as a system, particularly a distributed network with multiple subnets, a method, and / or a computer program product, which may include a computer-readable storage medium (or media) having computer-readable program instructions for a processor to perform aspects of the present invention.

[0104] A computer-readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but 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 thereof. As used herein, computer-readable storage medium should not be interpreted as a transitory signal itself, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted through a wire.

[0105] The computer-readable program instructions described herein can be downloaded to a respective computing or processing device, from a computer-readable storage medium, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The computer-readable program instructions for carrying out the operations of the present invention may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages.

[0106] 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.

[0107] Computer-readable program instructions according to embodiments of the present invention may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, whereby the instructions, when executed by the processor of the computer or other programmable data processing apparatus, produce means for implementing the function / act specified in the flowchart and / or block diagram block or blocks. These computer-readable program instructions may also be stored on a computer-readable storage medium capable of instructing a computer, programmable data processing apparatus, and / or other device to function in a particular manner. The computer-readable storage medium with stored instructions comprises a product containing instructions that implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0108] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to generate a series of operational steps performed on the computer, other programmable apparatus, or other device to generate a computer-implemented process executed on the computer, other programmable apparatus, or other device, such that the instructions executing on the computer, other programmable data processing apparatus, or other device implement the functions / acts specified in the flowcharts and / or block diagrams or blocks.

[0109] The illustrated flowcharts and block diagrams illustrate the architecture, functionality, and operation of possible implementations of networks, systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, comprising one or more executable instructions that implement a particular logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently. The blocks may also be executed in the reverse order, depending on the functionality involved.

[0110] While presently preferred embodiments of the invention have been shown and described herein, it is to be expressly understood that the invention is not limited thereto and may be variously embodied and carried out in other ways within the scope of the appended claims.

Claims

1. 1. A computer-implemented method for operating a distributed network, the distributed network comprising a plurality of subnets, each of the plurality of subnets including one or more assigned nodes, the method comprising: executing a series of computational units; assigning each of the set of computing units to one of the plurality of subnets according to a subnet assignment, thereby generating an assigned subset of the set of computing units for each of the plurality of subnets; executing the assigned subset of computing units on each node of the plurality of subnets; replicating the assigned subset of computing units across each of the subnets; migrating a computing unit from a first subnet of the plurality of subnets to a second subnet of the plurality of subnets, the migrating step comprising: communicating a computing unit of the first subnet to the first subnet and the second subnet as a migrating computing unit to be migrated; transferring the migrating computing unit from the first subnet to the second subnet; installing the migration computing unit in the second subnet; booting and running the migration computing unit on the second subnet; the plurality of nodes of the second subnet executing a consensus protocol to agree on the activation of the migration computing unit.

2. The computer-implemented method of claim 1 , further comprising the step of the first subnet preparing the migrating computing unit for migration.

3. The method is particularly characterized in that the step of preparing the migration computing unit for migration comprises: scheduling a transition time; ceasing to accept messages intended for the migration computing unit after the migration time; The computer-implemented method of claim 1 or 2, further comprising: ceasing execution of the transition computing unit and / or changing of the unit state of the transition computing unit after the transition time.

4. the plurality of subnets are configured to execute the plurality of blocks in a sequential manner; The computer-implemented method of claim 3 , wherein the transition time corresponds to a block height that defines the last block that the first subnet processes.

5. The step of obtaining the transition calculation unit includes: The computer-implemented method of claim 1 , further comprising the step of the plurality of nodes of the second subnet joining the first subnet.

6. 6. The computer-implemented method of claim 5, wherein the plurality of nodes of the second subnet passively join the first subnet in a listening mode, the listening mode including, among other things, verifying all artifacts of the first subnet but not generating the artifacts themselves.

7. The computer-implemented method of claim 5 or 6, wherein the joining step is performed on or before the transition time.

8. 8. The computer-implemented method of claim 5, wherein the step of transferring the migrating computing unit from the first subnet to the second subnet comprises performing an intra-node transfer of the migrating computing 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 are executed on the same node.

9. The step of transferring the transfer computation unit includes:

5. The computer-implemented method of claim 1, further comprising the step of each node of the second subnet obtaining the migration computing unit from a node of the first subnet via a messaging protocol.

10. The step of transferring the computing unit comprises: the plurality of nodes of the first subnet dividing the migration computing unit into one or more chunks; 10. The computer-implemented method of claim 9, further comprising: transferring the one or more chunks of the migrating computing unit from the first subnet to the second subnet via a messaging protocol.

11. 11. The computer-implemented method of claim 1, further comprising the step of the first subnet rejecting messages to the migration computing unit after the migration time, thereby facilitating retransmission of each of the messages.

12. The computer-implemented method of claim 1 , wherein the distributed network comprises a central controller, the central controller configured to perform the step of initiating the migration of the migration computing units.

13. Each of the plurality of nodes includes a node manager, the node manager comprising: monitoring a registry of said central controller; instructing the plurality of nodes to join a subnet; moving the computing unit to a partition of a node that joins the second subnet; and / or and instructing the plurality of nodes to cease participating in the subnet.

14. 1. A computer-implemented method for operating a distributed network, the distributed network comprising a plurality of subnets, each of the plurality of subnets including one or more assigned nodes, the method comprising: executing a series of computational units; assigning each of the set of computing units to one of the plurality of subnets according to a subnet assignment, thereby generating an assigned subset of the set of computing units for each of the plurality of subnets; executing the assigned subset of computing units on each node of the plurality of subnets; the plurality of nodes of the plurality of subnets performing a plurality of computations across the plurality of subnets in a deterministic and replicated manner; migrating a computing unit from a first subnet of the plurality of subnets to a second subnet of the plurality of subnets that is not an existing subnet, the migrating step comprising: communicating a computing unit of the first subnet to the first subnet as a migration computing unit to be migrated; the plurality of nodes of the first subnet initiating the second subnet; the plurality of nodes of the first subnet and the second subnet internally transferring the migration computing unit from the first subnet to the second subnet; the plurality of nodes of the first subnet and the second subnet installing the migration computing unit on the second subnet; the plurality of nodes of the first subnet and the second subnet booting and running the migration computing unit on the second subnet.

15. 15. The computer-implemented method of claim 14, further comprising adding a plurality of additional nodes of the second subnet that are not part of the first subnet.

16. 16. The computer-implemented method of claim 14 or 15, further comprising removing the plurality of nodes of the first subnet from the second subnet.

17. 17. A distributed network comprising a plurality of subnets, each of the plurality of subnets including one or more assigned nodes, the distributed network configured to perform each of the steps of the computer-implemented method of any one of claims 1 to 16.

18. 18. A node of the distributed network of claim 17, configured to participate in the computer-implemented method of any one of claims 1 to 16.

19. 17. A computer program for operating a distributed network, the distributed network comprising a plurality of subnets, the computer program comprising program instructions executable on one or more of a plurality of nodes, the program causing one or more of the plurality of nodes to perform the computer-implemented method of any one of claims 1 to 16.

20. 20. A computer readable storage medium having stored thereon the program instructions of claim 19.

Images