Anonymous transaction method and device based on ring signature

Abstract

One or more embodiments of the present specification provide an anonymous transaction method and device based on a ring signature, which may include: assembling a remittance transaction based on the assets to be spent in the corresponding account of the remitter and the shielded assets in the corresponding account of the shielding party; wherein the assets to be spent and the shielded assets are respectively recorded in the blockchain account book as asset commitments corresponding to the corresponding asset amounts; generating a linkable ring signature for the remittance transaction based on the private key and public key held by the remitter and the public key held by the shielding party, wherein the linkable ring signature includes a key image, and the value of the key image is related to the private key, public key and asset identifier of the remitter; submitting the signed remittance transaction to the blockchain network; wherein, after the transaction is completed, the key image is added to the historical key image set, and the assets to be spent are maintained and recorded as assets held by the remitter on the blockchain account book.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to an anonymous transaction method and device based on ring signature. 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. Summary of the invention

[0003] In view of this, one or more embodiments of the present specification provide an anonymous transaction method and device based on a ring signature.

[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 ring signature-based anonymous transaction method is proposed, including:

[0006] According to the to-be-spent assets ID_j_1~ID_j_m in the corresponding account of the remitter and the protected assets ID_i_1~ID_i_m in the corresponding account of the protector i, a remittance transaction M is assembled; wherein the to-be-spent assets ID_j_1~ID_j_m and the protected assets ID_i_1~ID_i_m are respectively recorded as asset commitments corresponding to the corresponding asset amounts in the blockchain ledger;

[0007] Generate a linkable ring signature for the remittance transaction M based on the private key x_j, public key P_j held by the remitter and the public key P_i held by the shielding party i, wherein the linkable ring signature contains key images I_1~I_m, and the values ​​of the key images I_1~I_m are related to the private key x_j, public key P_j and asset identifiers ID_j_1~ID_j_m of the remitter;

[0008] Submit the signed remittance transaction M to the blockchain network; wherein, after the transaction is completed, the key images I_1~I_m are added to the historical key image set, and the assets to be spent ID_j_1~ID_j_m are maintained and recorded as assets held by the remitter on the blockchain ledger.

[0009] According to a second aspect of one or more embodiments of this specification, a ring signature-based anonymous transaction method is proposed, including:

[0010] Receive remittance transaction M, which is generated by the remitter based on the to-be-spent assets ID_j_1~ID_j_m in its corresponding account and the shielded assets ID_i_1~ID_i_m in the corresponding account of shielding party i; after the transaction is completed, the assets ID_j_1~ID_j_m are recorded as assets held by the remitter in the blockchain ledger;

[0011] Obtain the key images I_1~I_m contained in the linkable ring signature of the remittance transaction M, where the values ​​of the key images I_1~I_m are related to the private key x_j, public key P_j and asset identifiers ID_j_1~ID_j_m of the remitter;

[0012] Verify the linkable ring signature, which is generated by the remitter based on its own private key x_j, public key P_j and public key P_i held by shielding party i;

[0013] When the transaction execution conditions are met, the remittance transaction M is executed; the transaction execution conditions include: the key images I_1~I_m do not belong to the historical key image set and the linkable ring signature passes the verification; wherein the key images I_1~I_m are added to the historical key image set after the transaction is completed.

[0014] According to a third aspect of one or more embodiments of this specification, an anonymous transaction device based on a ring signature is proposed, comprising:

[0015] The transaction assembly unit assembles the remittance transaction M according to the to-be-spent assets ID_j_1~ID_j_m in the corresponding account of the remitter and the protected assets ID_i_1~ID_i_m in the corresponding account of the protector i; wherein the to-be-spent assets ID_j_1~ID_j_m and the protected assets ID_i_1~ID_i_m are respectively recorded in the blockchain account book as asset commitments corresponding to the corresponding asset amounts, i∈[1,j-1]∪[j+1,n];

[0016] The signature generation unit generates a linkable ring signature for the remittance transaction M according to the private key x_j and public key P_j held by the remitter and the public key P_i held by the shielding party i, wherein the linkable ring signature includes key images I_1 to I_m, and the values ​​of the key images I_1 to I_m are related to the private key x_j, public key P_j and asset identifiers ID_j_1 to ID_j_m of the remitter;

[0017] The transaction submission unit submits the signed remittance transaction M to the blockchain network; wherein, after the transaction is completed, the key images I_1~I_m are added to the historical key image set, and the assets to be spent ID_j_1~ID_j_m are maintained and recorded on the blockchain account book as assets held by the remitter.

[0018] According to a fourth aspect of one or more embodiments of this specification, an anonymous transaction device based on a ring signature is proposed, comprising:

[0019] The transaction receiving unit receives the remittance transaction M, which is generated by the remitter according to the to-be-spent assets ID_j_1~ID_j_m in its corresponding account and the shielded assets ID_i_1~ID_i_m in the corresponding account of the shielding party i, i∈[1,j-1]∪[j+1,n]; after the transaction is completed, the assets ID_j_1~ID_j_m are recorded as the assets held by the remitter in the blockchain account book;

[0020] An image acquisition unit, which acquires key images I_1 to I_m contained in the linkable ring signature of the remittance transaction M, wherein the values ​​of the key images I_1 to I_m are related to the private key x_j, the public key P_j and the asset identifiers ID_j_1 to ID_j_m of the remitter;

[0021] A signature verification unit, which verifies the linkable ring signature, where the linkable ring signature is generated by the remitter according to its own private key x_j, public key P_j and public key P_i held by shielding party i;

[0022] The transaction execution unit executes the remittance transaction M when a transaction execution condition is met; the transaction execution condition includes: the key images I_1~I_m do not belong to the historical key image set and the linkable ring signature passes the verification; wherein the key images I_1~I_m are added to the historical key image set after the transaction is completed.

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

[0024] processor;

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

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

[0027] 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 are implemented.

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

[0029] processor;

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

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

[0032] According to an eighth 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 second aspect are implemented. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0035] Figure 3 The present invention is a flowchart of an anonymous transaction method based on a ring signature provided by an exemplary embodiment.

[0036] Figure 4 It is a schematic diagram of an asset account model provided by an exemplary embodiment.

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

[0038] Figure 6 It is a flowchart of another anonymous transaction method based on ring signature provided by an exemplary embodiment.

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

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

[0041] Fig. 9 It is a block diagram of an anonymous transaction device based on ring signature provided by an exemplary embodiment.

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

[0043] Fig.11 It is a block diagram of another anonymous transaction device based on ring signature provided by an exemplary embodiment. DETAILED DESCRIPTION

[0044] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. 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 merely examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] 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 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.

[0052] 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.

[0053] 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.

[0054] 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 1 In 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.

[0055] 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.

[0056] It should be pointed out that the transaction described in this specification refers to a piece of data created by the user through the client of the blockchain and ultimately published to the distributed database of the blockchain. Among them, transactions in the blockchain are 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. A transaction in a broad sense refers to a business data with business intent published by a user to the blockchain; for example, the operator can build a consortium chain based on actual business needs, and rely on the consortium chain to deploy some other types of online services 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.

[0057] 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. 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.

[0058] Through the distributed architecture adopted by the blockchain network and the chain structure adopted by the blocks, information can be permanently and tamper-proof recorded in the blockchain ledger maintained uniformly by each blockchain node. However, since the blockchain ledger is completely public, the privacy of information cannot be guaranteed. For example, any user can query the blockchain ledger on any blockchain node to obtain information such as the assets held by a certain account and the transfer amount of a certain transaction, which may be sensitive information that needs to be hidden.

[0059] For the purpose of privacy protection, the related technology proposes a commitment-based anonymous transaction or confidential transaction scheme, which can generate the corresponding commitment amount for the amount of assets held by each account and the amount of transfer involved in the transaction, and the blockchain account book only records the commitment amount, rather than directly recording the plain text amount of assets, transaction amount, etc. For example, when the Pedersen commitment mechanism is adopted, assuming that the original amount is t, the corresponding commitment amount can be PC(t,r)=r×G+t×H, where G and H are random generators on the elliptic curve, r is a random number, and the value of r is only controlled by the account holder, transaction participant, etc., so that irrelevant personnel will not be able to reverse the original amount t based on the value of PC(t,r). At the same time, the commitment amount also has the homomorphic property, so that the commitment amounts can directly participate in the calculation, such as PC(t1,r1)-PC(t2,r2)=PC(t1-t2,r1-r2). However, when verifying a transaction, the blockchain node cannot determine whether the relevant conditions are met based on the promised amount, such as whether the incoming amount of the transaction is equal to the outgoing amount or other conditions. Relevant proof information is required to ensure that the transaction is completed smoothly.

[0060] In addition, users need to sign when initiating transactions in the blockchain network. 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 through the public key P_j corresponding to the private key x_j held by user A. However, direct verification of the signature also exposes user A as the signatory of the corresponding signature, thereby leaking user A's privacy.

[0061] 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).

[0062] 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.

[0063] 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. When the ring signature scheme is applied to the 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.

[0064] 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.

[0065] For example, when an asset held by a signing party (such as the remitter in a remittance transaction) corresponds to a private key x_j and a public key P_j, the corresponding key-image can be generated according to the formula I=x_j×Hash(P_j). Then, as long as the asset has been spent before, the blockchain node will record a key-image with the same value, thereby identifying the "double spending" problem.

[0066] However, since each asset has a unique corresponding public-private key pair, when a transaction contains multiple assets, multiple sets of public-private key pairs are required. For example, when a transaction contains m assets, the signer needs to maintain m sets of public-private key pairs, which greatly increases the maintenance cost of the public-private key pairs.

[0067] To this end, this specification proposes a new technical solution, so that the signer only needs to maintain a set of public and private key pairs to generate a linkable ring signature for transactions involving multiple assets, and can meet the needs of confidential transactions for proof information, which will be described in conjunction with the embodiments below.

[0068] Figure 3 The present invention is a flowchart of an anonymous transaction method based on a ring signature provided by an exemplary embodiment.

[0069] like Figure 3 As shown, the method is applied to a client device and may include the following steps:

[0070] Step 302, assembling a remittance transaction M according to the to-be-spent assets ID_j_1~ID_j_m in the corresponding account of the remitter and the protected assets ID_i_1~ID_i_m in the corresponding account of the protector i; wherein the to-be-spent assets ID_j_1~ID_j_m and the protected assets ID_i_1~ID_i_m are respectively recorded in the blockchain ledger as asset commitments corresponding to the corresponding asset amounts.

[0071] As mentioned above, for the purpose of keeping the assets held confidential, the assets held by the remitter and any other user are recorded on the blockchain ledger as the corresponding commitment amount, rather than directly recording the asset amount in plain text. Taking the assets to be spent ID_j_1~ID_j_m as an example, ID_j_1~ID_j_m are asset identifiers used to distinguish different assets; assuming that the asset amount of the assets to be spent ID_j_1~ID_j_m is t_j_1~t_j_m, then the blockchain ledger can record the asset commitment PC(t_j_1,r_j_1)~PC(t_j_m,r_j_m) corresponding to the asset amount t_j_1~t_j_m, and r_j_1~r_j_m are random numbers. Due to the existence of random numbers r_j_1~r_j_m, the asset commitment PC(t_j_1,r_j_1)~PC(t_j_m,r_j_m) generated by amounts t_j_1~t_j_m are random. Except for the remitter who knows the random numbers r_j_1~r_j_m, other users can only see the asset commitment PC(t_j_1,r_j_1)~PC(t_j_m,r_j_m), and cannot infer the corresponding asset amounts t_j_1~t_j_m based on them.

[0072] Similarly, for the shielding assets ID_i_1~ID_i_m, ID_i_1~ID_i_m are asset identifiers used to distinguish different assets; assuming that the asset amount of the shielding assets ID_i_1~ID_i_m is t_i_1~t_i_m, then the blockchain ledger can record the asset commitment PC(t_i_1,r_i_1)~PC(t_i_m,r_i_m) corresponding to the asset amount t_i_1~t_i_m, where r_i_1~r_i_m are random numbers. For example, if shielding party 1 holds shielding assets ID_1_1~ID_1_m and the corresponding asset amounts are t_1_1~t_1_m, then the blockchain ledger can record the asset commitments PC(t_1_1,r_1_1)~PC(t_1_m,r_1_m) corresponding to the asset amounts t_1_1~t_1_m, where r_1_1~r_1_m are random numbers held only by shielding party 1.

[0073] For example, the blockchain ledger can record and store assets in a form similar to [identification, asset commitment]. For example, the above-mentioned to-be-spent assets ID_j_1~ID_j_m can be recorded as [ID_j_1, PC(t_j_1, r_j_1)]~[ID_j_m, PC(t_j_m, r_j_m)], and the shielded assets ID_i_1~ID_i_m corresponding to the shielding party i can be recorded as [ID_i_1, PC{i,1}]~[ID_i_m, PC{i,m}]. Of course, this is only an example, and the blockchain ledger can actually use other forms. For example, when there are multiple asset types, assets can be recorded and stored in a form similar to [type, identification, asset commitment]. In the process of calculating asset amounts and executing transactions, the impact of asset types needs to be considered, such as the proportional conversion of asset amounts between different types of assets. Furthermore, in addition to directly recording "asset commitment", other information can also be stored at the same time; taking the asset ID_j_m to be spent as an example, it can be recorded as [ID_j_m, E(t_j_m, r_j_m)], where E(t_j_m, r_j_m) = [PC(t_j_m, r_j_m), E(t_j_m), E(r_j_m)], E(t_j_m) and E(r_j_m) are the homomorphic ciphertexts corresponding to the asset amount t_j_m and the random number r_j_m, respectively, which can be obtained by encrypting the asset amount t_j_m and the random number r_j_m by the homomorphic encryption public key of the remitter (obtained by homomorphic encryption of the public key P_j). For ease of understanding, the following examples are given in the form of [identification, asset commitment].

