Distributed network with multiple subnets

Abstract

According to an embodiment of a first aspect of the present invention, a distributed network comprising a plurality of subnets is provided. Each of the plurality of subnets comprises a changeable set of nodes. For each of the plurality of subnets, the network is configured to generate, by means of a distributed key generation protocol, an individual static verification key of a public key signature method and a first corresponding set of secret key shares for a first set of nodes of each subnet. For each of the plurality of subnets, the network is configured to generate a second set of secret key shares corresponding to the same static verification key of each subnet by means of a secret redistribution protocol, by redistributing the secret key shares of each first set of secret key shares to a second set of nodes of each subnet. Further aspects of the present invention relate to a corresponding computer implementation method, a node, a computer program product, and a software architecture.

Description

Technology Field

[0001] The present invention relates to a distributed network comprising a plurality of subnets. Each subnet comprises one or more nodes.

[0002] Additional aspects relate to a key management method in a distributed network having multiple subnets, a node of the distributed network, a corresponding computer program product, and a software architecture encoded in a non-transient medium. Background Technology

[0003] In a distributed network, multiple nodes are arranged in a distributed manner. In distributed network computing, software and data are distributed across multiple nodes. Nodes configure computing resources, and the distributed network can utilize distributed computing technologies.

[0004] An example of a distributed network is a blockchain network. A blockchain network is a block-based, consensus-based electronic ledger. Each block contains transactions and other information. Additionally, each block includes the hash of the previous block so that blocks are linked together to create a permanent and immutable record of all transactions recorded on the blockchain. Transactions may include, for example, small programs known as smart contracts.

[0005] For a transaction to be recorded on the blockchain, it must be "verified" by the network. In other words, network nodes must obtain consent for the block to be recorded on the blockchain. This consent can be achieved through various consensus protocols.

[0006] One type of consensus protocol is the proof-of-work consensus protocol. Proof-of-work consensus protocols typically require parties participating in the consensus protocol to perform some work, which generally corresponds to processing time by computers. Proof-of-work based cryptocurrency systems, such as Bitcoin, involve solving computationally intensive puzzles to verify transactions and generate new blocks.

[0007] Another type of consensus protocol is the proof-of-stake consensus protocol. These protocols have the advantage of not requiring time-consuming and energy-intensive computing. For example, in a proof-of-stake-based blockchain network, the creator of the next block is selected through a combination of random selection and the stakes of each node within the network.

[0008] In addition to cryptocurrencies, decentralized networks can be used for various other applications. In particular, decentralized networks can be used to provide decentralized and distributed computing functions and services.

[0009] One problem with distributed networks is that the computational results of a subnet, such as state information, must be provided to external users of the subnet and / or other subnets in a secure, efficient, verifiable, and / or user-friendly manner.

[0010] Accordingly, one objective of an embodiment of the present invention is to provide a distributed network having advanced capabilities, particularly in terms of key management.

[0011] Another objective of another aspect of the present invention is to provide a distributed network that facilitates the verification of network computation results, particularly state information, in a safe, efficient, and / or user-friendly manner.

[0012] According to an embodiment of the first aspect of the present invention, a distributed network comprising a plurality of subnets is provided. Each of the plurality of subnets includes a changeable set of nodes. For each of the plurality of subnets, the network is configured to generate, by a distributed key generation protocol, an individual static verification key of a public key signature method and a first set of corresponding secret key shares for a first set of nodes of each subnet.

[0013] The network is further configured to, for each of the multiple subnets, redistribute the secret key shares of each first secret key share set to a second set of nodes in each subnet by means of a secret redistribution protocol, thereby creating a second secret key share set corresponding to the same static verification key of each subnet.

[0014] According to such embodied method, each of the plurality of subnets has an individual, i.e., self-owned, static verification key that remains constant over time. According to the embodiment, the static verification key may remain constant for the entire lifetime of the corresponding subnet. Therefore, the static verification key may be represented as a constant verification key.

[0015] While the static verification key remains constant, the corresponding secret key share may change over time. Additionally, the set of nodes forming or representing a subnet may change over time; that is, nodes may be added or removed from each subnet.

[0016] More specifically, initially, the subnet includes a first set of nodes, which may also be referred to as an initial set of nodes. According to an embodiment, each node of the first set of nodes holds a secret key share of a first set of secret key shares. The first set of secret key shares corresponds to a static verification key. More specifically, the static verification key enables verification of a joint signature performed by an acceptable subset of secret key shares.

[0017] The static verification key is a key for the public key signing scheme and can also be referred to as the public key. The corresponding secret key share can also be referred to as the signing key share or the signing key.

[0018] A public key signature method according to an embodiment of the present invention may include, for example, a key of a public key signature and encryption method such as RSA or a key of a public key signature method such as Schnorr or DSA.

[0019] Subsequently, the first set of secret key shares can be redistributed into the second set of secret key shares by the secret redistribution protocol. That is, the secret redistribution protocol updates the secret key shares of the secret key corresponding to the static verification key.

[0020] Such a distributed network with static verification keys for multiple subnets offers advantages in terms of key management, verification, and / or authentication. Specifically, on the one hand, since the static verification of multiple subnets remains constant over time, verifiers can always use the same static verification key to verify information provided by the subnets. On the other hand, through the redistribution of the secret key share, the distributed network can be tailored to the specific needs of each network in terms of security and flexibility. Thus, this distributed network offers users the advantage of being able to verify information provided by each subnet of the network using the same static verification key at all times. Furthermore, above all, the distributed network provides flexibility to the subnets, meaning that subnets can nevertheless update their secret key share internally for security or other reasons.

[0021] According to the embodiment, each node of the node subset of the first node set holds one secret key share of the first secret key share set.

[0022] According to the embodiment, each node of the node subset of the second node set holds one of the secret key shares of the second key share set.

[0023] According to the embodiment, a subset of the first set may include all nodes of the first set or may not include all nodes of the first set. In the first case, each node of the first set of nodes holds one secret key share of the first set of secret key shares. In the latter case, only the assigned committee of the first set of nodes may hold a secret key share.

[0024] According to the embodiment, a subset of the second set may include all nodes of the second set or may not include all nodes of the second set. In the first case, each node of the second set of nodes holds one secret key share of the second set of secret key shares. In the latter case, only the assigned committee of the second set of nodes may hold the secret key shares.

