CN112488703A

CN112488703A - Anonymous transaction method and device based on ring signature

Info

Publication number: CN112488703A
Application number: CN202011265039.8A
Authority: CN
Inventors: 张文彬
Original assignee: Advanced New Technologies Co Ltd
Current assignee: Alibaba Group Holding Ltd; Advanced New Technologies Co Ltd
Priority date: 2019-06-26
Filing date: 2019-06-26
Publication date: 2021-03-12
Also published as: TW202101436A; TWI731569B; CN110335042A; WO2020258832A1; CN110335042B

Abstract

One or more embodiments of the present specification provide an anonymous transaction method and apparatus based on a ring signature, and the method may include: assembling remittance transactions according to assets to be spent in the account corresponding to the remittance party and cover assets in the account corresponding to the cover party; wherein, the assets to be spent and the shield assets are respectively recorded as asset commitments corresponding to the corresponding asset amounts in the block chain account book; generating a linkable ring signature for the remittance transaction according to a private key, a public key and a public key held by a remitter, wherein the linkable ring signature comprises a key mirror image, and the value of the key mirror image is related to the private key, the public key and the asset identification of the remittance; submitting the signed remittance transaction to the blockchain network; wherein, upon completion of the transaction, a key image is added to the set of historical key images and the assets to be spent are kept recorded on the blockchain ledger as assets held by the transferor.

Description

Anonymous transaction method and device based on ring signature

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to an anonymous transaction method and apparatus based on ring signatures.

Background

The block chain technology (also called as distributed book technology) is a decentralized distributed database technology, has the characteristics of decentralization, openness and transparency, no tampering, trustiness and the like, and is suitable for application scenes with high requirements on data reliability.

Disclosure of Invention

In view of the above, one or more embodiments of the present disclosure provide an anonymous transaction method and apparatus based on a ring signature.

To achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:

according to a first aspect of one or more embodiments of the present specification, there is provided an anonymous transaction method based on a ring signature, including:

assembling a remittance transaction M according to assets to be spent ID _ j _ 1-ID _ j _ M in the account corresponding to the remittance party and shield assets ID _ i _ 1-ID _ i _ M in the account corresponding to the shield party i; wherein, the assets to be spent ID _ j _1 to ID _ j _ m and the shield assets ID _ i _1 to ID _ i _ m are respectively recorded as the asset commitments corresponding to the corresponding asset amounts in the block chain ledger;

generating a linkable ring signature for the remittance transaction M according to a private key x _ j, a public key P _ j and a public key P _ I held by a remitter I, wherein the linkable ring signature comprises 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, the public key P _ j and asset identifications ID _ j _1 to ID _ j _ M of the remitter;

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 kept recorded as the assets held by the remitter on the blockchain ledger.

According to a second aspect of one or more embodiments of the present specification, there is provided an anonymous transaction method based on a ring signature, including:

receiving a remittance transaction M generated by a remitter according to the assets to be spent ID _ j _1 to ID _ j _ M in the account corresponding to the remitter and the shield assets ID _ i _1 to ID _ i _ M in the account corresponding to the shield i; after the transaction is completed, the assets ID _ j _ 1-ID _ j _ m are kept recorded as the assets held by the transferor on the blockchain ledger;

key images I _ 1-I _ M contained in a linkable ring signature of the remittance transaction M are obtained, and the values of the key images I _ 1-I _ M are related to a private key x _ j, a public key P _ j and asset identifiers ID _ j _ 1-ID _ j _ M of a remittance party;

verifying the linkable ring signature, wherein the linkable ring signature is generated by the remitter according to a private key x _ j and a public key P _ j held by the remitter and a public key P _ i held by the masker i;

executing the remittance transaction M when a transaction execution condition is satisfied; the transaction execution condition includes: the key images I _ 1-I _ m do not belong to a historical key image set, and the linkable ring signature passes verification; wherein the key images I _1 to I _ m are added to the historical key image set after the transaction is completed.

According to a third aspect of one or more embodiments of the present specification, there is provided an anonymous transaction apparatus based on a ring signature, including:

the transaction assembly unit is used for assembling remittance transactions M according to the assets to be spent ID _ j _ 1-ID _ j _ M in the account corresponding to the remitter and the shield assets ID _ i _ 1-ID _ i _ M in the account corresponding to the shield i; the assets to be spent ID _ j _ 1-ID _ j _ m and the shield assets ID _ i _ 1-ID _ i _ m are respectively recorded as asset commitments corresponding to corresponding asset amounts in a block chain account book, and i belongs to [1, j-1], [ j +1, n ];

the signature generation unit is used for generating a linkable ring signature for the remittance transaction M according to a private key x _ j, a public key P _ j and a public key P _ I held by a remitter I, wherein the linkable ring signature comprises 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, the public key P _ j and asset identifications ID _ j _1 to ID _ j _ M of the remitter;

a transaction submitting unit for 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 kept recorded as the assets held by the remitter on the blockchain ledger.

According to a fourth aspect of one or more embodiments of the present specification, there is provided an anonymous transaction apparatus based on a ring signature, including:

the system comprises a transaction receiving unit, a remittance transaction M and a remittance management unit, wherein the remittance transaction M is generated by assembling a remitter according to assets to be spent ID _ j _ 1-ID _ j _ M in an account corresponding to the remittance, and shield assets ID _ i _ 1-ID _ i _ M in an account corresponding to a shield i, and i belongs to [1, j-1] [ j +1, n ]; after the transaction is completed, the assets ID _ j _ 1-ID _ j _ m are kept recorded as the assets held by the transferor on the blockchain ledger;

a mirror image obtaining unit, for obtaining key mirror images I _ 1-I _ M contained in the linkable ring signature of the remittance transaction M, wherein the values of the key mirror images I _ 1-I _ M are related to a private key x _ j, a public key P _ j and asset identifications ID _ j _ 1-ID _ j _ M of a remittance party;

a signature verification unit that verifies the linkable ring signature generated by the remitter from a private key x _ j and a public key P _ j held by the remitter and a public key P _ i held by the masker i;

a transaction execution unit that executes the remittance transaction M when a transaction execution condition is satisfied; the transaction execution condition includes: the key images I _ 1-I _ m do not belong to a historical key image set, and the linkable ring signature passes verification; wherein the key images I _1 to I _ m are added to the historical key image set after the transaction is completed.

According to a fifth aspect of one or more embodiments herein, there is provided an electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of the first aspect by executing the executable instructions.

According to a sixth aspect of one or more embodiments of the present description, there is provided a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method according to the first aspect.

According to a seventh aspect of one or more embodiments of the present specification, there is provided an electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method according to the second aspect by executing the executable instructions.

According to an eighth aspect of one or more embodiments of the present description, a computer-readable storage medium is proposed, on which computer instructions are stored, which instructions, when executed by a processor, implement the steps of the method according to the second aspect.

Drawings

FIG. 1 is a schematic diagram of an example environment provided by an example embodiment.

FIG. 2 is a schematic diagram of a conceptual architecture provided by an exemplary embodiment.

Fig. 3 is a flowchart of an anonymous transaction method based on a ring signature according to an exemplary embodiment.

FIG. 4 is a schematic diagram of an asset account model provided by an exemplary embodiment.

FIG. 5 is a flowchart of a method of generating a linkable ring signature, according to an example embodiment.

Fig. 6 is a flow chart of another anonymous transaction method based on ring signatures provided by an exemplary embodiment.

FIG. 7 is a flowchart of a method for verifying a linkable ring signature, according to an example embodiment.

Fig. 8 is a schematic structural diagram of an apparatus according to an exemplary embodiment.

Fig. 9 is a block diagram of an anonymous transaction device based on a ring signature according to an exemplary embodiment.

Fig. 10 is a schematic structural diagram of another apparatus provided in an exemplary embodiment.

Fig. 11 is a block diagram of another anonymous transaction device based on a ring signature provided by an example embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like 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 the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.

FIG. 1 is a schematic diagram of an example environment provided by an example embodiment. As shown in fig. 1, the example environment 100 allows entities to participate in a blockchain network 102. The blockchain network 102 may be a public type, a private type, or a federation type of blockchain network. The example environment 100 may include

computing devices

104, 106, 108, 110, 112 and a network 114; in an embodiment, the Network 114 may include a Local Area Network (LAN), Wide Area Network (WAN), the internet, or a combination thereof, and is connected to websites, user devices (e.g., computing devices), and backend systems. In one embodiment, the network 114 may be accessed through wired and/or wireless communication.

In some cases, the

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.

In an embodiment, computing devices 104-108 may run any suitable computing system that enables them to act as nodes in blockchain network 102; for example, the computing devices 104-108 may include, but are not limited to, servers, desktop computers, laptops, tablet computing devices, and smartphones. In an embodiment, the computing devices 104-108 can be affiliated with a related entity and used to implement a corresponding service, which can be used to manage transactions between an entity or entities, for example.

In one embodiment, the computing devices 104-108 respectively store a blockchain ledger corresponding to the blockchain network 102. The computing device 104 may be (or include) a web server for providing browser functionality that may provide visualization information related to the blockchain network 102 based on the network 114. In some cases, the computing device 104 may not participate in the blockchain verification, but rather monitor the blockchain network 102 to determine when other nodes (e.g., which may include the computing device 106 and 108) agree, and generate a corresponding blockchain visualization user interface accordingly.

In an embodiment, computing device 104 may receive a request initiated by a client device (e.g., computing device 110 or computing device 112) for a blockchain visualization user interface. In some cases, the nodes of the blockchain network 102 may also act as client devices, such that a user of the computing device 108 may send the request to the computing device 104 using a browser running on the computing device 108.

In response to the request, computing device 104 may generate a blockchain visualization user interface (e.g., a web page) based on the stored blockchain ledger and send the generated blockchain visualization user interface to the requesting client device. If blockchain network 102 is a private type or a federated type blockchain network, the request for the blockchain visual user interface may include user authorization information, which may be verified by computing device 104 before generating and sending the blockchain visual user interface to the requesting client device, and the corresponding blockchain visual user interface returned after verification.

The blockchain visualization user interface may be displayed on the client device (e.g., as may be displayed in user interface 116 shown in fig. 1). When the blockchain ledger is updated, the display content of the user interface 116 may be updated accordingly. Further, user interaction with user interface 116 may result in requests to other user interfaces, such as a search results page that displays a block list, block details, transaction list, transaction details, account list, account details, contract list, contract details, or results of a user conducting a search of the block chain network, and so forth.

