JP7288264B2 - Transaction sequence consensus method and system - Google Patents

Description

TECHNICAL FIELD This application relates to the field of computer technology, and more particularly to transaction sequence consensus methods and systems.

Transaction sequence consensus refers to ranking a group of transactions and reaching consensus on the ranking, which is the core content of blockchain technology. Transaction sequence consensus is also a core objective in blockchain technology. The essence of the blockchain system is a decentralized network clock, where each node has a unified understanding of time interpretation and progression rules, but the time progression right is monopolized by a single node. Also, it is not possible to predict which node will complete the next time advance. Each time time advances, a new timestamp is generated based on the previous timestamp and a group of possible transactions that have been received but have no bound timestamp. Nodes determine the causal order of transactions by consensus on dependencies on timestamps and binding relationships between transactions and timestamps, i.e., transactions bound by the same timestamp are concurrent. , is later than the transaction bound by the immediately preceding timestamp, thus analogizing the transaction for all timestamps.

A blockchain is a data structure that stores timestamp dependencies and binding relationships between transactions and timestamps. Consensus and cryptographic methods in blockchain technology are based on the idea that a blockchain can provide incremental backups that are irreversible and tamper-proof to some extent. to realize

Currently, the transaction sequence consensus method in blockchain technology generally includes four steps: "leader election, block generation, verification, and storage in the chain". Leader election is that each node in the consensus network competes and elects to become a leader node with time progression. The transaction bound with the selected timestamp is packaged into a block and transmitted to other nodes, and the verification and storage in the chain are performed by the consensus node, which receives the block generated by the leader node. It is to verify and write blocks that pass verification to the blockchain and execute them. The essence of leader election and block generation is to elect a leader node to complete one time progression.

However, since a node has no provable timekeeping means when it receives a transaction and accepts transactions in a buffer without discrimination, it loses the chronological information of when a transaction arrived at that node, and when a node performs a sequence Lack of objective evidence of chronology forces us to use non-chronological information bases such as fees, so that transactions receive sequence priority with high fees. The leader node's time progression includes privileges such as selection of transactions waiting for binding, generation of timestamps, determination of causality, and acquisition of bonuses, which causes irrational competition among nodes in the leader selection process. and can consume a lot of resources. Nodes are subjective in choosing and packaging transactions into blocks, often relying on subjective profit maximization rather than objective chronological evidence of transactions, and nodes are subject to objective evidence , the transaction sequence result loses its authenticity and is effectively a falsification of the actual timeline of transactions.

The present application addresses the problems in the prior art, such as lack of transaction sequence ability due to information loss, unfair competition and waste due to leader node competition, and unfair transaction sequence due to subjective operation of leader nodes, and the above problems. A transaction sequence consensus method and system for solving problems derived from

For descriptive convenience, the actual time series of transactions entering the consensus network is called the "authentic time series", the time series of transactions arriving at a node is the node's "arrival time series", and the time when a transaction enters the consensus network. A node's judgment on the sequence is called the "restored timeline", and the node's consensus on the timeline of transactions entering the network is called the "consensus timeline".

In the present application, 1) provide a node with a timing means that can record its own arrival time series and transaction origin information to avoid information loss; 2) provide a node with the arrival time series information of each node; and based on the origin information of the transaction, infer the time series information of the transactions entering the consensus network, respectively, to provide a method for giving a restored time series, respectively; 4) to define a new timing measure in consensus to aid sequence consensus and avoid node misbehavior when providing information, improve consensus efficiency, reduce consensus cost; A new transaction sequence consensus method and system is provided for degradation.

In order to achieve the above objects, the embodiments of the present application employ the following technical configurations.

A transaction sequence consensus method according to a first aspect is a step of acquiring a consensus-waiting transaction and corresponding transaction information, wherein the transaction information includes a transaction number, transaction entry module information, transaction entry node information, transaction execution including waiting information and path information for obtaining consensus-waiting transactions; dividing consensus-waiting transactions into local transactions and non-local transactions based on the path information for obtaining consensus-waiting transactions; The steps of verifying, parsing, and synchronizing; obtaining the arrival time-series information of local transactions at the consensus node and introducing the local transactions into a persistently knotted local arrival rope; and synchronizing the local arrival ropes between different consensus nodes. and acquiring arrival time-series information of each node after synchronization; analyzing the arrival time-series information of each node according to preset restoration rules; and restoring two transactions at each node. Obtaining continuous restoration time series information of a series and a group of transactions and building a local restoration rope; exchanging and synchronizing the local restoration rope between different consensus nodes to restore each node after synchronization; A step of acquiring sequence information, and a step of performing consensus processing on the restored time-series information of the own node according to a preset consensus rule to acquire consensus time-series information and constructing a consensus slope including consensus transactions. and obtaining a consensus transaction on the consensus slope based on the analysis on the consensus slope; and updating state data based on the consensus transaction.

A transaction sequence consensus system according to a second aspect includes a transaction input module for generating a consensus-waiting transaction, a consensus network for analyzing and processing the consensus-waiting transaction to obtain a consensus time series of the consensus-waiting transaction, and a state a status acquisition module for displaying status changes of the data.

The technical configurations according to the embodiments of the present application can have the following advantageous effects.

In the present application, a consensus node builds a local arrival rope to record the time series of transactions arriving at the consensus node, so that the consensus network retains the time series evidence information of transactions arriving at the consensus node and collects information. It avoids loss, so that the consensus node can restore the time series of transactions entering the network based on the arrival time series of transactions, respectively, and the transaction sequence capability of consensus nodes is enhanced.

In the consensus method of the present application, there is no leader node, no need to compete for leader nodes, and the consensus nodes jointly rank transactions, so that irrational competition and resource consumption due to competing leader nodes are avoided. Waste can be avoided.

In the present application, the consensus node completes the ranking of transactions with a preset objective analysis method, based on the time-series evidence of transactions arriving at each node, to ensure the objectivity of the ranking process, and to ensure the objectivity of the ranking process. The ranking of transactions is not subjectively manipulated by any node, and the basis for ranking transactions is not factors unrelated to the time series of transactions (low transaction fees, etc.), but the results of the ranking are also fundamental. close to the time series in which the transactions actually occurred. In addition, transaction initiators get fair posting treatment and do not have to increase fees to seek to be posted, and because initiated transactions entered the network earlier, they may not be posted for a long period of time or may be posted later. This increases confidence in using consensus networks without worrying about losing transaction timeliness or first mover advantage.

In the present application, in a single-strand rope, one knotting time of the local arrival rope is approximately equal to one hash calculation time of the consensus node, and each knotting of the local arrival rope can be regarded as progressing time, so Local arrival ropes can be used as timers for transaction arrivals, and when designed in this way provide very high temporal resolution in timing transaction arrivals, and consensus ropes can also provide full permutation for transactions. The present application can not only realize the full permutation of transactions, but also accurately analyze the changes in the frequency of transactions arriving at the consensus node, and further, based on the arrival time series and consensus time series of transactions, perform big data analysis and An optimization process can be performed.

In this application, transaction consensus is equivalent to transaction confirmation, and transaction consensus does not need to be completed in batches with a block generation interval as in the Bitcoin scheme, and consensus progresses smoothly. This greatly reduces the transaction confirmation delay, thus avoiding the security risk of double payment attacks by artificially confirming one transaction.

In this application, if a consensus node builds an arrival rope persistently, and in such a design, the consensus node wishes to reverse the record of the arrival chronologies of two transactions, it will spend the same amount of time reconstructing such rope segments. This has greatly increased the difficulty for consensus nodes to maliciously tamper with the timeline of transactions, as they must also process incoming transactions while reconstructing rope segments. In particular, when using multi-strand ropes and strand-change ropes, it becomes more difficult to forge transaction arrival time series. , is recognized at the arrival rope processing stage of the consensus node, so that it cannot affect the generation of the subsequent consensus slope, and the fault tolerance of the consensus system is guaranteed.

In the present application, the consensus node restores the time series of transactions entering the network by objectively analyzing the time series of transactions arriving at the consensus node, and reaches consensus on the time series of transactions entering the network. , executes transactions according to the consensus timeline, and such a design makes the transaction execution timelines closer to the actual timelines of transactions entering the consensus network.

The present application builds on a mechanism in which decentralized time is generated by the network itself, where the progression of time is not completed by the leader node, and transaction sequences frequently transform the frame of reference. It eliminates the need and avoids the tendency of nodes to centralize to monopolize time progress. Since the arrival time series of a single node is not the final consensus time series, it can be avoided that the arrival time series of a single node directly enters the consensus time series.

In order to more clearly explain the technical configuration of the embodiments and the prior art of the present application, the drawings required for the description of the embodiments and the prior art will be briefly described below. Of course, these are just some examples of the present application, and those skilled in the art can also obtain other accompanying drawings based on these drawings without creative efforts.
1 is a schematic configuration diagram of a transaction sequence consensus system according to an embodiment of the present application; FIG. FIG. 4 is a schematic configuration diagram of another transaction sequence consensus system according to an embodiment of the present application; 1 is a schematic configuration diagram of a consensus node according to an embodiment of the present application; FIG. FIG. 4 is a schematic configuration diagram of yet another transaction sequence consensus system according to an embodiment of the present application; 1 is a schematic configuration diagram of a transaction input module according to an embodiment of the present application; FIG. 3 is a schematic configuration diagram of a state acquisition module according to an embodiment of the present application; FIG. 1 is a schematic configuration diagram of a transaction sequence consensus system including a consensus node device according to an embodiment of the present application; FIG. 4 is a flowchart of a method of a transaction entry module according to an embodiment of the present application; FIG. 4 is a schematic diagram of how a transaction entry module initiates allocation of entry nodes for consensus-pending transactions according to an embodiment of the present application; 4 is a flowchart of a transaction sequence consensus method according to an embodiment of the present application; 4 is a flowchart of another transaction sequence consensus method according to an embodiment of the present application; 4 is a flowchart of a method for validating and analyzing a consensus-pending transaction according to an embodiment of the present application; FIG. 4 is a schematic diagram of how a consensus node validates a local transaction according to an embodiment of the present application; 1 is a schematic configuration diagram of an arrival rope according to an embodiment of the present application; FIG. FIG. 4 is a schematic diagram of a method of persistently tying a knot to extend a local arrival rope according to an embodiment of the present application; FIG. 5 is a schematic diagram of another method of persistently tying a knot to extend a local arrival rope according to an embodiment of the present application; FIG. 2 is a schematic diagram of a method for a consensus node according to an embodiment of the present application to process transaction arrival time series information according to a preset restoration rule, and output a restoration time series for every two transactions and a restoration time series for all transactions; be. FIG. 4 is a schematic diagram of a method for a consensus node to build a local restoration rope and store restoration time series information according to an embodiment of the present application; 1 is a schematic configuration diagram of a consensus application program according to an embodiment of the present application; FIG.

In order for those skilled in the art to understand the technical structure of the present application more easily, the technical structure of the embodiments of the present application will be clearly and completely described below with reference to the drawings of the embodiments of the present application. Examples are only some, but not all, implementations of the present application. Based on the embodiments of the present application, other embodiments obtained by persons skilled in the art without creative efforts also fall within the protection scope of the present application.

It should be noted that terms such as "first" and "second" in the specification, claims, and drawings of the present application are for distinguishing similar objects, and are not specified in a specific order or priority. It is not used to describe The data used in this manner may be interchanged in appropriate circumstances, and it is understood that the embodiments of the application described herein may be performed in an order other than that illustrated and described herein. I can understand. Also, the terms "including" and "having" and any variations thereof are intended to be non-exclusive.

