JP7192196B2 - Network transaction verification method and system based on multiple nodes, and storage medium - Google Patents

Description

TECHNICAL FIELD The present disclosure relates to the field of electronic commerce, and more particularly to a multi-node based network transaction verification method and its corresponding computer system and storage medium.

E-commerce uses Internet technology and basic communication facilities to provide many conveniences for transactions between merchants and users, but the two parties do not directly agree on transactions or transfer funds through the network. sometimes Therefore, both sides of the transaction should directly verify the identity of the other party, as in traditional transaction methods, and whether goods/services and funds are delivered in the manner specified in the agreement during the transaction period. can't In such cases, both trading parties often have to verify their identities through a third-party trading platform to secure the transaction.

Any Merchant or User who intends to trade using the Third Party Trading Platform must first submit proof of identity. In addition, the vendor may have to provide a separate security deposit. Third-party trading platforms must expend reasonable costs to verify the genuine identities of each party participating in the trading, and promptly handle any troubles that may arise during the trading process. Especially for daily large-volume small-value transactions, the background server of the third-party trading platform will simultaneously mass-check the identities of both parties in each transaction, verify the transaction content, and ensure the safety of the funds. We must ensure that the transaction is a true expression of the intent of both parties with the appropriate account. This puts significantly higher demands on the ability to maintain operations and costs of third party platforms.

In large-scale commodity transactions, especially for the first time for both parties, at present, both parties generally adopt traditional offline trading methods to ensure the fairness of both parties.

Also, related public blockchain technologies (eg, Bitcoin, Ethereum, and other cryptocurrencies) do not provide any verification mechanisms or provide data confidentiality. As such, these non-verification techniques require significant additional resources to prevent malicious activity, impacting transaction throughput. Currently, the Bitcoin network has a transaction processing capacity of about 3.3 to 7 transactions per second, and Ethereum about 25 transactions per second.

Therefore, it is necessary to provide a transaction method with high processing efficiency and data confidentiality in order to deal with a large volume of transactions.

In view of the deficiencies existing in the above technical solutions, the present disclosure provides a multi-node based network transaction verification method and corresponding computer system and storage medium so as to improve the problems in the related technical solutions. The above technical solution of the present application can effectively verify the validity of each transaction.
In order to achieve the above object, the present disclosure employs the following technical proposals.

First, the present disclosure provides a network transaction verification method based on multiple nodes, comprising the steps of identifying real identities corresponding to multiple nodes participating in a network transaction; to be verification nodes for verifying network transaction nodes; and initializing a current public transaction recording link list for recording public P2P channel transmission data and network transactions between said plurality of nodes. and generating a data block containing transaction information and a signature by an Istanbul Byzantine Fault Tolerant (IBFT) consensus algorithm and adding it to the current public transaction record linked list. . The node may be a client terminal participating in network transactions. The client terminal stores the true identity information of the actual identity. The true identity information can be stored on the device on which the client terminal is installed.

In the above embodiment of the present disclosure, when the number of verification nodes is 3F+1, initial public P2P channel transmission data among the plurality of nodes and a current public transaction record link list for recording network transactions; The above step of parsing further includes the substep of collecting verification results returned by at least 2F+1 verification nodes; and statistically collecting the collected verification results, and if the number of times the data block passes through verification nodes is F+1 or more. then recording said data block at the end of said current public transaction record link list.

In one or more embodiments of the present disclosure, the data block is write-locked during the process of being verified, causing all nodes to process the data block read-only.

In one or more embodiments of the present disclosure, the data block is generated at regular intervals, and transaction information in the data block is empty if there is currently no new transaction information.

In one or more embodiments of the present disclosure, if the increment of data blocks in the current public transaction record link list is greater than the update threshold, furthermore, 2/3 of the total number of all nodes fail verification. If so, a step is performed in which the verification node is no longer a verification node.

Similarly, in one or more embodiments of the present disclosure, if the increase in data blocks in the current public transaction record linked list is greater than the update threshold, all newly added nodes If ⅔ of the total number of nodes pass verification, a step is performed in which said node is selected as a new verification node.

In one or more embodiments of the present disclosure, the update threshold is 30000 (ie, perform the above verification every time 30000 new data blocks are added).

