A lattice-based blind signature and fragmented blockchain-based transaction method

Abstract

The present application relates to a kind of based on lattice blind signature and the transaction method of fragmented blockchain, comprising: according to the input of transaction, the Merkle tree of sharding leader is generated, the Merkle tree is blinded according to the public key of other nodes, sharding leader node executes unblinding algorithm and generates blind signature, other nodes are verified and adopted to blind signature, leader node collects the blind signature of all other nodes and does BFT consensus result verification, and the commitment signature of Merkle tree root is generated after verification;The information of each input and the commitment signature of Merkle tree root are sent to the leader of other input-output sharding of relevant transaction to determine whether the input of transaction is available, correct transaction is put into valid transaction pool;Sharding leader packs correct transaction into block and broadcasts to other nodes, carries out BFT consensus, completes block chain, and updates the transaction input state in utxo pool, and completes transaction.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, and in particular relates to a transaction method based on lattice-based blind signatures and sharded blockchains. Background Technology

[0002] Blockchain is developing rapidly, featuring technologies such as decentralization, distributed data storage, consensus mechanisms, encryption mechanisms, and peer-to-peer communication. It has already been applied in many fields, such as medicine, the Internet of Things, and the Internet of Vehicles, achieving remarkable results. However, the challenges facing blockchain are also quite obvious. One of the most serious problems is low transaction throughput, a goal that most current blockchain systems cannot achieve.

[0003] To improve transaction throughput, the design concept of sharded blockchain was proposed, which combines distributed database storage with blockchain, dividing different nodes participating in consensus into different shards, with different nodes responsible for generating and maintaining the designated blockchain.

[0004] The entire system consists of multiple shards, corresponding to multiple parallel blockchains. For a node within a shard, most communication takes place within that shard. Transactions are distributed to shards according to certain rules.

[0005] For transactions whose inputs and outputs are managed by different shards, the transaction commitment needs to be completed jointly by these respective shards. This type of transaction, known as a cross-shard transaction, accounts for the vast majority of transactions in a sharded blockchain. The more shards there are, the greater the proportion of cross-shard transactions. For example, when the number of shards is 3 and 16, the proportions of cross-shard transactions are 96.3% and 99.98%, respectively.

[0006] The method of handling cross-shard transactions has a significant impact on the efficiency and throughput of sharded blockchains. Currently, most existing cross-shard transaction processing schemes are based on the two-phase commit (2PC) protocol, which includes a preparation phase and a commit phase.

[0007] During the preparation phase, all input shards need to generate an availability certificate to prove whether an input is available. An input is available because it has not been spent by any transaction and is not locked. To generate such a certificate, a shard may invoke a BFT algorithm to reach an agreement and generate sufficient signatures. If an input is available, it should be locked after the certificate is generated to prevent another transaction from spending it, i.e., double-spending. All availability certificates should be sent to every input and output shard associated with the transaction.

[0008] During the commit phase, the shard that has received all relevant certificates can verify the validity of the transaction by checking if all inputs are available. If at least one input is unavailable, the transaction is invalid, and previously locked inputs should be unlocked. If all inputs are available, the inputs should be removed from the corresponding Unused Transaction Output (UTXO) pool of the relevant input shard, and the outputs should be created in the output shard.

[0009] Current cross-shard processing methods have several problems, such as low efficiency and vulnerability to attacks. Furthermore, multiple calls to the BFT algorithm are required to submit a transaction. Since the BFT algorithm involves at least two rounds of voting among all shard members (in committee-based sharded blockchains, there is typically a committee within a shard), multiple calls to BFT increase communication complexity.

[0010] With the rapid development of quantum computers, most digital signature schemes used for authentication in current cryptographic systems have significant vulnerabilities to quantum adversaries. Shor's algorithm offers exponential speedup for integer factorization and implements discrete logarithms via quantum Fourier transform. Grover's algorithm can provide four times the speedup for search problems. In sharded blockchains, where signatures are frequently required, the security of sharded transactions and user privacy are severely compromised. Summary of the Invention

