Method and device for generating and verifying linkable ring signature in blockchain

Abstract

One or more embodiments of this specification provide a method and apparatus for generating and verifying linkable ring signatures in a blockchain. The method may include: determining a signature party array (P_j, ID_j), where the signature party array (P_j, ID_j) includes the public key P_j of the signature party and the unique identifier ID_j of the unspent asset held by the signature party. Here, G is the base point of an elliptic curve, |G| = p and p is a prime number, x_j is the private key of the signature party and 0 < x_j < p; generating a key image I according to the private key x_j of the signature party and the signature party array (P_j, ID_j); when generating a linkable ring signature for a transaction M related to the unspent asset, adding the key image I to the linkable ring signature.

Description

Technical Field

[0001] One or more embodiments of the present specification relate to the field of blockchain technology, and more particularly, to a method and device for generating and verifying a linkable ring signature in a blockchain. Background Art

[0002] Blockchain technology (also known as distributed ledger technology) is a decentralized distributed database technology with many characteristics such as decentralization, openness, transparency, immutability, and trustworthiness. It is suitable for many application scenarios with high demands for data reliability. However, since the blockchain ledger is completely public, information privacy cannot be guaranteed. Summary of the invention

[0003] In view of this, one or more embodiments of this specification provide a method and device for generating and verifying a linkable ring signature in a blockchain.

[0004] To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions:

[0005] According to a first aspect of one or more embodiments of this specification, a method for generating a linkable ring signature in a blockchain is proposed, comprising:

[0006] Determine the signing party array (P_j, ID_j), which contains the signing party's public key P_j = x_j × G and the unique identifier ID_j of the asset to be spent held by the signing party, where G is the base point of the elliptic curve, |G| = p and p is a prime number, x_j is the signing party's private key and 0 <x_j<p;

[0007] Generate a key image I according to the private key x_j of the signer and the signer array (P_j, ID_j);

[0008] When generating a linkable ring signature for a transaction M related to the asset to be spent, the key image I is added to the linkable ring signature.

[0009] According to a second aspect of one or more embodiments of this specification, a method for verifying a linkable ring signature in a blockchain is proposed, comprising:

[0010] Get the key image I contained in the linkable ring signature of transaction M, the key image I is generated by the signer according to the private key x_j held and the signer array (P_j, ID_j), the signer array (P_j, ID_j) contains the signer's public key P_j = x_j × G and the unique identifier ID_j of the asset to be spent related to the transaction M, where G is the base point of the elliptic curve, |G| = p and p is a prime number, 0 <x_j<p;

[0011] The key image I is verified according to the saved historical key image to determine the validity of the linkable ring signature.

[0012] According to a third aspect of one or more embodiments of this specification, a device for generating a linkable ring signature in a blockchain is proposed, comprising:

[0013] A determination unit determines a signature party array (P_j, ID_j), wherein the signature party array (P_j, ID_j) includes the public key P_j = x_j × G of the signature party and the unique identifier ID_j of the asset to be spent held by the signature party, wherein G is the base point of the elliptic curve, |G| = p and p is a prime number, x_j is the private key of the signature party and 0 <x_j<p;

[0014] A first generating unit generates a key image I according to the private key x_j of the signer and the signer array (P_j, ID_j);

[0015] The second generating unit, when generating a linkable ring signature for a transaction M related to the asset to be spent, adds the key image I to the linkable ring signature.

[0016] According to a fourth aspect of one or more embodiments of this specification, a device for verifying a linkable ring signature in a blockchain is proposed, comprising:

[0017] An acquisition unit acquires a key image I contained in a linkable ring signature of a transaction M, wherein the key image I is generated by the signer according to the private key x_j held by the signer and the signer array (P_j, ID_j), wherein the signer array (P_j, ID_j) contains the signer's public key P_j=x_j×G and a unique identifier ID_j of the asset to be spent related to the transaction M, wherein G is a base point of the elliptic curve, |G|=p and p is a prime number, 0 <x_j<p;

[0018] The verification unit verifies the key image I according to the saved historical key image to determine the validity of the linkable ring signature.

[0019] According to a fifth aspect of one or more embodiments of this specification, an electronic device is provided, including:

[0020] processor;

[0021] a memory for storing processor-executable instructions;

[0022] The processor implements the method as described in the first aspect or the second aspect by running the executable instructions.

[0023] According to a sixth aspect of one or more embodiments of the present specification, a computer-readable storage medium is provided, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method described in the first aspect or the second aspect are implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 is a schematic diagram of an example environment provided by an exemplary embodiment.

[0025] Figure 2 is a schematic diagram of a conceptual architecture provided by an exemplary embodiment.

[0026] Figure 3 It is a flowchart of a method for generating a linkable ring signature in a blockchain provided by an exemplary embodiment.

[0027] Figure 4 It is a flowchart of a method for verifying a linkable ring signature in a blockchain provided by an exemplary embodiment.

[0028] Figure 5 A flowchart of generating a linkable ring signature is provided by an exemplary embodiment.

[0029] Figure 6 A flowchart of verifying a linkable ring signature is provided by an exemplary embodiment.

[0030] Figure 7 It is a structural schematic diagram of a device provided by an exemplary embodiment.

[0031] Figure 8 It is a block diagram of a device for generating a linkable ring signature in a blockchain provided by an exemplary embodiment.

[0032] Fig. 9 It is a schematic structural diagram of another device provided by an exemplary embodiment.

[0033] Fig.10 It is a block diagram of a device for verifying a linkable ring signature in a blockchain provided by an exemplary embodiment. DETAILED DESCRIPTION

[0034] Here, exemplary embodiments will be described in detail, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Instead, they are only examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the technical solutions described below.

[0035] It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the steps included in the method may be more or less than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may be combined into a single step for description in other embodiments.

[0036] Figure 1 FIG. 1 is a schematic diagram of an exemplary environment provided by an exemplary embodiment. Figure 1 As shown, the example environment 100 allows entities to participate in a blockchain network 102. The blockchain network 102 can be a public type, a private type, or a consortium type blockchain network. The example environment 100 may include computing devices 104, 106, 108, 110, 112 and a network 114; in one embodiment, the network 114 may include a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof, and is connected to a website, a user device (e.g., a computing device), and a backend system. In one embodiment, the network 114 can be accessed via wired and / or wireless communication.

[0037] In some cases, computing devices 106, 108 may be nodes of a cloud computing system (not shown), or each computing device 106, 108 may be a separate cloud computing system including multiple computers interconnected by a network and operating as a distributed processing system.

[0038] In one embodiment, computing devices 104-108 may run any suitable computing system that enables them to serve as nodes in blockchain network 102; for example, computing devices 104-108 may include, but are not limited to, servers, desktop computers, laptop computers, tablet computing devices, and smartphones. In one embodiment, computing devices 104-108 may belong to relevant entities and be used to implement corresponding services, such as the service that can be used to manage transactions between a certain entity or multiple entities.

