Read access to distributed network computation results

Abstract

According to an embodiment of a first aspect of the present invention, there is provided a distributed network including a plurality of nodes. Each of the plurality of nodes is configured to execute one or more computational units, the computational units having their own unit state. The network is configured to execute, by an executing subset of the plurality of nodes, a set of execution messages independently in a deterministic manner, thereby changing the unit state of one or more computational units of the executing subset. The network is further configured to periodically create, by the nodes of the executing subset, a read snapshot of the unit state of one or more computational units of the executing subset, and to provide, by one or more nodes of the executing subset, user access to the read snapshot. Further aspects of the present invention relate to computer-implemented methods, nodes, computer program products, and software architectures.

Description

[Technical Field]

[0001] The present invention relates to a distributed network comprising a plurality of nodes, each of which is configured to execute one or more computational units. Further aspects relate to corresponding methods for providing users of a distributed network with access to computational results computed by the distributed network, and in particular by nodes of the distributed network. Further aspects relate to nodes of the distributed network, corresponding computer program products, and software architectures encoded on non-transitory media. [Background technology]

[0002] In a distributed network, multiple nodes are deployed in a distributed manner. In distributed network computing, software and data are distributed across multiple nodes. The nodes establish computing resources, and the distributed network can use distributed computing techniques.

[0003] An example of a distributed network is a blockchain network. A blockchain network is a consensus-based electronic ledger based on blocks. Each block contains transactions (transaction records / transaction data) and other information. Furthermore, each block contains a hash of the previous block, so all blocks can be chained together to create a permanent, immutable record of all transactions written to the blockchain. Transactions can include small programs called smart contracts, for example.

[0004] In order for a transaction to be written to the blockchain, it must be "verified" by the network, meaning that the network nodes must agree on the block to be written to the blockchain. Such agreement can be achieved through various consensus protocols.

[0005] One type of consensus protocol is the proof-of-work consensus protocol. Proof-of-work consensus protocols generally require participants in the consensus protocol to perform some work, usually equivalent to computer time. Proof-of-work-based cryptocurrency systems, such as Bitcoin, require participants to participate in computationally intensive puzzle-solving tasks to validate transactions and generate new blocks.

[0006] Another type of consensus protocol is the Proof-of-Stake consensus protocol. Such Proof-of-Stake protocols have the advantage of not requiring time- or energy-consuming computation. In a Proof-of-Stake based blockchain network, for example, the creator of the next block is chosen by a combination of random selection and the stake of each node in the network.

[0007] Beyond cryptocurrencies, decentralized networks can be used for a variety of other purposes, particularly to provide decentralized and distributed computing functions and services. Therefore, there is a need for a more sophisticated distributed network. Summary of the Invention [Problem to be solved by the invention]

[0008] It is therefore an object of one aspect of the present invention to provide a distributed network with enhanced functionality, in particular a network that provides users of the network with enhanced access functionality or access capabilities for accessing the computational results of the distributed network. [Means for solving the problem]

[0009] According to one embodiment of the first aspect of the present invention, there is provided a distributed network including a plurality of nodes, in particular a plurality of computing nodes. Each of the plurality of nodes is configured to execute one or more computational units, and each of the computational units includes its own unit state. The network is further configured to, by an executing subset of the plurality of nodes, independently execute a set of execution messages in a deterministic manner, thereby changing the unit state of one or more computational units of the executing subset. The network is further configured to, by the nodes of the executing subset, periodically create read snapshots of the unit state of one or more computational units of the executing subset, and to provide user access to the read snapshots, by one or more nodes of the executing subset.

[0010] Such a distributed network facilitates user access to the computational results of the distributed network, particularly to computational results computed by one or more computational units of the network, in an efficient manner. More specifically, the computational results are provided by read snapshots. A read snapshot can be defined as a snapshot that can be read and therefore accessed by users of the distributed network. A read snapshot is performed periodically to record the state of the computational units at a consistent point in time.

[0011] A compute unit can be defined as a piece of software that runs on a node of the network and has its own unit state. More specifically, a compute unit can be defined as a deterministic program with orthogonal persistence. Furthermore, each node of the network runs one or more compute units and therefore maintains unit states for one or more compute units.

[0012] According to an embodiment, the unit state of the computational units of the execution subset is replicated across the execution subset. This may be facilitated, inter alia, by performing active replication in the space of the unit states of the computational units on each node of the execution subset. According to an embodiment, the unit state may include, inter alia, input queues, output queues, system state, and application or user state.

[0013] According to one embodiment, the network is configured to periodically execute, by a consensus subset of the plurality of nodes, a consensus protocol configured to reach consensus on the selection of an execution message from a current set of execution messages, in other words from the currently available set. Therefore, processing and execution of the current set of execution messages is performed in a two-stage approach according to an embodiment. More specifically, in a first step, a consensus subset of nodes executes a consensus protocol to reach consensus on a selection of currently available execution messages. The number of nodes in the consensus subset can be chosen according to the needs of the respective network, in particular in terms of efficiency on the one hand and security on the other hand. Then, in a second step, an execution subset of nodes executes the selected execution messages in a deterministic manner. The number of nodes in the execution subset can also be chosen according to the needs of the respective network.

[0014] According to some embodiments, the consensus subset and the running subset may not overlap at all. According to other embodiments, the consensus subset and the running subset may overlap partially. According to still other embodiments, the consensus subset may be a subset of the running subset, i.e., nodes in the consensus subset are also nodes in the running subset. According to embodiments, nodes in the running subset may form a subnet of the network. The running subset may also be denoted as a first subset, and the consensus subset may also be denoted as a second subset.

[0015] According to one embodiment, the network is configured to perform computations on the read snapshot by computation units of one or more nodes of the execution subset and provide the results of the computations to a user. Such an embodiment allows for providing users with highly functional access, and more particularly, users can request that calculations be performed on the read snapshot, allowing operations such as sorting the results to be performed before providing them to the user. Contrary to the unit state of a compute unit, according to an embodiment, the computations for a read snapshot are not replicated, but rather they may be executed separately and independently by each node of the execution subset upon receiving a corresponding read query by, for example, a user.

[0016] According to one embodiment, the network is configured to receive a read query from a user by one or more nodes of the execution subset, particularly by the computational units of one or more nodes of the execution subset, and to load (read) the unit state of the corresponding computational units associated with the read query. The unit state may be loaded, particularly from a memory of the respective node that stores a read snapshot, and thus may correspond to the unit state of the most recent read snapshot. The network is further configured to execute the read query on the respective computational units, particularly including a computation on the respective unit state of the computational units stored in the read snapshot. The read query is executed individually and independently on each node of the execution subset, and the corresponding computation is not replicated among the nodes of the execution subset. Ultimately, the results of the lead query may be returned to the user.

[0017] Such embodiments may also provide enhanced functionality for defining and processing lead queries, which may be used to execute computational units to provide functionality such as sorting, searching, filtering, etc. A read query can generally be defined as a query that does not permanently modify the unit state of the computation unit: a read query may temporarily modify the user state of the computation unit, such as memory, global variables, and tables, but all such modifications are discarded once the read query has been completely processed.

[0018] According to one embodiment, the network is further configured to authenticate one or more portions of the read snapshot, thereby generating one or more authenticated portions of the read snapshot. Such authentication can increase a user's trust and confidence in the snapshot. More specifically, a user can verify the authenticated portion of the read snapshot.

[0019] According to one embodiment, the network is further configured to authenticate one or more authenticated portions of the read snapshot by a majority of the nodes in the execution subset, and according to such an embodiment, a majority of the nodes must agree on the authenticated portion of the read snapshot. According to one embodiment, the network is further configured to authenticate one or more portions of the read snapshot by generating a signature for one or more portions of the read snapshot by a majority of the executing subset of nodes and making the signature available to a user. Such a signature allows the user to verify the authenticated portion of the snapshot.

[0020] According to an embodiment, the executing subset of nodes is configured to execute a threshold signature algorithm to authenticate one or more authenticated portions. Thus, the signature may be implemented as a threshold signature. According to another embodiment, a running subset of nodes may be configured to run a multi-signature algorithm. Such a multi-signature is a digital signature that allows nodes in the execution subset to jointly sign a snapshot, which is typically more compact than the collection of the individual signatures of all nodes in the execution subset.

