A consensus method based on a blockchain sensor and a terminal

Abstract

The application discloses a consensus method and a terminal based on a blockchain sensor, a transaction request is initiated to a target general node connected with the blockchain sensor in a blockchain peer-to-peer network by using the blockchain, when the target general node is connected with multiple blockchain sensors, it is considered that the transaction between the blockchain sensors connected with the same general node is a local transaction, a consensus node can be directly and randomly selected to complete the consensus, otherwise, multiple master nodes are used to complete the consensus of non-local transactions, by dividing the local transactions and the non-local transactions, different consensus methods are used, the calculation resources can be effectively saved, the consensus is realized by using multiple master nodes for the non-local transactions, which is different from the single master node consensus in the prior art, the communication complexity can be effectively reduced, the consensus efficiency is greatly improved, and even the resource-limited blockchain sensor can participate in the blockchain consensus process.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of consensus technology, in particular to a consensus method based on a blockchain sensor and a terminal. BACKGROUND

[0002] There are three improvement directions for the consensus algorithm PBFT (Practical Byzantine Fault Tolerance, Practical Byzantine Fault Tolerance algorithm): one is to control the number of nodes participating in consensus, this direction selects a part of all nodes in the system as a committee, the committee nodes participate in consensus, and then sends the consensus result to the remaining nodes, reduces the communication consumption, and thus achieves the purpose of improving the system scalability; the second is to optimize the consensus process, this direction improves the master node selection method or increases the node evaluation mechanism, reduces unnecessary communication, and thus achieves the purpose of improving the consensus efficiency; the third is to improve the consensus structure, this direction introduces a hierarchical model or a grouping idea to reduce the number of communications required for consensus, and thus achieves the purpose of improving the consensus efficiency.

[0003] The above three improvement methods improve the consensus efficiency to a certain extent, but the communication complexity is still O(n 2 ), O(n 2 ) is a square complexity, which means that each element is processed n times, the communication overhead is large, and it cannot meet the low energy consumption requirement of the blockchain sensor device, so that the blockchain sensor device cannot participate in the blockchain consensus process. SUMMARY

[0004] The technical problem to be solved by the present application is to provide a consensus method based on a blockchain sensor and a terminal, which can effectively reduce the communication complexity and maximize the consensus efficiency.

[0005] To solve the above technical problems, one technical solution adopted by the present application is:

[0006] A consensus method based on a blockchain sensor, comprising the steps of:

[0007] determining a target general node connected to a blockchain sensor in a blockchain peer-to-peer network, and initiating a transaction request using the target general node;

[0008] determining whether the target general node is connected to multiple blockchain sensors, if yes, marking the transaction request as a local transaction, and completing consensus on the local transaction based on a randomly selected consensus node, if not, marking the transaction request as a non-local transaction, and completing consensus on the non-local transaction based on a plurality of master nodes selected additionally.

[0009] To solve the above technical problems, another technical solution adopted by the present application is:

[0010] A consensus terminal based on a blockchain sensor, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the following steps when executing the computer program:

[0011] determining a target general node connected with the blockchain sensor in a blockchain peer-to-peer network, and initiating a transaction request by using the target general node;

[0012] judging whether the target general node is connected with multiple blockchain sensors, if yes, marking the transaction request as a local transaction, and completing consensus on the local transaction based on a randomly selected consensus node, if not, marking the transaction request as a non-local transaction, and completing consensus on the non-local transaction based on multiple master nodes selected additionally.

[0013] The present application has the beneficial effects that: the transaction request is initiated by using the target general node connected with the blockchain sensor in the blockchain peer-to-peer network, when the target general node is connected with multiple blockchain sensors, the transaction between the blockchain sensors connected with the same general node is considered as a local transaction, and a consensus node can be directly selected randomly to complete the consensus, otherwise, multiple master nodes are used to complete the consensus on the non-local transaction, by dividing the local transaction and the non-local transaction, different consensus methods are used respectively, the computing resources can be effectively saved, and for the non-local transaction, multiple master nodes are used to complete the consensus, which is different from the single master node consensus in the prior art, the communication complexity can be effectively reduced, and the consensus efficiency is greatly improved, even the resource-limited blockchain sensor can participate in the blockchain consensus process. BRIEF DESCRIPTION OF DRAWINGS

[0014] Figure 1 A step flow chart of a consensus method based on a blockchain sensor according to an embodiment of the present application;

[0015] Figure 2 A structure schematic diagram of a consensus terminal based on a blockchain sensor according to an embodiment of the present application;

[0016] Figure 3 A consensus schematic diagram of a consensus method based on a blockchain sensor according to an embodiment of the present application;

