Convergent consensus methods for distributed ledger transactions

Abstract

A computer system and computer-implemented method for efficiently achieving convergent consensus in a distributed network of nodes that maintains a decentralized database or ledger with immutable data storage. Through transactions, client nodes request updates to the ledger, which are validated by a group of peer nodes to achieve a new consensus of opinion across the network. The process involves a trust-merging function and state transition function that quickly converges to consensus. The convergent method uses "proof-of-stake" of peer nodes to avoid the high cost of "proof-of-work" alternatives that have unsustainable energy demands. Embodiments of the system have capacity for hundreds of thousands of transactions per second.

Description

Technical Field

[0001] This invention relates to systems and methods in distributed ledger technology (DLT). Consensus in this environment involves digital, cryptographically protected systems and processes that provide distributed agreement and immutable evidence for updating information or securely transferring value between signatory parties. Consensus on DLT transactions is typically maintained by many peer nodes in an Internet-connected network. Background Technology

[0002] Distributed ledger technology (DLT) is a decentralized database and computing technology (some types of which are called blockchain technology) that often operates on the internet. DLT is typically characterized by decentralization, transparency, tamper-proofing, trustworthiness, collective maintenance, and traceability. Blockchain is widely used in the financial industry and its use continues to grow in other sectors.

[0003] Data in a blockchain is distributed through a network of servers (sometimes referred to as nodes (or peer nodes) in the context of this invention) connected via communication protocols. Blockchain nodes typically participate in a sharing process to reach consensus, which ensures that they all agree on the same data values.

[0004] Many current DLT systems require significant computing power and / or data storage, which wastes considerable energy and hardware resources. This results in high costs for each individual business transaction. This inefficiency means they are generally unsuitable for small transactions typically used in payments or consumer applications. There are often long delays before consensus is reached. For example, a transaction may take more than 10 minutes to confirm, costing many dollars due to the large energy consumption. Another major blockchain, Ethereum, has a latency of approximately 20 seconds, with a maximum global throughput of 15 to 20 transactions per second.

[0005] Other consensus methods have attempted to avoid these problems by limiting the set of participants. This implies centralized control by a single entity or a small number of trusted entities. An example is "proof-of-authority" networks, such as Hyperledger. This approach cannot provide consensus for open, decentralized networks where any peer node (including untrusted and potentially malicious participants) can freely participate in the consensus process without any centralized control.

[0006] Some blockchains are also vulnerable to attacks on their security and integrity. For example, it is well known that malicious attackers can rewrite some recent blockchain history and potentially profit from disrupting the consensus order of transactions.

[0007] DLT node operators often need financial incentives to recoup their processing and data storage costs. Therefore, it's crucial to ensure that the incentives for node operation are well aligned with the requirements for trusted node operation. Recent innovations have proposed the idea of ​​rewarding node operators based on some economic stake they've invested in the network (proof-of-stake).

[0008] This invention represents a significant advancement over existing DLT techniques, addressing many performance, scalability, and cost issues of previous methods while maintaining high security even in fully decentralized environments. Summary of the Invention

[0009] A first aspect of the present invention provides a system for achieving effective consensus, comprising:

[0010] One or more nodes of various types, arranged in a network as arbitrary communication and functional participants, wherein at least a first node type is referred to as a peer node, are used for generating trusts by the peer nodes such that each trust contains data for forming consensus; a belief merge function that combines one or more trusts; wherein the peer nodes are arranged to maintain the consensus of the network according to a consensus protocol, the consensus protocol including applying the belief merge function to the trusts; wherein the belief merge function is defined to cause the network to exhibit the property of converging to a single consensus.

[0011] Preferably, at least the second node type is referred to as a client; and wherein the client is configured to submit new transactions that may affect the consensus and query information generated by the consensus of the network.

[0012] Preferably, the trust merge function is defined using idempotent, associative, and commutative computation, enabling the system to operate as a conflict-free copy data type.

[0013] Preferably, the system may further include:

[0014] A specific type of information unit called a block; the specific type of information unit, i.e., all or part of the block's order, including values ​​and units, is included as a component of trust; a state transition function capable of calculating an updated state given a certain order; one or more initial states; wherein the consensus state can be calculated by repeatedly applying the state transition function to the initial state and one or more information units that may be included in the order.

[0015] Preferably, the system may further include:

[0016] A collection of zero or more information units referred to as transactions, which are included as components of each block; optional additional information provided by peer nodes, such as timestamps or digital signatures; wherein the blocks and their constituent transactions and any additional information are arranged to be included as part of an ordering.

[0017] Preferably, the information units in the ordering are defined as those that do not contain references to one or more previous information units, so that the blocks can be reordered during the consensus process.

[0018] Preferably, the system may further include:

[0019] A device for calculating consensus ordering; wherein the device for calculating consensus ordering calculates consensus ordering as part of a trust merging function.

[0020] Preferably, the system may further include:

[0021] A device for allocating stake to peer nodes; a stake-weighted order merging process included as part of the consensus ordering computation; wherein stake-weighted order merging is used to resolve conflicts between orders proposed by different peer nodes.

[0022] Preferably, the system may further include:

[0023] A device for calculating common prefixes; wherein the computation of common prefixes between orders is used to reduce the computational cost for consensus.

[0024] Preferably, the system may further include:

[0025] A device for detecting new things; wherein a node that observes a new thing can communicate the new thing to other nodes; wherein nodes may optionally omit the communication of information about non-new things in order to save network resources and processing costs.

[0026] Preferably, the system may further include:

[0027] A means for representing information values, wherein the information values ​​are represented as one or more units;

[0028] Means for generating codes for cells, preferably in a form suitable for storage or network communication; means for smart references, which enable a reference to a cell to be included within the information and / or code of another cell; means for embedding codes within another code so that any value can be fully represented as a graph of cells connected by smart references.

[0029] Preferably, the system may further include:

[0030] A means for generating a value ID for a unit, such as a cryptographic hash function applied to encoding; wherein the value ID can be used as a unique reference for the information unit.

[0031] Preferably, the system may further include:

[0032] Convergent storage of information values; wherein, the working memory of a node only needs the information unit currently in active use, and other information units can be persistently saved to persistent storage and / or deleted when no further processing is needed, i.e., garbage collection; wherein adding new information to storage has convergent properties, thereby avoiding data inconsistency.

[0033] Preferably, the system may further include:

[0034] A means for calculating the memory size or other information value of a computing unit; a means for memory accounting; wherein the memory accounting is used to distribute incentives to participants on the network, for example, to save memory, storage and / or communication bandwidth.

[0035] Preferably, the system may further include:

[0036] A device for caching the memory size calculated for each unit or unit of information in working memory and / or storage; wherein the cached memory size is used to reduce the computational complexity of calculating the memory size for large data structures, for example, only needing to calculate the memory size for new things.

[0037] Preferably, the system may further include:

[0038] A means for arranging trusted code execution as part of a state transition function; wherein trusted code execution can be used to implement smart contracts or other programmable functions that can affect the consensus state.

[0039] Preferably, the system may further include:

[0040] One or more monotonic headers that associate header information with information values ​​and / or units; wherein the monotonic headers also provide convergence properties that can be relied upon for caching, performance optimization, and marking of unit states.

[0041] A second aspect of the present invention provides a computer-implemented method for achieving effective consensus, comprising:

[0042] Arrange one or more nodes of various types as arbitrary communication and functional participants in the network, wherein at least the first node type is referred to as a peer node, and trusts are generated by the peer nodes such that each trust contains data for forming consensus; merge one or more trusts into a trust merging function; wherein the peer nodes are arranged to maintain consensus of the network according to a consensus protocol, the consensus protocol including applying the trust merging function to the trusts; wherein the trust merging function is defined to make the network exhibit the property of converging to a single consensus.

[0043] Preferably, the trust merge function is defined using idempotent, associative, and commutative computation, enabling the system to operate as a conflict-free copy data type.

[0044] Preferably, the method may further include:

[0045] A specific type of information unit called a block; the specific type of information unit, i.e., a whole or part ordering of the block, including values ​​and units, as a component of trust; a state transition function capable of calculating an updated state given a certain ordering; one or more initial states; wherein the consensus state can be calculated by repeatedly applying the state transition function to the initial states and one or more information units that may be included in the ordering.

[0046] Preferably, the method may further include:

[0047] Calculate the consensus order; where the consensus order is calculated as part of the trust merging function.

[0048] Preferably, the method may further include:

[0049] Assigning stakes to peer nodes; a stake-weighted order merging process included as part of consensus ordering computation; wherein stake-weighted order merging is used to resolve conflicts between orders proposed by different peer nodes.

[0050] Preferably, the method may further include:

[0051] Calculate the common prefix; whereby the computation of the common prefix between orders is used to reduce the computational cost of consensus.

[0052] Preferably, the method may further include:

[0053] Detecting new things; where nodes that observe new things can communicate the new things to other nodes; where nodes can optionally omit the communication of information about non-new things in order to save network resources and processing costs.

[0054] Preferably, the method may further include:

[0055] The information value is represented as one or more units; an encoding for the unit is generated, preferably in a form suitable for storage or network communication; smart references are implemented such that a reference to a unit is included within the information and / or encoding of another unit; an encoding is embedded in another encoding such that any value can be fully represented as a graph of units connected by smart references.

[0056] Preferably, the method may further include:

[0057] Generate a value ID for the unit, such as a cryptographic hash function applied to the encoding; where the value ID can be used as a unique reference for the information unit.

[0058] Preferably, the method may further include:

[0059] The memory size or other information value of the computing unit; billing for memory; wherein the memory billing is used to allocate incentives to participants on the network, for example to save memory, storage and / or communication bandwidth.

[0060] Preferably, the method may further include:

[0061] The cached memory size is calculated for each unit or unit of information in the working memory and / or storage; wherein the cached memory size is used to reduce the computational complexity of calculating the memory size for large data structures, for example, only the memory size for new things needs to be calculated.

[0062] Preferably, the method may further include:

[0063] Trusted code execution can be incorporated as part of a state transition function; where trusted code execution can be used to implement smart contracts or other programmable functions that can affect the consensus state. Attached Figure Description

[0064] The accompanying drawings are illustrative and are intended to aid in understanding the invention and / or the embodiments described herein.

[0065] Figure 1 An example of a network of peer nodes and clients participating in the consensus method according to the present invention is described;

[0066] Figure 2 An example process is shown for merging different trusts from several peer nodes to create a single trust shared by all peer nodes;

[0067] Figure 3 This demonstrates how to update the consensus state by applying a state transition function using the consensus ordering of blocks;

[0068] Figure 4An example of peer nodes included in the voting set based on their order is shown;

[0069] Figure 5 The results of the stake voting process, which creates the winning order from the perspective of peer nodes, are shown.

[0070] Figure 6 This illustrates the difference between the consensus method of the present invention and tightly coupled traditional blockchains, where the consensus method of the present invention produces loosely coupled ordering;

[0071] Figure 7 This illustrates the process of allocating rewards through an incentive pool;

[0072] Figure 8 This illustrates the process for allocating transaction fees to a single transaction;

[0073] Figure 9 This shows the change in the ordering of individual peer nodes as part of the trust merge. Detailed Implementation

[0074] This invention relates to systems and methods in distributed ledger technology (DLT). Consensus in this environment involves digital, cryptographically protected systems and processes that provide distributed, consistent, and immutable evidence for the updating of information or the secure transfer of value between signatory parties. Consensus on DLT transactions is typically maintained by a number of peer nodes in an Internet-connected network. This invention represents a significant advancement over existing DLT techniques, addressing many performance, scalability, and cost issues of previous methods while maintaining high security even in a fully decentralized environment.

[0075] Description Overview

[0076] refer to Figure 1 The diagram provides an example of a network of peer nodes and clients participating in the consensus method according to the present invention, and is an overview of the network.

[0077] Peer nodes utilize a method to operate independent nodes in the network in order to reach a consensus on information of interest to network participants (often referred to as the consensus state). Clients are typically interested in observing or altering the consensus through transactions. Implementation examples can support applications such as:

[0078] Execute the "smart contract";

[0079] Establish verifiable public resources;

[0080] Operating decentralized applications, such as financial services;

[0081] Publish digital intellectual property rights and receive micropayments;

[0082] Provide trusted public databases and public key infrastructure for authentication;

[0083] Provide custody or parallel services for complex financial transactions.

[0084] The objectives of the embodiments of the present invention include, but are not limited to:

[0085] Trustless consensus can be achieved even if a malicious actor attempts to invalidate the consensus or steal resources from other participants;

[0086] Low latency, achieving global consensus in approximately 1 second;

[0087] High throughput, reaching tens of thousands of transactions per second;

[0088] Ensure transaction ordering, including preventing "double-spending" attacks;

[0089] General-purpose computing enables any "smart contract" to become part of the on-chain protocol;

[0090] Efficient processing and memory usage are proportional to the number of transactions rather than the size of data blocks representing on-chain state.

[0091] Implementations using consensus methods may only need to process the portion of the state currently used and needed in fast access memory. Working memory requirements are proportional to the amount of work done and are limited by the transaction size. Furthermore, due to convergent immutable storage or shared structure, it may only be necessary to share delta (changes) with peer nodes.

[0092] The consensus method operates on a network of decentralized peer nodes that have reached a consistent, replicable state and confirmed transaction completion. It ensures that all participants agree on a single version of the truth using stake-weighted voting. Every decentralized economic system needs to enforce ownership of digital assets. It can use "delegated proof-of-stake" to avoid wasting the resources and energy required by the "proof-of-work" method. An implementation using the on-chain consensus method is environmentally friendly by incorporating a variant of "conflict-free replicated data type" (CRDT), which converges to consensus after several rounds of random gossip among peer nodes.

[0093] A consensus method operates a defined protocol (“consensus protocol”) on one or more distributed peer nodes as network operations. Consensus is reached after the peer nodes agree on the validity of a set of data and the transactions associated with the generation of that data. During processing, a virtual state representing the configuration of information managed by the network is derived. Resources such as smart contracts or arbitrary data are controlled through cryptographic mechanisms to prevent unauthorized access or modification. Transactions can be applied to update the state, such as transferring funds from one account to another, modifying data, or invoking computations such as smart contracts.