In one or more embodiments of the present disclosure, between any two or more nodes, further initializing a private transaction data link list based on a private transaction transmission channel and a current public transaction record link list; allowing said two or more nodes to share a private transaction data link over a transaction transmission channel; and transferring data blocks containing transaction information and signatures between said two or more nodes to said private transaction data link list by means of a Raft consensus algorithm. and incrementally updating the private transaction data link list to the two or more nodes through the private transaction transmission channel, wherein the private transaction transmission channel is the public It is different from P2P channel.

Next, the present disclosure further provides a computer system. The computer system includes a memory, a processor, and a computer program stored in the memory and operable on the processor. When said processor executes said program, identifying actual identities corresponding to a plurality of nodes participating in a network transaction; as a verification node for verification; initializing a current public transaction record link list for recording public P2P channel transmission data and network transactions between the plurality of nodes; , generating a data block containing transaction information and a signature and adding it to the current public transaction record linked list.

In an embodiment of the present disclosure, when the number of verification nodes is 3F+1, initializing a current public transaction record link list for recording public P2P channel transmission data and network transactions among the plurality of nodes. The step further includes a substep of collecting verification results returned by at least 2F+1 verification nodes; and statistically collecting the verification results collected, and if the number of verification nodes passed by the data block is equal to or greater than F+1, said recording the data block at the end of the current public transaction record linked list.

In one or more embodiments of the present disclosure, the data block is write-locked during the process of being verified, causing all nodes to process the data block read-only.

In one or more embodiments of the present disclosure, the data block is generated with a certain frequency, and transaction information in the data block is empty if there is currently no new transaction information.

In one or more embodiments of the present disclosure, if the increment of data blocks in the current public transaction record link list is greater than the update threshold, then all ⅔ of the total number of verification nodes pass verification. If not, a step is performed in which the verification node is no longer a verification node.

Similarly, in one or more embodiments of the present disclosure, if the increase in data blocks in the current public transaction record linked list is greater than the update threshold, all newly added nodes A step is performed in which if ⅔ of the total number of validating nodes pass validation, the node is selected as the new validating node.
In one or more embodiments of the present disclosure, the update threshold is 30,000.

In one or more embodiments of the present disclosure, when the processor executes the program, between any two or more nodes, private transaction transmission channel and private transaction data based on current public transaction record link list. initializing a link list and allowing the two or more nodes to share a private transaction data link through the private transaction transmission channel; and exchanging transaction information and signatures between the two or more nodes by a Raft consensus algorithm. and incrementally updating the private transaction data link list to the two or more nodes through the private transaction transmission channel, wherein the A private transaction transmission channel is different from the public P2P channel.

Finally, the application discloses a storage medium on which a computer program is stored. The computer program, in operation, for identifying actual identities corresponding to a plurality of nodes participating in a network transaction, and selecting some nodes from among the plurality of nodes to verify network transaction nodes. and initializing a current public transaction record link list for recording public P2P channel transmission data and network transactions between the plurality of nodes, and transaction information and signatures according to the IBFT consensus algorithm. and adding to said current public transaction record linked list.

In an embodiment of the present disclosure, when the number of verification nodes is 3F+1, initializing a current public transaction record link list for recording public P2P channel transmission data and network transactions among the plurality of nodes. The step further includes the substep of collecting verification results returned by at least 2F+1 verification nodes; and statistically collecting the verification results collected, and if the number of verification nodes passed by the data block is F+1 or more, , recording said data block at the end of said current public transaction record linked list.

In one or more embodiments of the present disclosure, the data block is write-locked during the process of being verified, causing all nodes to process the data block read-only.

In one or more embodiments of the present disclosure, the data block is generated at regular intervals, and transaction information in the data block is empty if there is currently no new transaction information.

In one or more embodiments of the present disclosure, if the increment of data blocks in the current public transaction record link list is greater than the update threshold, furthermore, 2/3 of the total number of all nodes fail verification. If so, a step is performed in which the verification node is no longer a verification node.

Similarly, in one or more embodiments of the present disclosure, if the increase in data blocks in the current public transaction record linked list is greater than the update threshold, all newly added nodes If ⅔ of the total number of nodes pass verification, a step is performed in which said node is selected as a new verification node.