[0011] To address the problems existing in the background technology, the present invention provides a transaction method based on lattice-based blind signatures and sharded blockchains, so as to enhance the security of sharded blockchain transactions and user privacy, while improving transaction throughput;

[0012] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0013] S1: The leader of each shard collects all transactions related to its shard X from the UTXO pool; and creates the Merkel tree for shard X using all inputs of each collected transaction within shard X, the state of each input, and the transaction ID as leaf nodes of the Merkel tree;

[0014] S2: Broadcast the Merkel tree of shard X to other nodes within the shard, call the BFT consensus mechanism, and each other node of shard X verifies the state of all transaction inputs in the Merkel tree. After verification, generate a commitment message of the Merkel tree, and use the blinding algorithm and KeyGen algorithm to generate blind signatures for other nodes of shard X. The other nodes of shard X return the blind signatures to the leader of shard X.

[0015] S3: The leader of shard X counts the blind signatures returned by other nodes to generate the commitment signature of the Merkel tree root node, and broadcasts the commitment signature of the Merkel tree root node, the path from the leaf node corresponding to the transaction in the Merkel tree to the Merkel tree root node, the IDs of all inputs of the transaction in shard X, and the ID of the transaction to the leaders of the shards where the other inputs and outputs of the transaction are located.

[0016] S4: The leaders of the shards containing the other inputs and outputs of the transaction verify the commitment signature of the received Merkel tree root node, the path from the leaf node corresponding to the transaction in the Merkel tree to the Merkel tree root node, the IDs of all inputs of the transaction in shard X, and the ID of the transaction. If the verification is successful, all inputs of the transaction in shard X are placed into the availability proof pool of the shard containing the other inputs or outputs of the transaction. All inputs of each transaction in a shard are assumed to be in the availability proof pool of that shard by default.

[0017] S5: When the available proof pool of a shard contains all the inputs of a transaction, determine the correctness of the transaction based on all the inputs and all the outputs of the transaction. If the transaction is determined to be correct, update the status of all the inputs of the correct transaction in the UTXO pool to be occupied; then add the correct transaction to the valid transaction pool of that shard.

[0018] S6: When the number of transactions in the valid transaction pool of a shard reaches a certain amount or at regular intervals, all transactions in the valid transaction pool of the shard are packaged into a block. The leader of the shard broadcasts the block to other nodes in the shard and calls the BFT consensus mechanism. Other nodes in the shard verify the block. After successful verification, a commitment message for the block is generated, and blind signatures for other nodes in the shard are generated using the blinding algorithm and the KeyGen algorithm. Other nodes in the shard return the blind signatures to the leader of the shard. The leader of the shard counts the blind signatures returned by other nodes in the shard to determine whether the block is correct. If it is correct, the block is added to the chain, and the status of all transaction inputs in the block in the UTXO pool is updated to "used". The corresponding transaction output is generated, and the transaction is completed.

[0019] Preferably, the verification of the status of all transaction inputs in the Merkel tree includes: querying the local transaction history based on the ID of each transaction input to see if the status of the transaction input is consistent with the status of the transaction input in the Merkel tree; if they are consistent, the verification is successful.

[0020] Preferably, the process of generating blind signatures for other nodes of shard X using the blinding algorithm and the KeyGen algorithm includes:

[0021] Other nodes in shard X generate their public key pk using the KeyGen algorithm. a and private key ska and its public key PK a Commitment messages with Merkel trees x a The public key is uploaded to the leader node of shard X; the leader node of shard X randomly selects a blinding factor y from a bimodal Gaussian distribution and uses the public key pk of other nodes. a Commitment messages with Merkel trees x a Calculate the blind message μ of other nodes a and the blind messages μ of other nodes a Send to other node a; the blind message of the other node a is as follows:

[0022] μ a =(-1) t c a t∈{0,1} n

[0023] c a =H(x) a +y*pk a %2q,m)

[0024] Where H represents the hash function, q is the fundamental parameter of the lattice, which is itself a prime number, and μ a Let represent the blind messages of other nodes 'a', m represent the Merkel tree, and n represent the dimension of the KeyGen algorithm's foundation matrix; 'a' belongs to the set of all nodes in shard X except the leader node.