A transaction is a carrier of intent to change state, and state is the actual result of executing a transaction. It is the transaction that is started and the state that is obtained. A state is the basis for starting a new transaction, and a transaction is the motivation for creating a new state. Only executed transactions can change state, and different transaction execution orders produce different state change trajectories. A single chance to change state is a one-time resource. After a state is created, there is a window of opportunity for this state to change, and after this state changes to a new state, there is no window of opportunity for the original state to change. That is, after one transaction changes from the original state to the new state, another transaction will not make another change based on the original state.

Intention does not necessarily change reality, and transactions for which causal ordering is determined are not necessarily executed. In order for a transaction to be executed, two conditions must be satisfied: that the underlying state has not been changed by another transaction, and that the expected execution result of the transaction satisfies rationality. If two transactions contradict each other, the causal order of the transactions needs to be determined, the earlier transaction is executed, the later transaction is abandoned, and the underlying state is preset for the two transactions. If not, the subsequent transaction will not be executed because it is based on an unknown new state, and the expected execution result may lose rationality, and any subject may abandon or relinquish their will. Unwilling to be throttled, transactions need to contend for causal order and therefore submit requests to the transaction sequencing mechanism.

In a consensus network, data is stored in copies on different nodes, and each node modifies the state of the data copy by receiving and executing transactions. In order for data copies to have consistent synchronous state change trajectories, nodes must reach consensus on the causal order of transactions, and determine the execution order of transactions according to the agreed causal order of transactions. .

However, in the network space, astronomical phenomena in the physical space are not used as a reference frame. I have to. The network space is artificially created, the activities within the network can also be subjectively controlled, and the right to interpret, process, and publish network time is monopolized by a single node. or to avoid forming a particular dominance requires the establishment of a time mechanism that is not operated by a small number of nodes.

The prior art also has the following problems. By binding a group of transactions to the same time, the block generation mechanism assumes that this group of transactions occurs at the same time, reducing the resolution of the transaction time series and obviously not matching the actual time series of the transactions. . When blocks are copied across the network from a single node, block synchronization is delayed, and the system sets the block generation difficulty to maintain a stable block generation interval to ensure that blocks are distributed across the network. ensure a sufficient window of time to ensure that it is synchronized with the It gives the attacker enough time window to do evil. Block data is only probabilistically confirmed after multiple rounds of consensus, resulting in high transaction confirmation delays. This means that the network state data is in uncertainty for a long period of time, and such uncertainty poses risks to the subject's decision making.

Interpretations for related terms in this application are as follows.

State: In a system with memory, when a transaction is described by setting multiple reference items to one or a group of subjects, and the values of these reference items are constant, this transaction is "in a certain state." , and when the value of any one of these reference items changes, or the number of reference items changes, we say that a "state change" has occurred for this transaction.

The state of a transaction is obtained by the state changes immediately preceding this transaction, ie each state change changes from one "initial state" to a "final state". Such a state change relationship is expressed using S, and the state change relation is also a type of transaction.

ける要素とで１対１のマッピング関係が確立し、自然数の大きさの順序は、状態変化軌跡における要素によって生成される順序と１対１に対応する。状態展開集合は、状態におけ

は、軌跡における全ての要素の展開集合内の要素の集合であり、

State change trajectory: when the state of a transaction is changing, this transaction also generates a new state change relation with this change, the state change relation generated in the past forms a permutation according to the order of its generation, This permutation is called the "state change trajectory" of this transaction.

A one-to-one mapping relationship is established with the elements in the state change trajectory, and the order of magnitude of the natural numbers corresponds one-to-one with the order generated by the elements in the state change trajectory. The state expansion set is

is the set of elements in the expanded set of all elements in the trajectory, and

Time reference system: In reality, it is impossible for any entity to perceive all state changes in all transactions. To reduce the difficulty of writing, one or a group of entities can only agree that the state change trajectory of one or more transactions is the time reference system. time

Time: When the time reference system is one whole, and if the time reference system also has a state change trajectory, each item in the state change trajectory of the time reference system becomes one time. Time Delay: The length of time of the time interval defined by two instants.

Time series: Uses the state change trajectory of the time reference system to mark the sequence of event occurrence times or expected occurrence times. Knowing that event 0 occurs between time i and time m, event 1 occurs between time m and time n, and that time j is earlier than time m, event 0 is event It can be determined to occur earlier than 1.

Timestamp: For the convenience of writing and communication, the code adopted corresponds one-to-one with the time in the time reference system, and the code is the time stamp. As the state change trajectory of the time reference system continues to extend, the timestamp also needs to have a corresponding generation scheme.

Subject: An individual or an entire group of individuals with state acquisition and transaction output capabilities. One entity generally includes multiple transaction input modules and multiple status acquisition modules, and also includes one database for storing the acquired system data and one buffer for storing the processing results of the system data. and a group of decision modules for analyzing and understanding the system state to decide to start a transaction. M represents a subject, I represents a set of transaction input modules, F represents a set of state acquisition modules, Σ represents a set of acquired system states, B represents a buffer, and D is , represents the set of decision modules.

Consensus node: abbreviated as a node, it is a special subject, directly or indirectly connected with each other to form a network, perform a sequence for a group of transactions in the network, and Consensus on causal and execution order. Consensus nodes can actively initiate transactions, enter transactions into the network on behalf of other parties, and synchronize transactions sent by other nodes.

Consensus network: abbreviated as network. A group is formed by building a network with variable number of consensus nodes, and consensus nodes can join or leave the consensus network according to preset rules. The transaction input module inputs consensus-pending transactions into the consensus network, specifically, the transaction input module inputs consensus-pending transactions into consensus nodes in the consensus network. Consensus nodes constituting one consensus network are not necessarily directly connected two by two, but there is always at least one path between two consensus nodes. G represents the consensus network topology, V represents the set of nodes of the consensus network, and E represents the set of node connection relations.

Entry of a transaction into the network: A transaction is considered entered into the consensus network when it is timed and signed by an entry node and then transmitted from the entry node to another node. Since the embodiments of the present application assume that the transaction is signed and transmitted immediately after being timestamped by the entry node, the consensus timestamp of the transaction represents the time at which the transaction entered the network. .

れる。Transaction Synchronization: The process by which transactions are transferred between nodes so that preferably every node in the network gets the transaction. of

be

Transaction Sequence Consensus: The attainment of a consensus understanding of the causal order of a group of transactions by the nodes in a consensus network. While the causal order of transactions determines the order of execution of transactions, differences in the order of execution of transactions produce different state change trajectories, and to ensure that states have consistent change trajectories, the consensus network , we need to reach a consensus on the order of transaction execution.

Consensus pending transaction: transaction number, transaction entry module indicator, entry node indicator, transaction entry module description of change request to system specified state data. A transaction entry module may be a user client or other device. The system realizes verifiability whether the transaction content has been tampered with by cryptographic means. Here, the content of the transaction waiting to be executed generally includes a user ID, a designated transaction executor ID, and an update description command waiting to be executed.

Authentic time series: Each transaction input module inputs a transaction into the consensus network to generate a time series of transactions entering the consensus network, which is referred to as an "authentic time series". The consensus network is decentralized, the transactions entered by the transaction entry module enter the consensus network with different consensus nodes in the consensus network as entries, and the time sequence in which all transactions enter the network under the conditions of the prior art. , and consensus nodes do not base their transaction ranking on any external timestamp. Therefore, the authentic time series will not be captured by all consensus nodes in the consensus network immediately after a transaction enters the network.

Arrival time series: Each consensus node in the consensus network obtains a transaction and synchronizes the transaction with other consensus nodes to objectively generate a time series of the arrival of the transaction at each consensus node, and this time series is called the "arrival time series". Each Consensus Node records its arrival time series with a clock that it builds. The manner in which a transaction "arrives" at one consensus node includes the transaction arriving at the consensus node with the consensus node as the entry consensus node, or the transaction entering the consensus network and being propagated to the consensus nodes by a synchronization mechanism. is included. Clearly, the recorded arrival time series of each consensus node may be different from each other, nor is the arrival time series equivalent to the authentic time series. Arrival generally means first arrival

Restoration time series: Consensus nodes synchronize their respective arrival time series records, analyze some authentic time series information contained in each arrival time series record according to preset rules, and Integrate the authentic time series information to restore each judgment for the authentic time series. The restoration of the judgment of the authentic time series by the consensus node is called "restored time series",

ーク及びユーザとやり取りを行い、特定のアプリケーションシナリオの需要の主体を満たす。Consensus timeline: A consensus network is the recognition of a match against a reconstructed timeline of a group of transactions. Consensus nodes share their reconstructed time series and form consistency judgments for the authentic time series according to a preset consensus processing method. In general, once a consensus timeline is formed, it cannot be reversed and can only be extended in one direction by adding new consensus transactions at the end. Therefore, a consensus node can make one unidirectional extension of the consensus time series one time progress of the consensus network, i.e., make the consensus time series the common clock of the consensus network, and the consensus node can use consensus time series to record time. the consensus time series

interact with the work and users to meet the demands of a particular application scenario.

Rope: A data structure containing a group of consecutively generated data blocks, where each data block is created immediately after the previous block is generated and contains the data of the previous block (generally , writing the hash value of the immediately preceding data block into that block), and each data block has a sequential number. It is written as Φ.

Knot: Each data block in a rope is called a knot. The knot structure includes a knot number, a previous chronological knot citation, a transaction citation, a verification item, and a verification rule number. The knot numbers are generally consecutive natural numbers, with knots generated later on the same arrival rope having a higher number than knots generated earlier. A previous chronological knot citation is generally the digital digest value of the immediately preceding knot immediately adjacent to the self-knot on the same local arrival rope. A transaction citation is generally a digital digest value of a transaction that is pending consensus and has been verified, and represents that the transaction has been introduced, or is a null value or a specific value, indicating that the transaction is not installed. For verification items, zero or more verification items are set to increase the difficulty of reconstructing the arrival rope and facilitate checking for tampered knots, and the verification items are proved by the current knot. It can be some feature state value. As for the verification rule number, it is possible to set the verification rule number and specify which verification rule each verification item is to be verified according to. From the program angle, the verification rule is a program segment that verifies the truth of the verification code, and the consensus node is preset with a group of verification rules. With the verification rule number, it is possible to know which segment's verification rule is to be executed.

One knot is represented by one structure and may be stored in memory, or may be stored in a file, database, or magnetic disk in a format such as JSON or XML. The format and storage location of the knot are not limited as long as there is a preset format for storing the contents of transaction quotes, verification items, etc. tie

Time rope: A rope for defining time and event timing (an act of associating an event with one time stamp), and the status change trajectory of the rope is used as a time reference system. In our example, there are two temporal ropes, the arrival rope and the consensus rope. The essence of the information contained in the time rope is a quadruple consisting of a set of timestamps, a set of transactions, a set of ordered relations of timestamps, and a set of binding relations between transactions and timestamps, where one timestamp is: Zero or more transactions can be bound. A blockchain is a special case of a time rope, where a block is actually a collection of a timestamp and the transactions to which this timestamp is bound.

省略され、トランザクション結び目のみを列挙する。ローカル到着ロープ：自ノードによって構築された到着ロープには、トランザクションが自コンセンサスノードに到着した時系列データが記録される。Arrival Rope: A feasible form of data and data structures for carrying arrival information, a temporal rope that is constructed by a consensus node to define local time and record the arrival timeline of transactions, and that the consensus node is a rope This is transaction arrival time-series data recorded by the method. We refer to this rope as the “arrival rope” because the rope records the chronological evidence that transactions have arrived at the consensus node. Here, in general, one consensus node builds only one arrival rope. For example, one local arrival rope built by node n0 is