[0039] In one embodiment, computing devices 104-108 respectively store blockchain ledgers corresponding to blockchain network 102. Computing device 104 may be (or include) a network server for providing browser functions, which may provide visualization information related to blockchain network 102 based on network 114. In some cases, computing device 104 may not participate in block verification, but monitor blockchain network 102 to determine when other nodes (such as computing devices 106-108) reach consensus, and generate a corresponding blockchain visualization user interface accordingly.

[0040] In one embodiment, computing device 104 may receive a request for a blockchain visual user interface initiated by a client device (e.g., computing device 110 or computing device 112). In some cases, a node of blockchain network 102 may also serve as a client device, such as a user of computing device 108 may use a browser running on computing device 108 to send the above request to computing device 104.

[0041] In response to the above request, the computing device 104 may generate a blockchain visual user interface (such as a web page) based on the stored blockchain ledger, and send the generated blockchain visual user interface to the requesting client device. If the blockchain network 102 is a public type, a private type, or a consortium type blockchain network, the request for the blockchain visual user interface may include user authorization information. Before the blockchain visual user interface is generated and sent to the requesting client device, the computing device 104 may verify the user authorization information and return the corresponding blockchain visual user interface after the verification is passed.

[0042] The blockchain visualization user interface can be displayed on the client device (e.g. Figure 1 When the blockchain ledger is updated, the displayed content of the user interface 116 may also be updated accordingly. In addition, the user's interaction with the user interface 116 may result in a request for other user interfaces, such as displaying a block list, block details, a transaction list, transaction details, an account list, account details, a contract list, contract details, or a search result page generated by a user's search of the blockchain network.

[0043] Figure 2 is a schematic diagram of a conceptual architecture provided by an exemplary embodiment. Figure 2 As shown, the conceptual architecture 200 includes an entity layer 202, a hosting service layer 204, and a blockchain network layer 206. For example, the entity layer 202 may include three entities: entity 1, entity 2, and entity 3, each entity having its own transaction management system 208.

[0044] In one embodiment, the managed service layer 204 may include an interface 210 corresponding to each transaction management system 208. For example, each transaction management system 208 uses a protocol (such as Hypertext Transfer Protocol Secure (HTTPS) or the like) to communicate with each other over a network (such as Figure 1In some examples, each interface 210 can provide a communication connection between the transaction management system 208 and the blockchain network layer 206; more specifically, the interface 210 can communicate with the blockchain network 212 of the blockchain network layer 206. In some examples, the communication between the interface 210 and the blockchain network layer 206 can be implemented using remote procedure calls (RPCs). In some examples, the interface 210 can provide an API interface for accessing the blockchain network 212 to the transaction management system 208.

[0045] As described herein, the blockchain network 212 is provided in the form of a peer-to-peer network, which includes a plurality of nodes 214, each of which is used to persist a blockchain ledger 216 formed by the block chain data; wherein, Figure 2 Only one blockchain ledger 216 is shown, but there may be multiple blockchain ledgers 216 or copies thereof in the blockchain network 212. For example, each node 214 may respectively maintain a blockchain ledger 216 or a copy thereof.

[0046] It should be pointed out that the transaction described in this specification refers to a piece of data created by a user through a blockchain client and ultimately published to the distributed database of the blockchain. Among them, transactions in the blockchain can be divided into transactions in a narrow sense and transactions in a broad sense. A transaction in a narrow sense refers to a value transfer published by a user to the blockchain; for example, in a traditional blockchain network, a transaction can be a transfer initiated by a user in the blockchain. A transaction in a broad sense refers to a piece of business data with business intent published by a user to the blockchain; for example, an operator can build a consortium chain based on actual business needs, and rely on the consortium chain to deploy some other types of online businesses that are not related to value transfer (for example, rental business, vehicle dispatch business, insurance claims business, credit services, medical services, etc.), and in this type of consortium chain, a transaction can be a business message or business request with business intent published by a user in the consortium chain.

[0047] Blockchain is generally divided into three types: public blockchain, private blockchain and consortium blockchain. In addition, there are many types of combinations, such as private blockchain + consortium blockchain, consortium blockchain + public blockchain and other different combinations. Among them, the public chain has the highest degree of decentralization. Ethereum is a representative of the public chain. Participants who join the public chain can read the data records on the chain, participate in transactions, and compete for the right to record new blocks. Moreover, each participant (i.e., node) can freely join and exit the network and perform related operations. On the contrary, the private chain has the write permission of the network controlled by a certain organization or institution, and the data reading permission is stipulated by the organization. In simple terms, the private chain can be a weakly centralized system with strictly limited and few participating nodes. This type of blockchain is more suitable for use within a specific organization. The consortium chain is a blockchain between the public chain and the private chain, which can achieve "partial decentralization". Each node in the consortium chain usually has a corresponding entity or organization; participants join the network through authorization and form a stakeholder alliance to jointly maintain the operation of the blockchain.

[0048] Through the distributed architecture adopted by the blockchain network and the chain structure adopted by the blocks, information can be permanently and tamper-freely recorded in the blockchain ledger uniformly maintained by each blockchain node. However, since the blockchain ledger is completely public, the privacy of information cannot be guaranteed. For example, when user A wants to spend an asset held in the blockchain, he can initiate a blockchain transaction and sign it with the private key x_j held by user A. Correspondingly, the above signature can be verified by the public key P_j corresponding to the private key x_j held by user A. However, the direct verification of the signature also exposes user A as the signer of the corresponding signature, thereby leaking the privacy of user A.

[0049] In order to protect the identity of the signatory, a processing scheme based on ring signature is proposed in the related technology. User A can hide the public key P_j held by himself in a group of public keys (P_1,...,P_n), where the public keys P_1~P_j-1 and P_j+1~P_n belong to other users respectively; then, user A generates a signature through the private key x_j held by himself and the above-mentioned group of public keys (P_1,...,P_n). Then, the verifier can verify that the signature is generated by the private key corresponding to a public key in the above-mentioned group of public keys (P_1,...,P_n), but cannot determine which public key it is. Therefore, the identity of the signatory is hidden through the above-mentioned group of public keys (P_1,...,P_n).

[0050] It can be understood that: when described in the form of (P_1, ..., P_n) above, although it seems to be a group of public keys starting from P_1 and ending with P_n, in fact, the order between the public keys cannot be determined for the verifier, making this group of public keys equivalent to a ring structure without a beginning or an end for the verifier, so it is called a ring signature.

[0051] Although the ring signature scheme can hide the identity of the signatory, it will cause the "double-spending" problem when applied to the transaction scenario of the blockchain network. For example, the blockchain network can adopt the UTXO (Unspent Transaction Output) model for asset management: the blockchain assets held by the user are recorded as the output of the corresponding transaction, and each transaction takes one or more unspent transaction outputs as its input and generates one or more outputs accordingly. Typically, UTXO is applied to cryptocurrencies. When the ring signature scheme is applied to a blockchain network based on the UTXO model, the same asset may be referenced by multiple transactions separately, but because the identity of the signatory is hidden by the ring signature scheme, the verifier cannot check that the same asset is repeatedly referenced, resulting in the "double-spending" problem.

[0052] Therefore, an improved scheme for the above-mentioned ring signature scheme is proposed in the related art, called Linkable Spontaneous Anonymous Group Signature (LSAG), which can generate a key-image for marking the signatory, but will not expose the public key corresponding to the signatory in a set of ring signatures used for signing. In this way, the identity of the signatory can be hidden, and the "double-spending" problem can be solved based on the key-image.

[0053] When the private key held by the signer is x_j and the public key is P_j, the public key P_j can be hidden in a group of public keys (P_1, ..., P_n), and the key-image used can be I = x_j × Hash (P_j). Then, even if the signer hides the public key P_j in multiple groups of public keys and implements a linkable ring signature, the key-image generated each time is the same, so that the verifier can identify the "double-spending" problem based on this, thereby restricting the execution of related transactions.

[0054] However, in the above scheme, the key-image value is related to the private key x_j and public key P_j held by the signer, resulting in the same key-image value generated in different transactions for the same set of public-private key pairs, and thus can only be used once. Accordingly, the signer needs to maintain many public-private key pairs, and each transaction needs to use a new set of public-private key pairs, which increases the maintenance cost of the public-private key pairs.

[0055] To this end, this specification proposes a new linkable ring signature solution, so that the signer only needs to maintain a set of public and private key pairs to generate linkable ring signatures for all transactions of the signer, and support effective verification of linkable ring signatures.

[0056] Figure 3 This is a flowchart of a method for generating a linkable ring signature in a blockchain provided by an exemplary embodiment. Figure 3 As shown, the method may include the following steps:

[0057] Step 302, determine the signer array (P_j, ID_j), the signer array (P_j, ID_j) includes the signer's public key P_j = x_j × G and the unique identifier ID_j of the asset to be spent held by the signer, where G is the base point of the elliptic curve, |G| = p and p is a prime number, x_j is the signer's private key and 0 <x_j<p。

[0058] In one embodiment, the signatory in this specification may be any user who can perform a signing operation, and does not specifically refer to a certain user, and this specification does not limit this.

[0059] In one embodiment, the assets held by the signer in the blockchain may include one or more types of blockchain assets (such as blockchain rewards obtained by the signer through competition for bookkeeping rights, or obtained through transactions), off-chain assets, etc. The signer's asset holding information can be recorded in the blockchain account book; since the content of the blockchain account book is in a public state, the signer's asset holding information can be recorded in an encrypted form, for example, the asset value can be converted into a corresponding commitment value (for example, it can be converted based on the Pedersen commitment algorithm), and for another example, the above holding information can be stored in a ciphertext form on the blockchain node, and the ciphertext holding information can be decrypted and read in the Trusted Execution Environment (TEE) on the blockchain node. In short, the signer's asset holding information can be protected by the above or other methods to avoid leaking the signer's privacy.

[0060] In one embodiment, each user has a corresponding set of public-private key pairs on the blockchain, and a set of public-private key pairs only corresponds to one user, so the identity information of the relevant user can be represented by the public key or private key. For example, the above-mentioned signer can hold a public-private key pair consisting of a private key x_j and a public key P_j, where the private key x_j is kept by the signer, and the public key P_j is open to other users, blockchain nodes, etc., so that the public key P_j can be used to represent the identity information of the signer.

[0061] In one embodiment, the method of generating a private key x_j and a public key P_j includes: selecting a number field Z_q and an elliptic curve on the number field, for example, the elliptic curve can be Ed25519 or other; let the base point (or generator) of the selected elliptic curve be G, where |G|=p and p is a large prime number (for example, a prime number whose value is not less than a preset value); randomly select a private key x_j, so that 0<x_j<p, then the public key P_j=x_j×G. The generation process of the public and private key pairs of other users can refer to the above description. Of course, each user can also use other algorithms to generate public and private key pairs, and this specification does not limit this.

[0062] In one embodiment, each asset held by the signatory has a corresponding unique identifier, and the blockchain account book can record the correspondence between the signatory's public key P_j and the unique identifier of the asset held by the signatory, so that each blockchain node can determine the signatory's holding of the relevant assets based on the correspondence. For example, when the blockchain account book records the correspondence between the public key P_j and the identifier ID_j, it indicates that the user corresponding to the public key P_j (in the above embodiment, the user is the signatory) holds the asset corresponding to the identifier ID_j. Similarly, when the blockchain account book records the correspondence between the public key P_i and the identifier ID_i, it indicates that the user corresponding to the public key P_i holds the asset corresponding to the identifier ID_i.

[0063] In one embodiment, the unique identifier corresponding to the asset can be generated in any form as long as the uniqueness can be guaranteed. For example, the unique identifier can include a digital summary of the asset (such as a hash value). For another example, when there may be duplicate content between assets, the asset's creation timestamp, creation order, block height of the block in which it is located, and other information can be further added, and this information can be used together with the asset's content to generate a digital summary as the unique identifier of the asset.

[0064] In one embodiment, when the asset that the signer wishes to spend corresponds to the unique identifier ID_j, the public key P_j of the signer and the unique identifier ID_j can be combined into the above-mentioned signer array (P_j, ID_j). Of course, the signer array can also be in the form of (ID_j, P_j) or other forms, and this specification does not limit this.

[0065] Step 304: Generate a key image I according to the signer's private key x_j and the signer array (P_j, ID_j).

[0066] In one embodiment, a key image I is generated based on the private key x_j of the signer and the signer array (P_j, ID_j), so that the key image is related to the unique identifier ID_j of the asset in addition to the private key x_j and the public key P_j. Since the unique identifier ID_j of each asset must be different and unique, even if the signer only holds a set of public-private key pairs consisting of a private key x_j and a public key P_j, as long as the assets involved are different, the unique identifier ID_j of the asset can be ensured to be different, thereby generating different key-images. In other words, this specification adds consideration of the unique identifier ID_j of the asset in the process of generating the key image I, so that the signer only needs to maintain a set of public-private key pairs to generate different key-images for different assets, thereby solving the "double-spending" problem while enabling the public-private key pairs to be used without restriction, without the need to maintain multiple sets of public-private key pairs, and eliminating the need to replace the public-private key pairs after each transaction.

[0067] In one embodiment, based on the above elliptic curve, a hash function Hash_G() from the elliptic curve to itself can be selected to calculate the above key image I. For example, according to the private key x_j of the signer and the signer array (P_j, ID_j), the key image I = x_j × Hash_G (P_j, ID_j) can be calculated. Of course, other hash functions can be selected, and the above key image I can also be calculated based on the private key x_j and the signer array (P_j, ID_j), and this specification does not limit this.

[0068] Step 306: When generating a linkable ring signature for a transaction M related to the asset to be spent, add the key image I to the linkable ring signature.

[0069] By adding key image I to the linkable ring signature, each blockchain node can extract key image I from the linkable ring signature of transaction M after receiving transaction M to verify the key image I. Figure 4 To introduce the relevant verification process.

[0070] Figure 4 FIG. 1 is a flowchart of a method for verifying a linkable ring signature in a blockchain provided by an exemplary embodiment. Figure 4 As shown, the method may include the following steps:

[0071] Step 402: Obtain the key image I contained in the linkable ring signature of transaction M. The key image I is generated by the signer according to the private key x_j held by the signer and the signer array (P_j, ID_j). The signer array (P_j, ID_j) contains the signer's public key P_j and the unique identifier ID_j of the asset to be spent related to the transaction M.

[0072] Step 404: verify the key image I according to the saved historical key image to determine the validity of the linkable ring signature.

[0073] In one embodiment, each blockchain node can serve as a verifier to verify the linkable ring signature of the received transaction M to determine the validity of the linkable ring signature. The verification of the key image I is one of the verification operations of the linkable ring signature; in other words, the verification of the linkable ring signature can also include other operations. When any operation is confirmed as a verification failure, the verification process can be terminated and the verification failure can be determined; when all operations are confirmed as verification successes, it can be determined that the linkable ring signature is verified to be valid.

[0074] In one embodiment, the verifier maintains a historical key image, that is, a key image that the verifier has previously verified. The verifier can compare key image I with the historical key image: if key image I is the same as a certain historical key image, it indicates that the asset corresponding to identifier ID_j has been spent, and transaction M has a "double-spending" problem with the asset, then the linkable ring signature must be invalid; if key image I is different from all historical key images maintained by the blockchain node, it indicates that there is no "double-spending" problem, and the validity of the linkable ring signature can be determined in combination with other verification operations.

[0075] Among them, when the key image I is different from all the historical key images maintained by the blockchain node, after confirming that the asset corresponding to the identifier ID_j has been spent, the blockchain node adds the key image I as a historical key image to check for subsequent possible "double spending" problems for the asset.

[0076] Since the present specification adopts the form of array, such as the above-mentioned signer array (P_j, ID_j), it is necessary to determine the shielding array (P_i, ID_i) accordingly, so as to hide the signer array (P_j, ID_j) in the shielding array (P_i, ID_i) to achieve the hiding of the signer's identity information. Therefore, the generation and verification process of the linkable ring signature in this specification is also different from the above-mentioned method to a certain extent, which will be introduced below.

[0077] Combine the following Figure 5 Introducing a scheme for generating linkable ring signatures in this specification, such as Figure 5 As shown, the following steps may be included:

[0078] Step 502: The signer determines the array set [(P_1, ID_1), ..., (P_n, ID_n)].

[0079] In one embodiment, since j∈[1,n], the signer array (P_j,ID_j) is included in the above array set, and the remaining shielding arrays (P_i,ID_i) can be used to shield the signer array (P_j,ID_j), where i∈[1,j-1]∪[j+1,n]. Accordingly, the signer can generate a linkable ring signature based on its own private key x_j and the array set [(P_1,ID_1),…,(P_n,ID_n)].

[0080] In one embodiment, since the public key of each user is open to the public, the signer can randomly select n-1 users as the above-mentioned shielding parties. At the same time, since the unique identifiers of the assets held by each user are recorded in the blockchain ledger, the signer can query the unique identifiers of the assets held by these shielding parties from the blockchain ledger according to the selected n-1 shielding parties to form the corresponding shielding party array (P_i, ID_i).

[0081] Step 504: The signer calculates the key image I.

[0082] In one embodiment, the calculation process of the key image I can refer to the above Figure 3 The embodiments shown will not be described in detail here.

[0083] Step 506: The signer calculates the intermediate parameters L_j and R_j.

[0084] In one embodiment, the signer array (P_j, ID_j) and the shielding array (P_i, ID_i) contained in the array set [(P_1, ID_1), ..., (P_n, ID_n)] can be used to calculate the corresponding intermediate parameters L and R, respectively. For example, the signer array (P_j, ID_j) corresponds to the intermediate parameters L_j and R_j, and the shielding array (P_i, ID_i) corresponds to the intermediate parameters L_i and R_i. There is a certain dependency relationship between the intermediate parameters corresponding to different arrays. For example, the intermediate parameters L_j and L_i conform to the circular value rule, and the intermediate parameters R_j and R_i conform to the circular value rule. The values ​​of the intermediate parameters L_j, R_j, L_i, and R_i are related to at least one selected random number and / or its derivative value. The signer can generate a linkable ring signature for a transaction M based on the selected random number and / or its derivative value, and the transaction M is used to spend the assets corresponding to the identifier ID_j.

[0085] In the process of generating the intermediate parameters L and R corresponding to each array, the signer first generates the intermediate parameters L_j and R_j corresponding to the signer array (P_j, ID_j), and then generates the intermediate parameters L_i and R_i corresponding to each shielding array (P_i, ID_i) in sequence through subsequent steps. Although the signer does not rely on the intermediate parameters L_i and R_i corresponding to other arrays in the process of generating the intermediate parameters L_j and R_j, it can ultimately ensure that the intermediate parameters L_j and R_j maintain a dependency relationship with other intermediate parameters L_i and R_i in terms of value, thereby forming the above-mentioned circular value-taking rule.

[0086] In one embodiment, the signer may select a random number a from the number field Z_q described above, and calculate the intermediate parameters L_j and R_j according to the following formula:

[0087] L_j=a×G

[0088] R_j=a×Hash_G(P_j,ID_j)

[0089] Among them, G is the generator of the above-mentioned elliptic curve, and Hash_G() is the above-mentioned hash function from the elliptic curve to itself.

[0090] Furthermore, the signer may generate intermediate parameters L_i and R_i corresponding to the shielding party i, including: generating intermediate parameters L_i and R_i respectively according to the values ​​of the intermediate parameters L_j and R_j; this is described below in conjunction with steps 508 to 512.

[0091] Step 508: The signer calculates the intermediate parameters L_(j+1)~L_n, R_(j+1)~R_n.

[0092] In one embodiment, the calculation process of the intermediate parameters L_i and R_i conforms to the following formula:

[0093] L_i=(s_i×G+c_i×P_i)mod p

[0094] R_i=(s_i×Hash_G(P_i,ID_i)+c_i×I)mod p

[0095] In the calculation process, s_(j+1)~s_n are involved, which are all random numbers in the number field Z_q. In addition, c_(j+1)~c_n are involved in the calculation process, and the calculation process conforms to the following formula: c_i=Hash(M,L_(i-1),R_(i-1)), where Hash() is the hash function from the above-mentioned elliptic curve to the number field Z_q.

[0096] Therefore, in the case where L_j and R_j have been calculated in step 506, the intermediate parameters L_i and R_i when i∈[j+1,n] are calculated based on L_j and R_j, namely the above-mentioned L_(j+1)~L_n, R_(j+1)~R_n. Specifically, firstly, c_(j+1) is calculated based on the values ​​of L_j and R_j, and L_(j+1) and R_(j+1) are calculated based on the random number s_(j+1) and the calculated c_(j+1); then c_(j+2) is calculated based on the values ​​of L_(j+1) and R_(j+1), and L_(j+2) and R_(j+2) are calculated based on the random number s_(j+2) and the calculated c_(j+2); and so on, until L_n and R_n are calculated.

[0097] Step 510: The signer calculates the intermediate parameters L_1 and R_1.

[0098] In one embodiment, the calculation process of the intermediate parameters L_1 and R_1 complies with the following formula:

[0099] L_1=(s_1×G+c_1×P_1)mod p

[0100] R_1=(s_1×Hash_G(P_1,ID_1)+c_1×I)mod p

[0101] Among them, s_1 is a random number in the number field Z_q, c_1=Hash(M,L_n,R_n). Since the intermediate parameters conform to the circular value rule, although the intermediate parameters are expressed as L_1~L_n, R_1~R_n for the convenience of description, L_1 and R_1 are not arranged in the first place, and L_n and R_n are not arranged in the last place. In fact, it should be considered that L_1 and L_n are adjacent, and R_1 and R_n are adjacent. Therefore, when c_1=Hash(M,L_n,R_n), it actually conforms to c_i=Hash(M,L_(i-1),R_(i-1)) described in the above step 508, that is, the calculation formula of c_1 is consistent with that of c_(j+1)~c_n.

[0102] Step 512: The signer calculates the intermediate parameters L_2~L_(j-1) and R_2~R_(j-1).

[0103] In one embodiment, the calculation process of the intermediate parameters L_i and R_i conforms to the following formula:

[0104] L_i=(s_i×G+c_i×P_i)mod p

[0105] R_i=(s_i×Hash_G(P_i,ID_i)+c_i×I)mod p

[0106] In the calculation process, s_2~s_(j-1) are involved, which are all random numbers in the number field Z_q. In addition, c_2~c_(j-1) are involved in the calculation process, and the calculation process conforms to the following formula: c_i=Hash(M,L_(i-1),R_(i-1)).

[0107] Therefore, when L_1 and R_1 have been calculated in step 510, the intermediate parameters L_i and R_i at i∈[2,j-1] are calculated based on L_j and R_j, namely the above-mentioned L_2~L_(j-1) and R_2~R_(j-1). Specifically, firstly, c_2 is calculated based on the values ​​of L_1 and R_1, and L_2 and R_2 are calculated based on the random number s_2 and the calculated c_2; then c_3 is calculated based on the values ​​of L_2 and R_2, and L_3 and R_3 are calculated based on the random number s_3 and the calculated c_3; and so on, until L_(j-1) and R_(j-1) are calculated.

[0108] In step 514, the signer generates a linkable ring signature (I, c_1, s_1 ... s_n).

[0109] In one embodiment, based on the processing of the above steps, key images I, c_1, s_1 to s_(j-1), s_(j+1) to s_n can be obtained, and s_j needs to be calculated by the signatory according to the following formula:

[0110] s_j=(a-c_j×x_j)mod p

[0111]

[0112] Among them, although the above formula divides the value of c_j into two cases, first of all, the value of parameter j is actually fixed, for example, the value of parameter j is fixed to 1 or a value in [2,n], which should be distinguished from the above parameter i (parameter i has n values, 1 to n); at the same time, similar to the above description of c_1: since the intermediate parameters conform to the circular value rule, although the intermediate parameters are expressed as L_1 to L_n, R_1 to R_n for the convenience of description, L_1 and R_1 are not arranged in the first place, and L_n and R_n are not arranged in the last place. In fact, it should be considered that L_1 and L_n are adjacent, and R_1 and R_n are adjacent. Therefore, when c_1 = Hash(M, L_n, R_n), it actually meets c_j = Hash(M, L_(j-1), R_(j-1)).

[0113] Therefore, the linkable ring signature (I, c_1, s_1…s_n) contains the key image I, the random number s_i (where i∈[1,j-1]∪[j+1,n]), the derived values ​​s_j and c_1 (calculated based on the random numbers s_i, a, etc.).

[0114] against Figure 5 The linkable ring signature (I,c_1,s_1…s_n) generated in Figure 6 Introducing a scheme for verifying linkable ring signatures in this specification, such as Figure 6 As shown, the following steps may be included:

[0115] Step 602, the verifier verifies whether the asset corresponding to the identifier ID_k belongs to the holder of the public key P_k, k∈[1,n].

[0116] In one embodiment, the verifier may be a blockchain node in the blockchain network. After receiving the transaction M submitted by the signer, the blockchain node may verify the linkable ring signature of the transaction M. Similarly, each blockchain node will receive the transaction M and perform verification as a verifier. The transaction M may be sent from the client to the verifier, or the transaction M may be forwarded to other verifiers after being received from the client by a verifier, or the transaction M may be forwarded to other verifiers after being received from another verifier by a verifier.

[0117] In one embodiment, the verifier maintains the asset holdings of each user, and can verify whether the corresponding relationship between each public key P_k and the identifier ID_k in the corresponding array is established, that is, whether the holder of the public key P_k owns the asset corresponding to the identifier ID_k. If the corresponding relationship between each public key P_k and the identifier ID_k in the corresponding array is established, the subsequent steps can be continued; if the asset corresponding to a certain identifier ID_r does not belong to the holder of the public key P_k in the corresponding array (P_k, ID_k), the verifier can determine that the linkable ring signature is invalid, and there is no need to continue to execute the subsequent steps 604 to 608.

[0118] Step 604: The verifier calculates L_1~L_n, R_1~R_n in sequence according to s_1...s_n.

[0119] Step 606: The verifier calculates c_1' based on L_n and R_n, and verifies whether c_1' is equal to c_1.

[0120] In one embodiment, the verifier may calculate the intermediate parameters L_j, R_j, L_i, and R_i based on the random number and / or its derivative value contained in the linkable ring signature to verify whether the intermediate parameters L_j and L_i comply with the ring value rule, and whether the intermediate parameters R_j and R_i comply with the ring value rule.

[0121] For example, when the random number and / or its derivative value contained in the linkable ring signature includes: s_1~s_n, c_1, the ring value rule between the intermediate parameters L_j and L_i may include:

[0122] L_m=(s_m×G+c_m×P_m)mod p,m∈[1,n]

[0123]

[0124] The ring value rules between the intermediate parameters R_j and R_i include:

[0125] R_m=(s_m×Hash_G(P_m,ID_m)+c_m×I)mod p

[0126] Then, the verifier can first generate L_1 based on s_1, c_1, G, P_1 and p, and generate R_1 based on s_1, c_1, P_1, ID_1, I and p; then, the verifier can generate c_2 based on M, L_1 and R_1, and generate L_2 based on s_2, c_2, G, P_2 and p, and generate R_2 based on s_2, c_2, P_2, ID_2, I and p; and so on, until the verifier generates c_n based on M, L_(n-1) and R_(n-1), and generates L_n based on s_n, c_n, G, P_n and p, and generates R_n based on s_n, c_n, P_n, ID_n, I and p.

[0127] Furthermore, the verifier can calculate c_1'=Hash(M,L_n,R_n) according to the above calculation formula for c_m. The reason why c_1' is used here is to distinguish it from c_1 contained in the linkable ring signature. Then the verifier can compare c_1' with c_1 contained in the linkable ring signature: if c_1' is equal to c_1, it indicates that the above ring value rule is satisfied, and the linkable ring signature is indeed generated by the signer according to the private key x_j and the array set [(P_1,ID_1),...,(P_n,ID_n)], and continue to execute the subsequent steps; if c_1' is not equal to c_1, it indicates that the above ring value rule is not satisfied, the linkable ring signature is confirmed to be invalid, and there is no need to continue to execute the following step 608.

[0128] Step 608: The verifier verifies whether key image I already exists.

[0129] In one embodiment, reference may be made to Figure 4The illustrated embodiment enables the verifier to compare key image I with the historical key image to determine whether the key image I already exists, so as to verify whether there is a "double spending" problem.

[0130] Figure 7 is a schematic structural diagram of a device provided by an exemplary embodiment. Figure 7 , at the hardware level, the device includes a processor 702, an internal bus 704, a network interface 706, a memory 708, and a non-volatile memory 710, and may also include hardware required for other services. The processor 702 reads the corresponding computer program from the non-volatile memory 710 into the memory 708 and then runs it, forming a device for generating a linkable ring signature in the blockchain at the logical level. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0131] Please refer to Figure 8 In a software implementation, the device for generating a linkable ring signature in the blockchain may include:

[0132] The determination unit 801 determines a signature party array (P_j, ID_j), wherein the signature party array (P_j, ID_j) includes the public key P_j=x_j×G of the signature party and the unique identifier ID_j of the asset to be spent held by the signature party, wherein G is the base point of the elliptic curve, |G|=p and p is a prime number, x_j is the private key of the signature party and 0 <x_j<p;

[0133] A first generating unit 802 generates a key image I according to the private key x_j of the signer and the signer array (P_j, ID_j);

[0134] The second generating unit 803 adds the key image I to the linkable ring signature when generating a linkable ring signature for a transaction M related to the asset to be spent.

[0135] Optionally, the first generating unit 802 calculates the key image I by the following formula:

[0136] I = x_j × Hash_G (P_j, ID_j);

[0137] Among them, Hash_G() is the hash function of the elliptic curve to itself.

[0138] Optionally, the second generating unit 803 is specifically configured to:

[0139] Determine the shielding party array (P_i, ID_i) corresponding to the signing party array (P_j, ID_j), wherein the shielding party array (P_i, ID_i) contains the public key P_i of shielding party i and the unique identifier ID_i of the asset held by shielding party i, i∈[1,j-1]∪[j+1,n];

[0140] The linkable ring signature is generated according to the private key x_j of the signer and the array set [(P_1, ID_1), ..., (P_n, ID_n)].

[0141] Optionally, the second generating unit 803 is specifically configured to:

[0142] According to the private key x_j of the signer and the array set [(P_1, ID_1), ..., (P_n, ID_n)], generate intermediate parameters L_j and R_j corresponding to the signer, and intermediate parameters L_i and R_i corresponding to the shielding party i respectively; wherein the intermediate parameters L_j and L_i conform to the circular value rule, the intermediate parameters R_j and R_i conform to the circular value rule, and the values ​​of the intermediate parameters L_j, R_j, L_i, R_i are related to at least one selected random number and / or its derivative value;

[0143] A linkable ring signature for the transaction M is generated according to the selected random number and / or its derivative value.

[0144] Optional,

[0145] The second generation unit 803 generates the intermediate parameters L_j and R_j corresponding to the signer in the following manner: according to the random number a selected from the number field Z_q where the elliptic curve is located, the intermediate parameters L_j and R_j are calculated, where L_j=a×G, R_j=a×Hash_G(P_j,ID_j), G is the generator of the elliptic curve, and Hash_G() is the hash function from the elliptic curve to itself;

[0146] The second generation unit 803 generates the intermediate parameters L_i and R_i corresponding to the shielding party i in the following manner: according to the values ​​of the intermediate parameters L_j and R_j, the intermediate parameters L_i and R_i are generated respectively, so that L_i=(s_i×G+c_i×P_i)modp, R_i=(s_i×Hash_G(P_i,ID_i)+c_i×I)mod p; wherein s_i is a random number in the number field Z_q, when i=1, c_1=Hash(M,L_n,R_n), when i∈[2,j-1]∪[j+1,n], c_i=Hash(M,L_(i-1),R_(i-1)), and Hash() is a hash function from the elliptic curve to the number field Z_q;

[0147] Among them, the selected random number and / or its derived value include: random number s_i, derived value c_1, derived value s_j; among them, s_j=(a-c_j×x_j)mod p, when the value of j is determined to be 1, c_j=Hash(M,L_n,R_n), when the value of j is determined to belong to [2,n], c_j=Hash(M,L_(j-1),R_(j-1)).

[0148] Optionally, the second generating unit 803 generates intermediate parameters L_i and R_i respectively according to the values ​​of the intermediate parameters L_j and R_j, including:

[0149] For i∈[j+1,n], generate intermediate parameters L_i and R_i respectively, so that L_i=(s_i×G+c_i×P_i)modp, R_i=(s_i×Hash_G(P_i,ID_i)+c_i×I)mod p, where s_i is a random number in the number field Z_q, c_i=Hash(M,L_(i-1),R_(i-1));

[0150] For i=1, generate intermediate parameters L_1 and R_1, so that L_1=(s_1×G+c_1×P_1)mod p, R_1=(s_1×Hash_G(P_1,ID_1)+c_1×I)mod p, where s_1 is a random number in the number field Z_q, and c_1=Hash(M,L_n,R_n);

[0151] For i∈[2,j-1], generate intermediate parameters L_i and R_i respectively, so that L_i=(s_i×G+c_i×P_i)modp, R_i=(s_i×Hash_G(P_i,ID_i)+c_i×I)mod p, where s_i is a random number in the number field Z_q, c_i=Hash(M,L_(i-1),R_(i-1)).

[0152] Fig. 9 is a schematic structural diagram of a device provided by an exemplary embodiment. Fig. 9, at the hardware level, the device includes a processor 902, an internal bus 904, a network interface 906, a memory 908, and a non-volatile memory 910, and may also include hardware required for other services. The processor 902 reads the corresponding computer program from the non-volatile memory 910 into the memory 908 and then runs it, forming a device for verifying the linkable ring signature in the blockchain at the logical level. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0153] Please refer to Fig.10 In a software implementation, the device for verifying a linkable ring signature in the blockchain may include:

[0154] The acquisition unit 1001 acquires the key image I contained in the linkable ring signature of the transaction M, wherein the key image I is generated by the signer according to the private key x_j held by the signer and the signer array (P_j, ID_j), wherein the signer array (P_j, ID_j) includes the signer's public key P_j=x_j×G and the unique identifier ID_j of the asset to be spent related to the transaction M, wherein G is the base point of the elliptic curve, |G|=p and p is a prime number, 0 <x_j<p;

[0155] The first verification unit 1002 verifies the key image I according to the stored historical key image to determine the validity of the linkable ring signature.

[0156] Optionally, the linkable ring signature is generated by the signer according to the private key x_j and the array set [(P_1, ID_1), ..., (P_n, ID_n)]; wherein the shielding party array (P_i, ID_i) corresponding to the signer array (P_j, ID_j) contains the shielding party i's public key P_i and the unique identifier ID_i of the asset held by the shielding party i, i∈[1,j-1]∪[j+1,n]; the device further includes:

[0157] The second verification unit 1003 verifies whether the asset corresponding to the identifier ID_k belongs to the holder of the public key P_k, k∈[1,n].

[0158] Optionally, the linkable ring signature is generated by the signatory according to the private key x_j and the array set [(P_1, ID_1), ..., (P_n, ID_n)], after the intermediate parameters L_j and R_j corresponding to the signatory and the intermediate parameters L_i and R_i corresponding to the shielding party i are generated respectively, according to the random number and / or its derivative value related to the values ​​of the intermediate parameters L_j, R_j, L_i, R_i; the device also includes:

[0159] The third verification unit 1004 calculates the intermediate parameters L_j, R_j, L_i, and R_i according to the random number and / or its derivative value contained in the linkable ring signature to verify whether the intermediate parameters L_j and L_i comply with the ring value rule, and whether the intermediate parameters R_j and R_i comply with the ring value rule.

[0160] Optional,

[0161] The random number and / or its derived value contained in the linkable ring signature includes: s_1 to s_n, c_1;

[0162] The ring value rule between the intermediate parameters L_j and L_i includes: L_m = (s_m × G + c_m × P_m) mod p, m∈[1,n], when m=1, c_1 = Hash(M,L_n,R_n), when m∈[2,n], c_m = Hash(M,L_(m-1),R_(m-1)); wherein, s_m belongs to the number field Z_q where the elliptic curve is located, and Hash() is a hash function from the elliptic curve to the number field Z_q;

[0163] The circular value rules between the intermediate parameters R_j and R_i include: R_m=(s_m×Hash_G(P_m, ID_m)+c_m×I)mod p, where Hash_G() is a hash function from the elliptic curve to itself.

[0164] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, a game console, a tablet computer, a wearable device or a combination of any of these devices.

[0165] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0166] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0167] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0168] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0169] The above is a description of a specific embodiment of the present specification. Other embodiments are within the scope of the technical solution of the present specification. In some cases, the actions or steps recorded in the present specification can be performed in an order different from that in the embodiment and still achieve the desired results. In addition, the process depicted in the accompanying drawings does not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0170] The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms of "a", "said" and "the" used in one or more embodiments of this specification are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in this article refers to and includes any or all possible combinations of one or more associated listed items.