FIG. 2 is a schematic diagram of a conceptual architecture provided by an exemplary embodiment. As shown in fig. 2, the conceptual architecture 200 includes a physical layer 202, a managed services 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 having a respective transaction management system 208.

In an embodiment, managed service layer 204 may include a corresponding interface 210 for each transaction management system 208. For example, each transaction management system 208 communicates with a respective interface 210 over a network (e.g., network 114 in FIG. 1) using a protocol (e.g., Hypertext transfer protocol secure (HTTPS), etc.). In some examples, each interface 210 may provide a communication connection between the respective transaction management system 208 and the blockchain network layer 206; more specifically, the interface 210 may communicate with a blockchain network 212 of the blockchain network layer 206. In some examples, communication between the interface 210 and the blockchain network layer 206 may be implemented using Remote Procedure Calls (RPCs). In some examples, interface 210 may provide transaction management system 208 with an API interface for accessing blockchain network 212.

As described herein, the blockchain network 212 is provided in the form of a peer-to-peer network including a plurality of nodes 214, each of the nodes 214 for persisting a blockchain ledger 216 formed from blockchain data; where only one blockchain ledger 216 is shown in fig. 2, multiple blockchain ledgers 216 or copies thereof may exist in the blockchain network 212, e.g., each node 214 may maintain one blockchain ledger 216 or copy thereof, respectively.

It should be noted that: the transaction (transaction) described in this specification refers to a piece of data that a user creates through a client of a blockchain and needs to be finally published to a distributed database of the blockchain. The transactions in the blockchain are classified into narrow transactions and broad transactions. A narrowly defined transaction refers to a transfer of value issued by a user to a blockchain; for example, in a conventional bitcoin blockchain network, the transaction may be a transfer initiated by the user in the blockchain. The broad transaction refers to a piece of business data with business intention, which is issued to the blockchain by a user; for example, an operator may build a federation chain based on actual business requirements, relying on the federation chain to deploy some other types of online business unrelated to value transfer (e.g., a rental house business, a vehicle dispatching business, an insurance claim settlement business, a credit service, a medical service, etc.), and in such federation chain, the transaction may be a business message or a business request with a business intent issued by a user in the federation chain.

Blockchains are generally divided into three types: public chain (Public Blockchain), Private chain (Private Blockchain) and alliance chain (Consortium Blockchain). In addition, there are various types of combinations, such as private chain + federation chain, federation chain + public chain, and other different combinations. The most decentralized of these is the public chain. The public chain is represented by bitcoin and ether house, and the participators joining the public chain can read the data record on the chain, participate in transaction, compete for accounting right of new blocks, and the like. Furthermore, each participant (i.e., node) is free to join and leave the network and perform related operations. Private chains are the opposite, with the network's write rights controlled by an organization or organization and the data read rights specified by the organization. Briefly, a 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 particular establishment. A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; participants jointly maintain blockchain operation by authorizing to join the network and forming a benefit-related alliance.

Through the distributed architecture adopted by the block chain network and the chain structure adopted by the blocks, the information can be permanently recorded in the block chain account book uniformly maintained by each block chain link point without tampering. However, since the blockchain account book is completely disclosed, information privacy cannot be guaranteed. For example, any user may query the blockchain ledger at any blockchain node for information such as assets held by an account, transfer amounts for a transaction, etc., which may be sensitive and need to be hidden.

For the purpose of privacy protection, in the related art, an anonymous Transaction or Confidential Transaction (Confidential Transaction) scheme based on commitment is proposed, the amount of the assets held by each account, the amount of the transfers involved in the Transaction, and the like can be generated into corresponding commitment amount, and only the commitment amount is recorded in a blockchain account book, but not the amount of the assets, the Transaction amount, and the like in the clear text. For example, when the Pedersen commitment mechanism is adopted, assuming that the original amount is t, the corresponding commitment amount may be PC (t, r) ═ r × G + t × H, where G, H is a randomly generated element on an elliptic curve, r is a random number, and the value of r is only grasped by an account holder, a transaction participant, and the like, so that an irrelevant person cannot reversely deduce the original amount t only from the value of PC (t, r). Meanwhile, the commitment amount also has homomorphic characteristics, so that the commitment amount can directly participate in calculation, such as PC (t1, r1) -PC (t2, r2) -PC (t1-t2, r1-r 2). However, when verifying the transaction, the block nodes cannot determine whether the related conditions are met according to the commitment amount, for example, the remittance amount of the transaction is equal to the remittance amount or other conditions, and provide the related certification information is needed to ensure that the transaction is successfully completed.

In addition, the user needs a signature when initiating a transaction in the blockchain network. For example, when user A wishes to spend an asset that user A holds in the blockchain, a blockchain transaction may be initiated and signed with private key x _ j that user A holds. Correspondingly, the signature can be verified through the public key P _ j corresponding to the private key x _ j held by the user a. However, direct verification of the signature also exposes user a to the signer of the corresponding signature, resulting in privacy disclosure of user a.

For the purpose of protecting the identity of a signer, a processing scheme based on a ring signature is proposed in the related art, and a user a can hide a public key P _ j held by the user a in a set of public keys (P _1, … …, P _ n), wherein the public keys P _1 to P _ j-1 and P _ j +1 to P _ n belong to other users respectively; then, the user a generates a signature by using the private key x _ j owned by the user a and the set of public keys (P _1, … …, P _ n), so that the verifier can verify that the signature is generated by the private key corresponding to one of the public keys (P _1, … …, P _ n), but cannot determine which public key is specific, thereby hiding the identity of the signer by using the set of public keys (P _1, … …, P _ n).

It can be understood that: when the above is described as the form of (P _1, … …, P _ n), although it seems to be a set of public keys starting from P _1 and ending at P _ n, it is actually impossible for the verifier to determine the order between the respective public keys, so that the set of public keys is equivalent to presenting an endless ring structure to the verifier, and is therefore referred to as a ring signature.

Although the ring signature scheme can hide the identity of the signing party, the ring signature scheme can cause a 'double-flower' problem when applied to a transaction scenario of a block chain network. For example, a blockchain network may employ a UTXO (Unspent Transaction Output) model for asset management: blockchain assets held by the user are each recorded as an output of a respective transaction, each transaction having as its input one or more unspent transaction outputs, and one or more outputs are generated accordingly. Typically, UTXO is used in bitcoin and its derivative cryptocurrency. When the ring signature scheme is applied to the block chain network based on the UTXO model, the same asset may be referenced by multiple transactions respectively, but since the identity of the signer is hidden by the ring signature scheme, the verifier cannot check that the same asset is repeatedly referenced, thereby causing a "double-blossom" problem.

Therefore, an improvement scheme of the above ring Signature scheme, called a Linkable ring Signature (LSAG), is proposed in the related art, which can generate a key-image (key image) for marking a signing party, but does not expose a public key corresponding to the signing party in a set of ring signatures used by the signing party, so as to ensure identity hiding of the signing party and solve the problem of "double flowers" based on the key-image.

Take Menlo Currency (Monero) as an example. The Menluo currency adopts a UTXO (un-spent Transaction Output) model to realize asset management, all assets under the model are Transaction Output of corresponding blockchain transactions, all assets generated on a blockchain network are uniformly managed, each asset has a unique corresponding public and private key pair, and a user can spend corresponding assets through the held public and private key pairs. For example, when an asset held by a signer (e.g., a transferor in a money transfer transaction) corresponds to a private key x _ j and a public key P _ j, a corresponding key-image may be generated according to the formula I x _ j × Hash (P _ j), and as long as the asset is previously spent, the block link points record the key-image with the same value, so as to identify a "double flower" problem accordingly.

However, each asset has a unique corresponding public and private key pair, so that a plurality of sets of corresponding public and private key pairs are required in a case that a transaction includes a plurality of assets, for example, when a transaction includes m assets, a signing party needs to maintain m sets of public and private key pairs, which greatly causes the maintenance cost of the public and private key pairs.

For this reason, the present specification proposes a new technical solution, so that a signing party only needs to maintain a set of public and private key pairs to generate a linkable ring signature for a transaction involving multiple assets, and can meet the requirement of a confidential transaction for certification information, which will be described below with reference to the embodiments.

Fig. 3 is a flowchart of an anonymous transaction method based on a ring signature according to an exemplary embodiment. As shown in fig. 3, the method applied to the client device may include the following steps:

step 302, assembling remittance transaction M according to assets to be spent ID _ j _1 to ID _ j _ M in the account corresponding to the remittance party and shield assets ID _ i _1 to ID _ i _ M in the account corresponding to the shield party i; the assets to be spent ID _ j _1 to ID _ j _ m and the cover assets ID _ i _1 to ID _ i _ m are respectively recorded as the asset commitments corresponding to the corresponding asset amounts in the block chain ledger.

As previously described, the assets held by the transferor and any other user are recorded on the blockchain ledger as corresponding commitment amounts rather than as plain text asset amounts for the purpose of keeping the assets kept secret. Taking the assets to be spent ID _ j _ 1-ID _ j _ m as examples, and taking the ID _ j _ 1-ID _ j _ m as asset identifications to be used for distinguishing different assets; assuming that the asset amounts of the assets to be spent ID _ j _1 to ID _ j _ m are t _ j _1 to t _ j _ m, the blockchain ledger can record the asset commitments PC (t _ j _1, r _ j _1) to PC (t _ j _ m, r _ j _ m) corresponding to the asset amounts t _ j _1 to t _ j _ m, and r _ j _1 to r _ j _ m are random numbers. Due to the existence of the random numbers r _ j _1 to r _ j _ m, the asset commitments PC (t _ j _1, r _ j _1) to PC (t _ j _ m, r _ j _ m) generated by the amounts t _ j _1 to t _ j _ m have randomness, and except for the transferor who grasps the random numbers r _ j _1 to r _ j _ m, other users can only see the asset commitments PC (t _ j _1, r _ j _1) to PC (t _ j _ m, r _ j _ m) and cannot reversely deduce the corresponding asset amounts t _ j _1 to t _ j _ m.