[0094] As a better alternative to the conceptual understanding of blockchain methods, systems and methods for achieving consensus on the ordering of information units in on-chain distributed ledger domains and off-chain client portals include multiple nodes of various types arranged as arbitrary communication and functional participants in a network; a first node type, namely peer nodes, arranged to maintain the consensus of the network; a second node type, namely clients, arranged to query the consensus of the network; and wherein the computation of consensus for each peer node is managed by a trust merging function that merges the trust shared by the peer nodes to create an updated trust.

[0095] This invention discloses a system and method for achieving effective consensus in a distributed computing environment, comprising:

[0096] Multiple nodes of various types are arranged in a network as arbitrary communication and functional participants, where the first node type is called a peer node, and

[0097] The optional second node type is called a client;

[0098] The peer nodes are configured to maintain consensus in the network.

[0099] The client is configured to submit new transactions that may affect the consensus and query information generated by the consensus of the network.

[0100] Peer nodes generate information units (called trusts), where each trust contains information related to the consensus known to a given peer node.

[0101] The computation of consensus for each peer node is controlled by a trust merging function, which merges the trusts shared by peer nodes to create newer trusts. The trust merging function satisfies mathematical properties that guarantee convergence to a consensus value (under certain assumptions) (preferably idempotent, associative, and commutative computation), and even allows for the existence of some malicious peer nodes.

[0102] This trust contains information from multiple peer nodes, which can be digitally signed to prove authenticity and integrity.

[0103] The second node type (client) is configured to submit transactions (which may include new information) that are consistent with those of the first node type (peer node).

[0104] Additional node types, besides client and peer nodes, can have additional roles and can combine the functions of client and peer nodes.

[0105] The calculation of the consensus value involves a complete or partial ordering of some information units, where these units are independent of each other (e.g., do not need to contain references to previous information units), so that they can be ordered differently depending on the progress of the consensus algorithm.

[0106] An information unit is a block proposed by a peer node and may include:

[0107] - A collection of zero or more individual transactions that have been collected from the client.

[0108] - Additional information provided by peer nodes, such as timestamps or digital signatures.

[0109] - Any other information that may affect the network's consensus computation.

[0110] These blocks do not contain references to one or more previous blocks, thus allowing them to be reordered during consensus processing.

[0111] Ordered information units are used to compute states by repeatedly applying state transition functions, so that each peer node can independently and reliably compute the exact same state given the ordering already determined by the consensus system and any other relevant information included in the consensus computation.

[0112] The trust merging function computes (actual or proposed) consensus based on votes received from the trusts of other peer nodes, where each vote represents a peer node’s preference for the next unit of information to be included in the ordering.

[0113] In the sorting process, votes for each information unit are parsed sequentially. Peer nodes that voted for the "winning" information unit are given greater weight (or are fully allowed to have their votes counted in subsequent information units) (this process is called stake-weighted sorting merge).

[0114] The computation of common prefixes among orderings proposed by different peer nodes can be used to efficiently determine the degree of consensus among peer nodes regarding their respective orderings.

[0115] The first type of node, the peer node, is assigned an economic stake (which can be zero). The voting weight of the peer node is adjusted by the amount of economic stake placed on the consensus. This economic stake can be placed by the owner of the peer node, or by interests delegated by other participants, or a combination of both.

[0116] The system improves bandwidth efficiency and manages memory consumption by scaling resource requirements in a manner proportional to the number of new transactions (in contrast to the size of the total on-chain state).

[0117] The system only shares observed changes / new things (e.g., new transactions representing new things that were not previously seen) between nodes, plus any structural or billing overhead, and can omit information that has already been communicated.

[0118] In the system according to any one of the preceding claims, the information unit is defined as a canonical encoding having a low-level information format (e.g., a sequence of bytes).

[0119] Encoding can generate a unique value ID for each different information unit value through a cryptographic hash function, so that the value ID can be used as a reference to the information unit itself.

[0120] Value IDs can be embedded as references in the encoding of other information units, so that these references form a Merkle DAG (Directed Acyclic Graph).

[0121] Only information units currently in use need to be in the node's working memory, and other information units can be persistently stored in persistent storage and / or garbage collected (which can be automatic, for example, provided by the Java Virtual Machine).

[0122] Any unit of information in memory or storage may be associated with header information that can be incrementally computed or cached, and may be constructed such that changes to the header are monotonic relative to the values ​​in the header.

[0123] Provide a function to calculate a value representing the memory size of an information unit, which may include, for example, the size of the encoding plus a allowance for memory overhead.

[0124] The memory size calculation can be increased based on the memory size of any referenced information unit, such that the total memory size represents the size of the entire Merkle DAG.

[0125] The memory size is cached along with the information units (in the node’s working memory and / or storage), so that the memory size can usually be efficiently calculated without traversing the entire Merkle DAG.

[0126] Memory size is used in memory-billed systems and can be used to generate economic incentives, such as charging a fee for processing transactions with large memory sizes or increasing the overall size of the state in a state transition function.

[0127] Economic incentives include rewards for reducing memory size, thus motivating participants to use system resources more efficiently.

[0128] Performance, efficiency and utility

[0129] This invention is designed to improve transaction throughput and latency, especially compared to the inefficient Proof-of-Work consensus method, which relies on forcing nodes to undertake computationally expensive tasks (which typically do not add value to the network except for enhancing security).

[0130] This invention preferably achieves low latency by avoiding any requirement for wasteful work, featuring effective value encoding highly suitable for efficient storage and communication. It employs data structures and algorithms ideally suited for high performance (e.g., structure sharing in immutable values, Merkle trees, and common prefix computation).

[0131] Preferably, the embodiment allows peer nodes to operate in a loosely coupled manner (see...). Figure 6 It also proposes a block ordering method to improve latency and transaction throughput, which avoids the need to sequentially append blocks in a tightly coupled blockchain.

[0132] Preferably, the embodiments further improve latency by implementing a phased event-driven architecture (sometimes referred to in the art as SEDA), which facilitates asynchronous processing of messages as soon as a node or a component in a node is able to process them.

[0133] Safety Precautions

[0134] Typically, some participants in a network are not trusted; for example, they might attempt to disrupt or manipulate consensus in an unauthorized manner. These untrusted actors are sometimes referred to as "Byzantine" or "Sybil" actors. Implementations of the network preferably implement "Byzantine fault tolerance," meaning they are robust to unauthorized updates (intentional or otherwise) from multiple bad actors.

[0135] Consensus is preferably designed to be stable once established. Actors may need to rely on guarantees that transactions have been completed. Without such guarantees, actors may face significant economic risks if transactions are subsequently canceled or rolled back.

[0136] Preferably, the embodiments utilize strong digital signature methods (such as Ed25519) so that they can verify the authenticity of information shared on the network.

[0137] Description of the present invention with reference to the accompanying drawings

[0138] refer to Figure 1 An example of a network of peer nodes and clients participating in the consensus method according to the present invention is shown.

[0139] exist Figure 1 In the attached diagram, the reference numerals indicate:

[0140] 11 - A group of peer nodes participating in the consensus system.

[0141] 12 - Connections between peer nodes can be opened and closed at different times, and communication of information is allowed when open. Not every peer node needs to be connected to every other peer node at all times.

[0142] 13 - A peer node that is only connected to another peer node, but is still indirectly connected to the entire network.

[0143] 14 - A group of clients that connect to their peers and use that connection to submit new transactions or make queries to the network.

[0144] 15. Connection between the client and peer nodes.

[0145] More specifically, a group of peer nodes

[11] are directly connected to each other

[12] or indirectly connected to each other

[13] . A group of clients

[14] establish connections

[15] to participate in the network.

[0146] Figure 2 An example process is shown for merging different trusts from several peer nodes to create a single trust shared by all peer nodes.

[0147] exist Figure 2 In the attached diagram, the reference numerals indicate:

[0148] 21-A group of peer nodes participating in the consensus system, each with initial trust.

[0149] 22 - Clients (or peer nodes) generate new things in the form of 21 or more transactions.

[0150] 23- The client communicates new information to at least one peer node (this step can be omitted if the client itself is also a peer node).

[0151] 24 - A method of incorporating new things by including them in the trust of at least one peer node.

[0152] 25 - Transmit the updated trust from one peer node to other peer nodes in the network.

[0153] 26 - A process of executing a trust merging function performed by a peer node, combining its most recent trust with trust received from one or more other peer nodes to produce an updated trust.

[0154] 27 - Data is maintained by a single participant, displaying a timeline.

[0155] 28 - For a period of time, the trust for transmission and merging updates (as in 25. and 26.) is repeated iteratively until the new thing introduced by 22 is confirmed by a sufficient number of peer nodes as part of a stable consensus.

[0156] 29 - Peer nodes that now agree on new things and are able to use state transition functions to compute updated consensus states.

[0157] 210 - Any client interested in the consensus result (which may include the original client) can observe the consensus result and receive confirmation that new things have been successfully included.

[0158] More specifically, a client

[22] (which may also be a peer node) submits one or more transactions

[23] , which can be considered new. A group of peer nodes

[21] participate in the consensus process, each with an initial trust. The process

[24] incorporates the new by including it in the trust of at least one peer node

[21] . The transmission of updated trusts

[25] is transmitted from the first peer node to the other peers in the network

[21] . The process

[26] executes a "trust merging function" performed by each peer node, combining their own most recent trust with the trust received from other peer nodes to produce updated trusts. Each peer node

[21] maintains its own trust data during and after the merging process

[27] . The time period

[28] represents the iterative transmission and merging of updated trusts [24, 25, 26] until the new introduced by the client

[22] is consistently acknowledged by a sufficient number of peer nodes. After consensus is reached, the peer nodes

[29] are now able to compute the updated consensus state using the state transition function. Any client

[210] that may include the original client

[22] may query the consensus to confirm a successful trust merge and access other information in the new consensus state.

[0159] Figure 3 It demonstrates how to update the consensus state by applying a state transition function and using the consensus order of blocks.

[0160] exist Figure 3 In the attached diagram, the reference numerals indicate:

[0161] 31 - Multiple blocks in the sort, which is considered the current consensus sort.

[0162] 32 - The set of additional blocks that will be included in future proposed orderings (in addition to consensus ordering).

[0163] 33 - Additional blocks beyond the consensus proposed, which may contain new blocks submitted by peer nodes or clients.

[0164] 34 - Initial state, used as input to the state transition function of the first block.

[0165] 35 - Application of state transition functions, which use the state and the corresponding block to calculate the next state.

[0166] 36 - Consensus state, for example, the state after all blocks in the consensus order have been processed by 35.

[0167] 37 - The sequence of states generated from the initial state to the consensus state.

[0168] 38 - Optional: Predict future state updates based on possible future consensus ordering, which means what state will result from applying the state transition function to the block in 32 and 33.

[0169] More specifically, starting from the initial state

[34] , a set of blocks in the consensus order

[31] is processed in repeated steps through the state transition function

[35] until a consensus state is reached

[36] . Additional blocks in the “order” [32 and 33] may optionally be used to predict possible future consensus states

[38] , although this has not yet been confirmed in the consensus.

[37] denotes the computation of the full sequence of states up to and including the consensus state.

[0170] Figure 4 An example is shown of peer nodes included in the voting set based on the order of the voting set.

[0171] exist Figure 4 In the attached diagram, the reference numerals indicate:

[0172] 41 - The beginning of the consensus order under consideration (usually the first block in the order).

[0173] 42 - The consensus point of the current peer node that performs the trust merge, which defines the current consensus from the perspective of that peer node.

[0174] 43 - Current peer node sorting.

[0175] 44 - The ordering of peers that have the same consensus as the current peers, but may differ in subsequent blocks.

[0176] 45 - Has a consensus ordering that is longer than that of the current peer node, but is compatible with some other peer node orderings at least up to the current consensus

[42] .

[0177] 46 - The ordering of some other peers that has a shorter consensus ordering than the current peer, but whose proposed ordering is otherwise the same as that of the current peer up to

[42] .

[0178] 47 - A peer ordering that has a shorter consensus ordering than the current peer and whose subsequent orderings contain one or more blocks that differ from the consensus up to

[42] and therefore must be excluded.

[0179] 48 - If there are blocks that are insufficient to be compared with the current consensus, the peer order of that peer node must be excluded.

[0180] 49 - The consensus ordering announced by peer nodes is incompatible with the current consensus and therefore must be excluded (and may be penalized).

[0181] 410 - A set of peer nodes will be included in the voting set because they are compatible up to the consensus point

[42] .

[0182] 411 - The set of peers that will be excluded from the voting set because their order is not equal to that of the current peers (up to the current consensus point

[42] ).

[0183] 412 - Observe a subset of the ordering that matches the current peer node up to the consensus point

[42] .

[0184] 414 - Sort length by the number of blocks.

[0185] The ordering of blocks other than 415-

[42] is unrelated to consistency.

[0186] 416 - Blocks that match the consensus ordering of

[43] , are in the ordering of

[46] , but are not yet in the consensus ordering of

[46] .

[0187] The position of block 417 is inconsistent with the consensus order of

[43] .

[0188] 418 - Shade blocks that do not match

[412] or exceed

[412] .

[0189] 419 - Map blocks that match

[412] but are not sorted by consensus.

[0190] 420 - Map the blocks in the consensus order of the corresponding peer nodes.

[0191] Peers are included or excluded based on their consistency with the consensus ordering of the current peer

[43] . The current peer considers the consensus ordering to be the blocks between

[41] and

[42] in its own ordering. Peers

[44] ,

[45] , and

[46] are all consistent because their ordering matches the consensus ordering

[412] of the current peer

[42] , beyond which additional blocks in the ordering

[415] are never considered inconsistent. Peers

[47] ,

[48] , and

[49] are excluded because of inconsistency

[417] when compared with the consensus ordering of

[43] . Peer

[47] is excluded because its ordering

[418] contains one or more inconsistent blocks. Peer

[48] is excluded because its entire ordering is shorter than point

[42] and therefore cannot match. Peer

[49] is excluded because some blocks between

[41] and

[42] are inconsistent with

[43] .