[0074] As mentioned above, this specification uses the "account" form to manage the assets held by users. For example, the account model used in the UTXO model and related technologies such as Ethereum can be used to implement an asset management model based on the "account" form, namely the asset account model. The asset account model can generate corresponding accounts for each user and manage the assets held by the user based on the account. For example Figure 4 is a schematic diagram of an asset account model provided by an exemplary embodiment. Figure 4 The figure shows the account A_j corresponding to the remitter. Unlike the above account model, the account A_j does not directly record the account balance of the remitter, but records the assets held by the remitter, such as assets [ID_j_1, PC(t_j_1, r_j_1)], [ID_j_2, PC(t_j_2, r_j_2)], etc. These assets can be clearly distinguished by one-to-one corresponding asset identifiers. Each account has a unique corresponding account address (Account ID), which can be used to distinguish different accounts. At the same time, the information of all accounts is recorded in the blockchain ledger, so that by querying the blockchain ledger, the assets contained in each account can be known; of course, since the asset amount is recorded as the corresponding commitment amount in the blockchain ledger, it will not expose the user's asset holdings, and can protect user privacy.

[0075] There may be multiple types of assets maintained in the asset account model. For example, similar to the UTXO model, the assets in the asset account model may be the transaction outputs of the corresponding historical transactions, such as the to-be-spent assets ID_j_1~ID_j_m are the transaction outputs formed by the historical transactions previously participated in by the remitter, and the remitter is in the role of the "receiver" in these transactions. For another example, the shielded assets ID_i_1~ID_i_m are the transaction outputs formed by the historical transactions previously participated in by the shielding party i, and the shielding party i is in the role of the "receiver" in these transactions. For another example, similar to the account model, the asset account model may have a corresponding account balance, and actively divide at least a part of the account balance to form an asset with a certain asset amount, such as the to-be-spent assets ID_j_1~ID_j_m are generated by dividing the account balance corresponding to the remitter, and the shielded assets ID_i_1~ID_i_m are generated by dividing the account balance corresponding to the shielding party i. In the case where assets are generated by dividing account balances, all asset balances can be divided into corresponding assets for management, or part of the account balances can be divided into assets and the remaining account balances can still be maintained in the form of values ​​( Figure 4 This value is not shown).

[0076] Among all the assets in the corresponding account of the remitter, the assets to be spent ID_j_1~ID_j_m can be any assets held by the remitter. Of course, when actually selecting the assets to be spent, it is also necessary to refer to the remittance amount involved in the remittance transaction M, and ensure that the sum of the asset amounts of the assets to be spent is not less than the remittance amount. The remittance amount is the amount that the remitter needs to transfer to each actual recipient. These amounts are determined by the remitter and each actual recipient in advance, or they can be determined by the remitter itself.

[0077] From the perspective of the input of the remittance transaction M, the roles of the remitter and the cover party are involved, while from the perspective of the output of the remittance, the roles of the actual recipient and the transaction recipient are involved. Among these roles, some may overlap to a certain extent.

[0078] For the remitter and the shielding party, the remittance transaction M is assembled according to the to-be-spent assets ID_j_1~ID_j_m in the corresponding account of the remitter and the shielding assets ID_i_1~ID_i_m in the corresponding account of shielding party i, and the linkable ring signature generated below is added, so that shielding party i can hide the identity of the remitter, so that other users cannot determine which user in "remitter and shielding party i" has spent the assets. Here, the shielding party may include any user other than the remitter, for example, the shielding party may include the actual payee of the remittance transaction M. For example, when the remitter is user A and the actual payee is user B and user C, by configuring user B and user C as shielding parties, not only can user B and user C hide the identity of user A, but also because user B and user C belong to both "transaction remitter" and "transaction payee", it brings a stronger confusing effect. For another example, the shielding party may include other users different from the remitter and the actual payee. For example, when the remitter is user A and the actual payee is user B and user C, the irrelevant user D may be configured as the shielding party to hide the identity of user A. For another example, the shielding party may include both the actual payee and other users. For example, when the remitter is user A and the actual payee is user B and user C, user B, user C and user D may be configured as the shielding party to hide the identity of user A.

[0079] For the actual payee and the transaction payee: In one embodiment, the transaction payee can be the actual payee. At this time, the sum of the asset amounts t_j_1~t_j_m corresponding to the assets ID_j_1~ID_j_m to be spent is exactly equal to the sum of the transfer amounts corresponding to each actual payee, that is, there is no change. In another embodiment, in addition to the actual payee, the transaction payee may also include the remitter. In this case, there may be two situations: in one case, the remitter is not deliberately set as the transaction payee, but because the sum of the asset amounts t_j_1~t_j_m corresponding to the assets ID_j_1~ID_j_m to be spent is greater than the sum of the transfer amounts corresponding to each actual payee, there is change that needs to be returned to the remitter, and the change amount (that is, the transfer amount corresponding to the remitter) is the difference between the sum of the asset amounts t_j_1~t_j_m and the sum of the transfer amounts; in another case, although there is no change, the remitter can still be set as the transaction payee, so that the remitter can play a certain cover role for the actual payee, and at this time the transfer amount corresponding to the remitter can be set to 0 to avoid affecting the original transfer operation. In another embodiment, the transaction payee may include a shielding party that is different from the actual payee and the remitter, and the shielding party hides the identity of the actual payee, and the transfer amount corresponding to the shielding party is 0; of course, in addition to the shielding party, the transaction payee may also include the remitter: when there is no change, the transfer amounts corresponding to the remitter and the shielding party are both 0; when there is change, the transfer amount corresponding to the remitter is the change amount, and the transfer amount corresponding to the shielding party is 0.

[0080] According to the actual situation, the identity of the remitter can be hidden only by the cover party, or the identity of the actual payee can be further hidden. In one embodiment, the participants of the remittance transaction M can include the remitter, the actual payee and the cover party different from the two at the same time. These users form a total of n participants, and the n participants all participate in the remittance and collection of the remittance transaction at the same time, thereby hiding the identities of the remitter and the actual payee at the same time. Moreover, since each participant participates in the remittance and collection at the same time, the identity confusion between the remitter and the actual payee can be achieved, thereby further increasing the reliability of identity hiding.

[0081] Assume that the recipients of the remittance transaction M are Q_1~Q_u, and the corresponding transfer amounts are t'_1~t'_u, where 1≤u≤n. In the remittance transaction M, similar to the asset amounts t_j_1~t_j_m corresponding to the aforementioned assets to be spent, the transfer amounts t'_1~t'_u are recorded in the remittance transaction M as corresponding transfer amount commitments PC(t'_1,r'_1)~PC(t'_u,r'_u), where r'_1~r'_u are random numbers. Among them, the random numbers r'_1~r'_u can be determined by the remitter and notified to the corresponding payee through an off-chain channel (usually only the actual payee needs to be informed), so that each payee can verify based on the random numbers r'_1~r'_u. For example, the payee w can verify whether PC(t'_w,r'_w)=t'_w×G+r'_w×H holds, and manage the assets corresponding to the transfer amount commitment PC(t'_w,r'_w) after the transaction is completed.

[0082] In a confidential transaction, it is necessary to prove that the transfer amounts t'_1~t'_u in the remittance transaction M are not less than 0. The remitter can use the zero-knowledge proof technology in the relevant technology to generate corresponding range proofs RP_1~RP_u for the transfer amounts t'_1~t'_u, respectively, to prove t'_1≥0~t'_u≥0, and add these range proofs RP_1~RP_u to the transaction content of the remittance transaction M. Among them, the zero-knowledge proof technology used can be a range proof technology, such as the Bulletproofs scheme, etc., and this specification does not limit this.

[0083] Step 304: Generate a linkable ring signature for the remittance transaction M based on the private key x_j and public key P_j held by the remitter and the public key P_i held by the shielding party i. The linkable ring signature includes key images I_1~I_m, and the values ​​of the key images I_1~I_m are related to the private key x_j, public key P_j and asset identifiers ID_j_1~ID_j_m of the remitter.

[0084] The remitter needs to maintain a set of public-private key pairs, such as private key x_j and public key P_j. Before determining this set of public-private key pairs, it is necessary to determine a number field Z_q and an elliptic curve on the number field, such as the elliptic curve Ed25519, and let G and H be two random generators of the elliptic curve, where |G|=p is a large prime number (for example, not less than a preset value), and select the remitter's private key x_j in the value range (0,p), and the corresponding public key is P_j=x_j×G. For other users such as the shielding party, their unique corresponding public-private key pairs are determined in a similar way.

[0085] The key images I_1~I_m correspond to the assets ID_j_1~ID_j_m to be spent provided by the remitter, and are used to verify whether the corresponding assets to be spent have been spent, thereby solving the "double spending" problem. Among them, since the values ​​of the key images I_1~I_m are related to the asset identifiers ID_j_1~ID_j_m of the corresponding assets, even if all key images use the same set of public and private key pairs (i.e., the private key x_j and public key P_j of the remitter), it is possible to ensure that the generated key images I_1~I_m are completely different based on the value differences between the asset identifiers ID_j_1~ID_j_m. Therefore, there is no need to maintain a set of public and private key pairs for each asset. While solving the "double spending" problem, the number of public and private key pairs required to be maintained for each account is independent of the number of assets contained in the transaction. For example, I_d=x_j×Hash_G(P_j,ID_j_d), d∈[1,m]; wherein Hash_G() is the hash function of the above elliptic curve to itself.

[0086] According to the asset commitment PC(t_j_1,r_j_1)~PC(t_j_m,r_j_m) corresponding to the asset to be spent, and the aforementioned transfer amount commitment PC(t'_1,r'_1)~PC(t'_u,r'_u), it can be calculated that P"_j=[PC(t_j_1,r_j_1)+…+PC(t_j_m,r_j_m)]-[PC(t'_1,r'_1)+…+PC(t'_u,r'_u)]; and, according to the random numbers r_j_1~r_ j_m, and the random numbers r'_1~r'_u corresponding to the transfer amount, we can calculate r"=(r_j_1+...+r_j_m)-(r'_1+...+r'_u); and, according to the asset amount t_j_1~t_j_m corresponding to the asset to be spent and the transfer amount t'_1~t'_u, we can calculate t"=(t_j_1+…+t_j_m)-(t'_1+…+t'_u). Then, as mentioned above, it can be determined that P"_j=PC(r",t")=r"×G+t"×H. And because the remitter needs to ensure that t_j_1+…+t_j_m=t'_1+…+t'_u, so that t"=0, it can be determined that P"_j=r"×G.

[0087] Then, it can be seen from the form that the above "P"_j=r"×G" is similar to the relationship between the public-private key pair "P_j=x_j×G", and as described below, the shielding party i must satisfy P"_i≠r"×G, so r" can be regarded as a private key corresponding to the remitter, and P"_j is the public key corresponding to r". In order to distinguish it from the public-private key pair corresponding to the remitter, r" can be regarded as the pseudo-private key corresponding to the remitter, and P"_j can be regarded as the pseudo-public key corresponding to the remitter. Similarly, P"_i can be regarded as the pseudo-public key corresponding to shielding party i; for example, it can be calculated that shielding party i The corresponding parameter P”_i=[PC{i,1}+…+PC{i,m}]-[PC(t'_1,r'_1)+…+PC(t'_u,r'_u)], i∈[1,j-1]∪[j+1,n]. At the same time, the difference t”_i between the sum of the asset amounts corresponding to the m assets held by the shielding party i and the sum of the transfer amounts t'_1~t'_u can be calculated, and the difference r”_i between the sum of the random numbers corresponding to the m assets held by the shielding party i and the sum of the random numbers r'_1~r'_u corresponding to the transfer amounts t'_1~t'_u can be calculated.

[0088] Based on the homomorphic property, it can be determined that P”_i=r”_i×G+t”_i×H≠r”×G. It can be seen that the parameters P”_j and r” are uniquely corresponding to the remitter, and the parameter P”_i is uniquely corresponding to the shielding party i. Therefore, r” can be regarded as the pseudo private key corresponding to the remitter, P”_j can be regarded as the pseudo public key corresponding to the remitter, and P”_i can be regarded as the pseudo public key corresponding to the shielding party i.

[0089] According to the private key x_j, public key P_j, pseudo private key r”, pseudo public key P”_j corresponding to the remitter, and the public key P_i and pseudo public key P”_i corresponding to the shielding party i, a linkable ring signature is generated for the remittance transaction M, which can efficiently and compactly realize the following two verification functions: On the one hand, since the pseudo public key P”_j and the pseudo private key r” satisfy P”_j=r”×G, and the pseudo public key P”_i and the pseudo private key r” satisfy P”_i≠r”×G, when a linkable ring signature is generated according to the pseudo private key r”, the pseudo public key P”_j and P”_i, if the linkable ring signature passes the verification, it can be proved There is a pseudo public key in the pseudo public key (P”_1, …, P”_n) whose value is equal to r”×G, and this pseudo public key corresponds to the aforementioned t”=0, which can make the input and output of the remittance transaction M equal; on the other hand, when a linkable ring signature is generated according to the private key x_j corresponding to the remitter, the public key P_j and the public key P_i corresponding to the shielding party i, if the linkable ring signature passes the verification, it can be proved that the linkable ring signature is signed by the private key corresponding to a public key in the public key (P_1, …, P_n), thereby completing the identity authentication without exposing the identity of the remitter. Of course, without considering whether the input and output of the remittance transaction M are equal, the linkable ring signature can also be directly generated according to the private key x_j corresponding to the remitter, the public key P_j and the public key P_i corresponding to the shielding party i, without using the pseudo private key r” corresponding to the remitter, the pseudo public key P”_j and the pseudo public key P”_i corresponding to the shielding party i, and this specification does not limit this.

[0090] In addition to the key images I_1~I_m mentioned above, the remitter can also generate a key image I_(m+1)=r”×Hash_G(P”_j) based on the pseudo private key r” and the pseudo public key P”_j, thereby forming a total of m+1 key images with the key images I_1~I_m, which are used together to solve the "double spending" problem. In fact, since the values ​​of the pseudo private key r” and the pseudo public key P”_j are both random, the pseudo private key r” and the pseudo public key P”_j generated by different transactions must be different. Therefore, when the key image I_(m+1) is generated based on the pseudo private key r” and the pseudo public key P”_j, a one-to-one correspondence can be formed between the key image I_(m+1) and the corresponding transaction. Therefore, by comparing the key image I_(m+1) with the historical key image, the replay problem for the remittance transaction M can be identified: if the key image I_(m+1) has the same historical key image, it means that the remittance transaction M has been replayed.

[0091] Step 306, submitting the signed remittance transaction M to the blockchain network; wherein, after the transaction is completed, the key images I_1~I_m are added to the historical key image set, and the assets to be spent ID_j_1~ID_j_m are maintained and recorded on the blockchain ledger as assets held by the remitter.

[0092] After receiving the remittance transaction M, the blockchain node can compare the key images I_1~I_m with the historical key image set to determine whether there is a historical key image in the historical key image set that is the same as the key images I_1~I_m. The historical key image set is used to store key images corresponding to previously spent assets. If there is a historical key image that is the same as a key image in key images I_1~I_m, it means that the asset corresponding to the key image has been spent, that is, a "double spend" problem has occurred, and the execution of the remittance transaction M should be prevented. If key images I_1~I_m do not belong to the historical key image set, it means that the assets ID_j_1~ID_j_m corresponding to key images I_1~I_m have not been spent. If other transaction execution conditions are met, the remittance transaction M can be executed; and when the remittance transaction M is completed, the assets ID_j_1~ID_j_m corresponding to key images I_1~I_m have been spent, so it is necessary to add key images I_1~I_m to the historical key image set for subsequent detection of the "double spending" problem related to key images I_1~I_m.

[0093] In an account model such as that adopted by Ethereum, when the remitter spends a sum of money through a transaction, the account balance in the corresponding account is updated immediately, that is, the amount of money spent is deducted, thereby ensuring the accuracy of the account balance. However, in the technical solution of this specification, after the remittance transaction M is completed, although the assets ID_j_1~ID_j_m in the corresponding account of the remitter are spent, the corresponding account of the remitter is not updated immediately, that is, there is no need to immediately delete the assets ID_j_1~ID_j_m in the corresponding account of the remitter, so that when any user queries the corresponding account of the remitter through the blockchain account book, the asset change will not be noticed after the remittance transaction M is completed, avoiding the exposure of the real identity of the remitter in the remittance transaction M based on the asset change. At the same time, although the corresponding account of the remitter contains both spent and unspent assets, based on the maintenance of the above-mentioned historical key mirror set, it can be ensured that the remitter can actually only spend the unspent assets, and accurately detect the "double flower" operation implemented by the remitter on the spent assets.

[0094] Of course, in order to avoid excessive accumulation of assets in the account and increase the maintenance cost of the blockchain node, and to facilitate each user to manage the assets in their own account, the user can clean up the spent assets in their own account. Taking the above-mentioned remitter as an example, the remitter can initiate an asset deletion request to the blockchain network to delete at least a part of the assets that the remitter has spent from the blockchain account book; for example, the remitter can specify the asset identifier corresponding to the asset to be deleted, or the remitter can specify a time period (the two end points of the time period can be specified; if only the left end point is specified, the time period is from the corresponding time of the left end point to the present; if only the right end point is specified, the time period is from the account creation to the corresponding time of the right end point) and delete all assets generated or spent in the time period.

[0095] Based on the above description, it can be seen that the remittance transaction M generated by the remitter may include the following transaction contents:

[0096] 1) The remitter, the protector i and their assets: {[P_1:ID_1_1,…,ID_1_m], [P_2:ID_2_1,…,ID_2_m],…, [P_n:ID_n_1,…,ID_n_m]}, where P_1~P_n are the public keys of the remitter and the protector respectively, such as the public key P_j corresponding to the remitter and the public key P_i corresponding to the protector i, i∈[1,j-1]∪[j+1,n].

[0097] 2) Transaction recipients and their transfer amounts: {[Q_1,PC(t'_1,r'_1)],[Q_2,PC(t'_2,r'_2)],…,[Q_u,PC(t'_u,r'_u)]}.

[0098] 3) Range proof RP_1~RP_u.

[0099] Of course, the remittance transaction M may also include other transaction contents required in the blockchain network. Please refer to the relevant requirements in the relevant technologies, which will not be listed here one by one.

[0100] Then, the remitter can perform hash calculation on the transaction content of the remittance transaction M, and the parameter M can represent the calculated hash value, and the remitter can generate a linkable ring signature for the hash value M. Of course, the remitter can also directly generate a linkable ring signature for the entire transaction content, which may bring a relatively larger amount of calculation.

[0101] Combine the following Figure 5 The process of generating a linkable ring signature for a remittance transaction M based on the private key x_j, public key P_j, pseudo private key r”, pseudo public key P”_j corresponding to the remitter, and the public key P_i and pseudo public key P”_i corresponding to the shielding party i is described; wherein, Figure 5FIG. 1 is a flowchart of generating a linkable ring signature provided by an exemplary embodiment. Figure 5 As shown, the following steps may be included:

[0102] Step 502: Generate key images I_1 to I_(m+1).

[0103] The process of generating key images I_1~I_(m+1) can refer to the above content and will not be repeated here.

[0104] Among them, I_d=x_j×Hash_G(P_j,ID_j_d), d∈[1,m]; I_(m+1)=r”×Hash_G(P”_j).

[0105] Step 504a, calculating the intermediate parameters L_j_d and R_j_d.

[0106] The remitter can select a random number a_d (i.e., a_1 to a_m) from the number field Z_q and calculate the intermediate parameters L_j_d and R_j_d according to the following formula:

[0107] L_j_d=a_d×G

[0108] R_j_d=a_d×Hash_G(P_j,ID_j_d)

[0109] Therefore, the remitter can calculate L_j_d: L_j_1~L_j_m, and R_j_d: R_j_1~R_j_m.

[0110] Furthermore, the remitter may generate intermediate parameters L_i_d and R_i_d corresponding to the shielding party i, including: generating intermediate parameters L_i_d and R_i_d respectively according to the values ​​of the intermediate parameters L_j_d and R_j_d, which will be described in the following steps 506 to 510.

[0111] Step 504b, calculate the intermediate parameters L_j_(m+1) and R_j_(m+1).

[0112] The remitter can select a random number a_(m+1) from the number field Z_q and calculate the intermediate parameters L_j_(m+1) and R_j_(m+1) according to the following formula:

[0113] L_j_(m+1)=a_(m+1)×G

[0114] R_j_(m+1)=a_(m+1)×Hash_G(P”_j)

[0115] Therefore, the remitter can calculate L_j_(m+1) and R_j_(m+1). Further, the remitter can generate intermediate parameters L_i_(m+1) and R_i_(m+1) corresponding to the shielding party i, which will be described in the following steps 506 to 510.

[0116] Step 506, calculate the intermediate parameters L_(j+1)_d~L_n_d, R_(j+1)_d~R_n_d, L_(j+1)_(m+1)~L_n_(m+1), and R_(j+1)_(m+1)~R_n_(m+1).

[0117] When i=j+1~n, the calculation process of the intermediate parameters L_i_d and R_i_d conforms to the following formula:

[0118] L_i_d=(s_i_d×G+c_i×P_i)mod p

[0119] R_i_d=[s_i_d×Hash_G(P_i,ID_i_d)+c_i×I_d]mod p

[0120] At the same time, the calculation process of the intermediate parameters L_i_(m+1) and R_i_(m+1) conforms to the following formula:

[0121] L_i_(m+1)=[s_i_(m+1)×G+c_i×P”_i]mod p

[0122] R_i_(m+1)=[s_i_(m+1)×Hash_G(P”_i)+c_i×I_(m+1)]mod p

[0123] In the calculation process, s_(j+1)_d~s_n_d, s_(j+1)_(m+1)~s_n_(m+1) 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)_1,R_(i-1)_1,……,L_(i-1)_(m+1),R_(i-1)_(m+1)], where Hash() is the hash function from the above elliptic curve to the data Z_q.

[0124] When L_j_d, R_j_d, L_j_(m+1), and R_j_(m+1) have been calculated in steps 504a-b, the intermediate parameters L_i_d and R_i_d when i∈[j+1,n] are calculated based on L_j_d and R_j_d, i.e., the above-mentioned L_(j+1)_d~L_n_d and R_(j+1)_d~R_n_d. Specifically, first, c_(j+1)=Hash[M,L_j_1,R_j_1,……,L_j_(m+1),R_j_(m+1)] is calculated according to the values ​​of L_j_d, R_j_d, L_j_(m+1), and R_j_(m+1), and L_(j+1)_d and R_(j+1)_d are calculated according to the random number s_(j+1)_d and the calculated c_(j+1), that is, L_(j+1)_1 and R_(j+1)_1 are calculated according to the random number s_(j+1)_1 and the calculated c_(j+1), and L_(j+1)_d and R_(j+1)_d are calculated according to the random number s_(j+1)_1 and the calculated c_(j+1). (j+1)_2 and the calculated c_(j+1) calculate L_(j+1)_2, R_(j+1)_2, …, calculate L_(j+1)_m and R_(j+1)_m according to the random number s_(j+1)_m and the calculated c_(j+1); then calculate c_(j+2) according to the values ​​of L_(j+1)_d and R_(j+1)_d, and calculate L_(j+2)_d and R_(j+2)_d according to the random number s_(j+2)_d and the calculated c_(j+2); and so on, until L_n_d and R_n_d are calculated.

[0125] Similarly, based on the random number s_i_(m+1), the pseudo public key P”_i, the calculated c_i and the key image I_(m+1), the intermediate parameters L_(j+1)_(m+1)~L_n_(m+1) and R_(j+1)_(m+1)~R_n_(m+1) can be calculated according to the above formulas respectively, which will not be repeated here.

[0126] Step 508, calculate the intermediate parameters L_1_d, R_1_d, L_1_(m+1), and R_1_(m+1).

[0127] The calculation process of the intermediate parameters L_1_d and R_1_d conforms to the following formula:

[0128] L_1_d=(s_1_d×G+c_1×P_1)mod p

[0129] R_1_d=(s_1_d×Hash_G(P_1,ID_1_d)+c_1×I_d)mod p

[0130] The calculation process of the intermediate parameters L_1_(m+1) and R_1_(m+1) conforms to the following formula:

[0131] L_1_(m+1)=[s_1_(m+1)×G+c_1×P”_1]mod p

[0132] R_1_(m+1)=[s_1_(m+1)×Hash_G(P_1)+c_1×I_(m+1)]mod p

[0133] Among them, s_1_d and s_1_(m+1) are both random numbers in the number field Z_q, and c_1 = Hash[M, L_n_1, R_n_1,…, L_n_(m+1), R_n_(m+1)]. Since the intermediate parameters conform to the circular value rule, although the intermediate parameters are expressed as L_1_d~L_n_d, R_1_d~R_n_d, L_1_(m+1)~L_n_(m+1), R_1_(m+1)~R_n_(m+1) for the convenience of description, L_1_d, R_1_d, L_1_(m+1), R_1_(m+1) are not arranged in the first place, and L_n_d, R_n_d, L_n_(m+1), R_n_(m+1) are not arranged in the last place. In fact, it should be considered that L_1_d and L_n_d are adjacent, R_1_d and R_n_d are adjacent, L_1_(m+1) and L_n_(m+1) are adjacent, and R_1_(m+1) and R_n_(m+1) are adjacent. Therefore, when c_1=Hash[M,L_n_1,R_n_1,……,L_n_(m+1),R_n_(m+1)], it actually conforms to the c_i=Hash[M,L_(i-1)_1,R_(i-1)_1,……,L_(i-1)_(m+1),R_(i-1)_(m+1)] described in the above step 506, that is, the calculation formulas of c_1 and c_(j+1)~c_n are consistent.

