A blockchain sharding method based on secret handshake

Abstract

The present application relates to the technical field of blockchain, more particularly, to a secret handshake-based blockchain sharding method. The sharded blockchain is naturally formed through secret handshake technology, and both the user and the blockchain node only know the information of the shard they belong to, hiding the information of other shards, thereby improving the privacy of the shard. In addition, thanks to the internal relationship of the DAG graph, the blocks in the shard can be confirmed by all blockchain nodes, thereby improving the consensus speed of the blocks in the shard.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchain, more particularly, to a blockchain sharding method based on secret handshake. BACKGROUND

[0002] Sharding technology is one of the blockchain expansion technologies. Sharding refers to dividing blockchain nodes into different partitions according to certain rules, and nodes in each partition maintain the blockchain ledger in the partition, and each partition can independently and in parallel complete consensus, thereby increasing the transaction throughput of the blockchain system. The current common sharding technologies include network sharding, state sharding and transaction sharding, etc., but few sharding technologies consider the privacy security of sharding, thereby causing privacy leakage in the sharding process.

[0003] Secret handshake technology allows individuals belonging to the same organization to perform mutual authentication, and the authentication process does not disclose the privacy of both parties. This feature makes secret handshake technology widely used in Internet user authentication scenarios. SUMMARY

[0004] The present application provides a blockchain sharding method based on secret handshake to overcome the defects in the prior art, which improves the privacy of sharding and also improves the consensus speed of the sharding block.

[0005] To solve the above technical problems, the technical scheme adopted by the present application is: a blockchain sharding method based on secret handshake, including three types of entities of blockchain nodes CN, users U sending transactions and group management nodes GA, there is an effective point-to-point network between the blockchain nodes and the users, and there is a secure channel between the blockchain nodes and the users and the management nodes; wherein the blockchain nodes have n, the users have l, and the GA have m, m, n and l are natural numbers; the blockchain nodes CN i and the users U j register with the GA k through the secure channel and obtain the credentials of the GA k respectively. and wherein 1≤i≤n, 1≤j≤l, 1≤k≤m; comprising the following steps:

[0006] S1. The user performs a secret handshake protocol with the neighbor nodes in the point-to-point network and sends an encrypted transaction;

[0007] S2. The blockchain node re-encrypts and forwards the valid transaction of the user, and packages the valid transaction;

[0008] S3. The blockchain node publishes a block, participates in a directed acyclic graph (DAG) consensus, and updates the DAG blockchain;

[0009] S4. When a new block that has reached consensus appears in the DAG chain, the blockchain node and the block producer execute a secret handshake protocol to update the sharded blockchain.

[0010] In one embodiment, step S1 specifically includes:

[0011] S11. Let user U i The user sends data to neighboring blockchain nodes in the peer-to-peer network. Send handshake message

[0012] S12. User U j Neighboring blockchain nodes Return handshake message

[0013] S13. User U j and belong to the same group of management nodes (GA) k Neighboring blockchain nodes Generate shared key

[0014] S14. Using a shared key Secure symmetric encryption algorithm for encrypted transactions Obtaining crypto transactions

[0015] S15. User U j To the same group of management nodes (GA) k Neighboring blockchain nodes Send encrypted transaction

[0016] In one embodiment, step S2 specifically includes:

[0017] S21. Blockchain Node Received user U j Crypto transactions Employing a symmetric decryption algorithm and a shared key Decryption Get user U j transactions

[0018] S22. Blockchain Node Verify user transactions according to blockchain verification rules. The validity of the transaction, if the transaction If invalid, processing will stop; otherwise, the user transaction will be considered valid.

[0019] S23. Blockchain Node If no valid user transaction has been forwarded yet then the neighbor blockchain nodes of the blockchain node CN perform a secret handshake protocol, and the user transaction is encrypted by a shared key generated by the secret handshake protocol and re-encrypted; wherein the process of performing a secret handshake between the blockchain nodes is the same as the process of performing a secret handshake between the user and the blockchain node, see steps S11 to S14; in addition, the blockchain nodes belonging to the same group of management nodes can re-encrypt multiple valid user transactions using the shared key generated by the secret handshake after establishing a secret handshake, and do not need to perform a secret handshake protocol for each user transaction;

