How distributed deterministic networks work

Abstract

In an embodiment of a first aspect of the present invention, a computer-implemented method for operating a distributed network having a plurality of nodes and one or more subnets is provided. The method comprises: executing a set of computational units; and generating an assigned subset of computational units for each of a plurality of subnets by assigning each of the computational units to one of one or more subnets according to a subnet assignment. The method further comprises executing the assigned subset of computational units on each node of the one or more subnets, and configuring the computational units to perform computations in a deterministic manner to replicate the assigned subset of computational units on replicas across each subnet. The method further comprises executing a consensus component configured to reach agreement on input blocks processed by the replicas in each subnet. The method further comprises each replica of a subnet measuring replica local data, each replica of a subnet reporting the replica local data to the consensus component, and utilizing the replica local data to perform analysis, particularly statistical analysis, of a plurality of computations performed across each 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 comprising multiple subnets. Each subnet includes multiple nodes.

[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-temporary medium. [Background technology]

[0003] In a distributed network, multiple nodes are located in a distributed manner. In distributed network computing, software and data are distributed across multiple nodes. Nodes build computing resources, and distributed networks can utilize distributed computing techniques.

[0004] One example of a distributed network is a blockchain network. A blockchain network is a consensus-based electronic ledger consisting of multiple blocks. Each block consists of multiple transactions and other information. Furthermore, each block is chained by containing the hash of the previous block, so that all transactions written to the blockchain are created as a permanently immutable record. Transactions can include, for example, small programs known as smart contracts.

[0005] For a transaction to be written to the blockchain, "verification" by the network is essential. In other words, network nodes need to reach a consensus on the block to be written to the blockchain. Such consensus can be achieved through various consensus protocols.

[0006] As one form of consensus protocol, there is the proof-of-work consensus protocol. Generally, in the proof-of-work consensus protocol, some work is required from the parties participating in the consensus protocol, and usually, it corresponds to the processing time by a computer. In a cryptocurrency system based on proof-of-work such as Bitcoin, transactions are verified and new blocks are created by solving computationally intensive puzzles.

[0007] As another form of consensus protocol, there is the proof-of-stake consensus protocol. Such a proof-of-stake protocol has the advantage that it does not require computationally intensive calculations that take time and energy. In a blockchain network based on proof-of-stake, for example, the creator of the next block is selected through a combination of random selection and the stakes of each node in the network.

[0008] Apart from cryptocurrencies, distributed networks can be used for various other applications. In particular, they can be used for the provision of distributed and decentralized computing power and services.

[0009] <S International Publication No. 2020 / 187413 discloses a distributed network comprising multiple network nodes. Each of the multiple network nodes is linked to one of multiple first node identifiers. Each of the multiple first node identifiers contains a first verification key of a public key signing scheme. The distributed network is configured to perform a key shuffle step adapted to establish a non-linkable one-to-one mapping between the multiple first node identifiers and multiple second node identifiers. Each of the multiple second node identifiers contains a second verification key of a public key signing scheme. The distributed network is configured to execute a consensus protocol using a subset of the multiple second node identifiers.

[0010] Gang Wang ET AL: SoK: Sharding on Blockchain, IACR, INTERNATIONAL ASSOCIATION FOR CYRPTOLOGY RESEARCH, vol 20191010:125541, 10 October 2019, states that sharding is emerging as a promising candidate to address both scalability and performance challenges in blockchain. This document includes a discussion of general design procedures and key design challenges for sharding protocols, providing systematic and comprehensive insights into blockchain sharding technology.

[0011] Therefore, there is a need for a distributed network with enhanced functionality.

Summary of the Invention

Means for Solving the Problems

[0012] One object of one aspect of the present invention is to provide a method for operating a distributed network with improved functionality, particularly from the viewpoints of security, efficiency, and / or fairness.

[0013] In an embodiment of the first aspect of the present invention, a computer-implemented method for operating a distributed network is provided. The distributed network comprises a plurality of nodes and one or more subnets. The method comprises the steps of executing a set of computing units, and generating an assigned subset of the set of computing units for each of the plurality of subnets by assigning each of the computing units to one of the one or more subnets according to subnet assignment. The method further comprises the step of executing the assigned subset of computing units on each node of the one or more subnets, and replicating the assigned subset of computing units on replicas across the respective subnets by configuring the computing units to execute computations in a deterministic manner. The method further comprises the step of executing a consensus component configured to obtain a consensus on input blocks processed by replicas of each subnet. The method further comprises the steps of each replica of the subnet measuring replica-local data, and each replica of the subnet reporting the replica-local data to the consensus component. The replica local data contains multiple non-deterministic measures of the computation performed.

[0014] The materialized method further comprises a step of performing an analysis using replica local data, the analysis being a statistical analysis of multiple calculations performed in particular across each subnet. The materialized method also further comprises a step of performing one or more actions in response to the analysis of the replica local data.

[0015] Such an implemented method provides advantageous network operation. In particular, such a method enables the nodes of the subnets to measure replica-local data and use this replica-local data to perform an analysis of the plurality of computations executed across the respective subnets.

[0016] In some embodiments, the replica-local data may be defined in particular as any data of the replica that is local, and that the replicas of each subnet have not obtained a consensus on, i.e., any data that has not passed through the consensus component of the subnet.

[0017] In such a concrete method, a replica of the subnet itself is used to measure replica-local data, and this data is reported to the consensus component. The replica-local data can then be used for subnet analysis.

[0018] This method can be used to observe replicas and detect malicious, inadequate, or passive behavior, such as replica free-riding. Free-riding can be described as optimistic but short-sighted adherence to a protocol for the purpose of saving resources or costs; it is not necessarily malicious intent.

[0019] Furthermore, such embodied methods can be used to observe computing units running on replicas and detect below-average performance of a particular computing unit. Below-average performance can result from poorly programmed or maliciously programmed computing units, or from maliciously crafted inputs from users to computing units. In particular, such embodied methods can be used to detect and eliminate resource depletion attacks by computing units or users.

[0020] In addition, methods according to some embodiments of the present invention can be used to improve the fairness of billing for computing units for the use of network resources, despite the non-deterministic effects.

[0021] In some embodiments, replica local data is data relating to computations that the corresponding replica performs locally.

[0022] The results of the computation, i.e., the execution state of the computation unit, are the same across all replicas; however, efficiency and performance in terms of node processing resource usage, such as memory buses and caches, may differ from replica to replica. Therefore, in one embodiment, replica local data may, in particular, be data relating to computations performed locally by the corresponding replica. This data may, in particular, include non-deterministic data, specifically, multiple non-deterministic measurements of the computations performed.

[0023] In some embodiments, replica local data is data containing numerical or countable quantities. Such numerical or countable data includes Boolean data.

[0024] Measuring numerical or countable data facilitates efficient data analysis. More specifically, it enables efficient data comparison and facilitates the efficient implementation of operational logic, thereby improving subnet behavior.

[0025] For example, one measurement might relate to the real time required for execution on a given computing unit, as measured by a replica. More precisely, a replica might measure the ratio of logical time to local real time on the replica. Here, the logical time required for a given execution is deterministic and therefore identical across all replicas, while the real time is non-deterministic and therefore depends on local effects on the replica, such as memory bus usage and the state of the cache on the replica.

[0026] the The actions can generally be any means to improve the subnet's operation. In some embodiments, the subnet's system computing units may perform these actions. Such system computing units may receive reported replica local data, preferably in an analyzed form, and based on this data, determine what actions to take.

[0027] In some embodiments, the operation may include, for example, limiting and / or adjusting the price for one or more compute units on a subnet. Such limits may be, for example, the logical time allocated to a compute unit. The price may be the price at which the network charges compute units for network processing and use of network resources. Such a price may be set in the network's local currency and may also be referred to as gas.

[0028] In the same or similar manner, subnets may adjust user limits and / or pricing for the distributed network, particularly for users using compute units running on each subnet.

[0029] Furthermore, in some embodiments, a malicious or faulty replica may be shut down; in other words, it may be removed from the network.

[0030] In one embodiment, the method may include the step of each subnet calculating the geometric median of a set of replica local data across the subnet.

[0031] More specifically, each replica of a subnet can provide replica local data. The median of each replica local data is then calculated across the subnet. Obtaining a median has the advantage that a malicious or fraudulent replica cannot influence the final value used for subsequent analysis of subnet behavior. In this regard, some embodiments of the present invention offer the advantage of preventing a malicious node or malicious computing unit from significantly distorting the final value by providing extremely large or small values.

[0032] In one embodiment, a statistical analysis of a set of medians may then be performed, and one or more actions may be taken depending on the results of the statistical analysis.

[0033] In one embodiment, the statistical analysis may include the application of a method configured to ignore outliers, particularly a method that includes the calculation of the geometric median.

[0034] In one embodiment, statistical analysis can be performed robustly, in the sense that its results are not affected by outliers in the local measurements of the reported replicas. A statistical analysis beginning with obtaining the median is one exemplary embodiment of robust statistical analysis.

[0035] In one embodiment, it is assumed or expected that there are at most f malicious replicas within the subnet. The statistical analysis can then proceed only when there are at least 2f+1 reports from different replicas. The statistical analysis can then discard the f lowest and f highest values, considering only the remaining values.

[0036] In some embodiments, the statistical analysis may include the steps of calculating the deviation of a set of medians from the expected value, and performing one or more actions depending on the deviation. For example, a computing unit having resource consumption that deviates from the expected value by a predetermined ratio may be subject to an action such as a reduction in allocated logical time.

[0037] In addition to median analysis, further statistical analysis of the data may be performed. This additional data could be, in particular, publicly verifiable blockchain data—that is, data that is available to everyone and therefore no longer needs to be reported to the consensus component. In other embodiments, the additional data could come from reliable sources or providers.

[0038] In one embodiment, the component responsible for analysis and operation may perform one or more operations depending on the statistical analysis of the replica local data, a set of medians, and / or further data.

[0039] In one embodiment, a subnet may provide a time frame for replicas of the subnet to report replica local data. Such a time frame may be predefined by the subnet and implemented, for example, as code within the subnet client. As an example, the time frame may be specified, for example, with respect to a predetermined number of input blocks. Such a time frame facilitates regular analysis of the behavior of subnet components.

[0040] In one embodiment, replica local data may be data relating to the resource consumption of computing units on each replica, particularly the real time of execution and / or the maximum amount of memory allocated during execution. This is non-deterministic data that may differ from replica to replica.

[0041] In one embodiment, replica local data may be data relating to the user's resource consumption on the replica, in particular to the logical time and / or logical execution time performed on behalf of the user, and / or the maximum memory capacity allocated during execution performed on behalf of the user.

[0042] In one embodiment, replica local data may be data relating to measurements of other replicas with which that replica communicates. These replicas may be on the same subnet, or they may be on different subnets. Furthermore, it may mean that the two replicas have established a persistent communication link, for example, according to an overlay topology, or that they communicate only sporadically via a non-persistent communication link. Additionally, this may indicate that the two replicas are part of a gossip network.

[0043] In one embodiment, the data that a replica communicates with each of the other replicas may be replica-local data.

[0044] Measurement of the first parameter, in particular, the communication parameters of one replica to another, especially latency, response time, downtime, and / or reliability. Such communication parameters may also be expressed as low-level communication parameters.

[0045] In one embodiment, for each of the other replicas with which the replica communicates, the replica local data may be data relating to the semantic communication parameters of the replica and the other replica, such as measurements of the second parameter, in particular, accuracy to protocol specifications, such as subnet protocol specifications. Such communication parameters may be represented as high-level communication parameters.

[0046] In one embodiment, replica local data for each of the other replicas on the subnet may be data relating to measurements of the activity of the other replicas in the consensus protocol that the replica observes, such as the number of proposals for the input block and / or the number of shared signatures generated by the other replicas. In this embodiment, the replica does not need to communicate directly with the other replicas that performed the measurements.

[0047] In one embodiment, further data may be data from a reliable source, in particular from the blockchain. In such an embodiment, further data may be the number of blocks in a given section of the blockchain proposed by each replica. Blocks that are part of the agreed-upon blockchain may be referred to as finalized blocks. Furthermore, in one embodiment, further data may be the number of times each replica has participated in multiple signatures for all multiple signatures observed in the blocks of a given section of the blockchain.

[0048] In some embodiments, a subnet replica may handle non-replicated executions on behalf of a user. Such non-replicated executions are not intended to pass through agreement, run on other replicas, or modify replicated states. Such non-replicated executions may be referred to as query calls. In such embodiments, replica-local data may be data relating to the resource consumption of query calls for each compute unit or each user. Such embodied methods provide a favorable way to charge compute units and / or users for queries, for example, in gas formation. In particular, compute units may be charged an amount proportional to the median gas cost incurred across all replicas.

[0049] In this regard, gas can be defined as a complementary accounting unit that a distributed network uses to charge for the use of its resources, and which is separate from the network's intrinsic currency. Gas can also be expressed as fuel or cycles. Providing a complementary accounting unit offers the advantage that the cost of using resources can be maintained stably, independently of market fluctuations of the intrinsic currency. This is analogous to an automobile, in that it requires fuel or gas to run, and in embodiments of the present invention, gas is required to run the resources of the distributed network.

[0050] In some embodiments, subnets may also be represented as replicated compute clusters. In such replicated compute clusters, the compute units assigned to each subnet run on each node in the subnet and traverse a chain of identical execution states by replicating across subnets.

[0051] In one embodiment of another aspect of the present invention, a distributed network is provided that is configured to perform the steps of the method aspect of the present invention.

[0052] In one embodiment of another aspect of the present invention, a node of a distributed network is provided which is configured to perform and / or participate in a corresponding step of an aspect of the method of the present invention.

[0053] In another embodiment of the present 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 being executable on one or more of a plurality of nodes of the distributed network, and one or more of the plurality of nodes performing the steps of the method embodiment of the present invention.

[0054] In another embodiment of the present invention, a computer program product for operating nodes in a distributed network is provided.

[0055] In one embodiment of another aspect of the present invention, a software architecture encoded on a non-temporary computer-readable medium is provided. The software architecture is configured to operate one or more nodes of a distributed network. The encoded software architecture has program instructions that can be executed on one or more of the multiple nodes, and one or more of the multiple nodes perform a method comprising steps of an aspect of the method of the present invention.

[0056] Features and advantages of one aspect of the present invention may be applied to other aspects of the present invention as needed.

[0057] Other useful embodiments are listed in the dependent claims and the following description.

[0058] The present invention will be better understood and other purposes will become apparent from the following detailed description. Such a description is made with reference to the accompanying drawings. [Brief explanation of the drawing]

[0059] [Figure 1]Figure 1 is an illustrative block diagram of a distributed network according to one embodiment of the present invention. [Figure 2] Figure 2 shows a more detailed view of the computing units that operate on the network nodes and form replicas of the subnet. [Figure 3] Figure 3 shows each step of a computer implementation method according to one embodiment of the present invention. [Figure 4] Figure 4 shows the flow of messages and data in a distributed network according to an embodiment of the present invention. [Figure 5] Figure 5 shows the main processes running on each node of the network according to one embodiment of the present invention. [Figure 6] Figure 6 is a schematic block diagram of the protocol components of a subnet protocol client. [Figure 7] Figure 7 is an illustrative visualization of the workflow of messaging protocols, consensus protocols, and related components. [Figure 8] Figure 8 is a layer model diagram illustrating the main layers involved in the exchange of messages between and within subnets. [Figure 9] Figure 9 shows the creation of an input block for a consensus component according to an exemplary embodiment of the present invention. [Figure 10] Figure 10 shows the computing unit in more detail. [Figure 11] Figure 11 is a flowchart showing the method steps of a computer implementation method for running a distributed network. [Figure 12] Figure 12 is a flowchart that includes further method steps for a computer implementation method for operating a distributed network. [Figure 13] Figure 13 shows an exemplary embodiment of a node according to an embodiment of the present invention. [Modes for carrying out the invention]

[0060] First, we will introduce some general aspects and terminology of the embodiments of the present invention.

[0061] In some embodiments, a distributed network comprises multiple nodes arranged in a distributed manner. In computations on such a distributed network, software and data are distributed across multiple nodes. The multiple nodes build up computing resources, and the distributed network may, in particular, utilize distributed computing techniques.

[0062] In some embodiments, the distributed network may be embodied specifically as a blockchain network. The term "blockchain" may encompass 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.

[0063] A computing unit can be defined as part of software that runs on a node in a distributed network and has its own unit state. The unit state can also be referred to as the execution state.

[0064] A set of computing units, particularly the state of those computing units, is configured to be replicated across subnets. As a result, those computing units, as long as they behave honestly, always traverse the same chain of unit states or execution states. A computing unit includes the computing unit's code and the computing unit's state or execution state.

[0065] An artifact can be any information exchanged between nodes in a subnet.

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

[0067] A messaging protocol can be defined as a protocol that manages the exchange of messages within a network, particularly inter-unit messages. Specifically, a messaging protocol may be configured to send inter-unit messages from a sending subnet to a receiving subnet. For this purpose, the messaging protocol uses subnet assignments, which indicate to the messaging protocol the location / subnet of each compute unit for each communication.

[0068] In some embodiments, the unit state is understood as all data or information used by the compute unit, in particular, not only the data that the compute unit stores in variables, but also the data that the compute unit retrieves from remote calls. The unit state may, in particular, represent the storage locations in each memory location of each node. The contents of these memory locations are referred to as the unit state in some embodiments at any given point in time during the execution of the compute unit. The compute unit may, in particular, be embodied as a state compute unit, that is, the compute unit is designed according to embodiments that store preceding events or user interactions.

[0069] Figure 1 shows an exemplary block diagram of a distributed network 100 according to one embodiment of the present invention.

[0070] The distributed network 100 comprises multiple nodes 10, which can also be represented as network nodes 10. These multiple nodes 10 are distributed across multiple subnets 11. In the example in Figure 1, four subnets 11 are provided, which are represented as SNA, SNB, SNC, and SND.

[0071] Each of the subnets 11 is configured to run a series of compute units on each node 10 of each subnet 11. In some embodiments, the compute units are understood as part of the software; in particular, as part of the software that includes or has its own unit state, or in other words, as the running state.

[0072] Network 100 performs intra-subnet communication within each subnet 11. In particular, it includes communication links 12 that handle the communication of intra-subnet unit messages exchanged between computing units assigned to the same subnet, and the communication of intra-subnet messages containing replica local data for reporting.

[0073] Furthermore, the network 100 includes a communication link 13 for inter-subnet communication between different subnets within the subnet 11. This communication link 13 is particularly used for the communication of inter-unit messages exchanged between subnets between computing units assigned to different subnets.

[0074] Therefore, communication link 12 can also be represented as an intra-subnet or peer-to-peer (P2P) communication link. Similarly, communication link 13 can also be represented as an inter-subnet or subnet-to-subnet (SN2SN) communication link.

[0075] In some embodiments of the present invention, subnet 11 is configured to replicate a set of computing units across each subnet 11. More specifically, subnet 11 is configured to replicate the unit state of a set of computing units across each subnet 11. A set of computing units in a subnet running on a node forms a replica of the subnet.

[0076] Network 100 could, in particular, be a proof-of-stake blockchain network.

[0077] Proof of Stake (PoS) describes how a blockchain network reaches a decentralized consensus on which nodes are permitted to create the next block of the blockchain. The PoS approach may use weighted random selection. Thereby, the weight of an individual node may be determined according to, in particular, the assets (“stakes”) of each node.

[0078] Figure 2 shows details of the computing unit 15 executed on node 10 of network 100. Network 100 is configured to assign each computing unit executed on network 100 to one of a plurality of subnets, in this example, one of subnets SNA, SNB, SNC, and SND, according to subnet assignment. The subnet assignment of decentralized network 100 creates an assignment subset of the entire set of computing units for each of subnets SNA, SNB, SNC, and SND.

[0079] More specifically, Figure 2 shows node 10 of subnet SNA of Figure 1. In the subnet assignment of decentralized network 100, a subset of four computing units 15 is assigned to subnet SNA. More specifically, computing unit CU A1 、CU A2 、CU A3 、and CU A4 's subset is assigned. The assignment subsets of computing units CU A1 、CU A2 、CU A3 、and CU A4 are executed on each node 10 of subnet SNA. Further, the assignment subsets of computing units CU A1 、CU A2 、CU A3 、and CU A4 are the assignment subsets of computing units CU A1 、CU A2 、CU A3 、and CU A4Each of these is replicated across the entire subnet SNA, traversing the same chain of unit states to form a replica of the subnet at each node in the subnet. This is particularly true for each node 10 of the subnet SNA, where the compute unit CU A1 , CU A2 , CU A3 , and CU A4 This can be done by actively replicating in the space of the unit state. Computation unit CU A1 , CU A2 , CU A3 , and CU A4 This is materialized as a user computing unit. In addition, the subnet may also include system computing units, although these are not shown in Figure 2.

[0080] As shown in Figure 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 the network nodes.

[0081] In some embodiments, the distributed network may be configured to exchange inter-subnet messages 16 between subnets SNA, SNB, SNC, and SND via a messaging protocol. The inter-subnet messages 16 may be embodied in particular as inter-unit messages 16a exchanged between compute units assigned to different subnets according to subnet allocation. For example, the distributed network 100 may have compute unit CUs as transmitting compute units running on subnet SNA. A1 And, a compute unit CU as a receive compute unit that runs on the subnet SNB. B2The two can be configured to exchange inter-unit messages M1, 16a between them. Furthermore, the inter-subnet message 16 can be materialized as a signaling message 16b. The signaling message 16b may include an acknowledgment message (ACK) adapted to acknowledge acceptance or reception of an inter-unit message, or a non-acknowledgment message (NACK) adapted not to acknowledge acceptance (corresponding to rejection) of an inter-unit message indicating a transmission failure, for example.

[0082] Network 100 may be configured to store subnet assignments for computing units 10 as network configuration data. This information may also be stored in a central registry.

[0083] In a further embodiment, the network 100 may be configured to exchange intersubnet messages 16 via a messaging protocol and a consensus protocol. The consensus protocol may be configured to reach an agreement on the selection and / or processing order of intersubnet messages 16 in each receiving subnet.

[0084] For example, referencing subnet SNB, intersubnet messages 16 are received from subnets SNA, SNC, and SND. The consensus protocol receives and processes these intersubnet messages 16 and, by executing a predefined consensus algorithm or consensus mechanism, reaches an agreement on the selection and / or processing order of the received intersubnet messages 16.

[0085] Next, with reference to Figure 3, a computer implementation method for operating a distributed network according to several embodiments of the present invention will be described.

[0086] In this embodiment, it is assumed that the subnet SNA includes three nodes. Each of the three nodes has running replicas 1, 2, and 3, where each of replicas 1, 2, and 3 is a set of compute units (CUs). A1, CU A2 , CU A3 , and CU A4 It includes the following: Each of replicas 1, 2, and 3 measures replica local data during its operation and reports this replica local data to consensus component 63. Consensus component 63 is then configured to reach an agreement on the input blocks that replicas 1, 2, and 3 of the subnet SNA will process. Apart from the replica local data, consensus component 63 may receive messages from users or other subnets, for example, as described in more detail below. The subnet SNA then uses the replica local data to send compute units CU across the subnet. A1 , CU A2 , CU A3 , and CU A4 The calculations performed by the subnet are analyzed. The analysis may be performed by the statistical analysis component 62a. The subnet may then perform or initiate one or more actions based on the analysis. These actions may be performed at the replica level or the subnet level. The actions may be initiated by the action component 62b.

[0087] Referring to Figure 4, the flow of messages and data in a distributed network according to one embodiment of the present invention is shown. More specifically, Figure 4 shows the procedure for creating input blocks that are processed by subnet replicas.

[0088] Here, there are four computing units (CUs) A1 , CU A2 , CU A3 , and CU A4 Let's revisit the subnet SNA, which includes three replicas 1, 2, and 3 on which this is performed.

[0089] Each of replicas 1, 2, and 3 executes the same sequence of input blocks. The input blocks are created by the consensus component 63. The consensus component 63 receives multiple input data from multiple sources.

[0090] First, the consensus component 63 receives data from its own subnet SNA. Its subnet SNA comprises a reporting component 41 and a messaging component 61. The reporting component 41 reports replica local data measured on each replica 1, 2, and 3 of the subnet SNA to the consensus component 63. In addition, the messaging component 61 of the subnet SNA receives data from the compute unit CU A1 , CU A2 , CU A3 , and CU A4 One of them is another computing unit (CU) A1 , CU A2 , CU A3 , and CU A4 Provides an in-subnet message that appears as SN-data sent to one of the destinations.

[0091] Note that the reporting component 41 exists for each replica, and the messaging component 61 exists at least logically for each subnet. The messaging component 61 is deterministic, but the reporting component 41 can produce different outputs on each replica.

[0092] Furthermore, the consensus component 63 receives additional SN data from the messaging components 61 of other subnet SNBs, SNCs, and SNDs.

[0093] Furthermore, the consensus component 63 receives user data from users in the distributed network. This incoming user data can also be displayed as ingress messages.

[0094] Figure 5 shows the main processes that may be performed on each node 10 of network 100 according to one embodiment of the present invention. In some embodiments of the present invention, a network client of the network is a set of protocol components required by a node 10 joining the network. In some embodiments, each node 10 is a member of the mainnet. Furthermore, each node may be a member of one or more subnets.

[0095] The node manager 50 is configured to start, restart, and update the mainnet protocol client 51, the subnet protocol client 52, and the security application 53. In some other embodiments, the central control unit 20 may be used as a substitute for the mainnet protocol client (see Figure 1). In some embodiments, several replicas may be implemented using several subnet protocol clients.

[0096] In some embodiments, each of the multiple subnets 11 is configured to run a separate subnet protocol client 52 on the multiple nodes 10 corresponding to it. The mainnet protocol client 51 is configured in particular to distribute configuration data across and between the multiple subnets 11. The mainnet protocol client 51 may be configured in particular to run only system compute units, but not user-provided compute 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 subnet protocol client 52 comprises a registry 52a and a mainnet protocol client registry 51a.

[0097] The security application 53 stores the private keys of node 10 and performs actions corresponding to them.

[0098] The node manager 50 may, for example, monitor the registry 21 of the control unit 20 and instruct nodes to join a subnet and / or to stop joining a subnet.

[0099] Figure 6 shows a schematic block diagram of the protocol component 600 of a subnet protocol client, for example, subnet protocol client 52 in Figure 5.

[0100] The protocol component 600 comprises 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, in particular inter-unit messages and / or ingress messages. The protocol component 600 further comprises a consensus component 63 configured to execute a consensus protocol, a networking component 64 configured to execute a network protocol, a state manager component 65 configured to execute a state manager protocol, an X-Net component 66 configured to execute an inter-subnet transport protocol, and an ingress message handler component 67 configured to process ingress messages received from external users of the network. The protocol component 600 further includes a cryptographic component 68. The cryptographic component 68 works with a security component 611, which may be embodied, for example, as a security application 53 as described with reference to Figure 5. Furthermore, a subnet protocol client 52 may work with a leader component 610, which may be part of a mainnet protocol client 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. This includes node assignments to subnets, node public keys, and compute unit assignments to subnets.

[0101] The messaging component 61 and the execution component 62 are configured such that all calculations, data, and state in these components are replicated similarly 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.

[0102] On the one hand, the consensus component 63 ensures that the input stream to the messaging component 61 is agreed upon by each subnet. Thus, in some embodiments, such similar replication is achieved by ensuring that it is the same for all nodes, more specifically, for all honest nodes. On the other hand, this is achieved by the fact that the messaging component 61 and the execution component 62 are configured to perform computations that are deterministically replicated.

[0103] The X-Net forwarding component 66 sends message streams to other subnets and receives message streams from other subnets.

[0104] Most of the components access the cryptographic component 68 to execute cryptographic algorithms and access the mainnet reader 70 to read configuration information.

[0105] The execution component 62 receives the unit status of the compute unit and incoming messages from the compute unit from the messaging component 61, and replies with the outgoing messages of the compute unit and the updated unit status. During execution, the resource consumption (gas consumption) of the processing messages (queries) can also be measured.

[0106] The messaging component 61 is clock-controlled by input blocks received from the consensus component 63. Specifically, for each input block, the messaging component 61 performs the following steps: It parses each input block to obtain a message for its computing unit. Furthermore, it sends the message to the respective input queues of different computing units and plans which messages to execute according to the capacity allocated to each computing unit. Next, it uses the execution component 62 to process the message with the corresponding computing unit and adds the resulting message to the output queue of the respective computing unit. However, if the message is destined for a computing unit on the same subnet, the message may be placed directly into the input queue of the corresponding computing unit. Finally, the messaging component 61 sends the messages in the computing unit's output queue to the message stream of the subnet where the receiving computing unit is located, and forwards these message streams to the state manager component 65 for authentication, i.e., signing by the respective subnet.

[0107] The state manager component 65 includes an authentication component 65a. The authentication component 65a is configured to authenticate the output streams of each subnet. This can be done, for example, by threshold signing, multiple signing, or a collection of individual signatures of the compute units of each subnet.

[0108] As described above, the execution component 62 performs a deterministic and replicated execution of the input block. This execution takes place on each node 10 and uses the resources of node 10. However, the execution of the input block uses the resources of each node, in particular physical resources such as memory, processor, and network bandwidth. The use of these resources is non-deterministic and can differ between replicas in a subnet. Therefore, the non-deterministic portion of the execution of the input block is represented in Figure 6 using the execution component 69. The non-deterministic execution component 69 includes a measurement component 69a. The measurement component 69a measures replica-local data of the execution, in particular the non-deterministic data of the execution.

[0109] The execution component 69 sends the measured replica local data to the reporting component 41. The reporting component 41 reports the replica local data to the networking component 64, which then forwards or sends the replica local data to the consensus component 63.

[0110] The networking component 64 also forwards replica local data to other replicas on the subnet via a broadcast protocol, such as the gossip protocol. Conversely, the networking component 64 also receives replica local data generated by other replicas and forwards it to the consensus component 63.

[0111] The reporting component 41 includes an authentication component 41a. The authentication component 41a may authenticate the received replica local data before forwarding it to the networking component 64. In particular, the authentication component 41a may issue a signature of the replica or node on the replica local data.

[0112] Next, the replica local data is processed by the consensus component 63. The consensus component 63 executes the consensus protocol and forms the input blocks that the replicas will process.

[0113] Next, the replica local data is processed by the messaging component 61, which forwards or sends the replica local data to the execution component 62.

[0114] The execution component 62 includes a statistical analysis component 62a and an action component 62b as subcomponents.

[0115] The statistical analysis component 62a is configured to perform statistical analysis on replica local data.

[0116] Action component 62b is configured to perform or initiate one or more actions depending on the analysis of the replica local data.

[0117] Both the statistical analysis component 62a and the action component 62b are implemented as part of their respective subnet protocol clients 52.

[0118] In some embodiments, the statistical analysis component 62a and the action component 62b may be implemented as a system computing unit.

[0119] Figure 7 shows the messaging protocol and consensus protocol workflow 700 and their associated components. These are illustrative visualizations of, for example, the messaging component 61 and consensus component 63 in Figure 6.

[0120] Figure 7 visualizes the workflow of inter-subnet messages exchanged between the subnet SNB, subnet SNA, and subnet SNC. The subnet SNB also exchanges ingress messages with multiple users U. Furthermore, the subnet SNB measures, reports, and analyzes replica local data (RL-data).

[0121] Starting from the lower right of Figure 7, multiple input streams 701, 702, 703, and 704 are received by the consensus component 63. The consensus component 63 is a subnet consensus component run by the subnet client of the subnet SNB. Input stream 701 contains intersubnet messages 711 from subnet SNA to subnet SNB. Input stream 702 contains intersubnet messages 712 from subnet SNC to subnet SNB. Input stream 703 contains ingress messages 713 from multiple users U to subnet SNB. Input stream 704 contains replica local data 714 from the replica of subnet SNB.

[0122] The inter-subnet messages 711 and 712 comprise inter-unit messages and signaling messages exchanged between compute units on different subnets. Signaling messages are used to acknowledge or reject the acceptance of inter-unit messages. The messaging component 61 is configured to send signaling messages from the receiving subnet to the corresponding transmitting subnet, i.e., from subnet SNB to subnets SNA and SNC in this example. In this example, the messaging component 61 is configured to store inter-subnet transmitted inter-unit messages until an acknowledgment message is received for each inter-unit message. This provides a guarantee of delivery.

[0123] The consensus component 63 is configured to receive and process intersubnet messages 711 and 712 between the SNA and SNC, user U's ingress message 713, and replica local data 714 from the replica from the SNB, and to generate a queue of input blocks 720 from the intersubnet messages 711 and 712, the ingress message 713, and the replica local data 714 according to a predetermined consensus mechanism performed by the corresponding consensus protocol. Each input block 720 generated by consensus contains a set of input messages 713, a set of intersubnet messages 711 and 712, replica local data 714, and execution parameters 715 (EP). The execution parameters 715 (EP) may include, in particular, a random seed, a specified execution time, and / or a height index. The consensus component 63 may also change the number of messages in each input block based on the current load of the subnets.

[0124] The consensus component 63 provides a queue of input blocks 720 to the messaging component 61, which is configured to execute the messaging protocol and process the input blocks 720.

[0125] The messaging protocol and messaging component 61 are clock-controlled by the input block 720 received from the consensus component 63.

[0126] Before processing the received input block, the messaging component 61 may perform one or more preprocessing steps, including one or more input checks. Input checks may be performed by the input check component 740.

[0127] When the input check is successfully passed, the messages in each input block 720 may be further processed by the messaging component 61, and the corresponding messages may be added to the corresponding queue in the guidance pool of the guidance pool component 731. The guidance pool component 731 of the messaging component 61 receives the input blocks and input messages accepted by the messaging component 61 after successfully passing the input check component 740, and performs further processing accordingly. Before processing the received input blocks, the messaging component 61 may perform one or more preprocessing steps, including one or more input checks. The input check may be performed by the input check component 740. When the input check is passed, the messages in each input block 720 may be further processed by the messaging component 61, and the corresponding messages may be added to the corresponding queue in the guidance pool of the guidance pool component 731. The guidance pool component 731 of the messaging component 61 receives the input blocks and input messages accepted by the messaging component 61 for further processing after passing the input check component 740.

[0128] Generally, the messaging component 61 preprocesses the input block 720 by placing ingress messages, signaling messages, inter-subnet messages, and replica local data into the induction pool component 731 as needed. Signaling messages in the subnet stream are considered acknowledgments of messages in the clearable output queue.

[0129] In this example, the induction pool component 731 includes subnet-to-unit queues SNA-B1, SNC-B1, SNA-B2, and SNC-B2, as well as user-to-unit queues U-B1 and U-B2, along with replica local data for the statistical analysis component 62a and the action component 62b.

[0130] Following these preprocessing steps, the messaging component 61 invokes the execution component 62 (see Figure 6) to run as many induction pools as possible during a single execution cycle, providing a specified execution time and a random seed as additional inputs. Following the execution cycle, the output queue of messages, which may also appear as output messages, is sent to the output queue component 733. Initially, the output queue component 733 includes inter-unit and inter-unit-user output queues, in this example, inter-unit output queues B1-A1, B1-C2, B2-A2, and B2-C3, as well as inter-unit output queues B1-U1 and B2-U4. As an example, message B1-A1 represents an output message from compute unit B1 of subnet SNB to compute unit A1 of subnet SNA. As another example, message B1-U1 represents an output message from compute unit B1 of subnet SNB to user U1. Furthermore, the output queue includes an action message 716 containing the actions performed by action component 62b. Operation messages are addressed to registry 52a of the subnet protocol client or to a separate system compute unit.

[0131] The output queue component 733 performs post-processing of the output queue resulting from the output messages by, for example, forming a set of output streams per subnet that are authenticated by the authentication component 65a shown in Figure 6 and distributed by other components. In this example, the output streams SNB-SNA, SNB-SNC, and SNB-U per subnet are provided.

[0132] Therefore, the messaging component 61 further comprises a state storage component 732 configured to store the state or unit state of the compute units in each subnet, in this example the states of compute units B1 and B2 of subnet SNB. The corresponding unit state is the working memory of each compute unit.

[0133] The messaging component 61 revolves around deterministically changing specific parts of the system state. In each round, the execution component 62 executes specific messages from the induction pool by reading and updating the state of each compute unit and replies any outgoing messages that the executed compute unit wishes to send. These outgoing messages, in other words, output messages, are first entered into the output queue component 733, which contains inter-unit messages between compute units in the network. Intra-subnet messages between compute units in the same subnet can be sent and distributed internally within each subnet, while inter-subnet messages are sent to output streams separated by subnet destinations.

[0134] Furthermore, in some embodiments, two states may be maintained to inform the rest of the system which messages have been processed. The first state may be maintained for inter-subnet messages, and the second state may be maintained for ingress messages.

[0135] The following describes in more detail the interaction between the mainnet protocol client 51 and the subnet protocol client 52 (see Figure 5). The mainnet protocol client 51 manages a number of registries containing subnet configuration information. These registries are implemented by compute units on the mainnet. In other embodiments, a central registry may be used as an alternative to the mainnet. Each subnet protocol client 52 also maintains a registry 52a. This registry 52a contains control and / or system information that locally manages subnet operations. This can be used, in particular, to allocate resources of replicas or nodes to individual compute units. As an example, registry 52a may specify the maximum logical time allocated to compute units of a replica. In this regard, an operation message may include an instruction to registry 52a, for example, that the logical time allocated to an invalid compute unit of a subnet should be reduced.

[0136] This can also be used, in particular, to prevent malicious replicas. For example, registry 52a may specify a list of replicas to be assigned to a subnet. In this regard, the operation message may include, for example, an instruction to registry 52a that malicious replicas be removed or replaced.

[0137] Figure 8 shows the layer model 800, illustrating the main layers involved in the exchange of messages between and within subnets. The layer model 800 includes a messaging layer 81 configured to function as a higher layer for inter-subnet communication. More specifically, the messaging layer 81 is configured to send inter-subnet messages between compute units in different subnets. Furthermore, the messaging layer 81 is configured to send ingress messages from network users to compute units in the network.

[0138] The layer model 800 further comprises multiple consensus layers 82. The consensus layers 82 are configured to receive inter-subnet and ingress messages from different subnets and organize them, particularly by agreeing on the processing order, with each subnet 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 in a single subnet.

[0139] In some embodiments, the network may comprise several further layers, particularly execution layers configured to execute execution messages on the network's computing units.

[0140] Referring to Figure 9, the generation of a block in a distributed network according to an embodiment of the present invention is illustrated. The block may be an input block 720 in particular shown in Figure 7, which is created by a consensus component 63 that runs a consensus protocol, in particular a local subnet consensus protocol.

[0141] In this exemplary embodiment, three input blocks 901, 902, and 903 are illustrated. Block 901 contains multiple transactions, namely transactions tx1.1, tx1.2, and optionally further transactions indicated by dots. Block 902 also contains multiple transactions, namely transactions tx2.1, tx2.2, and optionally further transactions indicated by dots. Block 903 also contains multiple transactions, namely transactions tx3.1, tx3.2, and optionally further transactions indicated by dots. Input blocks 901, 902, and 903 are chained together. More specifically, each block contains the block hash of the previous block, which cryptographically links the current block to the previous block.

[0142] In some embodiments, transactions may be inter-subnet messages, ingress messages, and signaling messages.

[0143] In some embodiments, input blocks 901, 902, and 903 may be created by a proof-of-stake protocol.

[0144] However, it should be noted that, in some embodiments, the input blocks generated by the consensus component do not need to be chained together. Rather, in some embodiments, any consensus protocol can be used to reach some kind of agreement among multiple nodes in a subnet regarding the order in which incoming messages are processed.

[0145] Figure 10 shows a more detailed diagram of the computing unit 1000 according to an embodiment of the present invention.

[0146] The computing unit 1000 includes an input queue 1001, an output queue 1002, an application state 1003, and a system state 1004.

[0147] The computing unit 1000 generally comprises the computing unit's code and the computing unit's state or execution state.

[0148] Figure 11 shows a flowchart 1100 of the method steps of a computer implementation method for running a distributed network including multiple subnets according to an embodiment of the present invention. The distributed network can be embodied, for example, as network 100 as shown in Figure 1.

[0149] In step 1110, each subnet of the multiple subnets runs a set of compute units on its node, and each compute unit includes its own unit state.

[0150] In step 1120, the network replicates a set of computing units across each subnet.

[0151] Figure 12 shows a flowchart 1200 of the method steps of a computer implementation method according to one embodiment of the present invention. The distributed network can be embodied, for example, as network 100 as shown in Figure 1.

[0152] In step 1210, the subnet replicas or nodes measure the replica local data of their respective replicas.

[0153] In step 1220, the replica or node reports the replica local data to the consensus component, for example, the consensus component 63 described above.

[0154] One or more of the following steps involve using replica local data to analyze multiple calculations performed across each subnet, following the agreement.

[0155] More specifically, in step 1230, each subnet calculates the median of a set of replica local data across the subnet.

[0156] As a first example, suppose a subnet has, for example, 30 replicas, and each of the 30 replicas has 100 compute units. Furthermore, suppose each replica measures two replica-local values ​​as replica-local data for each of its 100 compute units, for example, the number of cache misses and the ratio of the logical time to the real time of execution performed by each compute unit. The subnet then calculates two sets of medians; that is, for each of the 100 compute units, it calculates the median number of cache misses and the median ratio of logical time to real time. As a result, in this example, the subnet calculates two sets of medians, each of which contains 100 medians.

[0157] As a second example, suppose a subnet has, for example, 30 replicas. Furthermore, suppose each replica maintains a direct communication link with 10 other replicas from the subnet, thereby forming an overlay topology. Furthermore, suppose each replica measures one replica-local value for each of the 10 other replicas it communicates with as replica-local data, for example, the average download rate at which protocol artifacts are received from the other replicas. The subnet can then calculate a set of medians; that is, for each of the 30 replicas, it calculates the median download rate that replica provides. As a result, in this example, the subnet calculates a set of medians, which contains 30 medians, each median calculated from 10 reported values.

[0158] As a third example, suppose a subnet has, for example, 30 replicas. Furthermore, suppose each replica measures, as replica local data, one replica local value for each of the other 29 replicas, for example, the number of times the replica observed sharing signatures from other replicas for threshold signatures that the subnet should create within a defined time frame. The subnet then calculates a set of medians, that is, the median number of shared signatures observed for each of the 30 replicas. As a result, in this example, the subnet calculates a set of medians, which contains 30 medians, each median calculated from 29 reported values.

[0159] Furthermore, in step 1240, additional data, particularly publicly verifiable data such as blockchain data, may be provided.

[0160] Next, in step 1250, the subnet performs an analysis, more specifically, a statistical analysis of a set of medians and further data. The statistical analysis may be used, for example, to identify computing units that generate significantly more cache misses than other computing units.

[0161] Next, in step 1260, the subnet performs one or more actions depending on the statistical analysis.

[0162] For example, the logical time allocated to computing units that generate a large number of cache misses can be reduced.

[0163] Referring to Figure 13, for example, a more detailed block diagram of network node 10 according to an embodiment of the present invention in network 100 of Figure 1 is shown. Network node 10 constitutes a computing node capable of performing computing functions. Therefore, it can generally be embodied as a computing system or computer. Network node 10 may be, for example, a server computer. Network node 10 may operate in a number of other general-purpose system environments or configurations, or in a dedicated computing system environment or configuration.

[0164] Network node 10 can be described in the general context of computer system executable instructions, such as program modules executed by a computer system. Generally, a program module may include routines, programs, objects, components, logic, data structures, etc., that perform a specific task or implement a specific abstract data type. Network node 10 is represented in the form of a general-purpose computing device. The components of network node 10 may include, but are not limited to, one or more processors or processing units 1315, system memory 1320, and a bus 1316 that connects various system components, including the system memory 1320, to the processor 1315.

[0165] Bus 1316 represents one or more of several types of bus structures.

[0166] Network node 10 typically includes various computer system-readable media.

[0167] The system memory 1320 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 1321 and / or cache memory 1322. The network node 1310 may further include other removable or non-removable, volatile or non-volatile computer system storage media. As just one example, the storage system 1323 is installable for reading and writing from a non-removable non-volatile magnetic medium (not shown, commonly referred to as a “hard drive”). As further illustrated and described below, the memory 1320 may include at least one computer program product having a set of program modules (e.g., at least one) configured to perform the functions of embodiments of the present invention.

[0168] The program or utility 1330 has a set of program modules 1331 (at least one), which may be stored in memory 1320, for example, and may also store 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 include an implementation of an environment for operating the network. The program module 1331 generally performs functions and / or methods of embodiments of the present invention described herein. In particular, the program module 1331 may perform one or more steps of an operating computer implementation method for causing a distributed network, for example, one or more steps of the method described above.

[0169] The network node 10 can also communicate with one or more external devices 1317, such as a keyboard or pointing device, as well as a display 1318. Such communication can be performed via an input / output (I / O) interface 1319. Furthermore, the network node 10 can communicate with one or more networks 1340, such as a local area network (LAN), a general-purpose wide area network (WAN), and / or a public network (e.g., the Internet), through a network adapter 1341. In some embodiments, the network 1340 may be a distributed network comprising multiple network nodes 10, for example, the network 100 shown in Figure 1.

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

[0171] A computer-readable storage medium can be a tangible device capable of holding and storing instructions used by an instruction execution unit. A computer-readable storage medium may be, 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 thereof. A computer-readable storage medium should not be construed, as used herein, as a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., optical pulses passing through optical fiber cables), or electrical signals transmitted through wiring.