[0021] According to yet another embodiment, the execution subset of nodes may be configured to execute individual signatures by the nodes of the execution subset. According to an embodiment, one or more authenticated portions of the read snapshot are variables of the unit state. According to one embodiment, the network is further configured to record, by the nodes of the execution subset, a read snapshot of the unit state in a cache memory. Such an approach has the advantages of speed and efficiency.

[0022] According to one embodiment, the network is further configured to periodically create, by the nodes of the execution subset, a recovery snapshot of the unit state of one or more computing units of the execution subset, and to authenticate the recovery snapshot by a majority of the nodes of the execution subset. Such a recovery snapshot may also be referred to as a full snapshot. A recovery snapshot may be defined as a snapshot that contains all of the state of a running subset of nodes necessary to restore the nodes. This may include, in particular, all data and all input blocks of messaging components.

[0023] According to one embodiment, the network is configured to hash the recovery snapshot, which is an efficient way to authenticate and enable verification of the recovery snapshot. According to one embodiment, the network is configured to persistently store the recovery snapshot at least until a subsequent recovery snapshot is created. This allows the network nodes and their corresponding states to be always restored.

[0024] According to one embodiment, the network is configured to perform read snapshots at a first rate and to perform restore snapshots at a second rate, the first rate being greater than the second rate. Such an embodiment offers several advantages: on the one hand, it allows timely access to the network calculation results, i.e., at an update rate corresponding to the first rate, and on the other hand, it further ensures that full recovery of the nodes of the execution subset is always possible.

[0025] According to one embodiment, execution messages encompass all messages to be executed, in particular inter-unit messages exchanged between computational units of the network and mutation (data creation, update, deletion) queries received from users of the network. Mutation queries may also be denoted as ingress messages and may be, for example, execution requests addressed to computational units of the network to perform a certain computational task.

[0026] According to one embodiment, each node in the consensus subset includes a consensus component configured to execute a consensus protocol. According to an embodiment, each node in the execution subset includes an execution component configured to execute a selection of an execution message and a messaging component configured to receive the selection of the execution message from the consensus component and provide the selection of the execution message to the execution component. Additionally, each node may include a state management component configured to manage and store read snapshots, a state reader component configured to process read queries from users of the network, and / or an ingress message handler component configured to process mutation queries from users of the network. Such components can facilitate efficient implementation of various functions of a distributed network.

[0027] According to one embodiment, the network is configured to sequentially execute multiple processing loops with increasing height index N, where N is an increasing integer. The multiple processing loops are configured to execute a consensus protocol in a first loop step, individually execute a selection of execution messages in a second loop step, and create a read snapshot in a third loop step. Furthermore, during the processing loop with height index N, the network is configured to provide user access to a read snapshot created at the end of a previous height index, specifically, the previous height index N-1. In other words, during the current processing loop, a user can access a snapshot of the results of the previous processing loop. In other words, the read snapshot freezes the read state of each computing unit for one processing loop or loop cycle while the next processing loop is executed simultaneously.

[0028] According to a further embodiment, the consensus protocol is configured to receive and process execution messages from the current set of execution messages, generate a queue of input blocks from the execution messages according to a predefined consensus mechanism, and provide the queue of input blocks to a messaging protocol. The messaging protocol executed by the messaging component is configured to process the input blocks and schedule the execution messages of the input blocks for execution by a scheduler. The messaging protocol may be conveniently initiated by input blocks received from the consensus protocol, thereby facilitating efficient and synchronous processing of the input blocks. Furthermore, the state management component may advantageously be configured to create read snapshots at processing boundaries of the input blocks.

[0029] According to one embodiment, the consensus protocol is further configured to add one or more execution parameters to the input block, which may be, for example, a random seed, a specified execution time, and / or a height index. Such execution parameters may further facilitate and improve the efficiency and / or security of processing of an input block and its corresponding message. The random seed may be used as needed, for example to achieve pseudo-randomness at runtime. The height index may be, for example, an ascending index of the input blocks to facilitate in-order processing of the input blocks.

[0030] According to further embodiments, the network may be configured to elect committee members from a plurality of nodes according to a predefined election scheme and to run a consensus protocol with the elected members of the committee, which, according to such embodiments, form a consensus subset. According to an embodiment, the network is configured to run a proof-of-stake consensus protocol as the consensus protocol. The Proof-of-Stake consensus protocol aims to reach consensus on the selection and processing order of execution messages (inter-subnet messages and mutation queries), in particular the next input block to be created for further processing.

[0031] According to a further embodiment, the distributed network includes a plurality of subnets. Each of a plurality of nodes is assigned to one of the plurality of subnets. Each of the plurality of nodes is configured to execute a mainnet protocol client and a subnet protocol client. The subnet protocol clients are configured to periodically execute a consensus protocol, individually execute a selection of execution messages, periodically create read snapshots, and provide user access to the read snapshots. The mainnet protocol client is configured to distribute configuration data to the plurality of subnets.

[0032] According to an embodiment, each subnet is configured to replicate a set of computing units, in particular the state of the computing units, across the subnets, so that the computing units of each subnet are always in the same state as long as they operate in a fault-free manner. Different subnets, in particular computing units of different subnets, can communicate with each other by exchanging inter-subnet messages via messaging protocols and consensus protocols. According to some embodiments, all nodes in each subnet can participate in the consensus protocol and thus form a consensus subset. According to other embodiments, the consensus protocol is configured to elect committee members from the nodes in the subnet according to a predefined election scheme and then run the consensus protocol with the elected committee members.

[0033] Such a network can achieve high transaction rates and fast finalization times because the committee can be significantly smaller than the entire set of nodes in the subnet. This embodiment is particularly useful for larger subnets, including hundreds or thousands of nodes. In such cases, the committee that forms the consensus subset may consist of only 20-60 nodes, for example. Thus, the committee can act more efficiently than if all nodes in the subnet participated. Such a committee is sometimes called a notarization committee, since it has the authority to notarize input blocks.

[0034] According to some embodiments, a threshold relaying scheme can be used. More specifically, networks according to embodiments of the present invention can use threshold relaying, i.e., distributed random beacons, maintained by subsequent notarization committees of randomly selected nodes in each subnet. The output of the random beacons is used as entropy in the system, for example, to rank block proposers and form new generation committees. Such a threshold relay method is described, for example, in the document "DFINITY Technology Overview Series, Consensus System, Rev.1, https: / / dfinity.org / static / dfinity-consensus-0325c35128c72b42df7dd30c22c41208.pdf" by Timo Hanke, Mahnush Movahedi and Dominic Williams.

[0035] According to one embodiment, the network further includes a networking component configured to execute a networking protocol, which may include a unicast component configured to execute inter-node communications, a broadcast component configured to execute intra-subnet communications, and / or a cross-net component configured to execute inter-subnet communications.

[0036] According to one embodiment of the method aspect of the present invention, a computer-implemented method is provided for providing users of a distributed network with access to computational results computed by the distributed network. The distributed network includes a plurality of nodes. The method includes executing one or more computational units at each of the plurality of nodes and periodically executing, by a consensus subset of the plurality of nodes, a consensus protocol configured to reach consensus on a selection and processing order of execution messages from a current set of execution messages. The method further includes independently executing, by the execution subset of the plurality of nodes, a selection of execution messages in a deterministic manner according to the processing order, thereby changing the unit state of one or more computational units of the execution subset. The method further includes periodically creating, by the nodes of the execution subset, a read snapshot of the unit state of one or more computational units of the execution subset and providing, by the one or more nodes of the execution subset, user access to the read snapshot.

[0037] According to an embodiment of another aspect of the present invention, there is provided a node of a distributed network. According to an embodiment of another aspect of the present invention, there is provided a computer program product for operating a distributed network, the computer program product including a computer-readable storage medium having program instructions embodied therein, the program instructions being executable by one or more of a plurality of nodes of the distributed network to cause one or more of the plurality of nodes to perform steps of a method aspect of the present invention.

[0038] According to 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 including program instructions executable by one or more of the plurality of nodes to cause one or more of the plurality of nodes to perform a method including steps of a method aspect of the present invention.