In one or more embodiments of the present disclosure, the update threshold is 30,000.

In one or more embodiments of the present disclosure, the computer program, in operation, further executes private transaction transmission between any two or more nodes and based on a private transaction transmission channel and a current public transaction record link list. initializing a data link list and allowing the two or more nodes to share a private transaction data link through the private transaction transmission channel; and transferring transaction information and signatures between the two or more nodes by a Raft consensus algorithm. and incrementally updating the private transaction data linked list to the two or more nodes through the private transaction transmission channel. The private transaction transmission channel is set up differently than the public P2P channel.

Beneficial effects of the present disclosure are as follows. If the same transaction is verified by multiple randomly selected nodes, and the number of transaction records is large at the same time, some nodes will go down or some nodes will be dominated by malicious trading participants. It ensures that even if a transaction is arbitrarily confirmed by a client, the corresponding transaction is still properly confirmed. Since the true identities of all trading participants are identified, this scheme can track the actual participants in each trade to ensure the authenticity of the trade. Since different consensus algorithms (IBFT and Raft) are used in public and private transactions respectively, the disclosed scheme can avoid the situation of transaction divergence. On the contrary, public blockchain transaction schemes using Proof of Work (PoW) often cause forks (sometimes hard forks) and waste resources.

FIG. 1 is a flowchart of a network transaction verification method based on multiple nodes, according to an embodiment of the present disclosure. FIG. 2 is a schematic diagram of a network composed of multiple nodes for network transaction verification of FIG. FIG. 3 is a schematic diagram showing the data block and the data structure of the current public transaction record linked list. FIG. 4 is a flowchart of a sub-scheme of initializing a current public transaction record link list for recording public P2P channel transmission data and network transactions between said plurality of nodes in FIG. FIG. 5 is a flowchart of validating transactions between any two or more nodes, according to an embodiment of the disclosure. FIG. 6 is a block diagram of a network transaction verification system based on multiple nodes, according to an embodiment of the present disclosure.

The following provides a clear and complete description of the concept, specific structure and technical effects of the present invention with reference to the embodiments and drawings, so that the objects, means and effects of the present invention can be fully understood. let them It should be noted that, unless contradictory, the embodiments of the present application and the features in the embodiments can be combined with each other. The same reference numerals used throughout the drawings indicate the same or similar parts.

Currently, in transactions involving large-scale products, both parties must spend considerable costs to verify information such as the identity, qualifications, and past transaction records of the other party in order to ensure the reliability of the transaction. There are many. However, the reliability of a trading object is generally based on the trading object's past transaction records and commercial credit ratings made on behalf of the trading object by other participants in the trading object's trading history. All of this information serves as a reference factor for both sides of the transaction to assess each other's commercial reputation.

Embodiments of the present disclosure utilize these factors and use them as indicators for measuring transaction security, thereby providing transaction security checks for electronic business to both sides of the transaction. In the application of this disclosure, the identities of both parties participating in the transaction are checked on various terminals (laptops, desktops, smartphones, tablet computers, etc.) by identity verification methods commonly used in the field. , is bound to the terminal. At this time, the corresponding terminal becomes one of a plurality of nodes used for validating network transactions. Specifically, refer to FIG. 1, which is a schematic flowchart of a network transaction verification method based on multiple nodes in an embodiment of the present disclosure, which method comprises multiple nodes participating in a network transaction; selecting some nodes from among the plurality of nodes to be verification nodes for verifying network transaction nodes; public P2P channel transmission between the plurality of nodes; Initializing a current public transaction record link list for recording data and network transactions, generating data blocks containing transaction information and signatures according to the IBFT consensus algorithm and adding them to the current public transaction record link list. Including.