[410] is a set of peer nodes to be included in the voting set.

[411] is a set of peer nodes to be excluded from the voting set.

[412] is a subset of the ordering that matches the consensus ordering of

[43] .

[414] indicates the ordering length.

[415] is an additional block that is not related to consistency.

[416] is a consistent block that is not yet in the consensus ordering of peer node

[46] .

[417] is a point of inconsistency.

[418] indicates that the block does not match the position of

[412] or is beyond the position of

[412] .

[420] indicates a block in the consensus ordering of each peer node.

[0192] Figure 5 This shows the results of the stake voting process that creates the winning ordering from the perspective of peer nodes.

[0193] exist Figure 5 In the attached diagram, the reference numerals indicate:

[0194] 51 - Current peer node.

[0195] 52 to 58 - Other peer nodes in the initial voting set (column width indicates proportional voting weight).

[0196] 59 - Start of sorting (first block).

[0197] 510 - (The current consensus point of peer node 51).

[0198] 511 - The length of the sort.

[0199] 512 - Winning order after all voting rounds are completed.

[0200] 513 - Symbols A through H represent different blocks included in the ordering of various peer nodes.

[0201] Round 521 results: Block A wins.

[0202] The result of round 522: Block B wins (among the peer nodes that voted for A in round 521).

[0203] The result of round 523: Block C wins (among the peer nodes that voted for B in round 522, the majority of voters for D have been excluded).

[0204] The result of round 524: Block D wins (among those who previously voted for A, B, and C).

[0205] Round 525 results: Block E wins (peer node 53 has an advantage over peer node 54).

[0206] Round 526 results: Block F wins (by default, only peer node 53 is retained).

[0207] 530 - Map blocks that are not part of the winning sort.

[0208] 531 - To trace the blocks that form part of the winning sort in each round.

[0209] 532 - Map blocks that are already in agreement with the consensus order.

[0210] Peer

[51] is the current peer with the current consensus ordering from

[59] to

[510] and proposes five new blocks specified by arbitrary symbols [A, C, D, E, F]. Each of the other peers [52 to 58] also has an ordering that matches the consensus ordering up to