Similarly, for the shield assets ID _ i _1 to ID _ i _ m, the ID _ i _1 to ID _ i _ m are asset identifications for distinguishing different assets; assuming that the asset amounts of the shield assets ID _ i _1 to ID _ i _ m are t _ i _1 to t _ i _ m, the blockchain ledger can record asset commitments PC (t _ i _1, r _ i _1) to PC (t _ i _ m, r _ i _ m) corresponding to the asset amounts t _ i _1 to t _ i _ m, wherein r _ i _1 to r _ i _ m are random numbers. For example, the shielding side 1 holds the shielding assets ID _1_1 to ID _1_ m, and the corresponding assets amount is t _1_1 to t _1_ m, then the blockchain ledger can record the asset commitments PC (t _1_1, r _1_1) to PC (t _1_ m, r _1_ m) corresponding to the assets amounts t _1_1 to t _1_ m, and r _1_1 to r _1_ m are random numbers held by the shielding side 1 only.

For example, the blockchain ledger may record and store assets in a form similar to [ identification, asset commitment ]. For example, the above-mentioned assets to be spent ID _ j _1 to 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 shield assets ID _ i _1 to ID _ i _ m corresponding to the shield i can be recorded as [ ID _ i _1, PC { i,1} ] [ ID _ i _ m, PC { i, m } ]. Of course, this is merely an example, and the blockchain ledger may actually take other forms. For example, when there are multiple asset types, the assets may be recorded and stored in a form similar to [ type, identification, asset commitment ], and then the influence of the asset types, such as scaling of asset amounts between different types of assets, etc., may be considered in calculating asset amounts, performing transactions, etc. Moreover, in addition to directly recording "asset commitments," other information may also be stored at the same time; taking the asset ID _ j _ m to be spent as an example, the asset ID _ j _ m may 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 homomorphic ciphertexts corresponding to the asset amount t _ j _ m and the random number r _ j _ m, respectively, and can be obtained by encrypting the asset amount t _ j _ m and the random number r _ j _ m by a homomorphic encryption public key (obtained by homomorphic encryption of the public key P _ j) of the remitter. For ease of understanding, the following is illustrated in the form of an asset [ identification, asset commitment ].

As mentioned above, the present specification manages assets held by a user in the form of "accounts", for example, an asset management model based on the form of "accounts", i.e., an asset account model, can be realized by referring to the UTXO model and an account model used in the related art, such as an etherhouse. The asset account model may generate a corresponding account for each user, and manage assets held by the users based on the accounts. For example, fig. 4 is a schematic diagram of an asset account model according to an exemplary embodiment, and fig. 4 shows the account a _ j corresponding to the transferor. Unlike the account model described above, the account a _ j does not directly record the account balance of the transferor, but records assets held by the transferor, such as assets [ ID _ j _1, PC (t _ j _1, r _ j _1) ], [ ID _ j _2, PC (t _ j _2, r _ j _2) ], and the like, which can be clearly distinguished by corresponding asset identifiers. Each Account has a unique corresponding Account address (Account ID), and different accounts can be distinguished according to the Account address. Meanwhile, the information of all accounts is recorded on the block chain account book, so that the assets contained in each account can be obtained by inquiring the block chain account book; of course, since the asset amount is recorded as the corresponding commitment amount on the blockchain account book, the asset holding condition of the user is not exposed, and the privacy of the user can be protected.

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 transaction outputs for corresponding historical transactions, such as the assets to be spent ID _ j _1 to ID _ j _ m being transaction outputs formed from historical transactions in which the transferor previously participated and the transferor being in the role of "recipient" in these transactions, such as the cover assets ID _ i _1 to ID _ i _ m being transaction outputs formed from historical transactions in which the protecter i previously participated and the protecter i being in the role of "recipient" 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 portion of the account balance to form assets with a certain asset amount, such as assets ID _ j _1 to ID _ j _ m to be spent divided from the account balance corresponding to the transferor, and cover assets ID _ i _1 to ID _ i _ m divided from the account balance corresponding to the cover i. For the case where the assets are generated by dividing the account balance, all the asset balances may be divided into corresponding assets for management, or some account balances may be divided into assets and the remaining account balances may still be maintained in the form of a value (this value is not shown in fig. 4).

Of all the assets within the remitter's corresponding account, the assets ID _ j _1 to ID _ j _ m to be spent may be any assets held by the remitter. Of course, in actually selecting the assets to be spent, it is also necessary to refer to the amount of money to be transferred in the money transfer transaction M and to ensure that the sum of the amounts of the assets to be spent is not less than the amount of money to be transferred. The money amount is the amount that the transferor needs to transfer to each actual transferee, and the amounts are determined by the transferor and each actual transferee in advance, or determined by the transferor.

The money input point of the money transfer transaction M is related to the roles of the transferor and the shelterer, and the money output point is related to the roles of the actual transferee and the transaction transferee. Among these roles, there may be some overlap between some roles.

For the transferor and the shield, the money transfer transaction M is assembled from the assets to be spent ID _ j _1 to ID _ j _ M in the transferor's corresponding account and the shield assets ID _ i _1 to ID _ i _ M in the shield's i corresponding account, plus the linkable ring signature generated below, so that the shield i can conceal the identity of the transferor so that other users cannot determine which user in the transferor and shield i pays the asset. Here, the sheltering party may include any user other than the transferor, for example, the sheltering party may include the actual transferee of the money transfer transaction M, for example, when the transferor is user a, the actual transferee is user B and user C, by configuring user B and user C as the sheltering party, not only user B and user C may be concealed from the identity of user a, but also user B and user C may be even more puzzled because both user B and user C belong to the "transaction transferor" and the "transaction transferee". For another example, the sheltering party may include other users that are distinct from the transferor and the actual transferee, such as when the transferor is user a, the actual transferee is user B and user C, and unrelated user D may be configured as a sheltering party for identity hiding from user a. For another example, the masker may include both the actual transferee and other users, such as when the transferor is user a, the actual transferee is user B and user C, and user B, user C and user D may be configured as a masker for identity hiding from user a.

For the actual payee and transaction payee: in one embodiment, the transaction payee may be an actual payee, and the sum of the asset amounts t _ j _1 to t _ j _ m corresponding to the assets to be spent ID _ j _1 to ID _ j _ m is just equal to the sum of the transfer amounts corresponding to the actual payees, that is, no change is made. In another embodiment, the transaction recipient may include a transferor in addition to the actual recipient, where two scenarios may exist: in one case, the sender is not set as a transaction receiver on purpose, but because the sum of the asset amounts t _ j _1 to t _ j _ m corresponding to the assets to be spent ID _ j _1 to ID _ j _ m is greater than the sum of the transfer amounts corresponding to the actual receivers, change is required to be returned to the sender, and the change amount (i.e., the transfer amount corresponding to the sender) is the difference between the sum of the asset amounts t _ j _1 to t _ j _ m and the sum of the transfer amounts; in another case, although there is no change, the transferor may be set as a transaction receiver, so that the transferor may have a certain shielding effect on the actual receiver, and at this time, the transfer amount corresponding to the transferor may be set to 0, so as to avoid affecting the original transfer operation. In yet another embodiment, the transaction recipient may include a shield distinct from the actual recipient and the sender, the shield effecting identity hiding from the actual recipient, and the shield corresponding to a transfer amount of 0; of course, in addition to the masker, the transaction recipient may also include a transferor: when the zero finding does not exist, the transfer amount corresponding to the sender and the shelter is 0; when the zero finding exists, the transfer amount corresponding to the sender is the zero finding amount, and the transfer amount corresponding to the shield party is 0.

According to the actual situation, the identity of the remitter can be hidden only by the shield, and the identity of the actual remitter can be further hidden. In one embodiment, the participants of the money transfer transaction M may include a transferor, an actual transferee and a shield distinguished from the transferor, the users constitute n participants, and the n participants all participate in the money transfer and the money transfer of the money transfer transaction at the same time, thereby hiding the identity of the transferor and the actual transferee at the same time. Moreover, since each participant participates in the remittance and the collection at the same time, identity confusion between the remitter and the actual collector can be realized, thereby further increasing the reliability of identity hiding.

Suppose the transaction recipients of the remittance transaction M are Q _1 to Q _ u, and the corresponding transfer amounts are t '_ 1 to t' _ u, respectively, wherein u is greater than or equal to 1 and less than or equal to n. In the remittance transaction M, the transfer amounts t '_ 1 to t' _ u are recorded as corresponding transfer amount commitments PC (t '_ 1, r' _1) to PC (t '_ u, r' _ u), respectively, in the remittance transaction M similarly to the asset amounts t _ j _1 to t _ j _ M corresponding to the aforementioned assets to be spent, with r '_ 1 to r' _ u being random numbers. The random numbers r '1 to r' u may be determined by the transferor and notified to the corresponding transferee through, for example, a downlink channel (usually only the actual transferee needs to be notified), so that each transferee can verify based on the random numbers r '1 to r' u, for example, the transferee w can verify whether PC (t 'w, r' w) ═ t 'w × G + r' w × H is established, and manage the assets corresponding to the transfer amount acceptance PC (t 'w, r' w) after the transaction is completed.

In the confidential transaction, it is required to prove that the transfer amounts t '_ 1 to t' _ u in the remittance transaction M are not less than 0. The transferor may utilize zero knowledge proof techniques in the related art to generate corresponding range certificates RP _1 to RP _ u for the transfer amounts t '_ 1 to t' _ u, respectively, to certify that t '_ 1 ≧ 0 to t' _ u ≧ 0, and add these range certificates RP _1 to RP _ u to the transaction contents of the remittance transaction M. The zero-knowledge Proof technique may be a Range Proof (Range Proof) technique, such as the bulletprofs scheme, and the like, which is not limited in this specification.

Step 304, according to the private key x _ j, the public key P _ j and the public key P _ I held by the remitter I, a linkable ring signature is generated for the remittance transaction M, wherein the linkable ring signature includes key images I _1 to I _ M, and 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 identifications ID _ j _1 to ID _ j _ M of the remittance.

The transferor needs to maintain a set of public-private key pairs, such as private key x _ j and public key P _ j. Before determining the set of public and private key pairs, a number domain Z _ q and an elliptic curve in the number domain, such as an elliptic curve Ed25519 and the like, are determined G, H as two random generators of the elliptic curve, where | G | ═ P is a large prime number (e.g., not less than a preset value), and a private key x _ j of the remitter is selected from a value range (0, P), and a corresponding public key P _ j ═ x _ j × G is selected. For other users such as a shield side and the like, the unique corresponding public and private key pair is determined in a similar manner.