[0025] According to an embodiment, a node in each subnet is configured to execute an allocated set of compute units. The compute units of a subnet are configured to execute compute in a deterministic and replicated manner across the subnet.

[0026] Such networks perform replicated computing across subnets. Therefore, subnets can also be represented as replicated computing clusters. For such networks, it is particularly advantageous to provide constant / static verification keys for multiple subnets.

[0027] A compute unit can be defined as a piece of software that runs on a node of a network and has its own unit or execution state. Each subnet is configured to replicate a set of compute units allocated across the subnet, specifically the unit state / execution state / state of the compute units.

[0028] According to an embodiment, replication of the unit state of a computational unit can be performed by performing active replication in the space of an allocated subset of the computational unit at each node of the subnet.

[0029] According to one embodiment, the network is further configured to redistribute the secret key shares of a second secret key share set to a third set of nodes of each subnet by means of a secret redistribution protocol for each of the plurality of subnets. This creates a third secret key share set corresponding to the same static verification key of each subnet.

[0030] According to the embodiment, each node of a subset of the third node set holds one of the secret key shares of the third key share set.

[0031] According to such an embodiment, the secret redistribution protocol can be used to perform additional updates to the secret key share. This can be particularly useful in terms of network security and / or network configuration flexibility. This step can be repeated as desired.

[0032] More specifically, according to some embodiments, the first node subset may be identical to the second node subset and / or the second node subset may be identical to the third node subset. That is, the configuration of the corresponding subnets has not changed. In this scenario, updating the secret key shares particularly enhances the security of the distributed network. This approach can be used particularly to implement preemptive security. In this regard, according to embodiments, a secret redistribution protocol may be performed periodically at predefined intervals for each subnet. This can prevent an attacker from gaining control of the subnet by collecting a sufficient number of key secret key shares to reconstruct the secret key corresponding to the subnet's static verification key.

[0033] According to another embodiment, the first node subset is different from the second node subset and / or the second node subset is different from the third node subset.

[0034] In this scenario, updating the secret key share allows it to be adjusted to a new or modified subnet configuration while the static verification key remains the same. Therefore, even if the subnet configuration changes, external users or external subnets receiving information from this subnet do not need to worry about such changes, and since the static verification key remains the same, they do not even need to be aware of them.

[0035] In this regard, an embodiment of the present invention enables the current subnet configuration to be hidden from users of a distributed network. Only a static verification key is required for a user to verify information from the subnet, and the corresponding configuration and distribution of the secret key share can be hidden. This can prevent or at least hinder adaptive attacks on nodes of the subnet.

[0036] According to an embodiment, the distributed key generation protocol may be, in particular, a distributed threshold key generation protocol.

[0037] Accordingly, according to this embodiment, the distributed key generation protocol generates a static threshold verification key of the public key signature method and a corresponding threshold secret key sharing set for the first set of nodes of each subnet.

[0038] According to such an embodiment, an acceptable subset of secret key shares held by a node can be used to generate a signature under a static verification key. This acceptable subset may be a predefined number of secret key shares or, generally, any predefined combination of secret key shares. According to an embodiment, the acceptable subset may be defined by a generally predefined access structure.

[0039] According to the embodiments, the secret redistribution protocol may be a critical key redistribution protocol in particular.

[0040] According to such an embodiment, the secret redistribution protocol is configured to redistribute the secret threshold key share corresponding to the threshold verification key.

[0041] According to an embodiment, nodes of a plurality of subnets are configured to perform a joint signature on subnet information through their secret key sharing portion by an acceptable subset of nodes.

[0042] This provides authentication of subnet information through a joint signature. The joint signature corresponds to a static verification key, meaning it can be verified with a static verification key. Subnet information is generally arbitrary information about the subnet, specifically information about the execution status of the subnet's computing units.

[0043] Signed subnet information can be provided to users and / or other receiving subnets of a distributed network.

[0044] According to one embodiment, a user and / or receiving subnet of a distributed network is configured to verify the joint signature of subnet information through a static verification key of the corresponding subnet.

[0045] According to an embodiment, a distributed network includes a governance subnet comprising a plurality of constituent nodes. The governance subnet is configured to store static verification keys for a plurality of subnets and to hold a root verification key of a public key signature method and a plurality of corresponding secret key shares. The governance subnet is further configured to receive a verification key request to provide a static verification key for one or more subnets and to provide a verification key response containing a static verification key for one or more subnets in response to the verification key request. The governance subnet is further configured to generate a joint signature for the verification key response by signing the verification key response with an acceptable subset of secret key shares corresponding to the root verification key by a subset of nodes of the governance subnet.

[0046] These governance subnets can provide users with a single root of trust. In particular, users do not need to know the configuration of each subnet or manage the static verification keys of the subnets. Instead, users can obtain any necessary static verification key from the governance subnet and verify the received static verification key against the root verification key.

[0047] According to the embodiment, the joint signature may be, in particular, a threshold signature or, in other words, a signature by a threshold key / threshold secret key.

[0048] According to an embodiment of the method of the present invention, a computer implementation method for managing a verification key in a distributed network including a plurality of subnets is provided.

[0049] This method includes the step of generating, for each of a plurality of subnets, an individual static verification key of a public key signature scheme and a first corresponding set of secret key shares for a first set of nodes of each subnet by means of a distributed key generation protocol. This method further includes the step of generating a second set of secret key shares corresponding to the same static verification key of each subnet by means of a secret redistribution protocol for each of the plurality of subnets, by redistributing the secret key shares of each first set of secret key shares to a second set of nodes of each subnet.

[0050] According to an embodiment, each node of a first set of nodes holds one secret key share of a first set of secret key shares. According to an embodiment, each node of a second set of nodes holds one of the secret key shares of a second set of key shares.

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

[0052] According to an embodiment of another aspect of the present invention, a computer program product for operating a distributed network is provided. The computer program product comprises a computer-readable storage medium in which program instructions are implemented, and the program instructions are executable by one or more of a plurality of nodes of a distributed network, thereby enabling one or more of the plurality of nodes to perform an aspect of the method of the present invention.

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

[0054] According to an embodiment of another aspect of the present invention, a software architecture encoded on a non-transient computer-readable medium is provided. The software architecture is configured to operate one or more nodes of a distributed network. The encoded software architecture is executable by one or more of a plurality of nodes, thereby enabling one or more of the plurality of nodes to perform an aspect of the method of the present invention.