[0039] Features and advantages of one aspect of the invention may be applied to other aspects of the invention, as appropriate. Further advantageous embodiments are set forth in the dependent claims as well as in the following description. The present invention will be better understood, and other objects will become apparent, from the following detailed description of the specification. The description refers to the accompanying drawings. [Brief explanation of the drawings]

[0040] [Figure 1] FIG. 1 is an exemplary diagram of a distributed network according to one embodiment of the present invention. [Figure 2] FIG. 2 illustrates in more detail the computational units operating on an exemplary node of the network. [Figure 3] FIG. 1 is an exemplary diagram of a distributed network including multiple subnets according to one embodiment of the present invention. [Figure 4] FIG. 4 illustrates in more detail the computing units operating on the distributed network of FIG. 3. [Figure 5]4 is a schematic diagram of an inter-subnet message received at a subnet of the network of FIG. 3. [Figure 6] FIG. 2 is a schematic block diagram illustrating protocol components of a subnet protocol client. [Figure 7] FIG. 1 is an exemplary visualization of the workflow of messaging protocols, consensus protocols, and related components. [Figure 8] FIG. 1 illustrates a more detailed embodiment of a state management component. [Figure 9] FIG. 10 is a timing diagram of an execute cycle and its corresponding read cycle. [Figure 10] FIG. 10 is a simplified schematic diagram illustrating block-by-block processing of input blocks performed by a messaging component and an execution component. [Figure 11] FIG. 1 illustrates the processing steps of a computer-implemented method for providing users of a distributed network with access to computational results. [Figure 12] 4 is a flowchart of further processing steps of a method according to an embodiment of the present invention; [Figure 13] FIG. 2 illustrates the main processes that run on each node of the network according to one embodiment of the present invention. [Figure 14] FIG. 1 is a diagram of a layer model showing the main layers involved in exchanging messages between and within subnets. [Figure 15] FIG. 2 illustrates a computation unit in more detail according to one embodiment of the present invention. [Figure 16] FIG. 10 illustrates the creation of input blocks by a consensus component according to an exemplary embodiment of the present invention. [Figure 17] FIG. 2 illustrates the networking components in more detail. [Figure 18] FIG. 2 illustrates an exemplary embodiment of a node according to an embodiment of the present invention. [Figure 19] FIG. 1 illustrates the cooperation of parts of a computing unit to execute a message. DETAILED DESCRIPTION OF THE INVENTION

[0041] First, some general aspects and terminology of embodiments of the present invention are introduced. According to an embodiment, a distributed network includes a plurality of nodes arranged in a distributed manner. In such distributed network computing, software and data are distributed across a plurality of nodes. The nodes establish computing resources, and the distributed network can particularly use distributed computing techniques. According to embodiments, the distributed network may be implemented as a blockchain network. The term "blockchain" includes all forms of electronic, computer-based, distributed ledgers. According to some embodiments, the blockchain network may be implemented as a proof-of-work blockchain network. According to other embodiments, the blockchain network may be implemented as a proof-of-stake blockchain network.

[0042] FIG. 1 is an exemplary block diagram of a distributed network 100 according to one embodiment of the present invention. The distributed network 100 includes a plurality of nodes 10 (sometimes referred to as network nodes 10 or computing nodes 10). Each of the plurality of nodes 10 is configured to execute one or more computational units. According to an embodiment, a computational unit should be understood as a piece of software, in particular a piece of software that includes or has its own unit state. Multiple nodes 10 of network 100 may be assigned to different subsets and / or subnets, and such assignments may change over time. According to this embodiment, the network 100 includes a consensus subset SS1 of nodes 10 and an execution subset SS2 of nodes 10.

[0043] The computational units running on the nodes 100 can be used by users of the network 100 to perform computational tasks. The computational units of the network 100 can execute specific execution messages from a current set of execution messages. The execution messages may include inter-unit messages exchanged between computational units of the network and / or ingress messages, i.e., messages received from external sources, in particular from users of the network. The network 100 is initially configured to execute a consensus protocol to obtain consensus on the selection and processing order of execution messages from each current set of execution messages. The consensus protocol is advantageously not executed by all nodes of the network 100, but only by a subset of the nodes 100 of the network 100. This subset is denoted below as consensus subset SS1. The consensus subset SS1 may also be denoted as consensus subset. The nodes of the consensus subset SS1 are then configured to execute the consensus protocol to obtain consensus on the selection and processing order of execution messages from the current set of execution messages.

[0044] Also, the execution of the execution message is advantageously not performed by all nodes of the network 100, but only by a subset of the nodes 10 of the network 100. This subset is denoted below as execution subset SS2, and may also be denoted as execution subset SS2. The computation units of the execution subset SS2 then individually execute the selection of messages to be executed in the processing order agreed upon in the previous consensus step. Each of the computation units of the execution subset SS2 executes in a deterministic manner, thereby changing the unit state of the corresponding computation unit of the execution subset SS2.

[0045] According to the embodiment, the unit state should be understood as all data or information used by the computing unit, in particular the data that the computing unit stores in variables, but also the data that the computing unit obtains from remote calls. The unit state can represent specific storage locations in the respective memory locations of the respective nodes. The contents of these memory locations at any point in the execution of the computing unit are called the unit state according to the embodiment. The computing unit may in particular be implemented as a stateful computing unit, i.e., the computing unit is designed according to the embodiment to remember previous events or user interactions. According to an embodiment, each node in the network is assumed to maintain a local clock that is approximately synchronized with the clocks of other nodes.

[0046] Figure 2 is a more detailed diagram of the computational units 15 operating on nodes 10 of network 100. More specifically, Figure 2 shows nodes 10 of subset SS2 of Figure 1 on which five computational units 15 are executed, more specifically, a set of computational units CUSS21, CUSS22, CUSS23, CUSS24, and CUSS25. The set of computational units CUSS21, CUSS22, CUSS23, CUSS24, and CUSS25 is executed on each node 10 of subset SS2. Furthermore, the set of computational units CUSS21, CUSS22, CUSS23, CUSS24, and CUSS25 is replicated throughout subset SS2 so that if each of computational units CUSS21, CUSS22, CUSS23, CUSS24, and CUSS25 operates correctly, they will have the same unit state. This may be implemented in particular by performing active replication in the space of unit states of the computing units CUSS21, CUSS22, CUSS23, CUSS24 and CUSS25 on each node 10 of the subset SS2.

[0047] FIG. 3 is an exemplary block diagram of a distributed network 300 according to one embodiment of the present invention. The distributed network 300 includes a plurality of nodes 10 . According to this embodiment, multiple nodes 10 are distributed across multiple subnets 11. In the example of Figure 1, four subnets 11 are provided, designated SNA, SNB, SNC, and SND. Network 100 includes communication links 12 for intra-subnet communication within each subnet 11 and communication links 13 for inter-subnet communication between different subnets of subnets 11. Thus, communication links 12 may also be designated intra-subnet or peer-to-peer (P2P) communication links, and communication links 13 may also be designated inter-subnet or subnet-to-subnet (SN2SN) communication links.

[0048] Each of the plurality of subnets 11 is configured to run a set of computational units on each node 10 of the respective subnet 11 . According to an embodiment of the present invention, the subnets 11 are configured to replicate a set of computational units across each of the subnets 11. More particularly, the subnets 11 are configured to replicate the unit states of the computational units across each of the subnets 11.

[0049] The network 100 may, in particular, be a proof-of-stake blockchain network. Proof of Stake (PoS) describes a method for achieving decentralized consensus in a blockchain network on which nodes are authorized to create the next block of the blockchain. PoS methods can use weighted random selection, whereby the weight of individual nodes can be determined, among other things, according to their respective assets ("stake"). According to an embodiment, it is assumed that at most a third of the nodes in each subnet will misbehave, so that artifacts generated and signed by the subnet can be fully trusted.