[0134] Step 510, calculate the intermediate parameters L_2_d~L_(j-1)_d, R_2_d~R_(j-1)_d, L_2_(m+1)~L_(j-1)_(m+1), and R_2_(m+1)~R_(j-1)_(m+1).

[0135] When i=2~j-1, the calculation process of the intermediate parameters L_i_d and R_i_d conforms to the following formula:

[0136] L_i_d=(s_i_d×G+c_i×P_i)mod p

[0137] R_i_d=(s_i_d×Hash_G(P_i,ID_i_d)+c_i×I_d)mod p

[0138] At the same time, the calculation process of the intermediate parameters L_i_(m+1) and R_i_(m+1) conforms to the following formula:

[0139] L_i_(m+1)=[s_i_(m+1)×G+c_i×P”_i]mod p

[0140] R_i_(m+1)=[s_i_(m+1)×Hash_G(P”_i)+c_i×I_(m+1)]mod p

[0141] In the calculation process, s_2_d~s_(j-1)_d, s_2_(m+1)~s_(j-1)_(m+1) are involved, all of which are 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)_1,R_(i-1)_1,……,L_(i-1)_(m+1),R_(i-1)_(m+1)).

[0142] Therefore, when L_1_d, R_1_d, L_1_(m+1), and R_1_(m+1) have been calculated in step 508, the intermediate parameters L_i_d and R_i_d when i∈[2,j-1], i.e., L_2_d~L_(j-1)_d and R_2_d~R_(j-1)_d mentioned above, can be calculated based on L_1_d, R_1_d, L_1_(m+1), and R_1_(m+1). Specifically, first, c_2 is calculated according to the values ​​of L_1_d, R_1_d, L_1_(m+1), and R_1_(m+1), and L_2_d and R_2_d are calculated according to the random number s_2_d and the calculated c_2, that is: L_2_1 and R_2_1 are calculated according to the random number s_2_1 and the calculated c_2, L_2_2 and R_2_2 are calculated according to the random number s_2_2 and the calculated c_2, ..., L_2_m and R_2_m are calculated according to the random number s_2_m and the calculated c_2; then c_3 is calculated according to the values ​​of L_2_d and R_2_d, and L_3_d and R_3_d are calculated according to the random number s_3_d and the calculated c_3; and so on, until L_(j-1)_d and R_(j-1)_d are calculated.

[0143] Similarly, based on the random number s_i_(m+1), the pseudo public key P”_i, the calculated c_i and the key image I_(m+1), the intermediate parameters L_2_(m+1)~L_(j-1)_(m+1) and R_2_(m+1)~R_(j-1)_(m+1) can be calculated according to the above formulas respectively, which will not be repeated here.

[0144] Step 512: Generate a ring signature.

[0145] Based on the processing of the above steps, we can obtain key images I_1, ..., I_(m+1), c_1, s_1_d ~ s_(j-1)_d, s_(j+1)_d ~ s_n_d, s_1_(m+1) ~ s_(j-1)_(m+1), s_(j+1)_(m+1) ~ s_n_(m+1), and s_j_d and s_j_(m+1) need to be calculated by the signatory according to the following formula:

[0146] s_j_d=(a_d-c_j×x_j)mod p

[0147] s_j_(m+1)=(a_(m+1)-c_j×r”)mod p

[0148]

[0149] 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 fixed to a value in [2,n]. This should be distinguished from the above parameters i and e (parameter i has n-1 values, 1 to j-1 and j+1 to n, and parameter e has m values, 1 to m). At the same time, similar to the description of c_1 above: Since the intermediate parameters conform to the circular value rule, although the intermediate parameters are expressed as L_1_d~L_n_d, R_1_d~R_n for the convenience of description _d, L_1_(m+1)~L_n_(m+1), R_1_(m+1)~R_n_(m+1), but L_1_d, R_1_d, L_1_(m+1), R_1_(m+1) are not arranged in the first place, and L_n_d, R_n_d, L_n_(m+1), R_n_(m+1) are not arranged in the last place. In fact, it should be considered that L_1_d and L_n_d are adjacent, R_1_d and R_n_d are adjacent, L_1_(m+1) and L_n_(m+1) are adjacent, and R_1_(m+1) and R_n_(m+1) are adjacent. Therefore, when c_1=Hash(M,L_n_1,R_n_1,……,L_n_(m+1),R_n_(m+1)), it actually also satisfies c_j=Hash(M,L_(j-1)_1,R_(j-1)_1,……,L_(j-1)_(m+1),R_(j-1)_(m+1)).

[0150] Therefore, the remitter can generate a ring signature [I_1,…,I_(m+1),c_1,s_1_1,…,s_1_(m+1),…,s_n_1,…,s_n_(m+1)], which contains key images I_1~I_(m+1), random numbers s_i_1~s_i_(m+1), derived values ​​s_j_1~s_j_(m+1) and c_1.

[0151] Figure 6 FIG. 1 is a flowchart of another anonymous transaction method based on ring signature provided by an exemplary embodiment. Figure 6 As shown, this method is applied to blockchain nodes, which Figure 3 Verifying the linkable ring signature generated in the illustrated embodiment and performing other necessary verification operations on the remittance transaction M may include the following steps:

[0152] Step 602, receiving a remittance transaction M, wherein the remittance transaction M is generated by the remitter according to the to-be-spent assets ID_j_1~ID_j_m in its corresponding account and the shielded assets ID_i_1~ID_i_m in the corresponding account of shielding party i; after the transaction is completed, the assets ID_j_1~ID_j_m are recorded in the blockchain ledger as the assets held by the remitter.

[0153] As mentioned above, for the purpose of keeping the assets held confidential, the assets held by the remitter and any other user are recorded on the blockchain ledger as the corresponding commitment amount, rather than directly recording the asset amount in plain text. Taking the assets to be spent ID_j_1~ID_j_m as an example, ID_j_1~ID_j_m are asset identifiers used to distinguish different assets; assuming that the asset amount of the assets to be spent ID_j_1~ID_j_m is t_j_1~t_j_m, then the blockchain ledger can record the asset commitment PC(t_j_1,r_j_1)~PC(t_j_m,r_j_m) corresponding to the asset amount t_j_1~t_j_m, and r_j_1~r_j_m are random numbers. Due to the existence of random numbers r_j_1~r_j_m, the asset commitment PC(t_j_1,r_j_1)~PC(t_j_m,r_j_m) generated by amounts t_j_1~t_j_m are random. Except for the remitter who knows the random numbers r_j_1~r_j_m, other users can only see the asset commitment PC(t_j_1,r_j_1)~PC(t_j_m,r_j_m), and cannot infer the corresponding asset amounts t_j_1~t_j_m based on them.

[0154] Similarly, for the shielding assets ID_i_1~ID_i_m, ID_i_1~ID_i_m are asset identifiers used to distinguish different assets; assuming that the asset amount of the shielding assets ID_i_1~ID_i_m is t_i_1~t_i_m, then the blockchain ledger can record the asset commitment PC(t_i_1,r_i_1)~PC(t_i_m,r_i_m) corresponding to the asset amount t_i_1~t_i_m, where r_i_1~r_i_m are random numbers. For example, if shielding party 1 holds shielding assets ID_1_1~ID_1_m and the corresponding asset amounts are t_1_1~t_1_m, then the blockchain ledger can record the asset commitments PC(t_1_1,r_1_1)~PC(t_1_m,r_1_m) corresponding to the asset amounts t_1_1~t_1_m, where r_1_1~r_1_m are random numbers held only by shielding party 1.

[0155] For example, the blockchain ledger can record and store assets in a form similar to [identification, asset commitment]. For example, the above-mentioned to-be-spent assets ID_j_1~ID_j_m can be recorded as [ID_j_1, PC(t_j_1, r_j_1)]~[ID_j_m, PC(t_j_m, r_j_m)], and the shielded assets ID_i_1~ID_i_m corresponding to the shielding party i can be recorded as [ID_i_1, PC{i,1}]~[ID_i_m, PC{i,m}]. Of course, this is only an example, and the blockchain ledger can actually use other forms. For example, when there are multiple asset types, assets can be recorded and stored in a form similar to [type, identification, asset commitment]. In the process of calculating asset amounts and executing transactions, the impact of asset types needs to be considered, such as the proportional conversion of asset amounts between different types of assets. Furthermore, in addition to directly recording "asset commitment", other information can also be stored at the same time; taking the asset ID_j_m to be spent as an example, it can be recorded as [ID_j_m, E(t_j_m, r_j_m)], where E(t_j_m, r_j_m) = [PC(t_j_m, r_j_m), E(t_j_m), E(r_j_m)], E(t_j_m) and E(r_j_m) are the homomorphic ciphertexts corresponding to the asset amount t_j_m and the random number r_j_m, respectively, which can be obtained by encrypting the asset amount t_j_m and the random number r_j_m by the homomorphic encryption public key of the remitter (obtained by homomorphic encryption of the public key P_j). For ease of understanding, the following examples are given in the form of [identification, asset commitment].

[0156] As mentioned above, this manual uses the form of "account" to manage the assets held by users. Figure 4In summary, based on the asset account model in this specification, a corresponding account can be generated for each user, and the assets held by the user can be managed based on the account.

[0157] From the perspective of the input of the remittance transaction M, the roles of the remitter and the cover party are involved, while from the perspective of the output of the remittance, the roles of the actual recipient and the transaction recipient are involved. Among these roles, some may overlap to a certain extent.

[0158] For the remitter and the shielding party, the remittance transaction M is assembled according to the to-be-spent assets ID_j_1~ID_j_m in the corresponding account of the remitter and the shielding assets ID_i_1~ID_i_m in the corresponding account of shielding party i, and the linkable ring signature generated below is added, so that shielding party i can hide the identity of the remitter, so that other users cannot determine which user in "remitter and shielding party i" has spent the assets. Here, the shielding party may include any user other than the remitter, for example, the shielding party may include the actual payee of the remittance transaction M. For example, when the remitter is user A and the actual payee is user B and user C, by configuring user B and user C as shielding parties, not only can user B and user C hide the identity of user A, but also because user B and user C belong to both "transaction remitter" and "transaction payee", it brings a stronger confusing effect. For another example, the shielding party may include other users different from the remitter and the actual payee. For example, when the remitter is user A and the actual payee is user B and user C, the irrelevant user D may be configured as the shielding party to hide the identity of user A. For another example, the shielding party may include both the actual payee and other users. For example, when the remitter is user A and the actual payee is user B and user C, user B, user C and user D may be configured as the shielding party to hide the identity of user A.

[0159] For the actual payee and the transaction payee: In one embodiment, the transaction payee can be the actual payee. At this time, the sum of the asset amounts t_j_1~t_j_m corresponding to the assets ID_j_1~ID_j_m to be spent is exactly equal to the sum of the transfer amounts corresponding to each actual payee, that is, there is no change. In another embodiment, in addition to the actual payee, the transaction payee may also include the remitter. In this case, there may be two situations: in one case, the remitter is not deliberately set as the transaction payee, but because the sum of the asset amounts t_j_1~t_j_m corresponding to the assets ID_j_1~ID_j_m to be spent is greater than the sum of the transfer amounts corresponding to each actual payee, there is change that needs to be returned to the remitter, and the change amount (that is, the transfer amount corresponding to the remitter) is the difference between the sum of the asset amounts t_j_1~t_j_m and the sum of the transfer amounts; in another case, although there is no change, the remitter can still be set as the transaction payee, so that the remitter can play a certain cover role for the actual payee, and at this time the transfer amount corresponding to the remitter can be set to 0 to avoid affecting the original transfer operation. In another embodiment, the transaction payee may include a shielding party that is different from the actual payee and the remitter, and the shielding party hides the identity of the actual payee, and the transfer amount corresponding to the shielding party is 0; of course, in addition to the shielding party, the transaction payee may also include the remitter: when there is no change, the transfer amounts corresponding to the remitter and the shielding party are both 0; when there is change, the transfer amount corresponding to the remitter is the change amount, and the transfer amount corresponding to the shielding party is 0.

[0160] According to the actual situation, the identity of the remitter can be hidden only by the cover party, or the identity of the actual payee can be further hidden. In one embodiment, the participants of the remittance transaction M can include the remitter, the actual payee and the cover party different from the two at the same time. These users form a total of n participants, and the n participants all participate in the remittance and collection of the remittance transaction at the same time, thereby hiding the identities of the remitter and the actual payee at the same time. Moreover, since each participant participates in the remittance and collection at the same time, the identity confusion between the remitter and the actual payee can be achieved, thereby further increasing the reliability of identity hiding.