[0055] The features and advantages of one embodiment of the present invention can be appropriately applied to other embodiments of the present invention.

[0056] Other preferred embodiments are listed in the dependent claims and the description below. Brief explanation of the drawing

[0057] The present invention will be better understood from the following detailed description, and purposes other than those described will also become apparent. This description refers to the accompanying drawings. FIG. 1 illustrates an exemplary block diagram of a distributed network according to an embodiment of the present invention. Figure 2 shows the expansion of the second subnet over time. FIG. 3 illustrates a correspondence table including a corresponding expansion of the secret key set of the second subnet. Figure 4 illustrates a computational unit running at a node of a network in a more detailed manner. FIG. 5 illustrates a flowchart of the method steps of a method according to an embodiment of the present invention. FIG. 6 illustrates a flowchart of an additional method step of a method according to an embodiment of the present invention. FIG. 7 illustrates a schematic diagram of a distributed network according to an embodiment of the present invention. Figure 8 shows an exemplary message flow of key exchange between a governance subnet and a user or other subnet. FIGS. 9a and 9b illustrate embodiments of a verification key and its corresponding secret key sharing portion that can be used according to an embodiment of the present invention. FIG. 10 illustrates the creation of a block in a distributed network according to an embodiment of the present invention. FIG. 11 illustrates a more detailed block diagram of a network node according to an embodiment of the present invention. FIG. 12 illustrates a more detailed example of a calculation unit according to an embodiment of the present invention. Specific details for implementing the invention

[0058] First, some general aspects and terms of the embodiments of the present invention will be introduced.

[0059] 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 the plurality of nodes. The nodes set up computing resources, and the distributed network can particularly utilize distributed computing technology.

[0060] According to embodiments, the distributed network may be implemented specifically 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.

[0061] Verification Key: A bit string of a public key signature scheme intended to be widely public. The verification key can also be represented as a public key and can be used, for example, to verify a digital signature in a public key signature scheme.

[0062] A public key signature method according to an embodiment of the present invention may include, for example, a key of a public key signature and encryption method such as RSA or a key of a public key signature method such as Schnorr or DSA.

[0063] Secret key (sk): A bit-string associated with a public key, specifically a verification key, that enables certain cryptographic operations, particularly digital signatures on messages and / or ciphertext encryption.

[0064] Distributed Key Generation (DKG): A protocol that enables a dealer set to generate a public key, specifically a verification key, and provide a shared portion of the corresponding secret key to a receiver set.

[0065] Secret Redistribution Protocol: The secret redistribution protocol may also be referred to as a secret re-sharing protocol. A protocol for updating a secret key share of a secret key. According to some embodiments, the protocol may provide a new or updated secret key share to a previous holder of the secret key share. According to other embodiments, the protocol may provide a new or updated secret key share to a new, particularly different, set of recipients.

[0066] (n,t)-threshold key / threshold secret key: Such a threshold key has a threshold (t) and multiple secret key shares (s1,...,sn) such that any t secret key shares enable the reconstruction of the secret key, but t-1 shares are insufficient to determine the secret key. In the case of a threshold public key signature scheme, any t secret key shares enable the execution of a valid signature under the threshold public key / verification key, but t-1 shares are insufficient to execute a valid signature.

[0067] Verifiable secret sharing (VSS): A protocol that enables a single dealer to generate random secret(s), a threshold secret sharing (s1,...,sn) for a set of recipients, and proof that each recipient can use to verify that their own sharing (si) is correct.

[0068] Proactive security: A security concept that captures multi-party systems that allow compromise of t-1 parties at any time. Time is divided into epochs, and while up to t-1 parties are compromised in each epoch, the attacker is mobile in that the set of compromised parties can differ from epoch to epoch. A distributed key management system with proactive security can be built by dividing time into epochs and using a new threshold of secret sharing for the secret key in each epoch.

[0069] Public key encryption with forward secrecy: A public key encryption method that divides time into epochs and allows the private decryption key to evolve over time, so that even if compromised, it does not help in decrypting the ciphertext of a previous epoch.

[0070] According to the embodiments, the Feldman protocol [Fel87], the Co-Feldman protocol [Ped91], and the GJKR protocol [GJKR99] may be used as distributed key generation protocols. These protocols are disclosed, for example, as follows, and the disclosures are incorporated by reference herein.

[0071] [Fel87] Paul Feldman. A practical scheme for non-interactive verifiable secret sharing.

[0072] In 28th Annual Symposium on Foundations of Computer Science, pages 427-437, Los Angeles, California, October 12-14, 1987. IEEE Computer Society Press.

[0073] [Ped91] Torben P. Pedersen. A threshold cryptosystem without a trusted party (extended abstract) (rump session). In Donald W. Davies, editor, Advances in Cryptology - EUROCRYPT'91, volume 547 of Lecture Notes in Computer Science, pages 522-526, Brighton, UK, April 8-11, 1991. Springer, Heidelberg, Germany.

[0074] [GJKR99] Rosario Gennaro, Stanislaw Jarecki, Hugo Krawczyk, and Tal Rabin. Secure distributed key generation for discrete-log based cryptosystems. In Jacques Stern, editor, Advances in Cryptology - EUROCRYPT'99, volume 1592 of Lecture Notes in Computer Science, pages 295-310, Prague, Czech Republic, May 2-6, 1999. Springer, Heidelberg, Germany.

[0075] According to an embodiment of the present invention, the following protocol may be used, for example, as a secret redistribution protocol.

[0076] Herzberg, Amir; Jarecki, Stanislaw; Hugo, Krawczyk; Yung, Moti ( 1995 ).Proactive Secret Sharing Or: How to Cope With Perpetual Leakage . CRYPTO '95: Proceedings of the 15th Annual International Cryptology Conference on Advances in Cryptology. London, UK: Springer-Verlag. pp. 339-352. ISBN 　 978-3-540-60221-7.

[0077] A simplified approach to threshold and proactive RSA", by T Rabin - Annual International Cryptology Conference, 1998 - Springer.

[0078] FIG. 1 illustrates an exemplary block diagram of a distributed network (100) according to an embodiment of the present invention.