[0025] Other node a selects a random vector γ and, based on its private key sk a and blind message μ a Generate blind message μ a signature z a The blind message μ is sent to the leader of shard X. a signature z a include:

[0026] z a =γ+μ a *sk a

[0027] The leader of shard X is determined based on the blinding factor y and the blind message μ. a signature z a Generate the verification signature Q for other node a a and verify the signature Q of other node a. a Send the verification signature Q to another node a. a include:

[0028] Q a = <e a ,ca >

[0029] e a =y+z a

[0030] Other node a verifies the received signature Q. a Perform verification and determine c a =H(pk) a *e a +q*c a If %2q,m) is true, then verify the signature Q. a As a blind signature for other node a.

[0031] Preferably, the commitment signature for generating the Merkel tree root node includes:

[0032] The leader of shard X counts the number of blind signatures from other nodes within the shard and determines whether the Merkel tree is correct. When the number of blind signatures reaches a preset value, the Merkel tree is determined to be correct, and a commitment signature of the Merkel tree root node is generated. The commitment signature of the Merkel tree root node includes: the root node information of the Merkel tree and the commitment signature of the shard leader.

[0033] Preferably, the verification of the received commitment signature of the Merkel tree root node, the path from the leaf node corresponding to the transaction in the Merkel tree to the Merkel tree root node, the IDs of all inputs and the transaction ID within shard X includes:

[0034] First, the commitment signature of the Merkel tree root node is parsed to obtain the root node information of the Merkel tree;

[0035] Calculate the root node of the Merkel tree based on the path from the leaf node corresponding to the transaction in the Merkel tree to the root node of the Merkel tree. Determine whether the calculated root node information of the Merkel tree is consistent with the root node information of the parsed Merkel tree. At the same time, determine whether the input ID in the leaf node is consistent with the ID input in the transaction within shard X. Also, determine whether all input states of the transaction in the leaf node are unoccupied. If all are true, the verification is successful.

[0036] Preferably, determining the correctness of a transaction includes: whether the sum of all input amounts in the transaction matches the sum of all output amounts in the transaction; if they match, the transaction is considered a correct transaction.

[0037] The present invention has at least the following beneficial effects

[0038] This invention enhances the security of transactions and user privacy in sharded blockchain systems by verifying and signing messages sent by leader nodes using a lattice-based blind signature algorithm. It also strengthens the sharded blockchain system's resistance to quantum attacks, providing more stable protection for user privacy information. Furthermore, sharded blockchains address the prominent shortcomings of current blockchain systems, namely low throughput and low security. By designing an effective transaction pool for batch processing, transactions can be processed in batches, significantly reducing the number of BFT consensus calls in the sharded blockchain system and decreasing the information complexity of communication between shards, thereby improving the overall system throughput. Attached Figure Description

[0039] Figure 1 This is a flowchart of the method of the present invention;

[0040] Figure 2 This is a schematic diagram of the Merkel tree construction of the present invention;

[0041] Figure 3 This is a schematic diagram of the transaction structure of the present invention. Detailed Implementation

[0042] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0043] The accompanying drawings are for illustrative purposes only and are schematic diagrams, not actual pictures. They should not be construed as limiting the invention. To better illustrate the embodiments of the invention, some parts in the drawings may be omitted, enlarged, or reduced, and do not represent the actual product dimensions. It is understandable to those skilled in the art that some well-known structures and their descriptions may be omitted in the drawings.

[0044] In the accompanying drawings of the embodiments of the present invention, the same or similar reference numerals correspond to the same or similar components. In the description of the present invention, it should be understood that if terms such as "upper," "lower," "left," "right," "front," and "rear" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, the terms used to describe positional relationships in the drawings are only for illustrative purposes and should not be construed as limiting the present invention. For those skilled in the art, the specific meaning of the above terms can be understood according to the specific circumstances.

