Sharding permission chain system and core consensus node selection method

Abstract

The application discloses a slice license chain system and a selection method of core consensus nodes, belongs to the technical field of blockchains, and aims to solve the technical problem of how to improve the transaction processing speed and concurrency of a license chain based on a verifiable random number and improve the transaction processing efficiency in a slice of the license chain. The technical scheme is as follows: the system comprises consensus nodes, accounting nodes and clients; the consensus nodes are divided into core consensus nodes and backup consensus nodes; the core consensus nodes broadcast blocks after receiving transactions and reaching a consensus; the backup consensus nodes receive and store the blocks broadcast by the core consensus nodes through secure channel communication; the core consensus nodes and the backup consensus nodes are transformed into each other when a set condition is met; the accounting nodes are used for recording the blocks of each slice and corresponding account transaction information; and the clients are used for sending various types of requests to the consensus nodes and the accounting nodes through secure channel communication.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, specifically to a sharded permissioned blockchain system and a method for selecting core consensus nodes. Background Technology

[0002] Blockchain is an immutable, distributed, shared ledger. In a blockchain, data is stored across multiple parties, and consensus algorithms ensure data consistency across nodes. Data in a blockchain can only be appended, not deleted or modified. Newer blockchains are programmable; smart contracts can encode business rules into the blockchain. These rules (code), like data, cannot be deleted or modified. The code executes automatically when invoked and cannot be skipped, and the results are also written to the blockchain. Because data is stored across multiple parties and on-chain data is immutable, blockchain enables trusted data sharing among multiple parties.

[0003] Blockchains can be divided into permissioned blockchains and permissionless blockchains. In permissioned blockchains, nodes must be authenticated before joining the blockchain network. Compared to permissionless blockchains, permissioned blockchains have higher consensus and block generation speeds, but their transaction processing speed still faces significant bottlenecks.

[0004] The verifiable random number is generated by an encryption function based on the data input and comes with a proof that anyone can verify.

[0005] Therefore, how to improve the transaction processing speed and concurrency of permissioned blockchains based on verifiable random numbers, and improve the transaction processing efficiency within permissioned blockchain slices, is a technical problem that urgently needs to be solved. Summary of the Invention

[0006] The technical objective of this invention is to provide a sharded permissioned blockchain system and a method for selecting core consensus nodes, in order to address the problem of how to improve the transaction processing speed and concurrency of the permissioned blockchain based on verifiable random numbers, and to improve the transaction processing efficiency within the permissioned blockchain shards.

[0007] The technical objective of this invention is achieved as follows: a sharded permissioned blockchain system, comprising consensus nodes, ledger nodes, and clients;

[0008] Consensus nodes are divided into core consensus nodes and standby consensus nodes. After receiving a transaction and reaching a consensus, the core consensus node packages the transaction into a block and broadcasts it. The standby consensus node receives and stores the block broadcast by the core consensus node through secure channel communication (such as TLS protocol). When the set conditions are met, the core consensus node and the standby consensus node can switch roles.

[0009] Ledger nodes are used to record the blocks in each region and the corresponding ledger transaction information;

[0010] The client is used to send various types of requests to consensus nodes and ledger nodes via secure channel communication (such as TLS protocol).

[0011] As a preferred option, the working process of this system is as follows:

[0012] S1. System initialization: Generate the key required to verify the random number, set the corresponding configuration parameters for each consensus node, and start the blockchain node.

[0013] S2. Select the core consensus node within the shard;

[0014] S3, Transaction Sharding: The accounting node shards the corresponding transaction, and the corresponding consensus node processes the transaction within its shard.

[0015] S4. Handling core consensus node failures;

[0016] S5. Cross-shard consensus: Since transactions within different shards do not affect each other, cross-shard consensus collects the hash value of the last block of each shard, processes it, and uses it as the global state of the blockchain.

[0017] As a preferred embodiment, the system initialization in step S1 is as follows:

[0018] S101. The key provider calls the key generation algorithm for verifiable random numbers: sk,pk = KeyGen(), to generate a private key sk and a public key pk for verifiable random numbers; and securely distributes the private key sk to the administrator and writes the public key pk into the configuration of all blockchain nodes.

[0019] S102. Determine the number of blockchain shards N, i.e., N shards are 0, 1, 2, ..., N-1, and write the number of shards N into the configuration of all blockchain nodes;

[0020] S103. Determine the consensus nodes within each shard, ensuring that the number of consensus nodes within each shard is not less than three; in the configuration of each consensus node, write the information of all consensus nodes in the same shard as the corresponding consensus node; in the accounting node, write the information of the consensus nodes of all shards.

[0021] S104. Start each blockchain node: After the consensus node is started, it calculates the hash value of the information of each consensus node in its shard, and sorts the consensus node information according to the hash value to form a sorted consensus node list.

[0022] As a preferred option, the selection of the core consensus node within the shard in step S2 is as follows:

[0023] S201. The administrator selects to send a core consensus node request. After the client reads the private key sk, it calls the RandomGen(sk) algorithm three times to generate three different random numbers r1, r2, r3 and proofs of the random numbers proof1, proof2, proof3. The random numbers r1, r2, r3 and proofs of the random numbers proof1, proof2, proof3 are attached to the request to randomly select a core consensus node and sent to the accounting node.

[0024] S202, The accounting node directly forwards the request to each consensus node in the configuration;

[0025] S203. After receiving the request to select a core consensus node, each consensus node in the shard calls the Verify(r1,proof1,pk), Verify(r2,proof2,pk), and Verify(r3,proof3,pk) algorithms to verify that the three random numbers are truly randomly generated, and then broadcasts the corresponding core consensus node request to the consensus nodes in the shard.

[0026] S204. Within each shard, consensus nodes calculate the length L of their respective shard consensus node list, calculate the indices of the three consensus nodes c1 = r1 mod L, c2 = r2 mod L, c3 = r3 mod L, and determine the relationship between c1, c2, and c3:

[0027] If c1 and c2 are equal, increment the value of c2 by 1.

[0028] If c1 and c3 are equal, increment the value of c3 by 1;

[0029] If c2 and c3 are equal, increment the value of c3 by 1;