Omitted to enumerate transaction knots only. Local arrival rope: The arrival rope constructed by the own node records the time-series data of transactions arriving at the own consensus node.

The present application will be described in more detail below with reference to the drawings.

Some embodiments of the present application provide a transaction sequence consensus system that can be applied as a temporal protocol and value transfer platform in the Metaverse.

As shown in FIGS. 1 and 2, the system includes multiple transaction input modules, a consensus network, and multiple state acquisition modules.

The transaction input module is used to generate consensus-waiting transactions, the consensus network is used to analyze and process the consensus-waiting transactions to obtain a consensus time series of the consensus-waiting transactions, and the state acquisition module is used to obtain the state Used to display data state changes.

As shown in FIG. 3, the consensus network includes N consensus nodes, which are a transaction processing sub-module, an arrival rope processing sub-module, a restoration rope processing sub-module, and a consensus rope processing sub-module. It includes a sub-module, a state processing sub-module, and a time processing sub-module.

A transaction processing sub-module is used to process local transactions and non-local transactions, and the transaction processing sub-module includes a local transaction processing unit, a non-local transaction processing unit, a transaction mark unit and a transaction storage unit. wherein the local transaction processing unit includes a local transaction acquisition subunit, a local transaction verification subunit, a local transaction analysis subunit, and a local transaction synchronization subunit. The non-local transaction processing unit includes a non-local transaction acquisition sub-unit, a non-local transaction verification sub-unit, a non-local transaction analysis sub-unit and a non-local transaction synchronization sub-unit.

The arrival rope processing sub-module is used to process the data of the local arrival rope and the non-local arrival rope, the arrival rope processing sub-module comprises a local arrival rope processing unit, a non-local arrival rope processing unit and an arrival time series. an information storage unit, an arrival time series information analysis unit, and an arrival rope processing optimization unit, wherein the local arrival rope processing unit comprises a local arrival rope initialization subunit and a local arrival rope notting subunit; , a local arrival rope synchronization subunit and a local arrival rope storage subunit. The non-local arrival rope processing unit comprises a non-local arrival rope acquisition sub-unit, a non-local arrival rope stitching sub-unit, a non-local arrival rope verification sub-unit, a non-local arrival rope analysis sub-unit, and a non-local arrival rope synchronization. and a non-local arrival rope storage subunit. The arrival time series information storage unit is used to store local and non-local arrival time series information. The arrival time series information analysis unit is used to analyze the arrival time series information. The arrival rope processing optimization unit is used to optimize the processing of arrival ropes in response to external inputs.

A restoration rope processing sub-module is used to process the data of the local restoration rope and the non-local restoration rope, and the restoration rope processing sub-module includes an arrival time series information acquisition unit, a local restoration rope generation unit, and a restoration rope synchronization. a unit, a local restoration time series information storage unit, a non-local restoration rope synchronization unit, a non-local restoration rope analysis unit, a non-local restoration rope verification unit, a non-local restoration time series information storage unit, and a restoration rope consensus time. and a sequence generation unit.

A consensus slope processing sub-module is used to process the data of the consensus slope, and the consensus slope processing sub-module includes a consensus slope initialization unit, a consensus slope notting unit, a consensus slope transaction verification unit, and a consensus slope transaction analysis. a consensus slope transaction execution unit, a consensus slope data analysis unit, a consensus slope synchronization unit, a consensus slope verification unit, and a consensus slope status output unit.

A state processing sub-module is used to process state data and exchange data with the state acquisition module, and the state processing sub-module includes a state data initialization unit, a state data update unit, and a state data verification unit. , a state data service unit, a state data storage unit, and a state data synchronization unit. The state data service unit includes a state data subscription management subunit, a state data active push subunit, a state data request response subunit, and a state data rights management subunit. The state data storage unit is used to store state data. A state data synchronization unit is used to synchronize state data.

The Time Processing sub-module is used by the user to obtain timestamps and to verify timestamps. The time processing sub-module includes a time definition unit, a time interpretation unit, a time verification unit, a time mark unit, a time acquisition unit and a time synchronization unit. Timestamps are used to mark the time that an action occurred, and in this application timestamps are not the year/month/day/hour/minute/second time display that people normally use, It is neither a time representation provided by a time source other than the consensus system, nor a time representation formed on the basis of some incremental quantity within the consensus system.

As shown in FIG. 4, in one embodiment, the system includes multiple transaction entry modules, a consensus network, and multiple state acquisition modules. Here, the consensus network includes N consensus nodes, and the consensus nodes include transaction processing, arrival time series information, restoration time series information, consensus time series information, state data, and time information. include. FIG. 2 is a detailed implementation of FIG. 4, and the present application not only includes the form of FIG. 2, but also includes other ways that other FIG. 4 can be implemented. A consensus node is embodied in detailed form through a transaction processing sub-module, an arrival rope processing sub-module, a recovery rope processing sub-module, a consensus slope processing sub-module, a state processing sub-module and a time processing sub-module, and the present application: It does not include only the implementation method of FIG.

As shown in FIG. 5, the transaction entry module includes a transaction initiation sub-module, a transaction entry node allocation sub-module, and a transaction transmission sub-module. Here, the transaction initiation sub-module is used to obtain the transaction trigger information, obtain the subject's will input to complete the transaction initiation, and submit the transaction to the transaction entry node assignment sub-module. The transaction entry node allocation sub-module obtains consensus node information from the consensus network, determines the entry node of the consensus-waiting transaction based on the preset entry node allocation rules, consensus-waiting transactions and consensus nodes, and executes the transaction. Used to submit to the Send submodule. The transaction sending sub-module is used to convey consensus-pending transactions to entry nodes.

As shown in FIG. 6, the status acquisition module includes a status display sub-module, a status request sub-module, a status subscription sub-module, a status synthesis sub-module, a status storage sub-module, and a status analysis sub-module. . The status display sub-module displays current or historical status data obtained by the status acquisition module. Here, in order to utilize the state data offline and reduce the number of data requests, the state display module can temporarily store the obtained state data without having to obtain the state data from the consensus node each time. The state storage sub-module is used to store the obtained state data. The state analysis sub-module is used to analyze the obtained state data and output the analysis result. The output of the analysis result forms the will of the subject through a series of processing and triggers the transaction input module. Transactions can be started.

Some embodiments of the present application provide a consensus node applied to the consensus network of the first part, as shown in FIG. 7, where the devices corresponding to the consensus node in FIG. 7 are: . The consensus node device includes an entry node device, an arrival time series node device, a restoration time series node device, a consensus time series node device, a state node device, and a time node device. The time series node device and the state node device are data-connected, the arrival time-series node device is data-connected with the restoration time-series node device, the restoration time-series node device is data-connected with the consensus time-series node device, and the consensus time-series The node device is data connected with the state node device, the time node device is data connected with the entry node device, the arrival time series node device, the restoration time series node device, the consensus time series node device and the state node device, and the full node device is , entry node, arrival time series node, restoration time series node, consensus time series node, state node and time node.

A transaction is started, an entry node is assigned to the transaction according to a preset allocation rule, and the transaction is input to the entry node. The entry node acquires and synchronizes the transaction, performs a series of processing on the transaction, to the arrival time series node. Here, the entry node classifies the transaction based on the entry node information possessed by the transaction, and the arrival time-series node obtains the transaction of the entry node, and according to the preset arrival rule, The sequence is recorded, and the arrival time series of its own node is transmitted to the restoration time series node. process the restored time series of its own node, send the restored time series to the consensus time series node, and the consensus time series node acquires and synchronizes the restored time series of the restored time series node, and follows the preset consensus rule process the restored time series into a consensus time series according to, send the consensus time series to the state node, and the state node obtains and executes transactions on the consensus time series according to the consensus time series, and updates its copy of the state data The time node defines time data using the consensus time series to input, output and process the time data, and the state acquisition module acquires state data from the state node.

The difference from the first aspect is that a consensus node in the consensus network has one or more node identities depending on the procedure of the transaction sequence consensus flow it is responsible for processing. A node identity includes:

Entry nodes receive transactions from the transaction input module and objectively generate an "authentic time series". The transaction processing submodule of the entry node receives transactions according to preset allocation rules and causes the transactions to enter the arrival time series node and the state node. The entry node apparatus includes an entry node including a local transaction processing module, where the local transaction processing module obtains and synchronizes transactions, performs sequence processing on the transactions, and forwards the transactions to arrival timeline nodes. where the local transaction processing module partitions the transaction based on the entry node information that the transaction has.

The transaction processing sub-module of the arrival time series node receives transactions from the entry node to objectively generate an "arrival time series", and the arrival rope processing sub-module constructs the arrival rope to obtain the arrival time series information. , and input the arrival rope to the restored time series node. The arrival time series node device includes an arrival time series node including a non-local transaction processing module and a local arrival rope processing module, where the arrival time series node is an arrival time series node in the system, where the non-local The transaction processing module acquires the transaction of the entry node, and the local arrival rope processing module records the arrival time series of its own node according to the preset arrival rule, and transfers the arrival time series of its own node to the restoration time series node. Send.

The restoration time series node receives the arrival rope from the arrival time series node, and the restoration rope processing submodule processes the arrival rope, constructs the restoration rope, records the restoration time series information, and converts the restoration rope to consensus time. Input to the series node. The restoration time series node device includes a restoration time series node including a non-local arrival rope processing module and a local restoration rope processing module, wherein the restoration time series node is a restoration time series node in the system, wherein the non The local arrival rope processing module acquires the arrival time series of the arrival time series node, and the local restoration rope processing module processes the arrival time series into the restoration time series of its own node according to the restoration rule set in advance. Send the series to the consensus time series node.

The consensus slope processing submodule of the consensus time series node receives the restoration rope from the restoration time series node, the consensus time series nodes achieve a consensus time series, and the consensus slope processing submodule builds the consensus slope. to store the consensus time series information, and send the consensus time series information to the state node and the time node. The consensus time series node device includes a consensus time series node including a non-local restoration rope processing module and a local consensus rope processing module, where the consensus time series node is a consensus time series node in the system, wherein non The local restoration rope processing module obtains and synchronizes the restoration time series of restoration time series nodes, and the local consensus slope processing module processes the restoration time series into a consensus time series according to a preset consensus rule, and this consensus Send the time series to the state node.

A state processing sub-module of the state node obtains the transactions from the entry node and the consensus timeline from the consensus timeline node, and executes the transactions according to the consensus timeline to complete changes to the state data. The state node device includes a state node including a non-local transaction processing module and a state processing module, where the state node is a time node in the system, where the non-local transaction processing module performs consensus according to a consensus timeline Obtaining the transactions on the timeline, the state processing module executes the transactions on the consensus timeline according to the consensus timeline to update a copy of the state data.

The time node causes the time processing submodule of the time node from the consensus time series node to input the consensus slope state information of the consensus time series node, the time node processes the consensus slope state information into time information, the entry node, the arrival provide time information to the time series node, the reconstruction time series node, the consensus time series node, the state node, and the time node, preferably the entry node receives the time information and adds a timestamp to the transaction, A series node receives time information and adds a timestamp to the current knot of the arrival rope, a restoration time series node receives time information and adds a timestamp to the output restoration rope, and a consensus time series node adds a timestamp to the current knot of the consensus slope, the state node receives the time information and adds the timestamp to the state data, the time node receives the time information and compares it with its own time do. The time node apparatus includes a time node including a time processing module, where the time node is a state node in the system, where the time processing module utilizes a consensus time series to define time data. , input, output, and process time data.

