Distributed networks with a consensus mechanism

Abstract

One aspect of the present invention relates to a decentralized network including a plurality of network nodes. The decentralized network is configured to execute a method for achieving consensus on a sequence of values ​​in an advantageous manner. The method is performed in successive notarization rounds. A notarization round comprises the steps of creating value propositions to be added to the sequence, communicating the value propositions to a notarized subset of the plurality of nodes, and validating the accepted value propositions. A notarization round may include the further step of performing individual notarization signatures on the subset of valid value propositions. The notarization round may further include performing an integrity check on the value propositions and performing a consistency signature on a subset of the value propositions. The method may further include a finality procedure that finalizes the value propositions once a predefined set of finality rules is met.

Description

Technical Field

[0001] The present invention relates to a distributed network including a plurality of network nodes. The distributed network is configured to form an agreement on a series of values, particularly on blocks to be written to a blockchain.

[0002] In a further aspect, it relates to a computer-implemented method for forming an agreement on a sequence of values, particularly on blocks to be written to a blockchain, nodes of a distributed network, corresponding computer program products, and software architectures encoded in a non-transitory medium.

Background Art

[0003] In a distributed network, a plurality of nodes are distributed. In the calculation of a distributed network, software and data are distributed across a plurality of nodes. Nodes define computing resources, and the distributed network may use distributed computing technologies.

[0004] An example of a distributed network is a blockchain network. A blockchain network is a consensus-based block-based electronic ledger. Each block is composed of transactions and other information. Further, each block contains the hash of the previous block, and the blocks are chained together to create a permanent and immutable record of all transactions written to the blockchain. Transactions may call known small programs known as smart contracts.

[0005] In order to write a transaction to the blockchain, the transaction needs to be "verified" and agreed upon by the network. In other words, network nodes need to form an agreement on the blocks to be written to the blockchain. Such an agreement can be realized by various consensus protocols.

[0006] In one type of blockchain network, consensus is achieved using the proof-of-work algorithm. Proof-of-work consensus protocols typically require work from the parties participating in the consensus protocol, which usually corresponds to computer processing time. Proof-of-work based cryptocurrency systems like Bitcoin involve solving computationally intensive puzzles.

[0007] Another type of consensus protocol is based on the proof-of-stake algorithm. Such proof-of-stake protocols have the advantage of not requiring a large amount of time and energy for computation. In a proof-of-stake based blockchain network, for example, the creator of the next block is selected by a combination of random selection and the stakes of each node in the network.

[0008] 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 functions and services. For this purpose, decentralized networks can use state machine replication protocols to ensure that applications run and their state is preserved across multiple nodes, even in the event of node crashes or adversarial attacks.

[0009] The consensus protocol used in blockchain networks can be designed to quickly and reliably settle transactions contained in a block by applying the "Byzantine Fault Tolerant" (BFT) consensus protocol. The "synchronous" BFT protocol relies on the assumption of network synchronization for security. The "asynchronous" BFT protocol, on the other hand, is different. In the asynchronous BFT protocol, failure of less than one-third of the participating nodes is usually tolerable.

[0010] However, the need for distributed networks with sophisticated consensus mechanisms and capabilities remains. [Overview of the project] [Means for solving the problem]

[0011] Therefore, one object of one aspect of the present invention is to provide a distributed network configured to form agreement on a set of values ​​in an advanced manner, particularly with respect to an asynchronous consensus protocol, especially in terms of throughput.

[0012] According to one embodiment of one aspect of the present invention, a distributed network as described in claim 1 is provided.

[0013] More specifically, a distributed network according to an embodiment of the present invention may comprise a plurality of network nodes. The distributed network may be configured, in particular, to perform a method for forming an agreement on a set of values ​​by an asynchronous consensus protocol. This method may comprise a step of performing a series of notarization rounds. The notarization rounds may be assigned a sequential notarization round number. The notarization rounds may be simply referred to as rounds. The notarization rounds shall represent several embodiments of rounds between the steps described below. The notarization round may comprise a step in which one or more network nodes create value proposals to be added to the sequence and communicate those value proposals to a notarization subset of a plurality of nodes. According to one embodiment, the value proposals may comprise a link to the parent value proposal of the previous notarization round.

[0014] A notarization subset shall represent several embodiments of a subset of multiple nodes that perform the steps of the notarization round as described below. A notarization subset may simply be referred to as a subset or the first subset. This method may further comprise a notarization subset of multiple nodes that perform the validity check of the accepted value proposals.

[0015] Validation may involve checking whether the received value proposals conform to a predefined set of validity rules. A notarization round may involve a further step in which a subset of notarization nodes communicate by performing individual notarization signatures on a subset of value proposals that are valid according to the validation. This results in individually notarized value proposals.

[0016] According to some embodiments, individual notarized signatures must represent the electronic signatures of individual nodes in a notarized subset.

[0017] According to one embodiment, a notarization round may include a further step in which a distributed network notarizes a value proposal once a predefined number of individual notarized signatures have been collected or observed. This results in a fully notarized value proposal for each notarization round.

[0018] A notarization round may include a further step in which multiple nodes of a notarization subset perform consistency checks on the value proposals of one or more notarization rounds for their own individual notarization signatures performed in the current notarization round. The consistency check consists of checking whether the value proposals of one or more consecutive notarization rounds conform to a set of predefined consistency rules.

[0019] According to some embodiments, a predefined set of integrity rules takes into account the unique notarized signature of each node being performed in the current notarization round.

[0020] A notarization round may involve a further step in which nodes in a notarization subset perform consistency signing and communicate in a subset of value proposals that are consistent according to a set of consistency rules, thereby creating a consistency-signed value proposal.

[0021] In some embodiments, a consistency signature must demonstrate the electronic signatures of individual nodes within a notarized subset.

[0022] This method is based on a consistency signature. In other words, it may further include a finality procedure that takes into account the consistency signature. The finality procedure may include steps for the distributed network to finalize a value proposition when the value proposition meets a predefined set of finality rules. The set of finality rules may include a predefined minimum number of consistency signatures. The predefined minimum number of consistency signatures may be a sufficient or necessary criterion for finalization.

[0023] As a result of the finality procedure, a finalized value may be created. The finality procedure may further include steps for adding the finalized value to a sequence of values.

[0024] In some embodiments, the finalized value may be defined as a value for which the distributed network has formed an agreement that addition to the sequence of values is mandatory.

[0025] Thus, according to some embodiments of the present invention, the notarization round and the finality procedure can be performed alternately in a pipeline format. More specifically, the distributed network may proceed to a new notarization round and start creating a new value proposition even before the previous notarization round has ended. In other words, the notarization round and the finality procedure may function asynchronously. Thereby, the throughput of the system can be significantly improved.

[0026] [[ID=J16]]In some embodiments, consecutive notarization rounds may partially overlap with each other. That is, the next notarization round may be started even if the previous notarization round has not ended.

[0027] The finality procedure based on consistency signatures created in accordance with a set of consistency rules can guarantee the safety of the Byzantine model's agreement method without assuming synchronization for communication between nodes in the distributed network, even if it is an asynchronous consensus protocol.

[0028] According to some embodiments, an asynchronous consensus protocol can be defined as a protocol configured to ensure the success of consensus, even though there is no guarantee that nodes in a distributed network will accept each message, particularly each individual attestation signature and each consistency signature, within a predefined time.

[0029] According to some embodiments, the communication of value proposals to the attestation subset can occur during the first period of the attestation round, as well as during the execution of individual attestation signatures and consistency signatures. The communication of individual attestation signatures and consistency can occur during the (subsequent) second period of the attestation round.

[0030] This is a very efficient communication scheme for the asynchronous consensus protocol. More specifically, after communicating the value proposal, only two communication rounds need to be arranged in the second period, one for communicating the attestation signature and one for communicating the (subsequent) consistency signature. After the first communication round of the two communication rounds arranged in the second period, the implemented method can already continue without waiting for the second communication round of the two communication rounds arranged in the second period to complete the next attestation round, that is, the communication of the next value proposal, without waiting for the completion of the finality procedure. Such embodiments can shorten or minimize the downtime of the asynchronous consensus scheme, that is, the time unavailable for the communication of new value proposals.

[0031] According to some embodiments, the first period of the attestation round can be selected or configured to be at least as long as the second period of the attestation round. According to some embodiments, the first period can be at least twice as long as the second period, and according to yet another embodiment, it can be three times as long as the second period. This makes it possible to increase the time available for communicating value proposals. According to some embodiments, the distributed network can be configured to use at least 60% of the time for communicating value proposals, and according to further embodiments, it can be configured to use at least 75% of the time.

[0032] Such communication methods can effectively improve the throughput of the consensus mechanism. According to some embodiments, throughput is defined as the total size of all value proposals agreed upon within a given time unit. To achieve high throughput, some embodiments of the present invention use large (in bytes) value proposals. With large value proposals, the bandwidth required to communicate the value proposal becomes dominant over the bandwidth required for notarized and integrity signatures. From the viewpoint of throughput, according to some embodiments, value proposals having a size of at least 1 MB are advantageous. Furthermore, according to some embodiments, individual notarized and integrity signatures having a size of less than 200 bytes are advantageous.

[0033] Value is typically any kind of information. In some embodiments, value can be a transaction. In further embodiments, value can be a block on a blockchain.

[0034] According to some embodiments, the validation test may, just as a first test, show a set of validation rules as a first set of rules and individual notarized signatures as individual first signatures.

[0035] According to some embodiments, integrity checks may also be represented as second checks, a set of integrity rules as a second set of rules, and a integrity signature as a second signature. Furthermore, a integrity signature may be represented as an individual integrity signature.

[0036] According to some embodiments, a set of finality rules may also be presented as a third set of rules.

[0037] In the following, the terms notarized and sufficiently notarized, and the terms notarized and fully notarized may be used interchangeably.

[0038] The step of conducting consistency checks may be performed, in particular, after the fully notarized valuation proposals of the current notarization round have been observed.

[0039] According to one embodiment, the step of preparing a current valuation proposal for the current notarization round may include, in particular, linking the current valuation proposal to a fully notarized valuation proposal from a previous notarization round.

[0040] Links can be referenced by hash digests. In other words, links can be established by including the hash digest of a fully notarized value proposal in the current value proposal. According to such embodiments, a network node attempting to create a new value proposal must select a parent value proposal from the previous notarization round. Thus, according to some embodiments, a directed graph of value proposals is created.

[0041] It should be noted that, according to such embodiments, such values ​​do not need to be linked to each other beforehand. Therefore, according to some embodiments, values ​​can be completely independent values, but value propositions are necessarily linked to each other.

[0042] According to one embodiment, the value proposal includes the current notarization round number. This facilitates the processing of the value proposal by the network nodes.

[0043] During validation performed by the nodes of the notarized subset, the value proposal is checked or reviewed to determine whether it conforms to a predefined set of validation rules. These rules may, for example, be specified as part of the specifications of a distributed network.

[0044] According to one embodiment, a set of validity rules may determine that a value proposal is valid only if the corresponding parent value proposal is fully notarized.

[0045] In particular, a set of predefined validity rules stipulate that the value proposal in the current notarization round is valid. It can be defined as valid only when it is linked to the fully notarized valuation proposal of the notarized round immediately preceding the current notarization round, and at the same time linked to the parent valuation proposal.

[0046] In a further embodiment, a predefined set of validity rules may define that a value proposal in the current notarization round is valid only if it links to a fully notarized value proposal in a previous notarization round, and that the previous notarization round generally precedes the current notarization round. In such an embodiment, the term “previous notarization round” shall mean one of the previous notarization rounds, which could be the last notarization round, the second to last notarization round, the third to last notarization round, and so on. More specifically, in such an embodiment, only all nth value proposals must be fully notarized according to the set of validity rules. This allows for further parallelization.

[0047] In such an embodiment, the full notarization makes each value proposal valid in the sense that future proposals can be built upon that notarization, i.e., it refers to that value proposal as their parent value proposal.

[0048] Such an embodiment offers the advantage that only fully notarized value proposals are viable, i.e., have the opportunity to be added to the value sequence. In return, it enhances the security of the consensus mechanism. More specifically, the subsequent finalization of value proposals based on a predefined count of integrity signatures works in conjunction with the enhanced security to provide a technical advantage in avoiding branching in an efficient manner.

