Key generation in distributed networks

Abstract

Some embodiments of the present invention relate to a computer-implemented method for generating verification keys for a public key signature scheme in a distributed network. The method includes a step in which a subset of nodes in a first subnetwork executes a first distributed key generation protocol, which jointly generates a verification key for the first subnetwork and a plurality of shared secret keys corresponding to the nodes in the first subnetwork. The method includes a step in which a subset of the nodes in the first subnetwork executes a second distributed key generation protocol for a second subnetwork, which jointly generates a verification key for the second subnetwork and a plurality of shared secret keys corresponding to the nodes in the second subnetwork. A further step includes a step in which the subset of nodes in the first subnetwork signs the verification key for the second subnetwork with an allowable subset of the shared secret keys of the nodes in the first subnetwork, thereby generating a joint signature on the verification key for the second subnetwork. Further aspects relate to a distributed network, a plurality of nodes in the distributed network, and a corresponding computer program product.

Description

[Technical Field]

[0001] The present invention relates to a computer implementation method for generating verification keys for a public key signing scheme in a distributed network.

[0002] Further embodiments relate to distributed networks, multiple nodes of a distributed network, corresponding computer program products, and software architectures encoded on non-temporary media. [Background technology]

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

[0004] One example of a distributed network is a blockchain network. A blockchain network is a consensus-based electronic ledger consisting of multiple blocks. Each block consists of multiple transactions and other information. Furthermore, each block is chained by containing the hash of the previous block, so that all transactions written to the blockchain are created as a permanently immutable record. Transactions can, for example, invoke small programs known as smart contracts. For a transaction to be written to the blockchain, "verification" and consensus by the network are essential. In other words, network nodes must reach a consensus on the block to be written to the blockchain. Such consensus can be achieved with various consensus protocols.

[0005] In one form of blockchain network, the consensus protocol is achieved using a proof-of-work algorithm. Generally, in a proof-of-work consensus protocol, some work is required from the parties participating in the consensus protocol, which usually corresponds to computer processing time. In proof-of-work based cryptocurrency systems such as Bitcoin, transactions are verified and new blocks are created by solving a computationally intensive puzzle.

[0006] Other forms of consensus protocols are based on proof-of-stake algorithms. Such proof-of-stake protocols have the advantage of not requiring time-consuming and energy-intensive computations. In a proof-of-stake based blockchain network, for example, the creator of the next block is elected through a combination of random selections, as well as through the stakes of each node in the network. Consensus protocols used in blockchain networks can be designed to reach the finality of transactions contained in a block quickly by applying a "Byzantine fault-tolerant" (BFT) consensus protocol. "Synchronous" BFT protocols rely on the assumption of network synchronous state for security, while "asynchronous" BFT protocols do not. Asynchronous BFT protocols are typically acceptable if the corruption of participating nodes is less than 1 / 3.

[0007] Apart from cryptocurrencies, decentralized networks can be used for a variety of other applications. In particular, they can be used to provide decentralized and distributed computing power and services. For this purpose, these decentralized networks can use state machine replication protocols to store state across multiple nodes, ensuring that multiple applications run reliably even in the event of multiple crashed nodes and various adversarial attacks.

[0008] One challenge for such a distributed network that provides distributed computing services is providing a mechanism for generating and distributing verification keys for public-key signing schemes. Such verification keys are, for example, public keys that can be used to verify signatures in a public-key signing scheme.

[0009] Another challenge of such distributed networks lies in providing a mechanism that allows (no longer) modern nodes to connect to or reconnect to the distributed network. Such nodes might be, for example, nodes that have crashed and want to resume participation in the distributed network, or nodes that want to join for the first time. [Prior art documents] [Non-patent literature]

[0010] [Non-Patent Document 1] Paul Feldman. A practical scheme for non-interactive verifiable secret sharing. In 28th Annual Symposium on Foundations of Computer Science, pages 427-437, Los Angeles, California, October 12-14, 1987. IEEE Computer Society Press. [Non-Patent Document 2] 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.

Outdoor Tools3

Outdoor Tools 4

Direct Environment 5

Outdoor Configuration 6

[0011] One object of one aspect of the present invention is to provide a novel and advantageous method for generating and distributing verification keys in a distributed network.

[0012] A further object of a further embodiment of the present invention is to provide a method for enabling the connection or reconnection of nodes of a non-modern distributed network to the distributed network, in particular in an efficient and secure manner.

[0013] In an embodiment of a first aspect of the present invention, a computer implementation method for generating a verification key for a public key signing scheme in a distributed network is provided. The distributed network comprises a plurality of nodes, which are subdivided into two or more subnetworks, and each of the plurality of nodes is configured to run one or more computing units. The computing units are configured to perform computations across the subnetworks of the plurality of nodes in a deterministic and replicable manner, thereby traversing a set of execution states. The method comprises the step of having a subset of nodes in a first subnetwork execute a first distributed key generation protocol, which is configured to jointly generate a verification key for the first subnetwork and a plurality of shared secret keys corresponding to the subset of nodes in the first subnetwork. For a second subnetwork, the method further comprises the step of having a subset of nodes in the first subnetwork execute a second distributed key generation protocol, which is configured to jointly generate a verification key for the second subnetwork and a plurality of shared secret keys corresponding to the subset of nodes in the second subnetwork. A further step involves a subset of nodes in the first subnetwork signing a verification key for the second subnetwork with an acceptable subset of the shared secret keys of the nodes in the first subnetwork, thereby generating a joint signature on the verification key for the second subnetwork.

[0014] In such a concretized method, multiple nodes are subdivided into subsets called subnetworks. All nodes within a single subnetwork traverse the same set of execution states. One particular subnetwork, referred to as the first subnetwork, is configured to generate a verification key for its own subnetwork, as well as at least one other subnetwork, referred to as the second subnetwork. In one embodiment, the first subnetwork is configured to generate verification keys for multiple second subnetworks, or more generally, for all subnetworks in a distributed network. The verification keys for subnetworks remain constant over time and can therefore also be referred to as static verification keys.

[0015] In some embodiments, the first subnetwork includes node assignment and key registry to the subnetwork and can function as a governing body for controlling and modifying protocol configurations required globally. In some embodiments, the first subnetwork, more specifically a subset of the nodes of the first subnetwork, executes a first distributed key generation protocol. Thereafter, the first subnetwork generates its own verification key, which is shown as a first verification key, and a shared secret key for the subnetwork, in particular for all nodes of the first subnetwork. When a second subnetwork is created as a new subnetwork, the first subnetwork, more specifically a subset of the nodes of the first subnetwork, executes a second distributed key generation protocol for this new subnetwork, thereby generating a second verification key for the new second subnetwork, as well as multiple shared secret keys for the subset, in particular for all nodes of the second subnetwork. The method further comprises the step of the subset of nodes of the first subnetwork using their shared secret keys to sign the public verification key of the (new) second subnetwork, thereby generating a joint signature that serves as a certificate for the verification key of the second subnetwork issued by the first subnetwork. This ensures that the validity of the verification keys of the second subnetwork(s) can be recognized. More specifically, each new verification key in the second subnetwork is linked to a verification key belonging to the first subnetwork. Joint signing is performed using an acceptable subset of the shared secret key. The acceptable subset can generally be defined as an access structure and may depend on the security requirements of each distributed network. In some embodiments, joint signing may be threshold signing, and the acceptable subset may be defined as the minimum number of shared secret keys. Such a distributed network easily, efficiently, and securely distributes the verification keys of its subnetworks. All nodes in the distributed network can use the verification keys of one or more second subnetworks to verify whether the information in their second subnetwork is signed. This also applies to the first subnetwork, which functions as the administrative subnetwork.Furthermore, in such a subnetwork configuration, the first subnetwork controls the creation of new subnetworks, thus preventing the unauthorized creation of new subnetworks. A further advantage is that the public verification key of the first subnetwork acts as a single root of trust, enabling the verification of all verification keys in the second subnetwork.

[0016] In one embodiment, the method further comprises the step of the second subnetwork signing a state information package of the second subnetwork, which has an acceptable subset of shared secret keys corresponding to the verification key of the second subnetwork, thereby generating a joint signature on the state information package of the second subnetwork, which includes the running state of the second subnetwork or a hash of the running state.

[0017] Such a concrete method provides nodes that are no longer up-to-date with a state information package that enables efficient and secure reconnection to the network. The state information package contains the most recent running state or a hash of the most recent running state. The joint signature on the state information package is verifiable using the respective second verification key.

[0018] Each of the multiple nodes runs one or more computing units. More specifically, each node within the same subnetwork runs the same set of computing units, which may include one or more computing units. A computing unit can be defined as part of software that runs on the network and has its own units or execution states. The computing units of a node perform computations across the subnetwork in a deterministically replicating manner, thereby traversing a set of execution states. In other words, the computing units of nodes within a subnetwork deterministically perform the same computations and traverse the same execution states, but different nodes within the subnetwork may be at different positions in the chain of execution states. In some embodiments, a computing unit can be defined as a deterministic program. A shared secret key for the subnetwork is jointly held by a subset of the subnetwork's nodes. The subset may include all the nodes in a small subnetwork, or only some of the nodes in a large subnetwork. The subset may change over time, and the number of nodes in the subset may adapt dynamically over time. The subnetwork verification keys are stored and can be provided to all nodes in the system through a registry in the first subnetwork, which can function as a management committee. For each verification key, there are multiple corresponding shared secret keys. Each of these shared secret keys is known only to the nodes corresponding to a subset, and each shared key is kept secret by each node in the subset. The term shared secret key encompasses secret keys in several embodiments. Verification keys may be represented as public keys, and secret keys may be represented as shared signing keys or signing keys. Public key signing schemes according to embodiments of the present invention may comprise keys for public key signing and encryption schemes such as RSA, or keys for public key signing schemes such as Schnorr or DSA. The state information package comprises the network's most recent running state or a hash of the most recent running state. This allows catch-up nodes to synchronize their "old" state with the latest state provided by the state information package when they become up-to-date again.Therefore, in such a state information package, catch-up nodes can synchronize their old state to the current state of the network in some kind of fast-forward mode. In embodiments where the state information package contains only hashes of the running state, positive verification of the hash has the advantage that each node can first verify the hash and then download only the completed running state. This avoids the unnecessary download of the complete state. Positive verification of the hash allows the (completed) running state itself to be fetched separately. For ease of illustration and explanation, the term running state below may include or indicate the hash of the running state as appropriate. In one embodiment, the method further comprises the step of the first subnetwork signing a state information package of the first subnetwork having an acceptable subset of the private key share corresponding to the verification key of the first subnetwork, thereby generating a joint signature on the state information package of the first subnetwork. The state information package contains the running state of the first subnetwork or hashes of the running state.

[0019] In such a concrete method, a state information package is provided to multiple nodes in the first subnetwork that are no longer up-to-date, enabling them to reconnect to the first subnetwork in an efficient and secure manner. Furthermore, this may allow multiple nodes in the second subnetwork to verify the state information package of the first subnetwork. The joint signature on the state information package can be verified using their respective first verification keys.

[0020] In one embodiment, the distributed network comprises multiple second subnetworks. In a further embodiment, the state information package of the first subnetwork comprises a list of second subnetworks, node verification keys corresponding to multiple second subnetworks, and multiple nodes of the second subnetworks. This makes it possible to find the subnetwork to which a node that has more or less completely lost its state belongs. In particular, this makes it possible for a node whose second subnetwork it belongs to is unknown to find it. More specifically, a node can first verify the state information package of the first subnetwork using the first verification key. Then, from the state information package verified by the first subnetwork, it can identify the second subnetwork to which it belongs, request another state information package from this subnetwork, and reconnect to the respective second subnetwork.

[0021] In one embodiment, the step of executing a second distributed key generation protocol for a second subnetwork comprises the step of a node in the first subnetwork generating a second verification key and a first shared secret key set corresponding to the second verification key for the node in the first subnetwork, wherein each node in the first subnetwork holds one of the shared secret keys from the first shared secret key set. Furthermore, the method comprises the further step of a secret redistribution protocol redistributing the shared secret keys of the first shared secret key set to multiple nodes in the second subnetwork, thereby creating a second shared secret key set corresponding to the second verification key of the second subnetwork.

[0022] Therefore, the second distributed key generation protocol can be implemented in two stages. In other words, it can encompass two stages. First, a node or subset of nodes in the first subnetwork generates a verification key and a corresponding set of shared secret keys for the second subnetwork. This first set of shared secret keys is held by a subset of nodes in the first subnetwork. Then, the multiple nodes in the first subnetwork redistribute these shared keys to the multiple nodes in the second subnetwork. Such redistribution of shares can be called re-sharing of shares. Re-sharing of shares can be implemented, in particular, by sharing the first set of shares with the multiple nodes in the second subnetwork.

[0023] More specifically, in one embodiment, redistribution may comprise the step of a subset of nodes in a first subnetwork generating a shared secret key of a first shared secret key set corresponding to a second verification key. The redistribution may then comprise the step of communicating, in other words, redistributing, the shared secret key to a plurality of nodes in a second subnetwork. Finally, the plurality of nodes in the second subnetwork may perform the step of computing individual shared secret keys from the shared secret key. In other words, the plurality of nodes in the second subnetwork reconstruct the second shared secret key set from the received shares of the first shared set. In some embodiments of the present invention, the plurality of nodes in the first subnetwork act as dealers in the second distributed key generation protocol, and the plurality of nodes in the second subnetwork act as receivers of the shared secret key.

[0024] In one embodiment, the method further includes the step of publishing a newly generated second verification key for a new second subnetwork, along with the joint signature of a first subnetwork acting as a management committee. This provides a certificate for the verification key of the second subnetwork. Such a certificate enables the verification of the new second verification key. The publication of the new verification key can be carried out in a variety of ways. Each method may depend, in particular, on the communications and communication channels of the respective distributed network. In this regard, the term publication generally refers to any kind of mechanism that makes the new second verification key available to multiple nodes that wish to connect to or reconnect to the distributed network.

[0025] In one embodiment, the method further comprises the step of a node, in particular a catch-up node wishing to connect to or reconnect to one of the second subnetworks, verifying a state information package of the second subnetwork. The verification of the state information package comprises two substeps. The first substep includes verifying the verification key of the second subnetwork corresponding to the joint signature of the state information package by verifying a certificate with the verification key of the first subnetwork. This allows the corresponding node to obtain a trusted verification key of the second subnetwork. In a further substep, the node may verify the joint signature on the state information package with the verified verification key of the second subnetwork corresponding to the joint signature of the state information package. As a result, the node obtains a state information package containing a trusted, most recent running state. In one embodiment, the method includes the step of a distributed network generating a blockchain of blocks. Each block corresponds to a running state in a chain of running states.