[0171] It should be understood that although the terms first, second, third, etc. may be used to describe various information in one or more embodiments of this specification, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0172] The above description is merely a preferred embodiment of one or more embodiments of the present specification and is not intended to limit one or more embodiments of the present specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of the present specification shall be included in the scope of protection of one or more embodiments of the present specification.

Claims

1. A method for generating a linkable ring signature in a blockchain, comprising: Determine the signing party array (P_j, ID_j), which contains the signing party's public key P_j = x_j × G and the unique identifier ID_j of the asset to be spent held by the signing party, where G is the base point of the elliptic curve, |G| = p and p is a prime number, x_j is the signing party's private key and 0 <x_j<p; Generate a key image I according to the private key x_j of the signer and the signer array (P_j, ID_j); Determine the shielding party array (P_i, ID_i) corresponding to the signing party array (P_j, ID_j), wherein the shielding party array (P_i, ID_i) includes the public key P_i of shielding party i and the unique identifier ID_i of the asset held by shielding party i, i, j∈[1,n], i, j and n are positive integers, i≠j, n≧2; Generate the linkable ring signature according to the signer's private key x_j and the array set [(P_1, ID_1), ..., (P_n, ID_n)]; Wherein, when a linkable ring signature is generated for a transaction M related to the asset to be spent, the key image I is added to the linkable ring signature.