[0020] S24. The blockchain node CN generates a block encryption key for the block B encrypts the user transaction using the key and a secure symmetric encryption algorithm, and packs the encrypted user transaction into the block B.

[0021] In one embodiment, the step S3 specifically comprises:

[0022] S31. Set a system threshold t B When the number of encrypted transactions packed in the block by the blockchain node CN i exceeds the system threshold t B , the blockchain node CN i sets a block header, which contains the handshake message of the blockchain node CN i , the link of the two latest blocks in the DAG chain, and consensus information, and then broadcasts the complete block to all blockchain nodes through a point-to-point network; the handshake message in this step has the same meaning as the handshake message in step S11, which is the first message of the secret handshake protocol;

[0023] S32. After receiving the block, the blockchain node CN i completes the DAG consensus process according to the consensus information in the block header, and updates the DAG blockchain.

[0024] In one embodiment, the step S4 specifically comprises:

[0025] S41. For the new block that reaches consensus in the DAG chain, if the blockchain node CN i checks that the new block is not generated by itself, it sends a secret handshake message to the generator of the new block using the handshake information in the block header; the secret handshake message sent to the generator of the new block in this step has the same meaning as the handshake message in step S12, which is the second message of the secret handshake;

[0026] S42. After receiving the secret handshake message, if the requestor and the generator belong to the same group of management nodes, the generator generates a shared key, and returns a block encryption key encrypted by the shared key and a secure symmetric encryption algorithm, otherwise the process is aborted; the shared key in this step has the same meaning as the shared key in step S13, which is the shared key generated by the secret handshake protocol;

[0027] S43. The blockchain node CN i After obtaining the block encryption key, decrypt and verify the validity of the block, if the block is valid, update the shard blockchain, that is, append the decrypted plaintext block PB to the local blockchain, otherwise abort the process.

[0028] In one embodiment, the management node GA k creates a group G k , G k , G k′ are cyclic groups of order q, define a bilinear mapping e: G k ×G k →G k′ , for all a, b∈Z q , P, Q∈G k , e(aP, bQ) = e(P, Q) ab ; define hash functions H1 and H2, where H1: {0, 1} * →G k , H2 is the SHA-1 function;

[0029] If a new blockchain node CN i or a user U j joins shard k, GA k allocates credentials and including group identity and group secret information including group identity and group secret information When a node in a shard is to be removed, GA k broadcasts the group identity of the node to other nodes in the shard, and warns the nodes in the shard not to handshake with the node;

[0030] wherein the user U j and the neighboring blockchain nodes in the peer-to-peer network The secret handshake process includes:

[0031] The user U j generates and broadcasts a handshake transaction

[0032] Neighbor blockchain node Receiving After that, sending own group identity and random number to user U j ;

[0033] User U j receiving and after that, sending back own group identity random number and message wherein,

[0034] Neighbor blockchain node after receiving user's response, generating verifying whether it is equal to if equal, responding with message if verification is not equal, not responding;

[0035] User U j receiving after that, verifying whether it is equal to if equal, user U j and chain node complete secret handshake; if verification is not equal, handshake fails.

[0036] In one of the embodiments, blockchain node CN i locally establishes block data pool, block database, and hash confirmation list; the local block data pool stores block hash values that have not reached consensus, the local block database stores block hashes that have reached consensus, and the hash confirmation list stores the number of confirmations for each block hash; the DAG consensus process of the block includes:

[0037] Blockchain node CN i stores the hash value of the block in the local block data pool after packaging a block, and adds node CN i as the confirmation node of the block hash in the local hash confirmation list, and initializes a hash list including the hash value of the block and the identity i of node CN encapsulates the hash list as consensus information into the block header; the complete block is broadcast to all blockchain nodes through the point-to-point network;

[0038] Blockchain node CN iUpon receiving a block, the local block data pool and hash confirmation list are updated based on the consensus information in the block header. Specifically, if a new block is received, the block hash from the consensus information is stored in the local block data pool, and node CN is added to the local hash confirmation list. i The local hash confirmation list contains a number of confirmation nodes for the block hash; when the number of confirmation nodes for the block hash in the local hash confirmation list is greater than or equal to... Then the block hash is stored in the local block database and deleted from the block data pool and hash confirmation list;