[0049] According to several further embodiments, validation of a given value proposal may involve examining one or more features of the given value proposal. According to several embodiments, one or more features may include the network node that created the given value proposal, the content of the given value proposal itself, and / or the content of previous value proposals linked to the given value proposal, in particular the content of the previous value proposals. According to several embodiments, a link may be established by including a hash digest of a previous value proposal in the given value proposal. This is referred to as a direct link. According to several embodiments, a link may be established as a chain of links in which one of the previous proposals is directly linked to a second previous proposal, and so on, until it is directly linked to the given value proposal. In this case, the first previous value proposal is referred to as indirectly linked to the given value proposal.

[0050] Such validation of the features of a value proposal can improve the quality of a notarized value proposal. In addition to checking whether the parent value proposal is fully notarized, a validation of the features of the value proposal can be performed.

[0051] In this regard, the term “quality” shall refer, in particular, to the quality relating to the semantics of the value proposition. For example, if the value proposition is a block of payment transactions, such duplicate spending can be eliminated early, especially before finalization in some embodiments, by using validation checks with notarized subsets.

[0052] According to some embodiments, passing the validation check requires, for example, that the value proposal is made by known nodes, that the value proposal includes a solution to its own proof-of-work puzzle, that the value proposal consists only of valid transactions, and that the transactions of the value proposal do not conflict with any transactions from previous value proposals to which a particular value proposal is directly or indirectly linked.

[0053] According to some embodiments, the notarized subset may depend on the notarized round, that is, the notarized subset may change from one notarized round to the next.

[0054] According to some embodiments, a set of validity rules may change over time.

[0055] This makes it possible, for example, to flexibly adapt distributed networks to new or changed requirements, applications, or needs.

[0056] According to one embodiment, validation is performed at individual nodes of a notarization subset, and these individual nodes may perform individual notarization signatures on value proposals that are valid according to a set of validation rules. In other words, if a value proposal passes the validation at an individual node, that node may perform an individual notarization signature on the value proposal. In this regard, an individual notarization signature can be considered to include a signature confirming that the value proposal has passed the validation at the signing node.

[0057] According to some embodiments, individual nodes of the notarized subset perform individual notarized signatures on a subset of value proposals that are valid according to the validation.

[0058] In particular, individual nodes may perform individual notarized signatures on fewer value proposals than all value proposals that are recognized and valid according to a set of validity rules.

[0059] This can increase the probability of success in the finality procedure. Consequently, the frequency of agreements also increases, meaning that the average "speed" of agreements can indirectly increase.

[0060] For example, the fewer individual notarized signatures required for the value proposition, the less likely it is to be fully notarized, and the less ambiguity there is. Therefore, the likelihood of the finality process succeeding increases.

[0061] This may be particularly useful when combined with another embodiment of the invention, which includes assigning ranks to block proposals.

[0062] In such embodiments, a distributed network may assign ranks to block proposals. Such ranks may be assigned according to embodiments based on the node rank of the corresponding node. In some other embodiments, the rank may be assigned to the block proposal itself, where the rank is not derived from the corresponding node. As an example, only the hash of the block proposal may define the rank.

[0063] According to some embodiments, the rank of a block proposal may depend on randomness beacons. For example, the node rank of a corresponding node may depend on randomness beacons.

[0064] According to some embodiments, individual nodes of a notarization subset may attempt to perform individual notarization signatures for a given notarization round, but only for one value proposal from that round.

[0065] Such embodiments can also be combined with the ranking described above. More specifically, according to such embodiments, a node may perform individual notarized signatures only for the highest-ranked value proposals.

[0066] This could further increase the success rate of the finality procedure.

[0067] According to some embodiments, the node may first wait for a waiting period to expire, which may be referred to below as a timeout period, then evaluate which of the value proposals received so far is of the highest rank, and then perform a notarized signature for it.

[0068] A node may perform a second notarized signature only if it receives a value proposal of a higher rank than the last value proposal already signed in the same notarization round.

[0069] To notarize a value proposal, according to some embodiments, it is necessary to satisfy a predefined set of notarization rules. This predefined set of notarization rules may, in particular, specify that a predefined number of individual notarized signatures are required. Thus, a network, in particular a subset of notarization nodes, can observe whether the value proposal satisfies this requirement. This predefined set of notarization rules may be presented as a fourth set of rules.

[0070] According to some embodiments, individual notarized signatures can be communicated, particularly within a network, and especially within nodes of a notarized subset, for example, by a gossip protocol to an unspecified number of recipients. According to another embodiment, individual notarized signatures can be communicated to a central authority that collects notarized signatures and performs sufficient notarization.

[0071] The predefined number of individual notarized signatures may depend on the security requirements of each distributed network. A node, upon observing a predefined number of individual notarized signatures, can notarize the corresponding value proposals, creating a fully notarized value proposal. This can be done by internally marking (flacking) the corresponding value proposals.

[0072] According to some embodiments, this may include performing a threshold signature recovery mechanism or a multi-signature aggregation mechanism for individual notarized signatures.

[0073] A signature corresponding to notarizing a value proposal and creating a fully notarized value proposal may, according to some embodiments, be presented as a fully notarized signature.

[0074] According to some embodiments, full notarization of a value proposal may represent confirmation of a subset of notarization that the value proposal conforms to a set of validity rules, in particular that the corresponding parent value proposal is fully notarized.

[0075] Therefore, notarizing a value proposal can be defined, according to several embodiments, as a notarization subset confirming that the value proposal conforms to a set of validity rules.

[0076] According to some embodiments, sufficient notarization of a value proposal may represent confirmation of a notarized subset that the value proposal is deemed favorable by that notarized subset.

[0077] In the next step, the nodes of the notarized subset perform integrity checks. According to some embodiments, integrity checks are performed on value proposals from one notarized round to the current notarized round. According to some embodiments, integrity checks can be defined as a check to see if a value proposal conforms to a predefined set of integrity rules. These sets of integrity rules differ from a set of validity rules and may be specified, for example, as part of the specifications of a distributed network. A set of consistency rules may specify specific rules for nodes in a notarial subset. According to these rules, one or more value proposals in a notarial round are considered consistent or inconsistent with their own individual notarial signatures performed in the current notarial round. In this regard, a consistency check of a given value proposal can be defined as a check that examines the relationship between the given value proposal and the value proposals individually signed by notaries by the nodes in the current notarial round.

[0078] According to one embodiment, a set of integrity rules may specify that only fully notarized value proposals may be considered consistent. In other words, a node may perform integrity signing only on fully notarized value proposals.

[0079] The implication of this rule is that a value proposal is automatically notarized once it receives a certain minimum number of consistency signatures. The advantage of this is that network nodes outside the notarization subset can skip verifying that the value proposal is notarized. The node only needs to ensure that there are a sufficient number of consistency proofs. This can reduce the total verification work performed by the distributed network. This can also enable verification by observers outside the distributed network who do not have access to the notarized signatures.

[0080] According to one embodiment, a value proposal is considered consistent with a set of consistency rules if, in the current notarization round, each node of the notarization subset does not perform individual notarization signatures that would conflict with the value proposal. In such an embodiment, the set of consistency rules may define certain scenarios in which a value proposal is not considered consistent. Such scenarios that define a conflict include, for example, ambiguity. For example, if each node individually notarizes each of several value proposals in the current notarization round, this creates ambiguity.

[0081] On the other hand, if each node in the notarization subset performs up to one separate notarization signature for any value proposal from the current notarization round in the current notarization round, the value proposals in the current notarization round may be considered consistent according to a set of consistency rules.

[0082] In other words, if each node in the notarization subset has not performed individual notarization signatures on any value proposal other than its own in the current notarization round, then that value proposal may be considered consistent with a set of consistency rules.

[0083] According to another embodiment, if each node of the notarization subset refers retrospectively to value proposals from previous notarization rounds when all value proposals that have undergone individual notarization signatures in the current notarization round are referenced to value proposals from previous notarization rounds, then the value proposals from previous notarization rounds may be considered consistent according to a set of consistency rules.

[0084] "Referring retrospectively" can mean a direct or indirect link established by including a hash digest of a valuation proposal from a previous notarization round in a valuation proposal from a later notarization round.

[0085] According to one embodiment, when all value proposals in the current notarization round, for which a node has performed individual notarization signatures, are linked retrospectively to value proposals under consistency checks, a set of consistency rules may define the value proposals under consistency checks as consistent from the perspective of the nodes in the notarization subset. Here, the retrospective linking can be performed through one step (direct) or multiple steps (indirect).

[0086] In such embodiments, the term “previous notarization round” means one or more of the previous notarization rounds, which may include the last notarization round, the second to last notarization round, the third to last notarization round, and so on. In other words, in such embodiments, a value proposal conforms to a set of consistency rules, when each node indicates a common parent of all value proposals that performed individual notarization signatures in the current notarization round.

[0087] According to some embodiments, a integrity-signed value proposal comprises a notarization round number to be finalized, a current notarization round number, and a signing node. More specifically, the integrity check and the performed integrity signature, according to some embodiments, are valid only for a specific combination of the current notarization round and the notarization round to be finalized.

[0088] According to some embodiments, a distributed network, in particular multiple nodes, specifically multiple nodes in the next notarization round, may move to the next notarization round in that manner once the fully notarized value proposal of the current notarization round is observed. As described above, a notarization subset may change from one notarization round to the next, and the new notarization subset may use adherence to a fully notarized value proposal as a trigger to initiate a notarization round.

[0089] According to some embodiments, once each node sends its integrity signature, the next notarization round may proceed if that node is a member of the notarization subset of the next notarization round.

[0090] The finality procedure of a given notarization round can be carried out in parallel with subsequent notarization rounds.

[0091] During the finality procedure, the nodes of the distributed network, particularly the notarized subset, observe whether the value proposal satisfies a predefined set of finality rules.

[0092] According to one embodiment, a set of finality rules are satisfied when a predefined number of consistency signatures are observed for a value proposal. Thus, the nodes of the notarization subset observe the number of consistency signatures performed on a value proposal in an unfinalized notarization round. A predefined number of consistency signatures are required to finalize a value proposal. Finalizing a value proposal means, according to some embodiments, that the distributed network or a notarization subset acting on behalf of the distributed network considers the value proposal final, i.e., that the notarization subset agrees to add the value proposal to the sequence of values.

[0093] Therefore, the network, and in particular the nodes of the notarized subset, can observe whether the value proposal has received sufficient integrity signatures. According to some embodiments, integrity signatures can be communicated, for example, by a gossip protocol, particularly within the network, and particularly among the nodes of the notarized subset.

[0094] The number of predefined integrity signatures may depend on the security needs of each distributed network. When a node observes a predefined number of integrity signatures, it may finalize the corresponding value proposal and flag it as a finalized value. This can be done, according to some embodiments, by performing a threshold signature scheme, a multi-signature scheme, or an aggregate signature scheme on the corresponding value proposal. The corresponding signature may be presented as a finality signature. Such a finality signature may be added to the value sequence, indicating that the value proposal is final and providing confirmation of a notarized subset.

[0095] According to another embodiment, a value proposal may satisfy a set of finality rules only after a predefined number of consistency signatures are observed in the value proposal and the value proposal has been fully notarized. Thus, according to such an embodiment, two criteria must be observed: sufficient notarization requires a number of individual notarized signatures different from the number of consistency signatures required.

[0096] According to some embodiments, a distributed network not only confirms value proposals that have received the required number of consistent signatures, but the distributed network or notarized subset may also add an implicit sequence implied by its confirmed value to the sequence. Such an implicit sequence may comprise all value proposals that the final value proposal references retrospectively. "References retrospectively" can mean a direct or indirect link established by including hash digests of value proposals from previous notarization rounds in value proposals from later notarization rounds.

[0097] According to some embodiments, the finalization procedure may not succeed in a given notarization round. More specifically, finalization may fail for all value proposals in a particular notarization round if the required number of consistency signatures has not been reached. This is due to the design in some embodiments. More specifically, one value proposal in a notarization round is subsequently added to the value sequence by becoming part of an implicit sequence.

[0098] An advantage of some embodiments of the present invention is that, given a notarization round, even if the value proposal is not finalized, subsequent notarization rounds can still proceed without being hindered.

[0099] An advantage of some embodiments of the present invention is that, when the finalization of a valuation proposal is slow or delayed in a given notarization round, subsequent notarization rounds can proceed asynchronously without waiting for the valuation proposal of the given notarization round to be finalized.

[0100] According to one embodiment, a network may be configured for the security assumptions or security needs of each of the networks. More specifically, a distributed network may be designed based on the security assumption that in all notarized subsets, at most f nodes are Byzantine and the remaining nodes are legitimate.

[0101] Next, according to some embodiments, the network may be configured to select n, a number of nodes in a notarized subset; t1, a predefined number of individual notarized signatures required to notarize the value proposal and create a fully notarized value proposal; and t2, a predefined number of integrity signatures required to satisfy the set of finality rules and finalize the value proposal according to the formula: t1 + t2 > n + f.