[0172] The computer-readable program instructions described herein can be downloaded to each computing or processing unit to an external computer or external storage device via a computer-readable storage medium or 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 transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers.

[0173] The computer-readable program instructions that perform the operation of the present invention may be 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 and C++, and conventional procedural programming languages ​​such as the C programming language or similar programming languages.

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

[0175] Computer-readable program instructions according to embodiments of the present invention can be provided to a processor of a general-purpose computer, a dedicated computer, or other programmable data processing device to generate a machine. This generates instructions executed by the processor of the computer or other programmable data processing device to generate means for implementing a function / operation specified in a block or a flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that can instruct a computer, a programmable data processing device, and / or other device to function in a particular way. A computer-readable storage medium having the stored instructions comprises a product containing instructions that implement a mode of function / operation specified in a flowchart and / or block diagram or a plurality of blocks.

[0176] Computer-readable program instructions can also be loaded onto a computer, other programmable data processing device, or other device to generate a set of operational steps that are executed on the computer, other programmable device, or other device, thereby generating a computer implementation process that is executed on the computer, other programmable device, or other device. Thus, the instructions executed on the computer, other programmable data processing device, or other device implement the functions / operations specified in flowcharts and / or block diagrams or multiple blocks.

[0177] 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 flowchart or block diagram may represent a module, segment, or part of an instruction, comprising one or more executable instructions that implement a particular logical function. In some alternative implementations, the functions described in the blocks may occur in a different order than shown in the diagram. For example, two blocks shown consecutively may actually be executed substantially simultaneously. Also, these blocks may be executed in reverse order depending on the functions involved.