[0039] Blocks stored in the local block database achieve consensus, and the blocks in the block database form a DAG blockchain based on their link relationships.

[0040] In one embodiment, the symmetric encryption algorithm includes the AES-CCM algorithm, using the handshake message during the secret handshake as the key, that is, in steps S12 and S13, the key is... As a shared key

[0041] In one embodiment, digital signatures are used to verify the validity of user transactions; User U j Generate a transfer transaction Includes timestamp, transaction type, transfer amount, target user identity, and user U. j Signature of transaction content; User U j Perform a secret handshake protocol with neighboring nodes in the peer-to-peer network to obtain a shared key. Transaction encryption using a symmetric encryption algorithm. Obtaining crypto transactions User U j To the same group of management nodes (GA) k Neighboring blockchain nodes Send encrypted transaction Blockchain Node Received user U j Crypto transactions Employing a symmetric decryption algorithm and a shared key Decryption Get user U j transactions Then blockchain node Verify user transactions according to the following blockchain verification rules. Validity:

[0042] Check if the transaction signature is valid. If it is valid, continue with the following checks.

[0043] If the user makes a transaction If the transaction type of the transaction is a transfer transaction, it is checked whether the transfer amount is a non-negative number. If yes, the following checks are continued. If no, the transaction is invalid .

[0044] It is checked whether the user U j 's blockchain account balance is greater than or equal to the transfer amount. If yes, the following checks are continued. If no, the transaction is invalid .

[0045] It is checked whether the target user is a user of the blockchain. If yes, the transaction is valid. If no, the transaction is invalid . .

[0046] In one embodiment, the validity of the block is verified by verifying the validity of each user transaction in the block. In step S43, the blockchain node CN i , after obtaining the block encryption key, decrypts the block to obtain t B decrypted user transactions. If all the t B user transactions are valid, the block is valid. Otherwise, the block is invalid.

[0047] Compared with the prior art, the beneficial effects are: the blockchain sharding method based on secret handshake provided by the present application is naturally formed by secret handshake technology. The user and the blockchain node only know the information of the shard they belong to, and hide the information of other shards, thereby improving the privacy of the shard. In addition, thanks to the internal relationship of the DAG graph, the blocks in the shard can be confirmed by all blockchain nodes, thereby improving the consensus speed of the blocks in the shard. BRIEF DESCRIPTION OF DRAWINGS

[0048] Figure 1 is a schematic diagram of the user and the blockchain node registering with the management node.

[0049] Figure 2 is a schematic diagram of the formation of the sharded blockchain. DETAILED DESCRIPTION

[0050] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, not all the embodiments. The present application will be described below in one embodiment in conjunction with the specific embodiments. The drawings are only used for illustrative description, and the representation is only a schematic diagram, not a physical diagram, and cannot be understood as a limitation of the present patent. Some components in the drawings may be omitted, enlarged or reduced, and do not represent the actual size of the product. It is understandable for those skilled in the art that some known structures and their descriptions in the drawings may be omitted.

[0051] Embodiment I:

[0052] A blockchain sharding method based on secret handshake, including three types of entities: blockchain nodes CN, users U sending transactions, and group management nodes GA, there is an effective point-to-point network between the blockchain nodes and the users, and there is a secure channel between the blockchain nodes and the users and the management nodes; wherein the blockchain nodes have n, the users have l, and the GA have m, m, n, and l are natural numbers; the blockchain nodes CN i and the users U j register with the GA k through the secure channel, and obtain the credentials of the GA k respectively and wherein 1≤i≤n, 1≤j≤l, and 1≤k≤m; including the following steps:

[0053] Step 1. The user performs a secret handshake protocol with the neighbor nodes in the point-to-point network and sends an encrypted transaction; step S1 specifically includes:

[0054] S11. Let the user be U j , the user sends a handshake message to the neighbor blockchain nodes in the point-to-point network

[0055] S12. The neighbor blockchain nodes of the user U j return a handshake message

[0056] S13. The user U j generates a shared key with the neighbor blockchain nodes belonging to the same group management node GA k

[0057] S14. Encrypt the transaction using the shared key and a secure symmetric encryption algorithm to obtain an encrypted transaction