The key images I _1 to I _ m are in one-to-one correspondence with the assets to be spent ID _ j _1 to ID _ j _ m provided by the transferor, and are respectively used for verifying whether the corresponding assets to be spent are spent or not, thereby solving the problem of 'double flowers'. Because the values of the key images I _ 1-I _ m are related to the asset identifications ID _ j _ 1-ID _ j _ m of the corresponding assets, even if all the key images adopt the same set of public and private key pairs (namely, a private key x _ j and a public key P _ j of a remitter), the generated key images I _ 1-I _ m can be ensured to be completely different based on the value difference between the asset identifications ID _ j _ 1-ID _ j _ m, so that a set of public and private key pairs does not need to be maintained for each asset, and the quantity of the public and private key pairs required to be maintained by each account is unrelated to the quantity of the assets contained in the transaction while the problem of 'double-pattern' is solved. 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 elliptic curve to itself.

According to the asset commitments PC (t _ j _1, r _ j _1) to PC (t _ j _ m, r _ j _ m) corresponding to the assets to be spent, and the aforementioned transfer amount commitments PC (t '_ 1, r' _1) to PC (t '_ u, r' _ u), P "_ j ═ can be calculated [ 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 random numbers r _ j _1 to r _ j _ m corresponding to assets to be spent and random numbers r '_1to r' u corresponding to transfer amounts, r ″ (r _ j _1+ ·+ r _ j _ m) - (r '1 + ·+ r' _ u) can be obtained through calculation; and calculating t ' - (t _ j _1+ … + t _ j _ m) - (t ' _1+ … + t ' _ u) according to the asset amount t _ j _ 1-t _ j _ m and the transfer amount t ' _ 1-t ' _ u corresponding to the assets to be spent. Then, as in the homomorphic characteristic described above, P "_ j ═ PC (r", t ") ═ r" × G + t "× H may be determined. Also, since the transferor needs to ensure that t _ j _1+ … + t _ j _ m is t '_ 1+ … + t' _ u so that t ″ -is 0, P "_ j ═ r ″ × G can be determined.

Then, it can be seen that the relationship "P _ j ═ r" × G "between the above-mentioned" P "_ j ≠ r" × G "and the public-private key pair is similar in form, and as described below, the masker i must satisfy P" _ i ≠ r "× G, and thus r" can be regarded as one kind of private key corresponding to the remitter and P "_ j as the public key corresponding to r", and r "can be regarded as the pseudo private key corresponding to the remitter and P" _ j as the pseudo public key corresponding to the remitter in order to distinguish from the public-private key pair corresponding to the remitter. Similarly, P "_ i can be considered as a pseudo public key corresponding to the masker i; for example, a 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 ] corresponding to the shield i may be calculated. Meanwhile, a difference t '_ i between the sum of the asset amounts corresponding to m assets held by the shielding party i and the sum of the transfer amounts t' _1 to t '_ u can be calculated, and a difference r' _ i between the sum of random numbers corresponding to m assets held by the shielding party i and the sum of random numbers r '_ 1 to r' _ u corresponding to the transfer amounts t '_ 1 to t' _ u can be calculated.

P "_ i ═ r" _ i × G + t "_ i × H ≠ r" × G may be determined based on homomorphic characteristics. It can be seen that the parameters P "_ j and r" each uniquely correspond to a transferor, the parameter P "_ i uniquely corresponds to a masker i, and thus r" can be considered a pseudo-private key corresponding to the transferor, P "_ j can be considered a pseudo-public key corresponding to the transferor, and P" _ i can be considered a pseudo-public key corresponding to the masker i.

Generating a linkable ring signature for the remittance transaction M according to a private key x _ j, a public key P _ j, a pseudo private key r ' and a pseudo public key P ' _ j corresponding to the remittance party and a public key P _ i and a pseudo public key P ' _ i corresponding to the shielding party i, and efficiently and compactly realizing the verification functions in the following two aspects: on the one hand, since P "_ j ═ r" × G is satisfied between the pseudo public key P "_ j and the pseudo private key r", and P "_ i ≠ r" × G is satisfied between the pseudo public key P "_ i and the pseudo private key r", when a linkable ring signature is generated from the pseudo private key r ", the pseudo public keys P" _ j and P "_ i, if the linkable ring signature is verified, it can be proved that a value of a certain public key pseudo in the pseudo public keys (P" _1, … …, P "_ n) is equal to r" × G, and the pseudo public key corresponds to the aforementioned t "_ 0, so that the input and output of the remittance transaction M can be equalized; on the other hand, when the linkable ring signature is generated according to the private key x _ j and the public key P _ j corresponding to the transferor and the public key P _ i corresponding to the shelterer i, if the linkable ring signature passes the verification, the linkable ring signature can be proved to be signed by the private key corresponding to one of the public keys (P _1, … …, P _ n), so that the identity verification is completed on the premise of not exposing the identity of the transferor. Of course, without considering the verification of whether the input and output of the remittance transaction M are equal, the linkable ring signature may be generated directly according to the private key x _ j and the public key P _ j corresponding to the remitter and the public key P _ i corresponding to the masker 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 masker i, which is not limited in this specification.

In addition to the key images I _1 to I _ m described above, the transferor may generate the key image I _ (m +1) ═ r "× Hash _ G (P" _ j) from the pseudo private key r "and the pseudo public key P" _ j, thereby forming m +1 key images in total with the key images I _1 to I _ m, which are used together to solve the "double-flower" problem. In fact, since the values of the pseudo private key r "and the pseudo public key P" _ j are random, so that the pseudo private key r "and the pseudo public key P" _ j generated by different transactions are different, when the key image I _ (M +1) is generated according to the pseudo private key r "and the pseudo public key P" _ j, a one-to-one correspondence relationship can be formed between the key image I _ (M +1) and the corresponding transaction, and therefore, by comparing the key image I _ (M +1) with the historical key image, a replay (replay) problem for the remittance transaction M is identified: if the same historical key image exists for key image I _ (M +1), then replay of money transfer transaction M is indicated.

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 kept recorded as the assets held by the remitter on the blockchain ledger.

After receiving the remittance transaction M, the blockchain node may compare the key images I _1 to I _ M with the historical key image set to determine whether a historical key image identical to the key images I _1 to I _ M exists in the historical key image set. The historical key image set is used to store key images corresponding to assets that have been previously spent. If there is a historical key image that is the same as one of the key images I _ 1-I _ M, indicating that the asset to which the key image corresponds has been spent, i.e., a "double flower" problem has occurred, the performance of the money transfer transaction M should be prevented. If the key images I _ 1-I _ M do not belong to the historical key image set, the assets ID _ j _ 1-ID _ j _ M corresponding to the key images I _ 1-I _ M are not spent, and the remittance transaction M can be executed under the condition that other transaction execution conditions are met; moreover, when the money transfer transaction M is completed, the assets ID _ j _1 to ID _ j _ M corresponding to the key images I _1 to I _ M are all spent, so that the key images I _1 to I _ M need to be added to the historical key image set for subsequent detection of the "double flower" problem associated with the key images I _1 to I _ M.

In an account model such as that employed in an ethernet house, when a remitter spends an amount of money through a transaction, the account balance in the corresponding account is updated, i.e., the amount of money spent is deducted, thereby ensuring the accuracy of the account balance. However, in the technical solution of the present specification, after the remittance transaction M is completed, although the assets ID _ j _1 to ID _ j _ M in the account corresponding to the remitter are spent, the account corresponding to the remitter is not updated immediately, that is, the assets ID _ j _1 to ID _ j _ M in the account corresponding to the remitter do not need to be deleted immediately, so that when any user queries the account corresponding to the remitter through the blockchain account book, the remittance transaction M is not aware of the asset change after the remittance transaction M is completed, and the true identity assumed by the remittance party in the remittance transaction M is prevented from being exposed based on the asset change. Meanwhile, although the remitter contains both spent and unspent assets in the corresponding account, based on the maintenance of the above-described mirror collection of historical keys, it is possible to ensure that the remitter can actually only spend the unspent assets and accurately detect the "double-flower" operation performed by the remitter on the spent assets.

Of course, in order to avoid excessive assets accumulated in the account and increase the maintenance cost of the block chain node, it is also convenient for each user to manage the assets in the account, and the user can clean the spent assets in the account. Taking the transferor as an example above, the transferor may initiate an asset deletion request to the blockchain network to delete from the blockchain ledger at least a portion of the assets that have been expended by the transferor; for example, the transferor may specify an asset identification corresponding to the asset that needs to be deleted, or the transferor may specify a time period (may specify both endpoints of the time period; if only the left endpoint is specified, the time period is from the time the left endpoint corresponds to the time so far; if only the right endpoint is specified, the time period is from the account creation to the time the right endpoint corresponds to the time) and delete all assets generated or spent within the time period.

Based on the above description, the remittance transaction M generated by the transferor may include the following transaction contents:

1) transferor, shelters 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 ] }, wherein P _1 to P _ n are public keys of the remitter and the shield, respectively, such as a public key P _ j corresponding to the remitter, and a public key P _ i corresponding to the shield i, i ∈ [1, j-1] [ j +1, n ].

2) Transaction payee and transfer amount: { [ Q _1, PC (t '_ 1, r' _1) ], [ Q _2, PC (t '_ 2, r' _2) ], …, [ Q _ u, PC (t '_ u, r' _ u) ] }.

3) The ranges prove RP _1 to RP _ u.

Of course, the money transfer transaction M may also include other transaction contents required in the blockchain network, and reference may be made to the related requirements in the related art, which are not listed here.

The transferor may then hash the transaction contents of the money transfer transaction M, and the parameter M may characterize the calculated hash value, and the transferor may generate a linkable ring signature for the hash value M. Of course, the transferor may also generate a linkable ring signature directly for the entire transaction content, which may result in a relatively greater amount of computation.

The following describes, with reference to fig. 5, a process of generating a linkable ring signature for the remittance transaction M according to the private key x _ j, the public key P _ j, the pseudo private key r ", and the pseudo public key P" _ j corresponding to the remitter, and the public key P _ i and the pseudo public key P "_ i corresponding to the shield i; FIG. 5, among other things, is a flow diagram for generating a linkable ring signature provided by an exemplary embodiment. As shown in fig. 5, the following steps may be included:

step 502, key images I _1 to I _ (m +1) are generated.

The process of generating the key images I _1 to I _ (m +1) can refer to the foregoing description, and will not be described herein again.

Wherein I _ d is x _ j × Hash _ G (P _ j, ID _ j _ d), d ∈ [1, m ]; i _ (m +1) ═ r "× Hash _ G (P" _ j).