[0079] A distributed network (100) includes a plurality of nodes (10), which may also be denoted as network nodes (10). The plurality of nodes (10) are distributed across a plurality of subnets (11). A subnet (11) may also be denoted as a subnet. In the example of FIG. 1, four subnets (11) denoted as SNA, SNB, SNC, and SND are provided.

[0080] Each of the plurality of subnets (11) is configured to execute a set of computational units at each node (10) of each subnet (11). According to the embodiment, a computational unit should be understood as a piece of software, specifically a piece of software that includes or has its own unit state. The unit state may also be indicated as an execution state.

[0081] The network (100) includes a communication link (12) for intra-subnet communication within each subnet (11), in particular a communication link (12) for exchanging intra-subnet unit-to-unit messages between computing units assigned to the same subnet.

[0082] Additionally, the network (100) includes a communication link (13) for inter-subnet communication between different subnets (11), in particular a communication link (13) for exchanging inter-subnet unit-to-unit messages between computing units assigned to different subnets.

[0083] Accordingly, the communication link (12) may also be referred to as an intra-subnet or P2P (Peer-to-Peer) communication link, and the communication link (13) may also be referred to as an inter-subnet or SN2SN (Subnet-to-Subnet) communication link.

[0084] The network (100) is configured to exchange unit-to-unit messages between the computational units of the network through a messaging protocol based on subnet allocation.

[0085] According to an embodiment, a distributed network may be configured to exchange inter-subnet messages (16) between subnets (SNA, SNB, SNC, and SND) particularly through a messaging protocol. The inter-subnet messages (16) may be implemented as inter-subnet unit-to-unit messages (16a) to be exchanged between computation units assigned to different subnets, particularly according to subnet allocation. For example, the distributed network (100) may include a computation unit (CU) which is a sending computation unit running in a subnet (SNA). A1 The computation unit (CU), which is a receiving computation unit running in the ) and subnet (SNB). B2 It can be configured to exchange unit-to-unit messages (16a) between them (see FIG. 4). Additionally, the inter-subnet message (16) can be implemented as a signaling message (16b). The signaling message (16b) may include an acknowledgment message (ACK) adapted to acknowledge acceptance or reception of the unit-to-unit message, or a non-acknowledgment message (NACK) adapted to indicate a transmission failure, for example, to not acknowledge acceptance of the unit-to-unit message (corresponding to rejection).

[0086] According to the embodiments, the unit state or execution state should be understood as all data or information used by the computation unit, in particular, as well as data that the computation unit stores in variables and data that the computation unit obtains from remote calls. The unit state may represent a specific storage location of each memory location of each node. At any given point in the execution of the computation unit, the contents of these memory locations are referred to as the unit state according to the embodiments. The computation unit may be implemented specifically as a state-maintaining computation unit, that is, the computation unit is designed to remember preceding events or user interactions according to the embodiments.

[0087] According to an embodiment of the present invention, a subnet (11) is configured to replicate a set of computational units across each subnet (11). In particular, the subnet (11) is configured to replicate the unit state / execution state of the computational units across each subnet (11).

[0088] The network (100) may include a plurality of interfaces (101) that can be used to exchange information with a user (U) of the distributed network. For example, the user (U) can send a read request to the distributed network through the interface (101) and receive a read response, such as execution status information containing a calculation result. According to a preferred embodiment, the user does not need to know the internal structure of the distributed network (100). In particular, the user preferably does not know the subnet configuration and each subnet processing their read request.

[0089] The subnet (11) can be reconfigured over time. More specifically, the number of nodes in the subnet (11) can change over time. For example, nodes can be added to the subnet (11) and / or nodes can be removed from the subnet (11). Thus, the subnet (11) includes a changeable set of nodes.

[0090] Each subnet (11) holds a private or individual static verification key using a public key signature method. In this example, the subnet (SNA) holds a static verification key (pk A ) holds, and the subnet (SNB) has a static verification key (pk B ) holds, and the subnet (SNC) has a static verification key (pk C It holds ), and the subnet (SND) has a static verification key (pk D Holds ). The static verification key is generally pk below. X It may be referred to as, where X represents the corresponding subnet. According to an embodiment, a static verification key (pk X ) is constant, that is, fixed for the entire lifespan of each subnet (11).

[0091] Static validation key (pk) X ) is generated by a distributed key generation protocol. The distributed key generation protocol provides a first corresponding set of secret key shares (sks1, sks2, sks n ), that is, each static validation key (pk) X A first secret key shared set corresponding to ) is created. The first secret key shared set is assigned to the first node set of each subnet. The first node set may specifically be the nodes of each subnet at time (t0), where time (t0) may be the creation time of each subnet. Verification key (pk X ) is the verification key of the public key signature method. Therefore, the verification key (pk X ) is the secret key sharing portion (sks1, sks2, sks n It can be used to verify joint signatures generated by nodes holding ). A distributed key generation protocol can be a critical key generation protocol in particular.

[0092] Static verification key (pk) of the distributed network (100) X) does not change over time, but the corresponding secret key shares (sks) may change over time. Changes to these secret key shares may be made when the node set of each subnet changes, or even when there are no changes to the nodes of the subnet. The latter can be used to provide preemptive security.

[0093] To change the secret key shares, the distributed network (100) performs a secret redistribution protocol. The secret redistribution protocol redistributes the secret key shares of the first set of secret key shares of each subnet to the second set of nodes of each subnet. This creates a second set of secret key shares corresponding to the same static verification key of each subnet. Consequently, each node or a subset of the second set of nodes holds one of the secret key shares of the second set of key shares.

[0094] This will be explained in more detail with reference to FIGS. 2 and FIGS. 3.

[0095] Figure 2 shows the expansion of a subnet (SNA) over time. Figure 3 shows a correspondence table including the corresponding expansion of the secret key set of the subnet (SNA).

[0096] Now, referring to FIG. 2, the subnet (SNA) initially has a subnet configuration (201) at time (t0), for example, at its creation. According to this subnet configuration (201), the subnet (SNA) includes five nodes (N1, N2, N3, N4, and N5). The subnet (SNA) has a static verification key (pk) of the public verification key method. A Nodes (N1, N2, N3, N4, and N5) establish the first set of nodes, or in other words, the initial set of nodes.