[0178] While this specification shows and describes preferred embodiments of the present invention, it is clearly understood that the invention is not limited thereto and can be embodied and implemented in various other ways within the scope of the claims.

Claims

1. A computer implementation method for operating a distributed network having multiple nodes and multiple subnets, A step of executing a set of computing units, The steps include: assigning each of the computing units to one of the subnets according to the subnet assignment, thereby generating a subset of the assignments for each of the subnets; A step of executing the allocated subset of the computing units on each node of the plurality of subnets, comprising the step of forming replicas by duplicating the computing units on each node of each subnet by configuring the computing units to perform calculations in a deterministic manner, The steps include: executing a consensus component configured to reach agreement on input blocks executed by the replicas of each subnet; Each of the replicas of the subnet measures replica local data, the replica local data includes a non-deterministic metric relating to the deterministic computation of the input block by the replica, The steps include each of the replicas in the subnet reporting the replica local data to the consensus component, The steps include: using the replica local data to analyze the calculations performed across each of the subnets; A computer implementation method comprising the steps of performing one or more operations in response to the analysis of the replica local data.

2. The computer implementation method according to claim 1, wherein the replica local data is data relating to the calculation performed locally by the corresponding replica.

3. The computer implementation method according to claim 1 or 2, wherein the replica local data is non-deterministic data.