[0050] FIG. 4 is a more detailed diagram of the computing units 15 operating on nodes 10 of network 300. More specifically, FIG. 2 shows, on the left side 401, nodes 10 of the subset SNA of FIG. 1 on which five computing units 15, more specifically, a set of computing units CUA1, CUA2, CUA3, CUA4, and CUA5, execute. The set of computing units CUA1, CUA2, CUA3, CUA4, and CUA5 executes on each node 10 of the subnet SNA. Furthermore, the set of computing units CUA1, CUA2, CUA3, CUA4, and CUA5 is replicated throughout the subnet SNA so that each of computing units CUA1, CUA2, CUA3, CUA4, and CUA5 has the same unit state. This may be implemented, inter alia, by performing active replication of the unit state space of computing units CUA1, CUA2, CUA3, CUA4, and CUA5 on each node 10 of the subnet SNA.

[0051] 4 further illustrates, on the right side 402, the nodes 10 of the subnet SNB of FIG. 1 on which four computing units 15, more specifically the set of computing units CUB1, CUB2, CUB3, and CUB4, are executed. The set of computing units CUB1, CUB2, CUB3, and CUB4 runs on each node 10 of the subnet SNB. Furthermore, the set of computing units CUB1, CUB2, CUB3, and CUB4 is replicated throughout the subnet SNB such that each of the computing units CUB1, CUB2, CUB3, and CUB4 has the same unit state, for example by performing active replication in the unit state space as described above.

[0052] Returning to Figure 3, network 300 is configured to exchange inter-subnet messages 16 between subnets SNA, SNB, SNC, and SND via messaging protocols and consensus protocols. The consensus protocols are configured to reach consensus at each receiving subnet regarding the processing order of inter-subnet messages 16. For example, with reference to subnet SNB, it receives inter-subnet messages 16 from subnets SNA, SNC, and SND. The consensus protocols receive and process these inter-subnet messages 16 and execute a predefined consensus algorithm or mechanism to reach consensus regarding the processing order of the received inter-subnet messages 16.

[0053] According to an embodiment, network 300 may be configured to run the consensus protocol separately on each subnet. That is, each of the SNA, SNB, SNC, and SND subnets runs its own consensus protocol separately and independently of the other subnets. Thus, each of the SNA, SNB, SNC, and SND subnets can determine, by itself and independently of the other subnets, which received messages to process and in what order to process them. Thus, each of the SNA, SNB, SNC, and SND subnets achieves consensus on a subnet-by-subnet basis regarding the processing order of received inter-subnet messages 16. Such consensus may also be referred to as local consensus or subnet consensus.

[0054] This concept is explained in more detail with reference to FIG. FIG. 5 is a schematic diagram of an inter-subnet message 16 received at the SNB of the subnet 11 of FIG. The subnet SNB receives inter-subnet messages SNA-SNB from the subnet SNA, inter-subnet messages SNC-SNB from the subnet SNC, and inter-subnet messages SND-SNB from the subnet SND. A pool of these inter-subnet messages is processed by a consensus component (CSNB) 30 that runs a consensus protocol locally on the subnet SNB. Therefore, the consensus component 30 may be referred to as the subnet consensus component. The consensus component 30 generates a queue of input blocks IB from the inter-subnet messages according to a predefined consensus algorithm or mechanism and provides the queue of input blocks IB to a messaging component (MSNB) 31 configured to execute a messaging protocol and further process the input blocks IB.

[0055] According to an embodiment, each of the nodes 10 in each subnet 11 may participate in the consensus protocol. According to such an embodiment, each of the subnets 11 may include, for example, 10 to 100 nodes, in particular 20 to 50 nodes. Such a number may provide an advantageous compromise between security and efficiency. According to another embodiment, the consensus protocol may be configured to elect committee members from multiple nodes 10 in each subnet 11 according to a predefined election scheme, and to run the consensus protocol only with the elected members of the committee. Such an approach is particularly useful for subnets with larger numbers of nodes, e.g., subnets with 1000 or more nodes.

[0056] FIG. 6 is a schematic block diagram illustrating protocol components 600 of a subnet protocol client, such as subnet protocol client 42 shown in FIG. The solid arrows in Figure 6 relate to execution messages, including inter-unit messages and ingress messages, which may be mutation queries, especially from users. The dashed arrows relate to system information.

[0057] The 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 for executing messages, particularly for executing inter-unit messages and / or mutation queries. The 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 management component 65 configured to execute a state management protocol, an XNet component 66 configured to execute a cross-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 also includes a cryptography component 68. The cryptography component 68 cooperates with a security component 611, which may be implemented as a security application 43, as described below with reference to FIG. 13, for example. The protocol component 600 further includes a state reader component 69 configured to receive read queries, or read requests, from users.

[0058] The state reader component 69 is configured to cooperate with the state management component 65 . Read queries received and processed by the state leader component 69 are specifically implemented as non-mutation queries, i.e., they do not permanently change the unit state of the computational units. On the other hand, ingress messages received from the ingress message handler component 67 and passing through the consensus component 63 may be specifically implemented as mutation queries, i.e., they change the unit state of the respective computational units executing the mutation query. Because read queries do not need to pass through the consensus component 63, they can be executed asynchronously on any node in the respective subnet and therefore can run faster.

[0059] Additionally, the subnet protocol clients 42 may cooperate with a leader component 610, which may be part of the mainnet protocol clients 41 as described with reference to Figure 13. The leader component 610 may provide each subnet protocol client 42 with information stored and distributed by the mainnet, including the assignment of nodes to subnets, the public keys of the nodes, the assignment of compute units to subnets, etc.

[0060] The messaging component 61 and the execution component 62 are configured so that all computation, data and state in these components is replicated identically across all nodes in their respective subnets, and more specifically across all trusted nodes in their respective subnets, as indicated by the wave-pattern background of these components. Such identical replication is achieved according to an embodiment by, on the one hand, the action of the consensus component 63, which ensures that the stream of inputs to the messaging component 61 is agreed upon by the respective subnets and, as such, is identical for all nodes, more particularly for all trusted nodes, and, on the other hand, by the fact that the messaging component 61 and the execution component 62 are configured to perform deterministic and replicated computations.

[0061] The XNet transport component 66 sends message streams to and receives message streams from other subnets. Most components will access the crypto component 68 to run encryption algorithms and the main net reader 610 to read configuration information.

[0062] The execution component 62 receives the unit states of and incoming messages for the computational units from the messaging component 61, and sends back outgoing messages and updated unit states for the computational units. It may also measure the gas or fuel consumption of processed messages (queries) during execution.

[0063] The messaging component 61 is initiated by an input block received from the consensus component 63. For each input block, the messaging component 61 performs the following steps: parses each input block to obtain messages for the computational units; routes the messages to the input queues of the different computational units, and schedules the messages for execution by the scheduler according to the capacity allocated to each computational unit; processes the messages by the corresponding computational units using the execution component 62, resulting in messages to be sent being added to the output queues of the respective computational units; however, messages destined for computational units on the same subnet can be directly queued in the input queues of the corresponding computational units; finally, the messaging component 61 routes messages in the output queues of the computational units to message streams for the subnet where the receiving computational unit is located, and forwards these message streams to the state management component 65 to be authenticated, i.e., signed by the respective subnet.

[0064] State management component 65 includes authentication component 65a, which is configured to authenticate the output stream of each subnet, which may be performed, for example, by a group signature of the computing units of each subnet. The authentication component 65a may further be configured to authenticate certain variables of the unit state, and in particular certain variables of the unit state snapshot, as will be explained in more detail below.

[0065] Figure 7 is an exemplary visualization of the workflow of messaging protocols, consensus protocols, and associated components, e.g., workflow 700 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 and subnet SNAs and SNCs. Furthermore, the subnet SNB exchanges ingress messages with multiple users U.

[0066] Starting from the bottom right of Figure 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 contains inter-subnet messages 711 from subnet SNA to subnet SNB. Input stream 702 contains inter-subnet messages 712 from subnet SNC to subnet SNB. Input stream 703 contains ingress messages 713 from multiple users U to subnet SNB.

[0067] Inter-subnet messages 711 and 712 include inter-unit messages exchanged between computing units of different subnets, as well as signaling messages. Signaling messages are used for acknowledging or negatively acknowledging the receipt of an inter-unit message. Messaging component 61 is configured to send signaling messages from a receiving subnet to a corresponding sending subnet, i.e., in this example, from subnet SNB to subnets SNA and SNC. Messaging component 61 is configured, according to the present embodiment, to store the sent inter-unit messages until it receives an acknowledgement message for the respective inter-unit message. This allows delivery to be guaranteed.

