A "one-to-many" efficient consensus method for naming architecture blockchains

Abstract

The present application relates to a blockchain based on a named data network, in particular to a kind of "one sends multiple receipts" efficient consensus method of named architecture blockchain.The present application utilizes the characteristics of the message consistency on the chain in the consensus process of blockchain, in each stage of consensus process, the main node only sends one request interest package, multiple consensus slave node reply consensus data package, aggregate after returning on the return path and return, aggregate BLS threshold signature aggregation mechanism is used.The present application increases a Record Field field in existing NDN data package, carries the aggregated consensus slave node number in the way of one-hot coding, solves the aggregation signature verification problem when only part of consensus slave node participates in consensus.Compared with the blockchain based on IP architecture and the blockchain based on classic NDN architecture, the consensus efficiency is higher and the transmission overhead of consensus process is smaller.

Description

TECHNICAL FIELD

[0001] The present application relates to named data network, and in particular to a "one-to-many" efficient consensus method of a named architecture blockchain. BACKGROUND

[0002] Blockchain is a kind of distributed ledger technology, which has the characteristics of decentralization, tamper resistance, transparency, etc. Due to these characteristics, blockchain has shown broad application potential in many fields, such as cross-border payment in the financial field, product traceability in the supply chain, electronic medical record management in the medical field, intellectual property protection, etc. With the blockchain technology receiving more and more attention and being widely applied in the world, people's demand for blockchain performance is also getting higher and higher.

[0003] Named data network (NDN) is one of the hot candidate solutions for the next generation network architecture, which has the characteristics of named addressing and in-network caching. Applying NDN to blockchain technology and replacing the original P2P architecture can bring many advantages to blockchain. First, NDN adopts a request and response mechanism based on data name, which allows blockchain nodes to request consensus information on the chain with the shortest path using the name. Compared with P2P message transmission path, the transmission time is shorter, and finally the blockchain consensus efficiency is improved. Secondly, the mechanism of NDN in-network caching can make each router of the NDN network cache the requested data, so that when other nodes need the same data, the cache node can directly provide these data, reducing the transmission of duplicate data.

[0004] Although NDN as a blockchain underlying communication architecture replacement solution has shown significant advantages in shortening the communication path and reducing redundant traffic, the "one-to-one" transmission mechanism of NDN based on the interest-driven model still faces important challenges in the blockchain scenario. In the blockchain, nodes often need to synchronize multi-source consensus information, at which time the node needs to send a separate interest package to all other consensus nodes to subscribe to these information, resulting in a linear growth of subscription overhead, greatly increasing the network communication complexity. At the same time, the routing system of ICN needs to maintain independent interest table entries for each node, resulting in a sharp rise in routing storage and lookup overhead, and when the node size of the blockchain expands, the consensus efficiency will decrease significantly.

[0005] To solve the above problems existing in the existing NDN "one-to-one" on the blockchain, the design of "one-to-many" broadcast mode, that is, subscribing to multiple data packets with one interest packet, can solve the problem. However, the original PIT table mechanism of NDN limits NDN to "one-to-one": 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, only the first arriving data packet will be forwarded, and subsequent data packets will be discarded by the router because NDN entries cannot find a return path. In order to meet the demand of "one-to-many" that one subscription and multiple "push" information are recovered, the first solution is to modify the survival period of the PIT entry and set a long PIT table. The router does not delete the entry after receiving a data packet, so that subsequent data packets can continue to return. The second solution is to add an additional table based on the original NDN three tables to enhance the reverse routing capability. The new table supports multiple forwarding of a specific name prefix. For one-to-many scenarios, the routing entry is recorded in the new table, and the reverse propagation path provided by the new table can realize "one-to-many".

[0006] However, the two types of implementation methods have some defects. For the first type of scheme, modifying the PIT entry time can easily form a routing loop in the network content, produce abnormal traffic, and cause congestion in the network. For the second type of scheme, introducing 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 system burden. SUMMARY

[0007] The traditional NDN is based on the interest packet driven mechanism of "one-to-one", and in the scene where the blockchain node needs to synchronize the multi-source consensus message, there is a significant efficiency bottleneck: the receiving node needs to send a subscription request to all consensus nodes one by one, resulting in linear growth of subscription overhead and router interest table maintenance cost.

[0008] In order to solve the problems existing in the prior art, the present application innovatively introduces the "one-to-many" aggregation and broadcast transmission paradigm on the blockchain of the NDN architecture, so that a single interest packet can trigger multiple node data return. By embedding a Record Field field (using one-hot encoding to identify the node set participating in consensus) supporting dynamic group management in the existing NDN data packet, and combining with the BLS threshold aggregation signature technology to support the signature verification compatibility of partial nodes participating in consensus, the hop-by-hop aggregation of data packets on the return path is realized.