[0030] S205. Each consensus node within a shard obtains the information List[c1], List[c2], and List[c3] of the three core consensus nodes c1, c2, and c3 through the shard consensus node list and the corresponding index, and determines whether the three core consensus nodes c1, c2, and c3 contain its own node:

[0031] If the three core consensus nodes c1, c2, and c3 contain its own node, then Raft consensus will begin with the other two nodes.

[0032] If none of the three core consensus nodes c1, c2, and c3 contain their own node, then request the three core consensus nodes to distribute blocks.

[0033] S206. After the three core consensus nodes c1, c2 and c3 in the shard reach consensus, a block containing the request and core consensus node information in step S201 is generated as the shard initialization block, and the shard initialization block is distributed to the corresponding consensus nodes and accounting nodes; wherein, the node recording of the shard initialization block records the core consensus node information.

[0034] As a preferred embodiment, the sharding process for transactions in step S3 is as follows:

[0035] S301. The user initiates a transaction request to the accounting node through the client;

[0036] S302. The accounting node extracts the user ID from the transaction request, calculates the hash value h of the user ID, and calculates the shard number n = h mod N. At the same time, it forwards the transaction request to the core consensus node in the corresponding shard.

[0037] S303. Upon receiving the request, the core consensus node within the shard reaches a consensus on the corresponding transaction using the Raft consensus algorithm, generates a block, and distributes the block to the remaining consensus nodes and ledger nodes; among them, the ledger nodes record the transaction information within the block.

[0038] As a preferred option, the handling of core consensus node failures in step S4 is as follows:

[0039] S401. When one of the three core consensus nodes c1, c2 and c3 in any shard fails, the remaining two core consensus nodes reach a consensus on the faulty node, generate a core consensus node fault block, and distribute the core consensus node fault block to the accounting node and the other consensus nodes in the shard.

[0040] S402. The node that receives the faulty block of the core consensus node performs an alarm operation;

[0041] S403. After the administrator discovers the alarm, he calls the RandomGen(sk) algorithm to generate a random number, the RandomGen(sk) algorithm, the random number r, and the random number proof proof. He attaches the random number r, the random number proof proof, and the shard where the faulty node is located to the request to add a new core consensus node and sends them to the accounting node.

[0042] S404. After receiving a request to add a core consensus node, the accounting node obtains the sharding information and forwards the request to the core consensus node of the corresponding shard.

[0043] S405. After receiving a request to add a new core consensus node, the core consensus node of the corresponding shard calls the Verify(r,proof,pk) algorithm to verify that the random number is correctly generated. Then, it calculates the index c = r mod L of the consensus node using the length L of the consensus node list List within the shard. If the index of the consensus node is the same as the index of an existing core consensus node, it increments the index c = r mod L until it is different from the index of any core consensus node. The new index value is then appended to the request to add a new core consensus node to initiate Raft consensus.

[0044] S406. After the core consensus nodes reach Raft consensus on the request for a new core consensus node, they begin to accept the consensus node with the corresponding index value c = r mod L as a new core consensus node, generate a block containing the request in step S405 to add a core consensus node, and distribute the block to the accounting nodes and other consensus nodes.

[0045] S407. After receiving the block for adding a core consensus node, the other consensus nodes extract the information of the newly added core consensus node from the core consensus node block. If the newly added core consensus node is itself, it begins to conduct Raft consensus with the core consensus node of that area.

[0046] More preferably, the cross-slice consensus in step S5 is as follows:

[0047] S501: The administrator sends cross-shard consensus requests to the core consensus nodes of each shard through the client.

[0048] S502. Each core consensus node verifies the cross-shard consensus request from the administrator and, after reaching a consensus on the cross-shard consensus request, stops processing other transaction requests, generates a block containing the cross-shard consensus request, and distributes it to the accounting nodes and other consensus nodes within the shard.

[0049] S503. Whenever the accounting node receives a cross-shard consensus request block from a shard, it forwards the cross-shard consensus request block to the core consensus nodes of the other shards.

[0050] S504. When any core consensus node of any partition obtains the cross-shard consensus request blocks of all shards, it appends the hash values ​​of all the cross-shard consensus request blocks in ascending order and writes the hash value of the calculated appended value into the global state request.

[0051] S505, the core consensus nodes in the corresponding area use the Raft algorithm to reach a consensus on the corresponding global state request, generate a global state block (the hash of the previous block is the hash value of the additional value in step S504), and distribute the global state block to the accounting nodes and consensus nodes in the area to continue receiving transactions.

[0052] A method for selecting core consensus nodes, the method is as follows:

[0053] (1) Generate the key required to verify the random number, set the corresponding configuration parameters for each consensus node, and start the blockchain node;

[0054] (2) Select the core consensus node within the shard;

[0055] (3) Transaction sharding: The accounting node shards the corresponding transaction, and the corresponding consensus node processes the transaction within the shard;

[0056] (4) Handling core consensus node failures;

[0057] (5) Cross-shard consensus: Since transactions in different shards do not affect each other, cross-shard consensus collects the hash value of the last block of each shard and processes it as the global state of the blockchain.

[0058] Preferably, in step (1), the key required to generate verifiable random numbers is used, and corresponding configuration parameters are set for each consensus node. The blockchain node is started as follows:

[0059] ① The key provider calls the key generation algorithm for verifiable random numbers: sk,pk = KeyGen(), to generate a private key sk and a public key pk for verifiable random numbers; and securely distributes the private key sk to the administrator and writes the public key pk into the configuration of all blockchain nodes;

[0060] ② The administrator determines the number of blockchain shards N, i.e., the N shards are 0, 1, 2, ..., N-1, and writes the number of shards N into the configuration of all blockchain nodes;

[0061] ③ Determine the consensus nodes within each shard, ensuring that the number of consensus nodes within each shard is no less than three; in the configuration of each consensus node, write the information of all consensus nodes in the same shard as the corresponding consensus node; in the accounting node, write the information of the consensus nodes of all shards.

[0062] ④ Start each blockchain node: After the consensus node starts, it calculates the hash value of the information of each consensus node in its shard, and sorts the consensus node information according to the hash value to form a sorted consensus node list.

[0063] Step (2) Selecting the core consensus node within the shard is as follows:

[0064] ① The administrator selects to send a core consensus node request. After the client reads the private key sk, it calls the RandomGen(sk) algorithm three times to generate three different random numbers r1, r2, r3 and proofs of the random numbers proof1, proof2, proof3. The random numbers r1, r2, r3 and proofs of the random numbers proof1, proof2, proof3 are attached to the request to randomly select a core consensus node and sent to the accounting node.

[0065] ② The accounting node directly forwards the request to each consensus node in the configuration;

[0066] ③ After receiving the request to select a core consensus node, each consensus node in the shard calls the Verify(r1,proof1,pk), Verify(r2,proof2,pk), and Verify(r3,proof3,pk) algorithms to verify that the three random numbers are truly randomly generated, and then broadcasts the corresponding core consensus node request to the consensus nodes in the shard.

[0067] ④ Each consensus node in a shard calculates the length L of its own shard's consensus node list, calculates the indices of the three consensus nodes c1 = r1 mod L, c2 = r2 mod L, c3 = r3 mod L, and determines the relationship between c1, c2, and c3:

[0068] If c1 and c2 are equal, increment the value of c2 by 1.

[0069] If c1 and c3 are equal, increment the value of c3 by 1;

[0070] If c2 and c3 are equal, increment the value of c3 by 1;

[0071] ⑤ Each consensus node within a shard obtains the information List[c1], List[c2], and List[c3] of the three core consensus nodes c1, c2, and c3 through the shard consensus node list and the corresponding index, and determines whether the three core consensus nodes c1, c2, and c3 contain its own node:

[0072] If the three core consensus nodes c1, c2, and c3 contain its own node, then Raft consensus will begin with the other two nodes.

[0073] If none of the three core consensus nodes c1, c2, and c3 contain their own node, then request the three core consensus nodes to distribute blocks.

[0074] ⑥ After the three core consensus nodes c1, c2 and c3 in the shard reach a consensus, a block containing the request and core consensus node information in step S201 is generated as the shard initialization block, and the shard initialization block is distributed to the corresponding consensus nodes and accounting nodes; wherein, the node recording of the shard initialization block records the core consensus node information.

[0075] More preferably, step (3) of sharding the transaction is as follows:

[0076] ① Users initiate transaction requests to the ledger nodes through the client;

[0077] ② The accounting node extracts the user ID from the transaction request, calculates the hash value h of the user ID, and calculates the shard number n = h mod N. At the same time, it forwards the transaction request to the core consensus node in the corresponding shard.

[0078] ③ Upon receiving the request, the core consensus node within the shard reaches a consensus on the corresponding transaction using the Raft consensus algorithm, generates a block, and distributes the block to the remaining consensus nodes and ledger nodes; among them, the ledger nodes record the transaction information within the block;

[0079] Step (4) for handling core consensus node failures is as follows:

[0080] ① When one of the three core consensus nodes c1, c2 and c3 in any shard fails, the remaining two core consensus nodes reach a consensus on the faulty node, generate a core consensus node fault block, and distribute the core consensus node fault block to the accounting node and the other consensus nodes in the shard.

[0081] ② Nodes that receive faulty blocks from core consensus nodes should perform alarm operations;

[0082] ③ After the administrator discovers the alarm, he calls the RandomGen(sk) algorithm to generate a random number, the RandomGen(sk) algorithm, the random number r, and the random number proof proof. He attaches the random number r, the random number proof proof, and the shard where the faulty node is located to the request to add a new core consensus node and sends it to the accounting node.

[0083] ④ After receiving a request to add a core consensus node, the accounting node obtains the sharding information and forwards the request to the core consensus node of the corresponding shard.

[0084] ⑤ After receiving a request to add a new core consensus node, the core consensus node of the corresponding shard calls the Verify(r,proof,pk) algorithm to verify that the random number is correctly generated. Then, it calculates the index of the consensus node c = r mod L based on the length L of the consensus node list List within the shard. If the index of the consensus node is the same as the index of an existing core consensus node, it increments the index c = r mod L until it is different from the index of any core consensus node. The new index value is then appended to the request to add a new core consensus node to initiate Raft consensus.

[0085] ⑥ After the core consensus nodes reach Raft consensus on the request for a new core consensus node, the consensus node with the corresponding index value c = r mod L is accepted as a new core consensus node. The block containing the request in step S405 is generated and distributed to the accounting nodes and other consensus nodes.

[0086] ⑦ After receiving the block for adding a core consensus node, the other consensus nodes extract the information of the newly added core consensus node from the core consensus node block. If the newly added core consensus node is itself, it starts to conduct Raft consensus with the core consensus node of that area.

[0087] Step (5) Cross-slice consensus is as follows:

[0088] ① The administrator sends cross-shard consensus requests to the core consensus nodes of each shard through the client;

[0089] ② Each core consensus node verifies the cross-shard consensus request from the administrator and, after reaching a consensus on the cross-shard consensus request, stops processing other transaction requests, generates a block containing the cross-shard consensus request, and distributes it to the accounting nodes and other consensus nodes within the shard.

[0090] ③ Each time a ledger node receives a cross-shard consensus request block from a shard, it forwards the cross-shard consensus request block to the core consensus nodes of the other shards;

[0091] ④ Once the core consensus node of any partition obtains the cross-shard consensus request blocks of all shards, it appends the hash values ​​of all the cross-shard consensus request blocks in ascending order and writes the hash value of the calculated appended value into the global state request.

[0092] ⑤ The core consensus nodes in the corresponding area reach a consensus on the corresponding global state request using the Raft algorithm, generate a global state block (the hash of the previous block is the hash value of the additional value in step S504), and distribute the global state block to the accounting nodes and consensus nodes in the area to continue receiving transactions.

[0093] Among them, Raft consensus is a widely used consensus algorithm in engineering. Consensus means that multiple nodes reach a consensus on a certain matter, even in the event of node failure, network latency, or network segmentation. Due to its strong consistency, decentralization, and high availability, Raft consensus is most widely used in permissioned blockchains.