[0026] Therefore, the methods of the embodiments of the present invention can be advantageously applied to distributed networks utilizing blockchains of multiple blocks. Multiple blocks may, in particular, be multiple input blocks processed by the computing units of a node. Multiple input blocks may, in particular, include execution messages executed by the computing units of multiple nodes. The execution state of a node corresponds to the execution result of the execution message of the corresponding block. In one embodiment, the state information package includes block verification information that verifies the validity of multiple subsequent blocks of the blockchain, in particular multiple subsequent blocks. The state information package may construct a kind of snapshot of the execution state of a chain of multiple execution states at a given point in time and be provided only for every i-th block, for example, every 500th block. For example, if a catch-up node wishes to reconnect to the network during a period when the network is already in execution state 600, the catch-up node will only receive the state information package for execution state 500. Therefore, in order to fully catch up to execution state 600, each node must execute and verify itself up to the subsequent blocks 501 through 600 with the help of the block verification information. Block verification information may include, in particular, a set of verification keys required to verify the validity of multiple blocks in a blockchain, especially the execution state of a state information package.

[0027] In one embodiment, the state information package includes key generation information of a distributed key generation protocol used to generate the verification key for the second subnetwork.

[0028] Such key generation information may, in particular, include a set of information required for a catch-up node to resume participation in a distributed key generation protocol. Each piece of information required for resuming participation in distributed key generation depends on the respective distributed key generation protocol. In one embodiment, the key generation information may include a completion document of the distributed key generation protocol. In another embodiment, it may include a summary of the distributed key generation protocol. This summary enables the catch-up node to rejoin the distributed key generation protocol and co-signature generation by allowing the extraction of the catch-up node's shared secret key. Such provision of key generation information further facilitates the efficient resumption of multiple nodes. More specifically, it facilitates the resuming node not only for updating its execution state but also for rejoining signature execution.

[0029] In one embodiment, the status information package includes a completion certificate.

[0030] This allows catch-up nodes to verify the co-signature of catch-up packages in an efficient manner.

[0031] In general terms, in some embodiments of the present invention, a state information package comprises a set of information that enables the synchronization of the execution state of catch-up nodes wishing to connect to or reconnect to a distributed network with their current execution state. The specific information in each set may depend on the technical implementation of the respective network.

[0032] In one embodiment, the method comprises the further step of adding a state information package to one of the blocks of a predetermined period, in particular to the first block of the predetermined period.

[0033] This facilitates efficient implementation of this method, as well as easy access to state information packages for catch-up nodes.

[0034] In one embodiment, the state information package provides the running state as a Merkle-tree structure, particularly as a hash root of the Merkle-tree structure. This enables memory-efficient storage. In one embodiment, the method further comprises the steps of: a catch-up node wishing to connect to or reconnect to a distributed network from the latest node requests the leaf hash of the Merkle-tree structure; the catch-up node compares the leaf hash of its own state with the leaf hash of the latest node; and the catch-up node requests from the latest node only the state information corresponding to leaves having different leaf hashes.

[0035] This further facilitates rapid and efficient state synchronization.

[0036] In one embodiment, the distributed key generation protocol is a threshold distributed key generation protocol. In other embodiments, the distributed key generation protocol is a multi-signature protocol or an aggregate signature protocol. Different distributed key generation protocols have in common that two or more nodes are required to generate a valid key.

[0037] Such embodiments further facilitate node catch-up. Typically, a node only accepts communication from known nodes. Such known nodes include particularly trusted nodes. These may be, for example, multiple nodes in the same subnetwork, and nodes assigned to each node that communicates according to the distributed network's communication scheme or protocol. Expanding the set of nodes that a catch-up node can communicate with can help facilitate a faster catch-up for catch-up nodes.

[0038] In another embodiment of the present invention, a distributed network is provided.

[0039] In one embodiment of another aspect of the present invention, a plurality of nodes of a distributed network are provided. In one embodiment of another aspect of the present invention, a computer program product for operating the distributed network is provided. The computer program product comprises a computer-readable storage medium containing a plurality of program instructions, the plurality of program instructions enabling an embodiment of the method of the present invention to be executed on one or more of the plurality of nodes.

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

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

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

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

[0044] [Figure 1] Figure 1 is an example diagram of a distributed network according to one embodiment of the present invention. [Figure 2] Figure 2 is a detailed diagram of the computing units running on an exemplary node in the network. [Figure 3] Figure 3 shows the generation of multiple blocks in a distributed network according to several embodiments of the present invention. [Figure 4]Figure 4 shows the block-by-block processing of multiple input blocks processed by the execution subset nodes. [Figure 5] Figure 5 is a state diagram of the node corresponding to Figure 4. [Figure 6] Figure 6 shows the subnet verification key certified by the signature of the managed subnet according to one embodiment of the present invention. [Figure 7a] Figure 7a is a timing diagram of the generation of state information packages according to several embodiments of the present invention. [Figure 7b] Figure 7b is a block diagram of the state information package. [Figure 8a] Figure 8a is a high-level flowchart of the method steps of a computer implementation method for generating a verification key for a public key signing scheme, according to several embodiments of the present invention. [Figure 8b] Figure 8b is a more detailed flowchart of some steps of the method shown in Figure 8a. [Figure 8c] Figure 8c shows the corresponding key material produced by the method steps shown in Figures 8a and 8b. [Figure 9] Figure 9 is a flowchart of the method steps showing the procedure for updating the execution status of a catch-up node. [Figure 10] Figure 10 is a flowchart illustrating some embodiments of the method of the present invention. [Figure 11] Figure 11 shows an example of execution status information. [Figure 12] Figure 12 shows the synchronization between the newest node and the older catch-up node. [Figure 13a] Figure 13a shows an embodiment of a key generated by a threshold-distributed key generation protocol. [Figure 13b] Figure 13b shows one embodiment of a key generated by a multi-signature protocol. [Figure 14] Figure 14 is a more detailed diagram of the computing unit according to one embodiment of the present invention. [Figure 15]Figure 15 shows an exemplary embodiment of a node according to one embodiment of the present invention. [Modes for carrying out the invention]

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

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

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

[0048] A verification key is a bit sequence of a public-key signature scheme intended to be widely publicized. Verification keys are also called public keys and can be used, for example, to verify the digital signature of a public-key signature scheme.

[0049] Public key signing schemes of some embodiments of the present invention may include, for example, keys for a public key signing scheme and encryption scheme such as RSA, or keys for a public key signing scheme such as Schnorr signature or DSA.

[0050] The private key (sk) is a bit sequence related to the public key, especially the verification key, which enables cryptographic operations, particularly the digital signing of messages.

[0051] Distributed Key Generation (DKG) is a protocol that enables a set of dealers (holders of confidential information) to generate a public key, particularly a verification key, and provide a shared secret key corresponding to a set of recipients.

[0052] A secret redistribution protocol, also known as a secret resharing protocol, is a protocol for updating a shared secret key of a secret key. In some embodiments, the protocol may provide a new or updated shared secret key to the previous holder of that shared secret key. In other embodiments, the protocol may provide a new or updated shared secret key to a new, in particular, different set of recipients.

[0053] Verifiable Secret Sharing (VSS) is a protocol that enables a single dealer to generate a random secret s, a secret sharing threshold s1, ..., sn for a set of recipients, and evidence that each recipient can use to verify the legitimacy of their shared secret si.