4. The computer implementation method according to any one of claims 1 to 3, wherein the replica local data is data containing numerical values ​​or countable quantities.

5. The computer implementation method according to any one of claims 1 to 4, further comprising the step of each subnet calculating the geometric median of a set of replica local data across the subnet.

6. The steps include performing a statistical analysis of a set of the aforementioned geometric medians, The computer implementation method according to claim 5, further comprising the step of performing one or more actions according to the results of the statistical analysis of a set of geometric medians.

7. The computer implementation method according to any one of claims 5 to 6, wherein the computer implementation method is a method that includes the analysis, in particular the calculation of the geometric median, by applying a method configured to ignore outliers.

8. A computer implementation method according to any one of claims 5 to 7, further comprising the steps of: calculating the deviation of a set of geometric medians from the expected value; and performing one or more operations according to the deviation.

9. In particular, the step involves performing further statistical analysis on publicly verifiable blockchain data, A computer implementation method according to any one of claims 5 to 8, further comprising the step of performing one or more operations in accordance with the replica local data, a set of the geometric medians, and / or the statistical analysis of the further data.

10. The computer implementation method according to any one of claims 1 to 9, further comprising the step of providing a time frame for the replica of the subnet to report the replica local data.

11. The computer implementation method according to any one of claims 1 to 10, wherein the step of performing analysis using the replica local data is performed by the system computing unit of the subnet.