[0094] Sharding technology overcomes the scalability issues faced by blockchains. As an on-chain scaling method, it improves blockchain performance without sacrificing centralization, thus becoming one of the mainstream methods for blockchain scaling. Sharding divides the entire blockchain network into different shards, with each shard's nodes responsible for processing transactions and storing the shard's state. Through parallel transaction verification, the overall blockchain throughput increases almost linearly. Simultaneously, as the number of nodes increases, the number of shards in the network also increases, further enhancing the network's transaction processing capacity. Sharding technology generally involves stages such as defining shard configurations, intra-shard and cross-shard consensus protocols, thus forming a complete sharded blockchain system.

[0095] The sharded permissioned blockchain system and the method for selecting core consensus nodes of the present invention have the following advantages:

[0096] (i) This invention uses verifiable random numbers to select core consensus nodes within the sharded permissioned blockchain, which fully guarantees the randomness of the selection of core consensus nodes. Moreover, in each shard of the permissioned blockchain, only three randomly selected core consensus nodes perform Raft consensus, while the remaining consensus nodes are only passively synchronizing messages as backups. This not only avoids the consensus communication bloat problem caused by too many consensus nodes and improves the transaction processing efficiency within the shard, but the existence of backup consensus nodes also ensures the reliability of consensus within the permissioned blockchain shard.

[0097] (II) This invention aims to construct a high-throughput permissioned blockchain system by selecting core consensus nodes within a shard based on verifiable random numbers. Compared with permissionless blockchains, permissioned blockchains have higher consensus and block generation speeds, but their transaction processing speed still faces significant bottlenecks. To improve the transaction processing speed and concurrency of permissioned blockchains, this invention uses a verifiable random function to select the minimum number of nodes required to reach consensus within a shard as core consensus nodes. Consensus within the shard is performed by the core consensus nodes to minimize the communication cost of consensus nodes and improve the transaction processing efficiency within the permissioned blockchain shard. Attached Figure Description

[0098] The invention will be further described below with reference to the accompanying drawings.

[0099] Appendix Figure 1 A flowchart illustrating the working process of a sharded permissioned blockchain system and the method for selecting core consensus nodes. Detailed Implementation

[0100] The sharded permissioned blockchain system and the method for selecting core consensus nodes of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0101] Example 1:

[0102] This embodiment provides a sharded permissioned blockchain system, which includes consensus nodes, ledger nodes, and clients;

[0103] Consensus nodes are divided into core consensus nodes and standby consensus nodes. After receiving a transaction and reaching a consensus, the core consensus node packages the transaction into a block and broadcasts it. The standby consensus node receives and stores the block broadcast by the core consensus node through secure channel communication (such as TLS protocol). When the set conditions are met, the core consensus node and the standby consensus node can switch roles.

[0104] Ledger nodes are used to record the blocks in each region and the corresponding ledger transaction information;

[0105] The client is used to send various types of requests to consensus nodes and ledger nodes via secure channel communication (such as TLS protocol).

[0106] As attached Figure 1 As shown, the specific working process of this system is as follows:

[0107] S1. System initialization: Generate the key required to verify the random number, set the corresponding configuration parameters for each consensus node, and start the blockchain node.

[0108] S2. Select the core consensus node within the shard;

[0109] S3, Transaction Sharding: The accounting node shards the corresponding transaction, and the corresponding consensus node processes the transaction within its shard.

[0110] S4. Handling core consensus node failures;

[0111] S5. Cross-shard consensus: Since transactions within different shards do not affect each other, cross-shard consensus collects the hash value of the last block of each shard, processes it, and uses it as the global state of the blockchain.

[0112] The system initialization in step S1 of this embodiment is as follows:

[0113] S101. The key provider calls the key generation algorithm for verifiable random numbers: sk,pk = KeyGen(), to generate a private key sk and a public key pk for verifiable random numbers; and securely distributes the private key sk to the administrator and writes the public key pk into the configuration of all blockchain nodes.

[0114] S102. Determine the number of blockchain shards N, i.e., N shards are 0, 1, 2, ..., N-1, and write the number of shards N into the configuration of all blockchain nodes;

[0115] S103. Determine the consensus nodes within each shard, ensuring that the number of consensus nodes within each shard is not less than three; in the configuration of each consensus node, write the information of all consensus nodes in the same shard as the corresponding consensus node; in the accounting node, write the information of the consensus nodes of all shards.

[0116] S104. Start each blockchain node: After the consensus node is started, it calculates the hash value of the information of each consensus node in its shard, and sorts the consensus node information according to the hash value to form a sorted consensus node list.

[0117] The specific steps for selecting the core consensus node within the shard in step S2 of this embodiment are as follows:

[0118] S201. The administrator selects to send a core consensus node request. After the client reads the private key sk, it calls the RandomGen(sk) algorithm three times to generate three different random numbers r1, r2, r3 and proofs of the random numbers proof1, proof2, proof3. The random numbers r1, r2, r3 and proofs of the random numbers proof1, proof2, proof3 are attached to the request to randomly select a core consensus node and sent to the accounting node.

[0119] S202, The accounting node directly forwards the request to each consensus node in the configuration;

[0120] S203. After receiving the request to select a core consensus node, each consensus node in the shard calls the Verify(r1,proof1,pk), Verify(r2,proof2,pk), and Verify(r3,proof3,pk) algorithms to verify that the three random numbers are truly randomly generated, and then broadcasts the corresponding core consensus node request to the consensus nodes in the shard.

[0121] S204. Within each shard, consensus nodes calculate the length L of their respective shard consensus node list, calculate the indices of the three consensus nodes c1 = r1 mod L, c2 = r2 mod L, c3 = r3 mod L, and determine the relationship between c1, c2, and c3:

[0122] If c1 and c2 are equal, increment the value of c2 by 1.

[0123] If c1 and c3 are equal, increment the value of c3 by 1;

[0124] If c2 and c3 are equal, increment the value of c3 by 1;

[0125] S205. Each consensus node within a shard obtains the information List[c1], List[c2], and List[c3] of the three core consensus nodes c1, c2, and c3 through the shard consensus node list and the corresponding index, and determines whether the three core consensus nodes c1, c2, and c3 contain its own node:

[0126] If the three core consensus nodes c1, c2, and c3 contain its own node, then Raft consensus will begin with the other two nodes.

[0127] If none of the three core consensus nodes c1, c2, and c3 contain their own node, then request the three core consensus nodes to distribute blocks.