[0068] The consensus component 63 is configured to receive and process inter-subnet messages 711, 712 of subnets SNA and SNC and ingress messages 713 of user U, and to generate a queue of input blocks 720 from the inter-subnet messages 711, 712 and ingress messages 713 according to a predefined 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, 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 vary the number of messages per input block based on the current load of the subnet.

[0069] The consensus component 63 then provides the queue of input blocks 720 to the messaging component 61. The messaging component 61 is configured to execute a messaging protocol and process the input blocks 720. The messaging protocol and messaging component 61 begins with an input block 720 received from the consensus component 63 . Before processing a received input block, the messaging component 61 may perform one or more pre-processing steps, including one or more input checks, which may be performed by the input check component 740.

[0070] Input checks may be performed at different granularities depending on the embodiment. First, input checks may be performed on the entire input block. Such checks may also be denoted input block checks. These may include checking the height of the next input block. If the height of the next input block is lower than the expected next in sequence, the input block is discarded. If the input block is not the expected next in sequence, the messaging component 61 may invoke a node catch-up protocol. If the input block is the next in sequence, the input block is further processed by the messaging component 61.

[0071] Different types of messages in an input block (signaling messages, ingress messages, inter-unit messages) may be grouped together.

[0072] The input checks may further include an overload check to check whether the messaging component is currently overloaded and does not have enough processing power to perform the processing. For example, if the associated queue in the induced pool is full, the corresponding message may be rejected. Furthermore, the input checks may include an in-order delivery check. To meet the in-order delivery requirement, messages can be annotated with, for example, a sequence number. When a message with a sequence number is received, the messaging component 61 can check whether it has the expected number and, if not, reject it. Furthermore, the input check component 740 can perform a validity check of the target destination, i.e., whether the message is intended for a computing unit that is active on the corresponding subnet.

[0073] If the input checks are successfully passed, the message of each input block 720 may be further processed by the messaging component 61, and the corresponding message may be added to a corresponding queue of the directing pool of the directing pool component 731. The directing pool component 731 of the messaging component 61 receives the input blocks and input messages that have successfully passed the input checks component 740 and have been accepted by the messaging component 61 accordingly for further processing. In general, the messaging component 61 pre-processes the input block 720 by placing ingress, signaling, and inter-subnet messages as appropriate into the directed pool component 731. Signaling messages in the subnet stream are treated as confirmation of messages in the purgeable output queue.

[0074] In this example, the directed pool component 731 includes subnet-to-unit queues SNA-B1, SNC-B1, SNA-B2, and SNC-B2, and user-to-unit queues U-B1 and U-B2. Following these preprocessing steps, messaging component 61 invokes execution component 62 (see FIG. 6 ) to execute as many induced pools as possible during one execution cycle, providing the specified execution time and a random seed as additional inputs. Following the execution cycle, the resulting message output queues are provided to output queue component 733. Initially, output queue component 733 includes inter-unit and unit-to-user output queues, which in this example include inter-unit output queues B1-A1, B1-C2, B2-A2, and B2-C3, and unit-to-user output queues B1-U1 and B2-U4. As an example, message B1-A1 represents a message from computing unit B1 of subnet SNB to computing unit A1 of subnet SNA. As another example, message B1-U1 represents a message from computing unit B1 of subnet SNB to user U1.

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

[0076] The messaging component 61 further comprises a state storage component 732 configured to store the state / unit state of the computing units of the respective subnet, in this example the states of the computing units B1 and B2 of the subnet SNB. The corresponding unit state is the working memory of each computing unit. The messaging component 61 is responsible for deterministically changing certain parts of the system state. In each round, the execution component 61 executes certain messages from the induced pool by reading and updating the state of each computation unit, and then returns the outgoing messages that the executed computation unit wants to send. These messages initially enter the output queue component 733, which contains inter-unit messages between computation units in the network. Intra-subnet messages between computation units in the same subnet are routed and distributed within each subnet, while inter-subnet messages are routed to output streams sorted by subnet-destination. Additionally, to inform the rest of the system which messages have been processed, two states may be maintained according to an embodiment: a first state may be maintained for inter-subnet messages and a second state may be maintained for ingress messages.

[0077] FIG. 8 illustrates a more detailed embodiment of a state management component 800, for example, state management component 65 of FIG. The state management component 800 includes a storage component 810, an authentication component 820, and a synchronization component 830. The storage component 810 is configured to store reader data 811, i.e., data that is available for read queries and that the state reader component 69 can access.

[0078] Reader data 811 includes, among other things, a read snapshot containing data for read queries submitted by users via state reader component 69. The read snapshot includes the latest unit state of the computing units of each node and one or more authenticated variables of the unit state authenticated by authentication component 820. Authentication component 820 may correspond to authentication component 65a of FIG. 6. More specifically, the authentication component 820 is configured to authenticate one or more portions, i.e., a subset of the unit state, particularly variables. Authentication can be initiated, notably by the messaging component 61, at block processing boundaries. Authenticating only one or more portions of the unit state, particularly one or more authenticated variables, rather than the entire unit state, improves the efficiency and speed of the node. While it is sufficient to read these authenticated portions or authenticated variables from only a single node, a user can provide additional read queries to further nodes in the execution subset to increase confidence in the legitimacy of unauthenticated portions of the snapshot. Furthermore, a user can verify whether they have communicated with an authentic node that holds the state of the computational unit of interest.

[0079] According to an embodiment, authentication component 820 is configured to perform a threshold signature algorithm to authenticate one or more authenticated portions. According to another embodiment, authentication component 820 can be configured to perform a multi-signature algorithm. According to yet another embodiment, authentication component 820 can be configured to perform individual signatures by the nodes of the execution subset.

[0080] The storage component 810 is further configured to store additional data, in particular a recovery snapshot 812. Such a recovery snapshot 812 may also be referred to as a full snapshot. According to an embodiment, the recovery snapshot includes all state of the nodes of the respective subnet or running subset necessary to restore the nodes of the subnet or running subset. The recovery snapshot includes all data of the messaging component 61, including, in particular, all unit states. The recovery snapshot also includes all input blocks provided by the consensus component 63. Given a recovery snapshot including input blocks, the messaging component 61 can restore that state for any block height of the subnet by replaying all input blocks up to that height. To enable other nodes to do this, the recovery snapshot is authenticated by the running subset or subnet, according to an embodiment. According to an embodiment, because the input blocks have already been authenticated by the consensus component 63, additional authentication of the input blocks of the recovery snapshot may be omitted. According to an embodiment, the recovery snapshot may be hashed. According to one embodiment, the storage component 810 persistently stores the recovery snapshot at least until a subsequent recovery snapshot is created.

[0081] Figure 9 is a timing diagram of the execution cycles performed by the messaging component 61 and execution component 62 of Figure 6, and the corresponding read cycles performed by the state management component 65 and state reader component 69. The x-axis represents time t. As described with reference to Figure 7, the messaging component begins with an input block IB generated by the consensus component. The input blocks are numbered by the consensus component in consecutive order, denoted as run heights, or height indices, and are processed by the messaging component in that order. Times tN-2, tN-1, and tN indicate the start of processing of each block with run heights N-2, N-1, and N, respectively.

[0082] Before each new input block is processed in the messaging component 61, the messaging component 61 sends a snapshot SS of the latest unit state of the computation unit to the storage subcomponent 810 of the state management 800. This snapshot SS is then stored, for example, in the cache memory of the storage subcomponent 810 during the processing and execution of the current input block, and can be used to provide user access to the snapshot's information via the state reader component 69. Thus, according to such an embodiment, there will always be a delay of one height index between the currently processed input block and the currently available snapshot information of the latest snapshot SS. As an example, during the processing and execution of an input block with height index N, available snapshot SSN-1 provides access to the snapshot information at the end of processing of the input block with height index N-1. Thus, the read height will lag one block or height index behind the height of the current execution.