[0017] Figure 4 A consensus flow chart of a consensus method based on a blockchain sensor according to an embodiment of the present application. DETAILED DESCRIPTION

[0018] To describe the technical content, the purposes and effects of the present application in detail, the following will be described in combination with the embodiments and the drawings.

[0019] Please refer toFigure 1 The embodiment of the present application provides a consensus method based on a blockchain sensor, comprising the following steps:

[0020] A target general node connected with the blockchain sensor in the blockchain peer-to-peer network is determined, and a transaction request is initiated by using the target general node;

[0021] It is judged whether the target general node is connected with multiple blockchain sensors, if yes, the transaction request is marked as a local transaction, and a consensus of the local transaction is completed based on a randomly selected consensus node, if not, the transaction request is marked as a non-local transaction, and a consensus of the non-local transaction is completed based on multiple master nodes selected additionally.

[0022] From the above description, the beneficial effects of the present application are that: the transaction request is initiated by using the target general node connected with the blockchain sensor in the blockchain peer-to-peer network, when the target general node is connected with multiple blockchain sensors, the transaction between the blockchain sensors connected with the same general node is considered as a local transaction, a consensus node can be directly selected randomly to complete the consensus, otherwise, multiple master nodes are used to complete the consensus of the non-local transaction, by dividing the local transaction and the non-local transaction, different consensus methods are used respectively, the calculation resources can be effectively saved, and for the non-local transaction, multiple master nodes are used to complete the consensus, which is different from the single master node consensus in the prior art, the communication complexity can be effectively reduced, and the consensus efficiency is greatly improved, even if the blockchain sensor is limited in resources, the blockchain sensor can also participate in the blockchain consensus process.

[0023] Further, the consensus of the local transaction based on the randomly selected consensus node comprises:

[0024] A trusted node list corresponding to the target general node is acquired, and the trusted node list comprises multiple consensus nodes;

[0025] A consensus node is randomly selected from the multiple consensus nodes, and the local transaction is verified by using the consensus node;

[0026] After the verification, the local transaction is sent to a sorting node, and all local transactions on the target general node are collected by using the sorting node;

[0027] The sorting node is used to construct a new block according to all the local transactions on the target general node, and the new block is signed and stored.

[0028] From the above description, for the local transaction, a consensus node can be randomly selected from the multiple consensus nodes to verify the local transaction, after the verification, the sorting node can be used to construct a new block, and the new block is chained, so that the consensus efficiency is effectively improved.

[0029] Further, the consensus on the non-local transaction based on the plurality of master nodes selected additionally comprises:

[0030] Obtaining a list of trusted nodes corresponding to the target general node, the list of trusted nodes comprising a plurality of consensus nodes;

[0031] Selecting a plurality of master nodes from the plurality of consensus nodes;

[0032] Verifying the non-local transaction using the plurality of master nodes, and after verification, generating a corresponding pre-preparation message according to the non-local transaction, and broadcasting the pre-preparation message to each consensus node using the plurality of master nodes;

[0033] Verifying the pre-preparation message using each consensus node, and after verification, generating a corresponding first preparation message according to the pre-preparation message, and sending the first preparation message to the plurality of master nodes;

[0034] Using the plurality of master nodes to determine whether the number of identical contents in all received first preparation messages exceeds a first preset proportion, and if so, generating a corresponding second preparation message according to the first preparation message, and sending the second preparation message to each consensus node;

[0035] Verifying the second preparation message using each consensus node, and after verification, executing the non-local transaction according to the second preparation message, generating transaction information with an execution result, and generating a first submission message according to the transaction information with the execution result;

[0036] Using each consensus node to send the first submission message to the plurality of master nodes;

[0037] Using the plurality of master nodes to determine whether the first submission message sent by the first preset proportion of consensus nodes is received, and if so, verifying the first submission message, and after verification, constructing a new block according to the first submission message, and broadcasting the new block to all consensus nodes;

[0038] Verifying the new block using each consensus node, and after verification, determining that the chaining is successful.

[0039] As can be seen from the above description, for non-local transactions, through multiple rounds of message interaction and verification between the plurality of master nodes and the plurality of consensus nodes, a new block is finally constructed, the chaining of the new block is completed, the algorithm processing pressure is shared by the plurality of nodes, the communication complexity is reduced, and the reliability of the consensus process is ensured.

[0040] Further, the determining includes:

[0041] Traversing the general nodes in the blockchain peer-to-peer network;

[0042] Obtaining the comprehensive scores and energy values of other nodes except the traversed general node;

[0043] Respectively sorting the other nodes in descending order according to the comprehensive scores and energy values, to obtain a first set and a second set;