12. The computer implementation method according to any one of claims 1 to 11, wherein the step of performing one or more operations is performed by the system computing unit of the subnet.

13. The aforementioned replica local data, Data relating to the resource consumption of the computing units on each replica, particularly the actual execution time and / or the maximum memory capacity allocated during execution, Data relating to the resource consumption of each user on each replica, in particular the real time and / or logical execution time performed on behalf of the user, and the maximum memory capacity allocated during execution performed on behalf of the user, Data obtained when each replica communicates with each of the other replicas, including data relating to the communication parameters of the other replicas to each of the replicas, particularly latency, response time, downtime, and / or reliability measurements, Data obtained when each replica communicates with each of the other replicas, including data relating to the measurement of the semantic communication parameters of the other replicas to each replica, particularly the accuracy of the protocol specifications, Data from other replicas on each subnet, relating to the activities of the other replicas in the consensus protocol as observed by each replica, in particular to measurements of the number of input block proposals and / or shared signatures generated by the other replicas, A computer implementation method according to any one of claims 1 to 12, selected from a data set composed of the above.

14. The aforementioned further data The number of blocks finalized from each replica, The number of times each replica participated in the multiple signing process, A computer implementation method according to any one of claims 9 to 13, selected from any one of the following.

15. The one or more of the above operations, Limit and / or price adjustments for one or more computing units of the subnet, Adjustments to limits and / or prices for users of the distributed network, Prohibition of copying, A computer implementation method according to any one of claims 1 to 14, selected from any one of the following.