In step 504a, intermediate parameters L _ j _ d and R _ j _ d are calculated.

The transferor may select a random number a _ d (i.e., a _ 1-a _ m) from the number field Z _ q and calculate intermediate parameters L _ j _ d, R _ j _ d according to the following equations:

L_j_d＝a_d×G

R_j_d＝a_d×Hash_G(P_j,ID_j_d)

thus, the transferor may calculate L _ j _ d: l _ j _1 to L _ j _ m, and R _ j _ d: r _ j _1 to R _ j _ m.

Further, the transferor may generate intermediate parameters L _ i _ d, R _ i _ d corresponding to the masker i, including: according to the values of the intermediate parameters L _ j _ d and R _ j _ d, the intermediate parameters L _ i _ d and R _ i _ d are respectively generated, which will be described in the following steps 506 to 510.

In step 504b, the intermediate parameters L _ j _ (m +1), R _ j _ (m +1) are calculated.

The transferor may select a random number a _ (m +1) from the number field Z _ q and calculate intermediate parameters L _ j _ (m +1), R _ j _ (m +1) according to the following equations:

L_j_(m+1)＝a_(m+1)×G

R_j_(m+1)＝a_(m+1)×Hash_G(P”_j)

thus, the transferor may calculate L _ j _ (m +1) and R _ j _ (m + 1). Further, the transferor may generate intermediate parameters L _ i _ (m +1), R _ i _ (m +1) corresponding to the masker i, as will be described in steps 506-510 below.

Step 506, calculating 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), R _ (j +1) _ (m +1) -R _ n _ (m + 1).

When i is j +1 to n, the intermediate parameters L _ i _ d and R _ i _ d are calculated according to the following equations:

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

meanwhile, the calculation process of the intermediate parameters L _ i _ (m +1) and R _ i _ (m +1) conforms to the following formula:

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

in the calculation process, s _ (j +1) _ d to s _ n _ d, s _ (j +1) _ (m +1) to s _ n _ (m +1) are all random numbers in the number field Z _ q. And 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 elliptic curve described above onto the data Z _ q.

In step 504a-b, when L _ j _ d, R _ j _ d, L _ j _ (m +1), R _ j _ (m +1) have been calculated, the intermediate parameters L _ i _ d, R _ i _ d, i e, L _ (j +1) _ d to L _ n _ d, R _ (j +1) _ d to R _ n _ d, are calculated based on L _ j _ d, R _ j _ d to obtain i e [ j +1, n ]. Specifically, first, according to values of L _ j _ d, R _ j _ d, L _ j _ d (M +1), and R _ j _1, c _ j _1 is calculated to be Hash [ M, L _ j _1, R _ j _1, … …, L _ j _1, R _ j _1 (M +1) ], and according to a random number s _ j + 1_ d and the calculated c _ j +1, L _ j + 1_ d, R _ j + 1_ d are calculated, that is: calculating L _ (j +1) _1 and R _ (j +1) _1 according to the random number s _ (j +1) _1 and the c _ (j +1) obtained through calculation, calculating L _ (j +1) _2, R _ (j +1) _2 and … … according to the random number s _ (j +1) _2 and the c _ (j +1) obtained through calculation, and calculating L _ (j +1) _ m and R _ (j +1) _ m according to the random number s _ (j +1) _ m and the c _ (j +1) obtained through calculation; then, calculating to obtain c (j +2) according to the values of L (j +1) d and R (j +1) d, and calculating 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 the like until L _ n _ d and R _ n _ d are obtained through calculation.

Similarly, according to 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), R _ (j +1) _ (m +1) -R _ n _ (m +1) can be calculated according to the above formula, which is not described herein again.

In step 508, the intermediate parameters L _1_ d, R _1_ d, L _1_ (m +1), and R _1_ (m +1) are calculated.

The calculation process of the intermediate parameters L _1_ d and R _1_ d conforms to the following formula:

L_1_d＝(s_1_d×G+c_1×P_1)mod p

R_1_d＝(s_1_d×Hash_G(P_1,ID_1_d)+c_1×I_d)mod p

the intermediate parameters L _1_ (m +1), R _1_ (m +1) are calculated according to the following formula:

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

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

wherein s _1_ d and s _1_ (M +1) are both random numbers in the number domain Z _ q, 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 annular value-taking 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 convenience of description, however, L _1_ d, R _1_ d, L _1_ (m +1), and R _1_ (m +1) are not arranged at the first position, and L _ n _ d, R _ n _ d, L _ n _ (m +1), and R _ n _ (m +1) are not arranged at the last position, and it should be considered that L _1_ d is adjacent to L _ n _ d, R _1_ d is adjacent to R _ n _ d, L _1_ (m +1) is adjacent to L _ n _ (m +1), and R _1_ (m +1) is adjacent to R _ n _ (m + 1). Therefore, when c _1 is Hash [ M, L _ n _1, R _ n _1, … …, L _ n _1, R _ n _1 (M +1) ], it substantially conforms to the above-described c _ i ═ Hash [ M, L _1 (i-1) _1, R _ (i-1) _1, … …, L _ (i-1) _1 (M +1), R _ (i-1) _ M +1) ], i.e., c _1 is consistent with the calculation formulas for c _ (j +1) -c _ n.

Step 510, calculating 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), R _2_ (m +1) -R _ (j-1) _ (m + 1).

When i is 2 to j-1, the intermediate parameters L _ i _ d and R _ i _ d are calculated according to the following formulas:

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

in the calculation process, s _2_ d to s _ (j-1) _ d, s _2_ (m +1) to s _ (j-1) _ (m +1) are all random numbers in a number field Z _ q. And c _2 to c _ (j-1) in the calculation process, wherein 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)).

Therefore, in the case that 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, i.e., L _2_ d to L _ (j-1) _ d, and R _2_ d to R _ (j-1) _ d described above, can be calculated based on L _1_ d, R _1_ d, L _1_ (m +1), and R _1_ (m +1) to obtain i ∈ [2, j-1 ]. Specifically, firstly, c _2 is obtained by calculation according to 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 a random number s _2_ d and the calculated c _2, that is: calculating L _2_1 and R _2_1 according to the random number s _2_1 and the calculated c _2, calculating L _2_2 and R _2_2 and … … according to the random number s _2_2 and the calculated c _2, and calculating L _2_ m and R _2_ m according to the random number s _2_ m and the calculated c _ 2; then, c _3 is obtained through calculation 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 c _3 obtained through calculation; and the rest is done in the same way until L (j-1) d and R (j-1) d are obtained through calculation.

Similarly, according to 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), R _2_ (m +1) -R _ (j-1) _ (m +1) can be calculated according to the aforementioned formulas, which are not described herein again.

At step 512, a ring signature is generated.

Based on the processing procedure of the above steps, key images I _1, … …, I _ (m +1), c _1, s _1_ d to s _ (j-1) _ d, s _ (j +1) _ d to s _ n _ d, s _1_ (m +1) -s _ (j-1) _ m +1), s _ (j +1) _ (m +1) -s _ n _ (m +1) can be obtained, and the required signature party of s _ j _ d, s _ j _ (m +1) is calculated according to the following formula:

s_j_d＝(a_d-c_j×x_j)mod p

s_j_(m+1)＝(a_(m+1)-c_j×r”)mod p

although the value of c _ j is divided into 2 cases in the above formula, firstly, the value of the parameter j is actually fixed, for example, the value of the parameter j is fixed to 1 or to a certain value in [2, n ], which should be distinguished from the above parameters i and e (n-1 values exist in the parameter i, which are respectively 1 to j-1 and j +1 to n, and m values exist in the parameter e, which are respectively 1 to m); meanwhile, similar to the above description of c _1: since the intermediate parameters conform to the annular value-taking 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 convenience of description, however, L _1_ d, R _1_ d, L _1_ (m +1), and R _1_ (m +1) are not arranged at the first position, and L _ n _ d, R _ n _ d, L _ n _ (m +1), and R _ n _ (m +1) are not arranged at the last position, and it should be considered that L _1_ d is adjacent to L _ n _ d, R _1_ d is adjacent to R _ n _ d, L _1_ (m +1) is adjacent to L _ n _ (m +1), and R _1_ (m +1) is adjacent to R _ n _ (m + 1). Therefore, when c _1 is Hash (M, L _ n _1, R _ n _1, … …, L _ n _1, R _ n _1, (M +1)), it is also true that c _ j is Hash (M, L _1) (j-1) _1, R _1 (j-1) _1, … …, L _1 (j-1) _ (M +1), R _1 (j-1) _ (M + 1)).

Thus, the transferor may 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 includes key images I _1 to I _ (m +1), random numbers s _ I _1 to s _ I _ (m +1), derivative values s _ j _1 to s _ j _ (m +1), and c _ 1.

Fig. 6 is a flow chart of another anonymous transaction method based on ring signatures provided by an exemplary embodiment. As shown in fig. 6, the method applied to the blockchain node, verifying the linkable ring signature generated in the embodiment of fig. 3 by the blockchain node, and performing other necessary verification operations on the money transfer transaction M, may include the steps of:

step 602, receiving a remittance transaction M generated by a remitter according to the assets to be spent ID _ j _1 to ID _ j _ M in the account corresponding to the remitter and the shield assets ID _ i _1 to ID _ i _ M in the account corresponding to the shield i; after the transaction is completed, the assets ID _ j _ 1-ID _ j _ m are kept recorded on the blockchain ledger as assets held by the transferor.

As mentioned above, the present specification manages assets held by the user in the form of "account", and reference may be made to the foregoing description in conjunction with fig. 4, which is not described herein again. In summary, based on the asset account model in this specification, a corresponding account may be generated for each user, and assets held by the user may be managed based on the account.

In an account model such as that employed in an ethernet house, when a remitter spends an amount of money through a transaction, the account balance in the corresponding account is updated, i.e., the amount of money spent is deducted, thereby ensuring the accuracy of the account balance. However, in the technical solution of the present specification, after the remittance transaction M is completed, although the assets ID _ j _1 to ID _ j _ M in the account corresponding to the remitter are spent, the account corresponding to the remitter is not updated immediately, that is, the assets ID _ j _1 to ID _ j _ M in the account corresponding to the remitter do not need to be deleted immediately, so that when any user queries the account corresponding to the remitter through the blockchain account book, the remittance transaction M is not aware of the asset change after the remittance transaction M is completed, and the true identity assumed by the remittance party in the remittance transaction M is prevented from being exposed based on the asset change. Meanwhile, although the remitter contains both spent and unspent assets in the corresponding account, based on the maintenance of the mirror collection of the historical keys, it can be ensured that the remitter can actually only spend the unspent assets and accurately detect the "double-flower" operation performed by the remitter on the spent assets.