The IBFT consensus algorithm utilizes the Proof of Authority (PoA) produced by the selected and actual verified verification nodes as the commercial credit rating of each participant in the transaction. Proof of authority involves validating new transactions using a set of validating nodes and, through consensus of multiple validating nodes, creating corresponding data blocks in new network transactions and adding them to the transaction record. According to the IBFT consensus algorithm, each verification node is randomly selected and can be dynamically changed in subsequent multiple transaction verification processes. Each time a new network transaction needs to be validated, one of the validating nodes is randomly selected as the Proposer. The randomly selected proposing node generates a corresponding data block based on the new network transaction and hands it over to the verifying nodes for verification. These verification nodes and other nodes are formed by the network structure shown in FIG. According to one or more embodiments of the invention, each data block is verified through a different set of verification nodes, and after consensus is reached, it is recorded as a digital signature on the data block. Here, the verification node verifies each transaction to determine if the data block can be added to the current public transaction record linked list. General nodes have a complete copy of the current public transaction record link list, and by transmitting data blocks containing transaction information between each node and verification results of the data blocks between each node, each It allows nodes to respond quickly to newly generated data blocks. After the data block passes verification and is added to the current public transaction record link list, or fails to pass verification and is discarded, one is randomly selected from all verification nodes, or the same proposal node. can be used to repeat the above process to validate the next network transaction. If the data block does not pass verification, the proposing node for that round of verification is replaced and a new proposing node is randomly selected. A data block can be implemented with the data structure shown in FIG. In some embodiments of the present application, these data blocks may be linked in a linked list fashion as shown to form a current public transaction record linked list. That is, the data head of each data block contains the digital signature of the previous data block (data block 1 contains the linked list head) to smoothly verify each data block of the current public transaction record linked list. It can quickly determine whether the current public transaction record link list has encountered malicious corruption, and quickly return to a normal state by deleting invalid data blocks. You can rollback. Those skilled in the art can choose other suitable data structures to record each data block and current public transaction record link list, thereby whether said current public transaction record link list encounters malicious corruption. can be easily verified, and if the current public transaction record linked list encounters malicious corruption, it can be quickly rolled back to a sane state. No further limitation is made in this regard in this disclosure. Similarly, the transaction verification scheme can be a verification scheme commonly used in the field (e.g., verifying whether the digital signature in the data block is correct) and self-defined rules (e.g., if the amount of each transaction is whether the upper limit has been exceeded, the past trading records of the relevant trading parties and whether the method of trading is legal), and no further limitation is made in this disclosure. A person skilled in the art can select an appropriate verification scheme according to the actual situation. In one or more embodiments of the present application, the current public transaction record link list can be recorded in a data center, and each data block that passes verification is linked to the current public transaction record stored in the data center. After being added to the linked list, it can be retrieved by any node (including verified nodes and non-verified general nodes) at any time. Correspondingly, alternatively, in other embodiments of the present application, each node locally stores a copy of the current public transaction record link list and, after a data block passes verification, copies it to a local distributed storage of the current public transaction record link list can be implemented to improve the robustness and security of the system. According to one or more embodiments of the present invention, to ensure that a data block is added to the record link list only one at a time, after the data block has reached consensus of multiple validating nodes: Stop selecting new data blocks while the data block has not yet been added to the record link list.

The purpose of the IBFT consensus algorithm is to establish trust among the nodes in an untrusted network environment. Therefore, in the above-mentioned network transaction verification method using the IBFT consensus algorithm, current users of some verification nodes maliciously collude and make incorrect judgments on transaction verification, thus reducing normal transactions to the maximum. Even if it destroys the limit, it can be dealt with. Even in the worst-case scenario, the IBFT consensus algorithm still ensures that each transaction recorded in the current public transaction record link list passes the scrutiny of most “loyalty” verification nodes, all of which are in the network. , can become part of a permanent record, track the verification results produced by each verification node over time, or even be the basis for dynamically adjusting verification nodes during subsequent multiple transaction verification processes. Therefore, the proof of authority verification method can verify the safety of transactions more quickly than the verification method that adopts proof of work in conventional blockchain technology, and can meet the actual usage demand. On the other hand, the proof-of-authority verification scheme retains the advantage of the proof-of-work verification scheme that it can be applied to untrusted network environments.

To further deal with the explosive growth of transaction volume during a particular period, referring to the sub-flowchart shown in FIG. 4, in one or more embodiments of the present application, when the number of verification nodes is 3F+1: The above step of initializing a current public transaction recording link list for recording public P2P channel transmission data and network transactions among the plurality of nodes further includes collecting verification results returned by at least 2F+1 verification nodes. and a substep of counting the collected verification results and recording the data block at the end of the current public transaction record link list if the number of times the data block has passed verification nodes is F+1 or more. including. where F is the number of error/malicious nodes acceptable to the network.