[510] and their own proposals for future blocks [AH] in their ordering, some of which can match blocks proposed by other peers. Peer nodes [51-58] together comprise the considered “vote set” (see Figure 4 Note that for each peer ordering, the proposed blocks are not in the same order. Consensus was reached after six rounds of voting.

[0211] Round 521: Five peer nodes [51 to 55] vote, and block A should be the next in the order and win this round;

[0212] Round 522: In the remaining peer nodes of Round 521, Block B was won by four peer nodes [52 to 55] through voting;

[0213] Round 523: Block C was won by a vote from three peer nodes [53, 54, 55].

[0214] Round 524: Block D was won by two peer nodes [53 and 54] through voting;

[0215] Round 525: Block E was won by a peer node

[53] through voting;

[0216] Round 525: Block F wins by default because it is voted by the only remaining peer node in the voting set

[53] , thus resulting in the final winning order

[512] .

[0217] Shaded:

[530] indicates a block that is not part of the winning order,

[531] indicates a block that is part of the winning order in each round, and

[532] indicates a block that is already in line with the consensus order.

[0218] The width of the peer order [51-58] in the diagram indicates the voting weight, which is proportional to the stake of the peer nodes.

[0219] Figure 6 The differences between the consensus method of the present invention and tightly coupled traditional blockchains are illustrated, with the consensus method of the present invention producing loosely coupled ordering.

[0220] exist Figure 6 In the attached diagram, the reference numerals indicate:

[0221] 61 - A traditional tightly coupled blockchain with pointer 64 embedded in block 62.

[0222] 62 - Blocks in traditional blockchains.

[0223] 63 - A pointer to the latest block in a traditionally tightly coupled blockchain.

[0224] The pointers within block 64 point to previous blocks (and indirectly to all previous blocks by repeating this process), so that the encrypted hash value is used as a pointer to ensure the integrity between a block and its previous history.

[0225] 65 - Consensus based on ordering.

[0226] 66 - A block in an order that is independent of other blocks (excluding pointers to previous blocks).

[0227] 67 - Sorted data structures (which are typically cryptographically verifiable structures, such as Merkle trees that allow robust integrity checks) maintain a list of blocks in a well-defined sort.

[0228] 68 - A pointer to a sorted data structure (possibly the ID of the root cell in the sorted value).

[0229] 610 - A comment used to indicate a pointer to a block / other data structure (usually a cryptographic hash).

[0230] The sorting should not be implemented as a tightly coupled linked list of blocks

[61] with pointers

[64] that include a hash of the previous block

[62] in each block. Preferably, the sorting should be loosely linked

[65] compared to a conventional “tightly linked chain”

[61] . Pointers

[68] are linked to a data structure

[67] , which may be a cryptographically verifiable structure such as a Merkle tree for representing the sorting. This allows robust integrity checks to maintain a list of blocks in a well-defined order. Blocks

[66] in a “loosely linked” sorting are independent of other blocks, i.e., they do not contain pointers to previous blocks.

[0231] An optional pointer

[63] can be used to specify the last block in the sort.

[610] represents a pointer of any type.

[0232] Figure 7 The process of allocating rewards through an incentive fund pool is illustrated.

[0233] exist Figure 7 In the attached diagram, the reference numerals indicate:

[0234] 71-Government Account.

[0235] 72 - Long-term block reward pool.

[0236] 73 - Current block reward pool.

[0237] 74-Peer Node Rights 1.

[0238] 75 - Peer Node Rights 2.

[0239] 76-Peer Node Rights 3.

[0240] 77-Fund Allocation.

[0241] 78-Release of Funds

[0242] 79 - Distribute the weighted rewards to the best peer node 1.

[0243] 710 - Distribute the weighted rewards to good peer nodes 2.

[0244] 711 - Remove the stake from bad peer node 3 and return it to the current block reward pool.

[0245] Construct rewards from a set of block reward incentive pools, where:

[0246] The governance account

[71] maintains a record of all rewards and

[77] transfers a large amount of funds to the long-term block reward pool

[72] ;

[0247] The short-term incentive reward pool

[73] is designed to reward peers who are currently operating and to pay out relatively quickly [79,710] to add equity to good peers [74,75];

[0248] The long-term reward pool

[72] is used to "fill" the short-term reward pool over time

[78] to ensure that peer nodes [74-76] are adequately incentivized to perform long-term operations;

[0249] Preferably, over time, rewards accumulate from the following positive peer nodes:

[0250] Transfer funds to the reward pool, for example [77,711];

[0251] Shift from long-term reward pools to short-term reward pools

[78] ;

[0252] Optionally, transaction fees paid by client transactions can be added to a short-term reward pool

[73] for sharing by current stakeholders;

[0253] Receive rewards from the short-term reward pool [79,710].

[0254] Bad peers

[76] can be penalized by “reduction”

[711] , in which a portion of their stake is deducted and returned to the short-term reward pool

[73] .

[0255] Figure 8 The process for allocating transaction fees to a single transaction is shown.

[0256] exist Figure 8 In the attached diagram, the reference numerals indicate:

[0257] 81 - Client Account.

[0258] 82 - Reserved transaction funds.

[0259] 83 - Current block reward pool (see 73 for other uses of this pool).

[0260] 84 - Peer-to-peer node rights.

[0261] 85 - Allocate funds for signed transactions (place them in reserves).

[0262] 86 - Execution fees based on the cost of executing transactions or smart code.

[0263] 87 - Optional transaction fees are paid directly to peer nodes.

[0264] 88 - Block fee paid by peer nodes for submitting blocks, which is shared by multiple transactions.

[0265] 89 - Any remaining transaction funds not consumed by fees are returned to the client.

[0266] When a transaction is initiated, a certain amount of funds is withdrawn from the user's account

[81]

[85] and placed into a reserve to pay for the transaction

[82] .

[0267] During transaction execution, all Ops and runtime functions charge a small “juice” cost based on the computational complexity of the executed code. The total juice cost of the transaction is multiplied by the juice price to calculate the total execution cost in cash

[86] , which is transferred

[86] to the current block reward pool

[83] .

[0268] Optional direct fees

[87] can be paid to the peer responsible for submitting the transaction by adding them to the peer stake

[84] .

[0269] After all fees have been paid, the remaining reserve funds are returned to the user's account

[89] . Optional block fees

[88] can be paid by peers in their stake

[84] (which can be shared among multiple transactions).

[0270] Figure 9 This shows the change in the ordering of individual peer nodes as part of the trust merge.

[0271] exist Figure 9 In the attached diagram, the reference numerals indicate:

[0272] 91 - Blocks already in the consensus order.

[0273] Blocks 92 to 99 - Blocks proposed for consensus.

[0274] 911 - Initial peer ordering (consensus ordering plus additional blocks).

[0275] 912 - The winning order is determined by a weighted sorting and merging process.

[0276] 913 - features a new ordering with additional blocks 98 and 99 added in timestamp order.

[0277] 914 - A new ordering with updated consensus ordering (moving forward to the new consensus point 917).

[0278] 915 - The beginning of the chain.

[0279] 916 - Initial consensus point.

[0280] 917 - A new point of consensus.

[0281] The order of peer nodes can be updated based on the equity-weighted sorting and merging process:

[0282] Peer nodes begin with the sorting in the first column

[911] ;

[0283] The winning order is calculated by merging the stake-weighted sorts of the peer nodes with their sorts from other peer nodes (second column

[912] ), see also Figure 5 ;

[0284] Peer nodes add additional blocks [98, 99] to the timestamp sort as needed to form their final updated sort

[913] ;

[0285] Finally, in

[914] , consensus moves to

[917] , depending on the calculation of the consensus order, which determines which blocks have sufficient support to be included in the consensus order;

[0286]

[91] Between the start of the consensus order

[915] and the current consensus position

[916] , specify any number of blocks that are already in the consensus order. [92-99] Specify blocks other than

[91] .

[0287] Description of key components

[0288] This document uses definitions of terms that may have specific meanings in the context of this invention, and these are generally indicated by capitalized first letters. For convenience, definitions are provided in alphabetical order, but other definitions and figures may be referenced as needed.

[0289] Account

[0290] Alternatively, one embodiment may include an account model, in which case the following paragraphs apply:

[0291] An account is an entity that can be owned or controlled by participants on a network.

[0292] Preferably, the status may include information about each account, such as:

[0293] Code uploaded by users for trusted code execution;

[0294] Information values ​​controlled by the account;

[0295] Security-related information, such as public keys used to verify transactions submitted for an account, or random numbers (arbitrary numbers that can only be used once in encrypted communication) used to prevent replay attacks.

[0296] Preferably, access control is implemented so that only properly authorized clients (e.g., verified by digital signatures) can control the account.

[0297] Preferably, the account is identified by referencing a unique identifier (e.g., an account address). This identifier should preferably remain consistent between status updates.

[0298] Alternatively, the account can be an autonomous actor account that cannot be controlled by external users. It operates according to predefined logic executed by a consensus protocol (such as trusted code execution). Actors are typically used to implement smart contracts.

[0299] Preferably, the embodiments have additional facilities to support the security of managed accounts, such as rotating public keys or setting access control rules that affect other accounts.

[0300] trust

[0301] Trust is a set of information that represents the consensus information held by peer nodes.

[0302] Preferably, trust is implemented as a single immutable value, representing a snapshot of the peer's understanding at a specific time.

[0303] Preferably, trust may include the following information:

[0304] The latest known ordering of blocks announced by each peer node;

[0305] A list of all blocks (or equivalent transactions) that are validly included in the consensus;

[0306] A set of transactions or blocks proposed for consensus, perhaps as an order of the proposals;

[0307] The state of the network at different points in time, such as a list of states after each block update;

[0308] A set of trusts, or data extracted from trusts held by other peer nodes.

[0309] Preferably, trust is implemented using a persistent, immutable data structure that includes a tree of units that share structural information.

[0310] Preferably, in most cases, it is only necessary to communicate incremental changes to trust (which may be classified as new things) between peer nodes in the network.

[0311] A trust can be considered "valid" if it satisfies the protocol used to create it. A valid trust must be formed by correctly applying the protocol using the data contained within it, and must be consistent with any previous trusts broadcast by other peer nodes. Preferably, the trust is stored as a single unit or value, which may contain nested values.

[0312] Preferably, the trust may include information from one or more other peer nodes, which may optionally sign it with a digital signature to prove its authenticity and integrity.

[0313] Trust merge function

[0314] The trust merging function calculates a new trust based on one or more other trusts.

[0315] Preferably, the trust merging function is a purely deterministic function of the following form:

[0316] B = F(E, B1, B2, ...., BN)

[0317] in:

[0318] B = New Trust Generated

[0319] E = Additional context information held by peer nodes

[0320] B1…Bn = Existing trust held by this peer or received from other peers.

[0321] Preferably, the properties of F are:

[0322] The relationship in trust is that F(E, B1, F(E,B2, B3)) equals F(E, F(E, B1, B2), B3);

[0323] The exchangeability of trust, i.e., F(E, B1, B2) = F(E, B2, B1);

[0324] Idempotency, i.e., F(E, B1, F(B1, B2)) = F(E, B1, B2).

[0325] Preferably, the embodiment uses this form of trust merging function, in which the properties of F are sufficient to ensure that the trusts combined using the trust merging function constitute a conflict-free replicated data type (CRDT) and have convergence. Applying the trust merging function to two or more valid trusts also produces valid trusts. This guarantees effective consensus under reasonable operating conditions.

[0326] Block

[0327] A block is a collection of zero or more data values ​​that make up a transaction.

[0328] Preferably, the state update is computed all at once over the entire transaction block. The block can be submitted simultaneously by peer nodes known as block producers.

[0329] Preferably, transactions are ordered within a block in a manner that precisely defines the order in which they must be executed. However, in one embodiment, for efficiency purposes, transactions that do not affect each other (i.e., do not have direct data correlation) can be reordered or computed in parallel, as long as such reordering does not affect the resulting state.

[0330] In embodiments of the invention, blocks are not essential. For example, each transaction can be executed independently, but blocks do offer some advantages for embodiments of the invention:

[0331] Peer nodes that transmit valid transactions can sign the entire block, rather than each individual transaction;

[0332] Batch state updates reduce the frequency at which state updates will be transmitted and stored;

[0333] It can incentivize peer nodes to execute effective transaction groups.

[0334] Preferably, compared to traditional blockchains, blocks do not need to contain references to previous blocks [see...]. Figure 6 Blocks can be reordered during the consensus process without invalidating previous references.

[0335] Alternatively, in addition to executing individual transactions, block execution can also perform processing such as updating the state to incorporate the timestamp of the latest block, or executing per-block billing. This can be considered equivalent to implicitly including one or more automatic "per-block" transactions.

[0336] In this document, blocks and transactions are used interchangeably, and the differences are irrelevant.

[0337] cell

[0338] A unit is a sub-component of a value, which allows large values ​​to be represented by multiple units (although small values ​​can also be a single unit).

[0339] Implementations may choose not to distinguish between values ​​and units, but the ability to make such a distinction can provide various conceptual and implementation advantages.

[0340] Preferably, large values ​​are represented as a tree data structure of multiple units. Some consistent units can be values ​​themselves, such as individual values ​​contained in a list data structure.

[0341] Preferably, the top-level cell contains references to multiple sub-cells. This allows large data structures to be represented as directed acyclic graphs (DAGs) of cells and / or smart references to cells.

[0342] Preferably, the cells should be impossible to contain circular references. This can be ensured, for example, by making all cells immutable and using cryptographic hash values ​​as identifiers, making it impossible to construct cells that directly or indirectly reference themselves.

[0343] Preferably, the size of each valid unit is limited by a maximum limit on the size of the data that can be encoded in a single unit. This allows all units to be represented within a fixed-size memory buffer.

[0344] In this document, terms, units, and values ​​are used interchangeably, especially where the differences are inconsequential.

[0345] Client

[0346] A client is a participating node in the network that performs roles other than maintaining consensus. Clients typically perform one or more of the following activities:

[0347] - Observe or query various aspects of the consensus status

[0348] Submit the transaction to the peer nodes that will be included in future consensus.

[0349] A peer node can also act as a client when performing actions other than maintaining consensus. For example, if a peer node submits a transaction that increases its stake, it acts as a client.

[0350] Common prefix calculation

[0351] Common prefix computation is a method for calculating the longest consecutive number of elements in two ordered sequences that are matched starting from the beginning of the sequences (sometimes referred to as the "longest common prefix" in computer science literature).

[0352] For example, consider two ordered sequences:

[0353] [A, B, C, D, F, G]

[0354] [A, B, C, G, D]

[0355] In this case, the common prefix is ​​[A, B, C] with a prefix length of 3.

[0356] Preferably, peer nodes use common prefix computation to compute the consistency of two or more orderings. For example, any ordering proposed by a peer node is consistent with the consensus ordering only if the length of the common prefix is ​​equal to the total length of the consensus ordering.

[0357] Preferably, common prefix computation is implemented using a data structure that allows for prefix computation in less than O(n) time, where n is the length of the structure being compared. For example, O(log n) can be achieved through a preferred embodiment. Conventional (naive) algorithms may have unacceptable performance for checking common prefixes of long sorts, operating in O(n) time, where n is the length of the sort being compared. They may need to process millions of blocks with unacceptable wait times and prohibitive computational costs.

[0358] Preferably, the common prefix computation combines a Merkle tree, i.e., a tree with embedded cryptographic hashes, with a tree structure (e.g., a radix tree) to compute the common prefix length. Therefore, efficient prefix computation is possible in O(log n) time. One embodiment can be implemented as follows:

[0359] Store the sequence of elements as a "vector", where a vector is a data structure that contains a sequence of arbitrary values;

[0360] Implement the vector as a tree (e.g., a radix tree), where each tree node has a limited number of child nodes, such as up to 16;

[0361] Calculate the cryptographic hash value of each node and include it in the parent node (“Merkle tree”);

[0362] Examine the hash value in each tree node to find the first pair of nodes with different hash values ​​(meaning the two nodes must contain the first difference), and recursively examine these two nodes until the position of the first different element is found.

[0363] Calculate consensus order

[0364] The consensus ordering calculation is a method for peer nodes to determine a new consensus ordering, preferably implemented as part of a trust merging function in an embodiment, such as... Figure 2 , Figure 5 and Figure 9 As shown.

[0365] Preferably, peer nodes are able to compute the consensus order of updates based on information contained in the trust (most commonly trusts merged with updates from other peer nodes).

[0366] Preferably, this trust includes an ordering proposed by other peer nodes in the network, such that the computation can rely on this information. This can be achieved mathematically idempotent, for example, by including an ordering with the latest timestamps from each peer node.

[0367] Preferably, the computation is performed in a mathematically idempotent manner, such that it satisfies the desired properties to be included in the trust merging function.

[0368] Preferably, the updated consensus order will be equal to the previous consensus order, plus zero or more additional blocks confirmed in the new consensus.

[0369] Preferably, the new consensus ordering will include all blocks proposed for consensus by the defined portion of the participating peer nodes (e.g., 2 / 3 of the peer nodes determined by stake weights).

[0370] Preferably, the calculation includes a method for enabling peer nodes to distinguish between their actual consensus ordering and their proposals for a new consensus ordering (“proposed ordering”). For example, peer nodes may communicate a longer ordering along with two numbers indicating the number of blocks (numbered from the beginning of the ordering) that the peer node considers to be in the latest consensus ordering, and the number of blocks that it considers to be in the proposed ordering. Additional blocks may exist in orderings beyond these numbers that are neither in the peer node’s consensus ordering nor in the peer node’s proposed ordering.

[0371] Preferably, peer nodes will use a “two-phase commit” approach in the computation, whereby they first create a proposal ordering and then confirm it as a new consensus ordering only if the proposal is confirmed by a sufficient number of other peer nodes (e.g., 2 / 3 of the peer nodes determined by stake weights).

[0372] Preferably, if peer nodes determine that this may lead to a new consensus ordering, they will propose a new proposed ordering. For example, once a sufficient number of other peer nodes are observed placing the same block in the same position in their respective orderings (e.g., 2 / 3 of the peer nodes determined by stake weights), they may include the block only in the proposed ordering, such as... Figure 5 As shown.

[0373] Preferably, for blocks that peer nodes cannot confirm in the "consensus ordering" or "proposal ordering" (possibly because none of the competing proposals have sufficient votes), peer nodes should construct an ordering that includes these blocks, which are most likely to be supported by other peer nodes in the future, thereby facilitating convergence towards common consensus. Stake-weighted ordering merging can be used for this purpose.

[0374] Preferably, the entire computation is constructed to have the property that trust merging is repeatedly applied by all peer nodes to converge to a single consensus order, assuming the following properties, for example:

[0375] A sufficient proportion of peer nodes correctly follow the protocol (e.g., 2 / 3 of the voting rights).

[0376] The network remains connected, allowing peer nodes to communicate directly or indirectly.

[0377] See “Consensus Properties and Proofs” for a more detailed description of this structure, as it can be applied to exemplary implementations.

[0378] consensus

[0379] Consensus is the agreement among a group of network nodes on one or more information values.

[0380] An information value can be described as "in consensus" if it is directly agreed upon by peer nodes according to the consensus protocol (e.g., the order of blocks), or if it can be calculated from values ​​already in consensus (e.g., the latest consensus state calculated from previous blocks).

[0381] Preferably, the consensus is designed to include a consensus state that is agreed upon by the network participants.

[0382] Preferably, the consensus is designed to include a consensus order, which can be used to compute the consensus state and / or any state prior to the consensus state (potentially returning to the initial state).

[0383] exist( Figure 3 The document provides an illustration of a consensus state update that can be implemented in an embodiment.

[0384] Consensus ordering

[0385] Consensus ordering is the ranking of blocks (or equivalent transactions) that have been confirmed by peer nodes in the consensus, such as... Figure 3 As shown.

[0386] Preferably, given a consensus order, peer nodes can compute a consensus state for any previous state and a corresponding subsequence of blocks between that state and the end of the consensus order by repeatedly applying the state transition function.

[0387] Consensus properties and proof

[0388] Preferably, the consensus protocol can be shown to converge to a stable consensus that is assumed to satisfy relevant assumptions and can be considered final by the participants in the network.

[0389] Preferably, the only block included in the consensus is a valid block that has been proposed by a peer node, for example, verified by a digital signature provided by such a peer node. A small number of bad peer nodes will prevent bad blocks from being accepted.

[0390] Preferably, the proposal order and consensus order for good peers are only communicated when a peer observes a majority of peers supporting it. If this is the case, then good peers will never change their opinions, and this order can be considered final.

[0391] Preferably, the embodiment is designed to provide Byzantine fault tolerance and is robust to up to one-third of bad peers through voting stake. A brief proof of this property is as follows:

[0392] Assume the proportion of bad peers is b, where b < 1 / 3;

[0393] Assume that the threshold of a 2 / 3 consensus for a good proposal has been reached;

[0394] Since 2 / 3 - b > b, bad peers have less voting power than good peers in the consensus.

[0395] In the worst-case scenario, if all the bad peers initially supported the good proposal but simultaneously converted their votes to a new bad proposal, the bad proposal still has fewer votes than the good proposal. The remaining good peers observe the higher votes of the good peers and confirm the good consensus. The bad peers cannot prevent the good peers from reaching a new 2 / 3 consensus.

[0396] consensus protocol

[0397] A consensus protocol is the process followed by peer nodes to compute an updated consensus state.

[0398] Preferably, the consensus protocol enables peer nodes to compute consensus on multiple blocks in parallel by not requiring blocks to contain cryptographic hashes of previous blocks. This reduces the waiting time in the embodiments.

[0399] Preferably, as part of the protocol, consensus is maintained on state updates using the following process:

[0400] Effective trust includes a consensus ordering that represents the latest consensus ordering observed by peer nodes that produce trust.

[0401] Peer nodes share trust among themselves, and if the network is limited by capacity, they preferably give priority to sharing trust with peer nodes with higher stake.

[0402] Peer nodes use a trust merging function that satisfies the CRDT properties to merge the trusts they receive. As part of this, the computation of an updated consensus order can be performed.

[0403] Peer nodes can obtain updated consensus ordering from the merged trust and any other relevant information;

[0404] Peer nodes use consensus ordering to calculate the latest consensus state as needed;

[0405] Peer nodes may optionally add additional data to their trust, such as adding additional blocks to their ordering for consideration in future consensus.

[0406] A peer node communicates its updated trust to one or more other peer nodes;

[0407] Peer nodes may optionally relay the results back to the client (e.g., the result of a transaction submitted by the client with the aim of changing the consensus state).

[0408] Repeat the process as needed.

[0409] exist[ Figure 2 The document provides an illustration of the trust merging process as part of the consensus protocol and further describes it as part of an example implementation.

[0410] Consensus state

[0411] The consensus state is the latest version of the state that the nodes consider to be the state, and the latest consensus is taken into account.

[0412] Different nodes may have different opinions on the value of the consensus state (e.g., allowing different propagation speeds across the network).

[0413] Preferably, in an embodiment where the state is determined by applying a state transition function to the order of blocks, the consensus state is the state that immediately follows the latest block in the current consensus order.

[0414] Preferably, participants in the network should regard the consensus state as a reliable source of facts about all information managed by the network, although they may optionally cite previous states for various purposes, such as historical analysis.

[0415] convergence

[0416] Convergence is a property of a system in which information values ​​converge to the same value over time. Such a system can be called "converged".

[0417] Preferably, one embodiment utilizes convergence properties to achieve consensus in a manner similar to CRDT.

[0418] Preferably, convergence can be arranged such that certain portions of the information values ​​are arranged to converge before others, for example, such that earlier blocks in the order converge to the consensus order before later blocks.

[0419] Convergence Storage

[0420] Convergent storage is a type of storage system in which the act of storing certain information has convergent properties.

[0421] Preferably, such actions are commutative, idempotent, and associative. These properties together enable the state of the storage system to operate in a manner similar to convergent replicated data types (CRDTs), allowing values ​​to be stored reliably in a conflict-free manner. Under this model, new information can be merged into memory at any time without altering or invalidating existing information.

[0422] Preferably, any action performed on the convergent storage system will result in an operational state of the convergent storage system that is guaranteed to be consistent with all previous versions of the storage. This consistency property should include:

[0423] If the value already exists in memory, it will still be accessible;

[0424] The new value is purely additive, so it is impossible to change, delete, or overwrite existing values ​​(because these values ​​are preferably immutable).

[0425] If the monotonic head information of the new values ​​is different, the monotonic head can converge to a single "maximum" value because the updates of the monotonic head are also commutative, idempotent, and associative.

[0426] Preferably, the convergence storage is configured to store cells referenced by value IDs.

[0427] Alternatively, a convergent storage implementation may allow "garbage collection" to remove stored values ​​that are no longer needed. This operation should not affect the behavior of the storage system, as long as references to the removed data are no longer maintained.

[0428] Preferably, the embodiments include some or all of the convergent storage systems that exhibit the above-described properties.

[0429] CRDT

[0430] CRDT stands for "Convergent Replicative Data Type," as generally understood in computer science literature. Such CRDTs are known to have convergent properties when shared under various configurations of network communication (e.g., "random rumor propagation" models).

[0431] Preferably, trusts have the property of being CRDTs, which allows them to be merged by a trust merging function to automatically resolve inconsistencies (trusts "converge" to the consensus value).

[0432] Preferably, the information groups in the storage subsystem are also represented as CRDTs, so that new information can be reliably merged into the memory without conflicts.

[0433] coding

[0434] Encoding is the representation of information contained in a unit, typically using zero or more lower-level information units.

[0435] Preferably, the encoding is defined as a convenient form for storage or network transmission, such as a sequence of 8-bit bytes implemented on a typical computing system. For example, a unit representing the digit "1" can be encoded by two bytes "0801" in hexadecimal.

[0436] Preferably, the encoding contains all relevant information in the unit, so that no information is lost when constructing the encoding, and equivalent units with the same information can be reconstructed from the encoding as a whole.

[0437] Preferably, each distinct unit is assigned a unique code. The converse is not necessarily true; for example, some byte strings may not represent valid units.

[0438] Preferably, each unit or value has one and only one valid code, which may be referred to as a "canonical code".

[0439] Preferably, the encoding process can "embed" small units within larger codes to reduce the need for separate codes and the storage of small values. For example, one embodiment can be configured to automatically embed codes of 140 bytes or fewer within the code of any parent unit. This type of encoding is called embedding.

[0440] Preferably, the encoding may include references to other units (e.g., encoding by means of a representation of the target unit's value ID). In this case, it may be necessary to obtain the encoding of the references in order to fully reconstruct the values ​​of the entire set (or the tree of units).

[0441] Preferably, the encoding of any unit has a limited maximum size, thus proving that any valid encoding fits within a fixed-size buffer (e.g., a byte buffer) of lower-level information units.

[0442] excitation

[0443] Preferably, the embodiments implement an incentive mechanism (see, for example, see...). Figure 7 and 8This is to encourage honest, efficient, and value-creating participation. The calculation and execution of these incentives can be performed when the computational state is updated, or through rules encoded in the protocol itself or through smart contracts. Incentives may include, but are not limited to:

[0444] Client transaction fees: Transaction fees that may be incurred when peer nodes submit transactions on behalf of clients to reach consensus;

[0445] Peer nodes pay block fees to bundle many transactions into larger blocks, which improves the efficiency of the consensus process.

[0446] Block rewards are given to peers or clients who place their stake on good peers.

[0447] Penalties for peers that are proven to have used the protocol inconsistently;

[0448] Discretionary payments shall be made to actors who provide valuable services to the network;

[0449] A pool allocates a portion of its fees from other pools to provide additional incentives, such as network governance costs.

[0450] The magnitude of the incentive can be determined in several ways:

[0451] Fixed at the network level;

[0452] Dynamic calculations, such as those based on transaction computation costs or the equity levels of peer nodes;

[0453] Regulated by network governance protocols, such as transactions signed by a management body that adjusts incentive calculations and updates network status;

[0454] Off-chain management is carried out by an organization that handles network governance;

[0455] Incentives can be distributed through multiple processes:

[0456] Direct transfer to or out of the account;

[0457] Adjust the rights and interests of peer nodes;

[0458] Incentives are guided through pools that encompass any combination of the above.

[0459] initial state

[0460] The state before any blocks are applied is called the initial state.

[0461] Preferably, all peer nodes in the network are arranged to have the same initial state knowledge. Peer nodes may want to confirm the value ID of the initial state to ensure they are computing the same consensus state.

[0462] Invalid trust

[0463] Invalid trusts may be created by nodes that fail to implement the consensus protocol (either intentionally or due to defects).

[0464] Preferably, therefore, the validity of all trusts received from untrusted peer nodes should be tested before applying the trust merging function. Implementations can use the following techniques to flag invalid trusts and exclude them from consensus:

[0465] Check the cryptographic signatures and peer registrations on the network;

[0466] Check the data structure, such as for bad data formats;

[0467] Check the timestamps of old trusts contained in the consensus;

[0468] Test the idempotency property of the trust merging function, i.e., F(latest trust, previous trust) = latest trust;

[0469] Preferably, upon detecting invalid trust, a good peer node may take one or more of the following actions:

[0470] Ignoring trust in the process of further consensus-building;

[0471] Blacklist the peer node, disconnect it, and block new connections;

[0472] Questioning peers based on invalid trust can cause bad peers to lose some or all of their equity (through erosion).

[0473] Memory billing

[0474] Memory billing is a method of attributing memory and / or storage usage to participants in a network.

[0475] Preferably, memory billing is used to create economic incentives for participants to minimize memory and / or storage usage, thereby improving the overall efficiency and scalability of the network.

[0476] Preferably, memory billing is performed by calculating based on memory size.

[0477] Preferably, memory billing is applied to transactions that change the memory size of the consensus state, and the change in memory size is attributed to the account of the participant who signed the transaction.

[0478] Preferably, participants should be required to make payments in order to increase the memory size of the state.

[0479] Preferably, if a participant reduces the size of the state, they should receive a refund.

[0480] Preferably, participants can be charged for other actions they perform on the network that consume storage resources, for example:

[0481] The fee is proportional to the memory size of the transaction executed on behalf of the client;

[0482] The cost is proportional to the memory size of the block proposed by the peer node.

[0483] Memory size

[0484] Memory size is a measure of the total size of information contained within a unit (or equivalent value).

[0485] Preferably, the memory size is defined as the size that includes other sub-units that can be indirectly referenced (e.g., via smart references).

[0486] Preferably, the memory size is an approximate measure of the number of bytes required to store or transmit a unit, which may include:

[0487] Size of the unit code;

[0488] The sum of the memory sizes of any sub-units (recursively defined);

[0489] Allowances for indexing and memory overhead.

[0490] Preferably, if the implementation supports embedded units that do not need to be stored with their own permissions (as defined in the code), these can be defined as having zero memory size. However, it should be noted that the size of such embedded units should be included in the memory size of any unit with code that includes embedded values.

[0491] Preferably, the memory size is calculated only when needed, such as when the state generated by a transaction is persistently stored. This minimizes the computational cost of considering objects in transient memory, allowing the memory size to be cached and improving performance. Caching the memory size (as part of a monotonic header) in the metadata of units attached to memory or storage is a preferred approach.

[0492] Monotonous head

[0493] The monotonic header is additional metadata that can be associated with a value or cell code.

[0494] Preferably, the monotonic head is accompanied by a "merge" function that is commutative, associative, and idempotent. This creates a structure that functions equivalently to the "merge half-lattice" typically defined in mathematics. This ensures that the head can be merged and converges to a single value, consistent with having convergent properties and / or being included in a CRDT.

[0495] Preferably (and as the logical meaning of the aforementioned attributes), the merge function ensures that the information contained in the monotonic header can only change in one "direction," such as an incrementing integer or a sequence of state flags associated with a graph (DAG) that does not contain cycles.

[0496] Preferably, the monotonic header includes a status label for the node to indicate the progress of processing units or values ​​from the perspective of network participants. For example, an exemplary embodiment includes a status label for:

[0497] Unknown - Peer nodes have a value ID hash, but it is unknown whether it is consistent with the encoding, and may not have the data in memory or storage;

[0498] The stored data is encoded in memory by peer nodes, which is verified as a well-formed cell (ignoring sub-cells) and consistent with the value ID hash value;

[0499] The persistent peer nodes have fully verified the structure of the cell, including recursively verifying all its sub-cells. At this point, it is safe for participants to use the data values ​​within the cell during computation.

[0500] Announcement - Peer nodes have included the data in the public broadcast trust;

[0501] Preferably, other possible labels include:

[0502] Embedded data values ​​can be embedded within other units and do not need to be stored separately;

[0503] An invalid cell can be proven to be inconsistent with one or more validation rules. Invalid data cannot be used for consensus, but caching invalid states can avoid the need for repeated validation processes.

[0504] Preferably, the monotonic header may include cached information that can be computed deterministically from units or values ​​(e.g., the memory size of a unit). This use of cached information can improve the performance of the implementation by reducing or eliminating the need to recompile such values ​​multiple times. Since the only valid change is from an "uncomputed" state to a "computed" state, the computation of such cached values ​​is commutative, associative, and idempotent.

[0505] network

[0506] A network is a collection of nodes arranged to communicate with each other. A network can be thought of as a single system, comprising subsystems representing the individual nodes.

[0507] Preferably, the purpose of including nodes is to participate in the operation of the consensus protocol (for peer nodes) or to interact with the maintained consensus (for clients).

[0508] Preferably, the network uses standard and well-known communication technologies, such as the Internet.

[0509] The network is preferably designed to operate such that communication between all nodes is possible at all times. Temporary failures may cause the network to cease full connectivity (“network partition”). Individual nodes can leave or join the network at any time.

[0510] exist Figure 1 An example network is described in the document.

[0511] New things are a quantity of information (e.g., a unit, or a set of units representing a value or a portion of a value) that is considered to have been created or observed for the first time by network participants (usually peer nodes).

[0512] Preferably, the embodiment detects new information to ensure that participating nodes only send new information to the network and do not retransmit non-new information, thereby reducing processing or network bandwidth usage.

[0513] Preferably, new things can be detected by the monotonic header of the stored cell, the monotonic header indicating the first update to a higher state level, such as a transition from a persistent state to an announcement state.

[0514] Preferably, novelty detection is used to improve the efficiency of the implementation, for example:

[0515] A new trust only requires adding an increment to the proposed ordering, without communicating the full ordering, which may be long but may be held by all other peer nodes;

[0516] The fact that recalculation is not required on already verified data portions can be important for big data structures that only require minor changes to verify the consensus state.

[0517] Preferably, the embodiment includes a convergent storage system that is capable of efficiently detecting and applying rules relating to new things, for example, by using status tags in a monotonic header.

[0518] Sort

[0519] The sort order is a value that specifies the order in which blocks (or equivalent transactions) should be executed. The order represented can be full or partial (as commonly understood in mathematics).

[0520] Optionally, the sorting can incorporate other data, for example:

[0521] The sequence of all state transition results, previously calculated up to the confirmed consensus point;

[0522] A pointer to the current consensus or proposed consensus position in the ordering;

[0523] Additional blocks that have been submitted by peer nodes but have not yet been included in the current consensus or proposed consensus;

[0524] Other information related to communication between peer nodes.

[0525] Preferably, the ordering is digitally signed by the peer nodes to provide proof that the ordering was legally created by the associated peer nodes. Peer nodes may ignore orderings that are not properly signed.

[0526] Preferably, the sorting uses loosely coupled blocks (see...). Figure 6 ).

[0527] Preferably, the use of sorting implementations enables high scalability and low latency, for example, by allowing independent blocks to be created and reordered simultaneously before consensus is reached. In traditional tightly coupled sorting, all previous blocks must be created and confirmed before a new block can be added.

[0528] Preferably, the sort is represented as an immutable, persistent data structure with shared structure, such that earlier blocks in the sort are shared with newer versions that have been appended with new blocks. In this way, only new blocks added to the sort can be considered new. This is an important optimization that reduces memory consumption and network traffic, especially when sharing large amounts of sorting over a network.

[0529] Peer nodes

[0530] Peer nodes are nodes in the network that participate in maintaining consensus.

[0531] Preferably, peer nodes should operate strictly according to the consensus protocol; however, even with the presence of some “bad peer nodes” that do not follow the protocol correctly, the entire consensus is designed to be robust and secure.

[0532] Preferably, peer nodes have associated stakes, representing an economic commitment to act faithfully. If a peer node is proven to be a "bad actor," it may lose its stake. Attempts to modify the consensus without following the protocol are not permitted, such as unauthorized withdrawals of funds from user accounts. Peer nodes with zero stake can be ignored or deregistered by other peer nodes.

[0533] Plan Execution

[0534] The embodiments may optionally implement a system for planned execution, in which case the following paragraphs apply:

[0535] A plan is a data structure that can be included in a state to specify a transaction to be executed in the future.

[0536] Preferably, plan execution is the execution of transactions from the plan as part of a state transition function (and by implication, this should be implemented and verified by a consensus protocol).

[0537] Preferably, the execution of the plan depends on a timestamp confirmed by the peer nodes as part of the consensus protocol. For example, the timestamp can be defined as the most recent timestamp observed from all blocks executed so far to produce a consensus state.

[0538] Preferably, the timestamp should be included in the state itself, so that it can also be used for trusted code execution and can be checked and verified by the participants.

[0539] Preferably, the plan is represented using a data structure designed to support efficient indexing, so that the next transaction to be executed can be queried efficiently, and transactions that have already been executed can be removed. An example of such a data structure is a "radix tree".

[0540] Preferably, access control is applied to scheduled transactions similar to regular transactions or trusted code execution, preventing them from making unauthorized changes to the state.

[0541] Smart Contracts

[0542] A smart contract is a computer program or protocol that digitally facilitates, verifies, or enforces the negotiation or execution of a contract.

[0543] Optionally, the implementation may support the implementation of smart contracts on the network, enabling their reliable execution to be verified and implemented in accordance with a consensus protocol.

[0544] Preferably, the smart contract has the ability to control resources managed within the on-chain state of the network. Such control may, for example, include transferring ownership of digital assets between users if certain predetermined conditions are met.

[0545] Preferably, based on the assumption that the network operates correctly according to the consensus protocol, independent parties can trust and verify the behavior of smart contracts.

[0546] Preferably, smart contracts are implemented using tools for executing trusted code over a network (assuming this is available in the embodiment).

[0547] Preferably, smart contracts are implemented so that execution can be deterministically computed from consensus information, such as the current state, transactions, and other inputs to the state-transaction function. As long as the inputs to the smart contract are in the consensus, the output of the execution can be verified as being in line with the consensus.

[0548] Preferably, a smart contract is activated by submitting a transaction that invokes the smart contract (directly or indirectly). These transactions can also be invoked automatically by other processes within the protocol, such as at a predetermined timestamp.

[0549] In this embodiment, smart contracts can be implemented using various features, such as:

[0550] Export externally accessible functionality;

[0551] It accepts the input parameters of the output function and returns the result as the output;

[0552] Call other smart contracts and execute other transactions on the network;

[0553] The computation is limited by pre-defined constraints on the computational units responsible for the transaction client;

[0554] Create and deploy other smart contracts;

[0555] Fees are charged for performing smart contract computations. Fees can be paid to peer nodes that publish transactions on behalf of clients. Payments can be made to the incentive pool as commissions to any third party or through other agreed-upon methods.

[0556] Code planned for future execution based on defined rules.

[0557] Smart Reference

[0558] A smart reference is a pointer to a unit (or equivalent value).

[0559] Preferably, smart references use a value ID as an identifier. This assumes the value is immutable, meaning the smart reference must always refer to the same immutable information.

[0560] Preferably, smart references allow for "garbage collection" of units or values, particularly when it is known that data has been written to memory and is not currently in use, thereby freeing up working memory in the host system. This can be achieved using Java "soft references" through the Java garbage collector.

[0561] Preferably, the smart reference incorporates a mechanism that allows data to be recovered from memory if future processing requires data previously garbage collected from working memory. A cryptographic hash value serving as the value ID ensures that the recovered data is identical to the original value, having the same encoding. Additionally, if the value cannot be retrieved directly from memory, the smart reference can request "lost data" from another peer node.

[0562] rights and interests

[0563] Equity is the quantity of assets that may have economic value.

[0564] Preferably, the embodiments mandate that participants provide rights under specific circumstances. This provides security by encouraging good behavior from network participants, who may risk losing their rights if they do not behave correctly.

[0565] Preferably, peer nodes are required to provide stakes in order to be eligible to participate in consensus; these are called peer stakes.

[0566] Preferably, the stakes of peer nodes are recorded as part of the state, so that knowledge of the stakes of each peer node can be obtained from the consensus.

[0567] Preferably, peer node stakes can be provided as voting rights in the consensus protocol. During consensus processing, stakes can be considered "locked" and cannot be used for other purposes.

[0568] Preferably, peers that misbehave according to the consensus protocol can be penalized by removing some or all of their stake (referred to as "diminishing"). Such a penalty can be defined as part of the protocol or triggered by other participants.

[0569] Optionally, equity can be added as a reward for processing transactions. See [ Figure 7 This example illustrates how, in one embodiment, a reward pool can be constructed to reward peer nodes by increasing their stake.

[0570] Optionally, users and / or clients may place additional interests, referred to as "delegated interests," in addition to those placed by peer nodes.

[0571] Typically, placing stakes involves both risks and responsibilities. For example, peer nodes may need to maintain the confidentiality of their private keys, otherwise they risk losing all stake to malicious actors.

[0572] Equity-weighted sorting and merging

[0573] Stake-weighted sort merge (sort merge) is a process that can resolve conflicts between sorts.

[0574] Preferably, the embodiment resolves conflicts between orders proposed by different peer nodes by performing state-weighted order merging, and preferably in a manner consistent with the consensus properties and proofs expected in delivery.

[0575] Preferably, sort merging is applied to all blocks following the current consensus sort.

[0576] Preferably, sort merge excludes peer sorts that are inconsistent with the consensus sort of the peer performing the sort merge (e.g., if a peer sort does not exactly match the consensus sort of a block up to the entire length of the consensus sort, it is ignored).

[0577] Preferably, the embodiment resolves conflicts between proposed orderings by performing a state-weighted merging.

[0578] Figure 4 A system for including peer nodes in an initial voting set based on participation stake weighted merging is shown.

[0579] Preferably, peer nodes calculate the sort merge according to the following process:

[0580] 1. Each peer computes an initial “vote set” of all peers with consistent consensus (e.g., peers whose ordering matches the consensus ordering maintained by that peer). The current peer is automatically included in this set (because by definition, it must be consistent with itself). This may include “lagging” peers (with shorter consensus orderings, but whose ordering is otherwise consistent with that peer’s consensus ordering) and “early” peers (who have announced a longer consensus ordering than that peer, but are still consistent with that peer), but peers inconsistent with the current consensus ordering should be excluded (this may be true in the case of consensus forks, no proposals, or outdated proposals). See [ Figure 4 [and the corresponding explanation above.]

[0581] 2. Determine the "winning sort" (see...) Figure 5 It is determined through the following process:

[0582] i) It is initialized to the consensus order of the peer node.

[0583] ii) Calculate the weighted stake for each peer in the set (e.g., peer A may have 2.3% of the vote in a given set).

[0584] iii) The next block with the highest total votes in the set (this is called the “winning block”) is appended to the winning order.

[0585] iv) Peer nodes that are no longer consistent with the winning order (i.e., do not vote for the winning block) are excluded from the voting set (inconsistent peer nodes may also be given a reduced weight instead of being removed completely, although it is preferred to set the weight to zero).

[0586] v) If any remaining peer nodes in the voting set have additional blocks in their order, return to ii) and repeat for the next block position.