2. According to the method of claim 1, the assets to be spent held by the signatory include blockchain assets and / or off-chain assets.

3. The method according to claim 2, generating the linkable ring signature according to the private key x_j of the signer and the array set [(P_1, ID_1), ..., (P_n, ID_n)], comprising: According to the private key x_j of the signer and the array set [(P_1, ID_1), ..., (P_n, ID_n)], generate intermediate parameters L_j and R_j corresponding to the signer, and intermediate parameters L_i and R_i corresponding to the shielding party i respectively; wherein the intermediate parameters L_j and L_i conform to the circular value rule, the intermediate parameters R_j and R_i conform to the circular value rule, and the values ​​of the intermediate parameters L_j, R_j, L_i, R_i are related to at least one selected random number and / or its derivative value; A linkable ring signature for the transaction M is generated according to the selected random number and / or its derivative value.

4. The method according to claim 3, Generating intermediate parameters L_j and R_j corresponding to the signer, including: According to the random number a selected in the number field Z_q where the elliptic curve is located, calculate the intermediate parameters L_j and R_j, where L_j = a×G, R_j = a×Hash_G(P_j, ID_j), and Hash_G() is a hash function from the elliptic curve to itself; Generate intermediate parameters L_i and R_i corresponding to the shielding party i, including: according to the values ​​of the intermediate parameters L_j and R_j, respectively generate intermediate parameters L_i and R_i, so that L_i=(s_i×G+c_i×P_i)mod p, R_i=(s_i×Hash_G(P_i,ID_i)+c_i×I)mod p; wherein s_i is a random number in the number field Z_q, when i=1, c_1=Hash(M,L_n,R_n), when i∈[2,j-1]∪[j+1,n], c_i=Hash(M,L_(i-1),R_(i-1)), and Hash() is a hash function from the elliptic curve to the number field Z_q; Among them, the selected random number and / or its derived value include: random number s_i, derived value c_1, derived value s_j; among them, s_j=(a-c_j×x_j)mod p, when the value of j is determined to be 1, c_j=Hash(M,L_n,R_n), when the value of j is determined to belong to [2,n], c_j=Hash(M,L_(j-1),R_(j-1)).