[0045] Sharded blockchains have three main characteristics. First, communication sharding: participating nodes are divided into different shards, where nodes in each shard primarily communicate internally. Second, computation sharding: each shard is responsible for processing only its corresponding transactions. Third, storage sharding: nodes in different shards only need to store the historical data of their respective shard's blockchain. Furthermore, sharded blockchains have several important components: node selection, node allocation, intra-shard consensus, cross-shard transaction processing, and shard reconfiguration. Among these, intra-shard consensus and cross-shard transaction processing are essential components of every sharded blockchain.

[0046] Please see Figure 1 This invention provides a transaction method based on lattice-based blind signatures and sharded blockchains, comprising:

[0047] S1: The leader of each shard collects all transactions related to its shard X from the UTXO pool; and sets each transaction... All inputs within slice X, each input Status and transactions The ID is used as the leaf node of the Merkel tree to create the Merkel tree for shard X; where, This represents the i-th transaction associated with shard X; Indicates transaction The j-th input within partition X; where i = 1, 2, ..., j = 1, 2, ...; each input of the transaction contains the ID information of the input node and the input amount information, and each output of the transaction contains the ID information of the output node and the output amount information;

[0048] In this embodiment, the leader node of each shard collects all transactions related to its shard X from the unspent transaction pool UTXO, where the transactions related to shard X are represented as transactions. Any input or output node is a node in shard X, which may contain transactions within a shard. Multiple inputs or outputs; transactions It can have one or more output nodes, and the status of transaction inputs can be represented as unoccupied, occupied, or used (spent);

[0049] Please see Figure 2 The creation of the Merkel tree for shard X includes:

[0050] For example, leaf nodes B1, B2, B3, and B4 are hashed separately to obtain hash(B1), hash(B2), hash(B3), and hash(B4). Adjacent hash(B1) and hash(B2) are added together and then hashed again to obtain hash(hash(B1)+hash(B2)). Similarly, hash(hash(B3)+hash(B4)) is obtained. Then hash(hash(B1)+hash(B2)) and hash(hash(B3)+hash(B4)) are added together and then hashed again to obtain the root node of the Merkel tree, hash(hash(hash(B1)+hash(B2))+hash(B3)+hash(B4))), thus constructing the Merkel tree.

[0051] S2: Broadcast the Merkel tree of shard X to other nodes within the shard, call the BFT consensus mechanism, and each other node of shard X verifies the state of all transaction inputs in the Merkel tree. After verification, generate a commitment message of the Merkel tree, and use the blinding algorithm and KeyGen algorithm to generate blind signatures for other nodes of shard X. The other nodes of shard X return the blind signatures to the leader of shard X.

[0052] Preferably, the verification of the status of all transaction inputs in the Merkel tree includes: querying the local transaction history based on the ID of each transaction input to see if the status of the transaction input matches the status of the transaction input in the Merkel tree; if they match, the verification passes. In this embodiment, the input status of a transaction can be unoccupied, occupied, or used. Therefore, the verification of the input status of a transaction mainly refers to the node querying the local transaction history based on the input ID to verify if the status of the transaction input matches the status of the transaction input in the Merkel tree; if they match, the verification passes. For example, an input ID represented by a leaf node in the Merkel tree is... If the input status is "unoccupied", the node will query the local transaction history. Transaction logs, determine input If it is indeed not occupied, then the verification is successful.

[0053] Preferably, the process of generating blind signatures for other nodes of shard X using the blinding algorithm and the KeyGen algorithm includes:

[0054] Other nodes in shard X generate their public key pk using the KeyGen algorithm. a and private key sk a and its public key PK a Commitment messages with Merkel trees x a The data is uploaded to the leader node of shard X; the leader node of shard X randomly selects a blinding factor y from a bimodal Gaussian distribution, and uses the public key pk of other nodes a. a Commitment messages with Merkel trees x a Calculate the blind message μ of other nodes a and the blind messages μ of other nodes a Send to other node a; the blind message of the other node a is as follows:

[0055] μ a =(-1) t c a t∈{0,1} n