[0054] In some embodiments, the Feldman protocol [Fel87], the joint Feldman protocol [Ped91], and the GJKR protocol [GJKR99] may be used as distributed key generation protocols. These protocols are disclosed, for example, in Non-Patent Document 1 (the Feldman protocol [Fel87]), Non-Patent Document 2 (joint Feldman protocol [Ped91]), and Non-Patent Document 3 (the GJKR protocol [GJKR99]), and their corresponding disclosures are incorporated herein by reference.

[0055] In some embodiments of the present invention, the protocols described in Non-Patent Documents 4, 5, and 5 may also be used as secret redistribution protocols.

[0056] Figure 1 shows an exemplary block diagram of a distributed network 100 according to one embodiment of the present invention. The distributed network 100 comprises a plurality of nodes 10, which may be referred to as network nodes 10. The plurality of nodes 10 are distributed across a plurality of subnetworks 11. Hereinafter, the plurality of subnetworks 11 will also be referred to as subnets 11. In the example of Figure 1, four subnets 11 are configured, represented as SN0, SNA, SNB, and SNC. Subnet 11 forms a first subnet, which may be referred to as the management subnet. Subnets SNA, SNB, and SNC may generally be referred to as second subnets. Each of the plurality of subnets 11 is configured to run a set of computing units on each node 10 of the respective subnet 11. In some embodiments, the computing units should be understood as including, or as part of, their own unit state, in particular, as part of the software. The unit state may also be referred to as the running state. Network 100 includes communication links 12 for intra-subnet communication within each subnet 11, which in particular facilitate the communication of inter-unit messages within a subnet between computing units assigned to the same subnet. Furthermore, network 100 includes communication links 13 for inter-subnet communication between different subnets within subnet 11, which in particular facilitate the communication of inter-unit messages between computing units assigned to different subnets. Thus, communication links 12 may also be described as intra-subnet or peer-to-peer (P2P) communication links, and communication links 13 may also be described as inter-subnet or subnet-to-subnet (SN2SN) communication links.

[0057] In some embodiments, the distributed network may be configured to exchange inter-subnet messages 16 between subnet SNAs, SNBs, and SNCs, in particular, through a messaging protocol.

[0058] In some embodiments, the unit state or execution state may be understood to include all data or information used by the compute unit, in particular data that the compute unit stores in variables, as well as data that the compute unit retrieves from remote calls. The unit state or execution state may, in particular, represent storage locations at each memory location of each node. In some embodiments, the contents of these storage locations are referred to as the unit state at any point in time while the compute unit is running. The compute unit may, in particular, be embodied as a stateful compute unit; that is, in some embodiments, the compute unit is designed to remember previous events or user interactions.

[0059] In some embodiments of the present invention, a plurality of subnets 11 are configured to replicate a set of computing units across each subnet 11. More specifically, a plurality of subnets 11 are configured to replicate the unit state or execution state of the computing units across each subnet 11.

[0060] Each subnet 11 holds its own verification key for the public key signing scheme, i.e., separate verification keys. In this example, subnet SN0 holds verification key pk0, and subnet SNA holds verification key pk A The subnet SNB holds the verification key pk B The subnet SNC holds the verification key pk C It holds the verification key, which is generally referred to as pk below. X It may be called this. Here, X indicates the corresponding subnet. In some embodiments, the verification key pk X It is constant, or in other words, fixed throughout the entire validity period of each subnet 11. Therefore, the verification key pk X This can also be represented as a static verification key or a constant verification key.

[0061] In some embodiments of this invention, the static verification key pk XIt is generated by the distributed key generation protocol executed by the first subnet SN0. More specifically, the first subnet SN0 has its own verification key pk0, as well as the verification keys pk A 、pk B 、and pk C of the subnets SNA, SNB, and SNC. Therefore, the first subnet SN0 forms the management subnet. Next, referring to FIGS. 8a, 8b, and 8c, the generation of multiple verification keys by the first subnet SN0 will be described in more detail. The method steps can be executed, for example, by the distributed network 100 shown in FIG. 1, and are shown with reference to the subnet structure of FIG. 1. FIG. 8a shows a high-level flowchart of the method steps of a computer-implemented method for generating a verification key of a public key signature scheme in some embodiments of the present invention. FIG. 8b shows a more detailed flowchart of some steps of the method of FIG. 8a, and FIG. 8c shows the corresponding key materials generated by each method step.

[0062] In the following exemplary and simplified description, the subnet SN0 operates as the first subnet, or rather, as the management subnet, and includes three nodes N1, N2, and N3. Assume that the subnet SNA operates as an exemplary second subnet and includes three nodes N4, N5, and N6 as shown in FIG. 8c.

[0063] In step 810, a subset of multiple nodes 10 of the first subnet SN0, for example, a subset including all nodes N1, N2, and N3, executes the first distributed key generation protocol. More specifically, the multiple nodes of the subset use, as the first verification key, the verification key pk0 for the first subnet SN0 and multiple shared secret keys share 0,N1 、share 0,N2 、and share 0,N3, jointly generate. The execution result of the first DKG protocol is shown in column 820. In step 830, node 10 of the first subnetwork SN0 executes the second distributed key generation protocol for the second subnetwork SNA. As a result, as shown in column 840, nodes N4, N5, and N6 generate the verification key pk A Multiple shared secret keys corresponding to A,N4 share A,N5 , and share A,N6 The following is held. Step 830 is illustrated in more detail in Figure 8b. In step 831, multiple nodes of the subset of the first subnetwork, namely multiple nodes N1, N2, and N3, as the second verification key, the verification key pk for the second subnetwork SNA. A and multiple shared secret keys corresponding to nodes N1, N2, and N3 A,N1 share A,N2 , and share A,N3 They jointly generate the verification key pk. In other words, first, multiple nodes N1, N2, and N3 of the first subnetwork SN0 generate the verification key pk. A Multiple shared secret keys corresponding to A,N1 share A,N2 , and share A,N3 The results of this step are shown in column 832. Next, in step 833, multiple nodes N1, N2, and N3 of the first subnetwork SN0 execute the secret redistribution protocol and share their shared secret key with multiple nodes N4, N5, and N6 of the second subnetwork SNA. A,N1 share A,N2 , and share A,N3 Redistribute, or in other words, reshare. This is the second verification key pk of the second subnetwork SNA. A The corresponding second shared secret key set share A,N4 share A,N5 , and share A,N6 This generates the second shared secret key set. The result of this step is shown in column 834. This means that each node of the multiple nodes N4, N5, and N6 of the second node set has the second shared secret key set shareA,N4 share A,N5 , and share A,N6 One of the shared secret keys is held. The secret redistribution protocol can be implemented as follows: Multiple nodes N1, N2, and N3 of the first subnetwork SN0 hold their multiple shared secret keys. A,N1 share A,N2 , and share A,N3 Multiple shares are generated from this, and these multiple shares are distributed to multiple nodes N4, N5, and N6. Then, the multiple nodes N4, N5, and N6 receive the multiple shares share A,N1 share A,N2 , and share A,N3 Therefore, their individual shared secret keys A,N4 share A,N5 , and share A,N6 Calculate.

[0064] Referring again to Figure 8a, a further step 850 is that a subset of nodes in the first subnetwork, for example, multiple nodes N1, N2, and N3, will have a second subnetwork SNA and a valid subset of the shared secret key SNA's verification key pk A And multiple shared secret keys corresponding to multiple nodes N1, N2, and N3 of the first subnetwork SN0 0,N1 share 0,N2 , and share 0,N3 This includes signing the second subnetwork's verification key pk. A The joint signature is σ pk0 It is being generated.