[0083] During the processing and execution of the input blocks, the snapshot can be considered frozen, i.e., the stored snapshot information does not change during the execution of the input blocks. Such an approach provides an elegant and efficient way to provide users with access to the latest computational results of the computational units. More specifically, users can perform read queries with low latency via the state reader component 69. Furthermore, such an approach can provide users with access to at least partially authenticated computational results of each computational unit.

[0084] According to an embodiment, the state reader component 800 may also perform or initiate some processing on the snapshot data of the latest snapshot. More specifically, a read query may also include performing a computation on or using the data of the read snapshot by a computation unit.

[0085] Although a read query generally cannot affect the system state according to an embodiment, it may nevertheless temporarily modify the user state of a computing unit according to an embodiment, e.g., the memory and tables of the computing unit. However, all such modifications are discarded once the read query has been fully processed. Processing of such snapshot data can be used to perform operations such as sorting and filtering of results before returning the results to the user.

[0086] 10 is a simplified schematic diagram of the block-by-block processing of input blocks performed by messaging component 61 and execution component 62. As explained above, several execution messages are grouped together in a block, but the execution messages maintain a logical order within the block. Examples of execution messages, also sometimes referred to as mutations, are as follows: A user U requests the execution of a method M on a computation unit B with arguments X. - A developer V requests the installation of a computational unit D with an initial state S. - Developer V requests an upgrade of computation unit D to computation unit D' with state transition function S → S'. - Developer V requests the removal of computing unit D. Execute messages are processed in order, but read queries do not have to be processed in order and multiple read queries can be processed in parallel.

[0087] According to this example, the nodes of the underlying distributed network, specifically the running subset of nodes in each subnet, are assumed to include three nodes: Node1, Node2, and Node3. Each of the three nodes runs replicas of three compute units: CUA, CUB, and CUC. Before starting execution of block N, a snapshot of the latest unit state for the execution of block N-1 is stored as a read snapshot. During the processing and execution of the current block N, available snapshots stored by the storage component 810 of the state management component 800 include snapshots with heights or height indices less than or equal to N-1. Thus, the state reader can read snapshots with height indices K < N. While snapshots for multiple heights or height indices can be stored according to some embodiments, according to other embodiments, only the snapshot for the latest height index N-1 is stored, i.e., the snapshot for the height index immediately preceding the height index of the input block currently being processed.

[0088] 11 illustrates the processing steps of a computer-implemented method for providing users of a distributed network with access to computational results computed by the distributed network, and more particularly, by one or more computing units operating on the distributed network.

[0089] At step 1110, each node of the plurality of nodes executes one or more computational units in a deterministic and replicated manner, each of the one or more computational units including its own unit state. Step 1110 can be viewed as a general step that is performed repeatedly. Steps 1120 through 1160 illustrate the processing and execution of the execute message and may be repeated continuously in a loop. In step 1120, the network or a node of the network receives a set of execution messages to be executed. In step 1130, the consensus subset of the plurality of nodes executes a consensus protocol. The consensus protocol is configured to reach consensus on the selection and processing order of execution messages from the current set of execution messages. The current set of execution messages may include not only ingress messages as described above, but also inter-unit messages. The consensus protocol causes the consensus subset of the plurality of nodes to agree on the selection and processing order of execution messages. In step 1140, the execution subset of nodes individually executes the selected execution messages in a deterministic manner in an agreed-upon processing order, which causes a change in unit state of one or more of the computational units involved in the execution. In step 1150, the nodes of the execution subset create a read snapshot of the latest unit state of one or more computational units of the execution subset. The latest read snapshot includes the computation results of the execution message. Creating the read snapshot may additionally involve authentication of one or more portions of the read snapshot by the nodes of the execution subset. Authentication may be performed, in particular, by execution of a threshold signature algorithm by the nodes of the execution subset. In step 1160, one or more nodes of the execution subset provide one or more users with user access to a read snapshot of the unit state of one or more computational units of the execution subset and, accordingly, the most recent computational results of the corresponding computational units.

[0090] FIG. 12 is a flow chart of the processing steps of a method according to a further embodiment of the present invention. The method executes multiple processing loops 1210 sequentially with increasing height index N, where N is an increasing integer, i.e., for example, 0, 1, 2, 3, N. The processing loop 1210 includes a first loop step 1211, a second loop step 1212, and a third loop step 1213.

[0091] In a first loop step 1211, a consensus subset of nodes in the network executes a consensus protocol to reach consensus on the selection and processing order of the current set of execution messages. In a second loop step 1212, the computational units of the nodes of the execution subset, for example of the subnet, individually perform the selection of the execution message in a deterministic manner. In the third loop step 1213, the nodes of the execution subset create the read snapshot and store it, for example, in their respective cache memories. Additionally, the nodes of the execution subset may authenticate one or more portions of the read snapshot. The method then continues with a subsequent processing loop 1210, during which another input block with a subsequent height index is processed. During this subsequent processing loop, the most recent read snapshot is available for a read step 1220. More specifically, during a processing loop with height index N, one or more nodes in the execution subset may provide the user access to the read snapshot created at the end of the previous loop with height index N-1. The read step 1220 may include one or more authenticated portions, such as user verification of authenticated variables. The read snapshot is performed regularly at the end of each processing loop 1210, in particular at block boundaries between processing of subsequent input blocks, and therefore at a first rate. It should be noted that the first rate may be determined and initiated by a particular input block. According to an embodiment, the first rate does not need to be a constant time interval, but may be a time-varying time interval.

[0092] After each processing loop, each node starts a counter and checks whether the counter has expired in step 1230. The counter can be implemented in a variety of ways. In particular, it may be programmed to expire after a predetermined number of processing loops 1210, for example, after 100 processing loops 1210. When the counter expires, for example, every 100th processing loop, the corresponding node performs a recovery snapshot, which may also be referred to as a full snapshot, in step 1240. Such a recovery snapshot contains all data necessary to recover the node in the event of, for example, a node or system failure. Then, in step 1250, the counter is reset. In the event of a system or node failure, the recovery snapshot can be used to recover the node in a recovery step 1260 . The recovery snapshot is performed at a second rate. As explained, the recovery snapshot is performed only every xth, e.g., 100th, processing loop. Thus, the first rate is higher than the second rate.

[0093] 13 illustrates the main processes running on each node 10 of the network 100, 300 according to an embodiment of the present invention. A network client of a network according to an embodiment of the present invention is a set of protocol components required for a node 10 to participate in the network. According to an embodiment, each node 10 is a member of the mainnet and at most one subnet, which means that each node runs a client for the mainnet and possibly a client for a subnet.

[0094] The node manager 40 is configured to start, restart and update the mainnet protocol clients 41, the subnet protocol clients 42 and the security applications 43. According to an embodiment, each of the plurality of subnets 11 is configured to run a separate subnet protocol client 42 on its corresponding node 10. The mainnet protocol client 41 is configured, among other things, to distribute configuration data between the plurality of subnets 11. The mainnet protocol client 41 may be configured, among other things, to run only system computation units and not any user-provided computation units. The mainnet protocol client 41 is a local client of the mainnet, and the subnet protocol client 42 is a local client of the subnet.

[0095] The security application 43 stores the private key of the node 10 and performs all operations with it. The security application 43 is configured to protect private keys held by the node. More specifically, the private keys are held and processed in a separate execution environment (a separate process or a separate virtual machine (VM)). The security application 43 is configured to operate with a limited and controlled interface so that the private keys cannot be extracted via the interface. According to an embodiment, the security application is configured to operate like or similar to a hardware security module (HSM). Therefore, the security application 43 may be referred to as a software HSM.

[0096] 14 is a diagram of a layer model 1400 illustrating the main layers involved in the exchange of messages between and within subnets. Layer model 1400 includes a messaging layer 51 configured to function as an upper layer for inter-subnet communication. More specifically, messaging layer 51 is configured to route inter-subnet messages between computing units of different subnets. Furthermore, messaging layer 51 is configured to route ingress messages from users of the network to computing units of the network. The layer model 1400 further includes a plurality of consensus layers 52 configured to receive inter-subnet messages as well as ingress messages from different subnets and to incorporate them into a sequence of input blocks that are then further processed by the respective subnets, particularly by agreeing on the processing order. Additionally, the layer model 1400 includes a peer-to-peer (P2P) layer 53 configured to organize and drive communication between nodes of a single subnet. According to an embodiment, the network may include several further layers, in particular an execution layer configured to execute messages on the computing units of the network.