[0587] 3. Once all blocks in the voting set have been selected, the final winning order is defined

[512] . This will (as a result of the voting rules described above) be exactly equal to the order of any peer nodes (one or more) remaining in the voting set (see also [reference]). Figure 5 , Figure 5 The final winning sort is shown as the longest remaining sort that is consistent with all previous winning rounds.

[0588] 4. Blocks that have been observed but not yet included in the winning order chain (e.g., new blocks provided by peers excluded from the voting set) can be appended to the winning order chain (e.g., in timestamp order). This ensures that all blocks are eventually included in the order proposed by the peers. Furthermore, using block timestamps to inform the order maximizes the likelihood that the proposed order is consistent with the order proposed by other peers, which improves efficiency and minimizes consensus discovery wait time.

[0589] 5. The resulting winning order then becomes the new order for that peer node and is included in the peer node’s trust for subsequent transmission to the network.

[0590] refer to Figure 9 This shows how to update the final result of the sorting and merging based on the above process:

[0591] state

[0592] State is a value representing data that can be computed or updated as a consensus outcome.

[0593] Preferably, the state includes information of interest to the network's peer nodes and clients, enabling them to derive values ​​from that information. This may include, but is not limited to:

[0594] The holding of other digital assets controlled by participants in the network;

[0595] Peer records that identify and describe peer nodes in a network, such as rights and network addresses;