In fact, the IBFT consensus algorithm predicts that “loyal” validating nodes in the network at any given time will have similar validation results, and the current number of validating nodes with malicious users is 1/3 of the total number of nodes. I'm assuming it won't go over. So, if we receive returned verification results from more than 2F+1 verification nodes, even in the worst case (i.e. if we receive verification results issued by all malicious verification nodes), we have enough "loyalty" verifier nodes have already received the correct verification result for that round of the transaction, so they do not make erroneous decisions about the transaction's safety. In addition, each "loyalty" verification node will all produce similar verification results, and the potential danger emerges that the "rebellion" intermediate node in the traditional Byzantine Generals Problem modifies the transmitted information. To ensure that it does not, the data block is write-locked during the verification process so that all nodes process the data block read-only. At this time, the data block will not be tampered with during the transmission process, even if the passing node is currently occupied by a malicious user.

In one or more embodiments of the present application, the data blocks are generated at regular intervals to ensure system security. If there is currently no new transaction information, the transaction information in said data block is empty. In fact, the length of the current public transaction record link list is steadily increasing, and the private key used for signing at each verification node depends on the current length of the public transaction record link list. Since it is updated periodically, a malicious user with some ulterior motive to collect signatures in data blocks will need to update the private key in sync with the verification node. This improves the safety of the system itself.

One or more embodiments of the present application to quickly discover and remove verification nodes with malicious intent by current users, which account for 1/3 of the total number of nodes assumed by the IBFT consensus algorithm , if the increase in the number of data blocks in the current public transaction record link list is greater than the update threshold, further verifying nodes verify each other, and one verifying node reaches 2/3 of the total number of verifying nodes. , the verification node is deleted and is no longer a verification node. Correspondingly, to replenish deleted verification nodes, in one or more embodiments of the present application, if the increase in data blocks in the current public transaction record link list is greater than the update threshold: further performs the step of selecting the newly added node as a new validating node if the newly added node passes 2/3 validation of the total number of validating nodes. Specifically, in some embodiments of the present disclosure, every time there are 30000 data blocks (including data blocks with empty transaction information) in the current public transaction record link list, Updates can be performed. In one or more embodiments of the present application, the verification of the verification node itself may be based on the accuracy of the verification node's determination of data blocks in the current public transaction record linked list within the period of time described above. can. Specifically, the verification node whose decision accuracy is the last 1/3 is deleted. In one or more embodiments of the present invention, this refers to maintaining a verified node if the node has not verified against the verified node.

Since data blocks in the current public transaction record linked list are examined by all nodes, a dedicated private transaction transmission channel is established between mutually trusting trading parties to verify transaction security. Specifically, referring to the sub-flowchart shown in FIG. 5, between any two or more nodes that have high trust between each other, a private transaction transmission channel (e.g., any two or more nodes specify the port of the private transaction transmission channel between) and the private transaction data link list based on the current public transaction record link list (e.g., create the private transaction data link list link head based on the current public transaction record link list) and allowing the two or more nodes to share a private transaction data link over the private transaction transmission channel; and transferring data blocks containing transaction information and signatures between the two or more nodes by a Raft consensus algorithm. to the end of the private transaction data link list, and incrementally updating the private transaction data link list to the two or more nodes through the private transaction transmission channel, wherein , the private transaction transmission channel is different from the public P2P channel. Between any two or more nodes, data can only be transmitted over the private transaction transmission channel. In addition, the current public transaction record link list and private transaction transmission channel are separate from each other. There is no interoperability or intersection between them. Thus, the benefits of transmitting transactions over a private transaction transmission channel include at least not broadcasting transaction information across the network. Each private transaction transmission channel can be thought of as a distributed Raft network.