Step 604a, key images I _1 to I _ M included in the linkable ring signature of the remittance transaction M are obtained, and values of the key images I _1 to I _ M are related to a private key x _ j, a public key P _ j and asset identifications ID _ j _1 to ID _ j _ M of a remittance party.

Step 604b, the linkable ring signature is verified, and the linkable ring signature is generated by the transferor according to the private key x _ j held by the transferor, the public key P _ j, and the public key P _ i held by the shield i.

The linkable ring signature can be generated by the transferor directly according to the private key x _ j, the public key P _ j and the public key P _ i corresponding to the shelterer i, without using the pseudo private key r ', the pseudo public key P ' _ j and the pseudo public key P ' _ i corresponding to the transferor i. At this time, if the linkable ring signature is verified, it can be verified that the linkable ring signature is signed by a private key corresponding to one of the public keys (P _1, … …, P _ n), thereby completing the authentication without revealing the identity of the transferor.

The linkable ring signature may be generated by the transferor based on its corresponding private key x _ j, public key P _ j, pseudo private key r ", pseudo public key P" _ j, and public key P _ i, pseudo public key P "_ i corresponding to the shield i. 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) ], and the pseudo private key r ″ (r _ j _1+ ·+ r _ j _ m) - (r '_ 1+ ·+ r' _ u). Meanwhile, according to the fact that the shelterer i holds assets [ ID _ i _1, PC { i,1} ] to [ ID _ i _ m, PC { i, m } ], the remitter can calculate a pseudo public key P "_ i ═ PC { i,1} + … + PC { i, m } ] to [ PC (t '_ 1, r' _1) + … + PC (t '_ u, r' _ u) ], i belongs to [1, j-1], [ j +1, n ]. The generation process of the linkable ring signature may refer to the embodiment shown in fig. 5, and is not described herein again. And the block link point can efficiently and compactly realize the following two verification functions by verifying the linkable ring signature: on the one hand, since P "_ j ═ r" × G is satisfied between the pseudo public key P "_ j and the pseudo private key r", and P "_ i ≠ r" × G is satisfied between the pseudo public key P "_ i and the pseudo private key r", when a linkable ring signature is generated from the pseudo private key r ", the pseudo public keys P" _ j and P "_ i, if the linkable ring signature is verified, it can be proved that a value of a certain pseudo public key in the pseudo public keys (P" _1, … …, P "_ n) is equal to r" × G, and the pseudo public key corresponds to the aforementioned t "_ 0, so that the remittance amount of the remittance transaction M can be equal to the remittance amount; on the other hand, when the linkable ring signature is generated according to the private key x _ j and the public key P _ j corresponding to the transferor and the public key P _ i corresponding to the shelterer i, if the linkable ring signature passes the verification, the linkable ring signature can be proved to be signed by the private key corresponding to one of the public keys (P _1, … …, P _ n), so that the identity verification is completed on the premise of not exposing the identity of the transferor.

Step 606, when the transaction execution condition is satisfied, executing the remittance transaction M; the transaction execution condition includes: the key images I _ 1-I _ m do not belong to a historical key image set, and the linkable ring signature passes verification; wherein the key images I _1 to I _ m are added to the historical key image set after the transaction is completed.

The linkable ring signature may further include a key image I _ (m +1), which is generated by the transferor according to the pseudo private key r ″ and the pseudo public key P "_ j corresponding to the transferor itself and the pseudo public key P" _ I corresponding to the shield I, for example, I _ (m +1) × Hash _ G (P "_ j). As previously described, there is a one-to-one correspondence between key image I _ (M +1) and the corresponding transaction, and thus by comparing key image I _ (M +1) to the historical key image, a replay (replay) problem for money transfer transaction M is identified: if the same historical key image exists for key image I _ (M +1), then replay of money transfer transaction M is indicated. Then, the transaction execution condition may further include: the key image I _ (m +1) does not belong to the historical key image set.

When the transferor corresponds to the public key P _ j and the masker i corresponds to the public key P _ i, the transaction execution condition may further include: the asset ID _ k _ d belongs to the owner of the public key P _ k, k belongs to [1, n ], d belongs to [1, m ]. In other words, the block link points may verify the affiliation of each asset.

In the confidential transaction, the block link points may also verify whether the transfer amounts t '_ 1 to t' _ u in the remittance transaction M are each no less than 0. And the transfer amount commitments PC (t '_ 1, r' _1) to PC (t '_ u, r' _ u) are generated by the transferor from the transfer amounts t '_ 1 to t' _ u and the random numbers r '_ 1 to r' _ u, and the transfer amounts t '_ 1 to t' _ u and the random numbers r '_ 1 to r' _ u are grasped only by the transferor and the transferees Q _1 to Q _ u, so that the transferor needs to perform a verification operation by the scope certificates RP _1 to RP _ u included in the remittance transaction M to determine whether the transfer amounts t '_ 1 to t' _ u satisfy t '_ 1 ≧ 0 to t' _ u ≧ 0, wherein the scope RP _1 to RP _ u is generated by the transferor added to the remittance transaction M. Then, the transaction execution condition may further include: all transfer amounts are not less than 0.

The process of verifying the linkable loop signature in step 604b is described below in conjunction with FIG. 7; FIG. 7 is a flowchart of a method for verifying a linkable ring signature according to an example embodiment. As shown in fig. 7, the following steps may be included:

step 702, verifying whether the asset corresponding to the identifier ID _ k _ d belongs to the holder of the public key P _ k, wherein k belongs to [1, n ], d belongs to [1, m ].

The verifying party may be a block link point in the blockchain network, and the block link point may verify the ring signature of the remittance transaction M after receiving the remittance transaction M submitted by the remitter; similarly, each blockchain node receives the money transfer transaction M and performs validation as a validating party. The remittance transaction M may be sent from the client device to the verifying party, or the remittance transaction M may be received by a certain verifying party from the client device and forwarded to another verifying party, or the remittance transaction M may be received by a certain verifying party from another verifying party and forwarded to another verifying party.

The verifier maintains a full blockchain ledger as a blockchain node so that the verifier can know the asset holding condition of each user. The money transfer transaction M involves the assets ID _ k _ d held by the user k (corresponding to the public key P _ k), and the verifying party can verify whether the correspondence between each public key P _ k and the corresponding asset ID _ k _ d is established, i.e. whether the holder of the public key P _ k owns M assets corresponding to the identification ID _ k _ d, respectively, based on the maintained asset holding situation. If the corresponding relation between each public key P _ k and the identification ID _ k _ d in the corresponding array is established, the subsequent steps can be continuously executed; if the asset to which an identifier corresponds does not belong to the holder of the public key P _ k, the verifying party may determine that the money transfer transaction M is invalid without continuing to perform subsequent steps 704-708.

Step 704, sequentially calculating L _ k _ 1-L _ k _ (m +1) and R _ k _ 1-R _ k _ (m +1) according to s _ k _ 1-s _ k _ (m + 1).

Step 706, calculating c _1 'according to L _ n _ 1-L _ n _ (m +1) and R _ n _ 1-R _ n _ (m +1), and verifying whether c _ 1' is equal to c _ 1.

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) according to the random number and/or its derivative contained in the ring signature, to verify whether the intermediate parameters L _ j _ d and L _ i _ d conform to the ring value-taking rule, whether the intermediate parameters R _ j _ d and R _ i _ d conform to the ring value-taking rule, whether the intermediate parameters L _ j _ (m +1) and L _ i _ (m +1) conform to the ring value-taking rule, and whether the intermediate parameters R _ j _ (m +1) and R _ i _ (m +1) conform to the ring value-taking rule.

For example, when the ring signature contains random numbers and/or derivatives thereof including: s _1_1 to s _1_ (m +1), …, s _ n _1 to s _ n _ (m +1), c _1, the ring-shaped value-taking rule between the intermediate parameters L _ j _ d and L _ i _ d may include:

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

the annular value-taking rule between the intermediate parameters L _ j _ (m +1) and L _ i _ (m +1) comprises the following steps:

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

the annular value-taking rule between the intermediate parameters R _ j _ d and R _ i _ d comprises the following steps:

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

the annular value-taking rule between the intermediate parameters R _ j _ (m +1) and R _ i _ (m +1) comprises the following steps:

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

then, the verifier may first generate L _1_ d, i.e., L _1_1 to L _1_ m, from s _1_ d, c _1, G, P _1, and P, and R _1_ d, i.e., R _1_1 to R _1_ m, from s _1_ d, c _1, P _1, ID _1_ d, I _ d, and P; and the verifier generates L _1_ (m +1) from s _1_ (m +1), c _1, G, P "_ 1, and P, and generates R _1_ (m +1) from s _1_ (m +1), c _1, P" _1, I _ (m +1), and P.

Then, the authenticator may generate c _2 from M, L _1_ d, R _1_ d, L _1_ (m +1), and R _1_ (m +1), and L _2_ d from s _2_ d, c _2, G, P _2, and P, R _2_ d from s _2_ d, c _2, P _2, ID _2_ d, I _ d, and P, L _2_ (m +1) from s _2_ (m +1), c _2, G, P "_ 2, and P, and R _2_ (m +1) from s _2_ (m +1), c _2, P" _2, I _ (m +1), and P; and so on, until the verifier generates c _ n from M, L _ (n-1) _ d, R _ (n-1) _ d, L _ (n-1) _ (m +1), and R _ (n-1) _ (m +1), and L _ n _ d from s _ n _ d, c _ n, G, P _ n, and P, R _ n _ d from s _ n _ d, c _ n, P _ n, ID _ n _ d, I _ d, and P, L _ n _ (m +1) from s _ n _ (m +1), c _ n, G, P "_ n, and P, and R _ n (m +1) from s _ n _ (m +1), c _ n, P" _ n, I _ (m +1), and P.