[0596] Information stored or updated by the user;

[0597] Executable smart contract code;

[0598] Global data, such as network state and other data accessible to smart contracts.

[0599] Preferably, the state is implemented using a data structure that facilitates quick access to and updating of the information contained in the state, for example by providing an efficient index for account access.

[0600] Preferably, the state is implemented as a value, so that the entire state can be represented as a single immutable unit of information.

[0601] Information included in the state or in the process of updating the state can be informally referred to as "on-chain".

[0602] State transition function

[0603] A state transition function is a function that can calculate and update the state.

[0604] Preferably, the mathematical model used for state transitions can be considered in the following form:

[0605] S(t+1) = f(S(t), T, E)

[0606] in:

[0607] f = state transition function

[0608] S(t) = the state before the state transition function is executed.

[0609] S(t+1) = the new state after executing the state transition function.

[0610] T = The transactions (or blocks of transactions) to be applied to this state.

[0611] E = Additional contextual information, if any (e.g., a source of random numbers).

[0612] Preferably, the execution of the state transition function is deterministic with respect to the input, such that, given the same initial state and transaction inputs, all peer nodes that correctly compute the state update will reach a consensus on the resulting state. This means that the nodes must also reach a consensus on the same environmental context.

[0613] Preferably, the state transition functions can be computed in bounded time and space, so that they can be executed on peer-to-peer machines with reasonable specifications in terms of storage, network and computing resources.

[0614] A state update can be considered "valid" if it has been computed according to the correct application of the protocol rules and state transition functions.

[0615] Optionally, not all peer nodes need to compute state updates, as long as they receive the resulting state in the future when they can maintain consistency. This may occur in the following situations:

[0616] Delegate to a subset of peer nodes, for example, if they have access to private data that is not accessible to all peer nodes;

[0617] Catching up after disconnecting or joining the network as a new peer can be done more efficiently and simply by obtaining the latest state from another peer, rather than recalculating a large number of previous state updates.

[0618] Trust that another peer node correctly computes the new state. Note that this potentially puts equity at risk if the trusted peer node fails to perform a valid state update.

[0619] Preferably, the embodiments implement state transition functions that support the typical requirements of decentralized ledger systems. These may include:

[0620] Execute transactions according to instructions provided by the client so that these transactions can update the consensus state;

[0621] Protect user accounts or digital assets that can only be modified when the correct digital signature is provided;

[0622] Calculate transaction fees so that there are economic incentives for users not to submit wasteful transactions;

[0623] Upon checking the digital signatures of peer nodes, update peer node information, such as equity or network address;

[0624] Distribute rewards to peer nodes, such as payments from incentive pools and rewards for peer nodes providing network resources;

[0625] Execute code (including smart contracts) in a predictable and secure manner as requested by client transactions or other triggers.

[0626] Manage the balance and ownership of digital assets.

[0627] storage

[0628] Storage is a method, system, or process in which any unit (or equivalent value) (and optionally other information) can be stored on a persistent storage medium for retrieval when needed.

[0629] Preferably, the storage is used to prevent information loss in the event of system failure and allows for the storage of large amounts of data that may exceed the working memory capacity of a single computing system (e.g., a server operating peer nodes).

[0630] Preferably, the encoded cryptographic hash value of the cell is used as a value ID (VID) to reference the cell. The VID can be used as a key to effectively address data in the indexed storage system.

[0631] Preferably, the cells referenced in the storage system are immutable. For a given key, the data value cannot be changed, which would invalidate its VID. Immutability has the following advantages in the embodiments:

[0632] Storage units are not resized and can be increased with a "attach only" limit, thus minimizing storage fragmentation.

[0633] The cache is always effective; replication does not require synchronization.

[0634] If a hash value exists in storage, verification is fast, and it is always valid once the data has been verified.

[0635] trade

[0636] A transaction is a unit of information representing a message or instruction to the network that can affect one or more information values ​​in the consensus.

[0637] Preferably, the transaction includes a digital signature, which allows network participants to verify that the transaction has been correctly signed with the appropriate private key, and thus, it can be assumed that such a transaction has the access rights associated with that key (e.g., the ability to execute instructions to transfer digital assets from a specific user account).

[0638] Preferably, in embodiments of the present invention, the transaction is designed to update the consensus state. Transaction processing may include:

[0639] Calculations that update the network state, such as transferring funds or triggering smart contracts;

[0640] The transaction initiator's cryptographic signature ensures security. For example, only users with the correct private key can spend currency from their own accounts;

[0641] The update will be applied to a given state of success or failure, such as if the account has insufficient funds.

[0642] Preferably, one embodiment provides a mechanism for recording the results of a transaction and communicating them back to the client (in particular, if the transaction was submitted by the client, it is communicated back to the client that submitted the transaction).

[0643] Trusted code execution

[0644] Trusted code execution (or simply code execution) is the execution of program code as part of a state transition function, according to rules that can be defined by the implementation.

[0645] This capability is optional for the implementation, but if the implementation chooses to implement trusted code execution, the following paragraphs should apply:

[0646] Preferably, there exists a facility that allows network participants to upload or deploy their own code to the consensus state, for example, by publishing appropriate transactions.

[0647] Preferably, trusted code execution is constrained by access control rules, preventing the execution of the code from arbitrarily changing the state (e.g., controlling digital assets owned by another arbitrary user).

[0648] Preferably, trusted code execution has the capability to implement Turing-complete computer programs, thereby enabling arbitrary logic. This can be achieved in embodiments using a custom VM with defined opcodes.

[0649] Preferably, a mechanism is included to limit the computational cost of the executing code so that the user does not consume excessive computing resources. For example, this can be achieved by charging a transaction fee for each code operation executed and suspending execution if the limit is exceeded.

[0650] Preferably, the working memory requirement for each transaction should be limited, so that transaction execution can be safely completed in an implementation with a limited working memory size. The ability to offload data to storage can help with this.

[0651] Preferably, trusted code execution supports atomic operations, ensuring that the execution of an atomic operation is entirely successful, or that the change is rolled back in the event of failure. One embodiment may choose to implement the entire transaction as an atomic operation, or allow the code to define custom atomic operations.

[0652] user

[0653] Users are individuals or legal entities who can perform actions and hold or control assets on the network, and therefore can be considered indirect participants in the network.

[0654] Preferably, the user interacts with the network using client software, and therefore can be considered a client from the network's perspective.

[0655] Users may include the following examples:

[0656] Developers, deploy the new smart contract;

[0657] People with mobile devices should check their account balances;

[0658] Bank employees fulfill on-chain derivative contracts.

[0659] Preferably, the user owns or controls one or more cryptographic private keys, enabling them to digitally sign transactions.

[0660] Value ID

[0661] A value ID is a unique identifier for a value (or equivalent to a unit).

[0662] Preferably, the value ID can be used to reference a value or unit in the encoding or in network communication.

[0663] Preferably, a strong cryptographic hash function applied to the encoding of the relevant unit is used to compute the value ID (for large values, this could be the encoding of the top-level unit in the unit tree). This provides a cryptographic guarantee that it is extremely unlikely that two different values ​​will be assigned the same value ID. Hash collisions under this scheme are highly improbable and can be ignored for practical purposes. An example embodiment uses the SHA3-256 hash of the value encoding to generate the value ID.

[0664] value

[0665] A value is an entity that represents a unit of information.

[0666] Preferably, some values ​​are synthesized, for example, a data structure containing multiple component values.

[0667] Preferably, standard methods for representing values ​​are used to represent all information shared or processed by participants in the network.

[0668] Preferably, the value is represented in a form similar to the data types typically found in mathematical or computational systems, for example:

[0669] Primitive values ​​such as integers or booleans;

[0670] Bit string;

[0671] Values ​​used for naming, such as symbols or keywords;

[0672] Composite data structures, such as lists, maps, vectors, and sets;

[0673] Data records containing multiple fields;

[0674] Blocks and transactions related to the consensus protocol;

[0675] Cryptographic primitives such as hash values ​​or digital signatures.

[0676] Preferably, the value can be implemented using an abstract data type (ADT) or a common base class or interface in an object-oriented programming language. Such a data type can be conveniently handled by computer programs in a uniform manner.