[0128] S206. After the three core consensus nodes c1, c2 and c3 in the shard reach consensus, a block containing the request and core consensus node information in step S201 is generated as the shard initialization block, and the shard initialization block is distributed to the corresponding consensus nodes and accounting nodes; wherein, the node recording of the shard initialization block records the core consensus node information.

[0129] The specific details of the sharded transaction processing in step S3 of this embodiment are as follows:

[0130] S301. The user initiates a transaction request to the accounting node through the client;

[0131] S302. The accounting node extracts the user ID from the transaction request, calculates the hash value h of the user ID, and calculates the shard number n = h mod N. At the same time, it forwards the transaction request to the core consensus node in the corresponding shard.

[0132] S303. Upon receiving the request, the core consensus node within the shard reaches a consensus on the corresponding transaction using the Raft consensus algorithm, generates a block, and distributes the block to the remaining consensus nodes and ledger nodes; among them, the ledger nodes record the transaction information within the block.

[0133] The specific steps for handling core consensus node failures in step S4 of this embodiment are as follows:

[0134] S401. When one of the three core consensus nodes c1, c2 and c3 in any shard fails, the remaining two core consensus nodes reach a consensus on the faulty node, generate a core consensus node fault block, and distribute the core consensus node fault block to the accounting node and the other consensus nodes in the shard.

[0135] S402. The node that receives the faulty block of the core consensus node performs an alarm operation;

[0136] S403. After the administrator discovers the alarm, he calls the RandomGen(sk) algorithm to generate a random number, the RandomGen(sk) algorithm, the random number r, and the random number proof proof. He attaches the random number r, the random number proof proof, and the shard where the faulty node is located to the request to add a new core consensus node and sends them to the accounting node.

[0137] S404. After receiving a request to add a core consensus node, the accounting node obtains the sharding information and forwards the request to the core consensus node of the corresponding shard.

[0138] S405. After receiving a request to add a new core consensus node, the core consensus node of the corresponding shard calls the Verify(r,proof,pk) algorithm to verify that the random number is correctly generated. Then, it calculates the index c = r mod L of the consensus node using the length L of the consensus node list List within the shard. If the index of the consensus node is the same as the index of an existing core consensus node, it increments the index c = r mod L until it is different from the index of any core consensus node. The new index value is then appended to the request to add a new core consensus node to initiate Raft consensus.

[0139] S406. After the core consensus nodes reach Raft consensus on the request for a new core consensus node, they begin to accept the consensus node with the corresponding index value c = r mod L as a new core consensus node, generate a block containing the request in step S405 to add a core consensus node, and distribute the block to the accounting nodes and other consensus nodes.

[0140] S407. After receiving the block for adding a core consensus node, the other consensus nodes extract the information of the newly added core consensus node from the core consensus node block. If the newly added core consensus node is itself, it begins to conduct Raft consensus with the core consensus node of that area.

[0141] The cross-chip consensus process in step S5 of this embodiment is as follows:

[0142] S501: The administrator sends cross-shard consensus requests to the core consensus nodes of each shard through the client.

[0143] S502. Each core consensus node verifies the cross-shard consensus request from the administrator and, after reaching a consensus on the cross-shard consensus request, stops processing other transaction requests, generates a block containing the cross-shard consensus request, and distributes it to the accounting nodes and other consensus nodes within the shard.

[0144] S503. Whenever the accounting node receives a cross-shard consensus request block from a shard, it forwards the cross-shard consensus request block to the core consensus nodes of the other shards.

[0145] S504. When any core consensus node of any partition obtains the cross-shard consensus request blocks of all shards, it appends the hash values ​​of all the cross-shard consensus request blocks in ascending order and writes the hash value of the calculated appended value into the global state request.

[0146] S505, the core consensus nodes in the corresponding area use the Raft algorithm to reach a consensus on the corresponding global state request, generate a global state block (the hash of the previous block is the hash value of the additional value in step S504), and distribute the global state block to the accounting nodes and consensus nodes in the area to continue receiving transactions.

[0147] Example 2:

[0148] As attached Figure 1 As shown in the figure, this embodiment provides a method for selecting core consensus nodes, which is as follows:

[0149] (1) Generate the key required to verify the random number, set the corresponding configuration parameters for each consensus node, and start the blockchain node;

[0150] (2) Select the core consensus node within the shard;

[0151] (3) Transaction sharding: The accounting node shards the corresponding transaction, and the corresponding consensus node processes the transaction within the shard;

[0152] (4) Handling core consensus node failures;

[0153] (5) Cross-shard consensus: Since transactions in different shards do not affect each other, cross-shard consensus collects the hash value of the last block of each shard and processes it as the global state of the blockchain.

[0154] In step (1) of this embodiment, the key required to generate verifiable random numbers is generated, and corresponding configuration parameters are set for each consensus node. At the same time, the blockchain node is started as follows:

[0155] ① The key provider calls the key generation algorithm for verifiable random numbers: sk,pk = KeyGen(), to generate a private key sk and a public key pk for verifiable random numbers; and securely distributes the private key sk to the administrator and writes the public key pk into the configuration of all blockchain nodes;

[0156] ② The administrator determines the number of blockchain shards N, i.e., the N shards are 0, 1, 2, ..., N-1, and writes the number of shards N into the configuration of all blockchain nodes;

[0157] ③ Determine the consensus nodes within each shard, ensuring that the number of consensus nodes within each shard is no less than three; in the configuration of each consensus node, write the information of all consensus nodes in the same shard as the corresponding consensus node; in the accounting node, write the information of the consensus nodes of all shards.

[0158] ④ Start each blockchain node: After the consensus node is started, it calculates the hash value of the information of each consensus node in its shard, and sorts the consensus node information according to the hash value to form a sorted consensus node list.

[0159] In this embodiment, step (2) of selecting the core consensus node within the shard is as follows:

[0160] ① The administrator selects to send a core consensus node request. After the client reads the private key sk, it calls the RandomGen(sk) algorithm three times to generate three different random numbers r1, r2, r3 and proofs of the random numbers proof1, proof2, proof3. The random numbers r1, r2, r3 and proofs of the random numbers proof1, proof2, proof3 are attached to the request to randomly select a core consensus node and sent to the accounting node.