Further, the verifier may 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. C _1 'is used here to distinguish 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, indicating that the above-mentioned ring-valued rule is satisfied, it can be determined that: 1) among the pseudo public keys P _ 1-P _ n, there is one pseudo public key to make the remittance transaction M's remittance amount equal to the remittance amount; 2) the ring signature is generated by a private key corresponding to one of the public keys P _1 to P _ m. And if c _ 1' and c _1 are not equal, indicating at least one of 1) and 2) is false, the money transfer transaction M is confirmed as invalid without continuing to perform step 708, described below.

Step 708, verify the range certifications RP _1 to RP _ u.

The verifying party obtains the range certifications RP _1 to RP _ u from the transaction contents of the remittance transaction M and verifies to determine whether the respective transfer amounts t '_ 1 to t' _ u each satisfy not less than 0. If so, step 710 is shifted to, otherwise the money transfer transaction M is confirmed to be invalid without continuing with step 710 as described below.

Step 710, verify whether the key images I _1 to I _ (m +1) already exist.

In one embodiment, the verifier may compare key images I _1 through I _ (m +1) to the historical key image to determine whether key images I _1 through I _ (m +1) already exist. If any of the key images I _ 1-I _ (M +1) already has a corresponding historical key image, it may be determined that the money transfer transaction M is invalid; if no corresponding historical key image exists in the key images I _ 1-I _ (M +1), the remittance transaction M can be judged to be valid, and the remittance transaction M can be executed to finish the remittance operation.

FIG. 8 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 8, at the hardware level, the apparatus includes a processor 802, an internal bus 804, a network interface 806, a memory 808, and a non-volatile memory 810, but may also include hardware required for other services. The processor 802 reads a corresponding computer program from the non-volatile storage 810 into the memory 808 and then runs, thereby forming an anonymous trading device based on the ring signature on a logical level. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Referring to fig. 9, in a software implementation, the anonymous transaction device based on a ring signature may include:

a transaction assembling unit 91 for assembling remittance transaction M based on assets to be spent ID _ j _1 to ID _ j _ M in the remitter-corresponding account and shield assets ID _ i _1 to ID _ i _ M in the shield i-corresponding account; the assets to be spent ID _ j _ 1-ID _ j _ m and the shield assets ID _ i _ 1-ID _ i _ m are respectively recorded as asset commitments corresponding to corresponding asset amounts in a block chain account book, and i belongs to [1, j-1], [ j +1, n ];

the signature generation unit 92 generates a linkable ring signature for the remittance transaction M according to a private key x _ j, a public key P _ j and a public key P _ I held by a remitter I, wherein the linkable ring signature comprises key images I _1 to I _ M, and values of the key images I _1 to I _ M are related to the private key x _ j, the public key P _ j and asset identifications ID _ j _1 to ID _ j _ M of the remitter;

a transaction submitting unit 93 for 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 kept recorded as the assets held by the remitter on the blockchain ledger.

Optionally, the key images I _1 to I _ m are calculated by the following formulas:

I_d＝x_j×Hash_G(P_j,ID_j_d)，d∈[1,m]；

where Hash _ G () is a Hash function of the elliptic curve onto itself.

Optionally, the shelter includes any one or a combination of the following: an actual transferee for the money transfer transaction M, other users distinct from the transferor and the actual transferee.

Alternatively to this, the first and second parts may,

when there is no zero finding, the transaction receiver of the remittance transaction M is the actual receiver; when there is a zero finding, the transaction transferee of the money transfer transaction M is the money transferor and the actual transferee; or the like, or, alternatively,

the transaction transferee comprises the actual transferee and the transferor; when zero finding does not exist, the transfer amount corresponding to the sender is 0; or the like, or, alternatively,

the transaction transferee comprises the actual transferee, the transferor, a shield distinct from the actual transferee and the transferor; wherein, when there is no zero finding, the transfer amount corresponding to the transferor and the shelterer as the transaction transferee is 0; and when the change is found, the transfer amount corresponding to the sender is the change finding amount, and the transfer amount corresponding to the sheltering party as the transaction receiver is 0.

Optionally, the method further includes:

the certification generating unit 94 generates respective range certifications for the transfer amounts corresponding to the respective transaction recipients of the money transfer transaction M, and the range certifications are assembled into the money transfer transaction M to certify that the respective transfer amounts are not less than 0.

Alternatively to this, the first and second parts may,

the assets to be spent ID _ j _1 to ID _ j _ m and the assets ID _ i _1 to ID _ i _ m are the transaction outputs of corresponding historical transactions; or the like, or, alternatively,

the assets to be spent ID _ j _1 to ID _ j _ m are generated by being divided from the account balance corresponding to the remitter, and the assets ID _ i _1 to ID _ i _ m are generated by being divided from the account balance corresponding to the masker i.

Optionally, the signature generating unit 92 is specifically configured to:

determining a pseudo public key P '_ j _ [ PC (t _ j _1, r _ j _1) + … + PC (t _ j _ m, r _ j _ m) corresponding to a remitter, r _ j _ m) ] - [ PC (t' _1, r '_ 84 + r' _ j _ \ ) U is more than or equal to 1;

according to asset commitments PC { i,1} to PC { i, m } corresponding to the shield assets ID _ i _1 to ID _ i _ m, determining a pseudo public key P ' _ i [ PC { i,1} + … + PC { i, m } ] corresponding to a shield party i [ PC (t ' _1, r ' _1) + … + PC (t ' _ u, r ' _ u) ], wherein i belongs to [1, j-1], [ U +1, n ];

and generating a linkable ring signature for the remittance transaction M according to a private key x _ j, a public key P _ j, a pseudo private key r ' and a pseudo public key P ' _ j corresponding to the remittance party, and a public key P _ i and a pseudo public key P ' _ i corresponding to the shielding party i.

Optionally, the method further includes:

a mirror image generation unit 95 that generates a key mirror image I _ (m +1) × r "× Hash _ G (P" _ j) from the pseudo private key r ″ and the pseudo public key P "_ j corresponding to the transferor; wherein the linkable ring signature further includes the key image I _ (m + 1).

Optionally, the signature generating unit 92 is specifically configured to:

generating intermediate parameters L _ j _ d, R _ j _ d, L _ j _ (m +1), R _ j _ (m +1) corresponding to the remitter and intermediate parameters L _ i _ d, R _ i _ d, L _ i _ (m +1), R _ i _ (m +1), d ∈ [1, m ] corresponding to the shield i, respectively; wherein, the intermediate parameters L _ j _ d and L _ i _ d conform to the annular value-taking rule, the intermediate parameters L _ j _ (m +1) and L _ i _ (m +1) conform to the annular value-taking rule, the intermediate parameters R _ j _ d and R _ i _ d conform to the annular value-taking rule, the intermediate parameters R _ j _ (m +1) and R _ i _ (m +1) conform to the annular 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 money transfer transaction M is generated based on the chosen random number and/or a derivative thereof.

Alternatively to this, the first and second parts may,

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;

generating intermediate parameters L _ j _ d, R _ j _ d corresponding to the transferor includes: calculating intermediate parameters L _ j _ d and R _ j _ d according to a random number a _ d selected from a number field Z _ q in which the elliptic curve is positioned, so that L _ j _ d is a _ d × G, R _ j _ d is a _ d × Hash _ G (P _ j, ID _ j _ d); wherein Hash _ G () is a Hash function from the elliptic curve to itself;