[0102] Such embodiments allow for the adjustment of predefined numbers t1 and t2, as well as the number n of notarized subset nodes, taking into account the respective security needs or assumptions of the network. In particular, such embodiments can ensure successful finality procedures for different security assumptions of the network.

[0103] According to another embodiment of the present invention, a computer-implemented method is provided for forming a consensus, in particular, on blocks to be written to a blockchain, as a sequence of values.

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

[0105] According to another embodiment of the present invention, a computer program product for operating a distributed network is provided. The computer program product comprises a computer-readable storage medium in which materialized program instructions are stored. Program instructions that can be executed by one or more of the nodes of the distributed network cause one or more of the nodes to perform a step of an embodiment of the method of the present invention.

[0106] According to another embodiment 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 includes program instructions that can be executed by one or more of the nodes, causing one or more of the nodes to carry out a method comprising the steps of each embodiment of the method of the present invention.

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

[0108] Other advantageous embodiments are described in the dependent claims and in the following description.

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

[0110] [Figure 1] Figure 1 is an exemplary diagram of a distributed network according to one embodiment of the present invention. [Figure 2] Figure 2 shows a more detailed view of the computing units that run on a typical node in the network. [Figure 3] Figure 3 is an exemplary diagram of a distributed network according to one embodiment of the present invention, which includes multiple subnets. [Figure 4] Figure 4 is a diagram that shows the computing units running in the distributed network of Figure 3 in more detail. [Figure 5] Figure 5 is a schematic diagram of inter-subnet messages received in the subnet of the network shown in Figure 3. [Figure 6] Figure 6 is a schematic block diagram of the protocol components of a subnet protocol client. [Figure 7] Figure 7 is a diagram illustrating the workflow of the message protocol, consensus protocol, and related components. [Figure 8] Figure 8 is a diagram showing an application unit according to one embodiment of the present invention in more detail. [Figure 9] Figure 9 shows the main processes performed at each node of a network according to one embodiment of the present invention. [Figure 10] Figure 10 shows a layer model illustrating the main layers involved in message exchange between and within subnets. [Figure 11] Figure 11 shows the generation of an input block by a consensus component according to an exemplary embodiment of the present invention. [Figure 12]Figure 12 is a diagram showing the networking components in more detail. [Figure 13] Figure 13 is a flowchart showing each step of a computer-implemented method according to several embodiments of the present invention. [Figure 14] Figure 14 is a flowchart showing each step of a computer-implemented method according to several embodiments of the present invention. [Figure 15] Figure 15 is a timing diagram illustrating the periods of the notarization round and the finalization round according to one embodiment of the present invention. [Figure 16] Figure 16 is a timing diagram illustrating the duration of the notarization round and the finalization round according to another embodiment of the present invention. [Figure 17] Figure 17 is a flowchart / timing diagram illustrating six consecutive notarization rounds. [Figure 18] Figure 18 shows an exemplary embodiment of a node according to the present invention. [Figure 19a] Figure 19a shows an asynchronous communication model and the corresponding asynchronous consensus mechanism. [Figure 19b] Figure 19b shows an asynchronous communication model and the corresponding asynchronous consensus mechanism. [Figure 20] Figure 20 is a timing diagram showing a communication scheme for communicating value propositions according to several embodiments of the present invention. [Figure 21] Figure 21 is a timing diagram illustrating the duration of the notarization round and the finalization round according to another embodiment of the present invention. [Modes for carrying out the invention]

[0111] <Mode for executing the invention> First, we will introduce some general aspects and embodiments of the present invention.

[0112] According to one embodiment, 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. Each node allocates computing resources, and the distributed network may use specific distributed computing techniques.

[0113] According to one embodiment, a distributed network can be embodied as a blockchain network. The term "blockchain" encompasses all forms of electronic ledgers, computer-based ledgers, and distributed ledgers.

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

[0115] The distributed network 100 comprises a plurality of nodes 10, which may also be referred to as network nodes 10 or computing nodes 10. Each of the plurality of nodes 10 is configured to run one or more computing units. According to one embodiment, the computing units should be understood as part of the software, in particular having or possessing its own unit state as part of the software.

[0116] Multiple nodes 10 in network 100 may be assigned to different subsets and / or subnets. Such assignments may change over time.

[0117] According to this embodiment, the network 100 comprises a consensus subset SS1 of node 10 and an execution subset SS2 of node 10.

[0118] Computing units running on multiple nodes 100 may be used by users of network 100 to perform or request computing tasks or services, in particular application services. Computing units of network 100 may perform execution messages from a current set of execution messages, in particular execution messages. Execution messages may include, in particular, inter-unit messages exchanged between computing units of the network, and / or input messages, i.e., messages received from external sources, in particular from users of the network. Network 100 is configured such that a consensus protocol is first performed to form an agreement on the selection and processing order of execution messages from each current set of execution messages. Depending on the number of nodes 10 in network 100, the consensus protocol is favorably performed not by all nodes of the network, but only by a subset of the nodes 10 of network 100, which is hereafter referred to as consensus subset SS1. Consensus subset SS1 may be referred to as consensus subset. Thus, the nodes of consensus subset SS1 are configured to perform the consensus protocol to form an agreement on the selection and processing order of execution messages from a current set of execution messages.

[0119] The execution of an execution message may also be advantageously performed not by all nodes of network 100, but only by a subset of nodes 10 of network 100. This subset is shown below as execution subset SS2.

[0120] Next, the computing units of the execution subset SS2 individually select the execution messages in the processing order agreed upon in the previous consensus step. Each computing unit of the execution subset SS2 performs the execution in a deterministic manner, thereby changing the unit state of the corresponding computing unit of the execution subset SS2.

[0121] According to one embodiment, the unit state must be understood as all data or information used by the compute unit, in particular not only the data that the compute unit stores in variables, but also the data that the compute unit retrieves from remote calls. The unit state may, in particular, represent specific storage locations in each storage location of each node. The contents of these storage locations are referred to as the unit state, according to the embodiment, at any point in the execution of the compute unit. The compute unit may, in particular, be embodied as a stateful compute unit; that is, the compute unit is designed according to the embodiment to store preceding events or user interactions.

[0122] In some embodiments, each node in the network is assumed to follow a local clock that is roughly synchronized with the clocks of the other nodes.

[0123] Figure 2 shows the computing units 15 running on node 10 of network 100 in more detail. More specifically, it shows node 10 of subset SS2 of Figure 1 where five computing units 15 are running. More specifically, these five computing units 15 are a set of computing units CU21, CU22, CU23, CU24, and CU25. The set of computing units CU21, CU22, CU23, CU24, and CU25 runs on each node 10 of subset SS2. Furthermore, the set of computing units CU21, CU22, CU23, CU24, and CU25 is replicated throughout subset SS2, and when each of the computing units CU21, CU22, CU23, CU24, and CU25 behaves honestly, they will eventually reach the same unit state. This can be implemented, in particular, by performing active replication in the unit state space of computing units CU21, CU22, CU23, CU24, and CU25 at each of the 10 nodes in subset SS2.

[0124] Computation units (CUs) can provide a variety of functions and can be of various types. One type of computing unit is an application computing unit configured to provide application services to users of a distributed network. For simplicity, application computing units will be referred to as application units or AUs below. Another type of computing unit is a wallet computing unit, which may be configured to manage user currency accounts for users of the network. And yet another type of computing unit is a system computing unit. Such system computing units may provide system or administrative functions to a distributed network.

[0125] Figure 3 shows an exemplary block diagram of a distributed network 300 according to one embodiment of the present invention.

[0126] The distributed network 300 comprises multiple nodes 10.

[0127] According to this embodiment, multiple nodes 10 are distributed across multiple subnets 11. In the example in Figure 1, four subnets 11 are provided, indicated as SNA, SNB, SNC, and SND. The network 100 comprises communication links 12 for intra-subnet communication within each subnet 11 and communication links 13 for inter-subnet communication between different subnets of subnet 11. Thus, communication links 12 may also be indicated as intra-subnet or peer-to-peer (P2P) communication links, and communication links 13 may also be indicated as inter-subnet or subnet-to-subnet (SN2SN) communication links.

[0128] Each of the multiple subnets 11 is configured to run a set of computing units on each node 10 within that subnet 11.

[0129] According to some embodiments of the present invention, subnet 11 is configured to replicate a set of computing units across each subnet 11. More specifically, subnet 11 is configured to replicate the unit state of the computing units across each subnet 11.

[0130] Distributed networks 100 and 300 can be embodied, in particular, as networks configured to run an asynchronous BFT consensus protocol. In such networks, since it is assumed that fewer than one-third of each subnet are corrupted nodes, the artifacts generated and signed by the subnets are sufficiently reliable.

[0131] Figure 4 shows a more detailed view of the compute units 15 running on node 10 of network 300. More specifically, on the left side 401 of Figure 4, node 10 of the subset SNA of Figure 1 is shown, where five compute units 15 are running. More specifically, the five compute units 15 are a set of compute units CUA1, CUA2, CUA3, CUA4, and CUA5. This set of compute units CUA1, CUA2, CUA3, CUA4, and CUA5 runs on each node 10 of the subnet SNA. Furthermore, this set of compute units CUA1, CUA2, CUA3, CUA4, and CUA5 is replicated across the subnet SNA so that each compute unit CUA1, CUA2, CUA3, CUA4, and CUA5 has the same unit state. This can be implemented, in particular, by performing active replication in the unit state space of compute units CUA1, CUA2, CUA3, CUA4, and CUA5 on each of the 10 nodes of the subnet SNA.

[0132] Furthermore, on the right side of Figure 4, 402, is shown node 10 of the subnet SNB in ​​Figure 1, where the four computing units 15 are running. More specifically, the four computing units 15 are a set of computing units CUB1, CUB2, CUB3, and CUB4. The set of computing units CUB1, CUB2, CUB3, and CUB4 runs on each node 10 of the subnet SNB. In addition, the set of computing units CUB1, CUB2, CUB3, and CUB4 is replicated across the subnet SNB so that each of the computing units CUB1, CUB2, CUB3, and CUB4 has the same unit state. Active replication is performed in the space of unit states as described above.

[0133] Referring back to Figure 3, the network 300 is configured to exchange intersubnet messages 16 between subnets SNA, SNB, SNC, and SND via a messaging protocol and a consensus protocol. The consensus protocol is configured to reach an agreement on the processing order of the intersubnet messages 16 in each receiving subnet. For example, for subnet SNB, this refers to receiving intersubnet messages 16 from subnets SNA, SNB, SNC, and SND. The consensus protocol receives and processes these intersubnet messages 16 and executes a defined consensus algorithm or consensus mechanism to reach an agreement on the processing order of the received intersubnet messages 16.

[0134] According to some embodiments, the network 300 may be configured to run separate consensus protocols in each subnet. That is, each of the subnets SNA, SNB, SNC, and SND runs its own consensus protocol independently of the other subnets. Thus, each of the subnets SNA, SNB, SNC, and SND can determine the order in which to process messages, within a defined range, independently of the other subnets that have received them. Hence, each of the subnets SNA, SNB, SNC, and SND forms an agreement on a subnet-by-subnet basis based on the processing order of the inter-subnet messages 16 that they have received. Such a consensus may be considered a local consensus or a subnet consensus.

[0135] This concept is illustrated in more detail in Figure 5.

[0136] Figure 5 shows a schematic diagram of the inter-subnet message 16 received by the SNB of subnet 11 in Figure 3.

[0137] The subnet SNB receives intersubnet messages SNA-SNB from subnet SNA, SNC-SNB from subnet SNC, and SND-SNB from subnet SND. This pool of intersubnet messages is processed by the CSNB, which is a consensus component 30 that locally executes the consensus protocol in the subnet SNB. Therefore, the consensus component 30 can be referred to as the subnet consensus component.

[0138] The consensus component 30 generates a queue of input block IBs from inter-subnet messages according to a predefined consensus algorithm or mechanism, provides the queue of input block IBs to an MSNB configured to execute a messaging protocol, and performs further processing of the input block IBs.

[0139] According to some embodiments, each node 10 in each subnet 11 can participate in a consensus protocol. According to such embodiments, each subnet 11 comprises, for example, 10 to 100 nodes, and in particular, 20 to 50 nodes. Such a number can provide a favorable compromise between security and efficiency.

[0140] According to several other embodiments, the consensus protocol may be configured to elect committee members from multiple nodes 10 in each subnet 11 according to a predefined election scheme, and to run the consensus protocol only with the elected committee members. Such an approach is particularly useful in subnets with a large number of nodes, for example, subnets with 1000 or more nodes.