[0065] Figure 2 shows a more detailed view of the compute unit 15 operating on node 10 of network 100. Network 100 is configured to assign each compute unit operating on network 100 to one of several subnets, in this example, one of subnets SN0, SNA, SNB, or SNC according to the subnet assignment. The subnet assignment of distributed network 100 creates a subset of the total compute unit allocation for each of subnets SN0, SNA, SNB, and SNC.

[0066] More specifically, the left side of Figure 2, 201, shows one node 10 in subnet SN0 of Figure 1. The subnet allocation of the distributed network 100 is such that a subset of 5 compute units 15 are allocated to subnet SN0. More specifically, compute unit CU 01 , CU 02 , CU 03 , CU 04 , and CU 05 A subset of these is assigned to a subnet. Compute Units (CUs) 01 , CU 02 , CU 03 , CU 04 , and CU 05 The subset to which these units are allocated operates on each node 10 of subnet SN0. Furthermore, the subset to which these compute units are allocated operates on compute unit CU 01 , CU 02 , CU 03 , CU 04 , and CU 05 Each of these is replicated across the entire subnet SN0 so that it traverses the same unit state or execution state.

[0067] Furthermore, on the right side of Figure 2, 202, there are four computing units 15, more specifically, a set of computing units CU A1 , CU A2 , CU A3 , and CU A4 Figure 1 shows one node 10 of the subnet SNA where the operation is performed. Compute unit set CU A1 , CUA2 , CU A3 , and CU A4 This runs on each node 10 of the subnet SNB. Furthermore, the compute unit set consists of compute unit CU A1 , CU A2 , CU A3 , and CU A4 Each of these is replicated across the entire subnet SNA so that it has the same unit state or running state.

[0068] Figure 3 illustrates the creation of multiple blocks in a distributed network in several embodiments of the present invention. These multiple blocks may, in particular, be multiple input blocks processed by the computing units of an execution subset. The multiple blocks to be processed by the execution subset are agreed upon by the consensus subset of nodes in the subnet.

[0069] In this exemplary embodiment, three input blocks 301, 302, and 303 are shown. Block 301 comprises multiple transactions, namely transactions tx1.1, tx1.2, and any further transactions indicated by dots. Block 302 also comprises multiple transactions, namely transactions tx2.1, tx2.2, and any further transactions indicated by dots. Block 302 also comprises multiple transactions, namely transactions tx3.1, tx3.2, and any further transactions indicated by dots. The multiple input blocks 301, 302, and 303 are grouped together and connected in a chain. More specifically, each block comprises the block hash of the previous block. This cryptographically links the current block to the previous block.

[0070] In some embodiments, a transaction may be, in particular, an execution message executed by multiple nodes in an execution subset. In some embodiments, multiple input blocks 301, 302, and 303 may be generated by a proof-of-stake consensus protocol. However, it should be noted that, in some embodiments, the multiple input blocks generated by the consensus component do not need to be chained together. Rather, in some embodiments, any consensus protocol that reaches some kind of consensus among nodes regarding the selection and / or processing order of incoming messages may be used.

[0071] Figure 4 shows an overview of the multiple input blocks processed by multiple nodes N1-N6 in the execution subset. The processing for each block is simplified here. Some execution messages can be grouped together to form blocks, but these messages maintain their logical order within the block. Examples of execution messages, which may also be represented as mutations, are shown below. - User U requests that the computation unit B, which has argument X, execute method M. - Developer V requests the installation of computing unit D in the initial state S. - Developer V requests an upgrade of computing unit D to computing unit D' using the state transition function S→S'. - Developer V requests the removal of computing unit D.

[0072] Each of the multiple nodes N1, N2, N3, N4, N5, and N6 in the execution subset is generally configured to execute the same chain of multiple input blocks, each containing an execution message such as block N, N-1, N-2. The number of blocks N, N-1, N-2 can be expressed as the height of the blockchain. In this example, we assume that the execution subset of multiple nodes in the underlying distributed network, particularly multiple nodes in each subnet, each has three compute units CU1, CU2, and CU3. Each of the six nodes N1-N6 executes a replica of the three compute units CU1, CU2, and CU3. As mentioned above, each of the six nodes N1-N6 deterministically processes multiple execution blocks, but the processing of multiple input blocks does not need to be done simultaneously and may be done in a staggered arrangement. In other words, multiple nodes can be at different heights of the blockchain. When a node processes or executes an input block of height N, the node has a corresponding execution state N. In other words, the execution state N of a node corresponds to the execution result of input block N. In the example in Figure 4, node N1 is in running state 87, having successfully executed input block 87, and is adapted to process input block 88 as the next input block. Furthermore, node N2 is in running state 88, having successfully executed input block 88, and is adapted to process input block 89 as the next input block. Correspondingly, node N3 is already in running state 93, node N4 is in running state 91, and node N5 is in running state 92. The running states of nodes N1-N5 are still close to each other, and any node that is slightly behind must process the remaining input blocks in order to traverse the running states. However, assuming that node N6 is a node that has lost track, it may be indicated by a lightning bolt as a crashed node, for example. Node N6, which has lost track of its running state, needs a way or means to catch up with nodes N1-N5 that are closer to the latest running state. From this point onward, node N6 may also be indicated as catch-up node 6.

[0073] Figure 5 shows the state diagrams of multiple nodes N1 to N6 corresponding to Figure 4. These multiple nodes N1 to N6 can communicate with each other through the communication link 510, indicated by the solid arrow. However, since catch-up node N6 is no longer up-to-date, it has lost its connection to the remaining nodes N1 to N5, as indicated by the dotted arrow 520.

[0074] In some embodiments of the present invention, a set of information is provided to a catch-up node N6. In other words, an information package is provided to node N6 that facilitates or enables it to catch up its own running state to the actual running state of the network. Such an information package or set of information will hereafter be referred to as a state information package or catch-up package. Further details of the information that may be included in such a state information package are described below.

[0075] Referring to Figure 6, several embodiments of the present invention illustrate methods that enable a catch-up node, for example catch-up node N6, to verify such a state information package.

[0076] More specifically, Figure 6 shows the signature σ of the first subnet or management subnet SN0. pk0 Multiple second verification keys pk for the second subnet SNA, SNB, and SNC, which are authenticated and are typically referred to as second verification key 610. A , pk B , and pk C These are shown respectively. Therefore, all second verification keys 610 are returned to the verification key pk0 of the first subnet or management subnet SN0. In this way, the verification key pk0 of the first subnet or management subnet SN0 establishes the root of trust in the distributed network.

[0077] public verification key pk A , pk B , and pk CEach of these is signed with the minimum number of predefined shared secret keys for the management subnet, i.e., the shared secret key corresponding to the verification key pk0. Public verification key pk i The signature jointly generated by the corresponding predefined minimum number of shared secret keys forms a joint signature 620 of the multiple nodes involved, and thereafter σ pki It is represented as follows.

[0078] The key thus formed can be verified with the verification key pk0, which establishes the root of trust for the distributed network. Key 610, together with signature 620, forms a key certificate 630.

[0079] To enable verification of multiple nodes in the network, particularly catch-up nodes, the network may publish multiple newly generated verification keys for multiple second subnets, along with a joint signature by the management committee or management subnet.

[0080] The publication of verification key certificate 630 can be carried out in various ways, depending on the communication mechanism of each distributed network. However, in general terms, publication should be understood as making it available to multiple nodes in the network, especially catch-up nodes.

[0081] Multiple key certificates 630 and corresponding verification keys may be used in accordance with some embodiments of the present invention to verify the signature of the state information package.