[0058] S15. The user U j sends the encrypted transaction to the neighbor blockchain nodes belonging to the same group management node GA k

[0059] Step 2. The blockchain nodes re-encrypt and forward the valid transactions of the users, and package the valid transactions; step S2 specifically includes:

[0060] S21. The blockchain nodes ​​Receiving an encrypted transaction of a user U j Using a symmetric decryption algorithm and a shared key Decrypting Obtaining a transaction of a user U j

[0061] S22. A blockchain node Verifying the validity of a user transaction according to the verification rule of the blockchain If the transaction is invalid, stop processing, otherwise determine it as a valid user transaction

[0062] S23. A blockchain node If it has not forwarded a valid user transaction Perform a secret handshake protocol with a neighbor blockchain node of the blockchain node Encrypt the user transaction using the shared key generated by the secret handshake protocol Forward the re-encrypted valid user transaction; wherein the process of performing a secret handshake between blockchain nodes is the same as that of performing a secret handshake between a user and a blockchain node, see steps S11 to S14; in addition, blockchain nodes belonging to the same group of management nodes can re-encrypt multiple valid user transactions using the shared key generated by the secret handshake after establishing a secret handshake once, without having to perform a secret handshake protocol for each user transaction

[0063] S24. A blockchain node Generate a block encryption key for block B Each time a valid user transaction is obtained, encrypt the user transaction using the key and a secure symmetric encryption algorithm, and pack the encrypted user transaction into block B.

[0064] Step 3. The blockchain node publishes the block, participates in the directed acyclic graph (DAG) consensus, and updates the DAG blockchain; step S3 specifically includes:

[0065] S31. Set the system threshold t B When the number of encrypted transactions packed in the block by the blockchain node CN i exceeds the system threshold t B The blockchain node CN i sets the block header, which contains the handshake message of the blockchain node CN i , the link of the two latest blocks in the current DAG chain, and the consensus information, and then broadcasts the complete block to all blockchain nodes through the point-to-point network; the handshake message in this step has the same meaning as the handshake message in step S11, which is the first message of the secret handshake protocol ​​​

[0066] S32. The blockchain node CN i After receiving the block, the DAG consensus process is completed according to the consensus information in the block header, and the DAG blockchain is updated.

[0067] Step 4. When a new block reaching consensus appears in the DAG chain, the blockchain node performs a secret handshake protocol with the generator of the block to update the shard blockchain; step S4 specifically includes:

[0068] S41. For the new block reaching consensus in the DAG chain, the blockchain node CN i If it is checked that the new block is not generated by itself, the handshake information in the block header is used to send a secret handshake message to the generator of the new block; the secret handshake message sent to the generator of the new block in this step has the same meaning as the handshake message in step S12, which is the second message of the secret handshake;

[0069] S42. After receiving the secret handshake message, if the requestor and the generator belong to the same group of management nodes, the generator generates a shared key and returns a block encryption key encrypted by the shared key and a secure symmetric encryption algorithm, otherwise the process is aborted; in this step, the shared key has the same meaning as the shared key in step S13, which is the shared key generated by the secret handshake protocol;

[0070] S43. The blockchain node CN i After obtaining the block encryption key, the validity of the block is decrypted and verified, and if the block is valid, the shard blockchain is updated, that is, the decrypted plaintext block PB is appended to the local blockchain, otherwise the process is aborted.

[0071] In embodiment 1, the consensus method of the DAG chain, the specific implementation of the secret handshake protocol, the symmetric encryption algorithm used, the method of verifying the validity of the user transaction, and the method of verifying the validity of the block are not specified.

[0072] Embodiment 2

[0073] In this embodiment, the secret handshake scheme based on bilinear pairings proposed by Dirk Balfanz et al. in the paper “Secret Handshakes from Pairing-Based Key Agreements” published in 2003 is adopted.

[0074] The management node GA k Create a group G k , G k , G k ′ are cyclic groups of order q, a large prime number, and define a bilinear mapping e: G k ×G k →G ke(aP, bQ) = e(P, Q) for all a, b∈Z q P, Q∈G k satisfying e(aP, bQ) = e(P, Q) ab Define hash functions H1 and H2, where H1: {0,1} * → G k H2 is the SHA-1 function.