[0141] Figure 6 shows a schematic block diagram of the protocol component 600 of a subnet protocol client, for example, subnet protocol client 42 shown in Figure 1.

[0142] The solid arrows in Figure 6 relate to execution messages, which consist of inter-unit messages and ingress messages. Input messages can be change queries, particularly from the user. The dashed arrows relate to system information.

[0143] The protocol component 600 comprises a message component 61 configured to execute a messaging protocol, and an execution component 62 configured to execute an execution protocol, which executes execution messages, in particular inter-unit messages and / or modifies queries. The protocol component 600 further comprises a consensus component 63 configured to execute a consensus protocol, a networking component 64 configured to execute a networking protocol, a state management component 65 configured to execute a state management protocol, an X-Net transport component 66 configured to execute a cross-subnet transport protocol, and an ingress message handler component 67 configured to process ingress messages received from external users of the network. The protocol component 600 further includes a cryptographic component 68. The cryptographic component 68 cooperates with a security component 611, which may be embodied as a security application 43, as will be described later with reference to Figure 16, for example. The protocol component 600 further comprises a state reader component 69 configured to receive read queries, or in other words, read requests from users.

[0144] The state reader component 69 is configured to cooperate with the state management component 65.

[0145] Read queries received and processed by the state reader component 69 are embodied as non-modification queries, in particular, that do not permanently change the unit state of the compute units. On the other hand, ingress messages received from the ingress message handler component 67 and passing through the consensus component 63 can be embodied as modification queries, in particular, that modify the unit state of each compute unit executing a modification query. Since read queries do not need to pass through the consensus component 63, they can be executed asynchronously on any node in each subnet and are therefore much faster.

[0146] Furthermore, the subnet protocol client 42 may cooperate with a leader component 610, which may be part of the mainnet protocol client 41, as illustrated with reference to Figure 6. The mainnet leader component 610 may provide information stored by the mainnet and distributed to each subnet protocol client 42. This includes the assignment of nodes to subnets, the public keys of the nodes, and the assignment of compute units to subnets.

[0147] The message component 61 and the execution component 62 are configured so that all calculations, data, and state within these components are identically replicated across all nodes in their respective subnets, more specifically, across all honest nodes in their respective subnets. This is illustrated by the waveform background of these components.

[0148] Such identical copies are achieved, on the one hand, thanks to a consensus component 63, which ensures that the stream of input to the message component 61 is agreed upon by each subnet and therefore identical by all nodes, more specifically by all honest nodes. On the other hand, this is achieved by configuring the message component 61 and the execution component 62 to perform deterministically replicated computations.

[0149] The X-Net forwarding component 66 sends a message stream to another subnet and receives a message stream from another subnet.

[0150] Most components access the cryptographic component 68 to execute cryptographic algorithms and the mainnet reader 610 to read configuration information.

[0151] The execution component 62 receives the unit status of the compute unit and incoming messages from the message component 61, and returns the outgoing messages of the compute unit and the updated unit status. While performing this computation, the gas or fuel consumption of the processed messages (queries) can be measured.

[0152] The message component 61 synchronizes with the input blocks received from the consensus component 63. That is, for each input block, the message component 61 performs the following steps: It parses each input block to obtain the message for its compute unit. It then routes the message to the respective input queues of different compute units and plans the messages to be executed by the scheduler according to the capacity allocated to each compute unit. Next, it uses the execution component 62 to process the message by the corresponding compute unit and adds the resulting message to the output queue of the respective compute unit. However, if the message is destined for a compute unit on the same subnet, it may be placed directly into the input queue of the corresponding compute unit. Finally, the message component 61 routes the messages in the compute unit's output queue to the message stream of the subnet where the receiving compute unit is located, and forwards these message streams to the state management component 65 for authentication, i.e., signed by the respective subnet.

[0153] The state management component 65 includes an authentication component 65a. The authentication component 65a is configured to authenticate the output streams of each subnet. This can be done, for example, by group signing of the compute units of each subnet.

[0154] The authentication component 65a may be further configured to authenticate specific variables of the unit state, in particular, specific variables of the unit state snapshot, as will be described in more detail below.

[0155] Figure 7 illustrates the workflow 700 of the message protocol and consensus protocol, as well as related components, such as the message component 61 and consensus component 63 in Figure 6. More specifically, Figure 7 visualizes the workflow of inter-subnet messages exchanged between the subnet SNB and subnet SNAs and SNCs. Furthermore, the subnet SNB exchanges input messages with multiple users U.

[0156] Starting from the lower right of Figure 7, multiple input streams 701, 702, and 703 are accepted by the consensus component 63. The consensus component 63 is a subnet consensus component executed by the subnet client of the subnet SNB. Input stream 701 contains an intersubnet message 711 from subnet SNA to subnet SNB. Input stream 702 contains an intersubnet message 712 from subnet SNC to subnet SNB. Input stream 703 contains input messages 713 from multiple users U to subnet SNB.

[0157] Inter-subnet messages 711 and 712 include inter-unit messages exchanged between compute units on different subnets, as well as signaling messages. Signaling messages are used to confirm whether the reception of an inter-unit message has been acknowledged. Message component 61 is configured to send signaling messages from the receiving subnet to the corresponding transmitting subnet, i.e., from subnet SNB to subnets SNA and SNC in this example. According to this example, message component 61 is configured to store transmitted inter-unit messages until an acknowledgment message is received for each inter-unit message. This ensures communication.

[0158] The consensus component 63 is configured to receive and process intersubnet messages 711, 712 of subnets SNA and SNC, and input message 713 with user U, and to generate a queue of input blocks 720 from the intersubnet messages 711, 712 and input message 713 according to a predefined consensus mechanism performed by the corresponding consensus protocol. Each input block 720 generated by consensus contains a set of input messages 713, a set of intersubnet messages 711, 712, and an EP which is an execution parameter 714. The EP which is an execution parameter 714 may include, in particular, a random seed, a specified execution time, and / or a height index. The consensus component 63 may also vary the number of messages in all input blocks based on the current load of the subnets.

[0159] The consensus component 63 then provides the queue of input block 720 to the message component 61. The message component 61 is configured to execute a message protocol to process the input block 720.

[0160] The message protocol and message component 61 synchronize with the input block 720 received from the consensus component 63.

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

[0162] According to some embodiments, input checks may be performed at different levels of granularity. First, input checks may be performed on the entire input block. Such checks may be referred to as input block checks. These may include a check of the height of the next input block. If the height of the next input block is lower than the height expected in the next order, it is discarded. If the input block is not scheduled in the next order, the message component 61 may invoke the node catch-up protocol. If the input block is present in the next order, it is further processed by the message component 61.

[0163] Various types of messages within an input block (signal messages, ingress messages, inter-unit messages) can be grouped together.

[0164] Input validation may further include overload checks to verify whether the message component is currently overloaded and does not have sufficient capacity to perform processing. For example, if the relevant queue in the induction pool becomes full, the corresponding message may be rejected. Further input checks may include sequential delivery checks. To satisfy the sequential delivery requirement, annotations on the message, such as the addition of a sequence number, may be made. If a message with a sequence number is received, the message component 61 may check whether it has the expected number, and if not, it may be rejected. Furthermore, the input check component 740 may perform validation of the target destination, i.e., validation of whether the message is intended for a compute unit that is active in the corresponding subnet.

[0165] If the input check is successful, the messages in each input block 720 may be further processed by the message component 61. The corresponding messages may then be added to the corresponding queue in the induction pool of the induction pool component 731.

[0166] Generally, the message component 61 pre-processes the input block 720 by appropriately placing ingress messages, signaling messages, and inter-subnet messages into the induction pool component 731. Signaling messages in the incoming subnet stream are treated as acknowledgments of messages in the output queue and can then be discarded.

[0167] In this example, the induction pool component 731 includes inter-unit queues A1-B1, C1-B1, A2-B2, and C1-B2, as well as user-to-unit queues U-B1 and U-B2.

[0168] Following these preprocessing steps, the message component 61 invokes the execution component 62 (see Figure 6) to run as many induction pools as possible during a single execution cycle, providing a specified execution time and a random seed as additional inputs. Following that execution cycle, the resulting output queue of messages is fed to the output queue component 733. Initially, the output queue component 733 comprises inter-unit output queues and unit-to-user output queues. In this example, the inter-unit output queues are B1-A1, B1-C2, B2-A2, and B2-C3, and the unit-to-user output queues are B1-U1 and B2-U4. As an example, message B1-A1 represents a message from compute unit B1 of subnet SNB to compute unit A1 of subnet SNA. As another example, message B1-U1 represents a message from compute unit B1 of subnet SNB to user U1.

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

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

[0171] The message component 61 revolves around deterministically changing specific parts of the system state. In each round, the execution component 61 executes specific messages from the induction pool by reading and updating the state of each compute unit, and returns the outgoing messages that the executed compute unit wants to send. These messages enter the output queue component 733, which initially contains unit-to-user and inter-unit messages between compute units in the network. Intra-subnet messages between compute units in the same subnet can be routed and delivered internally within each subnet, while inter-subnet messages are routed to an output stream sorted by subnet destinations.

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

[0173] Figure 8 shows an exemplary application (computation) unit 800 according to one embodiment of the present invention.

[0174] The application unit 800 includes an input queue 801, an output queue 802, a user or application state 803, and a system state 804.

[0175] (In a given subnet) all input queues 801 of an application unit aggregate to form an induction pool, but the input queues are part of the state of the application compute unit. Output queues 802 contain messages that may need to be delivered to other application compute units, possibly in other subnets.

[0176] Application state 803 includes a main web assembly (Wasm) module that implements the functionality of the application computing unit and its associated modules, along with examples of each module. Examples of Wasm modules consist of memory, global variables, and tables.

[0177] System state 804 cannot be freely modified by the application compute unit's code. This includes metadata, other state maintained by the system on behalf of the application compute unit, particularly compiled Wasm modules, and the context and callbacks for unprocessed messages.

[0178] Figure 9 shows the main processes performed at each node 10 of network 100 and network 300 according to one embodiment of the present invention. A network client of a network according to some embodiments of the present invention is a set of protocol components necessary for node 10 to join the network. According to some embodiments, each node 10 is a member of the mainnet, typically a subnet, which means that each node runs as a client of the mainnet or a client of the subnet.

[0179] The node manager 40 is configured to start, restart, and update the mainnet protocol client 41, the subnet protocol client 42, and the security application 43.

[0180] According to some embodiments, each of the multiple subnets 11 is configured to run a separate subnet protocol client 42 on the corresponding node 10. The mainnet protocol client 41 is configured, in particular, to distribute configuration data among the multiple subnets 11. The mainnet protocol client 41 may be configured, in particular, to run only system compute units and not user-provided compute units. The mainnet protocol client 41 is a local client of the mainnet, and the subnet protocol client 42 is a local client of the subnet.

[0181] The security application 43 stores the private keys of node 10 and uses them to perform all operations.

[0182] The security application 43 is configured to protect the private key held by the node. More specifically, the private key is held and processed in a separate execution environment (either a separate process or a separate virtual machine (VM)). The security application 43 is configured to operate through restricted and controlled interfaces so that the private key cannot be extracted through these interfaces. According to some embodiments, the security application is configured to operate like, or similar to, a hardware security module (HSM). Thus, the security application 43 may be represented as a software HSM.

[0183] Figure 10 shows a layer model 1000 illustrating the main layers involved in the exchange of inter-subnet and intra-subnet messages. Layer model 1000 includes a messaging layer 51 configured to function as a higher layer for inter-subnet communication. More specifically, the messaging layer 51 is configured to route inter-subnet messages between compute units in different subnets. Furthermore, the messaging layer 51 is configured to route ingress messages from network users to compute units in the network.

[0184] The layer model 1000 further includes multiple consensus layers 52 configured to receive intersubnet messages and ingress messages from different subnets and, in particular, to agree on a processing order, organize them into a series of input blocks that are then further processed by their respective subnets.

[0185] The consensus layer 52 may be configured in particular to facilitate agreement on a set of values, such as those described above and below. In this regard, the sequence of values ​​may be embodied as a sequence of input blocks as described above.

[0186] Furthermore, the layer model 1000 includes a peer-to-peer (P2P) layer 53 configured to organize and drive communication between nodes in a single subnet.

[0187] According to some embodiments, the network may include several further layers, in particular, execution layers configured to execute execution messages in the network's computing units.