[0161] Assume that the recipients of the remittance transaction M are Q_1~Q_u, and the corresponding transfer amounts are t'_1~t'_u, where 1≤u≤n. In the remittance transaction M, similar to the asset amounts t_j_1~t_j_m corresponding to the aforementioned assets to be spent, the transfer amounts t'_1~t'_u are recorded in the remittance transaction M as corresponding transfer amount commitments PC(t'_1,r'_1)~PC(t'_u,r'_u), where r'_1~r'_u are random numbers. Among them, the random numbers r'_1~r'_u can be determined by the remitter and notified to the corresponding payee through an off-chain channel (usually only the actual payee needs to be informed), so that each payee can verify based on the random numbers r'_1~r'_u. For example, the payee w can verify whether PC(t'_w,r'_w)=t'_w×G+r'_w×H holds, and manage the assets corresponding to the transfer amount commitment PC(t'_w,r'_w) after the transaction is completed.

[0162] In an account model such as that adopted by Ethereum, when the remitter spends a sum of money through a transaction, the account balance in the corresponding account is updated immediately, that is, the amount of money spent is deducted, thereby ensuring the accuracy of the account balance. However, in the technical solution of this specification, after the remittance transaction M is completed, although the assets ID_j_1~ID_j_m in the corresponding account of the remitter are spent, the corresponding account of the remitter is not updated immediately, that is, there is no need to immediately delete the assets ID_j_1~ID_j_m in the corresponding account of the remitter, so that when any user queries the corresponding account of the remitter through the blockchain account book, the asset change will not be noticed after the remittance transaction M is completed, avoiding the exposure of the true identity of the remitter in the remittance transaction M based on the asset change. At the same time, although the corresponding account of the remitter contains both spent and unspent assets, based on the maintenance of the historical key mirror set, it can be ensured that the remitter can actually only spend the unspent assets, and accurately detect the "double flower" operation implemented by the remitter on the spent assets.

[0163] Of course, in order to avoid excessive accumulation of assets in the account and increase the maintenance cost of the blockchain node, and to facilitate each user to manage the assets in their own account, the user can clean up the spent assets in their own account. Taking the above-mentioned remitter as an example, the remitter can initiate an asset deletion request to the blockchain network to delete at least a part of the assets that the remitter has spent from the blockchain account book; for example, the remitter can specify the asset identifier corresponding to the asset to be deleted, or the remitter can specify a time period (the two end points of the time period can be specified; if only the left end point is specified, the time period is from the corresponding time of the left end point to the present; if only the right end point is specified, the time period is from the account creation to the corresponding time of the right end point) and delete all assets generated or spent in the time period.

[0164] Step 604a, obtaining the key images I_1~I_m contained in the linkable ring signature of the remittance transaction M, wherein the values ​​of the key images I_1~I_m are related to the private key x_j, public key P_j and asset identifiers ID_j_1~ID_j_m of the remitter.

[0165] The remitter needs to maintain a set of public-private key pairs, such as private key x_j and public key P_j. Before determining this set of public-private key pairs, it is necessary to determine a number field Z_q and an elliptic curve on the number field, such as the elliptic curve Ed25519, and let G and H be two random generators of the elliptic curve, where |G|=p is a large prime number (for example, not less than a preset value), and select the remitter's private key x_j in the value range (0,p), and the corresponding public key is P_j=x_j×G. For other users such as the shielding party, their unique corresponding public-private key pairs are determined in a similar way.

[0166] The key images I_1~I_m correspond to the assets ID_j_1~ID_j_m to be spent provided by the remitter, and are used to verify whether the corresponding assets to be spent have been spent, thereby solving the "double spending" problem. Among them, since the values ​​of the key images I_1~I_m are related to the asset identifiers ID_j_1~ID_j_m of the corresponding assets, even if all key images use the same set of public and private key pairs (i.e., the private key x_j and public key P_j of the remitter), it is possible to ensure that the generated key images I_1~I_m are completely different based on the value differences between the asset identifiers ID_j_1~ID_j_m. Therefore, there is no need to maintain a set of public and private key pairs for each asset. While solving the "double spending" problem, the number of public and private key pairs required to be maintained for each account is independent of the number of assets contained in the transaction. For example, I_d=x_j×Hash_G(P_j,ID_j_d), d∈[1,m]; wherein Hash_G() is the hash function of the above elliptic curve to itself.

[0167] After receiving the remittance transaction M, the blockchain node can compare the key images I_1~I_m with the historical key image set to determine whether there is a historical key image in the historical key image set that is the same as the key images I_1~I_m. The historical key image set is used to store key images corresponding to previously spent assets. If there is a historical key image that is the same as a key image in key images I_1~I_m, it means that the asset corresponding to the key image has been spent, that is, a "double spend" problem has occurred, and the execution of the remittance transaction M should be prevented. If key images I_1~I_m do not belong to the historical key image set, it means that the assets ID_j_1~ID_j_m corresponding to key images I_1~I_m have not been spent. If other transaction execution conditions are met, the remittance transaction M can be executed; and when the remittance transaction M is completed, the assets ID_j_1~ID_j_m corresponding to key images I_1~I_m have been spent, so it is necessary to add key images I_1~I_m to the historical key image set for subsequent detection of the "double spending" problem related to key images I_1~I_m.

[0168] Step 604b, verifying the linkable ring signature, wherein the linkable ring signature is generated by the remitter based on its own private key x_j, public key P_j and public key P_i held by shielding party i.

[0169] The linkable ring signature can be generated by the remitter directly based on its own corresponding private key x_j, public key P_j and public key P_i corresponding to shield party i, without using the pseudo private key r”, pseudo public key P”_j and pseudo public key P”_i corresponding to the remitter. At this time, if the linkable ring signature passes the verification, it can be proved that the linkable ring signature is signed by the private key corresponding to a public key in the public key (P_1, ..., P_n), thereby completing the identity verification without exposing the identity of the remitter.

[0170] The linkable ring signature can be generated by the remitter based on its corresponding private key x_j, public key P_j, pseudo private key r", pseudo public key P"_j, and the public key P_i and pseudo public key P"_i corresponding to the shielding party i. Among them, the pseudo public key P"_j = [PC(t_j_1,r_j_1)+...+PC(t_j_m,r_j_m)]-[PC(t'_1,r'_1)+...+PC(t'_u,r'_u)], the pseudo private key r" = (r_j_1+.. .+r_j_m)-(r'_1+...+r'_u). At the same time, according to the assets [ID_i_1,PC{i,1}]~[ID_i_m,PC{i,m}] held by shielding party i, the remitter can calculate the pseudo public key P"_i=[PC{i,1}+…+PC{i,m}]-[PC(t'_1,r'_1)+…+PC(t'_u,r'_u)] corresponding to shielding party i, i∈[1,j-1]∪[j+1,n]. The generation process of linkable ring signature can refer to Figure 5 The embodiment shown is not described here. By verifying the linkable ring signature, the blockchain node can efficiently and compactly implement the following two verification functions: On the one hand, since the pseudo public key P”_j and the pseudo private key r” satisfy P”_j=r”×G, and the pseudo public key P”_i and the pseudo private key r” satisfy P”_i≠r”×G, when a linkable ring signature is generated based on the pseudo private key r”, the pseudo public key P”_j and P”_i, if the linkable ring signature passes the verification, it can be proved that there is a pseudo public key in the pseudo public key (P”_1, …, P”_n). The value of the key is equal to r”×G, and this pseudo public key corresponds to the aforementioned t”=0, which can make the incoming amount of the remittance transaction M equal to the outgoing amount; on the other hand, when a linkable ring signature is generated based on the private key x_j, public key P_j corresponding to the remitter and the public key P_i corresponding to the shielding party i, if the linkable ring signature passes the verification, it can be proved that the linkable ring signature is signed by the private key corresponding to a public key in the public key (P_1,...,P_n), thereby completing the identity verification without exposing the identity of the remitter.

[0171] Step 606, when the transaction execution conditions are met, execute the remittance transaction M; the transaction execution conditions include: the key images I_1~I_m do not belong to the historical key image set, and the linkable ring signature passes the verification; wherein the key images I_1~I_m are added to the historical key image set after the transaction is completed.

[0172] The linkable ring signature may also include a key image I_(m+1), which is generated by the remitter based on its corresponding pseudo private key r” and pseudo public key P”_j, and the pseudo public key P”_i corresponding to the shielding party i, for example, I_(m+1) = r”×Hash_G(P”_j). As mentioned above, there is a one-to-one correspondence between the key image I_(m+1) and the corresponding transaction. Therefore, by comparing the key image I_(m+1) with the historical key image, the replay problem for the remittance transaction M can be identified: if the key image I_(m+1) has the same historical key image, it indicates that the remittance transaction M has been replayed. Then, the transaction execution condition may also include: the key image I_(m+1) does not belong to the historical key image set.

[0173] When the remitter corresponds to the public key P_j and the shielding party i corresponds to the public key P_i, the transaction execution conditions may also include: the asset ID_k_d belongs to the owner of the public key P_k, k∈[1,n], d∈[1,m]. In other words, the blockchain node can verify the ownership of each asset.

[0174] In confidential transactions, blockchain nodes can also verify whether the transfer amounts t'_1~t'_u in the remittance transaction M are not less than 0. The transfer amount commitment PC(t'_1,r'_1)~PC(t'_u,r'_u) is generated by the remitter based on the transfer amount t'_1~t'_u and the random number r'_1~r'_u, and the transfer amount t'_1~t'_u and the random number r'_1~r'_u are only known by the remitter and the payee Q_1~Q_u. Therefore, the verifier needs to implement the verification operation through the range proof RP_1~RP_u contained in the remittance transaction M to determine whether the transfer amount t'_1~t'_u satisfies t'_1≥0~t'_u≥0, where the range proof RP_1~RP_u is generated by the remitter and added to the remittance transaction M. Then, the transaction execution condition can also include: all transfer amounts are not less than 0.

[0175] Combine the following Figure 7 The process of verifying the linkable ring signature in step 604b is described; wherein, Figure 7 FIG. 1 is a flowchart of verifying a linkable ring signature provided by an exemplary embodiment. Figure 7 As shown, the following steps may be included:

[0176] Step 702, verify whether the asset corresponding to the identifier ID_k_d belongs to the holder of the public key P_k, k∈[1,n], d∈[1,m].

[0177] The verifier can be a blockchain node in the blockchain network. After receiving the remittance transaction M submitted by the remitter, the blockchain node can verify the ring signature of the remittance transaction M. Similarly, each blockchain node will receive the remittance transaction M and perform verification as a verifier. The remittance transaction M can be sent from the client device to the verifier, or the remittance transaction M can be forwarded to other verifiers after being received from the client device by a verifier, or the remittance transaction M can be forwarded to other verifiers after being received from another verifier by a verifier.

[0178] The verifier maintains a full blockchain account book as a blockchain node, so that the verifier can know the asset holdings of each user. The remittance transaction M involves the asset ID_k_d held by user k (corresponding to the public key P_k), and the verifier can verify whether the corresponding relationship between each public key P_k and the corresponding asset ID_k_d is established based on the maintained asset holdings, that is, whether the holder of the public key P_k owns the m assets corresponding to the identifier ID_k_d. If the corresponding relationship between each public key P_k and the identifier ID_k_d in the corresponding array is established, the subsequent steps can be continued; if the asset corresponding to a certain identifier does not belong to the holder of the public key P_k, the verifier can determine that the remittance transaction M is invalid without continuing to execute the subsequent steps 704 to 708.

[0179] Step 704, calculate L_k_1~L_k_(m+1) and R_k_1~R_k_(m+1) in sequence according to s_k_1~s_k_(m+1).

[0180] Step 706, calculate c_1' according to L_n_1~L_n_(m+1) and R_n_1~R_n_(m+1), and verify whether c_1' is equal to c_1.

[0181] The verifier can calculate the intermediate parameters L_j_d, R_j_d, L_j_(m+1), R_j_(m+1), L_i_d, R_i_d, L_i_(m+1), and R_i_(m+1) based on the random number and / or its derivative value contained in the ring signature to verify whether the intermediate parameters L_j_d and L_i_d comply with the ring value rule, whether the intermediate parameters R_j_d and R_i_d comply with the ring value rule, whether the intermediate parameters L_j_(m+1) and L_i_(m+1) comply with the ring value rule, and whether the intermediate parameters R_j_(m+1) and R_i_(m+1) comply with the ring value rule.

[0182] For example, when the random number and / or its derivative value contained in the ring signature includes: s_1_1~s_1_(m+1),…,s_n_1~s_n_(m+1), c_1, the ring value rules between the intermediate parameters L_j_d and L_i_d may include:

[0183] L_k_d=(s_k_d×G+c_k×P_k)mod p, h∈[1,n]

[0184]

[0185] The circular value rules between the intermediate parameters L_j_(m+1) and L_i_(m+1) include:

[0186] L_k_(m+1)=[s_k_(m+1)×G+c_k×P”_k]mod p

[0187] The circular value rules between the intermediate parameters R_j_d and R_i_d include:

[0188] R_k_d=[s_k_d×Hash_G(P_k,ID_k_d)+c_k×I_d]mod p

[0189] The ring value rules between the intermediate parameters R_j_(m+1) and R_i_(m+1) include:

[0190] R_k_(m+1)=[s_k_(m+1)×Hash_G(P”_k)+c_k×I_(m+1)]mod p