5. The method according to claim 4, wherein the generating of intermediate parameters L_i and R_i respectively according to the values ​​of intermediate parameters L_j and R_j comprises: For i∈[j+1,n], generate intermediate parameters L_i and R_i respectively, so that L_i=(s_i×G+c_i×P_i)mod p, R_i=(s_i×Hash_G(P_i,ID_i)+c_i×I)mod p, where s_i is a random number in the number field Z_q, c_i=Hash(M,L_(i-1),R_(i-1)); For i=1, generate intermediate parameters L_1 and R_1, so that L_1=(s_1×G+c_1×P_1)mod p, R_1=(s_1×Hash_G(P_1,ID_1)+c_1×I)mod p, where s_1 is a random number in the number field Z_q, and c_1=Hash(M,L_n,R_n); For i∈[2,j-1], generate intermediate parameters L_i and R_i respectively, so that L_i=(s_i×G+c_i×P_i)mod p, R_i=(s_i×Hash_G(P_i,ID_i)+c_i×I)mod p, where s_i is a random number in the number field Z_q, c_i=Hash(M,L_(i-1),R_(i-1)).

6. According to the method of claim 1, the key image I is calculated by the following formula: I = x_j × Hash_G (P_j, ID_j); in, Hash_G() is the hash function of the elliptic curve to itself.