[0056] c a =H(x) a +y*pk a %2q,m)

[0057] Where H represents the hash function, q is the fundamental parameter of the lattice, which is itself a prime number, and μ a Let represent the blind messages of other nodes 'a', m represent the Merkel tree, and n represent the dimension of the KeyGen algorithm's foundation matrix; 'a' belongs to the set of all nodes in shard X except the leader node.

[0058] Other node a selects a random vector γ and, based on its private key sk a and blind message μ a Generate blind message μ a signature z a The blind message μ is sent to the leader of shard X. a signature z a include:

[0059] z a =γ+μ a *sk a

[0060] The leader of shard X is determined based on the blinding factor y and the blind message μ. a signature z a Generate the verification signature Q for other node a a and verify the signature Q of other node a.a Send the verification signature Q to another node a. a include:

[0061] Q a = <e a ,c a >

[0062] e a =y+z1

[0063] Other node a verifies the received signature Q. a Perform verification and determine c a =H(pk) a *e a +q*c a If %2q,m) is true, then verify the signature Q. a As a blind signature for other node a.

[0064] In this embodiment, for example, the leader node N1 of shard X sends the Merkel tree m to other nodes within the shard. After receiving the Merkel tree, the other nodes in the shard verify the status of all transaction inputs in the Merkel tree; after successful verification, they return a commitment message x to the leader node N1 regarding the Merkel tree. a public key pk of other node a a The public key of each node is generated by the KeyGen algorithm. Each node has a public key and a private key, both generated by the KeyGen algorithm.

[0065] S3: The leader of shard X counts the blind signatures returned by other nodes in the shard to generate the commitment signature of the Merkel tree root node, and then combines the commitment signature of the Merkel tree root node with the transactions in the Merkel tree. The corresponding leaf node to the root node of the Merkel tree, and the transaction All input IDs and transactions within shard X ID broadcast to the transaction Other inputs I otherin and output I otherout The leader of the partition;

[0066] Preferably, generating the commitment signature of the Merkle tree root node includes: the leader of shard X counting the number of blind signatures from other nodes within the shard, determining whether the Merkle tree is correct, and when the number of blind signatures reaches a preset value, determining that the Merkle tree is correct, and generating the commitment signature of the Merkle tree root node. The commitment signature of the Merkle tree root node includes: the root node information of the Merkle tree and the commitment signature of the shard leader. In this embodiment, according to the requirement of the BFT algorithm for the number of signatures, the number of signatures collected needs to be greater than or equal to 2f+1, where the total number of nodes in shard X is 3f+1.

[0067] Preferably, such as Figure 2 As shown, assuming the leaf nodes are B1, B2, B3, and B4; the path from leaf node B1 to the root node of the Merkel tree is represented as: B1-B2-hash(hash(B3)+hash(B4)); the path from leaf node B3 to the root node of the Merkel tree is represented as: B3-B4-hash(hash(B1)+hash(B2)).

[0068] Please see Figure 3 In this embodiment, for example, an unconsumed transaction has two inputs and one output; the inputs are A and B, and the output is C; where A and B are located in shard 1 and shard 2 respectively; the output is located in shard 3; then for shard 1, after the leader of shard 1 generates the commitment signature of the Merkel tree root node, it broadcasts the commitment signature of the Merkel tree root node, the path from the leaf node corresponding to the transaction in the Merkel tree to the Merkel tree root node, the ID of the transaction input A in shard 1, and the transaction ID to shard 2 and shard 3; similarly, the leader of shard 2 broadcasts the data corresponding to B to shard 1 and shard 3;

[0069] S4: Trading Other inputs I otherin and output I otherout The leader of each shard signs the commitment received from the root node of the Merkel tree and the transactions in the Merkel tree. The corresponding leaf node to the root node of the Merkel tree, and the transaction All input IDs and transactions within shard X The ID is verified; if verification is successful, the transaction will be processed. Place all inputs within slice X into the transaction. Other inputs I otherin Or output I otherout The availability proof pool of the shard in which it is located, where all inputs of each transaction within the shard are assumed to be in the availability proof pool of that shard;