[0191] Then, the verifier can first generate L_1_d, that is, L_1_1~L_1_m, based on s_1_d, c_1, G, P_1 and p, and generate R_1_d, that is, R_1_1~R_1_m, based on s_1_d, c_1, P_1, ID_1_d, I_d and p; and, the verifier generates L_1_(m+1) based on s_1_(m+1), c_1, G, P”_1 and p, and generates R_1_(m+1) based on s_1_(m+1), c_1, P”_1, I_(m+1) and p.

[0192] Then, the verifier can generate c_2 based on M, L_1_d, R_1_d, L_1_(m+1) and R_1_(m+1), and generate L_2_d based on s_2_d, c_2, G, P_2 and p, generate R_2_d based on s_2_d, c_2, P_2, ID_2_d, I_d and p, generate L_2_(m+1) based on s_2_(m+1), c_2, G, P”_2 and p, and generate R_2_(m+1) based on s_2_(m+1), c_2, P”_2, I_(m+1) and p; and so on until the verifier The party generates c_n according to M, L_(n-1)_d, R_(n-1)_d, L_(n-1)_(m+1) and R_(n-1)_(m+1), and generates L_n_d according to s_n_d, c_n, G, P_n and p, generates R_n_d according to s_n_d, c_n, P_n, ID_n_d, I_d and p, generates L_n_(m+1) according to s_n_(m+1), c_n, G, P”_n and p, and generates R_n_(m+1) according to s_n_(m+1), c_n, P”_n, I_(m+1) and p.

[0193] Furthermore, the verifier can calculate c_1'=Hash[M,L_n_1,R_n_1,……,L_n_(m+1),R_n_(m+1)] according to the above calculation formula for c_k. The reason why c_1' is used here is to distinguish it from c_1 contained in the ring signature. Then the verifier can compare c_1' with c_1 contained in the ring signature: if c_1' is equal to c_1, it indicates that the above ring value rule is satisfied, and it can be determined that: 1) among the pseudo public keys P_1~P_n, there is a pseudo public key that makes the inward amount of the remittance transaction M equal to the outward amount; 2) the ring signature is generated by the private key corresponding to a public key among the public keys P_1~P_m. If c_1' is not equal to c_1, it indicates that at least one of 1) and 2) is not true, and the remittance transaction M is confirmed to be invalid, and there is no need to continue to perform the following step 708.

[0194] Step 708, verify range proofs RP_1~RP_u.

[0195] The verifier obtains the range proofs RP_1-RP_u from the transaction content of the remittance transaction M and verifies them to determine whether the corresponding transfer amounts t'_1-t'_u are all not less than 0. If they are satisfied, the process proceeds to step 710, otherwise the remittance transaction M is confirmed to be invalid, and there is no need to continue to execute the following step 710.

[0196] Step 710: Verify whether key images I_1 to I_(m+1) already exist.

[0197] In one embodiment, the verifier may compare key images I_1 to I_(m+1) with historical key images to determine whether key images I_1 to I_(m+1) already exist. If any of key images I_1 to I_(m+1) already has a corresponding historical key image, the remittance transaction M may be determined to be invalid; if none of key images I_1 to I_(m+1) has a corresponding historical key image, the remittance transaction M may be determined to be valid, and the remittance transaction M may be executed to complete the remittance operation.

[0198] Figure 8 is a schematic structural diagram of a device provided by an exemplary embodiment. Figure 8 At the hardware level, the device includes a processor 802, an internal bus 804, a network interface 806, a memory 808, and a non-volatile memory 810, and may also include hardware required for other services. The processor 802 reads the corresponding computer program from the non-volatile memory 810 into the memory 808 and then runs it, forming an anonymous transaction device based on a ring signature at the logical level. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementation methods, 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.

[0199] Please refer to Fig. 9 In a software implementation, the anonymous transaction device based on ring signature may include:

[0200] The transaction assembly unit 91 assembles the remittance transaction M according to the to-be-spent assets ID_j_1-ID_j_m in the corresponding account of the remitter and the protected assets ID_i_1-ID_i_m in the corresponding account of the shielding party i; wherein the to-be-spent assets ID_j_1-ID_j_m and the protected assets ID_i_1-ID_i_m are respectively recorded in the blockchain account book as asset commitments corresponding to the corresponding asset amounts, i∈[1,j-1]∪[j+1,n];

[0201] The signature generation unit 92 generates a linkable ring signature for the remittance transaction M according to the private key x_j and public key P_j held by the remitter and the public key P_i held by the shielding party i, wherein the linkable ring signature includes key images I_1 to I_m, and the values ​​of the key images I_1 to I_m are related to the private key x_j, public key P_j and asset identifiers ID_j_1 to ID_j_m of the remitter;

[0202] The transaction submission unit 93 submits the signed remittance transaction M to the blockchain network; wherein, after the transaction is completed, the key images I_1~I_m are added to the historical key image set, and the assets to be spent ID_j_1~ID_j_m are maintained and recorded on the blockchain ledger as assets held by the remitter.

[0203] Optionally, the key images I_1 to I_m are calculated by the following formula:

[0204] I_d=x_j×Hash_G(P_j,ID_j_d), d∈[1,m];

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

[0206] Optionally, the shielding party includes any one of the following or a combination thereof: an actual payee of the remittance transaction M, and other users different from the remitter and the actual payee.

[0207] Optional,

[0208] When there is no change, the payee of the remittance transaction M is the actual payee; when there is change, the payee of the remittance transaction M is the remitter and the actual payee; or,

[0209] The transaction payee includes the actual payee and the remitter; wherein, when there is no change, the transfer amount corresponding to the remitter is 0; or,

[0210] The transaction payee includes the actual payee, the remitter, and a cover party different from the actual payee and the remitter; wherein, when there is no change, the transfer amount corresponding to the remitter and the cover party serving as the transaction payee is 0; when there is change, the transfer amount corresponding to the remitter is the change amount, and the transfer amount corresponding to the cover party serving as the transaction payee is 0.

[0211] Optionally, also include:

[0212] The proof generating unit 94 generates corresponding range proofs for the transfer amounts corresponding to the various transaction payees of the remittance transaction M, respectively. The range proofs are assembled into the remittance transaction M to prove that the corresponding transfer amounts are not less than 0.

[0213] Optional,

[0214] The assets to be spent ID_j_1~ID_j_m and the assets ID_i_1~ID_i_m are the transaction outputs of the corresponding historical transactions; or,

[0215] The assets to be spent ID_j_1 to ID_j_m are generated by dividing the account balance corresponding to the remitter, and the assets ID_i_1 to ID_i_m are generated by dividing the account balance corresponding to the shielding party i.

[0216] Optionally, the signature generation unit 92 is specifically used for:

[0217] According to the asset amounts t_j_1~t_j_m, random numbers r_j_1~r_j_m and asset commitments PC(t_j_1,r_j_1)~PC(t_j_m,r_j_m) corresponding to the assets to be spent ID_j_1~ID_j_m, and the transfer amounts t'_1~t'_u, random numbers r'_1~r'_u and transfer amount commitments PC(t'_1,r'_1) corresponding to the transaction payees Q_1~Q_u ~PC(t'_u,r'_u), determine the pseudo public key P"_j corresponding to the remitter = [PC(t_j_1,r_j_1)+...+PC(t_j_m,r_j_m)]-[PC(t'_1,r'_1)+...+PC(t'_u,r'_u)], and the pseudo private key r" corresponding to the remitter = (r_j_1+...+r_j_m)-(r'_1+...+r'_u), u≥1;

[0218] According to the asset commitments PC{i,1}~PC{i,m} corresponding to the shielded assets ID_i_1~ID_i_m, determine the pseudo public key P”_i=[PC{i,1}+…+PC{i,m}]-[PC(t'_1,r'_1)+…+PC(t'_u,r'_u)] corresponding to the shielding party i, i∈[1,j-1]∪[j+1,n];

[0219] According to the private key x_j, public key P_j, pseudo private key r", pseudo public key P"_j corresponding to the remitter, and the public key P_i and pseudo public key P"_i corresponding to the shielding party i, a linkable ring signature is generated for the remittance transaction M.

[0220] Optionally, also include:

[0221] The image generation unit 95 generates a key image I_(m+1)=r”×Hash_G(P”_j) according to the pseudo private key r” and pseudo public key P”_j corresponding to the remitter; wherein the linkable ring signature also includes the key image I_(m+1).

[0222] Optionally, the signature generation unit 92 is specifically used for:

[0223] Generate the intermediate parameters L_j_d, R_j_d, L_j_(m+1), R_j_(m+1) corresponding to the remitter, and the intermediate parameters L_i_d, R_i_d, L_i_(m+1), R_i_(m+1) corresponding to the shielding party i, d∈[1,m]; among which, the intermediate parameters L_j_d and L_i_d conform to the circular value rule, and the intermediate parameters L_j_(m+1) and L_i_(m+1) conform to the circular value rule. The value-taking rule, the intermediate parameters R_j_d and R_i_d conform to the circular value-taking rule, the intermediate parameters R_j_(m+1) and R_i_(m+1) conform to the circular value-taking rule, and the values ​​of the intermediate parameters L_j_d, R_j_d, L_j_(m+1), R_j_(m+1), L_i_d, R_i_d, L_i_(m+1), and R_i_(m+1) are related to at least one selected random number and / or its derivative value;

[0224] A linkable ring signature for the remittance transaction M is generated based on the selected random number and / or its derivative value.

[0225] Optional,

[0226] P_j=x_j×G, G is the base point of the elliptic curve, |G|=p and p is a prime number, 0 <x_j<p;

[0227] Generate intermediate parameters L_j_d and R_j_d corresponding to the remitter, including: according to a random number a_d selected in the number field Z_q where the elliptic curve is located, calculate the intermediate parameters L_j_d and R_j_d, so that L_j_d = a_d × G, R_j_d = a_d × Hash_G (P_j, ID_j_d); wherein Hash_G() is a hash function from the elliptic curve to itself;

[0228] Generate intermediate parameters L_j_(m+1) and R_j_(m+1) corresponding to the remitter, including: according to a random number a_(m+1) selected in the number field Z_q where the elliptic curve is located, calculate the intermediate parameters L_j_(m+1) and R_j_(m+1), so that L_j_(m+1)=a_(m+1)×G, R_j_(m+1)=a_(m+1)×Hash_G(P”_j);

[0229] Generate intermediate parameters L_i_d, R_i_d, L_i_(m+1), R_i_(m+1) corresponding to the shielding party i, including: generating intermediate parameters L_i_d, R_i_d, L_i_(m+1), R_i_(m+1) according to the values ​​of the intermediate parameters L_j_d and R_j_d, so that L_i_d=(s_i_d×G+c_i×P_i)mod p, R_i_d=(s_i_d×Hash_G(P_i,ID_i_d)+c_i×I_d)modp, L_i_(m+1)=[s_i_(m+1)×G+c_i×P”_i]mod p, R_i_(m+1)=[s_i_(m+1)×Hash_G(P”_i)+c_i×I_(m+1)]mod p, I_d=x_j×Hash_G(P_j,ID_j_d), I_(m+1)=r”×Hash_G(P”_j); wherein, s_i_1~s_i_(m+1) are random numbers in the number field Z_q, when i=1, c_1=Hash(M,L_n_1,R_n_1,……,L_n_(m+1),R_n_(m+1)), when i∈[2,j-1]∪[j+1,n], c_i=Hash(M,L_(i-1)_1,R_(i-1)_1,……,L_(i-1)_(m+1),R_(i-1)_(m+1)), Hash() is the hash function from the elliptic curve to the number field Z_q;

[0230] The selected random numbers and / or their derived values ​​include: random numbers s_i_1~s_i_(m+1), derived value c_1, and derived values ​​s_j_1~s_j_(m+1); wherein, s_j_d=(a_d-c_j×x_j)mod p, s_j_(m+1)=[a_(m+1)-c_j×r”]mod p, when the value of j is determined to be 1, c_j=Hash(M,L_n_1,R_n_1,…,L_n_(m+1),R_n_(m+1)), and when the value of j is determined to belong to [2,n], c_j=Hash(M,L_(j-1)_1,R_(j-1)_1,…,L_(j-1)_(m+1),R_(j-1)_(m+1)).

[0231] Optionally, also include:

[0232] The asset deletion unit 96 initiates an asset deletion request to the blockchain network to delete at least a portion of the assets that the remitter has spent from the blockchain account book.

[0233] Fig.10 is a schematic structural diagram of a device provided by an exemplary embodiment. Fig.10At the hardware level, the device includes a processor 1002, an internal bus 1004, a network interface 1006, a memory 1008, and a non-volatile memory 1010, and may also include hardware required for other services. The processor 1002 reads the corresponding computer program from the non-volatile memory 1010 into the memory 1008 and then runs it, forming an anonymous transaction device based on a ring signature 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.

[0234] Please refer to Fig.11 In a software implementation, the anonymous transaction device based on ring signature may include:

[0235] The transaction receiving unit 1101 receives a remittance transaction M, which is generated by the remitter according to the to-be-spent assets ID_j_1~ID_j_m in its corresponding account and the shielded assets ID_i_1~ID_i_m in the corresponding account of the shielding party i, i∈[1,j-1]∪[j+1,n]; after the transaction is completed, the assets ID_j_1~ID_j_m are recorded as the assets held by the remitter in the blockchain account book;

[0236] The image acquisition unit 1102 acquires the key images I_1 to I_m contained in the linkable ring signature of the remittance transaction M, where the values ​​of the key images I_1 to I_m are related to the private key x_j, the public key P_j and the asset identifiers ID_j_1 to ID_j_m of the remitter;

[0237] The signature verification unit 1103 verifies the linkable ring signature, where the linkable ring signature is generated by the remitter according to its own private key x_j, public key P_j and public key P_i held by shielding party i;

[0238] The transaction execution unit 1104 executes the remittance transaction M when the transaction execution conditions are met; the transaction execution conditions include: the key images I_1~I_m do not belong to the historical key image set and the linkable ring signature passes the verification; wherein the key images I_1~I_m are added to the historical key image set after the transaction is completed.

[0239] Optionally, the key images I_1 to I_m are calculated by the remitter using the following formula:

[0240] I_d=x_j×Hash_G(P_j,ID_j_d), d∈[1,m];

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

[0242] Optionally, the shielding party includes any one of the following or a combination thereof: an actual payee of the remittance transaction M, and other users different from the remitter and the actual payee.

[0243] Optional,

[0244] When there is no change, the payee of the remittance transaction M is the actual payee; when there is change, the payee of the remittance transaction M is the remitter and the actual payee; or,

[0245] The transaction payee includes the actual payee and the remitter; wherein, when there is no change, the transfer amount corresponding to the remitter is 0; or,

[0246] The transaction payee includes the actual payee, the remitter, and a cover party different from the actual payee and the remitter; wherein, when there is no change, the transfer amount corresponding to the remitter and the cover party serving as the transaction payee is 0; when there is change, the transfer amount corresponding to the remitter is the change amount, and the transfer amount corresponding to the cover party serving as the transaction payee is 0.

[0247] Optionally, also include:

[0248] The amount verification unit 1105 verifies whether the transfer amount corresponding to each transaction payee is not less than 0 according to the range proof contained in the remittance transaction M;

[0249] The transaction execution conditions also include: the transfer amount corresponding to each transaction payee is not less than 0.

[0250] Optional,

[0251] The assets to be spent ID_j_1~ID_j_m and the assets ID_i_1~ID_i_m are the transaction outputs of the corresponding historical transactions; or,

[0252] The assets to be spent ID_j_1 to ID_j_m are generated by dividing the account balance corresponding to the remitter, and the assets ID_i_1 to ID_i_m are generated by dividing the account balance corresponding to the shielding party i.

[0253] Optionally, the transaction execution condition also includes: the asset ID_k_d belongs to the owner of the public key P_k, k∈[1,n], d∈[1,m], i∈[1,j-1]∪[j+1,n].

[0254] Optionally, the linkable ring signature is generated by the remitter according to its own private key x_j, public key P_j, pseudo private key r″ and pseudo public key P″_j, and the public key P_i and pseudo public key P″_i corresponding to the shielding party i, so that when the linkable ring signature is verified, the remittance transaction M is confirmed as equal to the input and output;

[0255] Among them, the pseudo public key P”_j=[PC(t_j_1,r_j_1)+…+PC(t_j_m,r_j_m)]-[PC(t'_1,r'_1)+…+PC(t'_u,r'_u)], the pseudo private key r”=(r_j_1+…+r_j_m)-(r'_1+…+r'_u), the pseudo public key P”_i=[PC{i,1}+…+PC{i,m}]-[PC(t'_1,r'_1)+…+PC(t'_u,r'_u)], i∈[1,j-1]∪[j+1,n], the asset label Identification ID_j_1~ID_j_m corresponds to asset amounts t_j_1~t_j_m, random numbers r_j_1~r_j_m and asset commitments PC(t_j_1,r_j_1)~PC(t_j_m,r_j_m), covering assets ID_i_1~ID_i_m correspond to asset commitments PC{i,1}~PC{i,m}, and transaction recipients Q_1~Q_u correspond to transfer amounts t'_1~t'_u, random numbers r'_1~r'_u and transfer amount commitments PC(t'_1,r'_1)~PC(t'_u,r'_u), u≥1.

[0256] Optionally, the linkable ring signature further includes a key image I_(m+1)=r”×Hash_G(P”_j);

[0257] The transaction execution condition further includes: the key image I_(m+1) does not belong to the historical key image set.

[0258] Optionally, the remitter generates intermediate parameters L_j_d, R_j_d, L_j_(m+1), R_j_(m+1) corresponding to the remitter according to its own private key x_j, public key P_j, pseudo private key r", pseudo public key P"_j, public key P_i and pseudo public key P"_i corresponding to shield party i, and intermediate parameters L_i_d, R_i_d, L_i_(m+1), R_i_(m+1) corresponding to shield party i, and generates the linkable ring signature according to random numbers and / or their derivative values ​​related to the values ​​of the intermediate parameters L_j_d, R_j_d, L_j_(m+1), R_j_(m+1), L_i_d, R_i_d, L_i_(m+1), R_i_(m+1), d∈[1,m]; verifying the linkable ring signature includes:

[0259] According to the random number and / or its derivative value contained in the ring signature, the intermediate parameters L_j_d, R_j_d, L_j_(m+1), R_j_(m+1), L_i_d, R_i_d, L_i_(m+1), and R_i_(m+1) are calculated to verify whether the intermediate parameters L_j_d and L_i_d comply with the ring value rule, whether the intermediate parameters L_j_(m+1) and L_i_(m+1) comply with the ring value rule, whether the intermediate parameters R_j_d and R_i_d comply with the ring value rule, and whether the intermediate parameters R_j_(m+1) and R_i_(m+1) comply with the ring value rule.

[0260] Optional,

[0261] P_j=x_j×G, G is the base point of the elliptic curve, |G|=p and p is a prime number, 0 <x_j<p;

[0262] The random number and / or its derivative value contained in the ring signature include: s_k_1~s_k_(m+1), c_1, k∈[1,n];

[0263] The circular value rule between the intermediate parameters L_j_d and L_i_d includes: L_k_d = (s_k_d × G + c_k × P_k) mod p; wherein s_k_d 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;

[0264] The circular value rule between the intermediate parameters L_j_(m+1) and L_i_(m+1) includes: L_k_(m+1) = [s_k_(m+1) × G + c_k × P”_k] mod p; where s_k_(m+1) belongs to the number field Z_q;

[0265] The ring value rule between the intermediate parameters R_j_d and R_i_d includes: R_k_d = (s_k_d × Hash_G (P_k, ID_k_d) + c_k × I_d) mod p, I_d is included in the ring signature;

[0266] The ring value rule between the intermediate parameters R_j_(m+1) and R_i_(m+1) includes: R_k_(m+1)=[s_k_(m+1)×Hash_G(P”_k)+c_k×I_(m+1)]mod p, I_(m+1) is included in the ring signature;

[0267] Among them, when h=1, c_1=Hash(M,L_n_1,R_n_1,…,L_n_(m+1),R_n_(m+1)), and when h∈[2,n], c_k=Hash(M,L_(h-1)_1,R_(h-1)_1,…,L_(h-1)_(m+1),R_(h-1)_(m+1)).

[0268] Optionally, also include:

[0269] The asset deletion unit 1106 deletes at least a portion of the assets spent by the remitter from the blockchain account book according to the asset deletion request initiated by the remitter to the blockchain network.

[0270] 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.

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

[0272] 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.

[0273] 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.

[0274] 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.

[0275] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do 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.

[0276] 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 and the appended claims 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 herein refers to and includes any or all possible combinations of one or more associated listed items.

[0277] 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".

[0278] 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. An anonymous transaction method based on ring signature, comprising: According to the to-be-spent assets ID_j_1~ID_j_m in the corresponding account of the remitter and the protected assets ID_i_1~ID_i_m in the corresponding account of the protector i, a remittance transaction M is assembled; wherein the to-be-spent assets ID_j_1~ID_j_m and the protected assets ID_i_1~ID_i_m are respectively recorded as asset commitments corresponding to the corresponding asset amounts in the blockchain ledger; Generate a linkable ring signature for the remittance transaction M based on the private key x_j, public key P_j held by the remitter and the public key P_i held by the shielding party i, wherein the linkable ring signature contains key images I_1~I_m, and the values ​​of the key images I_1~I_m are related to the private key x_j, public key P_j and asset identifiers ID_j_1~ID_j_m of the remitter; Submit the signed remittance transaction M to the blockchain network; wherein, after the transaction is completed, the key images I_1~I_m are added to the historical key image set, and the assets to be spent ID_j_1~ID_j_m are maintained and recorded as assets held by the remitter on the blockchain ledger.

2. According to the method of claim 1, the key images I_1 to I_m are calculated by the following formula: I_d=x_j×Hash_G(P_j,ID_j_d), d∈[1,m]; in, Hash_G() is the hash function of an elliptic curve to itself.

3. The method according to claim 1, wherein the shielding party comprises any one of the following or a combination thereof: an actual payee of the remittance transaction M, and other users different from the remitter and the actual payee.

4. The method according to claim 1, When there is no change, the payee of the remittance transaction M is the actual payee; when there is change, the payee of the remittance transaction M is the remitter and the actual payee; or, The transaction payee includes the actual payee and the remitter; wherein, When there is no change, the corresponding transfer amount of the remitter is 0; or, The transaction payee includes the actual payee, the remitter, and a cover party different from the actual payee and the remitter; wherein, when there is no change, the transfer amount corresponding to the remitter and the cover party serving as the transaction payee is 0; when there is change, the transfer amount corresponding to the remitter is the change amount, and the transfer amount corresponding to the cover party serving as the transaction payee is 0.

5. The method according to claim 1, further comprising: For the transfer amounts corresponding to the various transaction payees of the remittance transaction M, corresponding range proofs are generated respectively, and the range proofs are assembled into the remittance transaction M to prove that the corresponding transfer amounts are not less than 0.

6. The method according to claim 1, The to-be-spent assets ID_j_1~ID_j_m and the cover assets ID_i_1~ID_i_m are the transaction outputs of the corresponding historical transactions; or, The assets to be spent ID_j_1 to ID_j_m are generated by dividing the account balance corresponding to the remitter, and the shielding assets ID_i_1 to ID_i_m are generated by dividing the account balance corresponding to the shielding party i.

7. The method according to claim 3, generating a linkable ring signature for the remittance transaction M based on the private key x_j, the public key P_j held by the remitter and the public key P_i held by the shielding party i, comprising: According to the asset amounts t_j_1~t_j_m, random numbers r_j_1~r_j_m and asset commitments PC(t_j_1,r_j_1)~PC(t_j_m,r_j_m) corresponding to the assets to be spent ID_j_1~ID_j_m, and the transfer amounts t'_1~t'_u, random numbers r'_1~r'_u and transfer amount commitments PC(t'_1,r'_1) corresponding to the transaction payees Q_1~Q_u ~PC(t'_u,r'_u), determine the pseudo public key P"_j corresponding to the remitter = [PC(t_j_1,r_j_1)+...+PC(t_j_m,r_j_m)]-[PC(t'_1,r'_1)+...+PC(t'_u,r'_u)], and the pseudo private key r" corresponding to the remitter = (r_j_1+...+r_j_m)-(r'_1+...+r'_u), u≥1; According to the asset commitments PC{i,1}~PC{i,m} corresponding to the shielded assets ID_i_1~ID_i_m, determine the pseudo public key P”_i=[PC{i,1}+…+PC{i,m}]-[PC(t'_1,r'_1)+…+PC(t'_u,r'_u)] corresponding to the shielding party i, i∈[1,j-1]∪[j+1,n]; Generate a linkable ring signature for the remittance transaction M based on the private key x_j, public key P_j, pseudo private key r”, pseudo public key P”_j corresponding to the remitter, and the public key P_i and pseudo public key P”_i corresponding to the shielding party i; According to the pseudo private key r” and pseudo public key P”_j corresponding to the remitter, a key image I_(m+1)=r”×Hash_G(P”_j) is generated; wherein the linkable ring signature also includes the key image I_(m+1).

8. The method according to claim 7, generating a linkable ring signature for the remittance transaction M according to the private key x_j, public key P_j, pseudo private key r", pseudo public key P"_j corresponding to the remitter, and the public key P_i and pseudo public key P"_i corresponding to the shielding party i, comprising: Generate the intermediate parameters L_j_d, R_j_d, L_j_(m+1), R_j_(m+1) corresponding to the remitter, and the intermediate parameters L_i_d, R_i_d, L_i_(m+1), R_i_(m+1) corresponding to the shielding party i, d∈[1,m]; among which, the intermediate parameters L_j_d and L_i_d conform to the circular value rule, and the intermediate parameters L_j_(m+1) and L_i_(m+1) conform to the circular value rule. The value-taking rule, the intermediate parameters R_j_d and R_i_d conform to the circular value-taking rule, the intermediate parameters R_j_(m+1) and R_i_(m+1) conform to the circular value-taking rule, and the values ​​of the intermediate parameters L_j_d, R_j_d, L_j_(m+1), R_j_(m+1), L_i_d, R_i_d, L_i_(m+1), and R_i_(m+1) are related to at least one selected random number and / or its derivative value; A linkable ring signature for the remittance transaction M is generated based on the selected random number and / or its derivative value.