[0075] If a new blockchain node CN i or a user U j joins the shard k, GA k allocates a credential and including the group identity and the group secret information including the group identity and the group secret information When a node in the shard is to be removed, GAk broadcasts the group identity of the node to other nodes in the shard, and warns the nodes in the shard not to handshake with the node.

[0076] User U j and the neighbor blockchain node in the peer-to-peer network secret handshake process is as follows:

[0077] (1) User U j generates and broadcasts a handshake transaction

[0078] (2) The neighbor blockchain node receives and sends its own group identity and a random number to the user U j ;

[0079] (3) User U j receives and and responds with its own group identity random number and a message, wherein

[0080] (4) After receiving the user's response, the neighbor blockchain node generates verifies whether it is equal to If equal, respond with the message If the verification is not equal, do not respond;

[0081] (5) User Uj receive Afterwards, verification Is it equal to If they are equal, then user U j and chain nodes Complete the secret handshake. If the verification results are not equal, the handshake fails.

[0082] Example 3

[0083] This embodiment specifies one implementation method for DAG consensus. Blockchain node CN i A local block data pool, a block database, and a hash confirmation list are established. The local block data pool stores the hash values ​​of blocks that have not reached consensus, the local block database stores the hashes of blocks that have reached consensus, and the hash confirmation list stores the confirmation count for each block hash. This embodiment uses the SHA256 hash function.

[0084] The consensus process for blocks is as follows:

[0085] (1) Blockchain Node CN i For each block packaged, the hash value of that block is stored in the local block data pool, and a node CN is added to the local hash confirmation list. i This node confirms the hash of this block. It also initializes a hash list, including the hash value of the block and the node's CN. i identity The hash list is encapsulated as consensus information in the block header. The complete block is then broadcast to all blockchain nodes via a peer-to-peer network.

[0086] (2) Blockchain Node CN i Upon receiving a block, the local block data pool and hash confirmation list are updated based on the consensus information in the block header. Specifically, if a new block is received, the block hash from the consensus information is stored in the local block data pool, and node CN is added to the local hash confirmation list. i These are the confirming nodes for the block hash. When the number of confirming nodes for the block hash in the local hash confirming list is greater than or equal to... The block hash is then stored in the local block database and deleted from the block data pool and hash confirmation list.

[0087] Blocks stored in the local block database achieve consensus, and the blocks in the block database form a DAG blockchain based on their link relationships.

[0088] Example 4

[0089] In this embodiment, the symmetric encryption algorithm used in this invention is specified as the AES-CCM algorithm given in RFC6655, and the handshake message during the secret handshake is used as the key. That is, in embodiment 1, in steps S12 and S13, the key is... As a shared key

[0090] Example 5

[0091] In step S22 of Example 1, different user transaction validity checks are required depending on the type of user transaction. In this example, ECDSA digital signature is used.

[0092] User U j Generate a transfer transaction Includes timestamp, transaction type, transfer amount, target user identity, and user U. j Signature of the transaction details. User U j Perform a secret handshake protocol with neighboring nodes in the peer-to-peer network to obtain a shared key. Transaction encryption using a symmetric encryption algorithm. Obtaining crypto transactions User U j To the same group of management nodes (GA) k Neighboring blockchain nodes Send encrypted transaction Blockchain Node Received user U j Crypto transactions Employing a symmetric decryption algorithm and a shared key Decryption Get user U j transactions Then blockchain node Verify user transactions according to the following blockchain verification rules. Validity:

[0093] (1) Check if the transaction signature is valid. If it is valid, continue with the following checks.

[0094] (2) If the user makes a transaction If the transaction type is a transfer transaction, then check if the transfer amount is non-negative. If yes, continue with the following checks; otherwise, the transaction... invalid;

[0095] (3) Check user U j Check if the blockchain account balance is greater than or equal to the transfer amount. If yes, continue with the following checks; otherwise, the transaction... invalid;

[0096] (4) check whether the target user is a user of the blockchain, if yes, the transaction is valid, if not, the transaction is invalid.

[0097] Embodiment 6

[0098] In this embodiment, the validity of each user transaction in the block is verified to verify the validity of the block.

[0099] In step S43 in Embodiment 1, the blockchain node CN i After obtaining the block encryption key, the block is decrypted to obtain t B valid user transactions, if the t B user transactions are all valid, the block is valid, otherwise the block is invalid.