The full node device includes at least a transaction processing sub-module, an arrival rope processing sub-module, a restoration rope processing sub-module, a consensus rope processing sub-module, a state processing sub-module, and a time processing sub-module. In extreme cases, the nodes in the consensus network are either all full nodes or not all full nodes. The full node device is a consensus node, and the full node includes a transaction processing sub-module, an arrival rope processing sub-module, a recovery rope processing sub-module, a consensus slope processing sub-module, a state processing sub-module, and a time processing sub-module. , where the full node is the consensus node in the system, where the transaction processing submodule acquires and synchronizes the transaction and performs a series of operations on the transaction, where the consensus node is , the transaction is divided according to the entry node information possessed by the transaction, the arrival rope processing submodule records the arrival time series of the own node, synchronizes the arrival time series of the own node, and the arrival rope processing submodule acquires and synchronizes the arrival time series of other nodes, and the restoration rope processing submodule processes the arrival time series of its own node and the arrival time series of other nodes into its own node restoration time series, and restores its own node Synchronize the time series, the restoration rope processing sub-module acquires and synchronizes the restoration time series of other nodes, and the consensus slope processing sub-module converts the self-node restoration time series and the other node restoration time series into the consensus time series. processing, a state processing sub-module retrieving and synchronizing transactions on the consensus time series according to the consensus time series and updating a copy of the state data, and a time processing sub-module utilizing the consensus time series to define time data. to input, output, and process time data.

In one embodiment, a transaction sequence consensus system includes N transaction entry modules, F state acquisition modules, and a consensus network, wherein the consensus network includes M entry nodes and , H arrival time series nodes, K reconstruction time series nodes, J consensus time series nodes, L state nodes, and T time nodes. Since one node can have multiple identities and even full node identities, the total number of nodes in the consensus network is less than or equal to (M+H+K+J+L+T), and in the extreme case all of the consensus networks are full nodes. Yes, ie the total number of nodes in the consensus network is M, and M=H=K=J=L=T.

Since the execution order of transactions is determined by the consensus slope, the transactions executed by each consensus node are actually duplicated calculations, and the execution efficiency of each consensus node is different. Synchronization becomes impossible, and the state data of each consensus node also becomes inconsistent in real time. As such, dedicated nodes may be established that are responsible for executing transactions and processing state data, and consensus nodes are responsible for completing consensus transactions.

State nodes obtain the latest unexecuted consensus slope segment and associated transactions from consensus nodes to complete the execution of transactions and work such as storing, updating, and subscribing to state data. A persistent connection may be established between a state node and a plurality of consensus nodes, a custom communication scheme may be used, the consensus node may oversee the execution node, or the execution node may They may supervise each other.

Since multiple consensus nodes can share the same state node, the computation and storage pressure of the consensus nodes can be alleviated, and waste of computation and storage resources can also be avoided.

Some embodiments of the present application provide a transaction sequence consensus method applied in a transaction sequence consensus system, first complete the following steps S0001-S0003 by a transaction input module, as shown in FIG.
In step S0001, transaction trigger information is acquired. The transaction can be submitted to the Transaction Entry Node Assignment sub-module by obtaining the subject's will input and completing the initiation of the transaction.
In step S0002, consensus node information in the consensus network is acquired.
In step S0003, the transaction entry node information of the consensus waiting transaction is determined based on the transaction trigger information and the consensus node information.

As shown in FIG. 9, the transaction entry node allocation sub-module obtains consensus node information including node address, port and communication protocol in the consensus network. The transaction entry node allocation sub-module obtains the operating parameters of the equipment of the consensus node. The transaction entry node allocation sub-module gets the transaction from the transaction initiation sub-module. The transaction entry node allocation sub-module determines the entry node of the transaction based on the node information according to preset entry node allocation rules. For example, as method 1, according to the designation principle, the transaction entry node allocation sub-module designates node 0 as the entry node of transaction 1, and as method 2, according to the polling principle, assume that there are a total of N nodes. , the transaction entry node allocation submodule designates the first node for the first transaction, the second node for the second transaction, the first node for the N+1th transaction, and method 3 , according to the random principle, the transaction entry node allocation sub-module randomly designates the entry node, and as method 4, according to the principle of proximity, the transaction entry node allocation sub-module already knows the communication delay information with each node. on the premise that one of the nodes whose communication delay is smaller than a certain threshold is selected as the transaction entry node, and as method 5, according to the principle of load balancing, the transaction entry node allocation submodule assigns each node Under the premise that the operation load information of and is already known, one of the nodes whose operation load is smaller than a certain threshold is selected as an entry node of the transaction.

Next, the transaction sequence consensus method includes steps S1001 to S1010, as shown in FIGS. 10 and 11. FIG.

In step S1001, a consensus-waiting transaction and corresponding transaction information are acquired. The transaction information includes a transaction number, transaction input module information, transaction entry node information, transaction execution waiting information, and path information for acquiring the consensus-waiting transaction. including. The transaction entry node information assigns entry nodes to consensus-waiting transactions according to preset allocation rules, where the preset allocation rules include designated, polling, random, proximity and load balancing, and the transaction entry node information Partition consensus-waiting transactions based on node.

In step S1002, the consensus-waiting transaction is classified into a local transaction and a non-local transaction based on the route information for obtaining the consensus-waiting transaction. Here, a local transaction is a transaction acquired by a certain consensus node by entering the network with its own consensus node as an entry node. In this application, it may refer to a single transaction or a group of transactions, depending on the context. For a certain consensus node, a non-local transaction is a transaction that enters the network with another consensus node as an entry node and is synchronized with its own consensus node. It can also refer to a transaction and is determined depending on the context. Here, the route information for acquiring the consensus-waiting transaction is acquired by acquiring the route list of the transaction synchronization message and adding the ID of the own node to the end of the route list of this transaction synchronization message.

In step S1003, the consensus-waiting transaction is verified, analyzed, and synchronized. Here, as shown in FIG. 12, the method of verifying and analyzing a consensus-waiting transaction consists of step S2001 of verifying a consensus-waiting transaction and acquiring a verification result based on preset verification items; , the step S2002 of marking the consensus-waiting transaction as a verified consensus-waiting transaction; the step S2003 of analyzing the verified consensus-waiting transaction to obtain an analysis result according to a preset analysis rule; marking S2004 the consensus-waiting transactions of the .

Here, in step S2001, as shown in FIG. 13, it is a schematic diagram of a local transaction verification method, for example, including some or all of the verification items listed below, but limited to the verification items listed below. not to be

(1) Check whether a duplicate transaction pending verification has been received. For example, after obtaining a transaction ID, it is searched whether or not the ID is included in already obtained transactions.
(2) Check if the awaiting verification transaction signature is correct. For example, if it is found that the digital signature of the transaction pending verification does not match the private key according to the digital signature verification method, it is determined that the verification of this item has failed.
(3) Check whether or not the structure of the verification-waiting transaction matches a predetermined structure. For example, if a preset rule stipulates that a transaction should be expressed in key-value pair format, and a transaction pending verification is not expressed in key-value pair format, or If the rules do not correspond or if the sequence order of the key-value pairs does not match, the verification of this item is judged to have failed.
(4) Check whether or not the structure of the verification-waiting transaction conforms to a predetermined structure. For example, a preset rule stipulates that the transaction ID is 20 digits in lower case letters, but if the transaction ID of the verification pending transaction is 19 digits, it is determined that the verification of this item has failed. For example, if the waiting content of the verification waiting transaction is empty, it is determined that the verification of this item has failed. Only when all pass the verification, it is determined that the verification is passed, otherwise, it is determined that the verification is failed, and the above verification items can be verified in parallel.

The local transaction verification sub-unit completes processing based on the verification result, i.e., upon passing the verification, calls the transaction mark unit to mark the consensus-waiting transaction as "verified", and passes the transaction to the local transaction analysis sub-unit. If submitted and fails validation, for example, delete the transaction from the transaction storage unit, or call the transaction mark unit to mark the transaction as "failed validation" and mark the associated transaction entry module as "untrusted". to process transactions.

In step S2002, a method for synchronizing an unsynchronized rope segment of a local arrival rope to other consensus nodes if a synchronization trigger condition of the local arrival rope is met. The specific steps of the method are as follows. The local arrival rope determines whether the synchronization condition of the local arrival rope is currently triggered, and if yes, performs the next step, otherwise after the next knotting of the local arrival rope is completed. Execute a step to generate a local arrival rope synchronization message, obtain a local arrival rope synchronization strategy, and synchronize according to the synchronization strategy. The Local Arrival Rope Synchronization message is written with the local arrival rope segment after compression and marks the synchronized local arrival rope segment as synchronized. The local arrival rope synchronization message includes at least the message publication timestamp, which is the chronological number and hash value of the trailing knot in the consensus rope when issuing the message, and the synchronization waiting local arrival, which may be compressed. It contains the rope and the signature of the Consensus Node of the issuer of the message.

A method for synchronizing non-local transactions comprises the steps of: a non-local transaction synchronization sub-unit obtaining a verified non-local transaction; the non-local transaction being unverified and synchronized to other nodes by its own consensus node; contains.

In step S1004, the arrival time series information of the local transactions at the consensus node is obtained, and the local transactions are introduced into the persistently knotted local arrival rope. During step S1005, before synchronizing the local arrival ropes among different consensus nodes, performing a segmentation process on the local arrival ropes to obtain arrival rope segments; and C. performing a compression process on the arrival rope segment, in which the compression process suspends transaction knots in the arrival rope segment and removes empty knots for non-marking of the arrival rope segment.

The purpose and function of the arrival rope will be specifically introduced below. If one consensus node can introduce a received transaction into the current knot as quickly as possible, the time generated by the current knot approximates the time the transaction was received by the consensus node. In general, the higher the knotting frequency, the smaller the time approximation error. As such, a transaction inserted into a knot earlier by the consensus node can be considered to have arrived at or been accepted by the consensus node earlier. Thus, the rope contains evidence of the relative chronology of transactions arriving at that consensus node. We refer to this rope as the “arrival rope” because the rope records the chronological evidence that transactions have arrived at the consensus node. Compared to the transaction buffer of the Bitcoin scheme, the arrival rope has at least three additional information dimensions: the consensus node where the transaction arrived, the time when the transaction arrived at the consensus node, and the transaction input module. greatly expanded. The arrival rope not only reflects the order before and after transactions arrive at the consensus node, but can also reflect changes in the frequency with which transactions arrive at the consensus node to some extent, and can also reflect the current network congestion situation. It can also approximately reflect the relative notting frequency of different consensus nodes, and can also reflect that local transactions entered the network later than non-local transactions that arrived earlier. From a security point of view, each knot in the rope depends on the previous one, so if you want to reverse the order of two transactions, you have to spend time constructing the relevant rope segments anew. must also be continuously introduced new incoming transactions into the rope during construction, otherwise there will be multiple transactions waiting to be introduced, and transactions must be introduced continuously, Such counterfeiting activities leave a mark on the rope and are easy to detect by other nodes. However, falsification of a single node's transaction arrival timeline is less likely to affect the eventual network-wide consensus on the transaction's entry timeline into the network. Therefore, it is useless for nodes to forge arrival ropes. The arrival rope can be regarded as a time-series data stream, the arrival rope of different steps can be selected, and statistics and probabilistic knowledge can be used to analyze the changing situation of transaction arrival frequency.