[0097] Below we will explain in more detail the interaction between the Mainnet Protocol Client 41 and the Subnet Protocol Client 42 (see Figure 13). The Mainnet Protocol Client 41 manages a number of registries containing configuration information for the subnets. These registries are implemented by computational units on the Mainnet, and since all nodes participate in the Mainnet, access to these registries can be achieved by a simple read state operation. That is, the Mainnet Reader 610 (see FIG. 6) may actually be a subcomponent of the Mainnet Protocol Client 41, so that interactions with this component result in interactions between the two isolated environments in which the Mainnet Client and the Subnet Client operate.

[0098] FIG. 15 illustrates a more detailed diagram of a computation unit 1500 according to one embodiment of the present invention. The computation unit 1500 includes an input queue 1501 , an output queue 1502 , a user or application state 1503 , and a system state 1504 . All input queues 1501 of a compute unit collectively constitute the induced pool, but the input queues are part of the compute unit's state. The output queues 1502 contain messages that need to be delivered to other compute units, possibly on other sub-networks. The user state 1503 consists of the main Web Assembly (WASM) module that implements the functionality of the computation unit, its dependent modules, and instances of each module. A WASM module instance consists of memory, global variables, and tables. System state 1504 cannot be freely modified by the compute unit's code. This includes metadata, other state maintained by the system on behalf of the compute unit, in particular the compiled form of WASM modules, and contexts and callbacks for outstanding (unprocessed) messages.

[0099] Figure 16 is a diagram illustrating the creation of a block in a distributed network according to an embodiment of the present invention. The block may be, in particular, the input block 720 shown in Figure 7. The input block 720 is created by the consensus component 63 running a consensus protocol, in particular the local subnet consensus protocol. In this exemplary embodiment, three input blocks 1601, 1602, and 1603 are shown. Block 1601 includes multiple transactions, namely, transactions tx1.1, tx1.2, and possibly further transactions indicated by dots. Block 1602 also includes multiple transactions, namely, transactions tx2.1, tx2.2, and possibly further transactions indicated by dots. Block 1603 also includes multiple transactions, namely, transactions tx3.1, tx3.2, and possibly further transactions indicated by dots. Input blocks 1601, 1602, and 1603 are chained together. More specifically, each block includes the block hash of the previous block, thereby cryptographically linking the current block to the previous block.

[0100] According to an embodiment, the transactions may be inter-subnet messages, ingress messages, and signaling messages. According to an embodiment, input blocks 1601, 1602, and 1603 may be created by a proof-of-stake consensus protocol. However, it should be noted that the input blocks produced by the consensus component do not need to be chained together in accordance with embodiments. Rather, any consensus protocol for achieving some agreement among the nodes of a subnet on the order in which received messages are processed can be used in accordance with embodiments.

[0101] Figure 17 illustrates in more detail a networking component 1700 configured to execute a networking protocol. Networking component 1700 may be, for example, a more detailed embodiment of networking component 64 shown in Figure 6. Networking component 1700 includes a unicast component 1710 configured to perform inter-node communication, a broadcast component 1720 configured to perform intra-subnet communication, and a cross-net component 1730 configured to perform inter-subnet communication.

[0102] Referring now to FIG. 18, there is shown a more detailed block diagram of a network node 10 according to an embodiment of the present invention, for example, of network 100 of FIG. 1. Network node 10 establishes a computing node capable of performing computing functions and therefore may generally be embodied as a computing system or computer. Network node 10 may be, for example, a server computer. Network node 10 may be configured to execute a computer-implemented method for providing users of a distributed network with access to computational results computed by the distributed network. Network node 10 is capable of operation with numerous other general-purpose or special-purpose computing system environments or configurations.

[0103] The network node 10 may be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, 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 1815, a system memory 1820, and a bus 1816 that couples various system components, including the system memory 1820, to the processor 1815.

[0104] Bus 1816 represents any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and without limitation, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0105] Network node 10 typically includes a variety of computer system readable media. Such media may be any available media that can be accessed by network node 10 and includes both volatile and nonvolatile media, removable and non-removable media. System memory 1820 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 1821 and / or cache memory 1822. Network node 1810 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 1823 may be provided for reading from and writing to a non-removable, non-volatile magnetic medium (not shown, typically referred to as a "hard drive"). Also, although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media, may be provided. In such cases, each may be connected to bus 1816 by one or more data media interfaces. As further shown and described below, memory 1820 may include at least one computer program product having a set (e.g., at least one) of program modules configured to perform the functions of embodiments of the present invention.

[0106] A program / utility 1830 having a set (at least one) of program modules 1831 may be stored in memory 1820, as well as, by way of example and not limitation, an operating system, one or more application programs, other program modules, and program data. Each or some combination of the operating system, one or more application programs, other program modules, and program data may comprise an implementation of a networked environment. The program modules 1831 generally perform the functions and / or methods of the embodiments of the invention described herein. The program modules 1831 may, in particular, perform one or more steps of a computer-implemented method for providing users of a distributed network with access to computational results computed by the distributed network, such as one or more steps of the method described above.

[0107] Network node 10 may also communicate with one or more external devices 1817, such as a keyboard or pointing device, as well as a display 1818. Such communication may occur via input / output (I / O) interface 1819. Additionally, network node 10 may communicate with one or more networks 40, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet), via a network adapter 1841. According to an embodiment, network 1840 may be, among other things, a distributed network including multiple network nodes 10, such as network 100 of FIG. 1. As shown, network adapter 1841 communicates with other components of network node 10 via bus 1816. It should be understood that other hardware and / or software components, not shown, may be used in conjunction with network node 10.

[0108] FIG. 19 illustrates how execution component 62 (see FIG. 6) coordinates parts of the computation unit to execute message M. To execute one message M from one input queue, the execution component 62 uses various fields of M to integrate different parts of the unit state with data from the scheduler 1901 of the messaging component 61, and then executes the correct part of the compiled code. The execution component 62 receives input 1902 as follows: randomness, time, and height are provided by the scheduler; the payload of the message is directly carried by the message M, i.e., it is not interpreted by the system; addressing and payment are also part of M's information; and finally, which method to execute is also specified in M.

[0109] The compiled code 1903 interacts with the system through a system API 1904, which provides the ability to access input, send messages (interacting with output queues, contexts, and callbacks), respond to the current message (interacting with the context), and transfer payments from a message to its balance. According to an embodiment, the execution component 62 may also include a fuel component 1905, which may also be referred to as a gas component. The compiled code and system API is instrumented by the fuel component, which terminates execution when a limit is reached. The amount of fuel consumed is also returned to the scheduler 1901 that made the execution call. Compiled code is paired with and executed by a particular module instance, which ensures that loads and stores are made to the correct persistent memory locations, that global variables are persisted between calls, and that the correct functions are performed when tables are used.

[0110] Aspects of the present invention may be embodied as a system, particularly a distributed network including multiple subnets, a method, and / or a computer program product. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to perform aspects of the present invention. A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution apparatus. 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, a computer-readable storage medium is not itself to be construed as a transitory signal, 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 over a wire.

[0111] The computer-readable program instructions described herein can be downloaded to each computing / processing device from a computer-readable storage medium or an external computer or external storage device over a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0112] Computer readable program instructions for carrying out 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. 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.

[0113] 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 device to create a machine. Specifically, the instructions, executed by the processor of the computer or other programmable data processing device, may be provided to create means for performing the functions / acts specified in the flowchart and / or block diagram blocks. These computer-readable program instructions may also be stored on a computer-readable storage medium that can instruct a computer, programmable data processing device, and / or other device to function in a particular manner. In such cases, storage is effected such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture containing instructions that perform aspects of the functions / acts specified in the flowchart and / or block diagram blocks.

[0114] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to perform a series of operational steps executed on the computer, other programmable apparatus, or other device to create a computer-implemented process, i.e., the instructions executing on the computer, other programmable apparatus, or other device perform the functions / acts specified in the flowchart and / or block diagram blocks. The flowcharts and block diagrams in the figures 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 one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks may be performed in an order different from that noted in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the functions may be executed in the reverse order. While preferred embodiments of the present invention have been shown and described, it is to be clearly understood that the invention is not limited thereto and that the invention can be variously embodied and embodied within the scope of the following claims.