[0009] In order to achieve the above invention purpose, the present application proposes a "one-to-many" efficient consensus method of a naming architecture blockchain, comprising the following steps:

[0010] S1, a transmission network of the blockchain constructed by NDN, used to support communication services between multiple nodes of the blockchain;

[0011] S2, a blockchain initialization stage: configuring a public parameter of the BLS threshold aggregation signature for the blockchain, and configuring a key of the BLS threshold aggregation signature for each node;

[0012] S3, a user transaction stage: when a user sends a transaction request, after any node of the blockchain receives the transaction request of the user, the node broadcasts an interest package to start a consensus process, and the node starting the consensus process is defined as a master node in the process, and other nodes in the blockchain are defined as slave nodes in the process;

[0013] S4, after the slave nodes participating in the consensus of the blockchain receive the interest package of the master node, the slave nodes reply to the master node with a consensus data package as a response, and the replied data package is signed by the BLS threshold aggregation signature;

[0014] S5, the consensus data package replied by the slave node is aggregated hop by hop at each router on the return path, including data package content aggregation and signature aggregation, and finally the master node only receives one aggregated consensus data package, that is, "one sending and one receiving";

[0015] S6, after the master node receives the aggregated consensus data package, the master node extracts the aggregated signature in the consensus data package for verification, judges whether the number of slave nodes participating in the signature meets the threshold required for consensus confirmation, and then completes the consensus process.

[0016] Further, the NDN constructing the blockchain in the above step S1 includes the following contents:

[0017] (1) replacing the IP router with the NDN router to construct the transmission network of the blockchain;

[0018] (2) a blockchain user; configuring an NDN protocol stack to facilitate access to the NDN network;

[0019] (3) the naming rules (Name field) of the interest package and the data package for blockchain business communication in the NDN network are: / blockchain name / consensus method / message type / participating node.

[0020] Further, the setting of the public parameter of the BLS threshold aggregation signature and the BLS threshold aggregation signature key initialized and configured for each node in the above step S2 includes:

[0021] (1) the public parameter of the BLS threshold aggregation signature includes G1, G2, G T , e, g1, g2, p, q, H0, H1, wherein G1, G2, G TG1 and G2 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, G1 and G2 are elements inside G1 and G2, and G1, G2, G T There is a bilinear mapping e: G1 x G2→ G T between them; H0 and H1 are two hash functions, defined as: H0: {0, 1} * → G1 (any binary string maps to G1 group element), H1: {0, 1} * → Z q (an arbitrary binary string maps to a q-order integer cyclic group element), Zq 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 agency and then disclosed.

[0022] (2) BLS threshold aggregation signature key setting

[0023] Based on the public parameters G1, G2, G T , e, g1, g2, p, q, H0, H1, each node i in the blockchain generates its own public key P i , private key sk i , member key MK i , and all nodes hold the same aggregation public key P, which is defined as P, and the calculation process is as follows:

[0024] Node public and private key calculation: node i selects a random number from Z q as its own private key sk i ∈ Z q , and the public key P i of node i is calculated as: P i = sk i *g1;

[0025] Aggregation public key P calculation: node i generates its own aggregation public key aggregation coefficient a i = H1(P i , (P1, P2... P n )), and then generates the aggregation public key P through the exchange of the public key P i and the aggregation public key aggregation coefficient a i :

[0026]

[0027] Member key MK i calculation: each node i signs the aggregation public key aggregation coefficient a i using the private key sk i , and then aggregates the signatures to obtain the member key MK i :

[0028] MKi = (a1*sk1)*H0(P,i) + (a2*sk2)*H0(P,i) +…+(a n *sk n )*H0(P,i)

[0029] Member Key MK i The role is to verify whether the member i is a real consensus node, verified by the following formula:

[0030] e(g2,MK i ) = e(P,H0(p,i)).

[0031] Further, the following operations are performed after the slave node receives the master node interest packet in the above step S4:

[0032] S4.1 Construct a special data packet Data Packet containing a Record Field field, which records the node number in the form of a bit mask, and the field uses one-hot encoding to ensure uniqueness;

[0033] S4.2 Each consensus slave node generates a BLS threshold aggregate signature and embeds it in the Signature field of the data packet, and returns to the master node, the calculation process is as follows:

[0034] sk1,sk2,...sk i are the private keys of nodes 1 to m, MK1,MK2,...MK i are the member keys of nodes 1 to m, P is the aggregate public key, H0:{0,1} * →G1 is a hash function, and Data is the content of the Data field of the data packet containing the consensus confirmation message. If there are m nodes participating in the consensus, the consensus slave node uses its own private key sk i ,sk2,...sk i to sign the content of the data packet Data field, and the following signatures Sig1,Sig2…Sig m will be obtained:

[0035]

[0036] S4.3 The slave node constructs a data packet and returns it to the master node, which mainly contains the following contents: Record Field field records the number of slave nodes, Data field records the consensus confirmation message of the slave node, and Signature field records the signature of the slave node to Data.

[0037] Further, the hop-by-hop aggregation in the above step S5 includes the following steps:

[0038] The NDN router is set with a waiting window time, and the NDN router waits for the return of the data packet within the waiting window time. If the data packet name corresponds to the entry of all interfaces in the Forwarding Information Base (FIB), the data packets returned by different interfaces are aggregated immediately. If the data packet is returned by only part of the FIB interfaces after the window time is exceeded, the data packets received within the window time are aggregated. The aggregated data packet only retains the original data of the first node data packet Data field, the Record Field field records the serial numbers of all the participating slave nodes in this aggregation, and the Signature field is updated to the aggregated signature S';

[0039] The aggregated signature S' is calculated as follows:

[0040] S' = Sig1 + Sig2 +... + Sig m

[0041] After the NDN router completes the data packet aggregation operation, the aggregated packet is returned. If multiple aggregated data packets are received by other NDN routers on the return path, the multiple aggregated data packets can be aggregated again, and so on. Finally, these data packets are aggregated into one to reach the master node.

[0042] Further, the above step S6 verification and consensus confirmation includes the following steps:

[0043] S6.1 After the master node receives the aggregated packet, the m slave node numbers participating in the aggregation are extracted from the Record Field field of the aggregated packet. It is judged whether the number of aggregated packets meets the requirements. The partial aggregation public key P' formed by the participants is calculated according to the number:

[0044] P' = P1 + P2 + P3 +... + P m

[0045] Wherein, P1, P2,..., P m are the public keys of nodes 1 to m, and P' is the partial aggregation public key;

[0046] S6.2 The partial aggregation signature S' is extracted from the Signature field of the aggregated packet, and the following formula is calculated to verify the signature:

[0047] e(g2, S') = e(P', H0(P, Data)) * e(P', H0(P, 1) + H0(P, 2) +... + H0(P, m))

[0048] Wherein, P' is the partial aggregation public key, P is the aggregation public key, and H0: {0, 1} *→ G1 is a hash function, and Data is the content of the Data field of the aggregated data packet containing the consensus confirmation message.

[0049] S6.3 After the master node verifies the legitimacy of the partial aggregated signature S', it confirms that m slave nodes complete the consensus and then broadcasts the final consensus result to the entire network.

[0050] Further, the consensus data packet has a special structure that can be aggregated along the path of the consensus message transmission.

[0051] Packet structure design: on the basis of inheriting the Name, Data, SignatureInfo and Signature fields of the NDN standard data packet, a Record Field field (structure as shown below) is added, which records all slave node numbers participating in this aggregation in sequence in the form of bitmask, wherein each bit corresponds to a unique node ID, and the effective participants are marked by setting 1, realizing lightweight node identity identification;

[0052]

[0053] Let i represent the number of each node, and n represent the total number of nodes, then the RecordField field of the data packet generated by the node i is Record i , and the calculation method is:

[0054] Record i = 2 i

[0055] Then the calculation result of Record i is converted into binary and written into the Record Field field.

[0056] Dynamic aggregation mechanism: when multiple data packets arrive at the router, the router supports aggregating the signatures of the multiple data packets and aggregating the Record Field field through XOR operation, retaining the numbers of historical nodes.

[0057] The beneficial effects of the present application are as follows:

[0058] Through the architecture design of triggering multi-source data aggregation by a single interest packet, the blockchain data transmission paradigm is restructured. The sender only needs to broadcast a single interest packet to trigger the distributed data response of the nodes in the entire network, and then in 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 individual subscription, and can effectively solve the performance bottleneck caused by high-frequency communication between nodes in traditional consensus algorithms (such as PBFT). BRIEF DESCRIPTION OF DRAWINGS

[0059] Figure 1 Flow chart of the method of the present application.

[0060] Figure 2 “One-to-many” mode of the present application.

[0061] Figure 3 Design diagram of the data packet structure of the present application.

[0062] Figure 4 System architecture diagram of one embodiment of the present application.

[0063] Figure 5 Record Field aggregation diagram of one embodiment of the present application. DETAILED DESCRIPTION

[0064] The present application will be further described below in conjunction with the accompanying drawings and specific embodiments. It should be noted that the following only describes one preferred technical solution in detail to illustrate the technical solution and design principle of the present application, but the protection scope of the present application is not limited thereto.

[0065] The embodiments are preferred embodiments of the present application, but the present application is not limited to the above embodiments. Any obvious improvement, replacement or modification made by those skilled in the art without departing from the essential content of the present application shall fall within the protection scope of the present application.

[0066] As shown in the “one-to-many” mode, a blockchain consensus method is constructed, which comprises the following steps: Figure 1 S1. Constructing a transmission network of the blockchain with NDN, which is used to support the communication service between multiple nodes of the blockchain;

[0067] S2. Blockchain initialization stage: configuring the public parameters of the BLS threshold aggregation signature for the blockchain, and configuring the key of the BLS threshold aggregation signature for each node;

[0068] S3. User transaction stage: when a user sends a transaction request, any node of the blockchain receives the user transaction request and broadcasts an interest packet to start the consensus process. 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;

[0069] S4. After the slave nodes participating in the consensus of the blockchain receive the interest packet of the master node, they reply with a consensus data packet as a response. The replied data packet is signed with the BLS threshold aggregation signature;

[0070] S5. As shown in the “one-to-many” mode, the master node collects the consensus data packets from the slave nodes, and verifies the signature of each consensus data packet with the BLS threshold aggregation signature.

[0071] Figure 2 ​As shown in the figure, the consensus data packet replied by the slave node is aggregated hop by hop at each router of the backhaul path, including packet content aggregation and signature aggregation, and finally the master node only receives one aggregated consensus data packet, that is, "one sending and one receiving";

[0072] S6, the master node extracts the aggregated signature in the aggregated consensus data packet for verification after receiving the aggregated consensus data packet, judges whether the number of slave nodes participating in the signature meets the threshold required for consensus confirmation, and then completes the consensus process.

[0073] As a preferred embodiment of the application, the NDN constructs a blockchain in step S1, including the following contents:

[0074] (1) The transmission network of the blockchain is constructed by replacing the IP router with the NDN router;

[0075] (2) Blockchain user; configure the NDN protocol stack to facilitate access to the NDN network;

[0076] (3) The naming rules (Name field) of the interest packet and the data packet for blockchain business communication in the NDN network are: / blockchain name / consensus method / message type / participating node.

[0077] As a preferred embodiment of the application, the public parameters of the BLS threshold aggregation signature and the BLS threshold aggregation signature key set initialized by each node in step S2 include:

[0078] (1) The public parameters of the BLS threshold aggregation signature include G1, G2, G T , e, g1, g2, p, q, H0, H1, wherein 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, wherein g1 and g2 are determined when G1 and G2 are generated, and are an element inside G1 and G2, and there is a bilinear mapping e: G1×G2→G T between 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 (an arbitrary binary string is mapped to a q-order integer cyclic group element), Z q 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 disclosed.

[0079] (2) BLS threshold aggregation signature key setting

[0080] Based on the public parameters G1, G2, G Te.g1, g2, p, q, H0, H1 blockchain each node i 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, the calculation process is as follows:

[0081] Node public and private key calculation: node i selects a random number from Z q as its own private key sk i ∈Z q , the public key P i of node i is calculated as: P i = sk i *g1;

[0082] Aggregate public key P calculation: node i generates its own aggregate public key aggregate coefficient a i = H1(P i ,(P1, P2...P n )), and then generates the aggregate public key P through the exchange of the public key P i and the aggregate public key aggregate coefficient a i :

[0083]

[0084] Member key MK i calculation: each node i signs the aggregate public key aggregate coefficient a i using the private key sk i , and then aggregates the signature to obtain the member key MK i :

[0085] MK i = (a1*sk1)*H0(P,i)+(a2*sk2)*H0(P,i)+…+(a n *sk n )*H0(P,i)

[0086] The role of the member key MK i is to verify whether the member i is a real consensus node, which is verified by the following formula:

[0087] e(g2, MK i ) = e(P, H0(p, i)).

[0088] As a preferred embodiment of the present application, the following operations are performed in S4 after the node receives the master node interest package:

[0089] S4.1 Construct a special data packet Data Packet containing a Record Field field recording its own node number in the form of a bit mask, which uses one-hot encoding to ensure uniqueness;

[0090] S4.2 Each consensus slave node generates a BLS threshold aggregate signature and embeds it in the Signature field of the data packet, and returns to the master node. The calculation process is as follows:

[0091] sk1,sk2,...sk i are the private keys of nodes 1 to m, MK1, MK2,...MK i are the member keys of nodes 1 to m, P is the aggregate public key, H0:{0,1} * →G1 is a hash function, and Data is the content of the Data field of the data packet containing the consensus confirmation message. If there are m nodes participating in the consensus, the consensus slave node uses its own private key sk i ,sk2,…sk i to sign the content of the data packet Data field, and the following signatures Sig1, Sig2...Sig m will be obtained:

[0092]

[0093] S4.3 The slave node constructs a data packet and returns it to the master node, which mainly contains the following contents: the Record Field field records the number of the slave node, the Data field records the consensus confirmation message of the slave node, and the Signature field records the signature of the slave node on Data.

[0094] As a preferred embodiment of the present application, the step S5 of hop-by-hop aggregation includes the following steps:

[0095] A waiting window time is set for the NDN router, and the NDN router waits for the return of the data packet within the waiting window time. If all FIB interfaces return the data packet, the data packets returned by different interfaces are immediately aggregated. If only part of the FIB interfaces return the data packet after the window time is exceeded, the data packets received within the window time are aggregated. The aggregated data packet only retains the original data of the first node data packet Data field, the Record Field field records the numbers of all slave nodes participating in this aggregation, and the Signature field is updated to the aggregated signature S';

[0096] The calculation method of the aggregated signature S' is as follows:

[0097] S' = Sig1 + Sig2 +... + Sig m

[0098] After the NDN router completes the packet aggregation operation, the aggregated packet is returned, and if other NDN routers on the return path receive multiple aggregated packets, the multiple aggregated packets can be aggregated again, and so on, and finally the packets are aggregated into one to reach the master node.

[0099] As a preferred embodiment of the application, the step S6 of verifying and consensus confirmation includes the following steps:

[0100] S6.1 After the master node receives the aggregated packet, the numbers of the m slave nodes participating in the aggregation are extracted from the Record Field field of the aggregated packet, it is judged whether the number of the aggregated packet meets the requirement, and the partial aggregated public key P' formed by the participants is calculated according to the numbers:

[0101] P' = P1 + P2 + P3 + … + P m

[0102] Wherein, P1, P2, … P m are the public keys of the slave nodes numbered 1~m, and P' is the partial aggregated public key;

[0103] S6.2 The partial aggregated signature S' is extracted from the Signature field of the aggregated packet, and the following formula is calculated to verify the signature:

[0104] e(g2, S') = e(P', H0(P, Data)) * e(P', H0(P, 1) + H0(P, 2) + … + H0(P, m))

[0105] Wherein, P' is the partial aggregated public key, P is the aggregated public key, H0: {0,1} * →G1 is a hash function, and Data is the content of the Data field of the aggregated packet containing the consensus confirmation message.

[0106] S6.3 After the master node verifies the legality of the partial aggregated signature S', it is confirmed that the m slave nodes complete the consensus, and then the final consensus result is broadcast to the whole network.

[0107] The consensus data packet of the application has the following special structure, which can be aggregated on the path of the consensus message transmission.

[0108] Packet structure design: as shown in the figure, Figure 3 On the basis of inheriting the Name, Data, SignatureInfo and Signature fields of the NDN standard data packet, a Record Field field is newly added, which records all the slave node numbers participating in this aggregation in order in the form of bit mask, wherein each bit corresponds to a unique node ID, and the effective participants are marked by setting 1, so as to realize lightweight node identity identification.

[0109] Let i represent the number of each node, and n represent the total number of nodes, then the RecordField field of the data packet generated by the node i is counted as Record i , the calculation method is:

[0110] Record i = 2 i

[0111] Then the calculation result of Record i is converted into binary and written into the Record Field field.

[0112] Dynamic aggregation mechanism: when multiple data packets arrive at the router, the router supports aggregation of the signatures of the multiple data packets, and aggregates the Record Field field through the exclusive or operation, and retains the number of historical nodes, and the aggregation process of the Record Field field is as shown in Figure 5 .

[0113] The design of Record Field has the following uses:

[0114] (1) After the master node receives the aggregated packet, the number of aggregated data packets is identified according to the number of Record Field fields “1” in the aggregated packet, so as to identify whether the number of consensus participating slave nodes meets the requirements.

[0115] (2) The master node can identify which nodes participate in the consensus according to the position of the Record Field field “1” in the aggregated packet, which is convenient for subsequent verification of the BLS threshold aggregation signature.

[0116] The technical solutions of the present application will be described in detail below with one specific embodiment of the present application, as shown in Figure 4 , the system architecture includes a user node User, three blockchain nodes Node1, Node2, Node3, an NDN router, wherein Node3 is the master node, and Node1 and Node2 are slave nodes. In the specific embodiment of the present application, the user node sends a transaction request to the master node (Node 3), 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 consistency of transmitting messages on the chain during consensus, the same data on the path of the consensus message propagation will be aggregated, and finally “one-to-many” is converted into “one-to-one”. (1) Parameter initialization stage:

[0117] The SS 512 is selected as the elliptic curve type of the G1 and G2 groups, and the order q of the group is q = 8780710799663312522437781984754049815806883199414208211028653399266475630880222957078625179422662221423155858769582317459277713367317481324925129998224791

[0118] The generator g1 = [6770972885476026750812806483786095675085597649276458672329012823927590471944179380632926936681711815845274904625121715347558385935858738136351352830737463, 830101697005469760960889646694389852608839075649927702221668343304011287748022948797271086480337431376668317760159035713338895115890100812418755120863968]

[0119] g2 = [479569593337518471780706337371656803535810298645162455463986487245293906892954014160339995937468099374540344450911524689279752297754410260043900177078477, 3354239225679180783384021030797770782235550568381385668774648479627901898839355943103373434949483940107186453783537698639160947061719757760054986201611249]

[0120] In this stage, each node in the blockchain generates its own public key, private key, aggregated public key, and member key. For the blockchain nodes Node1, Node2, and Node3, they are represented by i = 1, i = 2, and i = 3, respectively, i.e., node 1, node 2, and node 3. Each node generates a random number from Z qA random number is selected from Z

[0121] as the private key of node 1, and the private key of node 1 is

[0122] The private key of node 2 is

[0123] sk2= 295981573471165232135588872709878289553217734960

[0124] The private key of node 3 is

[0125] sk3= 685536739773921285600040428232715971597362689244

[0126] Node public key calculation: node i selects a random number from Z q as its own private key sk i ∈ Z q The public key P i of node i is calculated as: P i = sk i *g2

[0127] Therefore, the public key of node 1 is

[0128] P1= [3438329697561392519408529006157428679988816566294629660789183557553194183798338081473645774215739845930915129949960030413958314033595444075290276105008993, 8780093122663770446263848193575310659866966079582790137455039700889266605320832464751142791934029383014984077100827683472975481732058803131170833596556595]

[0129] The public key of node 2 is

[0130] P2 = [513423527750268296807131121550033939724855655717863533884071443851503815796088918166118673769497545716912163001657778860559849074572298160598544358768170, 5026624279950704727939381147935607225799480852589372492874408077047376738536946296513222278852442797362769173084074062655194513778442479821963500828924810]

[0131] Node 3's public key

[0132] P3 = [4977739083858898426138182797410343867378943327787140097403366087728817455848929131091350087382160429916069554477633238969046996406605015628268023508692234, 2087132263988365861758787888792690182561028780787748797148720503117182352455289625250354373829245320553212668881842614099250943026032112675942519755057093]

[0133] Next, the aggregated public key P is calculated, for Node 1, Node 2 and Node 3, from their own aggregated public key aggregation coefficients a i = H1(P i , (P1, P2... P n )) and further from the public key P i and the aggregated public key aggregation coefficients a i through an intra-network exchange:

[0134] P = [3339270023604969300856246971639343815297303641955187228513682741678145862427728924968273725261250794937473524695990271192742491400134202245882645469377915, 8173890265720692841339718165033668431731949486989121378101926182690810182674128930683718094330945037204257653353871309696074173774894006828283260726940017]

[0135] The member key MK is then calculated as i For node 1, we have

[0136] MK1 = [2097161551085839573924818842092324323099250198715134909729352146639829985404237982781482509919068641396512843830502444032350969291790375212225389127902664, 8458042985431576141932992653407116926241586470181718625487346347228088013532271843823132868695860552644729941919313064673384143290293169591438877642448041]

[0137] For node 2, we have

[0138] MK2 = [206058521031248064779396273657950019605711814811726480867202596054689197338183641931355109789083815699681349349076540101344677583943891431363324320548319, 80905794793616085798249099089811756627825835237717304363246693894816978188362888152424144776860400361543666249275158805841890358323206182823139797307011]

[0139] (2) Master node broadcast trigger phase

[0140] The user sends a transaction request to the master node Node 3, and the master node Node 3 receives the user transaction request, and broadcasts an NDN interest packet (Interest Packet) to the network consensus slave nodes Node 1 and Node 2, and starts the consensus process.

[0141] (3) Slave node response phase: after the slave node receives the master node interest packet, the following operations are performed:

[0142] ① Construct a special data packet (Data Packet) containing a Record Field field, which records the node number (using one-hot encoding to ensure uniqueness) in the form of a bit mask;

[0143] Node 1 number is 1: Record Field = 00000010

[0144] Node 2 number is 2: Record Field = 00000100

[0145] ② The nodes Node 1 and Node 2 participating in the consensus use their own private keys sk i , sk2 to sign the content of the data packet Data field, and the following signatures Sig1, Sig2 will be obtained:

[0146] Sig1 = [4090584062661854543335536934088420549398964062560468566439490136008382434212619520322726449314049929275898128977803474920553760353803174952368889682843103, 8608933460434058626498781852263052461016432472972132177819717735155780721825506729118702574241356955719267714063267976593277208531690327682816682585151067]

[0147] Sig2 = [5279166701528347011386759358651957266693448965531772063546528049156234128473582904869380412023575174534369710223042563261662359052318548696184347134678433, 2940390334543967863024180771702752677078260859137883450334041776144836380584262996313694746173986523859221953146928637230071284966042400479856213129155537]

[0148] (4) Hop-by-hop aggregation phase:

[0149] After receiving the packets from Node1 and Node2, the NDN router performs the aggregation operation, keeps the original Data field content of the first packet, and accumulates the signatures Sig1, Sig2 of the packets from Node1 and Node2 to generate a partial aggregation signature S′:

[0150] S' = [6426858558908535946829118640868207295322992591291517405807231129047613509071584690348571441592673504513203332605447569781512054276505471608045469862736489, 6529877134520047918567573184904407271352709346411313717461769944131831159389973872587221031952278435334981277576033334433671490344852960845194061040609900]

[0151] The Record Field fields of each data packet are merged by XOR operation to form a complete participant bitmap. As shown in Figure 5 , after aggregating the node data packets numbered 1 and 62, the Record Field of the aggregated packet is calculated as 1 +2 2 , obtaining Record Field of the aggregated packet = 00000110.

[0152] (5) Verification and consensus confirmation:

[0153] After receiving the aggregated packet, the master node extracts the node numbers 1 and 2 from the Record Field field 00000110 of the aggregated packet, and the number meets the requirement, and then calculates the partial aggregated public key P':

[0154] P' = [6040213940227655903999990000734973031101318974824160800252186099382779565756443041947637696354485995422116588499646385228789043054088536736354326969085053, 3791969129224302595632469443007691478885055913061624467450186849770994985403608107580807968396717880914686759291027186698042286201933637030193615958168135]

[0155] Then, whether the following equation is established is calculated to verify the signature S' in the aggregated packet:

[0156] e(g2,S') = e(P',H0(P,Data))*e(P',H0(P,1)+H0(P,2))

[0157] After the master node verifies the legitimacy of the partial aggregated signature S', it is confirmed that two slave nodes complete consensus, and then the final consensus result is broadcast to the slave nodes and users.

[0158] In the above specific implementation cases, the application has the following beneficial effects: the master node Node 3 can receive the data packets of Node 1 and Node 2 by sending one interest packet request, the packet aggregation technology is used on the consensus message transmission path, the original “one-to-many” communication mode is successfully optimized to “one-to-one” mode, and the identity verification problem of the aggregated group is solved by using the aggregated signature. Compared with the existing NDN architecture block chain, the communication times of the nodes on the chain can be significantly reduced, and the communication complexity and network bandwidth of the block chain are reduced.

Claims

1. A highly efficient consensus method for "one-to-many" consensus in a named architecture blockchain, characterized in that, Includes the following steps: S1 is a blockchain transmission network built using NDN to support communication services between multiple blockchain nodes. S2, Blockchain Initialization Phase: Configure the public parameters for BLS threshold aggregation signature for the blockchain, and configure the key for BLS threshold aggregation signature for each node; S3, User Transaction Phase: When a user sends a transaction request, any node in the blockchain, upon receiving the request, broadcasts an interest packet to initiate the consensus process. The node that initiates the consensus process is defined as the master node in this process, and all 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 BLS threshold aggregation signature. S5, the consensus data packets replied by the slave node are aggregated hop by hop at each router in the backhaul path, including data packet content aggregation and signature aggregation. In the end, the master node will only receive one aggregated consensus data packet, which is called "one send and one receive". S6. After receiving the aggregated consensus data packet, the master node extracts the aggregated signature for verification, determines whether the number of slave nodes participating in the signature meets the threshold required for consensus confirmation, and then completes the consensus process. The consensus data packets have a special structure and are aggregated along the path of consensus message transmission; Packet structure design: Based on the Name, Data, SignatureInfo and Signature fields inherited from the NDN standard data packet, a new Record Field is added. This field uses a bitmask to record the numbers of all slave nodes participating in this aggregation in sequence, where each bit corresponds to a unique node ID. Setting it to 1 marks a valid participant, realizing lightweight node identity identification. Let i represent the node number and n represent the total number of nodes. Then, the Record Field of the data packet generated by node i is denoted as Record. i The calculation method is as follows: Record i =2 i Then Record i The calculation result is converted to binary and then written to the Record 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, retaining the number of historical nodes.

2. The efficient consensus method for "one-to-many" consensus in a named architecture blockchain as described in claim 1, characterized in that, The NDN blockchain construction in S1 includes the following: (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 rules for interest packets and data packets used for blockchain business communication within the NDN network are: / blockchain name / consensus method / message type / participating node.

3. The efficient consensus method for "one-to-many" consensus in a named architecture blockchain as described in claim 1, characterized in that, The common parameters of the BLS threshold aggregation signature in S2 and the BLS threshold aggregation signature key settings configured during the initialization of each node include: (1) The common parameters of the BLS threshold aggregation signature include G1, G2, G T ,e,g1,g2,p,q,H0,H1,where G1,G2,G T Let G1 and G2 be 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 elements within G1 and G2. Furthermore, G1, G2, and G2 are... 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 an element of the G1 group, H1:{0,1} * →Z q Any binary string can be mapped to an element of a cyclic group of integers of order q, Z q It is a cyclic group of integers of order q, where p and q are two large prime numbers. The above parameters are generated by the key generation organization and then made public. (2) Setting the BLS threshold aggregation signature key Based on publicly available parameters G1, G2, G T 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: Node public / private key calculation: Node i from Z q Choose 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; Calculation of aggregated public key P: Node i generates its own aggregated public key and aggregation coefficient a. i =H1(P i ,(P1,P2...P n Then, through the public key P i With the aggregation coefficient a of the aggregated public key i The intranet exchange generates a aggregated public key P: Member key MK i Calculation: Each node i uses its private key sk i Aggregation coefficient a of the aggregated public key i Signatures are then combined to obtain the member key MK. i : MK i (a1*sk1)*H0(P,i)+(a2*sk2)*H0(P,i)+…+(a n *sk n )*H0(P,i) Member key MK i Its function is to verify whether member i is a true consensus node, using the following formula: e(g2,MK i )=e(P,H0(p,i))。 4. The efficient consensus method for "one-to-many" consensus in a named architecture blockchain as described in claim 1, further characterized in that, In step S4, after the slave node receives the interest packet from the master node, it performs the following operations: S4.1 Construct a special data packet containing a Record Field, which records its own node number in the form of a bitmask, and the field uses 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, then returns it to the master node. The calculation process is as follows: sk1, sk2, ... sk m These are the private keys from node 1 to node m: MK1, MK2, ..., MK m H0 is the member key from node 1 to node m, P is the aggregate public key, and H0:{0,1} * →G1 is a hash function, and 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 respective private keys sk1, sk2, ... sk m Signing the content of the Data field in the data packet will yield 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: the Record Field records the slave node's number, the Data Field records the slave node's consensus confirmation message, and the Signature Field records the slave node's signature on the Data.

5. The efficient consensus method for "one-to-many" consensus in a named architecture blockchain as described in claim 1, further characterized in that, The step-by-step aggregation in S5 includes the following steps: A wait window time is set for the NDN router. During the wait window time, the NDN router waits for the return data packets to arrive. If all interfaces with the data packet name corresponding to the entry 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 have returned data packets after the window time has expired, the data packets received within the window time are aggregated. The aggregated data packet retains only the original data in the Data field of the first node's data packet. The Record Field records the numbers of all slave nodes participating in this aggregation, and the Signature field is updated with the aggregated signature S′. The aggregate signature S′ is calculated as follows: S′=Sig1+Sig2+…+Sig m After completing the packet aggregation operation, the NDN router sends the aggregated packet back. If other NDN routers on the backhaul path receive multiple aggregated packets, they will aggregate the multiple aggregated packets again, and so on, until finally these packets are aggregated into one and reach the master node.

6. The efficient consensus method for "one-to-many" consensus in a named architecture blockchain as described in claim 1, further characterized in that, The verification and consensus confirmation in S6 include: After receiving the aggregation packet, the S6.1 master node extracts the m slave node numbers participating in the aggregation from the Record Field of the aggregation packet, determines whether the number of aggregation packets meets the requirements, and calculates the sub-aggregation public key P′ constructed by the participants based on the numbers: P′=P1+P2+P3+…+P m Where P1, P2, ... P m P is the public key of the slave nodes numbered 1 to m, and P′ is the partial aggregate public key; S6.2 Extract a partial aggregate signature S′ from the Signature field of the aggregate package and calculate 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 a partial aggregate public key, P is the aggregate public key, and 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; After the master node verifies the legality of the aggregate signature S′, it confirms that m slave nodes have completed consensus, and then broadcasts the final consensus result to the entire network.

Images