[0044] Selecting nodes of a second preset proportion in the first set as a first sub-set in sequence;

[0045] Selecting nodes of a second preset proportion in the second set as a second sub-set in sequence;

[0046] Determining other nodes existing in the first sub-set and the second sub-set as candidate consensus nodes;

[0047] Selecting nodes of a third preset proportion from the candidate consensus nodes as consensus nodes, to generate a trusted node list corresponding to the traversed general node.

[0048] As can be seen from the above description, the comprehensive scores and energy values are used to determine the trusted node list corresponding to the general node, which ensures the reliability of the consensus nodes in the list, reduces the possibility of Byzantine node evil, and thus improves the security of the consensus process.

[0049] Further, the transaction request includes transaction-related information and a signature of a sensor module corresponding to the blockchain sensor on the transaction;

[0050] The generating of the corresponding pre-preparation message according to the non-local transaction includes:

[0051] Generating a corresponding pre-preparation message according to the signature of the sensor module corresponding to the blockchain sensor on the transaction, the transaction-related information, and the master node sequence number;

[0052] The verifying of the pre-preparation message by the respective consensus nodes, and the generating of a corresponding first preparation message according to the pre-preparation message after the verification includes:

[0053] Verifying the signature of the transaction in the pre-preparation message and the master node sequence number by the respective consensus nodes, and generating a transaction set according to the transactions of different master nodes after the verification;

[0054] Generating a first preparation message based on the transaction set, the hash value of the transaction set, and the signature corresponding to the hash value of the transaction set by the respective consensus nodes.

[0055] From the above description, according to the sensor module corresponding to the blockchain sensor, the signature of the transaction, the transaction related information and the master node serial number generate a corresponding pre-preparation message, which is used as the basis message for subsequent verification, and a new message is generated every time for subsequent verification to ensure the validity of each verification, thereby ensuring the safety and reliability of the consensus process.

[0056] Please refer to Figure 2 A consensus terminal based on a blockchain sensor, comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the following steps when executing the computer program:

[0057] Determine a target general node connected to the blockchain sensor in the blockchain peer-to-peer network, and initiate a transaction request using the target general node;

[0058] Determine whether the target general node is connected to multiple blockchain sensors, if yes, mark the transaction request as a local transaction, and complete consensus on the local transaction based on a randomly selected consensus node, if not, mark the transaction request as a non-local transaction, and complete consensus on the non-local transaction based on multiple master nodes selected additionally.

[0059] From the above description, the beneficial effects of the present application are that: the target general node connected to the blockchain sensor in the blockchain peer-to-peer network is used to initiate a transaction request, when the target general node is connected to multiple blockchain sensors, the transaction between the blockchain sensors connected to the same general node is considered as a local transaction, and a consensus node can be randomly selected directly to complete the consensus, otherwise, multiple master nodes are used to complete the consensus of non-local transactions, by dividing local transactions and non-local transactions, different consensus methods are used respectively, which can effectively save computing resources, and for non-local transactions, multiple master nodes are used to realize consensus, which is different from the existing single master node consensus, which can effectively reduce the communication complexity and greatly improve the consensus efficiency, even if the resource-limited blockchain sensor can also participate in the blockchain consensus process.

[0060] Further, the consensus on the local transaction based on a randomly selected consensus node comprises:

[0061] Obtain a list of trusted nodes corresponding to the target general node, the list of trusted nodes comprising multiple consensus nodes;

[0062] Randomly select a consensus node from the multiple consensus nodes, and use the consensus node to verify the local transaction;

[0063] After the verification, the local transaction is sent to a sorting node, and all local transactions on the target general node are collected using the sorting node;

[0064] A new block is constructed using the sorting node according to all local transactions on the target general node, and the new block is signed and stored.

[0065] As can be seen from the above description, for a local transaction, since the target node and the source node approve the transaction, no other node is needed to endorse, a consensus node can be randomly selected from a plurality of consensus nodes to verify the local transaction, and after the verification, a new block can be constructed using the sorting node to complete the on-chain of the new block, thereby effectively improving the consensus efficiency.

[0066] Further, the consensus on the non-local transaction based on the plurality of master nodes selected additionally includes:

[0067] Obtaining a list of trusted nodes corresponding to the target general node, the list of trusted nodes including a plurality of consensus nodes;

[0068] Selecting a plurality of master nodes from the plurality of consensus nodes;

[0069] Verifying the non-local transaction using the plurality of master nodes, and after the verification, generating a corresponding pre-preparation message according to the non-local transaction, and broadcasting the pre-preparation message to each consensus node using the plurality of master nodes;