Operating a private transaction transmission channel allows network participants (who may even be competitors in the same industry) to choose other participants for private transactions, even if they cannot fully trust each other. , by transmitting data blocks only through the private transaction transmission channel, it means that only each party using the private transaction transmission channel can see the transaction data between them. This provides an option for higher transaction privacy. From the above discussion, it can be concluded that the parties conducting transactions over the private transaction transmission channel have a relatively high degree of trust with each other. to complete the verification of the transaction. That is, the Raft consensus algorithm is used to complete verification instead of the IBFT consensus algorithm. In this case, each node has a countdown timer (Election Timeout) for the current Raft network. In an embodiment of the present application, the countdown timer time is randomly between 150ms and 300ms. In other embodiments of the application, said time is 160ms, 180ms, 200ms, 220ms, 250ms or 280ms. During operation of the Raft network, each node performs at least two activities: Leader Election and Log Replication. At the beginning of the leader election activity, all nodes in the Raft network are initialized to the Follower state. When the countdown of a node ends (Timeout), the state of this node becomes Candidate state and an election is raised. It sends a Request Vote to some other node. If at least half of the other nodes return success, the state of this node is changed from Candidate to Leader, and Heartbeat Messages are sent to all Candidate state nodes at short intervals. to keep the current state of all nodes. A node in candidate state resets its countdown timer when it receives the heartbeat message of a node in leader state. When a client terminal sends a request to a node in leader state, the associated data is written to the local log by the node in leader state. The node in leader state then sends requests to other nodes in follower state to update their local logs. These data are written to local logs by other follower state nodes and send success messages back to the leader state node. As long as the node in leader state receives reply success messages from a majority of the nodes, the relevant data is set to confirmed state in the local log on the node in leader state. At this time, the leader state node will also send confirmation messages to other follower state nodes, and the setting of the corresponding data in the local log of the follower state node will also be changed to confirmed state, thereby A full log replication process is completed.

At the same time, it can increase transaction speed to thousands per second to meet daily transaction demands. For example, embodiments of the present invention are capable of processing at least 1400 transactions per second. In other embodiments, at least 1650 transactions per second can be processed. In addition, due to the robustness of the Raft consensus algorithm itself, if more than half of the two or more nodes participating in the transaction can operate normally, the transaction between each party can be verified as usual, And the private transaction data-linked list can be kept consistent on each node by operations such as rollback after the corresponding node comes back up. In other words, the Raft consensus algorithm is based on a network of trust, and the number of erroneous/malicious nodes allowed in the corresponding Raft network is less than 1/2. In one or more embodiments of the present invention, if a majority of nodes expire, the private transaction is suspended and the corresponding private transaction's data blocks are also not added to the private transaction's data block linked list. For example, if two nodes execute a private transaction and one of them expires or goes offline, the transaction will be aborted. In one or more embodiments of the present invention, a node that goes offline rejoins the original private transaction shortly thereafter and updates the data link list that was lost while offline to the rejoined node. be able to.

The high throughput, security and privacy features of the present invention can effectively manage or process transactions between multiple business organizations. This technical solution can be used to manage or process transactions between multiple commercial organizations, between multiple commercial organizations and consumers, and/or between multiple consumers. In an embodiment of the present invention, the above technical solution can be applied to the management of consumption incentive plans. Commercial organizations and consumers are multiple nodes of network transactions. Consumption records, merchant organization-specific bonus points, generality points, etc. are the transaction information and signatures in the data block.

Referring to the block diagram of a network transaction verification system based on multiple nodes shown in FIG. hardware, or a combination of computer software and electronic hardware. Whether these functions are ultimately implemented in hardware or software depends on the particular application of the technical solution and the constraints of the setup. Skilled artisans may implement the described functionality using different methods for each particular application, but such implementations should not be viewed as exceeding the scope of the present invention.

In the embodiments in which the invention is provided, it should be understood that the provided apparatus and method can be implemented by other means. For example, the above system embodiments are only schematic, for example, the division of modules and units is only the division of logical functions, and there may be other division schemes in actual implementation. For example, multiple units or elements may be combined, integrated into another system, or some features may be ignored or not performed. Also, any coupling or direct coupling or communication connection between one another shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, electrical, mechanical or otherwise. may be

The units described as separate members above may or may not be physically separated, and the members denoted as units may or may not be physical units, and may or may not be in one place. may be distributed over multiple network units. The purpose of the scheme of this embodiment can be achieved by selecting some or all units among them according to the actual demand.