[0082] Figure 7a shows a timing diagram for blockchain 710, which has blocks 711 with block numbers 22-32. In the illustrated example, four blocks create a predefined period 720 of four blocks 711 in blockchain 710. Corresponding to blockchain 710, multiple nodes in the distributed network traverse a chain 740 of execution states 22-31. Execution states 22-31 are represented by reference number 741 and further illustrated by diamonds 741. Multiple nodes in the execution subset of the distributed network execute the execution message of the corresponding block N and then capture or move to execution state N. For example, multiple nodes in the execution subset execute the execution message of block 24 and then capture or move to execution state 24. Therefore, the diamonds 741 representing the states in Figure 7a are shown slightly offset from the corresponding block 711. In the example in Figure 7a, the state information package for the seventh period, which has blocks 25-28, may be signed with a shared secret key corresponding to the verification of this subnet. In some embodiments, the state information package may also be represented as a catch-up package or a recovery package. The state information package comprises, in particular, the running state or a hash of the running state. Embodiments in which the state information package comprises only the hash of the running state have the advantage that, in positive verification of the hash, each node can first check the hash and download only the completed running state. In such embodiments, the state information package comprises the hash from pk0, along with all the keys and certificates necessary for its verification. This can avoid unnecessary downloading of the complete state. In positive verification of the hash, the (completed) running state itself can be fetched separately. The running state may be, in particular, the most recent running state, in particular the running state for the current period. For example, referring to Figure 7a, each subnet has its respective verification key pk XThe corresponding shared secret key can sign the state information package SIP, 750 corresponding to the execution state 24 after the execution of block 24. In some embodiments, the state information package SIP, 750 can be added to the blocks of the blockchain. In some embodiments, the first block of each of the plurality of periods 720 includes the state information package SIP, 750.

[0083] Figure 7b shows a more detailed block diagram of the state information package SIP, 750. The state information package 750 first constitutes an execution state 741. In addition, the state information package 750 includes a certificate 730 that can correspond to the certificate 630 as shown in FIG. 6.

[0084] Furthermore, the state information package 750 includes block verification information 752. Such block verification information 752 can include information necessary for verifying the validity of a plurality of subsequent blocks of the blockchain, particularly a plurality of subsequent blocks. In this regard, the plurality of subsequent blocks are blocks that should be executed following the execution state of the state information package. The block verification information can particularly include a set of verification keys necessary for verifying the validity of a plurality of blocks of the blockchain.

[0085] The complete state information package 750 is co-signed σ X by a predefined minimum number of shared secret keys corresponding to the verification key pk of each subnet pkX The certificate 730 includes the verification key necessary for verifying pk X After verifying pk using the verification key certificate X each node can verify the signature σ on the state information package 750 using the verified verification key pk X Note that the certificate 730 need not be included in the state information package 750 in some embodiments, but can be communicated to each catch-up node through other communication channels. pkX

[0086] ​Figure 9 shows a multi-step flowchart 900 of how a catch-up node enables an update of its execution state. In step 910, the catch-up node receives a state information package, for example, the state information package 750 shown in Figure 7b. The catch-up node may, for example, extract a state information package from a block containing a state information package. The catch-up node then verifies the received state information package using a two-step approach.

[0087] First, in step 920, the catch-up node extracts a certificate from the state information package. Then, in step 930, it uses that certificate to verify the verification key corresponding to the joint signature of the state information package. Steps 920 and 930 form the first part or first step of the verification of the state information package. Next, in step 940, the catch-up node uses the verification key previously verified in steps 920 and 930 to verify the joint signature on the state information package.

[0088] If the verification is successful, in step 950, the catch-up node can synchronize its execution state using further elements of the state information package, in particular using the execution state 741 provided by the state information package.

[0089] Figure 10 shows flowcharts illustrating some embodiments of the method of the present invention. More specifically, it shows a method for periodically adding state information packages to multiple blocks of a distributed network and associated protocols.

[0090] This method involves periodically executing a consensus protocol in loop 1010, thereby enabling a subset of executions from multiple nodes to reach a consensus on a set of execution messages, particularly those to be executed by a subnetwork. A consensus subset of multiple nodes in a network, particularly a consensus subset of a subnetwork, may execute the consensus protocol. Loop 1010 includes step 1011, in which multiple nodes in the consensus subset reach a consensus on a new input block. These input blocks may be numbered with an increasing height index N, where N is an increasing integer, i.e., 0, 1, 2, 3...N. The height index may also be expressed as the block height.

[0091] Next, in step 1021, the execution messages of the agreed-upon input blocks are deterministically executed individually by the computation units of multiple nodes in the execution subset. As a result of the execution, in step 1022, the multiple nodes in the execution subset update their execution states, thereby traversing a series of execution states. As described above, multiple different nodes in the execution subset may be operating at different positions in the chain at a given time. Steps 1021 and 1022 are repeated in loop 1020.

[0092] Furthermore, this method includes a loop 1040 that generates and signs a state information package SIP. The state information package SIP is not generated for every block, but only for every i-th block, for example, every 500th block. This can be done, for example, using a counter. Thus, after each block is generated, in step 1041, the counter is activated and checked to see if it has expired. The counter can be materialized in various ways. Specifically, it can be programmed to terminate after processing loop 1010 a predetermined number of times, for example, after processing loop 1010 500 times. When the counter expires, multiple nodes compile a state information package SIP in step 1042 that may contain the above information, in particular the most recent execution state. Next, in step 1043, the state information package for the current period or current loop is signed with a predefined minimum number of shared secret keys corresponding to the verification key of each subnetwork. Then, in step 1044, the state information package SIP is added to a block in the blockchain and the counter is reset.

[0093] Figure 11 shows an example of execution state 1100 in execution state "state@5000".

[0094] The execution state is provided as tree-structured data. Such an execution state may have a total size of several gigabytes. For efficient storage on disk, it may be provided with, for example, 64 KB of memory pages.

[0095] The execution state@5000 contains the execution states and metadata of multiple compute units. The execution state information of multiple compute units includes the computation results of computed execution messages. The execution state information may be stored as memory pages. System metadata may include other states maintained by the system on behalf of the context and callbacks of compute units and unprocessed messages. In some embodiments, the leaves of the tree structure data may contain only the corresponding data, such as the hash of each memory page.

[0096] In one embodiment, the execution state may be provided as a Merkle tree structure. In some embodiments, the state information package may store only the hash root of the tree structure, particularly the Merkle tree structure, as execution state information. This facilitates memory-efficient storage. The tree structure facilitates efficient synchronization between the most recent node and catch-up nodes that have expired and wish to resume participation in the distributed network.

[0097] Figure 12 illustrates such synchronization between the latest node 1210, which has a running state@5000, and the expired catch-up node 1220, which has an expired state@4000.

[0098] In one embodiment, the catch-up node 1220 may request only a number of leaf hashes of the tree structure from the latest node 1210 and compare the number of leaf hashes of its own state with the leaf hashes of the latest node. In a further step, the catch-up node 1220 may then request only the state information corresponding to a number of leaves having different number of leaf hashes from the latest node 1210. This avoids downloading the entire state information package but downloads only a portion of the state information package that is different from the state of the catch-up node.

[0099] Figures 13a and 13b illustrate several embodiments of verification keys in some embodiments of the present invention, and some embodiments of their corresponding shared secret keys obtained from the management committee subnet.