[0070] Preferably, the verification of the received commitment signature of the Merkel tree root node, the path from the leaf node corresponding to the transaction in the Merkel tree to the Merkel tree root node, the IDs of all inputs and the transaction ID within shard X includes:

[0071] First, the commitment signature of the Merkel tree root node is parsed to obtain the root node information of the Merkel tree;

[0072] According to the Merkel tree transaction The path from the corresponding leaf node to the root node of the Merkel tree is calculated to find the root node of the Merkel tree. It is then determined whether the calculated root node information of the Merkel tree is consistent with the root node information of the parsed Merkel tree. At the same time, it is determined whether the input ID in the leaf node is consistent with the ID input in the transaction within shard X. Additionally, it is determined whether all input states of the transaction in the leaf node are unoccupied. If all are true, the verification passes.

[0073] Preferably, the step of parsing the commitment signature of the Merkel tree root node to obtain the Merkel tree root node information includes:

[0074] Please see Figure 3 In this embodiment, the leader of shard 1 receives the pending verification information sent by shard 2; the leader of shard 2 receives the pending verification information sent by shard 1; and shard 3 receives the pending verification information sent by both shard 1 and shard 2. Each shard verifies the pending verification information sent by other shards. The pending verification information includes: the commitment signature of the Merkel tree root node, and transactions in the Merkel tree. The corresponding leaf node to the root node of the Merkel tree, and the transaction All input IDs and transactions within shard X ID.

[0075] In addition, parsing the commitment signature of the Merkel tree root node mainly involves extracting the required Merkel tree root node information from the commitment signature of the Merkel tree root node.

[0076] Preferably, in this embodiment, all inputs of each transaction within a shard are assumed to be within the availability proof pool of that shard, for example, Figure 3 Input A within shard 1 is assumed to be within the availability proof pool of shard 1.

[0077] S5: When the available proof pool of a shard contains all the inputs of a transaction, determine the correctness of the transaction based on all the inputs and all the outputs of the transaction. If the transaction is determined to be correct, update the status of all the inputs of the correct transaction in the UTXO pool to be occupied; then add the correct transaction to the valid transaction pool of that shard.

[0078] Preferably, determining the correctness of a transaction includes: whether the sum of all input amounts in the transaction matches the sum of all output amounts in the transaction; if they match, the transaction is considered a correct transaction.

[0079] S6: When the number of transactions in the valid transaction pool of a shard reaches a certain amount or at regular intervals, all transactions in the valid transaction pool of the shard are packaged into a block. The leader of the shard broadcasts the block to other nodes in the shard and calls the BFT consensus mechanism. Other nodes in the shard verify the block. After successful verification, a commitment message for the block is generated, and blind signatures for other nodes in the shard are generated using the blinding algorithm and the KeyGen algorithm. Other nodes in the shard return the blind signatures to the leader of the shard. The leader of the shard counts the blind signatures returned by other nodes in the shard to determine whether the block is correct. If it is correct, the block is added to the chain, and the status of all transaction inputs in the block in the UTXO pool is updated to "used". The corresponding transaction output is generated, and the transaction is completed.

[0080] In this embodiment, generating blind signatures for other nodes within the shard using the blinding algorithm and the KeyGen algorithm includes: other nodes in the shard using the KeyGen algorithm to generate their public key pk. b and private key sk b and its public key PK b And the commitment message x of the block b The public key pk of the other nodes is uploaded to the leader node of the shard; the leader node of the shard randomly selects a blinding factor y' from a bimodal Gaussian distribution and uses it according to the public keys pk of the other nodes. b And the commitment message x of the block b Calculate the blind message μ of other nodes b and the blind messages μ of other nodes b Send to other nodes; the blind messages of the other nodes are as follows:

[0081] μ b =(-1) t c b t∈{0,1} n

[0082] c b =H(x) b +y′*pk b %2q,m′)

[0083] Where H represents the hash function, q is the fundamental parameter of the lattice, which is itself a prime number, and μ b represents the blind messages of other nodes a, m′ represents the block, n represents the dimension of the KeyGen algorithm's fundamental matrix; b belongs to the set of all nodes in the shard except the leader node;