[0161] ② The accounting node directly forwards the request to each consensus node in the configuration;

[0162] ③ After receiving the request to select a core consensus node, each consensus node in the shard calls the Verify(r1,proof1,pk), Verify(r2,proof2,pk), and Verify(r3,proof3,pk) algorithms to verify that the three random numbers are truly randomly generated, and then broadcasts the corresponding core consensus node request to the consensus nodes in the shard.

[0163] ④ Each consensus node in a shard calculates the length L of its own shard's consensus node list, calculates the indices of the three consensus nodes c1 = r1 mod L, c2 = r2 mod L, c3 = r3 mod L, and determines the relationship between c1, c2, and c3:

[0164] If c1 and c2 are equal, increment the value of c2 by 1.

[0165] If c1 and c3 are equal, increment the value of c3 by 1;

[0166] If c2 and c3 are equal, increment the value of c3 by 1;

[0167] ⑤ Each consensus node within a shard obtains the information List[c1], List[c2], and List[c3] of the three core consensus nodes c1, c2, and c3 through the shard consensus node list and the corresponding index, and determines whether the three core consensus nodes c1, c2, and c3 contain its own node:

[0168] If the three core consensus nodes c1, c2, and c3 contain its own node, then Raft consensus will begin with the other two nodes.

[0169] If none of the three core consensus nodes c1, c2, and c3 contain their own node, then request the three core consensus nodes to distribute blocks.

[0170] ⑥ After the three core consensus nodes c1, c2 and c3 in the shard reach a consensus, a block containing the request and core consensus node information in step S201 is generated as the shard initialization block, and the shard initialization block is distributed to the corresponding consensus nodes and accounting nodes; wherein, the node recording of the shard initialization block records the core consensus node information.

[0171] In this embodiment, step (3) of sharding the transaction is as follows:

[0172] ① Users initiate transaction requests to the ledger nodes through the client;

[0173] ② The accounting node extracts the user ID from the transaction request, calculates the hash value h of the user ID, and calculates the shard number n = h mod N. At the same time, it forwards the transaction request to the core consensus node in the corresponding shard.

[0174] ③ Upon receiving the request, the core consensus node within the shard reaches a consensus on the corresponding transaction using the Raft consensus algorithm, generates a block, and distributes the block to the remaining consensus nodes and ledger nodes; among them, the ledger nodes record the transaction information within the block.

[0175] In this embodiment, step (4) for handling core consensus node failures is as follows:

[0176] ① When one of the three core consensus nodes c1, c2 and c3 in any shard fails, the remaining two core consensus nodes reach a consensus on the faulty node, generate a core consensus node fault block, and distribute the core consensus node fault block to the accounting node and the other consensus nodes in the shard.

[0177] ② Nodes that receive faulty blocks from core consensus nodes should perform alarm operations;

[0178] ③ After the administrator discovers the alarm, he calls the RandomGen(sk) algorithm to generate a random number, the RandomGen(sk) algorithm, the random number r, and the random number proof proof. He attaches the random number r, the random number proof proof, and the shard where the faulty node is located to the request to add a new core consensus node and sends it to the accounting node.

[0179] ④ After receiving a request to add a core consensus node, the accounting node obtains the sharding information and forwards the request to the core consensus node of the corresponding shard.

[0180] ⑤ After receiving a request to add a new core consensus node, the core consensus node of the corresponding shard calls the Verify(r,proof,pk) algorithm to verify that the random number is correctly generated. Then, it calculates the index of the consensus node c = r mod L based on the length L of the consensus node list List within the shard. If the index of the consensus node is the same as the index of an existing core consensus node, it increments the index c = r mod L until it is different from the index of any core consensus node. The new index value is then appended to the request to add a new core consensus node to initiate Raft consensus.

[0181] ⑥ After the core consensus nodes reach Raft consensus on the request for a new core consensus node, the consensus node with the corresponding index value c = r mod L is accepted as a new core consensus node. The block containing the request in step S405 is generated and distributed to the accounting nodes and other consensus nodes.

[0182] ⑦ After receiving the block for adding a core consensus node, the other consensus nodes extract the information of the newly added core consensus node from the core consensus node block. If the newly added core consensus node is itself, it begins to conduct Raft consensus with the core consensus node of that area.

[0183] In this embodiment, step (5) of cross-chip consensus is as follows:

[0184] ① The administrator sends cross-shard consensus requests to the core consensus nodes of each shard through the client;

[0185] ② Each core consensus node verifies the cross-shard consensus request from the administrator and, after reaching a consensus on the cross-shard consensus request, stops processing other transaction requests, generates a block containing the cross-shard consensus request, and distributes it to the accounting nodes and other consensus nodes within the shard.

[0186] ③ Each time a ledger node receives a cross-shard consensus request block from a shard, it forwards the cross-shard consensus request block to the core consensus nodes of the other shards;

[0187] ④ Once the core consensus node of any partition obtains the cross-shard consensus request blocks of all shards, it appends the hash values ​​of all the cross-shard consensus request blocks in ascending order and writes the hash value of the calculated appended value into the global state request.

[0188] ⑤ The core consensus nodes in the corresponding area reach a consensus on the corresponding global state request using the Raft algorithm, generate a global state block (the hash of the previous block is the hash value of the additional value in step S504), and distribute the global state block to the accounting nodes and consensus nodes in the area to continue receiving transactions.