[0188] A more detailed description of the interaction between the mainnet protocol client 41 and the subnet protocol client 42 is given below (see Figure 16). The mainnet protocol client 41 manages several registries containing subnet configuration information. These registries are implemented by the mainnet's computing units, and since all nodes participate in the mainnet, access to these registries can be easily implemented through state read operations.

[0189] In other words, the mainnet reader 610 (see Figure 6) can actually be a subcomponent of the mainnet protocol client 41. Therefore, interaction with this component results in interaction between two isolated environments where the mainnet and subnet clients are running.

[0190] Figure 11 illustrates the creation of blocks in a distributed network according to several embodiments of the present invention. Blocks may, in particular, be input blocks 720 shown in Figure 7. These are created by a consensus component 63 that runs a consensus protocol, specifically a local subnet consensus protocol.

[0191] In this exemplary embodiment, three input blocks 1101, 1102, and 1103 are shown. Block 1101 contains multiple transactions, namely transaction tx1.1, transaction tx1.2, and possibly further transactions indicated by a dot. Block 1102 also contains multiple transactions, namely transaction tx2.1, transaction tx2.2, and possibly further transactions indicated by a dot. Block 1103 also contains multiple transactions, namely transaction tx3.1, transaction tx3.2, and possibly further transactions indicated by a dot. The input blocks 1101, 1102, and 1103 are chained. More specifically, each block contains the block hash of the previous block. This cryptographically links the current block to the previous block.

[0192] According to some embodiments, transactions may be inter-subnet messages, ingress messages, and signaling messages.

[0193] Input blocks 1101, 1102, and 1103 establish blockchain 1100. According to some embodiments, input blocks 1101, 1102, and 1103 may be created by a method of forming a consensus on the sequence of values ​​described above and below.

[0194] As a result, input blocks 1101, 1102, and 1103, which form blockchain 1100, establish a specific embodiment of the value sequence.

[0195] However, it should be noted that, according to some embodiments, the input blocks generated by the consensus components do not need to be chained. Rather, any consensus protocol that reaches some kind of agreement among the subnet nodes regarding the order in which received messages are processed can be used, according to the embodiment.

[0196] Figure 12 shows a networking component 1200 configured to execute a networking protocol in more detail. Networking component 1200 may be, for example, a more detailed embodiment of networking component 64 shown in Figure 6. Networking component 1200 comprises a unicast component 1210 configured to perform inter-node communication, a broadcast component 1220 configured to perform intra-subnet communication, and a cross-net component 1230 configured to perform inter-subnet communication.

[0197] Figures 13 and 14 show flowcharts of each step of a computer implementation method according to several embodiments of the present invention. According to this exemplary embodiment, the sequence of values ​​is assumed to be embodied as a blockchain, or in other words, as a sequence of blocks of a blockchain.

[0198] More specifically, Figure 13 shows the method steps for the notarization round of this method, and Figure 14 shows the steps for the finality procedure, including the finalization round.

[0199] The method performed on the computer may, for example, be carried out by distributed network 100 or distributed network 300, as described above.

[0200] The steps of the notarization round and the finality procedure can be performed asynchronously.

[0201] Referring now to Figure 3, in step 1310, this method begins, for example, with the first notarization round of notarization round number N.

[0202] Next, in step 1320, one or more network nodes in the network create a block proposal to be added to or written to a blockchain, for example, as described with reference to Figure 11.

[0203] Next, the block proposal is communicated within the network, in particular to a subset of nodes, which are shown below as a notarized subset. This communication may be carried out, in particular, by distribution to an unspecified number of recipients, in particular by a gossip protocol.

[0204] In step 1330, each node in the notarized subset validates the block proposal it received as a result of the communication. The validation includes, in particular, checking whether the received block proposal conforms to a predefined set of validation rules. The set of validation rules may be specified as part of the distributed network specification.

[0205] According to some embodiments, validation may, for example, verify the block header of an received block proposal to determine that each block proposal originates from a known node. Such verification is referred to as shallow validation.

[0206] In other embodiments, validation may involve verifying the payload of the block proposal, i.e., verifying whether the payload conforms to predefined criteria. This is referred to as deep validation.

[0207] According to some embodiments, the validation (shallow or deep) of a given block proposal may depend on block proposals from previous notarization rounds that the given block proposal retrospectively references / links to. For example, a validation check may examine whether all previous block proposals referenced by a particular block proposal have been notarized.

[0208] Step 1330 may be performed, in particular, during the timeout period.

[0209] Step 1330 may only be executed after a timeout period.

[0210] Next, in step 1340, the notarized subset node performs individual notarized signatures on the subset of block proposals that are valid according to the validation check. Such individual notarized signatures are single-node signatures that confirm that the block proposals have passed the validation check performed by the node. Thus, individual notarized signatures can also be referred to as individual validation signatures. As a result, individually notarized block proposals are created.

[0211] The nodes of the distributed network, particularly the notarized subset, observe whether a predefined number of individual notarized signatures have been performed for one of the block proposals. In particular, individual notarized signatures can be distributed to an unspecified number of nodes in the notarized subset, for example, by a gossip protocol. This can be done, for example, by a P2P layer as shown in Figure 10.

[0212] In this case, the distributed network fully notarizes the corresponding block proposal in step 1350. This creates a fully notarized block proposal for each notarization round. A predefined number can be chosen depending on the security needs of the application. According to some embodiments, this number may correspond to more than two-thirds (2 / 3) of the nodes in the notarization subset.

[0213] Once one of the block proposals in a notarization round is notarized, the nodes in the notarization subset stop notarizing and, in step 1360, continue with integrity checks for one or more block proposals in the notarization round.

[0214] As part of consistency checks, nodes in a notary subset examine whether block proposals from one or more notary rounds match their own individual notary signatures performed in the current notary round. Consistency checks may include, in particular, examining whether block proposals conform to a predefined set of consistency rules. These rules may define certain scenarios that are not considered consistent. In this regard, a block proposal may be considered consistent with the set of consistency rules if the node in the notary subset has not performed any consistent signatures in the current notary round that would contradict the block proposal. This discussion may involve some degree of ambiguity.

[0215] Such ambiguity may be "subjective" according to some embodiments of the present invention. That is, a set of consistency rules may be applied individually by each of the nodes based on individual notarized signatures performed at this node, and only at this node.

[0216] Such ambiguity may depend on the round, according to some embodiments of the present invention. That is, a given node may apply a set of consistency rules based on individual notarized signatures that have been performed in one notarized round and in only one of a particular notarized round.

[0217] For example, ambiguity arises when each node individually notarizes multiple block proposals in the current notarization round.

[0218] On the other hand, if each node in the notarization subset has made at most one separate notarization signature for any block proposal in the current notarization round, and this separate notarization signature is for the block proposal, then the value proposals in the current notarization round may be considered consistent in accordance with a set of consistency rules.

[0219] According to another embodiment, if each node in the notarization subset refers retrospectively to block proposals from a previous notarization round, then the block proposals from the previous notarization round may be considered consistent according to a set of consistency rules, where all block proposals that have received individual notarization signatures in the current notarization round refer retrospectively to block proposals from a previous notarization round.

[0220] "Referring retrospectively" can mean a direct or indirect link established by including a hash digest of a block proposal from a previous notarization round in a block proposal from a later notarization round.

[0221] According to one embodiment, when all value proposals in the current notarization round, for which a node has performed individual notarization signatures, are linked retrospectively to value proposals under consistency checks, a set of consistency rules may define that value proposals under consistency checks are consistent with respect to the nodes of the notarization subset. Here, the retrospective linking can be carried out in one step (directly) or in multiple steps (indirectly).

[0222] Next, in step 1370, the nodes of the notarized subset perform a consistency signature on the subset of consistent block proposals in accordance with a set of consistency rules. This creates a consistency-signed block proposal. According to some embodiments, a consistency-signed block proposal comprises the notarized round number to be finalized, the current notarized round number, and a signature node. Thus, a consistency signature is valid only for a specific combination of the current notarized round and the notarized round to be finalized.

[0223] Next, in step 1380, the multiple nodes move on to the next notarization round. Then, for example, steps 1320 through 1370 of the method described above are repeated for round N+1.

[0224] According to some embodiments, the transition to the next notarization round may be initiated in particular when a fully notarized block proposal is observed for the current notarization round N. In particular, the next notarization round N+1 may be initiated in parallel with the current integrity signature period of the current notarization round N. In particular, nodes that are outside the notarization subset in the current notarization round N may transition to the next notarization round N+1 when a fully notarized block proposal is observed for the current notarization round N.

[0225] Figure 14 shows each of the steps of the finality procedure according to an embodiment of the present invention.

[0226] The finality procedure aims to finalize the notarization round. Therefore, each notarization round includes a corresponding finality procedure. To this end, in step 1410, the nodes of the distributed network, in particular the notarization subset, observe whether a set of finality rules are satisfied. According to this embodiment, a set of finality rules is assumed to be satisfied for a value proposal when a predefined number of consistency signatures are observed for that value proposal. Therefore, in step 1410, the nodes of the distributed network, in particular the notarization subset, observe the number of individual consistency signatures that block the proposal of the notarization round to be finalized. In particular, this step may include distributing individual consistency signatures to the nodes of the notarization subset, for example, by a gossip protocol to an unspecified number of people.

[0227] In this case as well, the required number may depend on the security needs of the application. According to some embodiments, it may be specified that integrity signatures are required for more than two-thirds of the nodes in the notarized subset.

[0228] The required number can be predefined as a system parameter of the distributed network. When the distributed network observes a predefined number for one of the block proposals, the distributed network finalizes that block proposal in step 1420 to create a finalized block proposal.

[0229] Next, in step 1430, the finalized block proposal may be added to the blockchain.

[0230] According to another embodiment, a value proposal may satisfy a set of finality rules only when a predefined number of consistency signatures are observed in the value proposal and the value proposal is fully notarized. Thus, according to such an embodiment, both criteria are observed in step 1410.

[0231] According to some embodiments, a network or multiple nodes of a notarized subset may further consider implicit chains of blocks, implied by the finalized blocks to be added to the blockchain. For example, when a notarized subset initially finalizes only block B1. Then, when the notarized subset observes enough integrity signatures in another block proposal B3 and finalizes block B3 accordingly, and implies that block B3 is an implicit chain of blocks B1←B2←B3, the notarized subset may consider the implicit chain of blocks B1←B2←B3 as a finalized blockchain, and thus block proposal B2 is also finalized.

[0232] The individual notarized signatures and integrity signatures performed in steps 1340 and 1370, respectively, may utilize threshold signature schemes, multi-signature schemes, or aggregate signature schemes.

[0233] According to some embodiments, a finality signature of a finalized block proposal can be added to multiple block proposals in the current notarization round. Such a finality signature can constitute, for example, an aggregate signature comprising individual integrity signatures from a predefined number of nodes.

[0234] Finality signatures can simplify the re-verification of finalized blocks by external observers. For example, aggregate signatures are smaller than sets of individual signatures, requiring less data for external observers to download. For example, a single aggregated signature can be verified faster than multiple individual signatures. For example, threshold signatures can work to reduce the amount of public key material that external observers need to verify.

[0235] Finality signatures can simplify broadcast protocols. For example, according to a broadcast protocol, if a node in a distributed network has finalized a block proposal from notarization round r and possesses a finality signature, the node can stop relaying individual consistency signatures for any block proposal from the same notarization round r and any block proposal from notarization rounds prior to r. Instead, the node can only relay finality signatures. The advantage of such an embodiment is that it is possible to set an upper limit on the number of artifacts that need to be relayed per round.

[0236] The size and selection of the notarization subset can depend on the needs of each application. Furthermore, the size of the notarization subset affects both speed and the security of the consensus mechanism.

[0237] According to some embodiments, the network may use the same notarized subset of a predefined period, for example, a predefined number of hours, days, weeks, or months.

[0238] According to some embodiments, the network may use the same notarized subset for a predefined range of notarized rounds or a predefined range of block numbers.

[0239] According to some embodiments, the network may require nodes in a notarized subset to make a deposit of a predefined minimum security deposit.

[0240] According to some embodiments, the network may select nodes for a notarized subset based on the node's deposit, for example, the higher the deposit, the more likely it is to be selected for the notarized subset.

[0241] According to some further embodiments, the network may periodically change the nodes of the notarized subset, for example, hourly or daily.

[0242] According to some further embodiments, the network may periodically change the nodes of the notarized subset, for example, every N notarized rounds or blocks.

[0243] According to several further embodiments, the network may select a notarized subset of nodes based on randomness beacons.

[0244] Figure 15 shows an exemplary timing diagram of the notarization round and finalization round according to one embodiment of the present invention.