[0070] Verifying the pre-preparation message using the each consensus node, and after the verification, generating a corresponding first preparation message according to the pre-preparation message, and sending the first preparation message to the plurality of master nodes;

[0071] Using the plurality of master nodes to determine whether the number of identical contents in all received first preparation messages exceeds a first preset proportion, if yes, generating a corresponding second preparation message according to the first preparation message, and sending the second preparation message to the each consensus node;

[0072] Verifying the second preparation message using the each consensus node, and after the verification, executing the non-local transaction according to the second preparation message, generating transaction information with an execution result, and generating a first submission message according to the transaction information with the execution result;

[0073] Sending the first submission message to the plurality of master nodes using the each consensus node;

[0074] determining whether the first submission message sent by a first preset proportion of consensus nodes is received, if yes, verifying the first submission message, and after verification, constructing a new block according to the first submission message and broadcasting the new block to all consensus nodes;

[0075] verifying the new block by using the respective consensus nodes, and after verification, determining that the new block is successfully chained.

[0076] As can be seen from the above description, for non-local transactions, through multiple rounds of message interaction and verification between multiple master nodes and multiple consensus nodes, a new block is finally constructed, the new block is chained, the algorithm processing pressure is shared by multiple nodes, the communication complexity is reduced, and the reliability of the consensus process is ensured.

[0077] Further, the determining a target general node connected with a blockchain sensor in the blockchain peer-to-peer network comprises:

[0078] traversing general nodes in the blockchain peer-to-peer network;

[0079] obtaining comprehensive scores and energy values of other nodes except the traversed general nodes;

[0080] sequentially selecting a second preset proportion of nodes in the first set as a first sub-set;

[0081] sequentially selecting a second preset proportion of nodes in the second set as a second sub-set;

[0082] sequentially selecting a second preset proportion of nodes in the second set as a second sub-set;

[0083] determining other nodes existing in both the first sub-set and the second sub-set as candidate consensus nodes;

[0084] selecting a third preset proportion of nodes from the candidate consensus nodes as consensus nodes, and generating a trusted node list corresponding to the traversed general node.

[0085] As can be seen from the above description, the comprehensive score and the energy value are used to determine the trusted node list corresponding to the general node, which ensures the reliability of the consensus nodes in the list, reduces the possibility of Byzantine node evil, and thus improves the security of the consensus process.

[0086] Further, the transaction request comprises transaction-related information and a signature of a sensor module corresponding to the blockchain sensor on the transaction;

[0087] The generating a corresponding pre-preparation message according to the non-local transaction comprises:

[0088] According to the signature of the transaction, the transaction related information and the master node sequence number of the sensor module corresponding to the blockchain sensor, a corresponding pre-preparation message is generated;

[0089] The use of the respective consensus nodes to verify the pre-preparation message, and after verification, a corresponding first preparation message is generated according to the pre-preparation message, comprising:

[0090] The use of the respective consensus nodes to verify the signature of the transaction in the pre-preparation message and the master node sequence number, and after verification, a transaction set is generated according to the transaction of different master nodes;

[0091] The use of the respective consensus nodes to generate a first preparation message based on the transaction set, the hash value of the transaction set and the signature corresponding to the hash value of the transaction set.

[0092] From the above description, according to the signature of the transaction, the transaction related information and the master node sequence number of the sensor module corresponding to the blockchain sensor, a corresponding pre-preparation message is generated, which is used as the basis message for subsequent verification, and a new message is generated every time for subsequent verification to ensure the validity of each verification, thereby ensuring the safety and reliability of the consensus process.

[0093] The above-mentioned consensus method and terminal based on the blockchain sensor of the application can be applied to the blockchain scene in the sensor environment, and the following will be described through specific embodiments:

[0094] Embodiment one

[0095] Please refer to Figure 1 , Figure 3 and Figure 4 , a consensus method based on a blockchain sensor of the present embodiment, comprising the steps of:

[0096] S1, traversing the general nodes in the blockchain peer-to-peer network;

[0097] The general node is authorized and verified by the CA (Certificate Authority, Certificate Authority) and then added to the blockchain peer-to-peer network, and the general node carries an information element of energy value.

[0098] S2, obtaining the comprehensive score and energy value of other nodes except the traversed general nodes, wherein the energy value is the electric quantity.

[0099] S3, respectively sorting the other nodes in descending order according to the comprehensive score and energy value, obtaining a first set and a second set;

[0100] In one alternative implementation, the other nodes are sorted in descending order according to the comprehensive score to obtain a first set, and then the other nodes are sorted in descending order according to the energy value to obtain a second set.

[0101] S4. Select nodes of the second preset proportion in the first set as the first subset CS in sequence.