[0189] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A fragmented permission chain system, characterized in that, The system includes consensus nodes, ledger nodes, and clients; Consensus nodes are divided into core consensus nodes and backup consensus nodes; after receiving a transaction and reaching a consensus, the core consensus node packages the transaction into a block and broadcasts it. The backup consensus node receives and stores the blocks broadcast by the core consensus node through secure channel communication; when the set conditions are met, the core consensus node and the backup consensus node switch roles with each other. Ledger nodes are used to record the blocks in each region and the corresponding ledger transaction information; The client is used to send various types of requests to consensus nodes and ledger nodes via secure channel communication; The working process of this system is as follows: S1. System initialization: Generate the key required to verify the random number, set the corresponding configuration parameters for each consensus node, and start the blockchain node. S2. Select the core consensus node within the shard; S3, Transaction Sharding: The accounting node shards the corresponding transaction, and the corresponding consensus node processes the transaction within its shard. S4. Handling core consensus node failures; S5, Cross-shard consensus: Cross-shard consensus collects the hash value of the last block of each shard, processes it, and uses it as the global state of the blockchain; The system initialization in step S1 is as follows: S101, The key provider invokes the key generation algorithm that can verify random numbers: Generate a private key sk and a public key pk that can verify random numbers; and securely distribute the private key sk to the administrator and write the public key pk into the configuration of all blockchain nodes; S102. Determine the number of blockchain shards N, i.e., N shards are 0, 1, 2, ..., N-1, and write the number of shards N into the configuration of all blockchain nodes; S103. Determine the consensus nodes within each shard, ensuring that the number of consensus nodes within each shard is not less than three; in the configuration of each consensus node, write the information of all consensus nodes in the same shard as the corresponding consensus node; in the accounting node, write the information of the consensus nodes of all shards. S104. Start each blockchain node: After the consensus node starts, it calculates the hash value of the information of each consensus node in its shard, and sorts the consensus node information according to the hash value to form a sorted consensus node list. The specific steps for selecting the core consensus node within the shard in step S2 are as follows: S201. The administrator selects to send a core consensus node request. After the client reads the private key sk, it calls three times. Algorithm to generate three distinct random numbers And the proof of random numbers and random number And the proof of random numbers Attached to the request for randomly selecting a core consensus node, it is sent to the ledger node; S202, The accounting node directly forwards the request to each consensus node in the configuration; S203. After receiving the request to select a core consensus node, each consensus node in a shard calls... After the algorithm verifies that the three random numbers are indeed generated randomly, it broadcasts the request of the corresponding core consensus node to the consensus nodes within the shard. S204. Each consensus node in a shard calculates the length of its respective shard's consensus node list. Calculate the indices of the three consensus nodes. and judge , and The relationship between them: like and If the values ​​are equal, let The value increments by 1. like and If the values ​​are equal, let The value increments by 1. like and If the values ​​are equal, let The value increments by 1. S205. The consensus nodes within each shard obtain the consensus node list and corresponding index of the shard. , and Information from the three core consensus nodes and judge , and Do the three core consensus nodes include their own nodes? like , and If the three core consensus nodes include its own node, then Raft consensus will begin with the other two nodes; like , and If none of the three core consensus nodes contain its own node, then the request is made to the three core consensus nodes to distribute blocks; S206, Within a Fragment , and After the three core consensus nodes reach a consensus, a block containing the request and core consensus node information in step S201 is generated as the sharding initialization block, and the sharding initialization block is distributed to the corresponding consensus nodes and accounting nodes; wherein, the node of the sharding initialization block records the core consensus node information.

2. The fragmented permissioned chain system according to claim 1, characterized in that, The specific details of the sharded transaction processing in step S3 are as follows: S301. The user initiates a transaction request to the accounting node through the client; S302. The accounting node extracts the user ID from the transaction request, calculates the hash value h of the user ID, and calculates the shard number n = h mod N. At the same time, it forwards the transaction request to the core consensus node in the corresponding shard. S303. Upon receiving the request, the core consensus node within the shard reaches a consensus on the corresponding transaction using the Raft consensus algorithm, generates a block, and distributes the block to the remaining consensus nodes and ledger nodes; among them, the ledger nodes record the transaction information within the block.

3. The fragmented permission chain system according to claim 1 or 2, characterized in that, The specific steps for handling core consensus node failures in step S4 are as follows: S401, within any segment , and When one of the three core consensus nodes fails, the remaining two core consensus nodes reach a consensus on the failed node, generate a core consensus node failure block, and distribute the core consensus node failure block to the accounting node and the other consensus nodes in the shard. S402. The node that receives the faulty block of the core consensus node performs an alarm operation; S403, After the administrator discovers the alarm, call... Algorithm for generating random numbers Algorithm, random number and proof of random numbers , random number Proof of random numbers The shard containing the faulty node is attached to the request for a new core consensus node and sent to the accounting node. S404. After receiving a request to add a core consensus node, the accounting node obtains the sharding information and forwards the request to the core consensus node of the corresponding shard. S405: After receiving the request to add a new core consensus node, the corresponding core consensus node in the shard calls... After the algorithm verifies that the random number has been correctly generated, the length of the consensus node list (List) within the shard is used as the criterion. Calculate the index of the consensus node When the consensus node index is the same as the index of the existing core consensus node, the index of the consensus node... It increments until it differs from the index of any core consensus node; The new index value is then appended to the request for a new core consensus node to initiate Raft consensus. After core consensus nodes, such as S406, reach Raft consensus on the request of newly added core consensus nodes, they begin to accept the corresponding index values. The consensus node becomes the new core consensus node, generates the add core consensus node block containing the request in step S405, and distributes the block to the accounting node and the remaining consensus nodes. S407. After receiving the block for adding a core consensus node, the other consensus nodes extract the information of the newly added core consensus node from the core consensus node block. If the newly added core consensus node is itself, it begins to conduct Raft consensus with the core consensus node of that area.

4. The fragmented permission chain system according to claim 3, characterized in that, The cross-slice consensus process in step S5 is as follows: S501: The administrator sends cross-shard consensus requests to the core consensus nodes of each shard through the client. S502. Each core consensus node verifies the cross-shard consensus request from the administrator and, after reaching a consensus on the cross-shard consensus request, stops processing other transaction requests, generates a block containing the cross-shard consensus request, and distributes it to the accounting nodes and other consensus nodes within the shard. S503. Whenever the accounting node receives a cross-shard consensus request block from a shard, it forwards the cross-shard consensus request block to the core consensus nodes of the other shards. S504. When any core consensus node of any partition obtains the cross-shard consensus request blocks of all shards, it appends the hash values ​​of all the cross-shard consensus request blocks in ascending order and writes the hash value of the calculated appended value into the global state request. S505 and other core consensus nodes within the corresponding area use the Raft algorithm to reach a consensus on the corresponding global state request, generate a global state block, and distribute the global state block to the accounting nodes and consensus nodes within the area to continue receiving transactions.