[0245] The basis of this method lies in performing notarization rounds NR1, NR2, NR3, and NR4 in succession. Each of these rounds consists of three stages. First, a timeout period TO is provided. During this timeout period TO, a notarization subset of multiple nodes may have already performed validation of the block proposals for each notarization round. More specifically, they may ignore invalid block proposals and compile a list of valid block proposals. However, the notarization subset of multiple nodes is configured to wait to perform notarization signing until the timeout period expires.

[0246] According to some embodiments, the length or duration of the timeout period TO can be dynamically adjusted.

[0247] The timeout period TO is followed by the notarization signing period NS. During the notarization signing period NS, a notarization subset of multiple nodes may perform individual notarization signings on block proposals that are valid according to a predefined set of validity rules.

[0248] According to some embodiments, a notarized subset may perform notarized signatures on all block proposals it deems valid. On the other hand, according to some other embodiments, a notarized subset may perform a single notarized signature on only one valid block proposal that has the highest rank in the list.

[0249] The distributed network, more specifically multiple nodes in the notarization subset, observes whether one of the block proposals in the current notarization round has received a sufficient number of individual notarized signatures. As soon as this is met, the multiple nodes in the notarization subset stop notarizing and proceed to the consistency signing period (CS).

[0250] In the next consistency signing period (CS), a subset of notarized nodes performs consistency checks as described above and performs consistency signing on a subset of consistent block proposals according to a set of consistency rules. Once each node has performed its individual consistency signing, it moves on to the next notarization round (NR2). The next notarization round (NR2) begins again from the timeout period (TO). It should be noted that the consistency signing period requires the time necessary for each node to perform consistency signing. Therefore, the length of the consistency signing period can vary from node to node and can even vary between consecutive consistency signing periods within the same node.

[0251] According to this exemplary embodiment, the commencement of the consistency signing period CS initiates the finality procedure, which includes the finalization round FR1 for the block proposal of the corresponding notarization round NR1. According to some other embodiments, the finality procedure may commence after a predefined interval following the commencement of the consistency signing period CS.

[0252] During the finalization round FR1, multiple nodes in the distributed network, particularly the notarization subset, observe the number of integrity signatures for the block proposals in notarization round NR1. When a predefined number of integrity signatures are observed for one of the block proposals in notarization round NR1, the corresponding block proposal is finalized and added to the blockchain, and the finalization round FR1 ends.

[0253] According to some embodiments, a corresponding block proposal is finalized and added to the blockchain only if it is also fully notarized itself.

[0254] Similarly, Finalize Rounds FR2 and FR3 commence after the Integrity Signature Period CS of Notarization Rounds NR2 and NR3, respectively.

[0255] The duration of each of the finalization rounds FR1, FR2, and FR3 depends on the time required to collect the number of consistent signatures predefined in the corresponding notarization rounds NR1, NR2, and NR3 block proposals. Therefore, the durations of finalization rounds FR1, FR2, and FR3 may differ.

[0256] A finalization round may also terminate when subsequent finalization rounds have finished. For example, FR2 may terminate when a predefined number of integrity signatures have been observed in FR2. This can implicitly terminate FR1 even if a predefined number of integrity signatures have not yet been observed in FR1.

[0257] In the example shown in Figure 15, it is assumed that the consistency signatures performed during the consistency signing period of the notarization round NRX are performed on block proposals created in the same notarization round NRX.

[0258] According to several other embodiments, the integrity signature performed in the integrity signing period CS of notarization round NRX can be performed on the block proposal created in the previous notarization round NRX-d, where d is an integer and may be a system parameter. The value d may be variable according to some embodiments. According to some embodiments, multiple values ​​of d can be considered simultaneously. According to some embodiments, a range of values ​​for d can be considered simultaneously.

[0259] An example is shown in Figure 16, which illustrates an exemplary timing diagram of the stages in the notarization round and finalization round according to another embodiment of the present invention.

[0260] Referring to Figure 15, the method underlying Figure 16 is shown, in which notarization rounds NR1, NR2, NR3, and NR4 are performed sequentially. Each of notarization rounds NR1, NR2, NR3, and NR4 comprises a timeout period TO, a notarization signing period NS, and a consistency signing period CS, as generally described with reference to Figure 15.

[0261] According to one embodiment shown in Figure 16, consistency signing performed during the consistency signing period of notarization round NRX is assumed to be performed on the block proposal created in the preceding notarization round NRX-1. For example, consistency signing performed during consistency signing period NR2 is performed on the block proposal created in the preceding notarization round NR1. Therefore, the finalization rounds of each notarization round may also be started at intervals. More specifically, as shown in Figure 16, the finalization round FR2 may only be started after the consistency signing period CS of notarization round NR3 has started.

[0262] In some other embodiments, consistency checks may be performed on multiple rounds to be finalized, as further shown below.

[0263] According to some embodiments, the notarization round may also be referred to as the first round, and the finalization round may be referred to as the second round.

[0264] Figure 17 shows an exemplary flowchart / timing diagram of six consecutive notarization rounds NR1, NR2, NR3, NR4, NR5, and NR6 according to one embodiment of the present invention. More specifically, it shows each step of the process performed by node N1, which is assumed to be a node in a notarization subset of multiple nodes.

[0265] In this example, it is assumed that three block proposals are created between each of the notarization rounds NR1 to NR6. Each block proposal includes the round number of the corresponding notarization round, for example, R1 for the first notarization round NR1. Each block proposal also includes a block number BXY, where X is the sequential number of the block proposal for the notarization round and Y is the round number of the notarization round.

[0266] The block proposal includes links 1710, indicated by arrows to the respective parent block proposals of the previous notarization round.

[0267] Referring here to the first notarization round R1, there are three block proposals B1.1, B2.1, and B3.1. Links to the block proposals from the first notarization round are not provided.

[0268] Node N1 validates the three block proposals. In this example, only block proposal B1.1 is found to be valid, so we assume that a separate notarized signature NSN1 is performed on block proposal B1.1. Here, the subscript N1 indicates the signing node.

[0269] After executing the individual notarized signature NSN1, node N1 performs an integrity check. The integrity check includes verifying whether the block proposal executed by node N1 in the current round R1 is an individual notarized signature that is considered consistent according to a set of integrity rules. In this round R1, node N1 executed only one individual notarized signature in block proposal B1.1, so block B1.1 is considered consistent, and node N1 executes the integrity signature CSR1R1N1 in block proposal B1.1.

[0270] A consistency signature comprises the notarization round number to be finalized, the current notarization round number, and the signer or signing node. Thus, the subscripts "R1R1N1" indicate the notarization round number to be finalized (first "R1"), the current notarization round number (second "R1"), and the signing node ("N1").

[0271] Now, referring to the second notarization round R2, there are three block proposals B1.2, B2.2, and B3.2.

[0272] Node N1 performs validation again on the three nodes. In this example, since block proposals B1.2 and B2.2 are found to be valid, it is assumed that individual notarized signatures NSN1 will be performed on block proposals B1.2 and B2.2.

[0273] After performing individual notarized signatures NSN1, node N1 performs a consistency check. In this round R2, node N1 performed two separate notarized signatures on two different blocks, and therefore is not considered consistent with the corresponding block proposals B1.2 and B2.2. Thus, node N1 does not perform a consistency signature in notarization round R2.

[0274] Now, referring to the third notarization round R3, there are three block proposals B1.3, B2.3, and B3.3.

[0275] Node N1 performs validation again on the three nodes. In this example, since block proposals B1.3 and B2.3 are found to be valid, it is assumed that individual notarized signatures NSN1 will be performed on block proposals B1.3 and B2.3.

[0276] After executing the individual notarized signature NSN1, node N1 performs a consistency check. In this round R3, since node N1 executed two individual notarized signatures on two different blocks, the corresponding block proposals B1.3 and B2.3 are not considered to be consistent. However, since both block proposals B1.3 and B2.3 refer to or link to the same parent block proposal B2.2 of the previous notarization round R2, the consistency check is considered to be consistent with the block proposal B2.2 of the previous round R2, and a consistency signature CSR2R3N1 is executed on the block proposal B2.2. The subscript "R2R3N1" indicates the notarization round number finalized by the first "R2". In this example, the previous notarization round number is R2, and "R3" indicates the current notarization round number R32.

[0277] Here, referring to the fourth notarization round R4, there are three block proposals B1.4, B2.4, and B3.4.

[0278] Node N1 performs a validity check again for three nodes. In this example, since it is found that block proposals B1.4 and B2.4 are valid, it is assumed that individual notarized signatures NSN1 are executed for block proposals B1.4 and B2.4.

[0279] After executing the individual notarized signature NSN1, node N1 performs a consistency check. In this round R4, since node N1 executed two individual notarized signatures on two different blocks, the corresponding block proposals B1.4 and B2.4 are not considered to be consistent.

[0280] Here, referring to the fifth notarization round R5, there are three block proposals B1.5, B2.5, and B3.5.

[0281] Node N1 performs a validity check again for three nodes. In this example, since it is found that only block proposal B3.5 is valid, it is assumed that an individual notarized signature NSN1 is executed for block proposal B3.5.

[0282] After executing the individual notarization signature NSN1, node N1 performs a consistency check. In this round R5, since node N1 executed only a single individual notarization signature in block proposal B3.5, block B3.5 is considered to be consistent, and node N1 executes the consistency signature CSR5R5N1 in block proposal B3.5.

[0283] Furthermore, consistency checks for the previous rounds R3 and R4 are also performed, and blocks B2.4 and B2.3 are considered to be consistent in the same way that block B3.5 links to them or refers back to block B2.4. Therefore, the consistency signature CSR3R5N1 is executed in block proposal B2.4, and the consistency signature CSR3R5N1 is executed in block proposal B2.3.

[0284] Here, referring to the sixth notarization round R6, there are three block proposals B1.6, B2.6, and B3.6.

[0285] Node N1 performs a validity check again for the three nodes. In this example, since it is found that only block proposal B3.6 is valid, it is assumed that the individual notarization signature NSN1 is executed for block proposal B3.6.

[0286] After executing the individual notarization signature NSN1, node N1 performs a consistency check. In this round R6, since node N1 executed only a single individual notarization signature in block proposal B3.6, block B3.6 is considered to be consistent, and node N1 executes the consistency signature CSR6R6N1 in block proposal B3.6.

[0287] In the above example, it is assumed that the step of performing the consistency check is carried out for a plurality of notarization rounds to be finalized. As an example, in notarization round NR5, node N1 signs for notarization rounds NR3, NR4, and NR5.

[0288] According to several other embodiments, for example, as shown in Figures 15 and 16, multiple nodes may perform integrity checks only for a single notarization round to be finalized.

[0289] According to some embodiments, multiple nodes may perform integrity checks on block proposals from multiple notarization rounds h during the integrity signing period of a single notarization round r, as shown in Figure 17, but only on a subset of round numbers h, rather than on all possible values ​​for h.

[0290] In some embodiments, a subset of round numbers h may be pre-selected. For example, a node may consider consistency checks only for every nth round where n is a predefined integer; that is, only values ​​of h that satisfy h = n mod n may be considered. This is done to reduce the number of messages delivered to an unspecified number of recipients by reducing protocol overhead.

[0291] In some other embodiments, a subset of round number h may be a function of a predefined r. For example, a subset of round number h may be a closed interval [rd, r], where d is a predefined constant. This is done to limit the number of messages delivered to an unspecified number of recipients by setting an upper limit on the protocol overhead.

[0292] In some other embodiments, a subset of round number h may be a half-open interval (s, s+d), where s is the last round in which each node observed a finalized block, and d is a predefined constant. This again creates an overhead and message volume upper limit.

[0293] The following sections disclose further cryptographic details according to some embodiments of the present invention. According to some embodiments of the present invention, distributed networks can be designed according to desired security assumptions or security needs.

[0294] According to some embodiments, the following may be assumed:

[0295] The size of every notarized subset is n, where n is an integer. In other words, a notarized subset has n nodes.

[0296] In every notarized subset, at most f nodes are Byzantine (unfair), and the rest are protocol (legitimate), where f is an integer.

[0297] The number of individual notarized signatures required to notarize a value proposal and create a fully notarized value proposal is a predefined number, where t1 is an integer.

[0298] The number of individual integrity signatures required to satisfy a set of finality rules and finalize a value proposal is t2, where t2 is an integer.

[0299] t1, t2, n, and f are selected by applying the following formula. t1+t2>n+f

[0300] The set of consistency rules identifies value proposal A as consistent (from the perspective of the nodes in the current round) only if A is a common ancestor of all current value proposals for which the nodes in the current round have performed individual notarization signatures. More specifically, A is a common ancestor if A is directly or indirectly linked to all current value proposals for which the nodes in the current round have performed individual notarization signatures.