[0100] Figure 13a shows an embodiment of the key 1310 generated by the threshold-distributed key generation protocol. In this example, we assume that N nodes participate in a distributed key generation protocol. For each round of the distributed key generation protocol, each of the N nodes generates a shared secret key sk where i=1, ..., N. iIt has. N nodes jointly generate a common public key pk. Here, a predefined threshold, for example, at least two-thirds or one-third of the nodes, agree on a new public key or a new verification key, and a threshold signature σ pk To generate, it is necessary to jointly sign on a new public key or a verification key.

[0101] Figure 13b shows an embodiment of the key 1320 generated by the multi-signature protocol.

[0102] In this example, it is again assumed 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 shared secret key sk i with i = 1, ···, N. In this embodiment, the shared secret key can be embodied as an independent secret key sk i . The N nodes jointly agree on a common public key or a common verification key vector pk embodied as a vector. Here too, a predefined threshold, for example, at least two-thirds of a plurality of nodes or one-third of the nodes, needs to provide a signature with a secret key (shared key) for a new public key or a verification key vector pk. In this embodiment, the N nodes use their respective secret keys sk i , sk2, ···, sk N to execute individual signatures σ 1pk1 , σ 2pk2 , ···, σ NpkN for the corresponding elements of the vector verification key vector pk. More specifically, each of the individual signatures σ ipki [[ID=2e]]has a corresponding individual public key pk i . Thus, in such an embodiment, the verification key is embodied as a vector pk = (pk i , pk2, ···, pk i , ···, pk N ) of the individual public keys pk, and the joint signature is also embodied as a vector σ pk = (σ 1pk1 , σ 2pk2 , ···, σ NpkN ). In other embodiments, an aggregated signature scheme may also be used.

[0103] Figure 14 shows a more detailed diagram of a computing unit 1400 according to one embodiment of the present invention. The computing unit 1400 includes a user or application state 1401 and a system state 1402.

[0104] User state 1401 consists of a main web assembly (WASM) module that implements the functionality of the compute unit and its associated modules, along with individual instances of each of the modules. The WASM module instance consists of multiple memory locations, multiple global variables, and multiple tables. System state 1402 cannot be freely modified by the compute unit's code. This includes metadata, other states maintained by the system on behalf of the compute unit, particularly the compiled form of the WASM module, and context and callbacks for unprocessed messages.

[0105] Referring here to Figure 15, a more detailed block diagram of a network node 10, for example, shown in network 100 of Figure 1, according to an embodiment of the present invention, is shown. Network node 10 constitutes a computing node capable of performing computing functions and thus generally embodied as a computing system or computer. Network node 10 may be, for example, a server computer. Network node 10 may be configured to perform a computer implementation method that provides users of the distributed network with access to computing results computed by the distributed network. Network node 10 can operate in many other general-purpose or special-purpose computing system environments or configurations. Network node 10 may be described in the general context of computer system executable instructions, such as program modules executed by the computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc., that perform a specific task or implement a specific abstract data type. Network node 10 is shown in the form of a general-purpose computing device. The components of network node 10 may include one or more processors or processing units 1515, system memory 1520, and a bus 1516 that connects various system components, including system memory 1520, to the processor 1515. However. Bus 1516 represents one or more of several types of bus structures, including a memory bus or memory controller, peripheral bus, accelerated graphics port (AGP), and a processor or local bus using any of the various bus architectures. For example, but not limited to, such architectures include the Industry Standard Architecture (ISA) bus, Microchannel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus. Network node 10 typically contains various computer system-readable media.Such media could be any available media accessible by network node 10, and could include both volatile and non-volatile media, removable and non-removable media. System memory 1520 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 1521 and / or cache memory 1522. Network node 1510 may further include other removable / non-removable, volatile / non-volatile computer system storage media. As an example, storage system 1523 could provide a non-removable, non-volatile magnetic medium (not shown, typically called a “hard drive”) for reading and writing. Not shown, it could also provide a magnetic disk drive for reading and writing to removable non-volatile magnetic disks (e.g., “floppy disks”), and an optical disk drive for reading or writing to removable non-volatile optical disks, such as CD-ROMs, DVD-ROMs, and other optical media. In such cases, each could be connected to bus 21516 by one or more data media interfaces. As will be further described below, memory 1520 may include at least one computer program product having a set of program modules (e.g., at least one) configured to perform the functions of several embodiments of the present invention. A program / utility 1530 having a set of program modules 1531 (at least one) may, as an example but not limited to, store an operating system, one or more application programs, other program modules, and program data in memory 1520. Each of the operating system, one or more application programs, other program modules, and program data, or several combinations thereof, may be implemented in a network environment. Program modules 1531 generally perform the functions and / or methodologies of several embodiments of the present invention as described herein.The program module 1531 may perform one or more specific steps of a method for implementing on a computer to provide users of the distributed network with access to computation results computed by the distributed network, for example, one or more steps of the method described above. The network node 10 may also communicate with one or more external devices 1517, such as a keyboard or pointing device, as well as a display 1518. Such communication can be performed via an input / output (I / O) interface 1519. Furthermore, the 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), through the network adapter 1541. In some embodiments, the network 1540 may be a distributed network comprising multiple network nodes 10, for example, a network 100 as shown in Figure 1. As illustrated, the network adapter 1541 communicates with other components of the network node 10 through the bus 1516. It should be understood that other hardware and / or software components can be used in combination with the network node 10, although not specifically shown.

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

[0107] A computer-readable storage medium can be a tangible device capable of holding and storing instructions used by an instruction execution unit. A computer-readable storage medium may be, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A computer-readable storage medium should not be construed, as used herein, as a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., optical pulses passing through optical fiber cables), or electrical signals transmitted through wiring.

[0108] The computer-readable program instructions described herein are downloadable to each computing or processing unit to an external computer or external storage device via a computer-readable storage medium or a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing or processing unit receives computer-readable program instructions from the network and transfers them for storage in the computer-readable storage medium within the respective computing / processing unit.

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

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

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

[0112] Computer-readable program instructions, when loaded onto a computer, other programmable data processing device, or other device, can generate a computer implementation process that runs on the computer, other programmable device, or other device, which is a set of operational steps that run on the computer, other programmable data processing device, or other device. Thus, the instructions run on the computer, other programmable data processing device, or other device implement functions / operations specified in flowcharts and / or block diagrams or multiple blocks.

[0113] The illustrated flowcharts and block diagrams illustrate the architecture, functionality, and operation of possible implementations of networks, systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or part of an instruction, comprising one or more executable instructions that implement a particular logical function. In some alternative implementations, the functions described in the blocks may occur in a different order than shown in the diagram. For example, two blocks shown consecutively may actually be executed substantially simultaneously. Also, these blocks may be executed in reverse order depending on the functions involved.

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

Claims

1. A computer implementation method for generating a verification key for a public key signing scheme in a distributed network, wherein the distributed network has a plurality of nodes, the plurality of nodes are divided into two or more subnetworks, each of the plurality of nodes is configured to execute one or more computing units, each computing unit of the two or more subnetworks is configured to perform computations in a deterministic and replicated manner across the corresponding subnetworks of the two or more subnetworks, thereby traversing a set of execution states corresponding to each of the two or more subnetworks, and the method is: The steps include: executing a first distributed key generation protocol configured such that a subset of nodes in a first subnetwork jointly generates a verification key for the first subnetwork and a set of shared secret keys corresponding to the subset of nodes in the first subnetwork; The steps include: executing a second distributed key generation protocol configured such that a subset of nodes in the first subnetwork jointly generates a verification key for the second subnetwork and a set of shared secret keys corresponding to a subset of nodes in the second subnetwork; A computer implementation method comprising the steps of: a subset of nodes of the first subnetwork signing the verification key of the second subnetwork together with an acceptable subset of the plurality of shared secret keys of the nodes of the first subnetwork, thereby generating a joint signature on the verification key of the second subnetwork.