The specific steps of the local arrival rope initialization method are as follows. The purpose of the method is to determine the initial knot of the local arrival rope, a consensus node can join and leave the consensus network multiple times with the same digital identity, and each time it leaves the consensus network , the local arrival rope will stop knotting, causing a discontinuity, so every time you join the consensus network, you need to tell the consensus network that you will soon initialize a new local arrival rope to determine the initial knot this time. be. The process includes: In a consensus network with N consensus nodes, after the first consensus node joins the consensus network, each consensus node in the consensus network issues a specific type of "local arrival rope initialization transaction", the transaction includes , at least, the signature of its own consensus node, and the tail knot of the local consensus slope generated by its own consensus node when it joined the consensus network last time; or a specific value, the consensus network reaches consensus on the transaction, the consensus node writes the transaction into the consensus slope, executes the transaction according to a preset method, and the execution result is the transaction data and the consensus on which the transaction exists Generating a selection strategy that selects a group of consensus nodes based on rope data.

A consensus node inquires of other consensus nodes whether it has sent local arrival rope data to other consensus nodes, and the majority or all of the consensus nodes have received the arrival rope data. If it replies that it has never done so, it explains that the local consensus node must generate a local arrival rope from scratch, and marks the rest of the consensus nodes as suspicious nodes. State that a local arrival rope has generated a local arrival rope if most or all nodes return the latest rope segment of the arrival rope's data and the latest knots in the rope segment are the same , and should be generated following the previous local arrival rope, the latest knot is taken as the initial knot to generate this arrival rope, and the rest of the consensus nodes are marked as suspicious nodes.

In step S1005, synchronize the local arrival ropes between different consensus nodes and acquire the arrival time series information of each node after synchronization. Steps S1004 and S1005 above include the steps of initializing the local arrival rope of the consensus node, and persistently creating a knot containing the knot number, introduction knot data and verification item to extend the local arrival rope. , when a consensus node receives a local transaction, introducing the local transaction into the current knot of the local arrival rope; and meeting a preset synchronization trigger condition of the local arrival rope, an unsynchronized portion of the local arrival rope. with a consensus node other than the self node; receiving, verifying, and synchronizing a non-local arrival rope according to a preset arrival rule; analyzing the local arrival rope and the non-local arrival rope; and obtaining arrival time series information for each node.

Here, the local arrival rope is continuously knotted and extended, and the local transaction or non-local transaction arriving at the own node is immediately quoted to the current knot. The specific steps of the method are as follows. After the local arrival rope synchronization module confirms the data to be quoted by the initial knot of the local arrival rope, the local arrival rope knotting module knots the initial knot of the local arrival rope and sets the initial knot number to 0. , at this time, the initial knot is also the trailing knot of the local arrival rope. The local arrival rope knotting module immediately obtains the tail knot of the local arrival rope and immediately computes the digital digest of the tail knot data. The local arrival rope notting module checks whether there are consensus-waiting transactions that have not been introduced into the local arrival rope, and if so, locks one of them, obtains a digital digest of the transaction, and presents Determines that the knot is a transaction knot, and if there are no unintroduced consensus-waiting transactions, determines that the current knot is an empty knot, creates the current knot, and the number of the current knot is the number of the trailing knot. Add 1 to the number, make the trailing knot one of the contents of the current knot, and if the current knot is a transaction knot, take the digital digest of the transaction as one of the contents of the current knot, and make the current knot empty. knot, the default value is the content of the current knot. The number of transaction knots from the initial node to the self node is counted and used as one of the contents of the current knot. Get the number of the transaction knot immediately before the current knot and make it one of the current contents. Two alternative means can add a method of verifying the data of the arrival rope to increase the difficulty of reconstructing the arrival rope, but the amount of data of the arrival rope is also increased. Store the current knot created in the local arrival rope data. Trigger the next knotting process until the consensus node stops knotting the local arrival rope for some preconfigured reason.

As shown in FIG. 14, the structure of the arrival rope consists of a group of consecutive predecessor-dependent data blocks, where the predecessor-dependent data blocks generally refer to the creation of the N+1th data block. depends on the data of the Nth data block as input. Data blocks with dependencies on previous ones are created serially, so data block creation can be used to fix the passage of time for a period of time, and each data block creation is means progress.

It is a schematic structural diagram of a knot, and the knot structure generally includes a knot number that is a continuous natural number, and the number of knots generated later in the same arrival rope is greater than the number of knots generated earlier. , the previous chronological knot citation, which is typically the digital digest value of the immediately preceding knot adjacent to the self-knot on the same local arrival rope, and the digital digest value of the transaction, typically pending consensus and validated, where the transaction is A transaction quote that indicates that it has been introduced, or is null (null value) or a specific value and indicates that no transaction has been introduced to its own knot, and the difficulty of reconstructing the arrival rope has been increased and tampered and a verification item, which may be set to zero or more, and which may be some characteristic state value evidenced by the current knot, to facilitate knot checking; the total number of transactions introduced in the local arrival rope existing up to the knot of , the number of the knot in which the transaction immediately before the current knot was introduced, and the total number of transactions introduced in the knot a certain number before the current knot, and , the ID of the entry consensus node of the transaction introduced into the current knot, the digital digest value of the knot that satisfies the Nth feature before the current knot, and other preset feature values. For the verification rule number, a number for verifying rules may be set in order to flexibly increase, decrease, or change verification items in different knots, and it is possible to specify which verification rule each verification item is to be verified according to. From the program angle, it is a program segment that verifies the authenticity of the verification code, and the consensus node has a set of verification rules in advance. , to know which segment's validation rule to run.

In one embodiment, as shown in FIG. 15, the step of persistently creating knots applied to the N pending knotters and the scheduler to extend the local arrival rope asynchronously It includes the steps of sequentially calling to perform knotting operations, generating knot numbers, determining previous chronological knots and transactions waiting to be introduced, and creating introductory knots.

As shown in FIG. 16, in another embodiment, persistently creating knots applied to N pending knotters to extend the local arrival rope, each of the N knotters: Contend for a mutex that has a unique number and persists, an integer variable a for the mutex to generate the knot number, and a variable b for recording the number of the knotter that obtained the mutex in the most recent contend. After the notter obtains the mutex in competition, the step of adding 1 to the integer variable a possessed by the mutex to generate the current knot number, and the step of reading the variable b of the mutex a step of obtaining the number of the knotter immediately before the mutex was obtained by competition; a step of setting a variable b to the number of the own knotter to determine whether or not there is a transaction of the knot waiting to be introduced; knotting the transaction knot on the local arrival rope if there is a transaction; and immediately releasing the mutex and knotting the empty knot if there is no transaction on the introduction pending knot, wherein the transaction knot is , the number of the own knotter and the number of the previous knotter that obtained the mutex in the race, and empty knots are created knots with no transaction introduced.

In the above two embodiments, the knotting of the local arrival rope consists of obtaining the rope segment containing the current knot from the local arrival rope and calculating the current knot for the total number of knots in the rope segment containing the current knot. and increasing the knotter of the local arrival rope if the ratio exceeds a preset threshold; is also low, reducing the knotter of the local arrival rope.

In step S1006, the arrival time-series information of each node is analyzed according to a preset restoration rule, and the restoration time-series information of each two transactions and the continuous restoration time-series information of one group of transactions at the own node are obtained. and build a local restoration rope. Here, the step of obtaining the restoration time series of each two transactions and the continuous restoration time series information of one group of transactions includes the step of obtaining related transaction information among the arrival time series information, a step of selecting two transactions from related transactions in the information; determining restoration time series of the two transactions; outputting; and repeating until obtaining a restoration time series in which one group of transactions is continuous from the arrival time series information. The step of exchanging local restoration ropes between different consensus nodes includes obtaining consensus node information, obtaining arrival ropes, restoration ropes and consensus slopes as initial values, and generating a random number based on the initial values. and based on the consensus node information and the random number, generating a node combination that exchanges the restored time series information.

In one embodiment, we further present a method for consensus nodes to process the data of the restoration rope and the restoration time series of two transactions in parallel. Specifically, the method generates M=N*(N−1)/2 pairs of transactions, that is, M time series analysis tasks, for N consensus-waiting transactions, and utilizes multi-core resources. , M time-series analysis tasks may be processed in parallel, with each core processing one task, or multiple cores may be called to jointly process M tasks. and writing to the restore rope immediately each time we get the time-series analysis result of a pair of transactions.

In step S1007, local restoration ropes are exchanged and synchronized between different consensus nodes, and restoration time-series information of each node after synchronization is obtained.

Step S1008: perform consensus processing on the restoration time-series information of the own node according to a preset consensus rule to acquire consensus time-series information, and construct a consensus slope including consensus-completed transactions. In steps S1007 and S1008, the step of performing consensus processing on the restoration time-series information of the own node according to a preset consensus rule, acquiring consensus time-series information, and constructing a consensus slope includes: obtaining a non-consensus stable restored rope segment in the restored rope; receiving corresponding non-consensus stable restored rope segments of the other N consensus nodes; checking the non-local restored rope based on the received arrival time series information and restored time series information; Retaining a time series relationship that is more than two-thirds the same in a different rope segment compared to the reconstructed rope segment in which consensus is not reached and is stable until the same time series relationship is obtained. and repeatedly comparing multiple reconstructed rope segments to obtain consensus time series information and build a consensus slope.

In step S1009, based on the analysis on the consensus slope, obtain a consensus transaction on the consensus slope.

In step S1010, state data is updated based on the consensus transaction. The step of updating state data based on the consensus transactions includes: analyzing the consensus transactions on the consensus slope based on the consensus time series information; creating a transaction execution queue based on the consensus transactions; writing completed transactions to a transaction execution queue; and processing transactions in the consensus transaction execution queue with an executor according to queue processing rules.

This method analyzes transactions in the local consensus slope, creates a transaction execution queue, and writes executable transactions to the transaction execution queue. Specifically, the method involves the consensus slope transaction analysis module obtaining the first knot within a parsed and unexecuted rope segment in the consensus slope and searching for the corresponding transaction based on the transaction citations in the consensus knot. , pushing the transaction into the execution queue, and repeatedly executing the steps until all the transaction execution tasks in all ropes are pushed into the execution queue; a step of obtaining the transaction T at the head of the execution queue according to the order of , and the consensus slope transaction execution module obtains the execution waiting contents of the transaction T, and executes the transaction T based on the executor ID specified by the execution waiting contents and obtaining an executor E for executing Here, the executor E is essentially a program segment capable of executing transactions, and may be one executor, or an executor combination in which a plurality of executors are configured with a certain structure. There may be. The pending content of the transaction T is loaded into the executor E, and the executor E executes the pending content according to the preset execution rules, changing the state data or not changing the state data. Here, if the contents of the transaction T waiting to be executed do not meet the preset execution conditions, the executor E actually refuses to execute the transaction T. A change request is present, but it is up to the executor corresponding to the transaction to decide if and how the request is responded to. After executor E completes execution, it marks transaction T as "executed" and the consensus slope transaction execution module pops the executed transaction from the execution queue.

The steps for the executor to process the transactions in the transaction execution queue include the step for the executor to acquire the execution pending contents of the consensus transaction, the step for checking the execution waiting contents, and the step for converting the execution waiting contents into executable instructions. and modifying the state data according to the executable instruction when the corresponding transaction satisfies the execution condition of the executable instruction.

After updating the state data in step S1010, the transaction sequence consensus method further includes the consensus node obtaining a consensus time based on the state change trajectory of the consensus slope. The current time of consensus time includes the current time value and the verification value of the current time value, where the current time value is the number of currently consensus transactions in the consensus time series, and the current time of consensus time Get it and use it as a timestamp.