16. The steps include: the consensus component of the subnet receiving intersubnet messages from other subnets, intrasubnet messages from replicas of the same subnet, messages including reports of replica local data, and messages from external users among the network users; The steps include generating a queue of input blocks from received messages according to a predetermined consensus mechanism, The computer implementation method according to any one of claims 1 to 15, further comprising the step of having the replica of the subnet execute the queue of input blocks.

17. The computer implementation method according to any one of claims 1 to 16, further comprising the step of performing a non-replicating calculation on each node of the computing unit, the step of including a measurement of the non-replicating calculation on which the replica local data was performed.

18. A distributed network having one or more subnets, each of which includes a plurality of assigned nodes, and the distributed network is configured to perform the computer implementation method according to any one of claims 1 to 17.

19. A node of the distributed network according to claim 18.

20. A computer program for operating a distributed network having one or more subnets, comprising program instructions, wherein one or more of the plurality of nodes are executable, and which executes the computer implementation method described in any one of claims 1 to 17 on one or more of the plurality of nodes.

21. A computer implementation method for operating a distributed network having multiple nodes and one subnet, A step of executing a set of computing units, The steps include: assigning each of the computing units to one subnet according to subnet assignment to generate a subset of the assignments of the computing units for one subnet; A step of executing the allocated subset of the computing units on each node of the one subnet, comprising the step of forming replicas by duplicating the computing units on each node of the one subnet, by configuring the computing units to perform calculations in a deterministic manner, The steps include: executing a consensus component configured to obtain agreement on input blocks executed by the replica of the subnet; Each of the replicas of the subnet measures replica local data, the replica local data includes a non-deterministic metric relating to the deterministic computation of the input block by the replica, The steps include each of the replicas in the subnet reporting the replica local data to the consensus component, The steps include: using the replica local data to perform the calculations performed across the subnet; A computer implementation method comprising the steps of performing one or more operations in response to the analysis of the replica local data.

Images