One-transmitting and multi-receiving efficient consensus method of naming architecture block chain
By introducing the "one send and multiple collect" efficient consensus method in the blockchain, using Record Field field and BLS threshold aggregation signature technology, the problem of low consensus efficiency under the "one send and one collect" mechanism of NDN is solved, and a more efficient inter-node communication and consensus process is achieved.
Patent Information
- Application Number
- CN202510366258.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-26
- Publication Date
- 2025-06-06
- Estimated Expiration
- 2045-03-26
AI Technical Summary
In blockchain, NDN's "one send, one receive" transmission mechanism causes nodes to send subscription requests to all consensus nodes one by one, resulting in linearly increasing subscription overhead and router interest table maintenance costs, thereby reducing consensus efficiency.
The efficient consensus method of "one send and multiple receives" is introduced. By embedding Record Field fields and BLS threshold aggregation signature technology in NDN data packets, a single interest packet triggers multi-node data backhaul and performs hop-by-hop aggregation on the backhaul path to reduce the number of communication interactions between nodes.
It significantly reduces the number of communication interactions between nodes and subscription overhead, improves blockchain consensus efficiency, and avoids the problem of increasing routing loops and system complexity.
Smart Images

Figure CN120111052A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a named data network, and in particular to a "send-to-multiple-receive" efficient consensus method for a named architecture blockchain. Background Art
[0002] Blockchain is a distributed ledger technology with the characteristics of decentralization, immutability, and transparency. Due to these characteristics, blockchain has shown a wide range of application potential in many fields, such as cross-border payments in the financial field, supply chain product traceability, electronic medical record management in the medical field, intellectual property protection, etc. As blockchain technology has received more and more attention and has been widely used around the world, people's demand for blockchain performance has also increased.
[0003] As one of the hot candidates for the next generation network architecture, named data networking has the characteristics of named addressing and in-network caching. Applying NDN to blockchain technology, replacing the original P2P architecture, can bring many advantages to blockchain. First, NDN adopts a request and response mechanism based on data names. This mechanism enables blockchain nodes to use names to request consensus information on the chain in the shortest path. Compared with P2P, the message transmission path is shorter, the transmission time is shorter, and finally the efficiency of blockchain consensus can be improved. Secondly, the in-network caching mechanism of NDN allows each router in the NDN network to cache the requested data. When other nodes need the same data, the cache node can directly provide this data, reducing the transmission of duplicate data.
[0004] Although NDN, as an alternative to the underlying communication architecture of blockchain, has shown significant advantages in shortening communication paths and reducing redundant traffic, NDN's "send-receive" transmission mechanism based on the interest-driven model still faces important challenges in blockchain scenarios. In blockchains, nodes often need to synchronize multi-source consensus information. At this time, nodes need to send separate interest packets to all other consensus nodes to subscribe to this information, resulting in linearly growing subscription overhead and greatly increasing the complexity of network communication. At the same time, the routing system of ICN needs to maintain independent interest tables for each node, resulting in a sharp increase in routing storage and lookup overhead. When the scale of nodes in the blockchain expands, the consensus efficiency will drop significantly.
[0005] In view of the above problems existing in the existing NDN "send and receive" on the blockchain, the design of "send and receive multiple times" mode, that is, broadcasting an interest packet to subscribe to multiple data packets, can solve the problem. However, the mechanism of the original NDN PIT table limits NDN to "send and receive one time": when an interest in the PIT table is satisfied, the table entry will be deleted, that is, when the router receives multiple data packets with the same name, it will only forward the first data packet that arrives, and the subsequent data packets that arrive will be discarded by the router because the NDN entry is deleted and the return path cannot be found. In order to meet the "send and receive multiple times" requirement of blockchain nodes to subscribe once and recycle multiple "pushed" information, the first solution is to modify the life cycle of the PIT entry and set a long-term PIT table. The router does not delete the entry after receiving a data packet, so that subsequent data packets can continue to be returned. The second solution is to add an additional table on the basis of the original three NDN tables to enhance the reverse routing capability. The new table supports multiple forwarding of specific name prefixes. For scenarios that require one-to-many, its routing entries are recorded in the new table, and the reverse propagation path provided by the new table can achieve "send and receive multiple times".
[0006] However, both of these two implementation methods have some defects. For the first type of solution, it is easy to form a routing loop in the network after modifying the PIT entry time, generating abnormal traffic and causing congestion in the network. For the second type of solution, the introduction of a new table will undoubtedly increase the overall complexity of the system and increase the cost of design, implementation and maintenance. Therefore, a more efficient and reliable solution is still needed to avoid routing loops and reduce the burden on the system. Summary of the invention
[0007] Traditional NDN is based on a "send-and-receive" interest packet-driven mechanism, which has a significant efficiency bottleneck in scenarios where blockchain nodes need to synchronize multi-source consensus messages: the receiving node needs to send subscription requests to all consensus nodes one by one, resulting in linearly growing subscription overhead and router interest table maintenance costs.
[0008] In order to solve the problems existing in the prior art, the present invention innovatively introduces the "one send, multiple receive" aggregate broadcast transmission paradigm on the blockchain of the NDN architecture, so that a single interest packet can trigger multi-node data backhaul. By embedding the Record Field field that supports dynamic group management in the existing NDN data packet (using one-hot encoding to identify the set of nodes participating in the consensus), combined with the BLS threshold aggregation signature technology to support the signature verification compatibility when some nodes participate in the consensus, the hop-by-hop aggregation of data packets on the backhaul path is realized.
[0009] In order to achieve the above-mentioned invention object, the present invention proposes a "one send, multiple receive" efficient consensus method for a naming architecture blockchain, comprising the following steps:
[0010] S1, using NDN to build a blockchain transmission network to support communication services between multiple nodes of the blockchain;
[0011] S2, blockchain initialization phase: configure the public parameters of the BLS threshold aggregate signature for the blockchain, and configure the key of the BLS threshold aggregate signature for each node;
[0012] S3, user transaction stage. When a user sends a transaction request, any node in the blockchain broadcasts an interest packet to start the consensus process after receiving the user's transaction request. The node that starts the consensus process is defined as the master node in this process, and the other nodes in the blockchain are defined as slave nodes in this process.
[0013] S4, after receiving the interest packet from the master node, the slave node participating in the consensus in the blockchain replies with a consensus data packet as a response. The reply data packet is signed with a BLS threshold aggregate signature.
[0014] S5: The consensus data packet replied by the slave node is aggregated hop by hop at each router on the return path, including data packet content aggregation and signature aggregation. Finally, the master node will only receive one aggregated consensus data packet, which is “one send and one receive”.
[0015] S6: After receiving the aggregated consensus data packet, the master node extracts the aggregate signature for verification to determine whether the number of slave nodes participating in the signature meets the threshold required for consensus confirmation, thereby completing the consensus process.
[0016] Furthermore, in the above step S1, NDN constructs the blockchain including the following contents:
[0017] (1) Use NDN routers to replace IP routers to build a blockchain transmission network;
[0018] (2) Blockchain users: configure the NDN protocol stack to facilitate access to the NDN network;
[0019] (3) The naming convention (Name field) followed by interest packets and data packets used for blockchain business communications in the NDN network is: / blockchain name / consensus method / message type / participating node.
[0020] Furthermore, the public parameters of the BLS threshold aggregate signature in the above step S2 and the BLS threshold aggregate signature key settings of each node initialization configuration include:
[0021] (1) The public parameters of the BLS threshold aggregation signature include G 1 ,G 2 ,G T ,e,g 1 ,g 2 ,p,q,H 0,H 1 , where G 1 ,G 2 ,G T are three additive cyclic groups with the same prime number p, G 1 and G 2 The generators are g 1 ,g 2 , where g 1 ,g 2 By G 1 and G 2 Determined when generated, G 1 and G 2 An element inside, and G 1 ,G 2 ,G T There exists a bilinear mapping e:G 1 ×G 2 →G T ;H 0 and H 1 are two hash functions, defined as: H 0 :{0,1} * →G 1 (Any binary string is mapped to G 1 group element), H 1 :{0,1} * →Z q (any binary string is mapped to an element of a q-order integer cyclic group), Zq is a q-order integer cyclic group, p and q are two large prime numbers, and the above parameters are generated by a key generation mechanism and then made public.
[0022] (2) BLS threshold aggregate signature key setting
[0023] Based on the public parameter G 1 ,G 2 ,G T ,e,g 1 ,g 2 ,p,q,H 0 ,H 1 Each node i in the blockchain generates its own public key P i , private key sk i , member key MK i , all nodes hold the same aggregate public key, defined as P, and the calculation process is as follows:
[0024] Node public and private key calculation: Node i starts from Z q Select a random number as your private key sk i ∈Z q , the public key P of node i i Calculated as: P i =ski *g 1 ;
[0025] Aggregate public key P calculation: Node i generates its own aggregate public key aggregation coefficient a i =H 1 (P i ,(P 1 ,P 2 ...P n )), and then through the public key P i and the aggregation coefficient a of the aggregate public key i The intra-network exchange generates the aggregated public key P:
[0026]
[0027] Member Key MK i Calculation: Each node i uses the private key sk i Aggregation coefficient a for aggregate public key i Signatures are then aggregated to obtain the member key MK i :
[0028] MK i =(a 1 *sk 1 )*H 0 (P,i)+(a 2 *sk 2 )*H 0 (P,i)+…+(a n *sk n )*H 0 (P,i)
[0029] Member Key MK i The function is to verify whether the member i is a real consensus node, which can be verified by the following formula:
[0030] e(g 2 ,MK i )=e(P,H 0 (p,i)).
[0031] Furthermore, in the above step S4, after receiving the interest packet from the master node, the following operations are performed:
[0032] S4.1 constructs a special data packet Data Packet containing a Record Field field, which records its own node number in the form of a bit mask. The field is encoded using one-hot encoding to ensure uniqueness.
[0033] S4.2 Each consensus slave node generates a BLS threshold aggregate signature and embeds it into the Signature field of the data packet, and returns it to the master node. The calculation process is as follows:
[0034] sk 1 ,sk 2 ,...sk i is the private key from node 1 to node m, MK 1 ,MK 2 ,...MK i is the member key from node 1 to node m, P is the aggregate public key, H 0 :{0,1} * →G 1 is a hash function, Data is the Data field of the data packet containing the consensus confirmation message. If there are m nodes participating in the consensus, the consensus slave nodes use their own private keys sk i ,sk 2 ,...sk i Signing the contents of the Data field of the data packet will result in the following signature Sig 1 、Sig 2 …Sig m :
[0035]
[0036] S4.3 The slave node constructs a data packet and returns it to the master node. The data packet mainly contains the following contents: the Record Field field records the slave node number, the Data field records the consensus confirmation message of the slave node, and the Signature field records the slave node's signature on the Data.
[0037] Furthermore, the hop-by-hop aggregation in the above step S5 includes the following steps:
[0038] Set a waiting window time for the NDN router. The NDN router waits for the return data packet to arrive within the waiting window time. If all interfaces corresponding to the entry of the data packet name in the forwarding information base (FIB) have returned data packets, the data packets returned by these different interfaces are immediately aggregated. If only some FIB interfaces return data packets after the window time has expired, the data packets received within the window time are aggregated. For the aggregated data packet, only the original data in the Data field of the first node data packet is retained. The Record Field field records the numbers of all slave nodes participating in this aggregation. The Signature field is updated to the aggregated signature S′.
[0039] The calculation method of the aggregate signature S′ is as follows:
[0040] S′=Sig1 +Sig 2 +…+Sig m
[0041] After the NDN router completes the data packet aggregation operation, it will return the aggregated packet. If other NDN routers on the return path receive multiple aggregated packets, they can aggregate the multiple aggregated data packets again, and so on. Finally, these data packets are aggregated into one and arrive at the master node.
[0042] Furthermore, the verification and consensus confirmation in step S6 above includes the following steps:
[0043] S6.1 After receiving the aggregation package, the master node extracts the numbers of the m slave nodes participating in the aggregation from the Record Field of the aggregation package, determines whether the number of aggregation packages meets the requirements, and calculates the sub-aggregation public key P′ constructed by the participants according to the numbers:
[0044] P′=P 1 +P 2 +P 3 +…+P m
[0045] Among them, P 1 ,P 2 ,…P m is the public key of nodes 1 to m, and P′ is the partial aggregate public key;
[0046] S6.2 extracts the partial aggregate signature S′ from the Signature field of the aggregate packet and calculates the following formula to verify the signature:
[0047] e(g 2 ,S′)=e(P′,H 0 (P,Data))*e(P′,H 0 (P,1)+H 0 (P,2)+…+H 0 (P,m)
[0048] Where P′ is the partial aggregate public key, P is the aggregate public key, and H 0 :{0,1} * →G 1 It is a hash function, and Data is the content of the Data field of the aggregated data packet, which contains the consensus confirmation message.
[0049] S6.3 After the master node verifies the legitimacy of the partial aggregate signature S′, it confirms that m slave nodes have completed the consensus, and then broadcasts the final consensus result to the entire network.
[0050] Furthermore, the above consensus data packet has a special structure that can be aggregated along the path of consensus message transmission.
[0051] Packet structure design: Based on the Name, Data, SignatureInfo and Signature fields of the NDN standard data packet, a new Record Field field is added (the structure is shown below). This field uses a bit mask to sequentially record the numbers of all slave nodes participating in this aggregation. Each bit corresponds to a unique node ID. By setting 1 to mark valid participants, lightweight node identification is achieved.
[0052]
[0053] Let i represent the number of each node and n represent the total number of nodes. The RecordField field of the data packet generated by node i is counted as Record i , which is calculated as:
[0054] Record i =2 i
[0055] Then record i The calculation result is converted into binary and written into the Record Field.
[0056] Dynamic aggregation mechanism: When multiple data packets arrive at the router, the router supports aggregating the signatures of these multiple data packets and aggregating the Record Field through an XOR operation to retain the number of historical nodes.
[0057] The beneficial effects of the present invention are as follows:
[0058] The blockchain data transmission paradigm is reconstructed through the architectural design of a single interest packet triggering multi-source data aggregation. The sender only needs to broadcast a single interest packet to trigger the distributed data response of all nodes in the network. Then, during the data return process, the routers along the way automatically aggregate these messages and finally output a unique aggregated data packet. This mechanism significantly reduces the number of communication interactions between nodes and the linear overhead generated by subscriptions one by one, and can effectively solve the performance bottleneck caused by high-frequency communication between nodes in traditional consensus algorithms (such as PBFT). BRIEF DESCRIPTION OF THE DRAWINGS
[0059] Figure 1 The present invention is a flow chart of the method.
[0060] Figure 2 This is the "one send, multiple receive" mode of the present invention.
[0061] Figure 3 It is a data packet structure design diagram of the present invention.
[0062] Figure 4It is a schematic diagram of the system architecture of a specific embodiment of the present invention.
[0063] Figure 5 The figure is a schematic diagram of Record Field aggregation according to a specific embodiment of the present invention. DETAILED DESCRIPTION
[0064] The present invention is further described below in conjunction with the accompanying drawings and specific implementation cases. It should be pointed out that the technical solution and design principle of the present invention are described in detail below only with a preferred technical solution, but the protection scope of the present invention is not limited to this.
[0065] The embodiments are preferred implementations of the present invention, but the present invention is not limited to the above-mentioned implementations. Any obvious improvements, substitutions or modifications that can be made by those skilled in the art without departing from the essential content of the present invention belong to the protection scope of the present invention.
[0066] like Figure 1 The "one send, multiple receive" model shown in the figure constructs a blockchain consensus method, including the following steps:
[0067] S1, using NDN to build a blockchain transmission network to support communication services between multiple nodes of the blockchain;
[0068] S2, blockchain initialization phase: configure the public parameters of the BLS threshold aggregate signature for the blockchain, and configure the key of the BLS threshold aggregate signature for each node;
[0069] S3, user transaction stage. When a user sends a transaction request, any node in the blockchain broadcasts an interest packet to start the consensus process after receiving the user's transaction request. The node that starts the consensus process is defined as the master node in this process, and the other nodes in the blockchain are defined as slave nodes in this process.
[0070] S4, after receiving the interest packet from the master node, the slave node participating in the consensus in the blockchain replies with a consensus data packet as a response. The reply data packet is signed with a BLS threshold aggregate signature.
[0071] S5, such as Figure 2 As shown in the figure, the consensus data packet replied by the slave node is aggregated hop by hop at each router on the return path, including data packet content aggregation and signature aggregation. Finally, the master node will only receive one aggregated consensus data packet, which is "one send and one receive".
[0072] S6: After receiving the aggregated consensus data packet, the master node extracts the aggregate signature for verification to determine whether the number of slave nodes participating in the signature meets the threshold required for consensus confirmation, thereby completing the consensus process.
[0073] As a preferred embodiment of the present invention, the NDN blockchain construction in step S1 includes the following contents:
[0074] (1) Use NDN routers to replace IP routers to build a blockchain transmission network;
[0075] (2) Blockchain users: configure the NDN protocol stack to facilitate access to the NDN network;
[0076] (3) The naming convention (Name field) followed by interest packets and data packets used for blockchain business communications in the NDN network is: / blockchain name / consensus method / message type / participating node.
[0077] As a preferred embodiment of the present invention, the public parameters of the BLS threshold aggregate signature in step S2 and the BLS threshold aggregate signature key setting of each node initialization configuration include:
[0078] (1) The public parameters of the BLS threshold aggregation signature include G 1 ,G 2 ,G T ,e,g 1 ,g 2 ,p,q,H 0 ,H 1 , where G 1 ,G 2 ,G T are three additive cyclic groups with the same prime number p, G 1 and G 2 The generators are g 1 ,g 2 , where g 1 ,g 2 By G 1 and G 2 Determined when generated, G 1 and G 2 An element inside, and G 1 ,G 2 ,G T There exists a bilinear mapping e:G 1 ×G 2 →G T ;H 0 and H 1 are two hash functions, defined as: H 0 :{0,1} * →G 1 (Any binary string is mapped to G 1 group element), H 1 :{0,1} * →Z q (any binary string is mapped to an element of the q-order integer cyclic group), Zq It is a q-order integer cyclic group, p and q are two large prime numbers, and the above parameters are generated by the key generation mechanism and then made public.
[0079] (2) BLS threshold aggregate signature key setting
[0080] Based on the public parameter G 1 ,G 2 ,G T ,e,g 1 ,g 2 ,p,q,H 0 ,H 1 Each node i in the blockchain generates its own public key P i , private key sk i , member key MK i , all nodes hold the same aggregate public key, defined as P, and the calculation process is as follows:
[0081] Node public and private key calculation: Node i starts from Z q Select a random number as your private key sk i ∈Z q , the public key P of node i i Calculated as: P i =sk i *g 1 ;
[0082] Aggregate public key P calculation: Node i generates its own aggregate public key aggregation coefficient a i =H 1 (P i ,(P 1 ,P 2 ...P n )), and then through the public key P i and the aggregation coefficient a of the aggregate public key i The intra-network exchange generates the aggregated public key P:
[0083]
[0084] Member Key MK i Calculation: Each node i uses the private key sk i Aggregation coefficient a for aggregate public key i Signatures are then aggregated to obtain the member key MK i :
[0085] MK i =(a 1 *sk 1 )*H 0 (P,i)+(a 2 *sk 2 )*H0 (P,i)+…+(a n *sk n )*H 0 (P,i)
[0086] Member Key MK i The function is to verify whether the member i is a real consensus node, which can be verified by the following formula:
[0087] e(g 2 ,MK i )=e(P,H 0 (p,i)).
[0088] As a preferred embodiment of the present invention, after receiving the interest packet from the master node in S4, the following operations are performed:
[0089] S4.1 constructs a special data packet Data Packet containing a Record Field field, which records its own node number in the form of a bit mask. The field is encoded using one-hot encoding to ensure uniqueness.
[0090] S4.2 Each consensus slave node generates a BLS threshold aggregate signature and embeds it into the Signature field of the data packet, and returns it to the master node. The calculation process is as follows:
[0091] sk 1 ,sk 2 ,...sk i is the private key from node 1 to node m, MK 1 ,MK 2 ,...MK i is the member key from node 1 to node m, P is the aggregate public key, H 0 :{0,1} * →G 1 is a hash function, Data is the Data field of the data packet containing the consensus confirmation message. If there are m nodes participating in the consensus, the consensus slave nodes use their own private keys sk i ,sk 2 ,…sk i Signing the contents of the Data field of the data packet will result in the following signature Sig 1 、Sig 2 ...Sig m :
[0092]
[0093] S4.3 The slave node constructs a data packet and returns it to the master node. The data packet mainly contains the following contents: the Record Field field records the slave node number, the Data field records the consensus confirmation message of the slave node, and the Signature field records the slave node's signature on the Data.
[0094] As a preferred embodiment of the present invention, the hop-by-hop aggregation in step S5 includes the following steps:
[0095] Set a waiting window time for the NDN router. The NDN router waits for the return data packet to arrive within the waiting window time. If all FIB interfaces return data packets, the data packets returned by these different interfaces are aggregated immediately. If only some FIB interfaces return data packets after the window time, the data packets received within the window time are aggregated. After the aggregation, only the original data of the Data field of the first node data packet is retained. The Record Field field records the numbers of all slave nodes participating in this aggregation. The Signature field is updated to the aggregated signature S′.
[0096] The calculation method of the aggregate signature S′ is as follows:
[0097] S′=Sig 1 +Sig 2 +…+Sig m
[0098] After the NDN router completes the data packet aggregation operation, it will return the aggregated packet. If other NDN routers on the return path receive multiple aggregated packets, they can aggregate the multiple aggregated data packets again, and so on. Finally, these data packets are aggregated into one and arrive at the master node.
[0099] As a preferred embodiment of the present invention, step S6 verification and consensus confirmation includes the following steps:
[0100] S6.1 After receiving the aggregation package, the master node extracts the numbers of the m slave nodes participating in the aggregation from the Record Field of the aggregation package, determines whether the number of aggregation packages meets the requirements, and calculates the sub-aggregation public key P′ constructed by the participants according to the numbers:
[0101] P′=P 1 +P 2 +P 3 +…+P m
[0102] Among them, P 1 ,P 2 ,…P m is the public key of the slave nodes numbered 1 to m, and P′ is the partial aggregate public key;
[0103] S6.2 extracts the partial aggregate signature S′ from the Signature field of the aggregate packet and calculates the following formula to verify the signature:
[0104] e(g 2 ,S′)=e(P′,H 0 (P,Data))*e(P′,H 0 (P,1)+H 0 (P,2)+…+H 0 (P,m)
[0105] Where P′ is the partial aggregate public key, P is the aggregate public key, and H 0 :{0,1} * →G 1 It is a hash function, and Data is the content of the Data field of the aggregated data packet, which contains the consensus confirmation message.
[0106] S6.3 After the master node verifies the legitimacy of the partial aggregate signature S′, it confirms that m slave nodes have completed the consensus, and then broadcasts the final consensus result to the entire network.
[0107] The consensus data packet of the present invention has the following special structure, which can be aggregated along the path of consensus message transmission.
[0108] Package structure design: Figure 3 As shown in the figure, based on the Name, Data, SignatureInfo and Signature fields of the NDN standard data packet, a new Record Field field is added. This field uses a bit mask to sequentially record the numbers of all slave nodes participating in this aggregation. Each bit corresponds to a unique node ID. By setting 1 to mark valid participants, lightweight node identification is achieved.
[0109] Let i represent the number of each node and n represent the total number of nodes. The RecordField field of the data packet generated by node i is counted as Record i , which is calculated as:
[0110] Record i =2 i
[0111] Then record i The calculation result is converted into binary and written into the Record Field.
[0112] Dynamic aggregation mechanism: When multiple data packets arrive at the router, the router supports aggregating the signatures of these multiple data packets and aggregating the Record Field field through XOR operation, retaining the number of historical nodes. The aggregation process of the Record Field field is as follows: Figure 5 shown.
[0113] The Record Field is designed to have the following uses:
[0114] (1) After receiving the aggregation packet, the master node identifies the number of aggregated data packets based on the number of "1"s in the Record Field in the aggregation packet, thereby identifying whether the number of consensus participating slave nodes meets the requirements.
[0115] (2) The master node can identify which nodes have participated in the consensus based on the position of the Record Field “1” in the aggregation packet, which facilitates the subsequent verification of the BLS threshold aggregation signature.
[0116] The technical solution of the present invention is described in detail below with a specific embodiment of the present invention. Figure 4 As shown, the system architecture includes a user node User, three blockchain nodes Node1, Node2, and Node3, and an NDN router, where Node3 is the master node and Node1 and Node2 are slave nodes. In a specific embodiment of the present invention, the user node sends a transaction request to the master node (Node 3), and Node 3 broadcasts an interest packet containing the transaction request. The interest packet is forwarded to each blockchain node through the NDN router, and the blockchain node returns a data packet. Since the blockchain has the characteristic of consistency in the transmission of messages on the chain during consensus, the same data is aggregated along the path of consensus message propagation, and finally "one send and multiple receive" is converted to "one send and one receive". (1) Parameter initialization phase:
[0117] Select SS512 as G 1 and G 2 Group elliptic curve type, group order q = 8780710799663312522437781984754049815806883199414208211028653399266475630880222957078625179422662221423155858769582317459277713367317481324925129998224791
[0118] Generator g 1=[677097288547602675081280648378609567508559764927645867232901282392759047194417938063292693668171181584527490462512171534755838593585873813635135283073746 3,830101697005469760960889646694389852608839075649927702221668343304011287748022948797271086480337431376668317760159035713338895115890100812418755120863968]
[0119] g 2 =[479569593337518471780706337371656803535810298645162455463986487245293906892954014160339995937468099374540344450911524689279752297754410260043900177078477 ,3354239225679180783384021030797770782235550568381385668774648479627901898839355943103373434949483940107186453783537698639160947061719757760054986201611249]
[0120] In this stage, each node in the blockchain generates its own public key, private key, aggregate public key, and member key. For blockchain nodes Node1, Node2, and Node3, i=1, i=2, and i=3 are used to represent them, namely, Node1, Node2, and Node3. Each node generates its own public key, private key, aggregate public key, and member key. q Select a random number as the private key. The private key of node 1 is
[0121] sk 1 =300975048882706705366219051163447934887287375423
[0122] The private key of node 2 is
[0123] sk 2=295981573471165232135588872709878289553217734960
[0124] The private key of node 3 is
[0125] sk 3 =685536739773921285600040428232715971597362689244
[0126] Node public and private key calculation: Node i starts from Z q Select a random number as your private key sk i ∈Z q , the public key P of node i i Calculated as: P i =sk i *g 2
[0127] So the public key of node 1
[0128] P 1 =[3438329697561392519408529006157428679988816566294629660789183557553194183798338081473645774215739845930915129949960030413958314033595444075290276105008993 ,8780093122663770446263848193575310659866966079582790137455039700889266605320832464751142791934029383014984077100827683472975481732058803131170833596556595]
[0129] Node 2's public key
[0130] P 2=[513423527750268296807131121550033939724855655717863533884071443851503815796088918166118673769497545716912163001657778860559849074572298160598544358768170 ,5026624279950704727939381147935607225799480852589372492874408077047376738536946296513222278852442797362769173084074062655194513778442479821963500828924810]
[0131] Node 3's public key
[0132] P 3 =[4977739083858898426138182797410343867378943327787140097403366087728817455848929131091350087382160429916069554477633238969046996406605015628268023508692234 ,2087132263988365861758787888792690182561028780787748797148720503117182352455289625250354373829245320553212668881842614099250943026032112675942519755057093]
[0133] Next, calculate the aggregate public key P. For nodes 1, 2, and 3, due to their own aggregate public key aggregation coefficient a i =H 1 (P i ,(P 1 ,P 2 ...P n )), and then through the public key P i and the aggregation coefficient a of the aggregate public key i The intra-network exchange generates the aggregated public key P:
[0134] P=[333927002360496930085624697163934381529730364195518722851368274167814586242 772892496827372526125079493747352469599027119274249140013420224588264546937791 5,8173890265720692841339718165033668431731949486989121378101926182690810182674128930683718094330945037204257653353871309696074173774894006828283260726940017]
[0135] Then calculate the member key MK i , for node 1, we can get
[0136] MK 1 =[2097161551085839573924818842092324323099250198715134909729352146639829985404237982781482509919068641396512843830502444032350969291790375212225389127902664 ,8458042985431576141932992653407116926241586470181718625487346347228088013532271843823132868695860552644729941919313064673384143290293169591438877642448041]
[0137] For node 2, we have
[0138] MK 2=[20605852103124806477939627365795001960571181481172648086720259605468919733818364193135510978908381569968134934907654010134467758394389143136332432054831 9,80905794793616085798249099089811756627825835237717304363246693894816978188362888152424144776860400361543666249275158805841890358323206182823139797307011]
[0139] (2) Master Node Broadcast Triggering Phase
[0140] The user sends a transaction request to the master node Node3. After receiving the user's transaction request, the master node Node3 broadcasts an NDN interest packet to the consensus slave nodes Node1 and Node2 in the entire network to start the consensus process.
[0141] (3) Slave node response phase: After receiving the interest packet from the master node, the slave node performs the following operations:
[0142] ① Construct a special data packet containing a Record Field field, which records its own node number in the form of a bitmask (using one-hot encoding to ensure uniqueness);
[0143] Node 1 is numbered 1: Record Field = 00000010
[0144] Node 2 is numbered 2: Record Field = 00000100
[0145] ②Nodes Node1 and Node2 participating in the consensus use their respective private keys sk i ,sk 2 Signing the contents of the Data field of the data packet will result in the following signature Sig 1 、Sig 2 :
[0146] Sig 1=[4090584062661854543335536934088420549398964062560468566439490136008382434212619520322726449314049929275898128977803474920553760353803174952368889682843103 ,8608933460434058626498781852263052461016432472972132177819717735155780721825506729118702574241356955719267714063267976593277208531690327682816682585151067]
[0147] Sig 2 =[5279166701528347011386759358651957266693448965531772063546528049156234128473582904869380412023575174534369710223042563261662359052318548696184347134678433 ,2940390334543967863024180771702752677078260859137883450334041776144836380584262996313694746173986523859221953146928637230071284966042400479856213129155537]
[0148] (4) Hop-by-hop aggregation stage:
[0149] After receiving the data packets from Node1 and Node2, the NDN router performs an aggregation operation, retains the original Data field content of the first data packet, and adds the signature Sig of the data packets from Node1 and Node2 to the 1 ,Sig 2 Accumulate and generate partial aggregate signature S′:
[0150] S′=[64268585589085359468291186408682072953229925912915174058072311290476135090 7158469034857144159267350451320333260544756978151205427650547160804546986273648 9,6529877134520047918567573184904407271352709346411313717461769944131831159389973872587221031952278435334981277576033334433671490344852960845194061040609900]
[0151] The Record Field fields of each data packet are combined through XOR operation to form a complete participant bitmap. Figure 5 As shown, after aggregating the data packets of nodes 1 and 62, calculate 2 1 +2 2 The Record Field of the aggregated package is obtained as 00000110.
[0152] (5) Verification and consensus confirmation:
[0153] After receiving the aggregation package, the master node extracts the participating node numbers from the Record Field 00000110 of the aggregation package, which are node 1 and node 2. The number meets the requirement, and then calculates the partial aggregation public key P′:
[0154] P′=[60402139402276559039999900007349730311013189748241608002521860993827795657 5644304194763769635448599542211658849964638522878904305408853673635432696908505 3,3791969129224302595632469443007691478885055913061624467450186849770994985403608107580807968396717880914686759291027186698042286201933637030193615958168135]
[0155] Then calculate whether the following equation holds true to verify the signature S′ in the aggregate package:
[0156] e(g 2 ,S′)=e(P′,H 0 (P,Data))*e(P′,H 0 (P,1)+H 0 (P,2))
[0157] After the master node verifies the legitimacy of the partial aggregate signature S′, it confirms that two slave nodes have completed the consensus, and then broadcasts the final consensus result to the slave nodes and users.
[0158] In the above specific implementation case, the present invention has the following beneficial effects: the master node Node3 can receive the data packets of Node1 and Node2 by sending an interest packet request. By adopting the packet aggregation technology on the consensus message transmission path, the original "one send and multiple receive" communication mode is successfully optimized to the "one send and one receive" mode, and the identity verification problem of the aggregated group is solved by adopting the aggregate signature. Compared with the existing NDN architecture blockchain, this method can significantly reduce the number of communication times of nodes on the chain, reduce the communication complexity and network bandwidth of the blockchain.
Claims
1. An efficient consensus method of "send one and receive multiple" for a naming architecture blockchain, characterized in that: The steps include: S1, using NDN to build a blockchain transmission network to support communication services between multiple nodes of the blockchain; S2, blockchain initialization phase: configure the public parameters of the BLS threshold aggregate signature for the blockchain, and configure the key of the BLS threshold aggregate signature for each node; S3, user transaction stage. When a user sends a transaction request, any node in the blockchain broadcasts an interest packet to start the consensus process after receiving the user's transaction request. The node that starts the consensus process is defined as the master node in this process, and the other nodes in the blockchain are defined as slave nodes in this process. S4, after receiving the interest packet from the master node, the slave node participating in the consensus in the blockchain replies with a consensus data packet as a response. The reply data packet is signed using the BLS threshold aggregate signature; S5: The consensus data packet replied by the slave node is aggregated hop by hop at each router on the return path, including data packet content aggregation and signature aggregation. Finally, the master node will only receive one aggregated consensus data packet, which is "one send and one receive". S6: After receiving the aggregated consensus data packet, the master node extracts the aggregate signature for verification to determine whether the number of slave nodes participating in the signature meets the threshold required for consensus confirmation, thereby completing the consensus process.
2. The "one send, multiple receive" efficient consensus method for a naming architecture blockchain as claimed in claim 1, characterized in that: The NDN blockchain construction in S1 includes the following contents: (1) Use NDN routers to replace IP routers to build a blockchain transmission network; (2) Blockchain users: configure the NDN protocol stack to facilitate access to the NDN network; (3) The naming convention followed by interest packets and data packets used for blockchain business communications in the NDN network is: / blockchain name / consensus method / message type / participating node.
3. The "one send, multiple receive" efficient consensus method for a naming architecture blockchain as claimed in claim 1, characterized in that: The public parameters of the BLS threshold aggregate signature in S2 and the BLS threshold aggregate signature key settings for each node initialization configuration include: (1) The public parameters of the BLS threshold aggregation signature include G1, G2, G T ,e,g1,g2,p,q,H0,H1, where G1,G2,G T are three additive cyclic groups with the same prime number p. The generators of G1 and G2 are g1 and g2 respectively, where g1 and g2 are determined when G1 and G2 are generated and are an element inside G1 and G2. T There exists a bilinear mapping e:G1×G2→G T ; H0 and H1 are two hash functions, defined as: H0:{0,1} * →G1, any binary string is mapped to a G1 group element, H1:{0,1} * →Z q , any binary string is mapped to an element of the q-order integer cyclic group, Z q is a q-order integer cyclic group, p and q are two large prime numbers, and the above parameters are generated by the key generation mechanism and then made public; (2) BLS threshold aggregate signature key setting Based on the public parameters G1, G2, G T ,e,g1,g2,p,q,H0,H1Each node i in the blockchain generates its own public key P i , private key sk i , member key MK i , all nodes hold the same aggregate public key, defined as P, and the calculation process is as follows: Node public and private key calculation: Node i starts from Z q Select a random number as your private key sk i ∈Z q , the public key P of node i i Calculated as: P i =sk i *g1; Aggregate public key P calculation: Node i generates its own aggregate public key aggregation coefficient a i =H1(P i ,(P1,P2…P n )), and then through the public key P i and the aggregation coefficient a of the aggregate public key i The intra-network exchange generates the aggregated public key P: Member Key MK i Calculation: Each node i uses the private key sk i Aggregation coefficient a for aggregate public key i Signatures are then aggregated to obtain the member key MK i : <h2 style=";text-align:left;direction:ltr">MK<h2 style=";text-align:left;direction:ltr"> i <h2 style=";text-align:left;direction:ltr"> (a1*sk1)*H0(P,i)+(a2*sk2)*H0(P,i)+…+(a<h2 style=";text-align:left;direction:ltr"> n <h2 style=";text-align:left;direction:ltr"> *sk<h2 style=";text-align:left;direction:ltr"> n <h2 style=";text-align:left;direction:ltr"> )*H0(P,i) Member Key MK i The function is to verify whether the member i is a real consensus node, which can be verified by the following formula: e(g2,MK i )=e(P,H0(p,i))。 4. The "one send, multiple receive" efficient consensus method for a naming architecture blockchain as claimed in claim 1 is further characterized in that: After receiving the interest packet from the master node in S4, the following operations are performed: S4.1 constructs a special data packet Data Packet containing a Record Field field, which records its own node number in the form of a bit mask. The field is encoded using one-hot encoding to ensure uniqueness. S4.2 Each consensus slave node generates a BLS threshold aggregate signature and embeds it into the Signature field of the data packet, and returns it to the master node. The calculation process is as follows: sk1,sk2,…sk i It is the private key of node 1 to node m, MK1, MK2, ...MK i is the member key from node 1 to node m, P is the aggregate public key, H0:{0,1} * →G1 is a hash function, Data is the data field of the data packet containing the consensus confirmation message; if there are m nodes participating in the consensus, the consensus slave nodes use their own private keys sk i ,sk2,...sk i Signing the contents of the Data field of the data packet will result in the following signatures Sig1, Sig2…Sig m : S4.3 The slave node constructs a data packet and returns it to the master node. The data packet mainly contains the following contents: the Record Field field records the slave node number, the Data field records the consensus confirmation message of the slave node, and the Signature field records the slave node's signature on the Data.
5. The "one send, multiple receive" efficient consensus method for a naming architecture blockchain as claimed in claim 1 is further characterized in that: The hop-by-hop aggregation in S5 includes the following steps: Set a waiting window time for the NDN router. The NDN router waits for the return data packet to arrive within the waiting window time. If all interfaces corresponding to the entry of the data packet name in the forwarding information base (FIB) have returned data packets, the data packets returned by these different interfaces are immediately aggregated. If only some FIB interfaces return data packets after the window time has expired, the data packets received within the window time are aggregated. For the aggregated data packet, only the original data in the Data field of the first node data packet is retained. The Record Field field records the numbers of all slave nodes participating in this aggregation. The Signature field is updated to the aggregated signature S′. The calculation method of the aggregate signature S′ is as follows: S′=Sig1+Sig2+…+Sig m After the NDN router completes the data packet aggregation operation, it will return the aggregated packet. If other NDN routers on the return path receive multiple aggregated packets, they can aggregate the multiple aggregated data packets again, and so on. Finally, these data packets are aggregated into one and arrive at the master node.
6. The "one send, multiple receive" efficient consensus method for a naming architecture blockchain as claimed in claim 1 is further characterized in that: The S6 verification and consensus confirmation includes the following steps: S6.1 After receiving the aggregation package, the master node extracts the numbers of the m slave nodes participating in the aggregation from the Record Field of the aggregation package, determines whether the number of aggregation packages meets the requirements, and calculates the sub-aggregation public key P′ constructed by the participants according to the numbers: P′=P1+P2+P3+…+P m Among them, P1, P2, ... P m is the public key of the slave nodes numbered 1 to m, and P′ is the partial aggregate public key; S6.2 extracts the partial aggregate signature S′ from the Signature field of the aggregate packet and calculates the following formula to verify the signature: e(g2,S′)=e(P′,H0(P,Data))*e(P′,H0(P,1)+H0(P,2)+…+H0(P,m)) Where P′ is the partial aggregate public key, P is the aggregate public key, H0:{0,1} * →G1 is a hash function, and Data is the Data field content of the aggregated data packet, which contains the consensus confirmation message; S6.3 After the master node verifies the legitimacy of the partial aggregate signature S′, it confirms that m slave nodes have completed the consensus, and then broadcasts the final consensus result to the entire network.
7. The "one send, multiple receive" efficient consensus method for a naming architecture blockchain as claimed in claim 1 is further characterized in that: The consensus data packet has a special structure that can be aggregated along the path of consensus message transmission; Packet structure design: Based on the Name, Data, SignatureInfo and Signature fields of the NDN standard data packet, a new Record Field field is added. This field uses a bit mask to sequentially record the numbers of all slave nodes participating in this aggregation. Each bit corresponds to a unique node ID. By setting 1 to mark valid participants, lightweight node identification is achieved. Let i represent the number of each node and n represent the total number of nodes. The Record Field of the data packet generated by node i is counted as Record i , which is calculated as: Record i =2 i Then record i The calculation result is converted into binary and written into the Record Field field; Dynamic aggregation mechanism: When multiple data packets arrive at the router, the router supports aggregating the signatures of these multiple data packets and aggregating the Record Field through an XOR operation to retain the number of historical nodes.
Citation Information
Patent Citations
Blockchain synchronization method and device based on NDN (Named Data Networking)
CN107317842A
Communication method and system for providing block chain application for NDN network
CN110072196A
Consensus method of block chain data and related equipment
CN110300172A
Blockchain consensus method and device based on VRF and threshold signature
CN111090892A
Aggregated signature method and device of block chain system and storage medium
CN111445334A