[0097] Now, referring to FIG. 3, the left column (301) contains a corresponding number of nodes of the subnet (SNA), specifically nodes (N1, N2, N3, N4, N5, N6, and N7). The columns (302, 303, 304, 305, and 306) contain the respective secret key shares of the corresponding nodes at different points in time. Specifically, column (302) corresponds to time (t0), column (303) corresponds to time (t1), column (304) corresponds to time (t2), column (305) corresponds to time (t3), and column (306) corresponds to time (t4). The rows (311, 312, 313, 314, 316, and 317) each contain the secret key shares of the nodes (N1, N2, N3, N4, N5, N6, and N7).

[0098] At time (t0), the nodes (N1, N2, N3, N4, and N5) of the subnet (SNA) each have a secret key share ( share 1,0 , share 2,0 , share 3,0 , share 4,0 and share 5,0 Holds ). The first digit of the subscript represents each node, and the second digit of the subscript represents each time point.

[0099] At a subsequent time point (t1), the subnet (SNA) still has the same set of nodes. Nevertheless, the distributed network has a secret key share ( share 1,0 , share 2,0 , share 3,0 , share 4,0 and share 5,0 A secret redistribution protocol was performed to redistribute ) to a second node set consisting of the same node set (N1, N2, N3, N4, and N5) in this case. The secret redistribution protocol is a second secret key sharing set different from the first set ( share 1,1, share 2,1, share 3,1, share 4,1 and share 5,1 ) created or generated. The second key sharing set is the same static verification key (pk) of the subnet (SNA). A Corresponds to ).

[0100] Now, referring to FIG. 2, a second subnet configuration (202) of a subnet (SNA) including an additional node (N6) in addition to the previous nodes (N1, N2, N3, N4, and N5) is shown. This subnet configuration (202) is valid at time points (t2 and t3).

[0101] Now, referring to Fig. 3, column (304) shows the secret key sharing portion of the new set of nodes at time (t2).

[0102] A distributed network is a secret key sharing portion ( share 1,1, share 2,1, share 3,1, share 4,1 and share 5,1 A secret redistribution protocol was performed to redistribute ) to a third set of nodes consisting of an enhanced set of nodes (N1, N2, N3, N4, N5, and N6) in this case.

[0103] The secret redistribution protocol is different from the second set and, in particular, includes a third set of secret key shares containing six key shares instead of the previous five key shares ( share 1,2, share 2,2, share 3,2, share 4,2, share 5,2 and share 6,2 ) created or generated. Again, the third key sharing set is the same static verification key (pk) of the subnet (SNA). A Corresponds to ).

[0104] At a subsequent time point (t3), the subnet (SNA) still has the same set of nodes (N1, N2, N3, N4, N5, and N6). The distributed network has a secret key share ( share 1,2, share 2,2, share 3,2, share 4,2, share 5,2 and share 6,2 A secret redistribution protocol was performed to redistribute ). Therefore, the secret redistribution protocol produced another new set of secret key shares different from the previous set ( share 1,3, share 2,3, share 3,3, share 4,3, share 5,3 and share 6,3 ) created or generated. The new key sharing set again uses the same static verification key (pk) of the subnet (SNA). A Corresponds to ).

[0105] Now, referring to FIG. 2, a third subnet configuration (203) of a subnet (SNA) is shown, which includes an additional node (N7) but removes the previous node (N3). This subnet configuration (203) is valid at time (t4).

[0106] Referring again to FIG. 3, column (306) shows the secret key sharing portion of the new set of nodes at time (t4).

[0107] A distributed network is a secret key sharing portion ( share 1,3, share 2,3, share 3,3, share 4,3, share 5,3 and share 6,3 A secret redistribution protocol was performed to redistribute ) to a new set of nodes (N1, N2, N4, N5, N6 and N7).

[0108] Therefore, the secret redistribution protocol is again different from the previous set and uses the same static verification key (pk) of the subnet (SNA). A Another new secret key sharing set corresponding to ) share 1,4, share 2,4, share 4,4, share 5,4, share 6,4 and share 7,4 created or generated ).

[0109] Distributed key generation protocols and secret redistribution protocols can generally be performed by a dealer set holding a secret key share of the secret key associated with / corresponding to a static public key / static verification key, and a receiver set receiving a (new) secret key share set corresponding to the same static verification key. The dealer set and the receiver set may be the same or different. The dealer set and the receiver set may generally be formed by nodes of a distributed network. According to some embodiments, the dealer set and the receiver set may belong to the same subnet. According to other embodiments, the dealer set and the receiver set may belong to different subnets. According to some embodiments, the dealer set may be provided by a governance subnet acting as a central authority and providing / redistributing a share of the secret key share / secret key share corresponding to each static verification key to other subnets.

[0110] FIG. 4 illustrates in more detail a computation unit (15) running at a node (10) of a network (100). The network (100) is configured to assign each computation unit running in the network (100) to one of a plurality of subnets according to subnet allocation, in this case to one of the subnets (SNA, SNB, SNC, or SND). The subnet allocation of the distributed network (100) creates an allocated subset of the entire set of computation units for each of the subnets (SNA, SNB, SNC, and SND).

[0111] More specifically, FIG. 4 shows the node (10) of the subnet (SNA) of FIG. 1 on the left (401). The subnet allocation of the distributed network (100) allocates a subset of five computing units (15) to the subnet (SNA), in particular computing units (CU). A1 , CU A2 , CU A3 , CU A4 and CU A5 Assigned to a subset of ). Compute Unit (CU A1 , CU A2 , CU A3 , CU A4 and CU A5 An allocated subset of ) is executed at each node (10) of the subnet (SNA). In addition, a compute unit (CU) A1 , CU A2 , CU A3 , CU A4 and CU A5 The allocated subset of ) is each compute unit (CU A1 , CU A2 , CU A3 , CU A4 and CU A5 ) is replicated across the entire subnet (SNA) so that it traverses the same unit state / execution state. This is specifically a compute unit (CU) at each node (10) of the subnet (SNA). A1 , CU A2 , CU A3 , CU A4 and CU A5It can be implemented by performing active replication in the unit state space of ).

[0112] Also, FIG. 4 shows four calculation units (15), in particular a set of calculation units (CU). B1, CU B2, CU B3 and CU B4 A node (10) of the subnet (SNB) of FIG. 1, where ) is executed, is shown on the right (402). Set of computing units (CU) B1, CU B2, CU B3 and CU B4 ) is executed at each node (10) of the subnet (SNB). In addition, a set of compute units (CU) B1, CU B2, CU B3 and CU B4 ) is replicated across the entire subnet (SNB) by performing active replication in the aforementioned unit state space, and compute units (CU) B1, CU B2, CU B3 and CU B4 Each has the same unit state.

[0113] FIG. 5 illustrates a flowchart of the method steps of a method according to an embodiment of the present invention.

[0114] This method performs multiple processing loops (510) in sequential order using an increasing height index (N). N is an increasing integer, i.e., 0, 1, 2, 3 … N.

[0115] The processing loop (510) includes a first loop step (511), a second loop step (512), a third loop step (513), a fourth loop step (514), and a fifth loop step (515).

[0116] In the first loop step (511), a subset of consensus of network nodes, in particular subnet nodes or a subset of subnet nodes, performs a consensus protocol to reach a consensus on, for example, the selection and processing order of the current set of execution messages to be executed by each subnet.

[0117] In the second loop step (512), the nodes of the execution subset, in particular the subnet nodes or the computational units of the subnet nodes, individually execute the selection of execution messages across each subnet in a deterministic and replication manner.

[0118] In the third loop step (513), the subnet node creates a state snapshot and stores it, for example, in the cache memory of each node. The state snapshot may include the unit state / execution state of the compute unit at a single consistent point in time. The state snapshot sets an example of subnet information. Generally, the subnet information may be any information of the subnet that may be provided by the subnet.

[0119] In step (514), the nodes of each subnet are configured to execute a joint signature of a state snapshot or, more generally, subnet information through their shared secret key by an acceptable subset of nodes.

[0120] In step (514), each subnet provides a signed state snapshot to the users of the distributed network.

[0121] FIG. 6 illustrates a flowchart of an additional method step of a method according to an embodiment of the present invention.

[0122] In step (611), a user of the distributed network can read a signed state snapshot, for example, through the user interface (10) illustrated in FIG. 1.

[0123] In step (612), the user can verify the joint signature of the state snapshot through the static verification key of the corresponding subnet.

[0124] FIG. 7 illustrates a schematic diagram of a distributed network (700) according to an embodiment of the present invention.

[0125] The distributed network (700) includes a governance subnet (701, SN0) comprising a plurality of governance nodes (10), and a plurality of additional subnets illustrated exemplarily as a subnet (SNA, 702) and a subnet (SNB, 703). The governance subnet (SN0) includes all static verification keys (pk) of the plurality of subnets (X). X ), that is, in this example, specifically the static verification key (pk) for each subnet (SNA and SNB). A and pk B Stores a list (710) containing ).

[0126] The governance subnet (SN0) additionally possesses a public key signature root verification key (pk0). A node (10) of the subnet (SN0) possesses multiple corresponding secret key shares for the root verification key (pk0).

[0127] Accordingly, the governance subnet (SN0) establishes a single root of trust for the distributed network (700), and nodes of additional subnets can use the root verification key (pk0) to verify information signed by the governance subnet (SN0). In particular, the governance subnet (SNO) uses the subnet's static verification key (pk0). X It can be used by additional subnets of the distributed network to receive one or more of ).

[0128] To this end, and as additionally illustrated in FIG. 8, an exemplary message flow of key exchange between one of the nodes of the user (U) or subnet (SNX), in particular the subnet (SNX), is illustrated.

[0129] In step (801), a user or node of one of the subnets (SNX) may send a verification key request to the governance subnet (SN0) to provide a static verification key for one or more subnets.

[0130] Then, the governance subnet (SN0) can compile a verification key response containing the requested verification key of the subnet in response to the received verification key request. Then, the governance subnet (SN0) can additionally sign the verification key response. More specifically, the verification key response can be signed by a subset of nodes (10) of the governance subset (SN0) as an acceptable subset of the secret key share corresponding to the root verification key (pk0). This is a joint signature (σ) on the entire verification key response or the static verification key(s) of the verification key response. pk0 generated ).

[0131] Then, the governance subnet (SN0) in step (802) requests a static verification key (p) of one or more subnets (SNX). kx A signed verification key response containing ) can be sent to a node of the user (U) or subnet (SNX).

[0132] Signature of the verification key response (σ pk0 ) is the root verification key(p k0 It can be verified by each node or user through ).

[0133] FIGS. 9a and 9b illustrate embodiments of a verification key and a corresponding secret key sharing portion that can be used according to an embodiment of the present invention.

[0134] FIG. 9a illustrates an example of a key set (910) generated by a distributed key generation protocol according to an embodiment of the present invention. The distributed key generation protocol is implemented as a distributed threshold key generation protocol.

[0135] In this example, it is assumed that N nodes participate in a distributed key generation protocol. The nodes are typically nodes in any subnet, or specifically nodes in a governance subnet allocated for the initial generation of the subnet's static verification keys and the corresponding secret key share initial subsets.

[0136] Each of the N nodes is a secret key shared portion (sk) with i = 1,..., N i ) has. N nodes each have a common static verification key (public key) (pk) for their respective subnet (X). X Jointly generate a ), wherein a predefined threshold, such as at least 2 / 3 or 1 / 3 of the nodes, agrees on the static verification key and jointly signs the new static verification key to create a threshold signature (σ pkX ) must be created.

[0137] FIG. 9b illustrates an example of a key set (920) generated by a distributed key generation protocol according to an embodiment of the present invention. The distributed key generation protocol is implemented as a multi-signature protocol.

[0138] In this example, we again assume that N nodes participate in the distributed key generation protocol. For each round of the distributed key generation protocol, each of the N nodes has a secret key share (sk) with i = 1, … , N. i has ).

[0139] According to this embodiment, the secret key sharing portion is an independent secret key (sk i It can be implemented as ). N nodes are common public key / common verification key implemented as a vector( Jointly agree to ). Again, a predefined threshold, such as at least 2 / 3 of the nodes or 1 / 3 of the nodes, along with the corresponding secret key (key shared portion), a new public key / verification key ( It is necessary to provide a signature for ). According to this embodiment, N nodes need to provide a signature for their respective individual secret keys (sk1, sk2, .., sk N Vector validation key with ) For the corresponding elements of ), individual signatures (σ 1pk1, σ 2pk2, 쪋, σ NpkN Executes ). More specifically, each individual signature (σ ipki ) is the corresponding individual public key (pk i) has. Therefore, according to this embodiment, the verification key is an individual public key (pk i )'s vector( = (pk1, pk2, ...pk N Implemented as ) and joint signature also vector( =(σ 1pk1, σ 2pk2, ..., σ NpkN It is implemented as ).