2. The computer implementation method according to claim 1, comprising the step of the second subnetwork signing a state information package of the second subnetwork together with an acceptable subset of the plurality of shared secret keys corresponding to the verification key of the second subnetwork, thereby generating a joint signature on the state information package of the second subnetwork, wherein the state information package includes the running state of the second subnetwork or a hash of the running state.

3. The computer implementation method according to claim 1, comprising the step of the first subnetwork signing a state information package of the first subnetwork together with an acceptable subset of a plurality of shared secret keys corresponding to the verification key of the first subnetwork, thereby generating a joint signature on the state information package of the first subnetwork, wherein the state information package includes the running state of the first subnetwork or a hash of the running state.

4. The distributed network has a plurality of second subnetworks, and the state information package of the first subnetwork includes a list, and the list is The node verification keys of the aforementioned plurality of second subnetworks, The computer implementation method according to claim 3, comprising a plurality of nodes of the plurality of second subnetworks.

5. The step of executing the second distributed key generation protocol on the second subnetwork is: A step in which a node of the first subnetwork generates a second verification key and a plurality of first shared secret key sets corresponding to the nodes of the first subnetwork, wherein each node of the first subnetwork holds one of the first shared secret key sets. The computer implementation method according to claim 1, comprising the steps of: the secret redistribution protocol redistributing the shared secret keys of the first shared secret key set to the plurality of nodes of the second subnetwork, thereby generating a second shared secret key set corresponding to the second verification key of the second subnetwork.

6. The computer implementation method according to claim 1, further comprising the step of publishing the verification key of the second subnetwork together with the joint signature of the first subnetwork, thereby providing a certificate of the verification key of the second subnetwork.

7. The step of a node, in particular a catch-up node that wishes to connect to or reconnect to the second subnetwork of the distributed network, further includes verifying the state information package of the second subnetwork, and the step of verifying the state information package is: The steps include verifying the certificate with the verification key of the first subnetwork, thereby verifying the verification key of the second subnetwork corresponding to the joint signing of the state information package, The computer implementation method according to claim 6, comprising the step of verifying the joint signature of the state information package using a verified verification key of the second subnetwork corresponding to the joint signature of the state information package.

8. The computer implementation method according to any one of claims 2, 3, and 7, wherein the distributed network further comprises the step of generating a blockchain of multiple blocks, and the state information package includes block verification information for verifying the validity of a subsequent number of blocks, in particular a successor number of blocks, of the blockchain.

9. The computer implementation method according to claim 8, wherein the block verification information includes a set of verification keys necessary for verifying the validity of multiple blocks of the blockchain.

10. The computer implementation method according to claim 7, wherein the status information package of the second subnetwork includes the verification key of the second subnetwork and the certificate.

11. The computer implementation method according to any one of claims 2, 3, and 7, wherein the state information package further includes key generation information of a distributed key generation protocol used to generate the verification key of the second subnetwork.

12. The computer implementation method according to any one of claims 2, 3, and 7, wherein the state information package includes a set of information that enables the execution state of a catch-up node wishing to connect to or reconnect to the distributed network to be synchronized with the most recent execution state.

13. The computer implementation method according to claim 8, further comprising the step of adding the state information package at predetermined time intervals of the blocks of the blockchain.

14. The computer implementation method according to any one of claims 2, 3, and 7, wherein the state information package provides the execution state as a Merkle tree structure, and more particularly as a hash root of the Merkle tree structure.

15. The steps include: a catch-up node that wishes to connect to or reconnect to the second subnetwork from the latest node of the second subnetwork requests multiple leaf hashes of the Merkle tree structure; The catch-up node compares the plurality of leaf hashes of its own state with the plurality of leaf hashes of the latest node, The computer implementation method according to claim 14, wherein the catch-up node from the latest node requests only state information corresponding to multiple leaves having multiple different leaf hashes.

16. The computer implementation method according to any one of claims 1 to 15, wherein the first distributed key generation protocol and the second distributed key generation protocol are threshold distributed key generation protocols.

17. The computer implementation method according to claim 5, wherein the secret redistribution protocol is a key redistribution protocol.

18. The computer implementation method according to any one of claims 1 to 17, wherein the joint signature is a multiple signature.

19. The aforementioned distributed key generation protocol is The catch-up node accepts one or more connections from unknown nodes, The steps include: restricting communication exchange with the unknown node to communication relating to the state information package and certificates; The computer implementation method according to claim 11, further comprising the step of stopping communication with the unknown node once the state information package and the certificate have been received.

20. A distributed network having multiple nodes, wherein the multiple nodes are divided into two or more subnetworks, each of the multiple nodes is configured to run one or more computing units, each computing unit of the two or more subnetworks is configured to perform computations in a deterministic and replicable manner across the corresponding subnetworks of the two or more subnetworks, thereby traversing a set of execution states corresponding to each of the two or more subnetworks, and the distributed network is, A subset of nodes in a first subnetwork is configured to execute a first distributed key generation protocol, which is configured to jointly generate a verification key for the first subnetwork and a set of shared secret keys corresponding to the subset of nodes in the first subnetwork. A subset of nodes in the first subnetwork is configured to execute a second distributed key generation protocol, which is configured to jointly generate a verification key for the second subnetwork and a subset of shared secret keys corresponding to the subset of nodes in the second subnetwork. A distributed network configured such that a subset of nodes of the first subnetwork signs the verification key of the second subnetwork together with an acceptable subset of the plurality of shared secret keys of the nodes of the first subnetwork, thereby generating a joint signature on the verification key of the second subnetwork.

21. A plurality of nodes in the distributed network described in claim 20, wherein the nodes are Participating in a first distributed key generation protocol configured to jointly generate a verification key for the first subnetwork and a plurality of shared secret keys corresponding to a subset of nodes in the first subnetwork, Participating in a second distributed key generation protocol configured to jointly generate a verification key for the second subnetwork and multiple shared secret keys corresponding to a subset of nodes in the second subnetwork, A node configured to participate in co-signing a verification key for the second subnetwork, which includes an acceptable subset of the shared secret keys of the nodes of the first subnetwork.

22. A computer program for operating a distributed network, wherein the distributed network comprises a plurality of nodes, the computer program comprises program instructions, the program instructions are executable by one or more of the plurality of nodes to cause one or more of the plurality of nodes to execute a predetermined method, and the method is The steps include: performing a computation in a deterministic and replicated manner across the corresponding subnetworks of the two or more subnetworks, thereby traversing a set of execution states corresponding to each of the two or more subnetworks; The steps include: executing a first distributed key generation protocol configured such that a subset of nodes in a first subnetwork jointly generates a verification key for the first subnetwork and a set of shared secret keys corresponding to the subset of nodes in the first subnetwork; The steps include: executing a second distributed key generation protocol configured such that a subset of nodes in the first subnetwork jointly generates a verification key for the second subnetwork and a set of shared secret keys corresponding to a subset of nodes in the second subnetwork; A step in which a subset of nodes of the first subnetwork signs the verification key of the second subnetwork together with an acceptable subset of the plurality of shared secret keys of the nodes of the first subnetwork, thereby generating a joint signature on the verification key of the second subnetwork, A computer program equipped with [a specific feature / ability].

Images