A specific process of applying the transaction sequence consensus method according to the present embodiment to the transaction sequence consensus system is as follows. Each transaction input module inputs a transaction into the consensus network to objectively generate an “authentic time series”.

(transaction processing module process)
Consensus nodes receive and synchronize transactions to objectively generate an "arrival timeline". Here, the transaction processing sub-module of the consensus node receives the local and non-local transactions, verifies, analyzes, stores and synchronizes the local and non-local transactions.

(Arrival Rope Handling Module Process)
Consensus Nodes record arrival time series information in a mutually understandable manner. where, after initializing the local arrival rope, the arrival rope processing submodule of the consensus node continuously notates and extends the local arrival rope, and immediately transfers the local or non-local transactions arriving at the node to the current forming evidence of the local arrival time series by citing the knot, and synchronizing the unsynchronized portion of the local arrival rope to other consensus nodes when a preset local arrival rope synchronization trigger condition is met; Receive, validate, store and synchronize non-local arrival ropes, and parse non-local arrival ropes to obtain non-local arrival time series. Here, the preset local arrival rope synchronization trigger conditions generally include that a local transaction was introduced into the current knot, the number of transaction knots or empty knots in the unsynchronized rope segment. including reaching a certain value, the hash value of the current knot conforming to certain characteristics, etc., where the method of obtaining the transaction arrival time series from the local and non-local arrival ropes is:

(restored rope processing module process)
Consensus nodes receive and synchronize the arrival time series information recorded by each node, analyze some authentic time series information contained in each arrival time series record according to preset rules, A "restored time series" is restored by integrating each part of the genuine time series information. Here, the restoration rope processing submodule of the consensus node obtains the transaction arrival time series information from the already obtained local and non-local arrival ropes according to the preset rules, and obtains the transaction arrival time series information according to the preset restoration rules. While processing the information to output the restored time series for every two transactions and the restored time series for all transactions, build a local restoration rope to store the restored time series information. Preferably, the restoration rope processing sub-module of the consensus node processes the data of the restoration rope in parallel to improve processing efficiency. Preferably, the consensus nodes timely remove redundant time-series data in the restoration rope to reduce the storage burden.

(Consensus slope processing module process)
Each consensus node receives and synchronizes the restored time-series information of each node, processes the restored time-series information with a preset processing method, and forms a consensus time-series. Here, the consensus slope processing sub-module of the consensus node exchanges the restoration time series information multiple times and performs consensus processing on the local and non-local restoration ropes to form a consensus time series. The consensus slope processing sub-module builds a local consensus slope storing consensus time series information. Preferably, the consensus slope processing sub-module randomly generates node combinations for exchanging restoration time series information, in order to avoid consensus nodes subjectively selecting node combinations for exchanging restoration time series information. . Preferably, the consensus slope processing sub-module verifies the data of the consensus slope to ensure that the consensus slope has not been tampered with and maintains as much state synchronization as possible with the consensus slopes of other consensus nodes.

(state handling module process)
A consensus node generates a state change trajectory that is consistent with each state data copy by executing transactions according to the consensus timeline. Here, the state processing submodule of the consensus node stores, verifies, and synchronizes state data, analyzes the transactions in the local consensus slope according to the consensus time series, creates a transaction execution queue, and executes the executable transactions. Write to the queue, call the executor corresponding to the transaction to execute the transaction in the transaction execution queue, complete the state change of the state data, and output the state data to the state acquisition module according to the rules agreed with the state acquisition module. . Preferably, in order to improve transaction execution efficiency, the state processing sub-module executes transactions in parallel, where the state processing sub-module actively pushes state data of subscriptions to the state acquisition module. and can respond to status acquisition requests of the status acquisition module.

(temporal processing module process)
A consensus node defines, interprets, and progresses a kind of time using the state change trajectory of the consensus time series. Preferably, after the time is generated in the transaction sequence system 1, consensus nodes can input, output and process the time information. Here, the time processing submodule of the consensus node defines the consensus time by taking the state change trajectory of the local consensus slope as the time reference system, and all consensus nodes interpret and progress the consensus time according to the matching rule to reach the current consensus It acquires time and puts consensus timestamps on events in the network, verifies consensus timestamps from other consensus nodes, and analyzes consensus time information for response optimization processing.

(state acquisition module process)
A state acquisition module acquires state data from the consensus network. Here, the state acquisition module agrees state acquisition rules with the consensus nodes to acquire state data from the consensus nodes, and stores and processes the state data. The state acquisition module can simultaneously acquire state data from multiple consensus nodes and accept multiple results therein, and can also accept the latest result therein, and synthesizes multiple results into one result. can also

In one embodiment, consensus nodes provide self-adaptive local time resolution to provide a way to build local arrival ropes in parallel, and all knots in the arrival rope are single-strand like a single-strand rope. construct the structure and call it a single-strand rope. In a single-strand rope, knots can only be generated synchronously and serially, which limits transaction write speed and processing resource utilization.

In order to make full use of multi-core processing resources and improve the time resolution of arrival ropes and the processing efficiency for incoming transactions, multi-core parallel knotting methods are proposed, including method 1 and method 2. Method 1 implements N notters waiting to be executed and one scheduler on the multi-core resource, and the scheduler asynchronously sequentially calls one idle notter each time to perform the notting operation, and calls each time. Before, the scheduler generates a knot number, determines a previous chronological knot, determines whether there is a transaction waiting to be introduced, the scheduler notters the knot number, the previous chronological knot, and the transaction waiting to be introduced and the knotter performs knotting according to the scheduler's input. Method 2: Implement N pending knotters on the multi-core resource, each of the N knotters has a unique number and continuously contends for a mutex, and the mutex generates a knot number. and a variable b to record the number of knotters that obtained the mutex in the most recent competition, and after one of them has obtained the mutex in the competition, the mutex possesses Add 1 to the integer variable a that is running to generate the current knot number, then read the variable b of the mutex to get the number of the knotter just before it got the mutex in competition, and then set the variable b to itself. Set to the number of the knotter, then check whether there is a transaction in the knot waiting to be introduced, if there is, decide to lock the transaction and knot to the transaction knot, otherwise knot to the empty knot , then immediately release the mutex and start knotting, the previous chronological knot of the knotted knot is the knot previously knotted by the own knotter, the knotted knot is the own knotter's number, the competition Also contains the number of the last notter that got the mutex in . Continuing to race the mutex after notting is complete.

According to the above method, N knotters produce a rope of N strands, N can be called the parallelism of the rope, and a rope with a parallelism of N can be called an N-strand rope. Furthermore, in order to increase the difficulty of reconstructing the rope, we set two previous time series knots, one of which is the last knot knotted by the own knotter, and the other is the previous time series knot. is the last knot knotted by the knotter who obtained the knotting right last time before his own knotter got the knotting right. In scheme 1 above, when the notter is called by the scheduler, it can be considered that the notter has obtained the notting right. In Scheme 2, when a notter wins a mutex in a race, it can be considered to have acquired the notting right. In addition, different degrees of parallelism occupy different computational resources, so different temporal resolutions are achieved. If the arrival frequency is not high, too high knotting parallelism is wasted, and if the transaction arrival frequency is high, low knotting parallelism cannot meet the time series resolution. In order to adjust the knotting parallelism in a self-adaptive manner based on the transaction arrival frequency, a self-adaptive changeable parallelism arrival rope knotting method and an arrival rope verification method are presented, in which the monitor Get the rope segment containing the current knot from the local arrival rope, statistic the ratio of the number of transaction knots in the rope segment to the total number of rope segment knots, and if the ratio exceeds some preset value, the local Increasing the parallelism of the arrival ropes and decreasing the parallelism of the local arrival ropes when the ratio is below some preset value. Ropes with varying degrees of parallelism may be referred to as strand-changing ropes.

In one embodiment, each consensus node performs a compression process on the data of its local arrival rope. Here, as method 1, the initial knot, the transaction knot, the tail knot, and some empty knots are reserved. As method 2, all initial knots, transaction knots, and unsynchronized rope segments are withheld. Method 3 reserves initial knots, transaction knots, tail knots, and knots whose number is an integral multiple of a given integer. There may also be other schemes aimed at withholding the basic information and deleting data derivable from the basic information.

In one embodiment, the consensus node uses statistical methods to analyze the data of the local and non-local arrival ropes to obtain feature change trajectories for the transaction input module, the consensus network, and the consensus node, and use the features. is a method of optimizing the corresponding response.

In one embodiment, this includes preconfiguring an analysis term that understands how often transactions arrive at a consensus node via local and non-local arrival ropes, which step includes a segment of arrival ropes (local arrival ropes). and obtaining the number a of knots included in the arrival rope of the segment, specifically, from the end knot number to the beginning knot number the number of transaction knots in the arrival rope of the segment b0, the number of local transaction knots b1 for the consensus node creating the arrival rope, and the number of local transaction knots b1 for the consensus node creating the arrival rope statistically comparing non-local transactions b2 to the consensus node creating the arrival rope, the frequency with which transactions arrive at the consensus node within the historical time represented by the arrival rope of the segment is b0/a. , the frequency at which local transactions arrive at the consensus node is b1/a, and the frequency at which non-local transactions arrive at the consensus node is b2/a.

In one embodiment, if the local arrival rope is a knotting extension form with variable parallelism, the arrival time series information analysis unit forms an analysis result by statistically changing the transaction arrival frequency within a certain period of time, and The rope processing optimization unit obtains the analysis result, and the analysis item corresponds to the parallelism change response rule of the arrival rope according to the preset association, so that the response rule is executed. When it gets and finds that the transaction arrival frequency exceeds a certain threshold, the response result is to increase the parallelism of the local arrival ropes.

In one embodiment, a consensus node obtains transaction arrival time series information from obtained local and non-local arrival ropes according to preset rules. The local arrival time series information has the same structure as the non-local arrival time series information, but differs in that the node in the local arrival time series information is the self node, and the transaction is the transaction that arrives at the self node. where the principle of obtaining transaction arrival time series information from local and non-local arrival ropes is that in the same arrival rope, the order of the number of knots where transactions exist is the local node of the arrival rope is the same as the arrival time series arriving at

As shown in FIG. 17, in one embodiment, the consensus node processes the transaction arrival time series information according to the preset restoration rules to generate the restoration time series of every two transactions and the restoration time series of all transactions. It is a method of output.

The preset restoration rule describes a transaction sequence consensus system including a consensus network G, a plurality of transaction input modules I and a plurality of state acquisition modules F, by way of example below. here,

Nodes 0, 1, 2, 3 constitute a consensus network, and as shown in FIG.

For convenience of calculation and explanation, it is assumed that the delay D between each node is a fixed value, specifically as follows.

そして、絶対時間が存在すると仮定し、絶対時間及び真正時系列に従ってトランザクションがネットワークに進入するスケジュール表を設計する。ここで、真正時系列におけるトランザクションはト、ランザクション入力モジュールによって、指定された時刻で指定されたノードに入力される。例えば、時刻１０で、トランザクション入力モジュール１がノード０をエントリノードとしてトランザクションＴ０を入力し、以下のように類推する。

To demonstrate the process by which consensus is reached for a group of transactions in a consensus network, assuming the objective existence of a true time series,

Then, assuming the existence of absolute time, we design a schedule in which transactions enter the network according to absolute time and true time series. Here, the transaction in the true time series is input to the designated node at the designated time by the transaction input module. For example, at time 10, transaction input module 1 inputs transaction T0 with node 0 as the entry node, and the following is analogized.

After timing begins, the designated transaction entry module causes the designated transaction to be entered into the designated entry node of the consensus network according to the schedule. Assuming t=0, each node's local arrival rope begins to knot, respectively:

