CN114745140A - Urban planning field block chain consensus verification method and system based on aggregation encryption - Google Patents
Urban planning field block chain consensus verification method and system based on aggregation encryption Download PDFInfo
- Publication number
- CN114745140A CN114745140A CN202210659280.1A CN202210659280A CN114745140A CN 114745140 A CN114745140 A CN 114745140A CN 202210659280 A CN202210659280 A CN 202210659280A CN 114745140 A CN114745140 A CN 114745140A
- Authority
- CN
- China
- Prior art keywords
- node
- nodes
- participating
- trust
- consensus verification
- 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.)
- Granted
Links
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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
- H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02A—TECHNOLOGIES FOR ADAPTATION TO CLIMATE CHANGE
- Y02A30/00—Adapting or protecting infrastructure or their operation
- Y02A30/60—Planning or developing urban green infrastructure
Abstract
The invention provides a block chain consensus verification method and a block chain consensus verification system in the urban planning field based on aggregation encryption, wherein the trust relationship between an initiating node of a block chain service and each participating node is divided according to the relationship between computing nodes in the urban planning field; and dividing the process into two processing flows according to the trust degrees of the initiating node and each participating node. The invention carries out high-efficiency flow processing consensus verification on the services among the internal nodes with high trust, thereby greatly reducing the complexity of verification; for the services with high and low confidence degrees, a scheme for setting weights for processing is provided, and the aggregation requirement can be met in advance.
Description
Technical Field
The invention belongs to the technical field of block chains, and particularly relates to a block chain consensus verification method and system in the urban planning field based on aggregation encryption.
Background
The block chain is a chain formed by blocks; each block stores certain information and is connected into a chain according to the time sequence generated by each block. This chain is maintained in all servers, and as long as one server can work in the entire system, the entire blockchain is secure. These servers are referred to as nodes in the blockchain system, and the nodes provide storage space and computational support for the entire blockchain system. If the information in the block chain is to be modified, more than half of the nodes must be authenticated and the information in all the nodes must be modified, and the nodes are usually held in different hands of different subjects, so that the information in the block chain is extremely difficult to tamper with. Compared with the traditional network, the block chain has two core characteristics: firstly, data is difficult to tamper, and secondly, decentralization is performed. Based on the two characteristics, the information recorded by the block chain is more real and reliable, and the problem that people are not trusted each other can be solved.
The main role of the consensus mechanism is to enable the blockchain to achieve a consistent state in a distributed network, and in a system for distributed accounting, such as the blockchain, the problem of consistency is the most critical problem.
The practical Byzantine fault tolerance provides (n-1)/3 fault tolerance on the premise of ensuring activity and safety. On distributed computing, different computers attempt to reach a consensus through message exchange; sometimes, however, the coordinating computer or member computers on the system may be in the form of a system error and exchange erroneous messages, which may affect the final system consistency. The "Byzantine general problem" looks for possible solutions based on the number of wrong computers, but cannot find an absolute answer, and can only be used to verify the validity of a mechanism. The potential solution of the byzantine problem is as follows: consistency is a possible solution in the case of N ≧ 3F + 1. Wherein N is the total number of computers, and F is the total number of problematic computers. After information is exchanged between computers, each computer lists all the information obtained, with most of the results as a solution. The traditional block chain technology is mainly applied to application environments such as intelligent contracts, value storage, copyright verification and the like, and the common characteristics of the application environments are that the number of participating nodes is large, the trust between the participating nodes is low, and the data volume of single service is small. Therefore, such traffic must use a consensus mechanism for all nodes. Although the amount of information to be interacted is relatively large, the node has resources to support the existing consensus mechanism because the data amount of each service to be processed by the node is not large. For example, byzantine fault tolerance can solve this problem.
However, when the blockchain technology is applied in the field of urban planning, all nodes participating in processing blockchain information are joint nodes, generally double-duty nodes, and also need to undertake the original calculation work, so that the calculation resources are often insufficient; moreover, the service in the urban planning field has obvious service characteristics, and information interaction of a part of services is only realized among specific nodes, so that the method is not like the conventional block chain nodes which are completely lack of trust, and has a certain trust basis relatively. Therefore, consensus verification of block chains needs to be established by combining the characteristics of nodes in the field of urban planning.
Disclosure of Invention
The invention provides a block chain consensus verification method and system in the urban planning field based on aggregation encryption, which are used for carrying out efficient flow processing consensus verification on services among internal nodes with high trust degree, and greatly reduce the complexity of verification.
In order to achieve the purpose, the technical scheme of the invention is realized as follows:
the urban planning field block chain consensus verification method based on aggregation encryption comprises the following steps:
according to the relation among the computing nodes in the urban planning field, dividing the trust relation between the initiating node of the block chain service and each participating node;
if the trust relationships between the initiating node and each participating node are high, selecting k nodes as consensus verification nodes at random; when the consensus verification is carried out, when the number of the signature information received by the initiating node is larger than k/2, the received signatures are aggregated into an aggregated signature, and the aggregated signature is sent to the consensus verification node for verification;
if the trust relationships between the initiating node and each participating node are not all high trust relationships, all participating nodes are taken as consensus verification nodes; and when the number of the signature information received by the initiating node is more than the number of the legal signatures, aggregating the received signatures into an aggregated signature, and sending the aggregated signature to the consensus verification node for verification.
Further, the method for partitioning the trust relationship between the initiating node and each participating node comprises the following steps:
if the initiating node and the participating node belong to the same internal node in the city planning field and belong to the same department or the same subnet, the initiating node and the participating node are in a high trust relationship;
if the initiating node and the participating node belong to the internal nodes in the city planning field and belong to different departments or different sub-networks, the confidentiality level of the block chain service is considered; if the security level is low, the initiating node and the participating node are in a high trust relationship, and if the security level is high, the initiating node and the participating node are in a low trust relationship;
if the participating node is an external node, the external node is a remote node or a cloud node, the initiating node and the participating node are in a low trust relationship.
Further, the k calculation method includes:
setting the number of all participating nodes in a high trust relationship with a service node as N;
computing
；
P% is the ratio of the number of consensus verification nodes to the number of all participating nodes of a high trust relationship.
Further, the ranges of P% include: 10% < = p% < = 20%.
Further, the method for determining the number of legal signatures based on the PBFT algorithm includes:
all the participating nodes are M, M is used as the node number of the PBFT algorithm, and the signature can be completed because the malicious node number is less than (M-1)/3, so that the legal signature number is 2 x (M-1)/3+ 1.
Further, the method for determining the number of legal signatures based on the PBFT algorithm includes:
all participating nodes are M, wherein the number of high-trust nodes is N; the number of the signature information received from the high trust relationship participating nodes is t1, and the number of the signature information received from the low trust relationship nodes is t 2;
setting the weight of the high trust node to be 2 times that of the low trust node; the weight of each high trust node is 2, the weight of each low trust node is 1, and the number of weighted nodes is 2 × N +1 × (M-N) = M + N;
m + N is taken as the node number of the PBFT algorithm, and because the malicious node number is less than (M + N-1)/3, signature can be completed,
the number of legal signatures was found to be 2 x (M + N-1)/3+ 1.
The invention also provides a block chain consensus verification system in the urban planning field based on aggregation encryption, which comprises the following steps:
the trust relationship module is used for dividing the trust relationship between the initiating node of the block chain service and each participating node according to the relationship between the computing nodes in the urban planning field;
the efficient consensus verification module is used for randomly selecting k nodes as consensus verification nodes if the trust relationships between the initiating node and each participating node are high trust relationships; when the consensus verification is carried out, when the number of the signature information received by the initiating node is larger than k/2, the received signatures are aggregated into an aggregated signature, and the aggregated signature is sent to the consensus verification node for verification;
the PBFT algorithm consensus verification module is used for taking all the participating nodes as consensus verification nodes if the trust relationships between the initiating node and each participating node are not high trust relationships; and when the number of the signature information received by the initiating node is more than the number of the legal signatures, aggregating the received signatures into an aggregated signature, and sending the aggregated signature to the consensus verification node for verification.
Further, the trust relationship module comprises:
the first dividing unit is used for determining that the initiating node and the participating node are in a high trust relationship if the initiating node and the participating node belong to the same internal node in the urban planning field and the same department or the same subnet;
the second division unit considers the confidentiality level of the block chain service if the initiating node and the participating node belong to the internal nodes in the city planning field and belong to different departments or different sub-networks; if the security level is low, the initiating node and the participating node are in a high trust relationship, and if the security level is high, the initiating node and the participating node are in a low trust relationship;
and if the participating node is an external node, the external node is a remote node or a cloud node, and the initiating node and the participating node are in a low trust relationship.
Further, the PBFT algorithm consensus verification module includes:
and (3) taking M as the number of nodes of the PBFT algorithm, and finishing signature because the number of malicious nodes is less than (M-1)/3, so that the number of obtained legal signatures is 2 x (M-1)/3+ 1.
Further, the PBFT algorithm consensus verification module includes:
all participating nodes are M, wherein the number of high-trust nodes is N; the number of the signature information received from the high trust relationship participating nodes is t1, and the number of the signature information received from the low trust relationship nodes is t 2;
setting the weight of the high trust node to be 2 times of that of the low trust node; the weight of each high trust node is 2, the weight of each low trust node is 1, and the number of weighted nodes is 2 × N +1 × (M-N) = M + N;
m + N is taken as the node number of the PBFT algorithm, and because the malicious node number is less than (M + N-1)/3, signature can be completed,
the number of legal signatures was found to be 2 x (M + N-1)/3+ 1.
Compared with the prior art, the invention has the following beneficial effects:
(1) the invention sets a trust relationship and is divided into two processing flows according to the trust degrees of an initiating node and a participating node; the service between internal nodes with high trust is subjected to high-efficiency flow processing consensus verification, so that the complexity of verification is greatly reduced;
(2) for services with high and low trust degrees, the invention determines the number of legal signatures based on the PBFT algorithm, and reduces the complexity of verification;
(3) the invention also provides a scheme for setting weight to process the service with high and low trust degree, the signature information fed back by the node with high trust relation is added with weight, and the physical distance between the node with high information relation and the service initiating node is closer, so the feedback can be more timely carried out, therefore, the aggregation requirement can be satisfied in advance due to the high weight of the feedback.
Drawings
FIG. 1 is a schematic flow chart of a first embodiment of the present invention;
fig. 2 is a schematic flow chart of a second embodiment of the present invention.
Detailed Description
It should be noted that the embodiments and features of the embodiments may be combined with each other without conflict.
In order to make the objects and features of the present invention more comprehensible, embodiments accompanying the present invention are further described below. It is noted that the drawings are in greatly simplified form and employ non-precise ratios for the purpose of facilitating and distinctly aiding in the description of the patented embodiments of the invention.
For the city planning field, a computer network in the city planning field comprises a plurality of computing nodes, and the computing nodes can be divided into internal nodes and external nodes; the internal nodes comprise internal nodes which can belong to a same subnet and internal nodes which do not belong to a same subnet, or comprise internal nodes which can belong to a same functional department and internal nodes which do not belong to a same functional department; the external nodes include remote nodes and/or cloud nodes. The city planning service may be applied to multiple computing nodes in a computer network, which may be multiple computing nodes in one sub-network or functional department, multiple computing nodes in multiple sub-networks or multiple functional departments, or require the use of a remote node or a cloud node.
The invention provides a block chain consensus verification method in the urban planning field based on aggregation encryption on the characteristics of the urban planning field, and the specific application example is as follows:
the first embodiment is as follows:
the specific steps of the first embodiment are shown in fig. 1, and include:
step 1: and dividing trust relations between the service initiating node and each service participating node, wherein the trust relations are a high trust relation and a low trust relation respectively. The same group of initiating nodes and participating nodes can present different trust relationships in different services, and the specific division rule is as follows:
(1) the internal nodes of the same subnet can be set to have a high trust relationship, or the internal nodes belonging to the same functional department can be set to have a high trust relationship; because nodes in the same subnet or in a certain functional department are generally in a trusted environment, the possibility of malicious nodes is very low;
(2) if the nodes are internal nodes but do not belong to the same functional department or the same subnet, a high trust relationship can be set when a service with low security level is processed together. But when a service with high security level is processed together, the low trust relationship can be set;
(3) if the participating node is an external node, the trust level is generally lower by default and set as a low trust relationship in view of security.
Step 2: and judging whether the initiating node and all the participating nodes of the service are in a high trust relationship, if so, executing the step 3, otherwise, executing the step 9. The principle of the urban planning service is that when the internal nodes can meet the requirements, the internal nodes are used as much as possible, so that most services can be completed only by the internal nodes. Therefore, most of the traffic only needs to perform the efficient procedure of step 3.
And step 3: acquiring the number N of all participating nodes which belong to a high trust relationship with a service initiating node;
and 4, step 4: computing
(ii) a From the stationRandomly selecting N nodes with high trust relationship
The node is used as a consensus verification node. The meaning of the above formula is that the ratio of the number of the consensus verification nodes to the total number of the high trust nodes is p%, but the minimum number cannot be less than 3. The setting of p% can ensure certain verification redundancy and control verification complexity. The higher p% has high verification redundancy, but increases verification complexity; while a lower p% can control the verification complexity but can make the verification redundancy insufficient. Preferably, 10%<= p%<=20%。
And 5: after the service initiating node creates a block, the block is sent to the consensus verification node selected in the step 4 in a point-to-point mode, and after receiving the block, the consensus verification node signs the block and sends signature information to the service initiating node;
step 6: when the number of the signature information received by the service initiating node is larger than k/2, aggregating the received signatures into an aggregated signature, and sending the aggregated signature to the consensus verification node;
and 7: after the consensus verification node receives the aggregated signature, if the aggregated signature passes the verification, the block is determined to be valid, and confirmation information is broadcasted in the whole network;
and step 8: after receiving the confirmation message of the step 7, the whole network node confirms that the block is valid on the node of the whole network node, and the flow is ended;
and step 9: acquiring the number M of all participating nodes except a service initiating node in the whole network, and after the service initiating node creates a block, sending the block to all participating nodes in a whole network broadcasting mode;
step 10: after all M nodes receive the block, signing the block and sending signature information to a service initiating node;
step 11: after receiving more than 2 x (M-1)/3+1 of signature information, aggregating the received signatures into an aggregated signature and sending the aggregated signature to a consensus verification node;
the step is based on a Practical Byzantine FaultTolerance consensus algorithm, called PBFT algorithm for short, so as to reduce the network complexity during consensus. The PBFT algorithm means a practical Byzantine fault-tolerant algorithm, and is a distributed consistency algorithm which can tolerate certain Byzantine errors. The PBFT algorithm can achieve consensus in a scene where a few nodes do malicious (such as forged messages), adopts cryptographic algorithms such as signature, signature verification, Hash and the like to ensure tamper resistance, counterfeit resistance and non-repudiation in the message transmission process, optimizes predecessor work, and reduces the complexity of the Byzantine fault-tolerant algorithm from an exponential level to a polynomial level.
The algorithm can complete signature only when the number of the malicious nodes is less than (M-1)/3, so that signature can be completed only when legal signatures of more than 2 x (M-1)/3+1 are obtained;
step 12: after the consensus verification node receives the aggregated signature, if the aggregated signature passes the verification, the block is determined to be valid, and confirmation information is broadcasted in the whole network;
step 13: after receiving the acknowledgement message of step 12, the whole network node confirms that the block is valid at its own node.
Through the scheme of the first embodiment, the technical effects are as follows: in the prior art, signature information of 2 × M (M-1)/3+1 nodes generally needs to be aggregated for effective verification, and when the number of nodes is large and the block generation speed is fast, the verification amount will cause relatively serious network congestion.
Example two:
the specific steps of the second embodiment are shown in fig. 2, and include:
step 1: and dividing trust relations between the service initiating node and each service participating node, wherein the trust relations are a high trust relation and a low trust relation respectively. The same group of initiating nodes and participating nodes can present different trust relationships in different services, and the specific division rule is as follows:
(1) the internal nodes of the same subnet can be set to have a high trust relationship, or the internal nodes belonging to the same functional department can be set to have a high trust relationship; because nodes in the same subnet or in a certain functional department are generally in a trusted environment, the possibility of malicious nodes is very low;
(2) if the nodes are internal nodes but do not belong to the same functional department or the same subnet, a high trust relationship can be set when a service with low security level is processed together. But when a service with high security level is processed together, the low trust relationship can be set;
(3) if the participating node is an external node, the default is generally that the trust degree is low and the low trust relationship is set for the safety consideration.
And 2, step: and judging whether the initiating node and all the participating nodes of the service are in a high trust relationship, if so, executing the step 3, otherwise, executing the step 9. The principle of the urban planning service is that when the internal nodes can meet the requirements, the internal nodes are used as much as possible, so that most services can be completed only by the internal nodes. Therefore, most of the traffic only needs to perform the efficient procedure of step 3.
And step 3: acquiring the quantity N of all participating nodes which belong to a high trust relationship with a service initiating node;
and 4, step 4: computing
(ii) a Randomly selecting one from all N high-trust relationship nodes
The node is used as a consensus verification node. The meaning of the above formula is that the ratio p% of the number of the common identification verification nodes to the total number of the high trust nodes, but the minimum number can not be less than 3. The setting of p% can guarantee certain verification redundancy and control verification complexity. The higher p% has high verification redundancy, but increases verification complexity; while a lower p% can control the verification complexity but can make the verification redundancy insufficient. Preferably, 10 percent<= p%<=20%。
And 5: after the service initiating node creates a block, the block is sent to the consensus verification node selected in the step 4 in a point-to-point mode, and after receiving the block, the consensus verification node signs the block and sends signature information to the service initiating node;
step 6: when the number of the signature information received by the service initiating node is larger than k/2, aggregating the received signatures into an aggregated signature, and sending the aggregated signature to the consensus verification node;
and 7: after the consensus verification node receives the aggregated signature, if the aggregated signature passes the verification, the block is determined to be valid, and confirmation information is broadcasted in the whole network;
and 8: after receiving the confirmation message of step 7, the whole network node confirms that the block is valid on the node of the whole network node, and the process is ended;
and step 9: acquiring the number M of all participating nodes except a service initiating node in the whole network, and after the service initiating node establishes a block, transmitting the block to all participating nodes in a whole network broadcasting mode;
step 10: after all M nodes receive the block, signing the block and sending signature information to a service initiating node;
step 11: counting the number of the nodes to be t1 after receiving the signature information from the high trust relationship node, and counting the number of the nodes to be t2 after receiving the signature information from the low trust relationship node;
step 12: when t1 × 2+ t2> =2 × 2 (M + N-1)/3+1, aggregating the received signatures into an aggregated signature, and sending the aggregated signature to a consensus verification node;
the step is based on a Practical Byzantine FaultTolerance consensus algorithm, called PBFT algorithm for short, so as to reduce the network complexity during consensus. The PBFT algorithm means a practical Byzantine fault-tolerant algorithm, and is a distributed consistency algorithm which can tolerate certain Byzantine errors. The PBFT algorithm can achieve consensus in the scenes of few nodes doing malicious (such as forged messages), adopts cryptographic algorithms such as signature, signature verification, Hash and the like to ensure tamper resistance, counterfeit resistance and non-repudiation in the message transmission process, optimizes predecessor work, and reduces the complexity of the Byzantine fault-tolerant algorithm from exponential level to polynomial level.
The traditional PBFT algorithm can complete signature only when the number of malicious nodes is less than (M-1)/3, and therefore signature can be completed only when legal signatures of more than 2 x (M-1)/3+1 are obtained.
The step is an improvement on the basis, and different weights are set for different types of nodes, so that the nodes with high trust relationship can be endowed with higher weights. The high trust relationship node has a greater effect in the process of aggregating signatures, so that the signature efficiency can be improved.
In this step, the weight of the high trust node is set to be 2 times that of the low trust node. Therefore, the total number of nodes after weighting is M + N. M is the total number of nodes, N is the number of high trust nodes, and M includes all N. Thus, there are N high trust nodes and M-N low trust nodes. The weight of each high trust node is 2 and the weight of each low trust node is 1. Therefore, the number of weighted nodes is 2 × N + (M-N) = M + N.
2 (M + N-1)/3+1 is the minimum number of nodes, i.e. the minimum number of legitimate signatures, determined according to the PBFT algorithm.
Step 13: after the consensus verification node receives the aggregated signature, if the aggregated signature passes the verification, the block is determined to be valid, and confirmation information is broadcasted in the whole network;
step 14: after receiving the acknowledgement message of step 13, the whole network node acknowledges that the block is valid at its own node.
For the second embodiment, in addition to the technical effect described in the first embodiment, the weight can be added to the signature information fed back by the node with the high trust relationship, and because the physical distance between the node with the high information relationship and the service initiating node is often closer, the signature information can be fed back in time, and therefore, because of the high weight of the feedback, the aggregation requirement can be met in advance.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and should not be taken as limiting the scope of the present invention, which is intended to cover any modifications, equivalents, improvements, etc. within the spirit and scope of the present invention.
Claims (10)
1. The block chain consensus verification method in the urban planning field based on the aggregation encryption is characterized by comprising the following steps:
according to the relation among the computing nodes in the urban planning field, dividing the trust relation between the initiating node of the block chain service and each participating node;
if the trust relationships between the initiating node and each participating node are high, selecting k nodes as consensus verification nodes at random; when the consensus verification is carried out, when the number of the signature information received by the initiating node is larger than k/2, the received signatures are aggregated into an aggregated signature, and the aggregated signature is sent to the consensus verification node for verification;
if the trust relationships between the initiating node and each participating node are not all high trust relationships, all participating nodes are taken as consensus verification nodes; and when the number of the signature information received by the initiating node is more than the number of the legal signatures, aggregating the received signatures into an aggregated signature, and sending the aggregated signature to the consensus verification node for verification.
2. The urban planning field block chain consensus verification method based on aggregation encryption according to claim 1, wherein the method for partitioning the trust relationship between the initiating node and each participating node comprises:
if the initiating node and the participating node belong to the same internal node in the city planning field and belong to the same department or the same subnet, the initiating node and the participating node are in a high trust relationship;
if the initiating node and the participating node belong to the internal nodes of the city planning field and belong to different departments or different sub-networks, the confidentiality level of the block chain service is considered; if the security level is low, the initiating node and the participating node are in a high trust relationship, and if the security level is high, the initiating node and the participating node are in a low trust relationship;
if the participating node is an external node, and the external node refers to a remote node or a cloud node, the initiating node and the participating node are in a low trust relationship.
3. The urban planning field block chain consensus verification method based on aggregation encryption as claimed in claim 1, wherein the k calculation method comprises:
setting the number of all participating nodes in a high trust relationship with a service node as N;
calculating out
；
P% is the ratio of the number of consensus verification nodes to the number of all participating nodes of a high trust relationship.
4. The urban planning field block chain consensus verification method based on aggregation encryption as claimed in claim 3, wherein a selection range of P% comprises: 10% < = p% < = 20%.
5. The urban planning field block chain consensus verification method based on aggregate encryption according to claim 1, wherein the method for determining the number of legal signatures based on the PBFT algorithm comprises:
and (3) taking M as the number of nodes of the PBFT algorithm, and finishing signature because the number of malicious nodes is less than (M-1)/3, so that the number of obtained legal signatures is 2 x (M-1)/3+ 1.
6. The urban planning field block chain consensus verification method based on aggregation encryption as claimed in claim 1, wherein the method for determining the number of legal signatures based on the PBFT algorithm comprises:
all participating nodes are M, wherein the number of high-trust nodes is N; the number of the signature information received from the high trust relationship participating nodes is t1, and the number of the signature information received from the low trust relationship nodes is t 2;
setting the weight of the high trust node to be 2 times of that of the low trust node; the weight of each high trust node is 2, the weight of each low trust node is 1, and the number of weighted nodes is 2 × N +1 × (M-N) = M + N;
m + N is taken as the node number of the PBFT algorithm, and because the malicious node number is less than (M + N-1)/3, signature can be completed,
the number of legal signatures was found to be 2 x (M + N-1)/3+ 1.
7. A block chain consensus verification system in the urban planning field based on aggregation encryption is characterized by comprising:
the trust relationship module is used for dividing the trust relationship between the initiating node of the block chain service and each participating node according to the relationship between the computing nodes in the urban planning field;
the efficient consensus verification module is used for randomly selecting k nodes as consensus verification nodes if the trust relationships between the initiating node and each participating node are high trust relationships; when the consensus verification is carried out, when the number of the signature information received by the initiating node is larger than k/2, the received signatures are aggregated into an aggregated signature, and the aggregated signature is sent to the consensus verification node for verification;
the PBFT algorithm consensus verification module is used for taking all the participating nodes as consensus verification nodes if the trust relationships between the initiating node and each participating node are not high trust relationships; and when the number of the signature information received by the initiating node is more than the number of the legal signatures, aggregating the received signatures into an aggregated signature, and sending the aggregated signature to the consensus verification node for verification.
8. The system of claim 7, wherein the trust relationship module comprises:
the first dividing unit is used for determining that the initiating node and the participating node are in a high trust relationship if the initiating node and the participating node belong to the same internal node in the urban planning field and belong to the same department or the same subnet;
the second division unit considers the confidentiality level of the block chain service if the initiating node and the participating node belong to the internal nodes in the city planning field and belong to different departments or different sub-networks; if the security level is low, the initiating node and the participating node are in a high trust relationship, and if the security level is high, the initiating node and the participating node are in a low trust relationship;
and if the participating node is an external node, the external node is a remote node or a cloud node, and the initiating node and the participating node are in a low trust relationship.
9. The system of claim 7, wherein the PBFT algorithm consensus verification module comprises:
and (3) taking M as the number of nodes of the PBFT algorithm, and finishing signature because the number of malicious nodes is less than (M-1)/3, so that the number of obtained legal signatures is 2 x (M-1)/3+ 1.
10. The system of claim 7, wherein the PBFT algorithm consensus verification module comprises:
all participating nodes are M, wherein the number of high-trust nodes is N; the number of the signature information received from the high trust relationship participating nodes is t1, and the number of the signature information received from the low trust relationship nodes is t 2;
setting the weight of the high trust node to be 2 times of that of the low trust node; the weight of each high trust node is 2, the weight of each low trust node is 1, and the number of weighted nodes is 2 × N +1 × (M-N) = M + N;
m + N is taken as the node number of the PBFT algorithm, and because the malicious node number is less than (M + N-1)/3, signature can be completed,
the legal signature number is obtained as 2 x (M + N-1)/3+ 1.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210659280.1A CN114745140B (en) | 2022-06-13 | 2022-06-13 | Urban planning field block chain consensus verification method and system based on aggregation encryption |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210659280.1A CN114745140B (en) | 2022-06-13 | 2022-06-13 | Urban planning field block chain consensus verification method and system based on aggregation encryption |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114745140A true CN114745140A (en) | 2022-07-12 |
| CN114745140B CN114745140B (en) | 2022-08-23 |
Family
ID=82287229
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210659280.1A Active CN114745140B (en) | 2022-06-13 | 2022-06-13 | Urban planning field block chain consensus verification method and system based on aggregation encryption |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114745140B (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114760157A (en) * | 2022-06-16 | 2022-07-15 | 天津市城市规划设计研究总院有限公司 | Method and system for verifying validity of block link nodes in urban planning field |
| CN116192881A (en) * | 2023-04-27 | 2023-05-30 | 天津市城市规划设计研究总院有限公司 | Access control method and system for block chain data in urban planning field |
Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109964242A (en) * | 2018-05-25 | 2019-07-02 | 北京大学深圳研究生院 | A kind of block chain common recognition method based on trusting relationship |
| CN110247774A (en) * | 2019-06-28 | 2019-09-17 | 深圳市网心科技有限公司 | A kind of the common recognition method and relevant device of block chain data |
| CN110602117A (en) * | 2019-09-20 | 2019-12-20 | 浙江树人学院（浙江树人大学） | Vehicle networking node consistency consensus method based on block chain |
| CN111371744A (en) * | 2020-02-21 | 2020-07-03 | 重庆邮电大学 | Byzantine fault-tolerant consensus method based on distributed key |
| CN111445334A (en) * | 2020-03-30 | 2020-07-24 | 北京数字认证股份有限公司 | Aggregation signature method and device for block chain system and storage medium |
| CN111582843A (en) * | 2020-04-07 | 2020-08-25 | 浙商银行股份有限公司 | Block chain privacy transaction method based on aggregated signature |
| CN111614468A (en) * | 2020-05-24 | 2020-09-01 | 济南欣格信息科技有限公司 | Block chain consensus method and system |
| CN112689848A (en) * | 2019-06-28 | 2021-04-20 | 深圳市网心科技有限公司 | Consensus method of block chain data and related equipment |
| CN112837162A (en) * | 2021-03-12 | 2021-05-25 | 中国工商银行股份有限公司 | Data interaction method, node and system based on block chain |
| CN112948886A (en) * | 2021-03-26 | 2021-06-11 | 重庆倍来电新能源有限公司 | Method for improving data transmission security based on block chain |
| CN113055188A (en) * | 2021-03-02 | 2021-06-29 | 腾讯科技（深圳）有限公司 | Data processing method, device, equipment and storage medium |
| CN114338701A (en) * | 2021-12-29 | 2022-04-12 | 四川启睿克科技有限公司 | Block chain-based zero-trust system and access method for Internet of things |
-
2022
- 2022-06-13 CN CN202210659280.1A patent/CN114745140B/en active Active
Patent Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109964242A (en) * | 2018-05-25 | 2019-07-02 | 北京大学深圳研究生院 | A kind of block chain common recognition method based on trusting relationship |
| CN110247774A (en) * | 2019-06-28 | 2019-09-17 | 深圳市网心科技有限公司 | A kind of the common recognition method and relevant device of block chain data |
| CN112689848A (en) * | 2019-06-28 | 2021-04-20 | 深圳市网心科技有限公司 | Consensus method of block chain data and related equipment |
| CN110602117A (en) * | 2019-09-20 | 2019-12-20 | 浙江树人学院（浙江树人大学） | Vehicle networking node consistency consensus method based on block chain |
| CN111371744A (en) * | 2020-02-21 | 2020-07-03 | 重庆邮电大学 | Byzantine fault-tolerant consensus method based on distributed key |
| CN111445334A (en) * | 2020-03-30 | 2020-07-24 | 北京数字认证股份有限公司 | Aggregation signature method and device for block chain system and storage medium |
| CN111582843A (en) * | 2020-04-07 | 2020-08-25 | 浙商银行股份有限公司 | Block chain privacy transaction method based on aggregated signature |
| CN111614468A (en) * | 2020-05-24 | 2020-09-01 | 济南欣格信息科技有限公司 | Block chain consensus method and system |
| CN113055188A (en) * | 2021-03-02 | 2021-06-29 | 腾讯科技（深圳）有限公司 | Data processing method, device, equipment and storage medium |
| CN112837162A (en) * | 2021-03-12 | 2021-05-25 | 中国工商银行股份有限公司 | Data interaction method, node and system based on block chain |
| CN112948886A (en) * | 2021-03-26 | 2021-06-11 | 重庆倍来电新能源有限公司 | Method for improving data transmission security based on block chain |
| CN114338701A (en) * | 2021-12-29 | 2022-04-12 | 四川启睿克科技有限公司 | Block chain-based zero-trust system and access method for Internet of things |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114760157A (en) * | 2022-06-16 | 2022-07-15 | 天津市城市规划设计研究总院有限公司 | Method and system for verifying validity of block link nodes in urban planning field |
| CN116192881A (en) * | 2023-04-27 | 2023-05-30 | 天津市城市规划设计研究总院有限公司 | Access control method and system for block chain data in urban planning field |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114745140B (en) | 2022-08-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Cui et al. | Extensible conditional privacy protection authentication scheme for secure vehicular networks in a multi-cloud environment | |
| CN109462587B (en) | Block chain layered consensus method, block chain network system and block chain node | |
| US11411721B2 (en) | Systems and methods for selecting and utilizing a committee of validator nodes in a distributed system | |
| US20200235988A1 (en) | Changing a master node in a blockchain system | |
| KR102566892B1 (en) | Blockchain consensus method, device and system | |
| CN114745140B (en) | Urban planning field block chain consensus verification method and system based on aggregation encryption | |
| CN111147228B (en) | Ethernet IoT entity based lightweight authentication method, system and intelligent terminal | |
| CN108616596A (en) | It is adaptively known together method based on the block chain that dynamic authorization and network environment perceive | |
| Mišić et al. | Adapting PBFT for use with blockchain-enabled IoT systems | |
| US20230316273A1 (en) | Data processing method and apparatus, computer device, and storage medium | |
| JP7407925B2 (en) | Flowline friendly signature and signature verification methods, equipment and storage media | |
| CN110945831B (en) | Generation of anti-Sybil attack identities | |
| CN113328997B (en) | Alliance chain crossing system and method | |
| KR20200081533A (en) | Blockchain Consensus Method based Improved Dynamic Blind Voting for Internet of Things Environment | |
| CN113055188A (en) | Data processing method, device, equipment and storage medium | |
| CN110445795B (en) | Block chain authentication uniqueness confirmation method | |
| CN112003820A (en) | Block chain consensus optimization method based on ring signature and aggregated signature | |
| Saha et al. | The blockchain solution for the security of internet of energy and electric vehicle interface | |
| Wang et al. | A fast and secured vehicle-to-vehicle energy trading based on blockchain consensus in the internet of electric vehicles | |
| Li et al. | EdgeWatch: Collaborative investigation of data integrity at the edge based on blockchain | |
| Lahiri et al. | A trustworthy blockchain based framework for impregnable IoV in edge computing | |
| Bai et al. | A two-layer-consensus based blockchain architecture for iot | |
| CN111385096A (en) | Block chain network, signature processing method, terminal and storage medium | |
| Prabhakar et al. | TCON-A lightweight Trust-dependent Consensus framework for blockchain | |
| WO2023231558A1 (en) | Blockchain consensus method and apparatus, medium, electronic device, and program product |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |