CN113348656A - Network transaction verification method based on multiple nodes, system and storage medium thereof - Google Patents
Network transaction verification method based on multiple nodes, system and storage medium thereof Download PDFInfo
- Publication number
- CN113348656A CN113348656A CN202080011112.0A CN202080011112A CN113348656A CN 113348656 A CN113348656 A CN 113348656A CN 202080011112 A CN202080011112 A CN 202080011112A CN 113348656 A CN113348656 A CN 113348656A
- Authority
- CN
- China
- Prior art keywords
- transaction
- nodes
- verification
- linked list
- network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000012795 verification Methods 0.000 title claims abstract description 134
- 238000000034 method Methods 0.000 title claims abstract description 50
- 230000005540 biological transmission Effects 0.000 claims abstract description 26
- 230000008569 process Effects 0.000 claims description 17
- 238000004590 computer program Methods 0.000 claims description 13
- 238000010586 diagram Methods 0.000 description 6
- 230000000694 effects Effects 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 238000011156 evaluation Methods 0.000 description 3
- 238000013475 authorization Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 2
- 230000010076 replication Effects 0.000 description 2
- RWSOTUBLDIXVET-UHFFFAOYSA-N Dihydrogen sulfide Chemical compound S RWSOTUBLDIXVET-UHFFFAOYSA-N 0.000 description 1
- 238000012550 audit Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000003116 impacting effect Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 239000000047 product Substances 0.000 description 1
- 238000012797 qualification Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
A multi-node based network transaction verification method, a network transaction verification system and a storage medium, the method comprising the steps of: identifying actual identities corresponding to a plurality of nodes participating in a network transaction (S100); selecting a part of the nodes from the plurality of nodes as authentication nodes for authenticating the network transaction nodes (S200); initializing a common P2P channel transmission data among the plurality of nodes and a current common transaction record linked list for recording network transactions (S300); generating and adding a data block containing transaction information and a signature to the current common transaction record linked list through an IBFT consensus algorithm (S400).
Description
The present disclosure relates to the field of electronic commerce, and in particular, to a multi-node based network transaction verification method, and a computer system and a storage medium thereof.
While electronic commerce provides a great deal of convenience for transactions between merchants and users through internet technology and basic communication devices, both parties to a transaction may directly enter into a transaction agreement and a transfer of funds over a network. Thus, the parties to the transaction cannot confirm that the identity of the other party can be directly confirmed, as in conventional transaction methods, and whether goods/services and funds are delivered in the manner specified by the agreement during the transaction. At this time, the two parties to the transaction often need to verify the identities of the two parties through a third party transaction platform and guarantee the transaction.
When a merchant or a user uses a third-party transaction platform to carry out transaction, identification is required to be provided firstly. At the same time, the merchant may either need to provide additional wagers. The third party transaction platform needs to spend corresponding cost to verify the true identity of each party participating in the transaction and timely handle disputes which may occur in the transaction process. Particularly for daily massive small-amount transactions, a background server of a third-party transaction platform needs to verify the identities of both parties in each transaction, confirm the contents of the transactions and ensure the safety of funds, so that the transactions are represented by the real meanings of both parties of the transactions with corresponding account numbers. This puts high demands on the operation and maintenance capability and cost of the third party platform.
For the bulk commodity transaction, especially the first transaction of both parties, both parties of the transaction generally adopt the traditional offline transaction mode at present to ensure the fairness of both parties of the transaction.
Moreover, data security is not provided because the related public blockchain technologies (e.g., bitcoin, etherhouse (Ethereum), and other crypto currency) do not have any authentication mechanism; these non-authentication techniques require a significant amount of additional resources to prevent malicious behavior, thereby impacting transaction processing capabilities. Currently, the transaction processing capacity of bitcoin networks is on the order of 3.3 to 7 transactions per second, with an ethernet house of about 25 transactions per second.
Therefore, there is a need to provide a transaction method with high processing efficiency and data security to cope with mass transactions.
Disclosure of Invention
In view of the above-mentioned drawbacks, the present disclosure provides a multi-node-based network transaction verification method, and a corresponding computer system and storage medium thereof, to alleviate the problems in the related art. The technical scheme of the application can obtain the effect of efficiently verifying the validity of each transaction.
In order to achieve the above object, the present disclosure adopts the following technical solutions.
Firstly, the present disclosure provides a multi-node based network transaction verification method, which includes the following steps: identifying actual identities corresponding to a plurality of nodes participating in network transactions; selecting a part of the nodes from the plurality of nodes as verification nodes for verifying the network transaction nodes; initializing a common P2P channel transmission data among the plurality of nodes and a current common transaction record linked list for recording network transactions; and generating and adding a data block containing transaction information and a signature to the current public transaction record linked list by an IBFT (International Byzantine factory Tolerant, Istanbulbaxatrint Fault-Tolerant) consensus algorithm. Wherein the node may participate in a client of a network transaction. The client stores the real identity information of the actual identity. The real identity information may be stored on the device on which the client is installed.
In the above embodiment of the present disclosure, when the number of the verification nodes is 3F +1, the step of initializing the common P2P channel between the plurality of nodes to transmit data and to record the current common transaction record linked list for network transaction further includes the following sub-steps: collecting verification results returned by at least 2F +1 verification nodes; and counting the collected verification results, and recording the data blocks to the tail of the current public transaction record linked list when the number of the data blocks passing through the verification nodes is greater than or equal to F + 1.
In one or more embodiments of the present disclosure, the data block is write-locked in the process of being verified, such that all nodes process the data block in a read-only manner.
In one or more embodiments of the present disclosure, the data block is generated at a constant frequency, wherein when there is no new transaction information currently, the transaction information within the data block is empty.
In one or more embodiments of the present disclosure, after the increment of the data blocks in the current common transaction record linked list is greater than the update threshold, the following steps are further performed: when the total number of all nodes 2/3 cannot be verified, the verifying node no longer acts as a verifying node.
Similarly, in one or more embodiments of the present disclosure, after the increment of the data blocks in the current common transaction record linked list is greater than the update threshold, the following steps are further performed: when the newly added node passes the verification of the total number of all nodes 2/3, the node is selected as the new verification node.
In one or more embodiments of the present disclosure, the update threshold is 30000 (i.e., the verification is performed every 30000 new data blocks).
In one or more embodiments of the present disclosure, the following steps may also be performed between any two or more nodes: initializing a private transaction transmission channel and a private transaction data linked list based on a current public transaction record linked list, and sharing the private transaction data link to the two or more nodes through the private transaction transmission channel; adding a data block containing transaction information and a signature between the two or more nodes to the tail of the private transaction data linked list through a Raft consensus algorithm; incrementally updating the private transaction data link table to the two or more nodes via the private transaction transport channel; wherein the private transaction transport channel is different from the public P2P channel.
Secondly, this disclosure also provides a computer system. The computer system includes a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, the following steps are executed: identifying actual identities corresponding to a plurality of nodes participating in network transactions; selecting a part of the nodes from the plurality of nodes as verification nodes for verifying the network transaction nodes; initializing a common P2P channel transmission data among the plurality of nodes and a current common transaction record linked list for recording network transactions; and generating and adding a data block containing transaction information and a signature to the current common transaction record linked list through an IBFT consensus algorithm.
In an embodiment of the present disclosure, when the number of the verification nodes is 3F +1, the step of initializing the common P2P channel transmission data among the plurality of nodes and the current common transaction record linked list for recording the network transaction further includes the following sub-steps: collecting verification results returned by at least 2F +1 verification nodes; and counting the collected verification results, and recording the data blocks to the tail of the current public transaction record linked list when the number of the data blocks passing through the verification nodes is greater than or equal to F + 1.
In one or more embodiments of the present disclosure, the data block is write-locked in the process of being verified, such that all nodes process the data block in a read-only manner.
In one or more embodiments of the present disclosure, the data block is generated at a constant frequency, wherein when there is no new transaction information currently, the transaction information within the data block is empty.
In one or more embodiments of the present disclosure, after the increment of the data blocks in the current common transaction record linked list is greater than the update threshold, the following steps are further performed: when the total number of all the verification nodes 2/3 cannot be verified, the verification node no longer acts as a verification node.
Similarly, in one or more embodiments of the present disclosure, after the increment of the data blocks in the current common transaction record linked list is greater than the update threshold, the following steps are further performed: when the newly added node passes the verification of the total number of all verification nodes 2/3, the node is selected as the new verification node.
In one or more embodiments of the present disclosure, the update threshold is 30000.
In one or more embodiments of the present disclosure, when the processor executes the program, the following steps may be further performed between any two or more nodes: initializing a private transaction transmission channel and a private transaction data linked list based on a current public transaction record linked list, and sharing the private transaction data link to the two or more nodes through the private transaction transmission channel; adding a data block containing transaction information and a signature between the two or more nodes to the tail of the private transaction data linked list through a Raft consensus algorithm; incrementally updating the private transaction data link table to the two or more nodes via the private transaction transport channel; wherein the private transaction transport channel is different from the public P2P channel.
Finally, the present application discloses a storage medium, wherein the storage medium has stored therein a computer program. The computer program is arranged to perform the following steps when executed: identifying actual identities corresponding to a plurality of nodes participating in network transactions; selecting a part of the nodes from the plurality of nodes as verification nodes for verifying the network transaction nodes; initializing a common P2P channel transmission data among the plurality of nodes and a current common transaction record linked list for recording network transactions; and generating and adding a data block containing transaction information and a signature to the current common transaction record linked list through an IBFT consensus algorithm.
In an embodiment of the present disclosure, when the number of the verification nodes is 3F +1, the step of initializing the common P2P channel transmission data among the plurality of nodes and the current common transaction record linked list for recording the network transaction further includes the following sub-steps: collecting verification results returned by at least 2F +1 verification nodes; and counting the collected verification results, and recording the data blocks to the tail of the current public transaction record linked list when the number of the data blocks passing through the verification nodes is greater than or equal to F + 1.
In one or more embodiments of the present disclosure, the data block is write-locked in the process of being verified, such that all nodes process the data block in a read-only manner.
In one or more embodiments of the present disclosure, the data block is generated at a constant frequency, wherein when there is no new transaction information currently, the transaction information within the data block is empty.
In one or more embodiments of the present disclosure, after the increment of the data blocks in the current common transaction record linked list is greater than the update threshold, the following steps are further performed: when the total number of all nodes 2/3 cannot be verified, the verifying node no longer acts as a verifying node.
Similarly, in one or more embodiments of the present disclosure, after the increment of the data blocks in the current common transaction record linked list is greater than the update threshold, the following steps are further performed: when the newly added node passes the verification of the total number of all nodes 2/3, the node is selected as the new verification node.
In one or more embodiments of the present disclosure, the update threshold is 30000.
In one or more embodiments of the disclosure, the computer program is arranged such that when run, the following steps may also be performed between any two or more nodes: initializing a private transaction transmission channel and a private transaction data linked list based on a current public transaction record linked list, and sharing the private transaction data link to the two or more nodes through the private transaction transmission channel; adding a data block containing transaction information and a signature between the two or more nodes to the tail of the private transaction data linked list through a Raft consensus algorithm; incrementally updating the private transaction data link table to the two or more nodes via the private transaction transport channel; wherein the private transaction transport channel is different from the public P2P channel.
The beneficial effect of this disclosure does: the randomly selected multiple nodes verify the same transaction, so that the corresponding transaction can be properly verified even if some nodes are down or controlled by malicious transaction participants to randomly verify the transaction under the condition that the transaction records are high in quantity and are concurrent. Because the true identity of all transaction participants is identified, the present solution is able to track the actual participants of each transaction, thereby ensuring the reliability of the transaction. The disclosed scheme avoids transaction forking situations because different consensus algorithms (IBFT and Raft) are used in public and private transactions, respectively. In contrast, common blockchain transaction schemes using Proof of Work (PoW) often suffer from forking (even hard forking) and waste resources.
FIG. 1 is a flow chart illustrating a multi-node based network transaction verification method according to an embodiment of the present disclosure;
FIG. 2 is a schematic diagram of a network formed by a plurality of nodes for network transaction verification in FIG. 1;
FIG. 3 is a diagram illustrating data structures of a data block and a current public transaction record linked list;
FIG. 4 is a flowchart illustrating a sub-method of the step of initializing a common P2P channel between the plurality of nodes to transmit data and a current common transaction record linked list for recording network transactions of FIG. 1;
FIG. 5 is a flow diagram illustrating the verification of a transaction between any two or more nodes according to an embodiment of the disclosure;
FIG. 6 is a block diagram of a multi-node based network transaction verification system according to an embodiment of the present disclosure.
The conception, the specific structure and the technical effects of the present invention will be clearly and completely described in conjunction with the embodiments and the accompanying drawings to fully understand the objects, the schemes and the effects of the present invention. It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict. The same reference numbers will be used throughout the drawings to refer to the same or like parts.
In the current transaction related to bulk commodities, both transaction parties often need to pay considerable cost to verify the identity, qualification, historical transaction records and other information of the other party so as to ensure the reliability of the transaction. However, the reliability of the transaction object is typically based on past transaction records of the transaction object; and the business credit evaluations made by other participants for the transaction object in the transaction history. These information are all reference factors for business credit evaluation of each other by the two parties of the transaction.
The embodiments of the present disclosure utilize these factors and use them as an index for measuring transaction security, thereby providing an e-commerce transaction security check for both parties to the transaction. In the application of the present disclosure, the identities of two or more parties participating in a transaction can be verified and bound to various terminals (e.g., notebook computer, desktop computer, smart phone, tablet computer, etc.) by means of common authentication methods in the field. At this time, the corresponding terminal will become one of a plurality of nodes for network transaction verification. Specifically, referring to fig. 1, a schematic flow chart of a multi-node based network transaction verification method according to an embodiment of the disclosure is shown, the method including: identifying actual identities corresponding to a plurality of nodes participating in network transactions; selecting a part of the nodes from the plurality of nodes as verification nodes for verifying the network transaction nodes; initializing a common P2P channel transmission data among the plurality of nodes and a current common transaction record linked list for recording network transactions; and generating and adding a data block containing transaction information and a signature to the current common transaction record linked list through an IBFT consensus algorithm.
The IBFT consensus algorithm utilizes Proof of rights (PoA) made by authentication nodes that are selected and verified for physical identity as a business credit evaluation for each participant in the transaction. The right certificate is to use a group of verification nodes to verify the new transaction, and the new network transaction generates a corresponding data block through the consensus of a plurality of verification nodes and adds the data block to the transaction record. According to the IBFT consensus algorithm, each verification node may be randomly selected and dynamically changed over the course of multiple subsequent transaction verifications. One of the verification nodes in the totality is randomly chosen as the proposed node (the promoter) each time a new network transaction needs to be verified. The randomly selected proposed node generates a corresponding data block according to the new network transaction and delivers the data block to the whole verification nodes for verification. These verification nodes and other nodes are formed in the network structure shown in fig. 2. According to one or more embodiments of the invention, each data block is verified by a different set of verification nodes, and after a consensus is obtained, the data block is recorded as a digital signature. The verification node verifies each transaction and determines whether the data block can be added to the current public transaction record linked list or not; and the common nodes have complete copies of the current public transaction record linked list, and the data blocks containing the transaction information and the verification results of the data blocks among the nodes are transmitted among the nodes, so that the nodes can quickly respond to the newly generated data blocks. After the data block is added to the current public transaction record linked list through verification or can not be discarded through verification, one of the verification nodes in the whole group can be selected randomly or the same proposed node can be used continuously, and the process is repeated to verify the next network transaction. When the data block can not pass the verification, the proposed node of the round of verification is replaced, and a new proposed node is randomly selected. The data blocks may be implemented as a data structure as shown in fig. 3. In some embodiments of the present application, the data blocks may be linked together in a linked list manner as shown in the figure to form a current common transaction record linked list, that is, a data header of each data block includes a digital signature of a previous data block (data block 1 includes a linked list header), so that each data block of the current common transaction record linked list may be conveniently verified, and thus, whether the current common transaction record linked list is maliciously damaged or not may be quickly determined, and a rollback to a normal state may be timely performed by deleting an illegal data block. The technical personnel in the field can also select other suitable data structures to record each data block and the current public transaction record linked list, so that whether the current public transaction record linked list is maliciously damaged or not can be conveniently verified, and the current public transaction record linked list can be timely rolled back to a normal state under the condition that the current public transaction record linked list is maliciously damaged. This is not further limited by the present disclosure. Similarly, the transaction verification method can be a common verification method in the art (e.g., verifying whether the digital signature in the data block is correct) and a customized rule (e.g., whether the amount of each transaction exceeds an upper limit, whether the transaction record and the transaction method of the related transaction party are legal), which are not further limited by the present disclosure. Those skilled in the art can select a suitable verification method according to actual situations. In one or more embodiments of the present application, the current public transaction record linked list may be recorded in the data center, and each verified data block may be retrieved by any node (including a verified node and a non-verified normal node) at any time after being added to the current public transaction record linked list stored in the data center. Correspondingly, alternatively, in other embodiments of the present application, each node may also locally store a copy of the current common transaction record linked list, and after the data block passes verification, update its increment to the local copy of the current common transaction record linked list, thereby implementing decentralized storage of the current common transaction record linked list, so as to improve the robustness and security of the system. According to one or more embodiments of the invention, to ensure that only one data block is added to the record linked list at a time, when the data block is known by a plurality of verification nodes but the data block is not added to the record linked list, the selection of a new data block is stopped.
The IBFT consensus algorithm aims to establish trust between nodes in an untrusted network environment; therefore, the network transaction verification method using the IBFT consensus algorithm allows the current user of part of the verification nodes to be malicious and to be colluded to make wrong judgments for the verification of the transaction so as to destroy the normal transaction to the maximum extent. Even under the worst situation, the IBFT consensus algorithm still ensures that each transaction recorded in the current public transaction record linked list passes the audit of most of the 'loyalty' verification nodes in the network and becomes a part of the permanent record, and can track the verification result made by each verification node at any time or further serve as the basis for dynamically adjusting the verification nodes in the verification process of subsequent transactions. Therefore, on one hand, the authorization certification verification mode can verify the safety of the transaction more quickly to meet the actual use requirement than the workload certification verification mode adopted by the traditional block chain technology, and on the other hand, the authorization certification verification mode reserves the advantage that the workload certification verification mode can be applied to an untrusted network environment.
To further cope with the burst-growth of transaction volume in a specific time period, referring to the sub-flowchart shown in fig. 4, in one or more embodiments of the present application, when the number of the verification nodes is 3F +1, the step of initializing the common P2P channel transmission data among the plurality of nodes and the current common transaction record linked list for recording network transactions further includes the sub-steps of: collecting verification results returned by at least 2F +1 verification nodes; and counting the collected verification results, and recording the data blocks to the tail of the current public transaction record linked list when the number of the data blocks passing through the verification nodes is greater than or equal to F + 1. Where F is the number of tolerable error/malicious nodes in a network.
In fact, the IBFT consensus algorithm assumes that the verification nodes which are "loyal" in the network can make the same verification result at any time, and the number of the verification nodes which are malicious to the current user does not exceed 1/3 of the total number of the verification nodes; therefore, when receiving the verification results returned by more than 2F +1 verification nodes, the verification nodes which have received enough loyalty even under the worst condition (namely receiving the verification results made by all the verification nodes with malicious intentions) can be considered to make correct verification results for the transaction, so that no wrong transaction safety judgment can be made. Further, to ensure that each "loyalty" verifying node will make the same verification without the potential for "traitory" intermediate nodes in the traditional Byzantine general Problim to modify the transmitted information, the block is write-locked during verification so that all nodes process the block in a read-only manner. At this time, in the process of transmitting the data block, even if the passed node is occupied by a malicious user currently, the data block is not tampered by the passed node.
In one or more embodiments of the present application, the data blocks are generated at a constant frequency to ensure the security of the system. And if no new transaction information exists currently, the transaction information in the data block is null. In fact, since the length of the current public transaction record linked list is steadily increasing, and the private keys used by the respective verification nodes for signature can be updated regularly according to the length of the current public transaction record linked list accordingly, any malicious user attempting to collect signatures within the data block needs to update the private keys in synchronization with the verification nodes to the needs. This leads to an improvement in the security of the system itself.
In order to timely find and remove 1/3 verification nodes which account for the total number of nodes and are assumed by the IBFT consensus algorithm and are malicious to the current user, in one or more embodiments of the present application, after an increment of data blocks in the current common transaction record linked list is greater than an update threshold, the following steps are further performed: the verification nodes verify each other and when a verification node fails the total 2/3 of all verification nodes, the verification node is deleted and no longer acts as a verification node. Correspondingly, in order to supplement the deleted verification node, in one or more embodiments of the present application, after the increment of the data blocks in the current common transaction record linked list is greater than the update threshold, the following steps are further performed: when the added node passes the verification of the total number of verification nodes 2/3, the added node is selected as the new verification node. Specifically, in some embodiments of the present disclosure, the update of all the nodes may be performed each time 30000 data blocks (including data blocks with empty transaction information) are added to the current common transaction record linked list. In one or more embodiments of the present application, the verification of the verification node itself may also be based on a correctness rate of the judgment of the verification node for the data blocks in the current public transaction record linked list in the time period. Specifically, the verification node that determines that the accuracy is the reciprocal 1/3 will be culled. In one or more embodiments of the invention, when a node does not authenticate to an authenticated node, it indicates that the authenticated node is maintained.
Because the data blocks on the current public transaction record linked list can be viewed by all nodes, the security of the transaction is verified for some mutually trusted transaction parties by creating a dedicated private transaction transmission channel. In particular, referring to the sub-flow diagram shown in fig. 5, the following steps may also be performed between any two or more nodes that are highly trusted with each other: initializing a private transaction transmission channel (for example, designating a port of the private transaction transmission channel between any two or more nodes) and a private transaction data linked list based on a current public transaction record linked list (for example, creating a link head of the private transaction data linked list based on the current public transaction record linked list), and sharing the private transaction data link to the two or more nodes through the private transaction transmission channel; adding a data block containing transaction information and a signature between the two or more nodes to the tail of the private transaction data linked list through a Raft consensus algorithm; incrementally updating the private transaction data link table to the two or more nodes via the private transaction transport channel; wherein the private transaction transport channel is different from the public P2P channel. And data can be transmitted between any two or more nodes only through the private transaction transmission channel. Further, the current public transaction record linked list and the private transaction transport channel are isolated from each other. There is no interoperability or crossover between them. Thus, the benefits of sending transactions over a private transaction transmission channel include at least not broadcasting transaction information to the entire network. Each private transaction transport channel can be considered a discrete Raft network.
Running a private transaction transmission channel means that although network participants may not trust each other completely (they may even be competitors of the same industry), they can select other participants with whom to conduct private transactions and, by transmitting the data block only on the private transaction transmission channel, so that only parties using the private transaction transmission channel can see the transaction data between them. This provides an option for greater transaction privacy. As can be seen from the foregoing discussion, since the parties that transact over the private transaction transport channel have a higher trust in each other, the verification of the transaction between these nodes will be completed in a manner different from the current public transaction record linked list, i.e., the verification is completed by using the Raft consensus algorithm instead of the IBFT consensus algorithm. At this point, there will be a countdown timer (electric Timeout) on each node for the current Raft network. In an embodiment of the application, the countdown timer is randomly between 150ms and 300 ms. In other embodiments of the present application, the time is 160ms, 180ms, 200ms, 220ms, 250ms, or 280 ms. During the operation of the Raft network, each node will perform at least the following two activities: a Leader Election (Leader Election) and a Replication Log (Log Replication). At the start of the election master activity, all nodes in the Raft network are initialized to a follow (Follower) state. After the countdown of a node is over (Timeout), the state of the node becomes the Candidate (Candidate) state and the election is lifted. It sends election requests (Request Vote) to several other nodes. If at least more than half of the other nodes return success, the state of the node is changed from candidate to dominant (Leader), and after a short time, a Heartbeat Message (Heartbeat Message) is sent to all nodes in the candidate state to keep the current state of all nodes. The candidate state node resets its own countdown timer after receiving the heartbeat information of the dominant state node. When the client sends a request to the node in the dominant state, the related data is written in the local log by the node in the dominant state. The node in the leading state then sends a request to the other nodes in the following state to update their local logs. When the data is written to the local log by other nodes in the following state and success information is returned to the nodes in the leading state. As long as the nodes in the leading state receive the success information returned by the majority of the nodes, the related data is set to be in a confirmation state in the local logs on the nodes in the leading state. At this time, the node in the leading state sends confirmation information to the nodes in other following states, so that the corresponding data setting of the nodes in the following states in the local log is changed into the confirmed state, and the complete log copying process is completed.
At the same time, this allows transaction speeds to be increased to thousands of transactions per second to meet daily transaction needs. For example, embodiments of the present invention can process at least 1400 transactions per second. In other embodiments, it can process at least 1650 transactions per second. In addition, the robustness of the Raft consensus algorithm also enables the transaction between the parties to be verified as usual as long as more than half of the two or more nodes participating in the transaction can normally operate; and the private transaction data linked list can be kept consistent on each node through operations such as rollback and the like after the corresponding node is recovered. In other words, the Raft consensus algorithm is based on a trust network, and a corresponding Raft network can tolerate a number of error/malicious nodes less than 1/2. In one or more embodiments of the invention, when most nodes fail, the private transaction will stop, and the corresponding data block of the private transaction will not be added to the private transaction data block linked list. For example, when two nodes conduct private transactions and one of the nodes fails or goes offline, the transaction will abort. In one or more embodiments of the invention, the node that was offline may later rejoin the original private transaction and update the data linked list missed while offline to the rejoined node.
The characteristics of high throughput, safety and privacy of the invention can effectively manage or process the affairs among a plurality of business organizations. The subject technology can be used to manage or process transactions between multiple business organizations, between multiple business organizations and consumers, and/or between multiple consumers. In the embodiment of the invention, the technical scheme can be applied to managing the consumption reward program. Business organizations and consumers are multiple nodes of network transactions. The consumption record, business organization specific reward points, general points, etc. are transaction information and signatures in the data block.
With reference to the block diagram of a multi-node based network transaction verification system shown in FIG. 6, one of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
In the embodiments provided in the present invention, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described system embodiments are merely illustrative, and for example, the division of the modules or units is only one logical division, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, all or part of the flow of the method according to the embodiments of the present invention may also be implemented by a computer program, which may be stored in a computer-readable storage medium, and when the computer program is executed by a processor, the steps of the method embodiments may be implemented. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, usb disk, removable hard disk, magnetic disk, optical disk, computer Memory, Read-Only Memory (ROM), Random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution medium, and the like. It should be noted that the computer readable medium may contain other components which may be suitably increased or decreased as required by legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer readable media which may not include electrical carrier signals and telecommunications signals in accordance with legislation and patent practice.
The above-mentioned embodiments are only used for illustrating the technical solutions of the present invention, and not for limiting the same; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present invention, and are intended to be included within the scope of the present invention.
Claims (10)
- A network transaction verification method based on multiple nodes, comprising the steps of:identifying actual identities corresponding to a plurality of nodes participating in network transactions;selecting a part of the nodes from the plurality of nodes as verification nodes for verifying the network transaction nodes;initializing a common P2P channel transmission data among the plurality of nodes and a current common transaction record linked list for recording network transactions;generating and adding a data block containing transaction information and a signature to the current public transaction record linked list through an IBFT consensus algorithm; andand updating the verification nodes after the increment of the data blocks in the current common transaction record linked list is larger than an updating threshold, wherein the updating step comprises that the verification nodes are verified by the plurality of nodes.
- The network transaction verification method of claim 1, wherein when the number of verification nodes is 3F +1, the step of initializing the common P2P channel between the plurality of nodes to transmit data and the current common transaction record linked list for recording network transactions further comprises the sub-steps of:collecting verification results returned by at least 2F +1 verification nodes;and counting the collected verification results, and recording the data blocks to the tail of the current public transaction record linked list when the number of the data blocks passing through the verification nodes is greater than or equal to F + 1.
- The network transaction verification method of claim 1, wherein the data block is generated at a constant frequency, wherein when there is no new transaction information currently, the transaction information in the data block is empty.
- The network transaction verification method of claim 1, wherein the updating step further comprises:when the verified verifying node cannot pass the verification of the total number 2/3 of the collective verifying nodes, the verified verifying node no longer acts as a verifying node.
- The network transaction verification method of claim 1, wherein the updating step further comprises:when the newly added verification node passes the verification of the total number 2/3 of verification nodes, the newly added node is selected as the new verification node.
- The network transaction verification method of claim 1, wherein the update threshold is 30000.
- The network transaction verification method of claim 1, wherein the following steps are further performed between any two or more nodes:initializing a private transaction transmission channel and a private transaction data linked list based on a current public transaction record linked list, and sharing the private transaction data link to the two or more nodes through the private transaction transmission channel;adding a data block containing transaction information and a signature between the two or more nodes to the tail of the private transaction data linked list through a Raft consensus algorithm;incrementally updating the private transaction data link table to the two or more nodes via the private transaction transport channel;wherein the private transaction transport channel is different from the public P2P channel.
- The network transaction verification method of claim 1, wherein the data block is write-locked during verification such that all nodes process the data block in a read-only manner.
- A computer system comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any of claims 1-8 when executing the computer program.
- A storage medium, wherein a computer program is stored in the storage medium, which computer program is arranged to, when executed, perform the method of any one of claims 1-8.
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| HK19123085 | 2019-04-29 | ||
| HK19123085.3 | 2019-04-29 | ||
| HK19133728 | 2019-12-17 | ||
| HK19133728.6 | 2019-12-17 | ||
| PCT/CN2020/087770 WO2020221292A1 (en) | 2019-04-29 | 2020-04-29 | Network transaction verification method based on plurality of nodes, and system therefor and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113348656A true CN113348656A (en) | 2021-09-03 |
Family
ID=73028603
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202080011112.0A Pending CN113348656A (en) | 2019-04-29 | 2020-04-29 | Network transaction verification method based on multiple nodes, system and storage medium thereof |
Country Status (4)
| Country | Link |
|---|---|
| JP (1) | JP7192196B2 (en) |
| CN (1) | CN113348656A (en) |
| SG (1) | SG11202110209WA (en) |
| WO (1) | WO2020221292A1 (en) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112600874B (en) * | 2020-11-24 | 2023-03-31 | 成都质数斯达克科技有限公司 | Node joining method and device, electronic equipment and readable storage medium |
| JPWO2024004485A1 (en) * | 2022-06-30 | 2024-01-04 | ||
| WO2024009650A1 (en) * | 2022-07-04 | 2024-01-11 | 株式会社CountUp | Blockchain network configuration method and computer software program for executing same |
| CN117978547B (en) * | 2024-03-29 | 2024-06-07 | 华东交通大学 | TRP-PBFT consensus method, system, storage medium and equipment |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107766540A (en) * | 2017-10-31 | 2018-03-06 | 上海分布信息科技有限公司 | A kind of block chain network of subregion and its method for realizing partitioned storage |
| CN107909369A (en) * | 2017-10-13 | 2018-04-13 | 布比（北京）网络技术有限公司 | Based on the common recognition method, apparatus merchandised across chain and storage medium |
| WO2018069566A1 (en) * | 2016-10-14 | 2018-04-19 | Nokia Technologies Oy | Method, device and system for validating sensitive user data transactions within trusted circle |
| US20180276668A1 (en) * | 2017-03-24 | 2018-09-27 | Alibaba Group Holding Limited | Method and apparatus for consensus verification |
| WO2018223042A1 (en) * | 2017-06-01 | 2018-12-06 | Schvey, Inc. d/b/a/ Axoni | Distributed privately subspaced blockchain data structures with secure access restriction management |
| CN109002349A (en) * | 2018-06-25 | 2018-12-14 | 百度在线网络技术（北京）有限公司 | Application program exchange method, implementation method, device, equipment and medium |
| CN109327459A (en) * | 2018-11-12 | 2019-02-12 | 崔晓晖 | A kind of common recognition method of alliance's block chain network |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180123779A1 (en) * | 2016-11-01 | 2018-05-03 | Jiangang Zhang | Flexible Blockchain Smart-Contract Deployment |
| CN107124403A (en) * | 2017-04-14 | 2017-09-01 | 朱清明 | The generation method and computing device of common recognition block in block chain |
| CN107231299A (en) * | 2017-06-07 | 2017-10-03 | 众安信息技术服务有限公司 | A kind of chain route and realized the system that block chain communicates across chain |
| CN108320155B (en) * | 2017-12-21 | 2020-09-11 | 中国科学院信息工程研究所 | Method for realizing block chain consensus mechanism |
| CN108881287A (en) * | 2018-07-18 | 2018-11-23 | 电子科技大学 | A kind of Internet of things node identity identifying method based on block chain |
-
2020
- 2020-04-29 SG SG11202110209WA patent/SG11202110209WA/en unknown
- 2020-04-29 CN CN202080011112.0A patent/CN113348656A/en active Pending
- 2020-04-29 WO PCT/CN2020/087770 patent/WO2020221292A1/en active Application Filing
- 2020-04-29 JP JP2021544762A patent/JP7192196B2/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018069566A1 (en) * | 2016-10-14 | 2018-04-19 | Nokia Technologies Oy | Method, device and system for validating sensitive user data transactions within trusted circle |
| US20180276668A1 (en) * | 2017-03-24 | 2018-09-27 | Alibaba Group Holding Limited | Method and apparatus for consensus verification |
| WO2018223042A1 (en) * | 2017-06-01 | 2018-12-06 | Schvey, Inc. d/b/a/ Axoni | Distributed privately subspaced blockchain data structures with secure access restriction management |
| CN107909369A (en) * | 2017-10-13 | 2018-04-13 | 布比（北京）网络技术有限公司 | Based on the common recognition method, apparatus merchandised across chain and storage medium |
| CN107766540A (en) * | 2017-10-31 | 2018-03-06 | 上海分布信息科技有限公司 | A kind of block chain network of subregion and its method for realizing partitioned storage |
| CN109002349A (en) * | 2018-06-25 | 2018-12-14 | 百度在线网络技术（北京）有限公司 | Application program exchange method, implementation method, device, equipment and medium |
| CN109327459A (en) * | 2018-11-12 | 2019-02-12 | 崔晓晖 | A kind of common recognition method of alliance's block chain network |
Non-Patent Citations (1)
| Title |
|---|
| YUTELIN: "Istanbul Byzantine Fault Tolerance", 《GITHUB》 * |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2020221292A1 (en) | 2020-11-05 |
| JP7192196B2 (en) | 2022-12-20 |
| SG11202110209WA (en) | 2021-11-29 |
| JP2022518960A (en) | 2022-03-17 |
| WO2020221292A9 (en) | 2021-01-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10942994B2 (en) | Multicomputer processing for data authentication using a blockchain approach | |
| US11159537B2 (en) | Multicomputer processing for data authentication and event execution using a blockchain approach | |
| CN111464518B (en) | Method and device for sending and verifying cross-link communication data | |
| US11962681B2 (en) | Symmetric encryption for private smart contracts among multiple parties in a private peer-to-peer network | |
| CN113348656A (en) | Network transaction verification method based on multiple nodes, system and storage medium thereof | |
| CN115210741B (en) | Partially ordered blockchain | |
| CN110351133A (en) | Method and device for the host node hand-off process in block catenary system | |
| CN114600419A (en) | Encrypted asset hosting system with equity certification blockchain support | |
| CN118395709A (en) | Computer-implemented system and method for connecting blockchain to digital twinning | |
| CN114631286B (en) | Encrypted asset hosting system with custom logic | |
| US10693646B2 (en) | Event execution using a blockchain approach | |
| CN110769035A (en) | Block chain asset issuing method, platform, service node and storage medium | |
| CN114363327A (en) | Compliance mechanism in blockchain networks | |
| CN110555682B (en) | Multi-channel implementation method based on alliance chain | |
| CN113328854B (en) | Service processing method and system based on block chain | |
| WO2021143364A1 (en) | Method and apparatus for acquiring transaction processing state in decentralized application cluster | |
| KR102376783B1 (en) | The blockchain-based transaction history confirmation system | |
| CN112182626A (en) | Supply chain financial risk management system based on block chain technology | |
| Behl et al. | Trusted data notifications from private blockchains | |
| US20240163120A1 (en) | Information transmission method, system and device based on blockchain, and computer-readable storage medium | |
| KR102605368B1 (en) | Method and server for verifying authenticity of mail | |
| CN111162970B (en) | Method and device for testing decentralized application server in block chain system | |
| CN114239044B (en) | Decentralizing device retrospective shared access system | |
| RU2794054C2 (en) | Automated system for independent confirmation of transactions | |
| US20230368293A1 (en) | Fiat payment based on a cryptocurrency blockchain transaction |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20210903 |
|
| WD01 | Invention patent application deemed withdrawn after publication |