[0301] All A's are consistent when the node has not performed any individual notarized signatures in the current round.

[0302] A series of finality rules require at least the consistency signature of t2, and they all specify that they are created between the same notarized round r by the notarized subset of that round r.

[0303] Based on the above premises, according to one embodiment, the following theorem can be carried out. First, the value proposal A from round h is finalized. Next, there is a sufficiently long sequence of notarized value proposals that includes A. More precisely, there exists a number r = r(A) such that A is included in any sequence of notarized value proposals of length r.

[0304] According to one embodiment, the proof of the theorem can be provided as follows.

[0305] Since A is finalized, there exists a number r ≥ h such that A receives at least the consistency signatures of t2 that were all created during the consistency period CP of round r.

[0306] Let B be a value proposal fully notarized from round r. It is claimed that A is an ancestor of B, thereby proving the theorem.

[0307] First, assume that the claim is false, that is, A is not an ancestor of B. Let S be the notarized subset that was active in round r. At least t2 nodes in S executed individual consistency signatures for A. Of those t2 nodes, at least t2 - f were valid. According to a series of consistency rules, those t2 - f nodes did not execute individual notarization signatures for B. Because when a node in s executed an individual notarization signature for B in round r, since A is not an ancestor of B, A is not consistent for that node in round r. Therefore, the number of individual notarization signatures for B by nodes from s is at most n - (t2 - f) = n + f - t2 < t1. This means that B is not fully notarized. This is a contradiction, so the above claim is true.

[0308] Some examples are shown below. Assuming f < n / 3, the distributed network can select t1, t2, and n according to some of the following embodiments, for example. t1 = t2 = 2 / 3 * n, or t1 = 5 / 6 * n, t2 = 1 / 2 * n, or t1 = 1 / 2 * n, t2 = 5 / 6 * n.

[0309] In the above - described embodied proof, it should be noted that for a series of finality rules, even if the notarized subset does not change from round to round, all t2 consistency signatures created during the same notarized round are required.

[0310] Referring now to FIG. 18, a more detailed block diagram of a network node 10, such as shown in network 100 of FIG. 1, according to an embodiment of the present invention is shown. The network node 10 can perform computing functions and thus establish a computing node that can generally be embodied as a computing system or a computer. The network node 10 can be, for example, a server computer. The network node 10 can operate in many other general - purpose or special - purpose computing system environments or configurations.

[0311] The network node 10 can be described in the general context of computer system - executable instructions, such as program modules executed by a computer system. Generally, program modules can include routines, programs, objects, components, logic, data structures, etc. that perform specific tasks or implement specific abstract data types. The network node 10 is shown in the form of a general - purpose computing device. The components of the network node 10 can include one or more processors or processing units 1815, a system memory 1820, and a bus 1816 that couples various system components including the system memory 1820 to the processor 1815. However, it is not limited thereto.

[0312] Bus 1816 represents one or more of several types of bus structures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports (AGP), and processor or local buses using one of 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.

[0313] Network node 10 typically contains various computer system-readable media. Such media can be any available media accessible by network node 10, and it includes both volatile and non-volatile media, and removable and non-removable media.

[0314] System memory 1820 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 1821 and / or cache memory 1822. Network nodes 1810 may further include other removable / non-removable, volatile / non-volatile computer system storage media. As an example, storage system 1823 may provide a non-removable, non-volatile magnetic medium (not shown, typically referred to as a “hard drive”) for reading and writing. Not shown, a magnetic disk drive may be provided for reading and writing to a removable non-volatile magnetic disk (e.g., a “floppy disk”), and an optical disk drive may be provided for reading or writing to a removable non-volatile optical disk, such as a CD-ROM, DVD-ROM, and other optical media. In such cases, each may be connectable to bus 1816 by one or more data medium interfaces. As further described and explained below, memory 1820 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 some embodiments of the present invention.

[0315] A program / utility 1830 having a set of program modules 1831 (at least one) may, as an example, store an operating system, one or more application programs, other program modules, and program data in memory 1820, though not limited thereto. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may be implemented in a networking environment. Program modules 1831 generally implement functions and / or methodologies of some embodiments of the present invention as described herein. Program modules 1831 may perform one or more specific steps of a method of implementation on a computer that provides users of a distributed network with access to computation results computed by the distributed network, for example, one or more steps of the method described above.

[0316] The network node 10 can also communicate with one or more external devices 1817, such as a keyboard or pointing device, as well as the display 1818. Such communication is possible via the input / output (I / O) interface 1819. Furthermore, the network node 10 can communicate with one or more networks 40, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet), via the network adapter 1841. According to some embodiments, the network 1840 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 1841 communicates with other components of the network node 10 via the bus 1816. It should be understood that other hardware and / or software components, not shown, can be used in combination with the network node 10.

[0317] Network node 10 provides network resources to the corresponding distributed network. Network resources include, in particular, memory 1820, which includes processing unit 1815 and storage system 1823.

[0318] Figures 19a and 19b illustrate an asynchronous communication model for a distributed network and a corresponding asynchronous consensus mechanism according to one embodiment of the present invention.

[0319] Synchronous consensus protocols rely on network synchronization to observe agreement. In other words, after a predefined time has elapsed, it is assumed that all messages have been received by other nodes / replicas. For example, a message could be a block, and agreement is determined by examining the longest blockchain. In such synchronous consensus protocols, there is a trade-off between security and low latency. A long predefined time allows nodes to be confident that all relevant messages have been received and that they know what has been agreed upon, but latency becomes very high. On the other hand, a considerably short predefined time can improve latency, but nodes may not have yet received all blocks, and incorrect input may be considered agreed upon.

[0320] Some embodiments of the present invention address the technical issues associated with this trade-off by providing a finality procedure that can be executed asynchronously in parallel with the notarization round. The finality procedure provides concrete confirmation to nodes / replicas when agreement is reached on the new value proposition.

[0321] At any height, when a node stops performing individual notarized signatures by confirming that block proposal b is fully notarized, the node checks the number of individual notarized signatures it performed at that height. If it did not sign any block proposals other than b, it may add a consistency signature to b. According to one such embodiment, the meaning of a consistency signature from node i in block b at height h can be understood as "I, node i did not perform any individual notarized signatures on any block proposals other than b at height h."

[0322] The nodes in the notarized subset distribute their integrity signatures (if they create them) to an unspecified number of recipients, and a block proposal can be finalized when a sufficient number of integrity signatures (2f+1) satisfy a set of finality rules. When a node / replica confirms sufficient finalization of block proposal b, it considers b and the chain indicated by b to be final.

[0323] This approach to finalization satisfies safety without considering the network, as long as at most f out of n nodes / replicas are corrupted, for n=3f+1. In other words, finalizing block b at height h means that no notarized block b'≠b can exist at height h.

[0324] Referring to Figure 19a, square 1911 represents the block proposal of block proposal chain 1910. Checkmark 1912 indicates that block proposal 1911 has been fully notarized. Arrow 1913 points to the previous block proposal to which each block proposal is linked.

[0325] The dashed line indicating block proposal 1921 represents another possible chain 1920 of block proposals. As previously stated, one embodiment of the present invention is based on an asynchronous communication model. According to such an asynchronous communication model, even if only block proposal chain 1910 exists, it is not possible to be certain that the dashed alternative chain 1920 does not exist, so the nodes of the network seeing chain 1910 cannot proceed. Therefore, they cannot determine whether block proposal 1911 has actually been agreed upon.

[0326] To facilitate the progress of agreement in some embodiments of such asynchronous consensus systems / networks of the present invention, integrity checks and integrity signatures are used. Referring to Figure 19b, squares 1931 are fully notarized blocks, some of which have integrity signatures 1934 added, indicated by stars. Integrity signature 1934 excludes the presence of another dashed notarized block 1941 in a parallel chain of block proposals 1940 at the same block height. Thus, in this example, a node / replica that checks integrity signature 1934 can accept each block proposal as final. This is also true under the assumption of asynchronous communication.

[0327] Figure 20 shows a timing diagram of a communication scheme for communicating value propositions according to several embodiments of the present invention.

[0328] The horizontal axis represents time, and the vertical axis represents the bandwidth used to distribute the value proposition to a large, unspecified audience.

[0329] According to one illustrated embodiment, the value proposal is communicated, in particular, delivered to an unspecified number of people during the first period 2010 of the notarization round. The first period 2010 may be represented as VBP (Delivery of Value Proposal). The first period VBP, 2010 may, according to some embodiments, coincide with a timeout period TO, as shown in Figures 15 and 16.

[0330] The first period 2010 is placed between VBP and the second period 2020, which is used to perform and distribute the protocol signatures to an unspecified number of people. The second period may be referred to as SB (Signature Distribution) and may be used in particular for performing and distributing individual notarized and integrity signatures to an unspecified number of people. The second period 2020, SB may coincide with periods NS and CS, as shown in Figures 15 and 16.

[0331] According to some embodiments, the second period SB, 2020 may only include the execution of integrity signatures and the initial communication / distribution of integrity signatures executed by the corresponding node to an unspecified number of recipients. On the other hand, it should be noted that the transfer / further distribution of integrity signatures by other nodes, and the observation of a predefined minimum number of integrity signatures (defined by a set of finality rules) may be performed in the background as part of the finality procedure. Therefore, the integrity signature period CS can be very short and is illustrated as shorter than the notarized signature period NS.

[0332] Such communication methods address the technical problem of improving throughput, particularly consensus throughput. According to some embodiments, consensus throughput can be defined as the sum of all value proposals finalized within a given time unit.

[0333] According to some embodiments, high throughput can be achieved with large value proposals, particularly those delivered to a large number of recipients during a first VPB period. The bottleneck in such embodiments is the network bandwidth required to deliver the (large) value proposal to the large number of recipients. For large value proposals, the bandwidth required to deliver the value proposal to the large number of recipients is dominant over the bandwidth required for other messages in the consensus mechanism, which are primarily signatures. According to some embodiments, such other messages may be represented as consensus overhead.

[0334] According to some embodiments, a value proposition distributed to an unspecified number of people during a first period has a size of at least 1 MB, while individual notarized signatures and integrity signatures distributed to an unspecified number of people during a second period have a size of less than 200 bytes.

[0335] According to some embodiments, the first period VPB of the notarization round is at least the same length as the second period SB of the notarization round, and in particular, at least twice the length of the second period.

[0336] This reduces downtime not used for distributing the value proposal to a large, unspecified audience, thereby improving consensus throughput. According to some embodiments, at least 60% of the time may be used for distributing the value proposal to communications / a large, unspecified audience. In other words, the first period VPB would include at least 60% of the time, and the second period SB would include less than 40%.

[0337] Such high bandwidth use for distributing value proposals to a large, unspecified audience is achieved by an innovative design of the consensus mechanism, particularly by performing notarized signatures and distributing them to a large audience, by performing consistency signatures and communicating them initially during a relatively short second period between the first and second periods, and further by transferring / distributing the consistency signatures to a larger audience, and by performing finality procedures in parallel with the notarization rounds in a staggered and overlapping manner.

[0338] Figure 21 shows an exemplary timing diagram of the notarization round and finalization round according to another embodiment of the present invention.

[0339] The underlying method involves sequential notarization rounds NR1, NR2, and NR3, each comprising a timeout period TO, a notarization signing period NS, and a consistency signing period CS. During the timeout period TO, new value proposals may be distributed to an unspecified number of recipients, and a notarization subset of multiple nodes may have already performed validation checks on the value proposals. During the notarization signing period NS, the notarization subset of multiple nodes may perform and communicate / distribute individual notarization signatures on block proposals that are valid according to a predefined set of validation rules. Furthermore, the notarization signing period NS may include receiving and forwarding individual notarization signatures from other nodes, as well as notarization itself. As soon as a sufficient number of individual notarization signatures are observed, the multiple nodes in the notarization subset may stop performing notarization signatures and proceed to the consistency signing period CS for their respective notarization rounds. The consistency signing period CS may, in particular, include consistency checks, as well as the performance of consistency signatures and initial communication by the multiple nodes that performed consistency signatures.

[0340] According to this embodiment, the network is configured to start a new notarization round after the notarization signing period has already been completed. For example, notarization round NR2 has already started immediately after the notarization signing period NS of notarization round NR1. At the same time, finality procedure FR1 may also start. Thus, according to such an embodiment, the notarization periods may also partially overlap, in other words, they may run alternately.