Since each node has a different notting frequency, for t=10, the local arrival rope for each node is:

このとき、ノード０は、ローカル到着ロープの同期されていないセグメントを同期する。At this time, transaction T0 is captured by entry node 0, node 0 determines that transaction T0 is a local transaction, and verifies, parses, stores and synchronizes local transaction T0. Node 0 notates transaction T0 to the 1001 knot of the local arrival rope and notates it as follows.

Node 0 then synchronizes the unsynchronized segment of the local incoming rope.

このとき、ノード１は、ローカル到着ロープの同期されていないセグメントを同期する。When t=11, transaction T0 synchronized by node 0 arrives at node 1, node 1 determines that transaction T0 is a non-local transaction, verifies, parses, stores and synchronizes non-local transaction T0. do. At this time, since the end number of the local arrival rope of node 1 is 2200, node 1 notates the transaction T0 to the knot 2201 of the local arrival rope,

Node 1 then synchronizes the unsynchronized segment of the local incoming rope.

After a certain period of time, each transaction is entered into the consensus network and synchronized to each node, and the local arrival ropes of each node are also synchronized to other nodes in the consensus network.

各ノードの到着ロープのデータは、次のとおりである。

For simplicity of computation, we can ignore the locally generated processing time that nodes have for synchronizing transactions, and the "absolute time" for a transaction to arrive at each node, based on the delay settings between nodes. It turns out that it is as follows.

The arrival rope data for each node is as follows.

After each node receives the non-local arrival rope, it begins the restoration rope process. Taking node 0 as an example, we obtain the time series of transactions arriving at each node according to the local and non-local arrival ropes, as follows.

According to Restoration Rule 1 (restoration of consensus-waiting transactions is slower than restoration of consensus transactions), rule 1 cannot be used because there are currently no consensus transactions yet.

According to restoration rule 2 (same arrival and restoration time series for both local transactions at the same node), node 0's local transaction has T0 and T4, and node 1's local transaction has T1 and T5. , and it is known that node 2's local transaction has T2 and node 3's local transaction has T3.

According to Restoration Rule 3 (the greater the knot number difference in the arrival ropes where the two transactions being compared are the same), it is as follows.

According to restoration rule 5 (restored time series of transactions satisfy transferability), the result in combination with rules 2 and 3 is as follows.

At present, the reconstructed chronological relationships of T0 and T1, T1 and T2, T1 and T3, T2 and T3, T2 and T4, T3 and T4, T4 and T5 cannot be established yet.

According to restoration rule 4 (the greater the difference in the number of nodes where the two transactions being compared arrive first), for T0 and T1, T0 arrives earlier than T1 at nodes 0, 2, and 3. However, if T1 is earlier than T0 only in node 1, it is determined that T0 entered the network earlier than T1, and by the same principle, T1 is earlier than T3, T2 is earlier than T3, and T2 is earlier than T4. As soon as possible, it can be determined that T3 is earlier than T4, and T4 is earlier than T5. At this time, again according to Rule 5, it is as follows.

However, T1 and T2 each have two nodes whose arrival time series are earlier than their counterparts, and so far, the restored time series relationship between T1 and T2 cannot be determined yet.

According to Restoration Rule 6 (the interval between the arrival time series of two transactions at the same node is greater than some threshold), we obtain and compute knot numbers in the local and non-local arrival ropes of T0 and T1.

So far, node 0 can get the restored time series,

By the same principle, nodes 1, 2, 3 can obtain the restored time series according to the same method,

Node 0 sends the local reconstruction time series to other nodes, other nodes return their own local reconstruction time series, and node 0 compares the received non-local reconstruction time series to complete Upon finding a match, it is determined that the reconstructed time series has achieved the consensus time series.

The consensus slope obtained by node 0 writing the consensus time series into the consensus slope in order is as follows.

Node 0 analyzes the transactions in the consensus slope according to the consensus time series, writes them into the transaction execution queue, calls the transaction executors corresponding to the transactions one by one, executes the transactions in the transaction execution queue, and outputs the state data. Complete your changes. Other nodes do the same. For example, the contents of the transaction waiting to be executed are T0 requesting that the variable A be incremented by 1, T1 requesting that the variable A be incremented by 2, and 2 and 3 for the variable B, respectively. T2 requires adding 3 to variable A; T3 requires subtracting 3 from variable A; T4 requires subtracting 2 from variable A; There is a constraint that A and B must not be less than 0,
Before the transaction enters the network, the node's state data includes that A has a value of 1 and B has a value of 2.

When the consensus time series starts running, T0 runs and the value of A becomes 1+1=2, T1 runs and the value of A becomes 2+2=4, T2 runs and the value of B is 2, adds 3 to 2 to get 5, T3 is executed and the value of A becomes 4-3=1, T4 is executed and the value of A becomes 1-2<0 Then T4 is discarded because the constraint is not met, and T5 is discarded because T5 has been executed and the value of B is 5 and 1 cannot be added to 2.

At the same time, the state acquisition module acquires state data from any node. For example, get state module 0 requests the value of A from node 0, A sends back to node 0 the value of A at this time, get state module 1 has already subscribed to the value of B from node 2, Each time it updates the value of B, node 2 pushes the value of B to Get State Module 1, Get State Module 2 simultaneously solicits the value of A from Nodes 0, 1, 2, 3, and Get State Module 3. simultaneously subscribe to the value of A from nodes 1 and 2.