Claims

1. A distributed network including a plurality of nodes, each of the plurality of nodes configured to operate one or more computing units; each of said computational units includes its own unit state; The distributed network comprises: independently executing a set of execution messages in a deterministic manner by an execution subset of the plurality of nodes, thereby changing the unit states of one or more of the computational units of the execution subset; periodically creating, by the nodes of the execution subset, a read snapshot of the unit state of the one or more compute units of the execution subset; configured to provide user access to the read snapshot by one or more nodes of the execution subset; The distributed network comprises: receiving a lead query from a user by one or more nodes of the execution subset; reading, by the one or more nodes, the unit state of the computational units associated with the read query; executing the computation unit using the read query; configured to return results of the read query by the one or more nodes; the read query does not permanently change the unit state; A distributed network characterized by:

2. 10. The distributed network of claim 1, The distributed network is configured to periodically execute, by a consensus subset of the plurality of nodes, a consensus protocol configured to reach consensus on the selection of an execution message from the currently available set of execution messages.

3. A distributed network according to claim 1 or claim 2, The distributed network is configured to perform a calculation on the read snapshot by a computing unit of one or more nodes of the execution subset, and to provide a result of the calculation to a user by the computing unit.

4. A distributed network according to claim 1 or claim 2, the distributed network is further configured to authenticate one or more portions of the read snapshot, thereby generating one or more authenticated portions of the read snapshot.

5. 5. The distributed network of claim 4, The distributed network is further configured to authenticate the one or more authenticated portions of the read snapshot by a majority of the nodes of the execution subset.

6. 5. The distributed network of claim 4, The distributed network comprises: authenticating the one or more portions of the read snapshot by generating a signature for the one or more authenticated portions of the read snapshot by a majority of the execution subset; The decentralized network is further configured to make the signatures available to users.

7. 7. The distributed network of claim 6, A decentralized network, characterized in that the signature is a threshold signature, a multi-signature, or a collection of individual signatures of the majority of the nodes in at least the running subset.

8. 5. The distributed network of claim 4, 10. A distributed network comprising: a network that stores a read snapshot of a unit state; a network that stores a read snapshot of a unit state;

9. A distributed network according to claim 1 or claim 2, The distributed network is further configured to record, by the nodes of the execution subset, the read snapshot of the unit state in a cache memory.

10. A distributed network according to claim 1 or claim 2, The distributed network comprises: periodically creating, by the nodes of the execution subset, recovery snapshots of the unit states of the one or more compute units of the execution subset; a majority of the nodes in the execution subset authenticating the recovery snapshot;

11. 11. The distributed network of claim 10, The distributed network is configured to persistently store the recovery snapshot at least until a subsequent recovery snapshot is created.

12. 11. The distributed network of claim 10, the distributed network is configured to execute the read snapshots at a first rate and execute the recovery snapshots at a second rate; A distributed network, wherein the first rate is greater than the second rate.

13. A distributed network according to claim 1 or claim 2, A distributed network characterized in that the execution messages include inter-unit messages exchanged between computational units of the distributed network and mutation queries received from users of the distributed network.

14. 3. The distributed network of claim 2, each node of the consensus subset includes a consensus component configured to execute the consensus protocol; Each node in the execution subset: an execution component configured to execute said selection of execution messages; a messaging component configured to receive the selection of execution messages from the consensus component and provide the selection of execution messages to the execution component; a state management component configured to manage and store the read snapshot; a state reader component configured to process read queries from users of the distributed network; an ingress message handler component configured to process mutation queries from users of the distributed network; A distributed network characterized by:

15. 3. The distributed network of claim 2, the distributed network is configured to execute a plurality of processing loops sequentially with increasing height indices N, where N is an increasing integer; The plurality of processing loops include: executing the consensus protocol in a first loop step; executing said selection of execution messages individually in a second loop step; a third loop step creating the read snapshot; During the processing loop with height index N, the distributed network is configured to provide user access to the read snapshot created at the end of a previous height index, in particular the previous height index N-1.

16. A distributed network according to claim 2 or 14, comprising: The consensus protocol comprises: receiving and processing the execution message from the currently available set of execution messages; generating a queue of input blocks from the execution messages according to a predefined consensus mechanism; providing the queue of input blocks to a messaging protocol; the messaging protocol is configured to process the input block and schedule the execution message of the input block for execution. A distributed network characterized by:

17. The distributed network of claim 16, which recites claim 14, the messaging protocol is configured to be initiated by the input block received from the consensus protocol; The distributed network, wherein the state management component is configured to create the read snapshot at a processing boundary of the input block.

18. 17. The distributed network of claim 16, The consensus protocol is further configured to add one or more execution parameters to the input block, the execution parameters being selected from a group including a random seed, a specified execution time, and a height index.

19. 3. The distributed network of claim 2, the distributed network includes a plurality of subnets; each of the plurality of nodes is assigned to one of the plurality of subnets; each of the plurality of nodes configured to execute a mainnet protocol client and a subnet protocol client; the subnet protocol client is configured to periodically execute the consensus protocol, individually execute the selection of execution messages, periodically create the read snapshot, and provide user access to the read snapshot; the Mainnet Protocol Client is configured to distribute configuration data to the plurality of subnets; A distributed network characterized by:

20. 1. A computer-implemented method for providing users of a distributed network with access to computational results computed by said distributed network, comprising: the distributed network includes a plurality of nodes; The method comprises: executing one or more computational units at each of the plurality of nodes, each of the one or more computational units including its own unit state; independently executing a set of execution messages in a deterministic manner by an execution subset of the plurality of nodes, thereby changing the unit states of one or more of the computational units of the execution subset; periodically creating, by the nodes of the execution subset, a read snapshot of the unit state of the one or more compute units of the execution subset; providing user access to the read snapshot by one or more nodes of the execution subset; receiving, by one or more nodes of the execution subset, a lead query from a user; reading, by the one or more nodes, the unit state of the computing units associated with the read query; executing the computation unit using the read query; returning results of the read query by the one or more nodes; the read query does not permanently change the unit state; 10. A computer-implemented method comprising:

21. A node for a distributed network, comprising: The node operating one or more computational units, each of said computational units including its own unit state; independently executing a set of execution messages in a deterministic manner, thereby changing the unit state of one or more of the computational units; periodically creating a read snapshot of the unit state of the one or more compute units; providing user access to said read snapshot; Receive lead queries from users, reading the unit state of the computing unit associated with the read query; executing the computation unit using the read query; returning a result of the read query; the read query does not permanently change the unit state; A node for a distributed network.

22. 1. A computer program for operating a distributed network, comprising: the distributed network includes a plurality of nodes; each of the plurality of nodes configured to operate one or more computing units; each of said computational units includes its own unit state; The computer program includes program instructions: The program instructions are executable by one or more of the plurality of nodes, whereby the method performed on the one or more of the plurality of nodes comprises: independently executing a set of execution messages in a deterministic manner by an execution subset of the plurality of nodes, thereby changing the unit states of one or more of the computational units of the execution subset; periodically creating, by the nodes of the execution subset, a read snapshot of the unit state of the one or more compute units of the execution subset; providing user access to the read snapshot by one or more nodes of the execution subset; receiving, by one or more nodes of the execution subset, a lead query from a user; reading, by the one or more nodes, the unit state of the computing units associated with the read query; executing the computation unit using the read query; returning results of the read query by the one or more nodes; the read query does not permanently change the unit state; A computer program characterized by:

23. 1. A computer program for operating a node of a distributed network, comprising: The computer program includes program instructions: The program instructions are executable by the node, thereby causing the node to perform the method: operating one or more computing units, each of said computing units including its own unit state; individually executing a set of execution messages in a deterministic manner, thereby changing the unit state of one or more of the computational units; periodically creating a read snapshot of the unit state of the one or more compute units; providing a user access to the read snapshot; receiving a lead query from a user; reading the unit state of the computing unit associated with the read query; executing the computation unit using the read query; returning a result of the read query; the read query does not permanently change the unit state; A computer program characterized by:

Images