5. A method for selecting core consensus nodes, characterized in that, The method is as follows: (1) Generate the key required to verify the random number, set the corresponding configuration parameters for each consensus node, and start the blockchain node; (2) Select the core consensus node within the shard; (3) Transaction sharding: The accounting node shards the corresponding transaction, and the corresponding consensus node processes the transaction within the shard; (4) Handling core consensus node failures; (5) Cross-shard consensus: Cross-shard consensus collects the hash value of the last block of each shard, processes it and uses it as the global state of the blockchain; In step (1), the key required to generate verifiable random numbers is generated, and corresponding configuration parameters are set for each consensus node. At the same time, the blockchain node is started as follows: ① The key provider calls a key generation algorithm that can verify random numbers: Generate a private key sk and a public key pk that can verify random numbers; and securely distribute the private key sk to the administrator and write the public key pk into the configuration of all blockchain nodes; ② The administrator determines the number of blockchain shards N, i.e., the N shards are 0, 1, 2, ..., N-1, and writes the number of shards N into the configuration of all blockchain nodes; ③ Determine the consensus nodes within each shard, ensuring that the number of consensus nodes within each shard is no less than three; in the configuration of each consensus node, write the information of all consensus nodes in the same shard as the corresponding consensus node; in the accounting node, write the information of the consensus nodes of all shards. ④ Start each blockchain node: After the consensus node starts, it calculates the hash value of the information of each consensus node in its shard, and sorts the consensus node information according to the hash value to form a sorted consensus node list. Step (2) Selecting the core consensus node within the shard is as follows: ① The administrator selects to send a core consensus node request. After the client reads the private key sk, it calls three times. Algorithm to generate three distinct random numbers And the proof of random numbers and random number And the proof of random numbers Attached to the request for randomly selecting a core consensus node, it is sent to the ledger node; ② The accounting node directly forwards the request to each consensus node in the configuration; ③ After receiving the request to select a core consensus node, each consensus node in a shard calls... After the algorithm verifies that the three random numbers are indeed generated randomly, it broadcasts the request of the corresponding core consensus node to the consensus nodes within the shard. ④ Each consensus node within a shard calculates the length of its own shard's consensus node list. Calculate the indices of the three consensus nodes. And judge , and The relationship between them: like and If the values ​​are equal, let The value increments by 1. like and If the values ​​are equal, let The value increments by 1. like and If the values ​​are equal, let The value increments by 1. ⑤ Each consensus node within a shard obtains the consensus node information through the shard consensus node list and its corresponding index. , and Information from the three core consensus nodes and judge , and Do the three core consensus nodes include their own nodes? like , and If the three core consensus nodes include its own node, then Raft consensus will begin with the other two nodes; like , and If none of the three core consensus nodes contain its own node, then the request is made to the three core consensus nodes to distribute blocks; ⑥ Within the segment , and After the three core consensus nodes reach a consensus, a block containing the request and core consensus node information in step S201 is generated as the sharding initialization block, and the sharding initialization block is distributed to the corresponding consensus nodes and accounting nodes; wherein, the node of the sharding initialization block records the core consensus node information.

6. The method for selecting core consensus nodes according to claim 5, characterized in that, Step (3) sharding the transaction is as follows: ① Users initiate transaction requests to the ledger nodes through the client; ② The accounting node extracts the user ID from the transaction request, calculates the hash value h of the user ID, and calculates the shard number n = h mod N. At the same time, it forwards the transaction request to the core consensus node in the corresponding shard. ③ Upon receiving the request, the core consensus node within the shard reaches a consensus on the corresponding transaction using the Raft consensus algorithm, generates a block, and distributes the block to the remaining consensus nodes and ledger nodes; among them, the ledger nodes record the transaction information within the block; Step (4) for handling core consensus node failures is as follows: ① Within any segment , and When one of the three core consensus nodes fails, the remaining two core consensus nodes reach a consensus on the failed node, generate a core consensus node failure block, and distribute the core consensus node failure block to the accounting node and the other consensus nodes in the shard. ② Nodes that receive faulty blocks from core consensus nodes should perform alarm operations; ③ After the administrator discovers the alarm, call... Algorithm for generating random numbers Algorithm, random number and proof of random numbers , random number Proof of random numbers The shard containing the faulty node is attached to the request for a new core consensus node and sent to the accounting node. ④ After receiving a request to add a core consensus node, the accounting node obtains the sharding information and forwards the request to the core consensus node of the corresponding shard. ⑤ After receiving the request to add a new core consensus node, the corresponding shard's core consensus node calls... After the algorithm verifies that the random number has been correctly generated, the length of the consensus node list (List) within the shard is used as the criterion. Calculate the index of the consensus node When the consensus node index is the same as the index of the existing core consensus node, the index of the consensus node... The index is incremented until it differs from the index of any core consensus node; the new index value is then appended to the request for a new core consensus node to initiate Raft consensus. ⑥ After the core consensus nodes reach Raft consensus on the request of the newly added core consensus nodes, the corresponding index value will be accepted. The consensus node becomes the new core consensus node, generates the add core consensus node block containing the request in step S405, and distributes the block to the accounting node and the remaining consensus nodes. ⑦ After receiving the block for adding a core consensus node, the other consensus nodes extract the information of the newly added core consensus node from the core consensus node block. If the newly added core consensus node is itself, it starts to conduct Raft consensus with the core consensus node of that area. Step (5) Cross-slice consensus is as follows: ① The administrator sends cross-shard consensus requests to the core consensus nodes of each shard through the client; ② Each core consensus node verifies the cross-shard consensus request from the administrator and, after reaching a consensus on the cross-shard consensus request, stops processing other transaction requests, generates a block containing the cross-shard consensus request, and distributes it to the accounting nodes and other consensus nodes within the shard. ③ Each time a ledger node receives a cross-shard consensus request block from a shard, it forwards the cross-shard consensus request block to the core consensus nodes of the other shards; ④ Once the core consensus node of any partition obtains the cross-shard consensus request blocks of all shards, it appends the hash values ​​of all the cross-shard consensus request blocks in ascending order and writes the hash value of the calculated appended value into the global state request. ⑤ Once the core consensus nodes within the corresponding area reach a consensus on the corresponding global state request using the Raft algorithm, a global state block is generated, and the global state block is distributed to the accounting nodes and consensus nodes within the area to continue receiving transactions.

Images