In one embodiment, a method for building a local restoration rope to store restoration timeline information. Constructing a topology map data structure, the topology map data structure is used to store and display the time-series relationship of consensus-waiting transactions that are analyzed and restored from the received arrival rope by their own consensus node and enter the network, and this map is called the “restoration rope”. Here, "points" in the restoration rope represent entities, "edges" represent relationships between entities, and both points and edges have types and attributes. Point types include transactions and consensus nodes, and edge types include issuing relationships (a single edge connecting a transaction entity and a consensus node entity that issues the transaction), chronological relationships (two One edge connecting transactions A and B, the attribute is the belief score of the consensus node that determines that the A transaction entered the network earlier than the B transaction, obtained by computing the belief score. The consensus node selects two transactions A and B from the set of consensus-waiting transactions, obtains the confidence score that A entered the network earlier than B according to the analysis rules, and writes the analysis results to the restoration rope while redundant time Remove lineage edges. The consensus node performs consensus processing with other consensus nodes on the portion of the restoration rope that is assumed to be stable and consensus has not been achieved, and consensus is achieved according to the consensus time series of transactions entering the network. Write the part to the consensus slope, and mark transactions for which consensus was achieved as "consensus completed" on the restore rope. To save storage space, transactions, issue relationships and chronological relationships for which consensus has been reached are deleted from the restoration map.

As shown in FIG. 18, in one embodiment, a method for consensus nodes to exchange restoration time series information multiple times and perform consensus processing on local and non-local restoration ropes to form a consensus time series, comprising: , the specific steps are as follows. The consensus node takes the non-consensus and stable restored rope segment and the tail knot of the current consensus rope from the restored rope and randomly sends them to the N consensus nodes. The method by which a consensus node takes non-consensual and stable restored rope segments from the restored rope includes the steps of ensuring that all transactions included in the received incoming rope have been analyzed, and redundant relationships. After deleting , the chronological relationship of transactions that entered the network earlier in the restoration loop will form a single chain, so that new transactions can be inserted into the earlier part of the single chain. A step in which a single chain in this part is a stable time series, and a consensus node has N consensus nodes, and a stable restored rope segment and a consensus rope trailing knot are randomly a step of claiming, wherein after a consensus node receives a consensus-waiting rope segment transmitted from another node, it compares with the corresponding rope segment of its own consensus node for a different time-series relationship thereof, a plurality of the and accepting the result.

Provide a method for randomly generating a node combination for consensus nodes to exchange restored time-series information, specifically, obtain node information, and set an initial value based on the arrival rope, restoration rope and consensus slope data generating a random number based on the initial value; and generating a node combination based on the node information and the random number.

Consensus nodes are a real-time way to remove redundant time-series data in the restoration rope. A specific step is to determine and remove redundant chronological relationship edges in consensus-waiting transactions.

In one embodiment, a method for consensus nodes to build local consensus slopes and store consensus time series information. Specifically, after the consensus node joins the consensus network, triggering the consensus slope initialization module to start synchronization for initialization of the consensus slope; , sending a consensus slope synchronous request for the purpose of obtaining the current latest consensus knot, and other consensus nodes replying with the latest consensus knot; establishing a persistent connection for a period of time to persistently push the latest consensus knot to the node that submitted the request; and C. sending requests to download, aimed at supplementing consensus slopes that have been generated in the consensus network but not stored locally. The consensus rope knotting module obtains a consensus stable restored rope segment and a consensus knot corresponding to the rope segment. Transactions that have already entered the consensus slope are correspondingly marked as "consented" at the own consensus node, one transaction per entry may be marked, or marked in batches. You may

It is the way consensus nodes define, interpret and progress local time. The specific steps are as follows. The consensus node takes the local arrival rope as the internal clock of the consensus node, the increase in the number of knots of the local arrival rope as the basis for time progression, and the knot of the local arrival rope as the internal time scale of the consensus node.

The transaction sequence consensus method according to the present application is essentially that each consensus node records the local time when a group of transactions arrives at the consensus node according to the local time, reaches consensus on the time series of the transaction arrival consensus network, The consensus timeline of transactions arriving at the consensus network is used to define the consensus time of the consensus network, enhancing sequencing capabilities in both consensus time and local time.

Also, the knotting frequency of different consensus nodes may differ, and the rate of progress of the formed local time may also differ.

Timestamps are used to mark the time when an action occurs, and in this application, timestamps are not the year/month/day/hour/minute/second time display that people normally use, It is neither a time representation provided by a time source other than the consensus system, nor a time representation formed on the basis of some incremental quantity within the consensus system.

In one embodiment, a method for a consensus node to verify consensus timestamps from other consensus nodes. The specific steps are as follows. Obtain the provided timestamp containing the consensus time and verification code, search the corresponding knot from the consensus slope of the own consensus node based on the verification code, obtain the knot number and hash value of the knot, and obtain the corresponding consensus Calculate the time and verification code and check if it is equal to the provided timestamp, fail verification if not, pass verification if equal.

In one embodiment, we propose a method to encourage consensus nodes to perform consensus processing conscientiously, wherein an entry consensus node attaches a consensus slope time t0 to a received local transaction T; , obtaining the current consensus slope time t1 and delaying the consensus by Δt=t1−t0; determining a characteristic value x of some relationship with [t] so that the system determines a bonus or penalty for the entry consensus node of transaction T, wherein the degree of bonus and penalty is related to the value of x. do.

In one embodiment, a method for unranked transaction consensus, comprising: a transaction input module inputting a rank unranked transaction to a consensus node; a step of synchronous processing after notting and attaching a consensus time stamp to the transaction knot; says that the forward-backward order between votes does not affect the vote outcome. However, in order to avoid the problem of "double spending", a situation where one votes for two may occur in a competitive voting scene, and it is still necessary to rank transactions of the same voter. Yes, in this case, we can order by using the consensus time of the transactions and remove the double-spending transactions that were written later. Because there is no need to rank, transactions in the same application scene generally have exactly the same fees, and there is no need to falsify the time when consensus nodes timestamp transactions, so the transaction sequence consensus of the present application The consensus time formed by the method is the time generated by the network itself and does not depend on external time sources. Therefore, it is also possible to rank using the consensus timestamp of direct transactions.

In the application scene of transactions that do not need to be ranked, it is common to set the start time and end time so as not to perform synchronization and consensus processing for transactions that arrive at the consensus network after reaching consensus on the transaction. For the application scene of unranked transactions with start and end demands, the consensus node may request the node to start and An option to compare end times can be added to the validation of incoming transactions.

In one embodiment, a method of encouraging consensus nodes to conscientiously perform consensus processing, comprising the steps of: an entry consensus node marking a received local transaction T with a consensus slope time t0; , obtain the current consensus slope time t1 and delay the consensus by Δt=t1−t0, obtain the consensus delay interval [t] of a group of consensus-completed transactions close to transaction T, determining a characteristic value x of some relationship with [t] so that the system determines a bonus or penalty for the entry consensus node of transaction T, wherein the degree of bonus and penalty is related to the value of x. .

In one embodiment, a multi-level access method for a consensus node, for the purpose of improving the loyalty of the consensus node and improving the security of the consensus network, wherein the consensus node accesses the identity state data of the consensus node Including maintaining. The identity states of consensus nodes include seed nodes, official nodes, preparation nodes, breeding nodes, and nodes can temporarily become patrol nodes and referral nodes. Here, seed nodes are generally used to initially configure the network, and can operate stably in the consensus network for a long time, participate in the consensus, and obtain bonuses. Official nodes participate in consensus, can be used as entry consensus nodes, can get bonuses, and bonuses are not locked. A seed node is a special official node. All official nodes are required to commit a certain fee to the system each time, and the fee is used to encourage contributors to the consensus network. Preliminary nodes participate in the consensus, can be used as entry consensus nodes, and can get bonuses, but if the bonuses are locked and the history of participating in the consensus in good faith meets certain identity change conditions, the official nodes You can change to an official node by submitting an identity change application to , and once changed to an official node, the bonuses you have obtained will be unlocked. A locked bonus means that the bonus can be obtained but not executed. If a breeding node participates in consensus and can be used as an entry consensus node, and does not get a bonus and has a history of faithfully participating in consensus and meets certain identity change conditions, it can apply for identity change to the official node. It can be submitted and changed to a ready node. Seed nodes and official nodes can be used as referral nodes. When a node satisfies the identity change conditions, it randomly sends an identity change request to multiple (generally 6 or more) nodes according to a preset rule, and the node that received the request sends the identity change request to the node that submitted the identity change request. is called an referral node that performs The referral node examines the identity change application and returns the examination result to the node that submitted the identity change application (application node for short), and the application node finally passes the examination after totaling all the examination results. and synchronize the aggregate result as one transaction across the network, and the result of executing the transaction is to change or not change the identity of the applying node in the state data. A patrol node acquires a single patrol right when a consensus node satisfies a preset condition, and execution of the patrol right means that the consensus node sends one or more "patrol" to one or more consensus nodes. Transactions” are entered randomly, and patrol transactions are similarly written to the consensus slope by the consensus process. The goal is to use patrol transactions to break the act of reversing the arrival time sequence, and to make the patrol transaction entry consensus node perform corresponding verification according to the patrol transaction's requirements.

Some embodiments of the present application provide a consensus application program applied to a transaction sequence consensus system, including a plurality of transaction input modules, a plurality of state acquisition modules, and an application deployment module, wherein the application deployment module comprises a consensus application It is used to manage the deployment of transaction executors and state data associated with the consensus node. As shown in FIG. 19, the transaction sequence consensus system 1 is composed of a consensus network and multiple consensus applications, where the consensus applications include multiple transaction input modules, multiple state acquisition modules, and application deployment modules. are combined, and the consensus network is composed of consensus nodes. The application deployment module manages available node information for the application, processes deployment resource matching for the application, deploys the application or stops deployment, and includes an available node management submodule and a deployment resource matching submodule. Contains modules.

The present application provides a transaction sequence consensus method and system, in which each node in the consensus network does not trust the external time, only the calculation and communication means in the network form a time mechanism that is not operated by a minority, and is entered into the network. an irreversible consistency consensus on the causal order of a group of transactions, so that the copy states of each data have a consistent change trajectory, where the causal order of the consensus transactions is the It should be the same as the time series that actually entered the network.

The above content is only for explaining the technical concept of the present application, and does not limit the scope of protection of the present application. are within the scope of protection of the claims of the present application.

Claims (15)

obtaining a consensus-waiting transaction and corresponding transaction information, wherein the transaction information includes a transaction number, transaction input module information, transaction entry node information, transaction execution waiting information, and path information for obtaining the consensus-waiting transaction; a step comprising
dividing the consensus-waiting transaction into a local transaction and a non-local transaction based on path information to obtain the consensus-waiting transaction;
verifying, parsing and synchronizing the consensus-pending transaction;
obtaining the arrival time series information of the local transaction at a consensus node and introducing the local transaction into a persistently knotting local arrival rope;
synchronizing the local arrival ropes between different consensus nodes to obtain the arrival time series information of each node after synchronization;
Analyzing the arrival time-series information of each node according to a preset restoration rule to obtain restoration time-series information of two transactions at the node and continuous restoration time-series information of one group of transactions; building a local restoration rope;
exchanging and synchronizing local restoration ropes between different consensus nodes to obtain restoration time series information of each node after synchronization;
performing consensus processing on the restoration time-series information of its own node according to a preset consensus rule to obtain consensus time-series information and constructing a consensus slope including consensus transactions;
obtaining a consensus transaction on a consensus slope based on the analysis on the consensus slope;
updating state data based on the consensus transaction;
A transaction sequence consensus method, characterized by: After updating the state data,
the consensus node obtaining a consensus time based on the state change trajectory of the consensus slope;
The transaction sequence consensus method of claim 1, characterized by: the current time of the consensus time includes a current time value and a verification value of the current time value;
The current time value is the number of currently consensus transactions in the consensus time series information ,
Obtaining the current time of the consensus time as a timestamp;
3. The transaction sequence consensus method of claim 2, wherein: Before obtaining consensus-pending transactions and corresponding transaction information,
obtaining transaction trigger information;
obtaining consensus node information in a consensus network;
determining transaction entry node information for a consensus-waiting transaction based on the transaction trigger information and consensus node information;
The transaction sequence consensus method of claim 1, characterized by: The transaction entry node information assigns entry nodes to the consensus-waiting transaction according to preset allocation rules, wherein the preset allocation rules include designated, polling, random, proximity and load balancing. ,
segmenting the consensus-waiting transaction based on the transaction entry node information;
The transaction sequence consensus method of claim 1, characterized by: The step of verifying and analyzing the consensus-waiting transaction includes:
obtaining a verification result by verifying the consensus-waiting transaction based on preset verification items;
if the verification result is pass, marking the consensus-waiting transaction as a verified consensus-waiting transaction;
analyzing the verified consensus-waiting transaction according to a preset analysis rule to obtain an analysis result;
marking the validated consensus-waiting transaction as a parsed consensus-waiting transaction;
The transaction sequence consensus method of claim 1, characterized by: obtaining the arrival time series information of the local transaction at a consensus node, introducing the local transaction into a persistently knotted local arrival rope, and synchronizing the local arrival rope between different consensus nodes;
initializing a local arrival rope of a consensus node;
persistently creating a knot including a knot number, an introduction knot data and a verification item to extend the local arrival rope;
when the consensus node receives a local transaction, introducing the local transaction into the current knot of the local arrival rope;
synchronizing an unsynchronized portion of the local arrival rope to a consensus node other than the self node when a preset local arrival rope synchronization trigger condition is satisfied;
receiving, validating and synchronizing non-local arrival ropes according to preset arrival rules;
analyzing the local arrival rope and the non-local arrival rope to obtain arrival time series information of each node after synchronization;
The transaction sequence consensus method of claim 1, characterized by: persistently creating knots applied to N pending notters and a scheduler to extend the local arrival rope;
asynchronously sequentially calling available knotters to perform a knotting operation;
generating a knot number, determining a previous timeline knot and pending transactions to create an introductory knot;
The transaction sequence consensus method of claim 7 , characterized by: In the step of persistently creating knots and extending local arrival ropes applied to the N pending knotters, each of the N knotters has a unique number and persistently holds one mutex. competing and said mutex possessing an integer variable a for generating a knot number and a variable b for recording the number of the knotter who obtained the mutex in the most recent competition;
adding 1 to an integer variable a held by the mutex to generate a current knot number after the knotter has obtained the mutex in the competition;
reading the variable b of the mutex to obtain the number of the last notter who obtained the mutex in competition;
setting the variable b to the number of the own knotter and determining whether or not there is a knot transaction waiting to be introduced;
knotting a transaction knot on the local arrival rope if there is a transaction on the introduction pending knot;
immediately releasing the mutex and notting the empty knot if there are no transactions in the knot waiting to be introduced;
The transaction knot contains the own knot number and the number of the previous notter that obtained the mutex in competition, and the empty knot is a created knot with no transaction introduced.
The transaction sequence consensus method of claim 7 , characterized by: The knotting of the local arrival rope is
obtaining a rope segment containing the current knot from the local arrival rope;
statisticizing the ratio of the number of transaction knots in the rope segment in which the current knot is included to the total number of knots in the rope segment in which the current knot is included;
increasing the knotter of the local arrival rope if said ratio exceeds a preset threshold;
reducing the knotter of the local arrival rope if the ratio is below a preset threshold;
The transaction sequence consensus method according to claim 8 or 9 , characterized by: Before synchronizing the local arrival ropes between different consensus nodes,
performing a segmentation process on the local arrival rope to obtain arrival rope segments;
performing a compression process on the arriving rope segment according to preset compression rules;
suspending transaction knots in the arrival rope segment and deleting empty knots for non-marking of the arrival rope segment in the compression process;
The transaction sequence consensus method of claim 7 , characterized by: The step of obtaining restoration time series of two transactions and continuous restoration time series information of a group of transactions,
obtaining relevant transaction information among the arrival time series information;
selecting two transactions from related transactions in the arrival time series information;
determining the restoration time series of the two transactions, and outputting the restoration time series information of the two transactions and the reliability of the restoration time series information of the two transactions;
repeating until a group of transactions obtains a consecutive recovery time series from the arrival time series information;
The transaction sequence consensus method of claim 1, characterized by: The step of exchanging local restoration ropes between different consensus nodes is
obtaining consensus node information, obtaining an arrival rope, a restoration rope and a consensus slope as initial values;
generating a random number based on said initial value;
generating a node combination that exchanges restored time series information based on the consensus node information and the random number;
The transaction sequence consensus method of claim 1, characterized by: The step of performing consensus processing on the restoration time-series information of the own node according to a preset consensus rule, acquiring consensus time-series information, and constructing a consensus slope,
obtaining a non-consensus and stable restored rope segment in the self-node restored rope;
receiving the corresponding unconsensus and stable restored rope segment of the other N consensus nodes;
checking the non-local restoration rope based on the obtained arrival time series information and restoration time series information;
Comparing the received non-consensual and stable restored rope segment with the consensus and stable restored rope segment corresponding to the own node and finding that more than two-thirds of the same portion is the same in different rope segments. suspending a time series relationship;
obtaining consensus time series information and building a consensus slope by repeatedly comparing multiple non-consensus and stable restored rope segments until obtaining the same time series relationship;
The transaction sequence consensus method of claim 1, characterized by: The step of updating state data based on the consensus transaction includes:
analyzing the consensus transactions on the consensus slope based on the consensus time series information;
creating a transaction execution queue based on the consensus transaction;
writing the consensus transaction to the transaction execution queue;
and processing transactions in the consensus transaction execution queue with an executor according to queue processing rules.
The transaction sequence consensus method of claim 1, characterized by:

Images