[0084] Other node b selects a random vector γ′ and, based on the node's private key sk b and blind message μ b Generate blind message μ b signature z b The blind message μ is sent to the leader of the shard. b signature z b include:

[0085] z b =γ′+μ b *sk b

[0086] The leader of shard X is determined based on the blinding factor y and the blind message μ. b signature z b Generate the verification signature Q for other node b b and verify the signature Q of other node b. b Send the verification signature Q to other node b. b include:

[0087] Q b = <e b ,c b >

[0088] e b =y′+z b

[0089] Other node b verifies the received signature Q b Perform verification and determine c b =H(pk) b *e b +q*c b If %2q,m′) is true, then verify the signature Q. b As a blind signature for other node b.

[0090] Preferably, in this embodiment, for a verified block in shard 1, it is assumed that there are two valid transactions, including five inputs I1, I2, I3, I4, and I5, and two outputs O1 and O2. Their states in the UTXO pool are all occupied. When the block is added to the chain, it means that these inputs have been used. Therefore, the UTXO pool will update the states of the five inputs I1, I2, I3, I4, and I5 to be used to avoid the reuse of the same input. At the same time, new outputs O1 and O2 are generated as inputs for subsequent transactions.

[0091] Preferably, determining whether a block is correct includes, for example, the leader in shard 1 judging the number of signatures collected by the BFT consensus algorithm from other nodes. The steps are the same as the BFT consensus algorithm's signature count judgment process in S3. Confirming that the number of correct signatures meets the requirements of the BFT consensus algorithm determines the block's correctness.

[0092] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A transaction method based on lattice-based blind signatures and sharded blockchain, characterized in that, include: S1: The leader of each shard collects all transactions related to its shard X from the UTXO pool; and creates the Merkel tree for shard X using all inputs of each collected transaction within shard X, the state of each input, and the transaction ID as leaf nodes of the Merkel tree; S2: Broadcast the Merkel tree of shard X to other nodes within the shard, call the BFT consensus mechanism, and each other node of shard X verifies the state of all transaction inputs in the Merkel tree. After verification, generate a commitment message of the Merkel tree, and use the blinding algorithm and KeyGen algorithm to generate blind signatures for other nodes of shard X. The other nodes of shard X return the blind signatures to the leader of shard X. S3: The leader of shard X counts the blind signatures returned by other nodes to generate the commitment signature of the Merkel tree root node, and broadcasts the commitment signature of the Merkel tree root node, the path from the leaf node corresponding to the transaction in the Merkel tree to the Merkel tree root node, the IDs of all inputs of the transaction in shard X, and the ID of the transaction to the leaders of the shards where the other inputs and outputs of the transaction are located. S4: The leaders of the shards containing the other inputs and outputs of the transaction verify the commitment signature of the received Merkel tree root node, the path from the leaf node corresponding to the transaction in the Merkel tree to the Merkel tree root node, the IDs of all inputs of the transaction in shard X, and the ID of the transaction. If the verification is successful, all inputs of the transaction in shard X are placed into the availability proof pool of the shard containing the other inputs or outputs of the transaction. All inputs of each transaction in a shard are assumed to be in the availability proof pool of that shard by default. S5: When the available proof pool of a shard contains all the inputs of a transaction, determine the correctness of the transaction based on all the inputs and all the outputs of the transaction. If the transaction is determined to be correct, update the status of all the inputs of the correct transaction in the UTXO pool to be occupied; then add the correct transaction to the valid transaction pool of that shard. S6: When the number of transactions in the valid transaction pool of a shard reaches a certain amount or at regular intervals, all transactions in the valid transaction pool of the shard are packaged into a block. The leader of the shard broadcasts the block to other nodes in the shard and calls the BFT consensus mechanism. Other nodes in the shard verify the block. After verification, a commitment message for the block is generated, and blind signatures for other nodes within the shard are generated using the blinding algorithm and the KeyGen algorithm. The other nodes within the shard return the blind signatures to the leader of the shard. The leader of the shard determines whether the block is correct based on the blind signatures returned by other nodes in the shard. If it is correct, the block is added to the chain, and the status of all transaction inputs in the block in the UTXO pool is updated to "used". The corresponding transaction output is generated, and the transaction is completed.