generating intermediate parameters L _ j _ (m +1), R _ j _ (m +1) corresponding to the transferor, including: calculating intermediate parameters L _ j _ (m +1) and R _ j _ (m +1) according to a random number a _ (m +1) selected from a number field Z _ q in which the elliptic curve is located, so that L _ j _ (m +1) ═ a _ (m +1) × G, R _ j _ (m +1) × a _ (m +1) × Hash _ G (P "_ j);

generating intermediate parameters L _ i _ d, R _ i _ d, L _ i _ (m +1), R _ i _ (m +1) corresponding to the shield i, including: generating intermediate parameters L _ I _ d, R _ I _ d, L _ I _ d (m +1), and R _ I _ d (m +1) according to values of the intermediate parameters L _ j _ d and R _ j _ d, such 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) [ (m + I) × G) + c _ I _ (m +1) × Hash _ G (P" _ I) + (m +1) × I _ m +1) ] mod P, I _ j (m _ j × j ═ I _ j (m _ I _ j), and R _ I _ d (m _ I _ d); wherein s _ i _1 to s _ i _ (M +1) are random numbers in the domain Z _ q, 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 a Hash function from the elliptic curve to the domain Z _ q;

the random numbers and/or derivatives thereof are selected to include: random numbers s _ i _1 to s _ i _ (m +1), derivative values c _1, and derivative values s _ j _1 to s _ j _ (m + 1); where s _ j _ d is (a _ d-c _ j × x _ j) mod p, s _ j _ (M +1) [ a _ (M +1) -c _ j × R "] mod p, c _ j is Hash (M, L _ n _1, R _ n _1, … …, L _ n _ (M +1), R _ n _ (M +1)) when the value of j is determined to be 1, and c _ j is Hash (M, L _ (j-1) _1, R _ (j-1) _1, … …, L _ (j-1) _ (M +1), R _ (j-1) _ M +1)) when the value of j is determined to belong to [2, n ]).

Optionally, the method further includes:

asset deletion unit 96 initiates an asset deletion request to the blockchain network to delete at least a portion of the assets that have been spent by the transferor from the blockchain ledger.

FIG. 10 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 10, at the hardware level, the apparatus includes a processor 1002, an internal bus 1004, a network interface 1006, a memory 1008, and a non-volatile memory 1010, although it may also include hardware required for other services. The processor 1002 reads a corresponding computer program from the non-volatile memory 1010 into the memory 1008 and then runs the computer program to form an anonymous transaction device based on the ring signature on a logical level. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Referring to fig. 11, in a software implementation, the anonymous transaction device based on a ring signature may include:

a transaction receiving unit 1101, which receives a remittance transaction M, which is generated by a remitter assembling according to assets to be spent ID _ j _1 to ID _ j _ M in an account corresponding to the remitter and cover assets ID _ i _1 to ID _ i _ M in an account corresponding to a cover party i, where i belongs to [1, j-1], [ j +1, n ]; after the transaction is completed, the assets ID _ j _ 1-ID _ j _ m are kept recorded as the assets held by the transferor on the blockchain ledger;

a mirror image obtaining unit 1102, configured to obtain key mirror images I _1 to I _ M included in a linkable ring signature of the remittance transaction M, where values of the key mirror images I _1 to I _ M are related to a private key x _ j, a public key P _ j, and asset identifiers ID _ j _1 to ID _ j _ M of a remittance party;

a signature verification unit 1103 that verifies the linkable ring signature generated by the remitter from the private key x _ j and the public key P _ j held by the remitter and the public key P _ i held by the masker i;

a transaction execution unit 1104 that executes the remittance transaction M when a transaction execution condition is satisfied; the transaction execution condition includes: the key images I _ 1-I _ m do not belong to a historical key image set, and the linkable ring signature passes verification; wherein the key images I _1 to I _ m are added to the historical key image set after the transaction is completed.

Optionally, the key images I _1 to I _ m are calculated by the transferor according to the following formula:

I_d＝x_j×Hash_G(P_j,ID_j_d)，d∈[1,m]；

where Hash _ G () is a Hash function of the elliptic curve onto itself.

Alternatively to this, the first and second parts may,

Optionally, the method further includes:

an amount verifying unit 1105 verifying whether the transfer amount corresponding to each transaction receiver is not less than 0 according to the range certification included in the remittance transaction M;

wherein the transaction execution condition further includes: the transfer amount corresponding to each transaction payee is not less than 0.

Alternatively to this, the first and second parts may,

Optionally, the transaction execution condition further includes: the asset ID _ k _ d belongs to all parties of the public key P _ k, k belongs to [1, n ], d belongs to [1, m ], i belongs to [1, j-1 ]. times [ j +1, n ].

Optionally, the linkable ring signature is generated by the transferor based on the private key x _ j, public key P _ j, pseudo private key r "and pseudo public key P" _ j corresponding to itself, and the public key P _ i and pseudo public key P "_ i corresponding to the shelterer i, such that when the linkable ring signature is verified, the money transfer transaction M is confirmed as input and output, etc.;

wherein, 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" _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 identification ID _ j _ 1-PC _ j _ m corresponds to the number of asset j _1, t _ j _ m and r _ j _ m, and the random commitment number of asset j _ 1-r _ j _ m, r _ j _1) to PC (t _ j _ m, r _ j _ m), the cover assets ID _ i _1 to ID _ i _ m correspond to the asset commitments PC { i,1} to PC { i, m }, the transaction payees Q _1 to Q _ u correspond to the transfer amounts t '_ 1 to t' _ u, the random numbers r '_ 1 to r' _ u, and the transfer amount commitments PC (t '_ 1, r' _1) to PC (t '_ u, r' _ u), u ≧ 1.

Optionally, the linkable ring signature further includes a key image I _ (m +1) ═ r "× Hash _ G (P" _ j);

wherein the transaction execution condition further includes: key image I _ (m +1) does not belong to the historical key image set.

Optionally, the remitter generates intermediate parameters L _ j _ d, R _ j _ d, L _ j _ (m +1), R _ j _ (m +1) corresponding to the remitter, and intermediate parameters L _ i _ d, R _ i _ d, L _ i _ (m +1), R _ i _ (m +1) corresponding to the shelterer i, respectively, according to the private key x _ j, the public key P _ j, the pseudo private key R', the pseudo public key P "_ j corresponding to the remitter, and the pseudo public key P" _ i corresponding to the shelterer i, and generates the signable ring linking value according to the random number and/or derivative thereof associated with 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 is belonged to [1, m ]; verifying the linkable ring signature, including:

according to the random number and/or the derivative value thereof contained in the ring signature, calculating 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) so as to verify whether the intermediate parameters L _ j _ d and L _ i _ d conform to a ring value-taking rule, whether the intermediate parameters L _ j _ (m +1) and L _ i _ (m +1) conform to a ring value-taking rule, whether the intermediate parameters R _ j _ d and R _ i _ d conform to a ring value-taking rule, and whether the intermediate parameters R _ j _ (m +1) and R _ i _ (m +1) conform to a ring value-taking rule.

Alternatively to this, the first and second parts may,

the random number and/or its derivative value contained in the ring signature includes: s _ k _1 to s _ k _ (m +1), c _1, k belongs to [1, n ];

the annular value-taking rule between the intermediate parameters L _ j _ d and L _ i _ d comprises the following steps: l _ k _ d ═ (s _ k _ d × G + c _ k × P _ k) mod P; wherein s _ k _ d belongs to a number domain Z _ q where the elliptic curve is located, and Hash () is a Hash function from the elliptic curve to the number domain Z _ q;

the annular value-taking rule between the intermediate parameters L _ j _ (m +1) and L _ i _ (m +1) comprises the following steps: l _ k _ (m +1) ═ s _ k _ (m +1) × G + c _ k × P "_ k ] mod P; wherein s _ k _ (m +1) belongs to the number domain Z _ q;

the annular value-taking rule between the intermediate parameters R _ j _ d and R _ i _ d comprises the following steps: 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 annular value-taking rule between the intermediate parameters R _ j _ (m +1) and R _ i _ (m +1) comprises the following steps: r _ k _ (m +1) [ (s _ k _ (m +1) × Hash _ G (P "_ k) + c _ k × I _ (m +1) ] mod P, I _ (m +1) is contained in the ring signature;

wherein c _1 is Hash (M, L _ n _1, R _ n _1, … …, L _ n _ (M +1), R _ n _ (M +1)) when h ∈ [2, n ], c _ k is Hash (M, L _ (h-1) _1, R _ (h-1) _1, … …, L _ (h-1) _ (M +1), R _ (h-1) _ (M +1)) when h ∈ [2, n ].

Optionally, the method further includes:

an asset deletion unit 1106 deletes at least a part of the assets that the remitter has spent from the blockchain ledger in accordance with the asset deletion request issued to the blockchain network of the remitter.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

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

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, 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 Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims

1. An anonymous transaction method based on a ring signature, comprising:

2. The method of claim 1, wherein 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]；

where Hash _ G () is a Hash function of the elliptic curve onto itself.

3. The method of claim 1, the screen comprising any one or a combination of: an actual transferee for the money transfer transaction M, other users distinct from the transferor and the actual transferee.

4. The method of claim 1, wherein the first and second light sources are selected from the group consisting of,

5. The method of claim 1, further comprising:

and respectively generating corresponding range certificates aiming at the transfer amount corresponding to each transaction receiver of the remittance transaction M, wherein the range certificates are assembled into the remittance transaction M to be used for proving that the corresponding transfer amount is not less than 0.

6. The method of claim 1, wherein the first and second light sources are selected from the group consisting of,

7. The method of claim 1, generating a linkable ring signature for the money transfer transaction M based on a private key x _ j held by a transferor, a public key P _ j, and a public key P _ i held by a shield i, comprising:

8. The method of claim 7, further comprising:

generating a key image I (m +1) ═ r '× Hash _ G (P' _ j) according to a pseudo private key r 'and a pseudo public key P' _ j corresponding to a transferor; wherein the linkable ring signature further includes the key image I _ (m + 1).

9. The method of claim 7, generating a linkable ring signature for the money transfer transaction M based on the private key x _ j, public key P _ j, pseudo private key r ", pseudo public key P" _ j, public key P _ i, pseudo public key P "_ i corresponding to the depositor i, comprising:

10. The method of claim 9, wherein the first and second light sources are selected from the group consisting of,

11. The method of claim 1, further comprising:

an asset deletion request is initiated to the blockchain network to delete at least a portion of the assets that have been spent by the transferor from the blockchain ledger.

12. An anonymous transaction method based on a ring signature, comprising:

13. The method of claim 12, wherein the key images I _1 to I _ m are calculated by the transferor using the following formula:

I_d＝x_j×Hash_G(P_j,ID_j_d)，d∈[1,m]；

where Hash _ G () is a Hash function of the elliptic curve onto itself.

14. The method of claim 12, the screen comprising any one or a combination of: an actual transferee for the money transfer transaction M, other users distinct from the transferor and the actual transferee.

15. The method of claim 12, wherein the first and second light sources are selected from the group consisting of,

16. The method of claim 12, further comprising:

verifying whether the transfer amount corresponding to each transaction receiver is not less than 0 according to the range certificate contained in the remittance transaction M;

17. The method of claim 12, wherein the first and second light sources are selected from the group consisting of,

18. The method of claim 12, the transaction execution condition further comprising: the asset ID _ k _ d belongs to all parties of the public key P _ k, k belongs to [1, n ], d belongs to [1, m ], i belongs to [1, j-1 ]. times [ j +1, n ].

19. The method of claim 12, the linkable ring signature being generated by the transferor based on a private key x _ j, a public key P _ j, a pseudo private key r ", and a pseudo public key P" _ j corresponding to itself, and a public key P _ i and a pseudo public key P "_ i corresponding to the shelterer i, such that when the linkable ring signature is verified, the money transfer transaction M is validated as input and output, etc.;

20. The method of claim 19, the linkable ring signature further comprising a key image I _ (m +1) ═ r "x Hash _ G (P" _ j);

21. The method of claim 19, wherein the transferor generates intermediate parameters L _ j _ d, R _ j _ d, L _ j _ L _1, R _ j _ L _1, and R _ j _ L _1 corresponding to the transferor, respectively, and intermediate parameters L _ i _ d, R _ i _ d, L _ i _ L _1, and R _ i _1 corresponding to the transferor i, and generates the signable ring value based on the random number and/or derivative thereof associated with the values of the intermediate parameters L _ j _ d, R _ j _ d, L _ j _ L (m +1), R _ i _ d, L _ i _1, and R _ i _1, respectively, d is belonged to [1, m ]; verifying the linkable ring signature, including:

22. The method of claim 21, wherein the first and second light sources are selected from the group consisting of,

23. The method of claim 12, further comprising:

deleting at least a portion of the assets spent by the transferor from a blockchain ledger in accordance with an asset deletion request initiated by the transferor blockchain network.

24. An anonymous transaction device based on a ring signature, comprising:

the transaction assembly unit is used for assembling remittance transactions M according to the assets to be spent ID _ j _ 1-ID _ j _ M in the account corresponding to the remitter and the shield assets ID _ i _ 1-ID _ i _ M in the account corresponding to the shield i; wherein, the assets to be spent ID _ j _1 to ID _ j _ m and the shield assets ID _ i _1 to ID _ i _ m are respectively recorded as the asset commitments corresponding to the corresponding asset amounts in the block chain ledger;

25. An anonymous transaction device based on a ring signature, comprising:

26. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 1-11 by executing the executable instructions.

27. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of claims 1 to 11.

28. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 12-23 by executing the executable instructions.

29. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of claims 12-23.