[0677] Preferably, the value is immutable, meaning that once the relevant information contained in a particular value is constructed, it cannot be changed (although implementations may choose to augment their internal representation of the value with additional metadata that is not considered part of the information represented by the value (e.g., a cached value ID).

[0678] Prefix computation based on vectors

[0679] Consensus algorithms compare contiguous datasets. They compare two or more sorts to identify whether blocks are identical. For example, it computes the longest common prefix of two sequences, such as sorts.

[0680] [A, B, C, D, F, G]

[0681] [A, B, C, G, D]

[0682] The common prefix is ​​[A, B, C] with a prefix length of 3.

[0683] Previous algorithms suffered from unacceptable performance for long sorting operations in O(n) time, where n is the length of the shorter chains. They could potentially handle millions of blocks with unacceptable wait times and prohibitive computational costs. This protocol combines a Merkle tree (a tree with embedded cryptographic hashes) with a radix tree to compute the common prefix length. Efficient prefix computation is completed in O(log n) time. It achieves this by:

[0684] The sorted blocks are stored as "vectors", where a vector is a smart data structure containing a sequence of arbitrary values;

[0685] The vector is implemented as a radix tree, where each tree node has a limited number of child nodes, preferably a maximum of 16.

[0686] Embed the cryptographic hash value of each child node in the parent node. The hash value serves as a smart reference.

[0687] Examine the hash values ​​in the vector to find the first pair of nodes with different hash values, thus determining the common prefix. Skipping identical nodes in large vectors improves computational efficiency.

[0688] When two corresponding sub-branches have different hash values, a recursive descent is performed, which determines the position where the first difference in the element values ​​occurs.

[0689] Examples of the present invention use

[0690] Examples of this invention are open, publicly accessible, decentralized networks designed to support digital assets, such as central bank digital currencies (CBDCs). They support flexible, Turing-complete smart contracts that can be used to automate transactions and settlements involving such digital assets. The network is fully decentralized, meaning that any participant is allowed to operate peer-to-peer server instances within the network. They utilize strong cryptographic techniques, such as digital signatures. An economic staking system is placed to regulate peer-to-peer behavior, ensuring that the network as a whole operates in a secure, verifiable, and trustworthy manner.

[0691] This type of smart contract tool makes it easy to implement and / or manage new types of digital assets.

[0692] The example is designed to support access for users submitting transactions as clients of the network, such as code for trading digital assets or executing smart contracts. Other tools include client software libraries (available in various programming languages) provided to facilitate client software implementation. Users are expected to use digital signatures to ensure the authenticity of their transactions and the security of their digital assets, facilitated by an account system that can be controlled by different users.

[0693] To achieve high transaction throughput and low latency, the examples utilize efficient implementations of the consensus protocols described in this invention. These are supported by efficient data structures and cell encoding, efficient trust merging functions for block ordering, and optimized storage systems.

[0694] Peer node server

[0695] The network consists of one or more Internet-connected servers

[11] with publicly addressable TCP / IP ports that facilitate connection and communication between other peer nodes[11,13] and clients

[14] [12, 15].

[0696] Host running

[0697] Peer-to-peer servers

[11] use the Java programming language and the Java Virtual Machine (JVM) to run. They can run on servers that operate common operating systems such as Linux and Windows.

[0698] networking

[0699] The networking implementation uses Java NIO to provide asynchronous, event-driven message processing, primarily for performance reasons. The fixed-size buffer used in this implementation allows backpressure to be applied to connected systems that send too many messages, and mitigates denial-of-service attacks.

[0700] Peer-to-peer protocol

[0701] Peer nodes communicate using a standardized protocol known as the peer node protocol.

[0702] The protocol involves sending messages as a sequence of bytes, beginning with a message identifier, and then encoding one or more data values ​​according to the message type definition. The most important message types implemented include:

[0703] Challenge - Sending a cryptographic challenge to a participant at the other end of the connection to prove ownership of one or more private keys;

[0704] Response - Respond to the challenge with a digital signature proving ownership of the private key;

[0705] Data - conveys data values ​​(as unit encoding);

[0706] Commands - Control instructions for peer nodes used for peer management;

[0707] MISSING_DATA - A request for some unit value corresponding to a given value ID, which is typically used by peer nodes or clients to obtain a value that they do not currently hold in their local memory or storage;

[0708] A query is a request to perform computations on the current consensus state, but it is not actually executed as a transaction. Queries cannot modify the state.

[0709] A transaction is a request from a client that asks a peer node to submit a transaction for inclusion in the consensus. If successful (including verification of any relevant digital signatures), the transaction can lead to an update of the state.

[0710] Results - Communication of the results of some previously sent messages;

[0711] Trust - According to the convergence proof of the stake algorithm described in this invention, communication of the peer trust data structure necessary for peer nodes to converge to consensus.

[0712] The message is limited to a maximum length of 8191 bytes, which is generally sufficient for small message encodings (e.g., TRANSACT), but insufficient for large values ​​(e.g., the entire BELIEF). In practice, it may only include one or more root units of the message, and some sub-units may be excluded. To manage this:

[0713] Peer nodes are typically expected to use DATA messages to pre-send child cells to ensure that the receiver has all relevant cells when the top-level message arrives. However, if a peer node represents something new—that is, something that has not been previously communicated by peer nodes—then the peer node should generally only send such cells.

[0714] If a peer node receives a message but does not have one or more child cells, it can request the missing child cells using the MISSING_DATA message. If one or more MISSING_DATA requests do not result in obtaining the required cells, the peer node is authorized to ignore the message.

[0715] Consensus and Trust Merging Process

[0716] Using a peer-to-peer protocol, peer nodes execute a consensus protocol primarily consisting of a trust merging process. Figure 2 ]

[0717] storage

[0718] The peer node server utilizes a custom key / value database to provide persistent storage required for peer node operations and allows the peer node server to restart. The storage implementation uses memory-mapped I / O. From the peer node server's perspective, the storage subsystem enables peer nodes to store the encoding of any unit of a key with an SHA3-256 hash value (value ID) equal to the encoded value, and to look up data based on the same value ID.

[0719] Information Model

[0720] This embodiment defines a standard information model suitable for use by peer nodes and clients, and this standard information model enables efficient serialization, storage, and communication of information values.

[0721] value types

[0722] In this embodiment, all values ​​created and transferred are implemented as immutable values ​​in the host runtime environment (JVM), using a public base class "ACell" corresponding to any unit.

[0723] Most cells are also values, although some cells are used as components of larger values ​​and are not considered valid values ​​within their own permissions.

[0724] The main types available in this embodiment are:

[0725] Original language

[0726] ○ Byte - An 8-bit byte is considered an integer ranging from 0 to 255;

[0727] ○ Double-64 bit IEEE double-precision floating-point value;

[0728] A signed integer of length -64 bits;

[0729] ○ character - 16-bit UTF16 character;

[0730] ○ Boolean - Two possible values: "true" and "false";

[0731] ○Nil - Monotonic value "nil"

[0732] ○ Address - Account number identifier, such as "#123";

[0733] ○ Symbol - A named identifier used in the code, such as "x";

[0734] ○Keywords - typically used as named values ​​for mapping keys, such as ":foo";

[0735] String-like objects (of any length)

[0736] ○ String - A sequence of UTF16 characters;

[0737] ○Block - A sequence of 8-bit bytes;

[0738] Data Structures

[0739] ○ List - Typically used to represent the values ​​of codes, such as "(do 23)";

[0740] ○ A sequence of vector-value pairs, such as "

[123] ";

[0741] ○ Mapping - Mapping from keywords to values, for example, "{: foo 1,: bar 2}";

[0742] ○ Set - A group of unique values, such as "# {123}";

[0743] ○Record - A class-mapped object with predefined fields and value types, most commonly used to represent specialized data structures in an embodiment, such as account records;

[0744] code object

[0745] ○ Syntax - An object used to represent code with optional metadata;

[0746] ○ Function - A callable function that can be executed;

[0747] ○Op- refers to instructions compiled by the virtual machine;

[0748] consensus object

[0749] ○State - Complete State

[0750] ○ Block - The block containing the transactions;

[0751] ○Transaction - A single instruction sent to the network;

[0752] ○ Sequence - Complete sorting of blocks;

[0753] ○ Trust - Peer-to-peer trust data structure;

[0754] ○Signature data - A digital signature with any other value applied.

[0755] The units implement some standard functions to facilitate their use in the embodiments, including:

[0756] The ability to obtain the unit's encoding or value ID;

[0757] The ability to inspect sub-units (if any);

[0758] Functions used to verify the correctness of the unit;

[0759] The ability to generate smart references for units.

[0760] All values ​​that require multiple units to represent them are implemented as persistent, immutable data structures that support structure sharing, thus allowing efficient updates (avoiding copy-on-write requirements).

[0761] coding

[0762] The unit is encoded as a sequence of bytes.

[0763] The first byte in the sequence is always a "marker" byte that specifies the type of the unit being encoded. The remainder of the encoding is a serialized representation of the unit's information content.

[0764] The coding utilizes industry-standard techniques to minimize the code size, such as...

[0765] Use variable-length integer encoding, where smaller integers are encoded in fewer bytes compared to larger values;

[0766] Use a bit field to indicate the presence / absence of an optional value;

[0767] Short encoding is intentionally chosen for public values ​​(e.g., 0 x 00 bytes as the encoding for "nil").

[0768] Value ID

[0769] The unit is identified by a value ID, which is defined as equal to the encoded SHA3-256 hash value, which can be represented as a 32-byte (256-bit) sequence.

[0770] state

[0771] The state managed by the consensus algorithm is implemented as a single immutable data structure containing the following information:

[0772] An ordered index from account address to account record;

[0773] An ordered index from peer node addresses to peer node records;

[0774] An ordered index of planned future transactions;

[0775] A small group of global values.

[0776] Using ordered indexes is important for allowing efficient lookups of values ​​in related data structures, which is achieved in O(log n) time, where n is the size of the index.

[0777] Account records

[0778] The status includes account records within the index. Each account can be one or both of the following:

[0779] User accounts controlled by external users of the (digitally signed) network;

[0780] An actor account that autonomously executes code according to the rules of the state transition function can be used to implement smart contracts.

[0781] An account can include any of the following information:

[0782] The serial number indicates the total number of transactions processed for the account so far and is used to prevent transaction replay attacks.

[0783] The balance of funds;

[0784] The remaining balance of the memory allowance is used for memory billing;

[0785] The mapping from symbols to values ​​represents the context of a definition stored in an account, typically used for programmatic purposes;

[0786] The mapping from symbols to metadata represents the optional metadata that can be provided for any symbol defined in the environment;

[0787] A holdings chart is provided to conveniently store added value allocated by other accounts and is typically used to track the balance of a digital asset in that account.

[0788] The controller field, which can be used to grant another account control over that account;

[0789] The public key field is used to store the Ed25519 public key for the user account.

[0790] Accounts are indexed by addresses, which are small integer values ​​indicating the account's position in the account index. Whenever a new account is added to the status, addresses are issued sequentially, starting with #0.

[0791] The account is central to the system's security model. In most cases, from the perspective of most network participants, the account is read-only and can only be updated using transactions signed with the correct Ed25519 private key. There are some carefully controlled exceptions to this rule (for example, you can provide funds to a user account without account permissions, or you can call smart contract code within an actor that has made such code callable, in which case the smart contract code can update the actor's account under well-defined rules).

[0792] Peer node records

[0793] This state includes an index of peer records indexed by the peer's public key.

[0794] Each peer record contains:

[0795] Peer stakes are placed by peer nodes as a guarantee of their own performance.

[0796] Any delegated interests placed on this peer node by other accounts

[0797] The total stake across peer nodes is used to calculate the voting weight of peer nodes in executing the consensus protocol.

[0798] Reward Pool

[0799] Funds used for peer rewards are also stored in the state, and equity holders have the right to claim a share of these accumulated rewards.

[0800] The VM includes a mechanism to ensure that stakeholders cannot demand rewards beyond what they deserve, and the rewards that can be demanded are defined in proportion to the stake of their peers. Delegated stakeholders are incentivized to invest on peers with higher stake and are therefore likely to be considered more “trustworthy.”

[0801] Memory allowance

[0802] The status also includes memory allowances for memory, which are used for memory billing.

[0803] The memory allowance is primarily used to purchase additional on-chain memory capacity (measured in bytes) during the execution of the transactions detailed below. It is also transferable.

[0804] virtual machine

[0805] This embodiment implements a virtual machine (VM) for the execution of Op and other runtime functions that are part of the state transition function.

[0806] Basic Ops

[0807] The virtual machine executes values ​​called "Ops," which are low-level "bytecode" of the VM used as an example of trusted code execution. The provided Ops are roughly equivalent to the basic operations available in a typical implementation of Lambda calculus, a functional programming paradigm most often associated with the computer language Lisp.

[0808] These Ops include:

[0809] Constant - Loads a constant value into the VM's result register;

[0810] Invoke - Invokes a runtime function or a user-defined function;

[0811] Execution (do) - Executes a series of sub-operations;

[0812] Conditional (Cond) - Performs an operation conditionally, similar to constructing IF (...) THEN.... ELSE IF (THEN) ....ELSE ... in general programming languages;

[0813] Lookup - Finds the value defined by the symbol in the current execution context;

[0814] Def - Defines a value named by a symbol in the current execution context;

[0815] λ (Lambda) - Creates instances of functions (or closures) typically used in functional programming languages;

[0816] `let` - binds one or more symbols to values ​​in the local vocabulary context;

[0817] Query - Execute Op, but ignore all state changes;

[0818] Loops - Create executable code within loops, where recursion can be controlled by various runtime functions;

[0819] Special - Calculates and returns various special values ​​relevant to the current execution context.

[0820] Op is represented as a value in the form of a tree data structure, which may optionally contain sub-Op. In this sense, Op can be considered structurally similar to an "abstract syntax tree" commonly used in programming language implementations.

[0821] Runtime functions

[0822] In addition to the operations executed by the VM, the VM also provides the system with a set of built-in core runtime functions. These are typically used to provide user code with the ability to access the VM's programming capabilities. This embodiment uses runtime functions, including but not limited to:

[0823] Common numerical operations (addition, subtraction, square root, etc.);

[0824] Functions used to manipulate and query data structures (e.g., construct vectors);

[0825] Control flow construction (at a higher level than, for example, Cond);

[0826] Functions used to support the creation of macros;

[0827] Functions used to support network operation-related operations, such as placing stake on one or more peer nodes;

[0828] Functions used for transferring and managing funds on a network;

[0829] Functions for transferring and managing memory allowances for accounts;

[0830] Functions used to facilitate invocation and interaction with actors and smart contracts;

[0831] Functions for managing account security (such as rotating the Ed25519 public key).

[0832] Extensions and compilation

[0833] The VM implements an on-chain compiler to transform code (represented in Lisp form) into a compiled Ops tree ready for execution. For example, the code "(if true 2 3)" will be translated into the Ops tree "(Cond (Constant true) (Constant2) (Constant 3))".