7. According to the method of claim 1, the unique identifier ID_j includes a digital summary of the asset to be spent, and the digital summary is generated based on the following information: the asset content, creation timestamp, creation order and block height of the block in which the asset to be spent is located.

8. A method for verifying a linkable ring signature in a blockchain, comprising: Get the key image I contained in the linkable ring signature of transaction M, the key image I is generated by the signer according to the private key x_j held and the signer array (P_j, ID_j), the signer array (P_j, ID_j) contains the signer's public key P_j = x_j × G and the unique identifier ID_j of the asset to be spent related to the transaction M, where G is the base point of the elliptic curve, |G| = p and p is a prime number, 0 <x_j<p; Verifying the key image I according to the saved historical key image to determine the validity of the linkable ring signature; The linkable ring signature is generated by the signer according to the private key x_j and the array set [(P_1, ID_1), ..., (P_n, ID_n)]; the shielding party array (P_i, ID_i) corresponding to the signer array (P_j, ID_j) contains the shielding party i's public key P_i and the unique identifier ID_i of the asset held by the shielding party i, i, j∈[1,n], i, j and n are positive integers, i≠j, n≧2.

9. The method according to claim 8, further comprising: Verify whether the asset corresponding to ID_k belongs to the holder of the public key P_k, k∈[1,n].

10. According to the method of claim 8, the linkable ring signature is generated by the signatory according to the private key x_j and the array set [(P_1, ID_1), ..., (P_n, ID_n)], respectively, and the intermediate parameters L_j and R_j corresponding to the signatory, and the intermediate parameters L_i and R_i corresponding to the shielding party i, and then the random number and / or its derivative value related to the value of the intermediate parameters L_j, R_j, L_i, R_i is generated; the method further comprises: According to the random number and / or its derivative value contained in the linkable ring signature, the intermediate parameters L_j, R_j, L_i, and R_i are calculated to verify whether the intermediate parameters L_j and L_i comply with the ring value rule, and whether the intermediate parameters R_j and R_i comply with the ring value rule.

11. The method according to claim 10, The random number and / or its derivative value contained in the linkable ring signature includes: s_1~s_n, c_1; The ring value rule between the intermediate parameters L_j and L_i includes: L_m = (s_m × G + c_m × P_m) mod p, m∈[1,n], when m=1, c_1 = Hash(M,L_n,R_n), when m∈[2,n], c_m = Hash(M,L_(m-1),R_(m-1)); wherein, s_m belongs to the number field Z_q where the elliptic curve is located, and Hash() is a hash function from the elliptic curve to the number field Z_q; The circular value rules between the intermediate parameters R_j and R_i include: R_m=(s_m×Hash_G(P_m, ID_m)+c_m×I)mod p, where Hash_G() is a hash function from the elliptic curve to itself.

12. According to the method of claim 8, the assets to be spent held by the signatory party include blockchain assets and / or off-chain assets.

13. According to the method of claim 8, the unique identifier ID_j includes a digital summary of the asset to be spent, and the digital summary is generated based on the following information: the asset content, creation timestamp, creation order and block height of the block in which the asset to be spent is located.

14. A device for generating a linkable ring signature in a blockchain, comprising: A determination unit determines a signature party array (P_j, ID_j), wherein the signature party array (P_j, ID_j) includes the public key P_j=x_j×G of the signature party and the unique identifier ID_j of the asset to be spent held by the signature party, wherein G is the base point of the elliptic curve, |G|=p and p is a prime number, x_j is the private key of the signature party and 0 <x_j<p; A first generating unit generates a key image I according to the private key x_j of the signer and the signer array (P_j, ID_j); A second generating unit, when generating a linkable ring signature for a transaction M related to the asset to be spent, adds the key image I to the linkable ring signature; The linkable ring signature is generated by the signer according to the private key x_j and the array set [(P_1, ID_1), ..., (P_n, ID_n)]; the shielding party array (P_i, ID_i) corresponding to the signer array (P_j, ID_j) contains the shielding party i's public key P_i and the unique identifier ID_i of the asset held by the shielding party i, i, j∈[1,n], i, j and n are positive integers, i≠j, n≧2.

15. A device for verifying a linkable ring signature in a blockchain, comprising: An acquisition unit acquires a key image I contained in a linkable ring signature of a transaction M, wherein the key image I is generated by the signer according to the private key x_j held by the signer and the signer array (P_j, ID_j), wherein the signer array (P_j, ID_j) contains the signer's public key P_j=x_j×G and a unique identifier ID_j of the asset to be spent related to the transaction M, wherein G is a base point of the elliptic curve, |G|=p and p is a prime number, 0 <x_j<p; A verification unit, verifying the key image I according to the saved historical key image, so as to determine the validity of the linkable ring signature; The linkable ring signature is generated by the signer according to the private key x_j and the array set [(P_1, ID_1), ..., (P_n, ID_n)]; the shielding party array (P_i, ID_i) corresponding to the signer array (P_j, ID_j) contains the shielding party i's public key P_i and the unique identifier ID_i of the asset held by the shielding party i, i, j∈[1,n], i, j and n are positive integers, i≠j, n≧2.

16. An electronic device, comprising: processor; a memory for storing processor-executable instructions; The processor implements the method according to any one of claims 1 to 13 by running the executable instructions.

17. A computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of the method according to any one of claims 1 to 13.

Images