[0100] Obviously, the above embodiments of the present application are merely exemplary for clearly illustrating the present application, and are not intended to limit the embodiments of the present application. Based on the above description, other different forms of changes or variations can be made by those skilled in the art. Here, it is not necessary and also impossible to enumerate all the embodiments. Any modification, equivalent replacement and improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the claims of the present application.

Claims

1. A method for blockchain sharding based on secret handshake, characterized in that, Comprising blockchain nodes , users sending transactions and group management nodes Three kinds of entities, there is an effective point-to-point network between blockchain nodes and users, and there is a secure channel between blockchain nodes and users and management nodes; wherein the blockchain nodes have , the users have , and the GA has , Natural number; the blockchain nodes and the users Register through the secure channel , respectively, to obtain Credentials and , wherein , , ; comprising the following steps: S1. The user performs a secret handshake protocol with a neighbor node in the point-to-point network, sends an encrypted transaction; S2. The blockchain node re-encrypts and forwards the user's valid transaction, and packages the valid transaction; S3. The blockchain node publishes a block and participates in a directed acyclic graph (DAG) consensus, updating the DAG blockchain; When a new block that reaches consensus appears in the DAG chain, the blockchain node performs a secret handshake protocol with the generator of the block, updating the sharded blockchain; Wherein, the management node creates a group , is a cyclic group with a large prime number as the order, defines a bilinear mapping , for all , satisfies ; defines hash functions and , wherein , is a SHA-1 function; If a new blockchain node or user joins a shard , it is assigned a credential and , which includes a group identity and group secret information , which includes a group identity and group secret information ; when a node within a shard is to be removed, the group identity of the node is broadcast to other nodes within the shard, and the nodes within the shard are warned not to handshake with the node; wherein the user and the neighbor blockchain nodes in the point-to-point network The secret handshake procedure comprises: User Generating and broadcasting handshake transactions ; Neighbor blockchain node , receiving After that, the group identity and the random number of the user are sent to the user User Receiving And After that, respond to their own group identity , random number And message , in which ; Neighbor blockchain node Upon receiving the user response, a message is generated , verifying whether it is equal to , and if so, responding with a message ; if the verification is not equal, no response is sent. user received , the user is verified whether equal to , if equal, the user and the chain node complete a secret handshake; if the verification is not equal, the handshake fails; In addition, the blockchain node locally establish a block data pool, a block database, and a hash confirmation list; the local block data pool stores block hashes that have not reached consensus, the local block database stores block hashes that have reached consensus, and the hash confirmation list stores the number of confirmations for each block hash; the DAG consensus process of the block includes: Blockchain node Upon packaging a block, the hash value of the block is stored in the local block data pool, and the node is added to the local hash confirmation list For the block hash confirmation node, and initialize a hash list including the hash value of the block and the node Identity of the node Encapsulate the hash list as consensus information into the block header; the complete block is broadcast to all blockchain nodes through the point-to-point network; Blockchain node After receiving the block, the local block data pool and the hash confirmation list are updated according to the consensus information in the block header, specifically: if the received block is a new block, the block hash in the consensus information is stored in the local block data pool, and the confirmation nodes of the block hash are added to the local hash confirmation list; when the number of confirmation nodes of the block hash in the local hash confirmation list is greater than or equal to , the block hash is stored in the local block database, and the block data pool and the hash confirmation list are deleted; ​ The blocks stored in the local block database complete consensus, and the blocks in the block database form a DAG blockchain according to the link relationship.