9. The method according to claim 8, P_j=x_j×G, G is the base point of the elliptic curve, |G|=p and p is a prime number, 0 <x_j<p; Generate the intermediate parameters L_j_d and R_j_d corresponding to the remitter, including: According to the random number a_d selected in the number field Z_q where the elliptic curve is located, calculate the intermediate parameters L_j_d and R_j_d, so that L_j_d = a_d × G, R_j_d = a_d × Hash_G (P_j, ID_j_d); wherein Hash_G() is a hash function from the elliptic curve to itself; Generate intermediate parameters L_j_(m+1) and R_j_(m+1) corresponding to the remitter, including: according to a random number a_(m+1) selected in the number field Z_q where the elliptic curve is located, calculate the intermediate parameters L_j_(m+1) and R_j_(m+1), so that L_j_(m+1)=a_(m+1)×G, R_j_(m+1)=a_(m+1)×Hash_G(P”_j); Generate intermediate parameters L_i_d, R_i_d, L_i_(m+1), R_i_(m+1) corresponding to the shielding party i, including: generating intermediate parameters L_i_d, R_i_d, L_i_(m+1), R_i_(m+1) according to the values ​​of the intermediate parameters L_j_d and R_j_d, so that L_i_d=(s_i_d×G+c_i×P_i)mod p, R_i_d=(s_i_d×Hash_G(P_i,ID_i_d)+c_i×I_d)mod p, L_i_(m+1)=[s_i_(m+1)×G+c_i×P”_i]mod p, R_i_(m+1)=[s_i_(m+1)×Hash_G(P”_i)+c_i×I_(m+1)]mod p, I_d=x_j×Hash_G(P_j,ID_j_d), I_(m+1)=r”×Hash_G(P”_j); wherein, s_i_1~s_i_(m+1) are random numbers in the number field Z_q, when i=1, c_1=Hash(M,L_n_1,R_n_1,……,L_n_(m+1),R_n_(m+1)), when i∈[2,j-1]∪[j+1,n], c_i=Hash(M,L_(i-1)_1,R_(i-1)_1,……,L_(i-1)_(m+1),R_(i-1)_(m+1)), Hash() is the hash function from the elliptic curve to the number field Z_q; The selected random numbers and / or their derived values ​​include: random numbers s_i_1~s_i_(m+1), derived value c_1, and derived values ​​s_j_1~s_j_(m+1); wherein, s_j_d=(a_d-c_j×x_j)mod p, s_j_(m+1)=[a_(m+1)-c_j×r”]mod p, when the value of j is determined to be 1, c_j=Hash(M,L_n_1,R_n_1,…,L_n_(m+1),R_n_(m+1)), and when the value of j is determined to belong to [2,n], c_j=Hash(M,L_(j-1)_1,R_(j-1)_1,…,L_(j-1)_(m+1),R_(j-1)_(m+1)).

10. The method according to claim 1, further comprising: Initiate an asset deletion request to the blockchain network to delete at least a portion of the assets that the remitter has spent from the blockchain ledger.

11. An anonymous transaction method based on ring signature, comprising: Receive remittance transaction M, which is generated by the remitter based on the to-be-spent assets ID_j_1~ID_j_m in its corresponding account and the shielded assets ID_i_1~ID_i_m in the corresponding account of shielding party i; after the transaction is completed, the assets ID_j_1~ID_j_m are recorded as assets held by the remitter in the blockchain ledger; Obtain the key images I_1~I_m contained in the linkable ring signature of the remittance transaction M, where the values ​​of the key images I_1~I_m are related to the private key x_j, public key P_j and asset identifiers ID_j_1~ID_j_m of the remitter; Verify the linkable ring signature, which is generated by the remitter based on its own private key x_j, public key P_j and public key P_i held by shielding party i; When the transaction execution conditions are met, the remittance transaction M is executed; The transaction execution conditions include: the key images I_1~I_m do not belong to the historical key image set and the linkable ring signature passes verification; wherein the key images I_1~I_m are added to the historical key image set after the transaction is completed.

12. According to the method of claim 11, the key images I_1 to I_m are calculated by the remitter through the following formula: I_d=x_j×Hash_G(P_j,ID_j_d), d∈[1,m]; in, Hash_G() is the hash function of an elliptic curve to itself.

13. The method according to claim 11, wherein the shielding party comprises any one of the following or a combination thereof: an actual payee of the remittance transaction M, and other users different from the remitter and the actual payee.

14. The method according to claim 11, When there is no change, the payee of the remittance transaction M is the actual payee; when there is change, the payee of the remittance transaction M is the remitter and the actual payee; or, The transaction payee includes the actual payee and the remitter; wherein, When there is no change, the corresponding transfer amount of the remitter is 0; or, The transaction payee includes the actual payee, the remitter, and a cover party different from the actual payee and the remitter; wherein, when there is no change, the transfer amount corresponding to the remitter and the cover party serving as the transaction payee is 0; when there is change, the transfer amount corresponding to the remitter is the change amount, and the transfer amount corresponding to the cover party serving as the transaction payee is 0.

15. The method according to claim 11, further comprising: According to the range proof contained in the remittance transaction M, verify whether the transfer amount corresponding to each transaction recipient is not less than 0; The transaction execution conditions also include: the transfer amount corresponding to each transaction payee is not less than 0.

16. The method according to claim 11, The to-be-spent assets ID_j_1~ID_j_m and the cover assets ID_i_1~ID_i_m are the transaction outputs of the corresponding historical transactions; or, The assets to be spent ID_j_1 to ID_j_m are generated by dividing the account balance corresponding to the remitter, and the shielding assets ID_i_1 to ID_i_m are generated by dividing the account balance corresponding to the shielding party i.

17. The method according to claim 11, wherein the transaction execution condition further comprises: The asset ID_k_d belongs to the owner of the public key P_k, k∈[1,n], d∈[1,m], i∈[1,j-1]∪[j+1,n].

18. The method according to claim 13, wherein the linkable ring signature is generated by the remittance party according to its own private key x_j, public key P_j, pseudo private key r″ and pseudo public key P″_j, and the public key P_i and pseudo public key P″_i corresponding to the shielding party i, so that when the linkable ring signature is verified, the remittance transaction M is confirmed as equal to the input and output; in, Pseudo public key P”_j=[PC(t_j_1,r_j_1)+…+PC(t_j_m,r_j_m)]-[PC(t'_1,r'_1)+…+PC(t'_u,r'_u)], pseudo private key r”=(r_j_1+…+r_j_m)-(r'_1+…+r'_u), pseudo public key P”_i=[PC{i,1}+…+PC{i,m}]-[PC(t'_1,r'_1)+…+PC(t'_u,r'_u)], i∈[1,j-1]∪[j+1,n], asset identifiers ID_j_1~ID_j_m correspond to asset amounts t_j_1~t_j_m, random numbers r_j_1~ r_j_m and asset commitment PC(t_j_1,r_j_1)~PC(t_j_m,r_j_m), the cover asset ID_i_1~ID_i_m corresponds to the asset commitment PC{i,1}~PC{i,m}, the transaction payee Q_1~Q_u corresponds to the transfer amount t'_1~t'_u, the random number r'_1~r'_u and the transfer amount commitment PC(t'_1,r'_1)~PC(t'_u,r'_u), u≥1; the linkable ring signature also includes the key image I_(m+1)=r”×Hash_G(P”_j); wherein the transaction execution condition also includes: the key image I_(m+1) does not belong to the historical key image set.

19. The method according to claim 18, wherein the remitter generates intermediate parameters L_j_d, R_j_d, L_j_(m+1), R_j_(m+1) corresponding to the remitter according to its own private key x_j, public key P_j, pseudo private key r", pseudo public key P"_j, public key P_i and pseudo public key P"_i corresponding to the shield party i, and intermediate parameters L_i_d, R_i_d, L_i_(m+1), R_i_(m+1) corresponding to the shield party i, and generates the linkable ring signature according to random numbers and / or their derivative values ​​related to the values ​​of the intermediate parameters L_j_d, R_j_d, L_j_(m+1), R_j_(m+1), L_i_d, R_i_d, L_i_(m+1), R_i_(m+1), d∈[1,m]; verifying the linkable ring signature comprises: According to the random number and / or its derivative value contained in the ring signature, the intermediate parameters L_j_d, R_j_d, L_j_(m+1), R_j_(m+1), L_i_d, R_i_d, L_i_(m+1), and R_i_(m+1) are calculated to verify whether the intermediate parameters L_j_d and L_i_d comply with the ring value rule, whether the intermediate parameters L_j_(m+1) and L_i_(m+1) comply with the ring value rule, whether the intermediate parameters R_j_d and R_i_d comply with the ring value rule, and whether the intermediate parameters R_j_(m+1) and R_i_(m+1) comply with the ring value rule.

20. The method according to claim 19, P_j=x_j×G, G is the base point of the elliptic curve, |G|=p and p is a prime number, 0 <x_j<p; The random number and / or its derivative value contained in the ring signature includes: s_k_1~s_k_(m+1), c_1, k∈[1,n]; The circular value rule between the intermediate parameters L_j_d and L_i_d includes: L_k_d = (s_k_d × G + c_k × P_k) mod p; wherein s_k_d 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 rule between the intermediate parameters L_j_(m+1) and L_i_(m+1) includes: L_k_(m+1) = [s_k_(m+1) × G + c_k × P”_k] mod p; where s_k_(m+1) belongs to the number field Z_q; The ring value rule between the intermediate parameters R_j_d and R_i_d includes: R_k_d = (s_k_d × Hash_G (P_k, ID_k_d) + c_k × I_d) mod p, I_d is included in the ring signature; The ring value rule between the intermediate parameters R_j_(m+1) and R_i_(m+1) includes: R_k_(m+1)=[s_k_(m+1)×Hash_G(P”_k)+c_k×I_(m+1)]mod p, I_(m+1) is included in the ring signature; Among them, when h=1, c_1=Hash(M,L_n_1,R_n_1,…,L_n_(m+1),R_n_(m+1)), and when h∈[2,n], c_k=Hash(M,L_(h-1)_1,R_(h-1)_1,…,L_(h-1)_(m+1),R_(h-1)_(m+1)).

21. The method according to claim 11, further comprising: According to an asset deletion request initiated by the remitter to the blockchain network, at least a portion of the assets spent by the remitter is deleted from the blockchain account book.

22. An anonymous transaction device based on ring signature, comprising: The transaction assembly unit assembles the remittance transaction M according to the to-be-spent assets ID_j_1~ID_j_m in the corresponding account of the remitter and the protected assets ID_i_1~ID_i_m in the corresponding account of the protector i; wherein the to-be-spent assets ID_j_1~ID_j_m and the protected assets ID_i_1~ID_i_m are respectively recorded as asset commitments corresponding to the corresponding asset amounts in the blockchain account book; The signature generation unit generates a linkable ring signature for the remittance transaction M according to the private key x_j and public key P_j held by the remitter and the public key P_i held by the shielding party i, wherein the linkable ring signature includes key images I_1 to I_m, and the values ​​of the key images I_1 to I_m are related to the private key x_j, public key P_j and asset identifiers ID_j_1 to ID_j_m of the remitter; The transaction submission unit submits the signed remittance transaction M to the blockchain network; wherein, after the transaction is completed, the key images I_1~I_m are added to the historical key image set, and the assets to be spent ID_j_1~ID_j_m are maintained and recorded on the blockchain account book as assets held by the remitter.

23. An anonymous transaction device based on ring signature, comprising: The transaction receiving unit receives the remittance transaction M, which is generated by the remitter according to the to-be-spent assets ID_j_1~ID_j_m in its corresponding account and the shielded assets ID_i_1~ID_i_m in the corresponding account of the shielding party i, i∈[1,j-1]∪[j+1,n]; after the transaction is completed, the assets ID_j_1~ID_j_m are recorded as the assets held by the remitter in the blockchain account book; An image acquisition unit, which acquires key images I_1 to I_m contained in the linkable ring signature of the remittance transaction M, wherein the values ​​of the key images I_1 to I_m are related to the private key x_j, the public key P_j and the asset identifiers ID_j_1 to ID_j_m of the remitter; A signature verification unit, which verifies the linkable ring signature, where the linkable ring signature is generated by the remitter according to its own private key x_j, public key P_j and public key P_i held by shielding party i; A transaction execution unit, which executes the remittance transaction M when a transaction execution condition is met; The transaction execution conditions include: the key images I_1~I_m do not belong to the historical key image set and the linkable ring signature passes verification; wherein the key images I_1~I_m are added to the historical key image set after the transaction is completed.

24. 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 10 by running the executable instructions.

25. 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 10.

26. An electronic device comprising: processor; a memory for storing processor-executable instructions; The processor implements the method according to any one of claims 11 to 21 by running the executable instructions.

27. 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 11 to 21.

Images