[0341] Aspects of the present invention may be embodied as a system, in particular as a distributed network comprising multiple subnets, methods, and / or computer program products. The computer program products may include a computer-readable storage medium (or multiple media) having computer-readable program instructions that cause a processor to execute certain aspects of the present invention.

[0342] A computer-readable storage medium can be a tangible device capable of holding and storing instructions used by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. As used herein, a computer-readable storage medium should not be construed 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., light pulses passing through fiber optic cables), or electrical signals transmitted through wiring.

[0343] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computer / processor, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may consist of copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface of each computer / processor receives computer-readable program instructions from the network, transfers those instructions, and stores them in the computer-readable storage medium of each computer / processor.

[0344] 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. The programming languages ​​may be smalltalk, object-oriented programming languages ​​such as C++, and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages.

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

[0346] Computer-readable program instructions according to some embodiments of the present invention are provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, and the instructions, executed via the processor of the computer or other programmable data processing device, create means to perform functions / actions specified in a flowchart and / or a block diagram consisting of one or more blocks, thereby manufacturing a machine. These computer-readable program instructions may 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. The computer-readable storage medium storing these instructions comprises a product containing instructions that perform a manner of function / action specified in a flowchart and / or a block diagram consisting of one or more blocks.

[0347] Computer-readable program instructions can also be loaded into a computer, other programmable data processing device, or other device to generate a computer implementation process by causing the computer, other programmable device, or other device to execute a series of operational steps so that the instructions executed by the computer, other programmable device, or other device implement the functions / operations specified in a flowchart and / or a block diagram consisting of one or more blocks.

[0348] The flowcharts and block diagrams in the figures illustrate the architectures, functions, and operations of various embodiments of the present invention that can be implemented in networks, systems, methods, and computer program products. In this regard, each block in a flowchart or block diagram may represent a module, segment, or part of an instruction, which comprises one or more executable instructions that implement a given logical function. In some alternative implementations, the functions shown in the blocks may differ from the order shown in the figures. For example, two blocks shown consecutively may actually be executed substantially simultaneously. Also, depending on the functions involved, the blocks may be executed in reverse order.

[0349] The following sections provide several additional and / or alternative embodiments, as well as definitions of some additional and / or alternative wording and terms of embodiments of the present invention.

[0350] According to some embodiments, a set of validity rules may determine that a value proposal is valid when a node in a notarization subset verifies and / or receives the value proposal. According to such embodiments, sufficient notarization may be considered confirmation, authentication, or evidence that a predefined number of nodes have verified and / or received the value proposal. According to such embodiments, notarizing a value proposal may be considered evidence of publication. In this regard, the nodes in a notarization subset may, according to some embodiments, serve as witnesses that they have received and / or verified the corresponding value proposal.

[0351] According to some further embodiments, the term notarization may also include voting. According to such embodiments, the corresponding distributed network may aim to estimate the limits of value proposals and aim to notarize only one value proposal per round, in particular the highest priority one, or only a group of high priority value proposals.

[0352] Therefore, according to some embodiments, a set of validity rules can be embodied as a set of prioritization rules. According to such embodiments, a set of prioritization rules may designate prioritization rules as validity rules. Such prioritization rules may designate criteria such that a corresponding node can determine which value proposal or group of value proposals to notarize, i.e., which to notarize.

[0353] According to some embodiments, the validation may comprise two distinct substeps, where the two distinct substeps may be configured to perform the validation using two distinct sets of validation rules, for example, a first set of validation rules and a second set of validation rules.

[0354] The first substep may, in particular, include a first set of validity rules, e.g., validity checks of one or more features of the value proposal described above. The second substep may, in particular, include a second set of validity rules, e.g., validity checks that specify that a value proposal is valid when a node in the notarization subset verifies and / or receives the value proposal.

[0355] According to such embodiments, the first and second substeps may be carried out by different notarization subsets, for example, a first notarization subset and a second notarization subset. According to some embodiments, the first notarization subset may be selected to be smaller than the second notarization subset.

[0356] According to some embodiments, a notarized signature may also be presented as a vote or represent a vote. A notarized round may be presented as a pre-approved round, and a notarized value proposal may be presented as a pre-approved value proposal.

[0357] According to some embodiments, a notarized signature may also be presented as a valid signature.

[0358] Preferred embodiments of the present invention have been shown and described. However, it should be clearly understood that the present invention is not limited thereto and can be embodied and implemented in various ways within the scope of the following claims.

Claims

1. A distributed network comprising multiple network nodes, The distributed network is configured to perform a method of reaching an agreement on a set of values, particularly through an asynchronous consensus protocol. The method comprises the step of performing a series of notarization rounds, The aforementioned notarization round, A step in which one or more of the plurality of network nodes create a value proposal to be added to the sequence, wherein the value proposal includes a link to a parent value proposal from a previous notarization round, The steps include distributing the aforementioned value proposition to an unspecified number of people, A step in which network nodes of a subset of the plurality of network nodes, designated as a notarization subset, perform a validity check of an accepted value proposal, the validity check includes a step of checking whether the accepted value proposal conforms to a set of predefined validity rules, The steps include: the network nodes of the notarized subset performing individual notarized signatures on the value proposals that are valid in accordance with the validation check and communicating, thereby creating individually notarized value proposals; The steps include notarizing the value proposal when the distributed network satisfies a set of predefined notarization rules, in particular when a predefined number of individual notarization signatures have been collected, thereby creating a fully notarized value proposal for each of the notarization rounds, The step of a network node of the notarization subset performing an integrity check of value proposals for one or more consecutive notarization rounds with respect to its own individual notarization signatures performed in the current notarization round, wherein the integrity check includes checking whether the value proposals for one or more consecutive notarization rounds conform to a set of predefined integrity rules, The steps include: the network nodes of the notarized subset communicate by performing integrity signing in the value proposal that has been aligned in accordance with the set of integrity rules, thereby creating a value proposal that has been aligned and signed; The method further comprises a finality procedure, the finality procedure being, The distributed network, upon determining that the value proposal satisfies a predefined set of finality rules, thereby creating a finalized value, wherein the set of finality rules includes a predefined minimum number of consistency signatures. A distributed network comprising the steps of adding the finalized value to the sequence of values.

2. The method further comprises the step of performing the integrity check when a fully notarized valuation proposal is observed in the current notarization round, according to claim 1 of the distributed network.

3. The value proposition comprises the number of the current notarization round, as described in claim 1 or 2, for the distributed network described in claim 1 or 2.

4. The distributed network according to claim 1 or 2, wherein the set of validity rules indicates that a value proposal is valid only if the corresponding parent value proposal is fully notarized.

5. The validation of the accepted value proposal comprises examining one or more features of the accepted value proposal, The distributed network according to claim 1 or 2, wherein one or more of the features are selected from a group consisting of the network node that creates the accepted value proposition, the content of the accepted value proposition, and the content of a previous value proposition linked to the accepted value proposition.

6. The distributed network according to claim 1 or 2, wherein the set of finality rules is deemed satisfied in a value proposal when a predefined number of consistency signatures are observed in the value proposal.

7. The distributed network according to claim 1 or 2, wherein the set of finality rules is satisfied in a value proposal if a predefined number of consistency signatures have already been observed in the value proposal and the value proposal has been fully notarized.

8. The distributed network according to claim 1 or 2, further comprising the step of moving to the next notarization round of the method when a fully notarized value proposal is observed in the current notarization round.

9. The distributed network according to claim 1 or 2, wherein the notarization round includes a timeout period at the start of each notarization round, and the notarization subset of the plurality of network nodes is configured to wait for the execution of individual notarization signatures until the timeout period has expired.

10. The distributed network according to claim 1 or 2, further comprising the step of the distributed network distributing internal integrity signatures of the distributed network to an unspecified number of recipients.

11. The distributed network according to claim 1 or 2, wherein the distributed network is configured to add the finality signatures of each finalized value to the value proposal of the current notarization round.

12. The distributed network according to claim 1 or 2, wherein the distributed network is configured to periodically change the plurality of network nodes of the notarized subset.

13. The distributed network according to claim 12, wherein the distributed network is configured to select the plurality of network nodes of the notarized subset in response to random beacons.

14. The distributed network according to claim 1 or 2, wherein the consistent signed value proposal comprises the number of the notarization round to be finalized, the number of the current notarization round, and a signing node.

15. The distributed network according to claim 1 or 2, wherein the value is a block written to the blockchain.

16. The distributed network according to claim 15, wherein the step of validating the accepted value proposals includes the step of verifying the block header of a block proposal and / or the step of verifying the payload of a block proposal.

17. The distributed network is configured to assign ranks to value propositions, The step of performing the aforementioned validation test is: Steps to ignore invalid value propositions, The process includes the step of compiling a list of reasonable value propositions, The distributed network according to claim 1 or 2, wherein the step of performing the individual notarized signatures comprises the step of performing a single individual notarized signature only for the most reasonable value proposition of the highest rank in the list.

18. The distributed network according to claim 1 or 2, wherein the step of performing the integrity check is performed for a single notarization round to be finalized.

19. The distributed network according to claim 1 or 2, wherein the distributed network is configured to perform the integrity check for a plurality of notarization rounds to be finalized.

20. The distributed network is configured to select n, the number of network nodes in the notarized subset; t1, a predefined number of individual notarized signatures required to notarize the value proposal and create a fully notarized value proposal; and t2, a predefined number of consistency signatures required to satisfy the set of finality rules and finalize the value proposal according to the formula: t1 + t2 > n + f. The distributed network according to claim 1 or 2, wherein the distributed network is configured on the security assumption that in all notarized subsets, at most f network nodes are Byzantine and the remaining nodes are legitimate.

21. The step of communicating the value proposal to the notarization subset is performed during the first period of the notarization round. The distributed network according to claim 1 or 2, wherein the steps of performing the individual notarized signatures and the integrity signatures, and communicating the individual notarized signatures and the integrity signatures, in particular, distributing them to an unspecified number of recipients, are performed during a second period of the notarization round.

22. The first period of the notarization round is at least the same length as the second period of the notarization round, and in particular, at least twice the length of the second period. The distributed network according to claim 21.

23. The distributed network according to claim 21, wherein the size of the value proposal is at least 1 MB, and the size of the individual notarized signature and the consistency signature is less than 200 bytes.

24. The distributed network according to claim 1 or 2, wherein the distributed network is configured to spend at least 60% of its time communicating the value proposition.

25. A method implemented on a computer for reaching an agreement on a set of values ​​using an asynchronous consensus protocol in a distributed network, The method described above involves a series of consecutive notarization rounds, and the notarization rounds consist of, A step in which one or more network nodes of the distributed network create a value proposal to be added to a sequence, wherein the value proposal includes a link to a parent value proposal from a previous notarization round, The steps include distributing the aforementioned value proposition to an unspecified number of people, A step in which network nodes of a subset of the plurality of network nodes, designated as a notarization subset, perform a validity check of an accepted value proposal, the validity check includes a step of checking whether the accepted value proposal conforms to a set of predefined validity rules, The steps include: the network nodes of the notarized subset performing individual notarized signatures on the value proposals that are valid in accordance with the validation and communicating them, thereby creating individually notarized signed value proposals; The steps include: the distributed network notarizing a value proposal when a set of predefined notarization rules are met, in particular when a predefined number of individual notarization signatures are collected, thereby creating a fully notarized value proposal for each of the said notarization rounds; A step of performing a consistency check of the value proposals of one or more notarized rounds for their own individual notarized signatures performed in the current notarized round, wherein the consistency check includes a step of checking whether the value proposals conform to a set of predefined consistency rules, The steps include: the network node of the notarized subset performing a consistency signature on the value proposal that conforms to the set of consistency rules and communicating; This includes the steps for performing the finality procedure, A computer-implemented method comprising the steps of: performing the finalization procedure, where the distributed network finalizes the value proposal when the value proposal satisfies a set of predefined finality rules, thereby creating a finalized value, wherein the set of finality rules includes a predefined minimum number of consistency signatures; and adding the finalized value to a sequence of values.

26. A network node for a distributed network, wherein the network node is configured to perform the method described in claim 25.

27. A computer program product for operating a distributed network, wherein the distributed network comprises a plurality of network nodes, the computer program product comprises a computer-readable storage medium storing materialized program instructions, the program instructions are executable by one or more of the plurality of network nodes, and the computer program product causes one or more of the plurality of network nodes to implement the method implemented in the computer according to claim 25.

28. A computer program product for operating nodes of a distributed network, wherein the computer program product comprises a computer-readable storage medium storing materialized program instructions, the program instructions are executable by one or more network nodes among the plurality of network nodes, and the computer program product causes the network nodes to implement the method implemented in the computer according to claim 25.

Images