2. The transaction method based on lattice-based blind signatures and sharded blockchain according to claim 1, characterized in that, The verification of the status of all transaction inputs in the Merkel tree includes: querying the local transaction history based on the ID of each transaction input to see if the status of the transaction input is consistent with the status of the transaction input in the Merkel tree; if they are consistent, the verification is successful.

3. The transaction method based on lattice-based blind signatures and sharded blockchain according to claim 1, characterized in that, The process of generating blind signatures for other nodes of shard X using the blinding algorithm and the KeyGen algorithm includes: Other nodes in shard X generate their public key pk using the KeyGen algorithm. a and private key sk a and its public key PK a Commitment messages with Merkel trees x a The public key pk of other nodes is uploaded to the leader node of shard X; the leader node of shard X randomly selects a blinding factor y from a bimodal Gaussian distribution and uses it according to the public keys pk of other nodes. a Commitment messages with Merkel trees x a Calculate the blind message μ of other nodes a and the blind messages μ of other nodes a Send to other node a; the blind message of the other node a is as follows: m a =(-1) t c a ,t∈{0,1} n c a =H(x a +y*pk a %2q,m) Where H represents the hash function, q is the fundamental parameter of the lattice, which is itself a prime number, and μ a Let represent the blind messages of other nodes 'a', m represent the Merkel tree, and n represent the dimension of the KeyGen algorithm's foundation matrix; 'a' belongs to the set of all nodes in shard X except the leader node. Other node a selects a random vector γ and, based on its private key sk a and blind message μ a Generate blind message μ a signature z a The blind message μ is sent to the leader of shard X. a signature z a include: from a =γ+μ a *sk a The leader of shard X is determined based on the blinding factor y and the blind message μ. a signature z a Generate the verification signature Q for other node a a and verify the signature Q of other node a. a Send the verification signature Q to another node a. a include: Q a =<e a ,c a > yes a =y+z a Other node a verifies the received signature Q. a Perform verification and determine c a =H(pk) a *e a +q*c a If %2q,m) is true, then verify the signature Q. a As a blind signature for other node a.

4. The transaction method based on lattice-based blind signatures and sharded blockchain according to claim 1, characterized in that, The commitment signature for generating the Merkel tree root node includes: The leader of shard X counts the number of blind signatures from other nodes within the shard and determines whether the Merkel tree is correct. When the number of blind signatures reaches a preset value, the Merkel tree is determined to be correct, and a commitment signature of the Merkel tree root node is generated. The commitment signature of the Merkel tree root node includes: the root node information of the Merkel tree and the commitment signature of the shard leader.

5. The transaction method based on lattice-based blind signatures and sharded blockchain according to claim 1, characterized in that, The verification of the received commitment signature of the Merkel tree root node, the path from the leaf node corresponding to the transaction in the Merkel tree to the Merkel tree root node, and the IDs of all inputs and the transaction within shard X includes: First, the commitment signature of the Merkel tree root node is parsed to obtain the root node information of the Merkel tree; Calculate the root node of the Merkel tree based on the path from the leaf node corresponding to the transaction in the Merkel tree to the root node of the Merkel tree. Determine whether the calculated root node information of the Merkel tree is consistent with the root node information of the parsed Merkel tree. At the same time, determine whether the input ID in the leaf node is consistent with the ID input in the transaction within shard X. Also, determine whether all input states of the transaction in the leaf node are unoccupied. If all are true, the verification is successful.

6. The transaction method based on lattice-based blind signatures and sharded blockchain according to claim 1, characterized in that, The determination of the correctness of a transaction includes: whether the sum of all input amounts in the transaction matches the sum of all output amounts in the transaction; if they match, the transaction is a correct transaction.

Images