Also, each functional unit in each embodiment of the present invention may be integrated within one processing unit, each unit may physically exist alone, or two or more units may be combined into one unit. May be integrated within a unit. The integrated units may be implemented using hardware forms or using software functional units.

When the integrated units are implemented in the form of software functional units and sold or used as independent products, they can be stored in one computer readable storage medium. Based on this understanding, all or part of the flow in the method of implementing the above embodiments in the present invention can also be completed by instructing relevant hardware by a computer program. can be stored in a computer-readable storage medium, and the computer program, when executed by a processor, can implement the steps of each of the above method embodiments. Here, said computer program comprises computer program code, which may be in source code form, object code form, executable file or some intermediate form, or the like. The computer readable medium is any entity or device capable of carrying the computer program code, recording medium, USB flash memory, portable hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM, Read-Only Memory). ), Random Access Memory (RAM), electrical carrier wave signals, telegraph signals, software distribution media, and the like. It should be noted that the content contained on the computer-readable medium may be scaled up or down as appropriate based on the requirements of legislation and patent practice within a jurisdiction. Under statutory and patent practice, a computer-readable medium does not include being an electrical carrier wave signal or a telegraphic signal.

The above examples are intended to illustrate the technical solution of the present invention, but not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art can still modify the technical solutions described in the above embodiments, or find one of the technical features therein. Parts can be replaced equally, and their modifications or replacements do not deviate from the spirit and scope of the technical solution of each embodiment of the present invention for the essence of the corresponding technical solution, and all are protected by the present invention. should be understood to be included within the scope.

Claims (9)

A network transaction verification method based on multiple nodes, comprising:
a computer system identifying actual identities corresponding to multiple nodes participating in a network transaction;
a step in which the computer system selects some nodes from the plurality of nodes to be verification nodes for verifying network transaction nodes;
the computer system initializing a current public transaction recording link list for recording public P2P channel transmission data and network transactions between the plurality of nodes;
said computer system generating a data block containing transaction information and a signature according to an IBFT consensus algorithm and adding it to said current public transaction record linked list;
An updating step of updating the validating node if the increment of data blocks in the current public transaction record linked list is greater than an update threshold, comprising the plurality of nodes validating the validating node. including steps and
If the number of verification nodes is 3F+1, the step of initializing a current public transaction recording link list for recording public P2P channel transmission data and network transactions between the plurality of nodes further comprises:
a substep of collecting verification results returned by at least 2F+1 verification nodes;
statistically collecting verification results, and recording the data block at the end of the current public transaction record linked list if the number of times the data block passed verification nodes is F+1 or more. characterized by
Network transaction verification method. 2. The network transaction verification of claim 1, wherein the data block is generated with a certain frequency, and transaction information in the data block is empty if there is no new transaction information at present. Method. The updating step further comprises:
If a verifier node to be verified fails to pass ⅔ verification of the total number of verifier nodes, the verified verifier node ceases to be a verifier node,
The network transaction verification method of claim 1. The updating step further comprises:
selecting the newly added verification node as the new verification node if the newly added verification node passes ⅔ verification of the total number of verification nodes;
The network transaction verification method of claim 1. The network transaction verification method according to claim 1, characterized in that said update threshold is 30,000. between any two or more nodes, and
initializing a private transaction transmission channel and a private transaction data link list based on a current public transaction record link list, and allowing the two or more nodes to share the private transaction data link through the private transaction transmission channel;
appending data blocks containing transaction information and signatures between the two or more nodes to the end of the private transaction data linked list according to the Raft consensus algorithm;
incrementally updating the private transaction data link list to the two or more nodes over the private transaction transmission channel;
wherein the private transaction transmission channel is different from the public P2P channel;
The network transaction verification method of claim 1. 2. The network transaction verification of claim 1, wherein the data block is write-locked during the process of being verified so that all nodes process the data block read-only. Method. In a computer system comprising a memory, a processor, and a computer program stored in the memory and operable on the processor, the processor, in executing the computer program, a method according to any one of the preceding claims 1-7 . A computer system characterized by realizing A storage medium on which a computer program is stored, which in operation is arranged to carry out the method according to any one of the preceding claims.

Images