2. The secret handshake based blockchain sharding method of claim 1, wherein, The step S1 specifically comprises: S11. Set the user as a neighbor to the blockchain node in the point-to-point network sending a handshake message , ; S12. User of the neighbor blockchain node returns the handshake message , ; S13. User S14. Neighbor blockchain node belonging to the same group of management nodes S15. Generating a shared key S16. Sharing the shared key , ; S14. Use the shared key and a secure symmetric encryption algorithm to encrypt the transaction , obtaining an encrypted transaction , ; S15. User Sends an encrypted transaction to a neighbor blockchain node belonging to the same group of managing nodes .​​ 3. The secret handshake based blockchain sharding method of claim 2, wherein, The step S2 specifically comprises: S21. Blockchain Node Received user Crypto transactions It employs a symmetric decryption algorithm and a shared key. Decryption To acquire users transactions ; S22. Blockchain Node Verify user transactions according to blockchain verification rules. The validity of the transaction, if the transaction If invalid, processing will stop; otherwise, the user transaction will be considered valid. S23. A blockchain node If a valid user transaction has not yet been forwarded then performing a secret handshake protocol with a neighbour blockchain node of the blockchain node encrypting the user transaction using a shared key resulting from the secret handshake protocol forwarding the re-encrypted user valid transaction; S24. blockchain node To block A block encryption key is generated Each time a valid user transaction is received, the key The user transaction is encrypted using a secure symmetric encryption algorithm and packaged into a block .

4. The secret handshake based blockchain sharding method of claim 3, wherein, The step S3 specifically comprises: S31. Set system threshold When the blockchain node The number of encrypted transactions packaged in the block exceeds the system threshold After that, the blockchain node Sets the block header, containing the handshake message of the blockchain node , the link of the two recent blocks in the current DAG chain, and the consensus information, and then broadcasts the complete block to all blockchain nodes through the point-to-point network; the handshake message in this step has the same meaning as the handshake message in step S11, which is the first message of the secret handshake protocol; S32. A blockchain node Upon receiving the block, the DAG consensus process is completed according to the consensus information of the block header, and the DAG blockchain is updated. 5.The secret handshake based blockchain sharding method of claim 4, wherein, The step S4 specifically comprises: S41. For the new block reaching consensus in the DAG chain, the blockchain node If it is checked that the new block is not generated by itself, the handshake information of the block header is adopted to send the secret handshake message to the generator of the new block; the secret handshake message sent to the generator of the new block in this step has the same meaning as the handshake message in step S12, which is the second message of the secret handshake; S42. After receiving the secret handshake message, if the requestor and the generator belong to the same group of management nodes, a shared key is generated, and a block encryption key encrypted by the shared key and a secure symmetric encryption algorithm is returned, otherwise the process is aborted; the shared key in this step has the same meaning as the shared key in step S13, which is a shared key generated by the secret handshake protocol; S43. A blockchain node After obtaining the block encryption key, decrypt the validation block to verify its validity, and if the block is valid, update the shard blockchain, i.e. append the decrypted plaintext block into the local blockchain, otherwise abort the process. 6.The secret handshake based blockchain sharding method according to any one of claims 2 to 5, characterized in that, The symmetric encryption algorithm includes the AES-CCM algorithm, and uses the handshake message when the secret handshake is used as a key, i.e. in steps S12 and S13, the as a shared key . 7.The secret handshake based blockchain sharding method according to any one of claims 3 to 5, characterized in that, In step S22, the validity of the user's transaction is verified using a digital signature; the user Generate a transfer transaction It includes timestamps, transaction type, transfer amount, target user identity, and user. Signature of transaction content; user Perform a secret handshake protocol with neighboring nodes in the peer-to-peer network to obtain a shared key. Transaction encryption using symmetric encryption algorithm Obtain crypto transactions ;user To belong to the same group of management nodes Neighboring blockchain nodes Send encrypted transaction Blockchain node Received user Crypto transactions It employs a symmetric decryption algorithm and a shared key. Decryption To acquire users transactions Then the blockchain node Verify user transactions according to the following blockchain verification rules. Validity: Check if the transaction signature is valid, if valid, continue to check as follows; If the transaction type of the user transaction is a transfer transaction, then check if the transfer amount is non-negative, if yes, then continue with the following checks, if no, then the transaction is invalid; Check user Check if the blockchain account balance is greater than or equal to the transfer amount. If yes, continue with the following checks; otherwise, the transaction... invalid; checks whether the target user is a user of the present blockchain, and if so, the transaction is valid, and if not, the transaction is invalid. 8.The secret handshake based blockchain sharding method of claim 5, wherein, Each user transaction in the validation block is verified to be valid to verify the block is valid; in step S43, the blockchain node After obtaining the block encryption key, the block is decrypted to obtain user transactions, if user transactions are valid, the block is valid, otherwise the block is invalid.

Images