[0834] The compiler includes an extender function that transforms the code form before compilation, similar to most Lisp-based languages. This allows users to define custom macros to extend the language while still compiling to the same standard set of base Ops. This embodiment uses the "extension pass-through" of the macro extender (Dybvig, Friedman, Haynes 1988).

[0835] The process of executing the code provided as a Lisp form is as follows:

[0836] Expand the form using the default expander;

[0837] Compile the forms using an on-chain compiler;

[0838] Execute the generated Op (which may be the root of the Ops tree).

[0839] Users can also choose to compile their code off-chain and submit Ops directly for execution. This offers some benefits in terms of lower transaction costs and improved performance, so it is encouraged if users do not need to use on-chain compilation.

[0840] User Code

[0841] User code can be deployed on a VM (as part of its state), which uses the aforementioned capabilities to implement custom functionality. Because this functionality is Turing complete, any user functionality can be implemented. For convenience, some user code in the form of utility functions and tools can be automatically deployed to the VM as part of network initialization.

[0842] User code can be specified as an Ops tree intended for direct execution on the VM, or alternatively as a Lisp form that is expanded and compiled before execution.

[0843] User codes can be stored in the user account's environment, or alternatively included directly in submitted queries or transactions.

[0844] Transaction cost billing

[0845] This embodiment implements a transaction fee system. Figure 8 This aims to stimulate the effective use of network resources.

[0846] If at any time the transaction fee exceeds the maximum allowed fee, the transaction will be aborted with a Juice error, and the user will not receive any refund.

[0847] Memory billing

[0848] At the end of each transaction, the VM checks the memory size of the state to see if it has changed.

[0849] VM calculates unit memory size in the following way:

[0850] 64 + [Memory size of the encoded unit data] + [Sum of memory sizes of any referenced sub-units]

[0851] Note: The constant 64 given here is an estimate of the number of bytes of overhead involved in the storage of each unit.

[0852] For efficiency purposes, whenever the memory size is calculated for any cell, the memory size is cached, and the cached memory size can also be written into memory along with the cell value.

[0853] If a transaction results in an increase in memory size, that increase is subtracted from the account's memory allowance. In the case of a decrease, the difference in memory size is refunded to the account's memory allowance as a refund.

[0854] If the account's memory allowance is insufficient to cover additional memory consumption, try using funds to purchase additional memory allowances from a smart contract.

[0855] If any required memory allowance is successfully used, the transaction will complete normally. Otherwise, the transaction will be aborted, any state changes will be rolled back, and an error will be reported to the user.

[0856] Incentive pool

[0857] This embodiment implements an incentive pool system to reward peer nodes for participating in consensus. As part of the VM, the management of these pools is simplified.

[0858] [ Figure 7 This shows how block rewards are channeled through incentive pools to reward peer participation and penalize bad peers. The governance account

[71] allocates funds

[77] to the long-term block reward pool

[72] to fund network operations over many years.

[0859] Over time, funds are gradually released

[78] as part of an agreement that deposits the funds into a “current block reward pool”

[73] . The transfer rate is configured to be a percentage of each year

[72] (e.g., 20%).

[0860] The current block reward pool is used to reward good peers [74 and 75] [79 and 710], where the share of the reward pool is proportional to their stake and is paid out over time. The total payout rate is configured as a percentage of

[72] per hour (e.g., 10%).

[0861] Bad peers

[76] are penalized by removing some or all of their stake ("reduction")

[711] , which is then redistributed to the current block reward pool.

[0862] Because the stake removed from bad peers is quickly redistributed through the current block reward pool, good peers have a strong incentive to detect and punish bad peers, as they will share the rewards for doing so.

[0863] Client

[0864] The network can be joined at any time by a client, which may include a user application such as a web browser or a mobile device. The client computer

[14] connects to the peer node

[11] in order to submit and communicate

[15] information about the transaction.

[0865] The client corrects one or more peer nodes in the following ways:

[0866] Using the peer-to-peer protocol, directly connect to the open TCP / IP port of the selected peer node.

[0867] Access via HTTP REST API using commonly understood web encoding and protocols (such as JSON).

[0868] For example, if the client functionality is also implemented in the server process of the peer node or in a concurrently operating process with appropriate access permissions, then the peer node implementation can be accessed directly.

[0869] Clients typically need to maintain secure private keys, which is necessary for them to sign transactions submitted to peer nodes. Under normal circumstances, clients should not disclose their private keys to any third party.

[0870] trade

[0871] Clients typically interact with the network by submitting transactions (such as TRANSACT messages using peer-to-peer protocols). Transactions typically include:

[0872] The sequence number, where 1 is the first transaction, and subsequent transactions are sequentially numbered (to prevent "replay attacks" of the same transaction).

[0873] The address used for the account;

[0874] Digital signatures enable nodes to verify that a transaction was signed with the correct private key from a user account;

[0875] The payload is typically in the form of VM code to be executed.

[0876] Peer nodes typically report the transaction results back to the client after confirming that the transaction is included in the block in the consensus.

[0877] Client library

[0878] To facilitate application development, the client library provides a simple API for programmatically accessing network capabilities. Performance features include:

[0879] Prepare and submit transactions to be executed by the peer network;

[0880] Query data on peer nodes (e.g., request the user's current fund balance from the latest consensus state).

[0881] Execute transactions synchronously (waiting for confirmation of the result) or asynchronously (submitting a request and checking the result later);

[0882] APIs used to interact with specific smart contracts.

[0883] The client library is provided for a variety of different programming languages, such as Java, Python, C, and JavaScript. These different language versions of the client library allow users of specific programming languages ​​to access the performance of the decentralized network using APIs, interfaces, and idioms that are more familiar to them. For example, in Java, a connection to the network is represented by an instance of a Java class.

Claims

1. A system for achieving effective consensus, comprising: One or more nodes of various types are arranged in a network as arbitrary communication and functional participants, wherein at least the first node type is called a peer node. A means for producing trusts by the peer nodes such that each trust contains data for forming consensus; A trust merging function that combines one or more trusts; The peer nodes are configured to maintain the consensus of the network according to a consensus protocol, which includes applying the trust merging function to trusts. The trust merging function is defined as a property that makes the network exhibit convergence to consensus.

2. The system according to claim 1, wherein, At least the second node type is referred to as a client; and The client is configured to submit a new transaction that affects the consensus and the query information generated by the consensus of the network.

3. The system according to claim 1 or 2, wherein, The trust merging function is defined using idempotent, associative, and commutative computation, such that under normal circumstances, the system can operate as a conflict-free, replicated data type, but rejects certain information that does not meet consensus or verification requirements, thus providing Byzantine fault tolerance.

4. The system according to claim 1, further comprising: A specific type of information unit called a block; The specific type of information unit, i.e., all or part of the block's sorting, including values ​​and units, is included as a component of trust; State transition functions are able to calculate and update the state given a certain sorting. One or more initial states; The consensus state is calculated by repeatedly applying the state transition function to the initial state and one or more information units included in the ordering.

5. The system according to claim 4, further comprising: A collection of zero or more information units, referred to as a transaction, is included as a component of each block; Optional additional information provided by the peer nodes; The blocks, their constituent transactions, and any additional information are arranged to be included as part of the sorting.

6. In the system according to claim 5, the optional additional information is a timestamp or a digital signature.

7. The system according to any one of claims 4 to 6, in, The information unit in the ordering is defined as not containing references to one or more previous information units, such that the blocks are reordered during the consensus process.

8. The system according to claim 7, further comprising: A device for calculating consensus ordering; The apparatus for calculating consensus ordering calculates consensus ordering as part of the trust merging function.

9. The system according to claim 8, further comprising: A device for allocating rights to peer nodes; The stake-weighted sorting and merging process is included as part of the calculation of the consensus sorting; The equity-weighted sorting merge is used to resolve conflicts between sortings proposed by different peer nodes.

10. The system according to claim 8, further comprising: A device for calculating common prefixes; This involves utilizing the computation of common prefixes between sortings to reduce the computational cost for consensus.

11. The system according to claim 1, further comprising: Devices used for detecting new things; The node that observes something new will communicate the new information to other nodes; The nodes omit the transmission of information that is not new, in order to save network resources and processing costs.

12. The system according to claim 1, further comprising: A means for representing information values, wherein the information values ​​are represented as one or more units; A means for generating codes for units; A device for smart referencing, which enables a reference to the unit to be included within the information and / or encoding of another unit; A means for embedding an encoding within another encoding so that any value can be fully represented as a graph of units connected by the smart reference.

13. The system of claim 12, wherein the means for generating the code for the unit is in a form suitable for storage or network communication.

14. The system according to claim 4, further comprising: A device for generating a value ID for a cell; The value ID is used as a unique reference for the information unit.

15. The system of claim 14, wherein the means for generating a value ID for a cell is a cryptographic hash function applied to encoding.

16. The system according to claim 1, further comprising: Convergence and storage of information values; In this process, the node's working memory only needs the information units that are currently in active use, while other information units are persistently saved to persistent storage and / or deleted when no further processing is needed, i.e., garbage collection. Adding new information to memory has a convergence property, thus avoiding data inconsistency.

17. The system according to claim 1, further comprising: A device for calculating the memory size or other information values ​​of a computing unit; Devices used for memory billing; The memory metering is used to distribute incentives to participants on the network in order to save memory, storage and / or communication bandwidth.

18. The system of claim 17, further comprising: A device for caching the memory size calculated for each unit or unit of information in working memory and / or storage; The size of the cache memory is used to reduce the computational complexity of calculating the memory size for big data structures, so that only the memory size for new things needs to be calculated.

19. The system according to claim 4, further comprising: A means for arranging trusted code execution as part of the state transition function; Among them, it is possible to use trusted code execution to implement smart contracts or other programmable functions that can affect the consensus state.

20. The system according to claim 16 or 18, further comprising: One or more monotonic headers that associate header information with information values ​​and / or units; The monotonic head also provides convergence properties, which are then used for caching, performance optimization, and marking of unit states.

21. A computer-implemented method for achieving effective consensus, comprising: Arrange one or more nodes of various types as arbitrary communication and functional participants in the network, wherein at least the first node type is referred to as a peer node. Trusts are generated by the peer nodes, such that each trust contains data for forming consensus; Merge one or more trusts into a trust merge function; The peer nodes are configured to maintain consensus in the network according to a consensus protocol, which includes applying the trust merging function to trusts. The trust merging function is defined as a property that makes the network exhibit convergence to consensus.

22. The method according to claim 21, wherein, At least the second node type is referred to as a client; and The client is instructed to submit a new transaction, which affects the consensus and the query information generated by the consensus of the network.

23. The method according to claim 21 or 22, wherein, The trust merging function is defined using idempotent, associative, and commutative computation, such that under normal circumstances, the system used to achieve effective consensus can operate as a conflict-free, replicated data type, but rejects certain information that does not meet consensus or verification requirements, thus providing Byzantine fault tolerance.

24. The method of claim 21, further comprising: A specific type of information unit called a block; The specific type of information unit, i.e., all or part of the block's sorting, including values ​​and units, is included as a component of trust; State transition functions are able to calculate and update the state given a certain sorting. One or more initial states; The consensus state is calculated by repeatedly applying the state transition function to the initial state and one or more information units included in the ordering.

25. The method of claim 24, further comprising: A collection of zero or more information units, referred to as a transaction, is included as a component of each block; Optional additional information provided by peer nodes; The blocks, their constituent transactions, and any additional information are arranged to be included as part of the sorting.

26. The method of claim 25, wherein the optional additional information is a timestamp or a digital signature.

27. The method according to any one of claims 24 to 26, The information unit in the sorting is defined as one that does not contain references to one or more previous information units, such that the blocks are reordered during the consensus process.

28. The method of claim 27, further comprising: Calculate consensus ordering; The consensus ordering is calculated as part of the trust merging function.

29. The method of claim 28, further comprising: Allocate rights to peer nodes; The stake-weighted ranking and merging process is included as part of the consensus ranking calculation; The equity-weighted sorting merge is used to resolve conflicts between sortings proposed by different peer nodes.

30. The method of claim 28, further comprising: Calculate the common prefix; This involves utilizing the computation of common prefixes between sortings to reduce the computational cost for consensus.

31. The method of claim 21, further comprising: Detecting new things; The node that observes something new will communicate the new information to other nodes; The nodes omit the transmission of information that is not new, in order to save network resources and processing costs.

32. The method of claim 21, further comprising: The information value is represented as one or more units; Generate encoding for the unit; Implement smart referencing, such that a reference to the unit is included within the information and / or encoding of another unit; Encoding is embedded within another encoding, so that any value can be fully represented as a graph of units connected by the smart reference.

33. The method of claim 32, further comprising: The code for the unit is generated in a form suitable for storage or network communication.

34. The method of claim 24, further comprising: Generate a value ID for the cell; The value ID is used as a unique reference for the information unit.

35. The method of claim 34, further comprising: A value ID is generated for the cell by using a cryptographic hash function applied to the encoding.

36. The method of claim 32, further comprising: Convergence and storage of information values; In this process, the node's working memory only needs the information units that are currently in active use, while other information units are persistently saved to persistent storage and / or deleted when no further processing is needed, i.e., garbage collection. Adding new information to memory has a convergence property, thus avoiding data inconsistency.

37. The method of claim 21, further comprising: The memory size or other information value of the computing unit; Memory is billed; The memory metering is used to distribute incentives to participants on the network in order to save memory, storage and / or communication bandwidth.

38. The method of claim 37, further comprising: The memory size calculated for each unit or unit of information is cached in the working memory and / or storage. The size of the cache memory is used to reduce the computational complexity of calculating the memory size for big data structures, so that only the memory size for new things needs to be calculated.

39. The method of claim 24, further comprising: The execution of trusted code is arranged as part of the state transition function; Among them, it is possible to use trusted code execution to implement smart contracts or other programmable functions that can affect the consensus state.

40. The method according to claim 36 or 38, further comprising: One or more monotonic headers that associate header information with information values ​​and / or units; The monotonic head also provides convergence properties, which are then used for caching, performance optimization, and marking of unit states.

Images