[0102] S5. Select nodes of the second preset proportion in the second set as the second subset EV in sequence.

[0103] In one optional implementation, the second preset ratio is 40%.

[0104] S6. Other nodes that exist in both the first subset and the second subset are identified as candidate consensus nodes CN, i.e., CS∩EV=CN.

[0105] S7. Select the top three preset proportion of nodes from the candidate consensus nodes as consensus nodes, and generate a list of trusted nodes corresponding to the general nodes traversed.

[0106] In one optional implementation, the third preset ratio is 20%; in another optional implementation, the remaining 80% of the candidate consensus nodes are used as backup nodes.

[0107] In other words, in addition to carrying energy values, each general node also has its own list of trusted nodes.

[0108] S8. Identify the target general node in the blockchain peer-to-peer network that is connected to the blockchain sensor, and initiate a transaction request using the target general node.<Request,m,sign(m),t> C t >, such as Figure 4 As shown, that is Figure 4 The transaction request includes transaction-related information m, the signature sign(m) of the transaction from the sensor module TM (Trusted Module) corresponding to the blockchain sensor, and the serial number C of the blockchain sensor. t Where m includes information such as the transaction timestamp, the public keys of both parties, and the transaction amount;

[0109] In one alternative implementation, such as Figure 3 As shown, the blockchain sensor (i.e. Figure 4The sensor device in the target general node sends a transaction proposal request to the blockchain peer-to-peer network through an SDK (Software Development Kit), and the blockchain peer-to-peer network randomly assigns the target general node to connect with the blockchain sensor according to the distance between the node and the blockchain sensor;

[0110] S9, determining whether the target general node is connected to multiple blockchain sensors, if yes, performing S91, if not, performing S92.

[0111] S91, marking the transaction request as a local transaction, and performing consensus on the local transaction based on a randomly selected consensus node, specifically including:

[0112] S911, marking the transaction request as a local transaction, and obtaining a trusted node list corresponding to the target general node, the trusted node list including multiple consensus nodes;

[0113] S912, randomly selecting a consensus node from the multiple consensus nodes, and verifying the local transaction using the consensus node;

[0114] S913, after verification, sending the local transaction to an ordering node, and using the ordering node to collect all local transactions on the target general node, the ordering node being a concept of an ordering node in hyperledger Fabric, used for ordering transactions and packing into a new block according to rules;

[0115] S914, using the ordering node to construct a new block according to all local transactions on the target general node, and signing and storing the new block, thereby completing the on-chain of the new block, as shown in Figure 3 , Figure 4 B0, B1, …, B j+3 representing a block.

[0116] S92, marking the transaction request as a non-local transaction, and performing consensus on the non-local transaction based on a plurality of master nodes selected additionally, specifically including:

[0117] S921, marking the transaction request as a non-local transaction, and obtaining a trusted node list corresponding to the target general node, the trusted node list including multiple consensus nodes;

[0118] S922, selecting multiple master nodes from the multiple consensus nodes;

[0119] In an optional embodiment, 20% of the master nodes are selected from the multiple consensus nodes in order, effectively reducing the possibility of a Byzantine node committing fraud.

[0120] S923, verifying the non-local transaction using the plurality of master nodes, and upon verification, generating a corresponding pre-preparation message according to the non-local transaction, and broadcasting the pre-preparation message to each consensus node using the plurality of master nodes;

[0121] The generating of the corresponding pre-preparation message according to the non-local transaction comprises:

[0122] According to the signature sign(m) of the transaction, the transaction-related information m, and the master node sequence number Ni of the corresponding sensor module of the blockchain sensor, a corresponding pre-preparation message <<Pre-prepare, sign(m), Ni>, m> is generated, as shown in Figure 4 , that is, the Pre-prepare (pre-preparation) stage in Figure 4 ;

[0123] S924, verifying the pre-preparation message using each consensus node, and upon verification, generating a corresponding first preparation message according to the pre-preparation message, and sending the first preparation message to the plurality of master nodes, specifically comprising:

[0124] S9241, verifying the signature of the transaction and the master node sequence number in the pre-preparation message using each consensus node, and upon verification, generating a transaction set according to the transactions of different master nodes;

[0125] In an optional embodiment, the transactions PT1, PT2, …, PT k are taken and the union is obtained to obtain PT = PT1∪PT2∪……∪PT k , which is sorted according to the timestamp to generate a transaction set T.

[0126] S9242, generating a first preparation message based on the transaction set, the hash value of the transaction set, and the signature corresponding to the hash value of the transaction set using each consensus node;

[0127] In an optional embodiment, a first preparation message <<Prepare1, H(T), sign(H(T)), Ni>, T> is generated according to the transaction set T, the hash value H(T) of the transaction set, the signature sign(H(T)) corresponding to the hash value of the transaction set, and the sequence number Ni of the master node using each consensus node, as shown in Figure 4 , that is, the Prepare1 (first preparation) stage in Figure 4 .

[0128] S9243, sending the first preparation message to the plurality of master nodes.

[0129] S925, determining, using the plurality of master nodes, whether the number of identical contents in all received first preparation messages exceeds a first preset proportion, if yes, generating a corresponding second preparation message according to the first preparation messages, and sending the second preparation message to the respective consensus nodes;

[0130] In an optional implementation, the first preset proportion is 2 / 3; the generating of the corresponding second preparation message according to the first preparation messages is: generating the corresponding second preparation message <<Prepare2, H(T), Prepare1Tset, sign(H(T) || Prepare1Tset), Ni, Prepare1Tset> according to the set of first preparation messages Prepare1Tset, the hash value H(T) of the transaction set, the signature sign(H(T) of the hash value of the transaction set, and the sequence number Ni of the master node, as shown in Figure 4 , that is, the Prepare2 (second preparation) phase in Figure 4 .

[0131] S926, verifying, using the respective consensus nodes, the second preparation message, and after the verification is passed, executing the non-local transaction according to the second preparation message, generating transaction information with an execution result, and generating a first submission message according to the transaction information with the execution result;

[0132] In an optional implementation, the generating of the first submission message according to the transaction information with the execution result is:

[0133] generating the first submission message <<Commit1, H(T2), sign(H(T2)), Ni, T2> according to the transaction information with the execution result T2, the hash value H(T2) of the transaction information with the execution result, the signature sign(H(T2)) of the hash value of the transaction information with the execution result, and the sequence number Ni of the master node, as shown in Figure 4 , that is, the Commit1 (first submission) phase in Figure 4 .

[0134] S927, sending, using the respective consensus nodes, the first submission message to the plurality of master nodes;

[0135] S928, determining, using the plurality of master nodes, whether the first submission message sent by the first preset proportion of consensus nodes is received, if yes, verifying the first submission message, and after the verification is passed, constructing a new block according to the first submission message, and broadcasting the new block to all consensus nodes, as shown in Figure 4 , that is, the Commit2 (second submission) phase in Figure 4 .

[0136] S929. The new block is verified using the consensus nodes. Once the verification is successful, the block is confirmed to have been successfully uploaded to the blockchain.

[0137] In one optional implementation, the transaction request includes a request time. After a transaction is added, each master node executes the transaction request of the message content in sequence according to the request time. Executing the request by request time ensures the correctness of PBFT (Practical Byzantine Fault Tolerance). In addition, nodes discard requests whose request time is less than the time of the sent reply. For example, if the request time of the first transaction request is 16:06 and the request time of the second transaction request is 16:07, when the second transaction request is received, the first transaction has been processed at 16:08. At this time, the second transaction request is discarded, so that each request is completed only once.

[0138] In one alternative implementation, it further includes:

[0139] Each master node returns confirmation information to the client corresponding to the transaction request, such as... Figure 4 As shown, that is Figure 4 The Reply phase in the text.

[0140] Compared to the traditional PBFT consensus mechanism, which has a communication complexity of O(n^2), this mechanism has a communication complexity of O(n^2). 2 The consensus method of this invention has a communication count of 3(n-1)k+2(n-1)k=5kn-5k, where n represents the number of nodes and k represents the number of master nodes specified by the system. Its communication complexity is O(n), which reduces the communication complexity. When the number of nodes n is larger, the consensus communication volume of this invention will be less, the scalability will be better, and it will be more suitable for resource-constrained devices such as sensors.

[0141] like Figure 4 As shown, Figure 4 The numbers 0-9 on the left represent the nodes participating in the consensus. For example, if the number of master nodes is specified as k (a constant) based on the approximate size of the system, and there are n nodes participating in the consensus, then the communication complexity of the Pre-prepare stage is k(n-1). Therefore, the first three preparation stages are 3k(n-1), and the last two submission stages are 2k(n-1).

[0142] Example 2

[0143] Please refer to Figure 2 This embodiment of a consensus terminal based on a blockchain sensor includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the various steps of the consensus method based on a blockchain sensor in Embodiment 1.

[0144] In summary, the application provides a consensus method and terminal based on a blockchain sensor, determines a target general node connected with a blockchain sensor in a blockchain peer-to-peer network, and initiates a transaction request by using the target general node; judges whether the target general node is connected with multiple blockchain sensors, if yes, marks the transaction request as a local transaction, and completes consensus on the local transaction based on a randomly selected consensus node, if not, marks the transaction request as a non-local transaction, and completes consensus on the non-local transaction based on multiple selected master nodes; at the same time, determines a trusted node list corresponding to a general node based on a comprehensive score and an energy value, ensures the reliability of the consensus nodes in the list, reduces the possibility of a Byzantine node doing evil, and improves the security of the consensus process; by dividing the local transaction and the non-local transaction, different consensus methods are used respectively, which can effectively save the computing resources, and for the non-local transaction, multiple master nodes are used to realize consensus, which is different from the existing single master node consensus, can effectively reduce the communication complexity, and greatly improves the consensus efficiency, even if the resource-limited blockchain sensor can also participate in the blockchain consensus process.

[0145] The above is only an embodiment of the application, and does not limit the patent range of the application, and any equivalent transformation or direct or indirect application in the related technical field by using the content of the specification and drawings of the application is also included in the patent protection range of the application.

Claims

1. A consensus method based on blockchain sensors, characterized in that, Including the following steps: Identify the target general node in the blockchain peer-to-peer network that is connected to the blockchain sensor, and initiate a transaction request using the target general node; Determine whether the target general node is connected to multiple blockchain sensors. If so, mark the transaction request as a local transaction and complete consensus on the local transaction based on a randomly selected consensus node. If not, mark the transaction request as a non-local transaction and complete consensus on the non-local transaction based on multiple other selected master nodes. The consensus reached on the non-local transaction based on multiple additionally selected master nodes includes: Obtain a list of trusted nodes corresponding to the target general node, wherein the list of trusted nodes includes multiple consensus nodes; Select multiple master nodes from the plurality of consensus nodes; The non-local transaction is verified using the multiple master nodes. After successful verification, a corresponding pre-preparation message is generated based on the non-local transaction, and the pre-preparation message is broadcast to each consensus node using the multiple master nodes. The pre-prepared message is verified using the consensus nodes. After verification, a corresponding first preparation message is generated based on the pre-prepared message, and the first preparation message is sent to the multiple master nodes. The multiple master nodes determine whether the number of identical contents in all received first preparation messages exceeds a first preset ratio. If so, a corresponding second preparation message is generated based on the first preparation message, and the second preparation message is sent to each consensus node. The consensus nodes are used to verify the second preparation message. After the verification is successful, the non-local transaction is executed according to the second preparation message to generate transaction information with execution results, and a first commit message is generated according to the transaction information with execution results. The first commit message is sent to the plurality of master nodes using the respective consensus nodes; The multiple master nodes determine whether they have received the first commit message sent by the first preset proportion of consensus nodes. If so, the first commit message is verified. After successful verification, a new block is constructed based on the first commit message, and the new block is broadcast to all consensus nodes. The new block is verified using the various consensus nodes. Once the verification is successful, the block is confirmed to have been successfully uploaded to the blockchain.

2. The consensus method based on blockchain sensors according to claim 1, characterized in that, The consensus reached by a randomly selected consensus node for the local transaction includes: Obtain a list of trusted nodes corresponding to the target general node, wherein the list of trusted nodes includes multiple consensus nodes; Randomly select one consensus node from the plurality of consensus nodes, and use the consensus node to verify the local transaction; After successful verification, the local transaction is sent to the sorting node, and the sorting node is used to collect all local transactions on the target general node; The sorting node is used to construct a new block based on all local transactions on the target general node, and the new block is signed and stored.

3. The consensus method based on blockchain sensors according to claim 1, characterized in that, Before determining the target generic node connected to the blockchain sensor in the blockchain peer-to-peer network, the following steps are included: Traverse the common nodes in the blockchain peer-to-peer network; Obtain the overall score and energy value of all nodes except the general nodes traversed; The other nodes are sorted in descending order according to the comprehensive score and energy value to obtain the first set and the second set; Nodes in the first set at a second preset ratio are selected in sequence as the first subset; Nodes in the second set at a second predetermined ratio are selected as the second subset in sequence; Other nodes that exist in both the first subset and the second subset are identified as candidate consensus nodes; Select the top three preset proportion of nodes from the candidate consensus nodes as consensus nodes, and generate a list of trusted nodes corresponding to the general nodes traversed.

4. The consensus method based on blockchain sensors according to claim 1, characterized in that, The transaction request includes transaction-related information and the signature of the transaction by the sensor module corresponding to the blockchain sensor; The step of generating the corresponding pre-prepared message based on the non-local transaction includes: Based on the signature of the transaction, the transaction-related information, and the master node serial number of the sensor module corresponding to the blockchain sensor, a corresponding pre-preparation message is generated. The step of verifying the pre-prepared message using the consensus nodes, and generating a corresponding first preparation message based on the pre-prepared message after successful verification, includes: The signatures and master node sequence numbers of the transactions in the pre-prepared message are verified using the consensus nodes. After verification, a transaction set is generated based on the transactions of different master nodes. Each consensus node generates a first preparation message based on the transaction set, the hash value of the transaction set, and the signature corresponding to the hash value of the transaction set.

5. A consensus terminal based on a blockchain sensor, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it performs the following steps: Identify the target general node in the blockchain peer-to-peer network that is connected to the blockchain sensor, and initiate a transaction request using the target general node; Determine whether the target general node is connected to multiple blockchain sensors. If so, mark the transaction request as a local transaction and complete consensus on the local transaction based on a randomly selected consensus node. If not, mark the transaction request as a non-local transaction and complete consensus on the non-local transaction based on multiple other selected master nodes. The consensus reached on the non-local transaction based on multiple additionally selected master nodes includes: Obtain a list of trusted nodes corresponding to the target general node, wherein the list of trusted nodes includes multiple consensus nodes; Select multiple master nodes from the plurality of consensus nodes; The non-local transaction is verified using the multiple master nodes. After successful verification, a corresponding pre-preparation message is generated based on the non-local transaction, and the pre-preparation message is broadcast to each consensus node using the multiple master nodes. The pre-prepared message is verified using the consensus nodes. After verification, a corresponding first preparation message is generated based on the pre-prepared message, and the first preparation message is sent to the multiple master nodes. The multiple master nodes determine whether the number of identical contents in all received first preparation messages exceeds a first preset ratio. If so, a corresponding second preparation message is generated based on the first preparation message, and the second preparation message is sent to each consensus node. The consensus nodes are used to verify the second preparation message. After the verification is successful, the non-local transaction is executed according to the second preparation message to generate transaction information with execution results, and a first commit message is generated according to the transaction information with execution results. The first commit message is sent to the plurality of master nodes using the respective consensus nodes; The multiple master nodes determine whether they have received the first commit message sent by the first preset proportion of consensus nodes. If so, the first commit message is verified. After successful verification, a new block is constructed based on the first commit message, and the new block is broadcast to all consensus nodes. The new block is verified using the various consensus nodes. Once the verification is successful, the block is confirmed to have been successfully uploaded to the blockchain.

6. A consensus terminal based on a blockchain sensor according to claim 5, characterized in that, The consensus reached by a randomly selected consensus node for the local transaction includes: Obtain a list of trusted nodes corresponding to the target general node, wherein the list of trusted nodes includes multiple consensus nodes; Randomly select one consensus node from the plurality of consensus nodes, and use the consensus node to verify the local transaction; After successful verification, the local transaction is sent to the sorting node, and the sorting node is used to collect all local transactions on the target general node; The sorting node is used to construct a new block based on all local transactions on the target general node, and the new block is signed and stored.

7. A consensus terminal based on a blockchain sensor according to claim 5, characterized in that, Before determining the target generic node connected to the blockchain sensor in the blockchain peer-to-peer network, the following steps are included: Traverse the common nodes in the blockchain peer-to-peer network; Obtain the overall score and energy value of all nodes except the general nodes traversed; The other nodes are sorted in descending order according to the comprehensive score and energy value to obtain the first set and the second set; Nodes in the first set at a second preset ratio are selected in sequence as the first subset; Nodes in the second set at a second predetermined ratio are selected as the second subset in sequence; Other nodes that exist in both the first subset and the second subset are identified as candidate consensus nodes; Select the top three preset proportion of nodes from the candidate consensus nodes as consensus nodes, and generate a list of trusted nodes corresponding to the general nodes traversed.

8. A consensus terminal based on a blockchain sensor according to claim 5, characterized in that, The transaction request includes transaction-related information and the signature of the transaction by the sensor module corresponding to the blockchain sensor; The step of generating the corresponding pre-prepared message based on the non-local transaction includes: Based on the signature of the transaction, the transaction-related information, and the master node serial number of the sensor module corresponding to the blockchain sensor, a corresponding pre-preparation message is generated. The step of verifying the pre-prepared message using the consensus nodes, and generating a corresponding first preparation message based on the pre-prepared message after successful verification, includes: The signatures and master node sequence numbers of the transactions in the pre-prepared message are verified using the consensus nodes. After verification, a transaction set is generated based on the transactions of different master nodes. Each consensus node generates a first preparation message based on the transaction set, the hash value of the transaction set, and the signature corresponding to the hash value of the transaction set.

Images