[0140] According to another embodiment, an aggregate signature method may also be used.

[0141] FIG. 10 illustrates the generation of a block in a distributed network according to an embodiment of the present invention. The block may be an input block to be processed by a computational unit of a subset of executions, in particular. The block to be processed by the subset of executions is agreed upon by a subset of the consensus of each node of the subnet.

[0142] In this exemplary embodiment, three input blocks (1001, 1002, and 1003) are illustrated. Block (1001) contains a plurality of transactions, namely transactions (tx1.1, tx1.2) and possibly additional transactions denoted by dots. Block (1002) also contains a plurality of transactions, namely transactions (tx2.1, tx2.2) and possibly additional transactions denoted by dots. Block (1003) also contains a plurality of transactions, namely transactions (tx3.1, tx3.2) and possibly additional transactions denoted by dots. The input blocks (1001, 1002, and 1003) are chained together. More specifically, each block contains the block hash of the previous block. This cryptographically links the current block to the previous block(s).

[0143] According to the embodiment, the transaction may be an execution message to be executed by a node of a subset of execution, in particular.

[0144] According to the embodiment, input blocks (1001, 1002 and 1003) can be generated by a proof-of-stake consensus protocol.

[0145] However, it should be noted that the input blocks generated by the consensus component do not need to be chained together according to the embodiment. Rather, any consensus protocol that reaches some form of consensus among the nodes regarding the selection and / or processing order of received messages may be used according to the embodiment.

[0146] Now, referring to FIG. 11, a more detailed block diagram of a network node (10) of a network (100) of FIG. 1 is illustrated, for example, according to an embodiment of the present invention. The network node (10) sets up a computing node that can perform computing functions and thus can be implemented as a computing system or computer. The network node (10) may be, for example, a server computer. The network node (10) may be configured to perform or participate in a computer-implemented method according to an embodiment of the present invention. The network node (10) may operate using a number of other general-purpose or special-purpose computing system environments or configurations.

[0147] A network node (10) may be described in the general context of computer system executable instructions, such as program modules executed by a computer system. Generally, a program module may include routines, programs, objects, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. The network node (10) is illustrated 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 (1115), system memory (1120), and a bus (1116) that connects various system components, including the system memory (1120), to the processor (1115).

[0148] The bus (1116) represents one or more of any type of bus structure among 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 various bus architectures. As examples, but not limitations, these 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.

[0149] A network node (10) typically includes various computer system readable media. These media may be any available media accessible by the network node (10) and include both volatile and non-volatile media, and both removable and non-removable media.

[0150] System memory (1120) may include computer system readable media in the form of volatile memory, such as random access memory (RAM) (1121) and / or cache memory (1122). Network nodes (1110) may further include other removable / non-removable volatile / non-volatile computer system storage media. As merely an example, a storage system (1123) for reading from and writing to non-removable non-volatile magnetic media (not shown and typically referred to as a “hard drive”) may be provided. 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 a bus (1116) by one or more data media interfaces. As further illustrated and described below, the memory (1120) 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 an embodiment of the present invention.

[0151] As an example, not limited to, an operating system, one or more application programs, other program modules, and program data, as well as a program / utility (1130) having a set (at least one) of program modules (1131), may be stored in memory (1120). Each of the operating system, one or more application programs, other program modules, and program data, or a combination thereof, may include an implementation of a networking environment. The program module (1131) generally performs the functions and / or methodologies of embodiments of the invention as described herein. The program module (1131) may perform one or more steps of a computer-implemented method for performing inter-subnet communication, including a consensus protocol in a distributed network, for example, one or more steps of a method as described above.

[0152] The network node (10) may also communicate with one or more external devices (1117), such as a keyboard or pointing device, and a display (1118). This communication may occur through an input / output (I / O) interface (1119). Additionally, the network node (10) may communicate with one or more networks (1140), such as a local area network (LAN), a wide area network (WAN), and / or a public network (e.g., the Internet), through a network adapter (1141). According to an embodiment, the network (1140) may be a distributed network, specifically comprising a plurality of network nodes (10), such as the network (100) shown in FIG. 1. As illustrated, the network adapter (1141) communicates with other components of the network node (10) through a bus (1116). It should be understood that, although not shown, other hardware and / or software components may be used with the network node (10).

[0153] FIG. 12 illustrates a more detailed example of a calculation unit (1200) according to an embodiment of the present invention.

[0154] The calculation unit (1200) includes a user or application state (1201) and a system state (1202).

[0155] The user state (1201) consists of a main Web Assembly (WASM) module that implements the functions of the compute unit, its dependent modules, and instances of each module. A WASM module instance consists of memory, global variables, and tables.

[0156] The system state (1202) cannot be freely modified by the code of the compute unit. It includes metadata, other states maintained by the system on behalf of the compute unit, in particular the compiled format of the WASM module, and context and callbacks for pending messages.

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

[0158] A computer-readable storage medium may be a type of device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing, but is not limited thereto. A computer-readable storage medium as used herein shall not be interpreted as being a transient signal in itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., optical pulses passing through fiber optic cables), or electrical signals transmitted through wires.

[0159] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to their respective computing / processing device, or to an external computer or external storage device via a network, e.g., the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. In each computing / processing device, a network adapter card or network interface receives computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium within their respective computing / processing device.

[0160] Computer-readable program instructions for performing the operation of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and ordinary procedural programming languages ​​such as the "C" programming language or similar programming languages.

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

[0162] Computer-readable program instructions according to an embodiment of the present invention may be provided to a processor of a general-purpose computer, a special-purpose computer, or another programmable data processing device to create a machine, so that instructions executed through the processor of the computer or other programmable data processing device may create means for implementing a function / operation specified in blocks or blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium capable of instructing a computer, a programmable data processing device and / or other device to function in a specific manner, such that the computer-readable storage medium storing the instructions may comprise a manufactured article containing instructions that implement an aspect of a function / operation specified in blocks or blocks of a flowchart and / or block diagram.

[0163] Computer-readable program instructions can also be loaded into a computer, another programmable data processing device, or another device to cause a series of operational steps to be performed on that computer, other programmable device, or other device, thereby creating a computer-implemented process in which instructions executed on the computer, other programmable device, or other device implement the functions / actions specified in the blocks or blocks of a flowchart and / or block diagram.

[0164] In the drawings, flowcharts and block diagrams illustrate the architecture, functionality, and operation of possible implementations of networks, systems, methods, and computer program products according to various embodiments of the present invention. In this regard, in a flowchart or block diagram, each block may represent a module, segment, or part of an instruction containing one or more executable instructions for implementing a specified logical function(s). In some alternative implementations, the functions mentioned in the blocks may occur out of the order mentioned in the drawings. For example, two blocks depicted consecutively may be executed substantially simultaneously, or blocks may sometimes be executed in reverse order depending on the functionality involved.

[0165] Although preferred embodiments of the present invention have been shown and described, it should be clearly understood that the present invention is not limited thereto and may be implemented and practiced in various ways within the scope of the subsequent claims.

Claims

Claim 1 A distributed network comprising a plurality of subnets, wherein each of the plurality of subnets comprises a changeable set of nodes, and the network is configured to generate, for each of the plurality of subnets, an individual static verification key of a public key signature method and a first set of corresponding secret key shares for a first set of nodes of each subnet by means of a distributed key generation protocol, and for each of the plurality of subnets, to redistribute the secret key shares of each first set of secret key shares to a second set of nodes of each subnet by means of a secret redistribution protocol, thereby generating a second set of secret key shares corresponding to the same static verification key of each subnet, wherein a node of each subnet is configured to execute an allocated set of computational units, and each of the computational units is a piece of software that is executed at a node of the network and has its own unit state, and the computational units of the subnets are configured to execute computations in a deterministic and replicated manner across the subnets by performing active replication in the space of an allocated subset of the computational units at each node of the subnets, and the nodes of the plurality of subnets are A distributed network configured to execute a joint signature on subnet information by an acceptable subset of nodes through a secret key shared portion of an acceptable subset of nodes, and to provide the signed subnet information to users and / or other receiving subnets of the distributed network. Claim 2 A distributed network according to claim 1, wherein each node of a subset of the first set of nodes holds one secret key share of the first set of secret key shares, and each node of a subset of the second set of nodes holds one secret key share of the second set of secret key shares. Claim 3 A distributed network according to claim 1 or 2, wherein the network is further configured to redistribute the secret key share of the second secret key share set to a third node set of each subnet by means of the secret redistribution protocol for each of the plurality of subnets to generate a third secret key share set corresponding to the same static verification key of each subnet. Claim 4 In paragraph 3, the first node set is identical to the second node set, and / or the second node set is identical to the third node set, a distributed network. Claim 5 In paragraph 3, the first node set is different from the second node set, and / or the second node set is different from the third node set in a distributed network. Claim 6 A distributed network according to claim 1 or 2, wherein the distributed network is configured to periodically perform the secret redistribution protocol for each subnet at predefined intervals. Claim 7 In claim 1 or 2, the distributed key generation protocol is a distributed threshold key generation protocol, a distributed network. Claim 8 In claim 1 or 2, the secret redistribution protocol is a critical key redistribution protocol, a distributed network. Claim 9 A distributed network according to claim 1, wherein the user of the distributed network and / or the other receiving subnet is configured to verify the joint signature of the subnet information through the static verification key of the corresponding subnet. Claim 10 A distributed network according to claim 1 or 2, wherein the distributed network comprises a governance subnet including a plurality of constituent nodes, and the governance subnet stores static verification keys of the plurality of subnets, holds a root verification key of a public key signature method and a plurality of corresponding secret key shares, receives a verification key request to provide the static verification keys of one or more subnets, and in response to the verification key request, provides a verification key response including the static verification keys of one or more subnets, and is configured to generate a joint signature for the verification key response by a subset of nodes of the governance subnet using an acceptable subset of the secret key shares corresponding to the root verification key. Claim 11 A computer implementation method for managing a verification key in a distributed network comprising a plurality of subnets, wherein each of the plurality of subnets comprises a plurality of nodes, and the method comprises the steps of: generating, by means of a distributed key generation protocol for each of the plurality of subnets, an individual static verification key of a public key signature method and a first corresponding set of secret key shares for a first set of nodes of each subnet; redistributing, by means of a secret redistribution protocol for each of the plurality of subnets, the secret key shares of each first set of secret key shares to a second set of nodes of each subnet to generate a second set of secret key shares corresponding to the same static verification key of each subnet; executing an allocated set of computational units by a node of each subnet—each of which is a piece of software that is executed at a node of the network and has its own unit state—and executing computations in a deterministic and replicated manner across the subnets by performing active replication in the space of an allocated subset of computational units at each node of the subnets by the computational units of the subnets, and by an acceptable subset of nodes, A computer-implemented method comprising the steps of executing a joint signature for subnet information through a secret key sharing portion of an acceptable subset of the nodes, and providing the signed subnet information to a user and / or another receiving subnet of the distributed network. Claim 12 A node of a distributed network according to paragraph 1 or 2. Claim 13 A computer program stored on a computer-readable storage medium for operating a distributed network, wherein the distributed network comprises a plurality of subnets, each of the plurality of subnets comprises a set of nodes, and the computer program has program instructions, wherein the program instructions are executable by one or more of the plurality of nodes so as to cause one or more of the plurality of nodes to perform a method, the method comprising: generating, by means of a distributed key generation protocol for each of the plurality of subnets, an individual static verification key of a public key signature method and a first corresponding set of secret key shares for a first set of nodes of each subnet; redistributing the secret key shares of each first set of secret key shares to a second set of nodes of each subnet by means of a secret redistribution protocol for each of the plurality of subnets to generate a second set of secret key shares corresponding to the same static verification key of each subnet; and executing an allocated set of computational units by a node of each subnet—each of which is a piece of software that is executed at a node of the network and has its own unit state—and, by means of the computational units of the subnet, at each node of the subnet A computer program comprising the steps of: executing computation in a deterministic and replicated manner across said subnet by performing active replication in the space of an allocated subset of computation units; executing a joint signature for subnet information by an acceptable subset of said nodes through a secret key sharing portion of an acceptable subset of said nodes; and providing said signed subnet information to users of said distributed network and / or other receiving subnets. Claim 14 delete Claim 15 delete

Images