Method and device for implementing confidential blockchain transactions using ring signatures

Abstract

One or more embodiments of the present specification provide a method and device for implementing confidential blockchain transactions using ring signatures, which may include: determining all participants in a remittance transaction, each participant's account including an income balance and a number of assets; assembling a remittance transaction based on the assets to be spent in the corresponding account of the real remitter among the participants, the cover assets in the corresponding account of the fake remitter, and the commitment value of the transfer amount corresponding to each payee among the participants; generating a linkable ring signature containing a key image for the remittance transaction, and the value of the key image is related to the private key, public key and asset identifier of the real remitter; submitting the signed remittance transaction to the blockchain network; wherein, after the transaction is completed, the income balance in the corresponding account of each payee is increased by the corresponding transfer amount, the key image is added to the historical key image set, and the assets to be spent are maintained and recorded on the blockchain ledger as assets in the corresponding account of the real remitter.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a method and device for implementing confidential blockchain transactions using ring signatures. Background Art

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

[0003] In view of this, one or more embodiments of this specification provide a method and device for implementing confidential blockchain transactions using ring signatures.

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

[0005] According to a first aspect of one or more embodiments of this specification, a method for implementing a confidential blockchain transaction using a ring signature is proposed, including:

[0006] Determine all participants in the remittance transaction M, each of whom has a corresponding account on the blockchain ledger, including a revenue balance whose value is recorded as the corresponding commitment value and a number of assets whose asset amount is recorded as the asset commitment;

[0007] Assemble the remittance transaction M according to the to-be-spent assets ID_j_1~ID_j_m in the corresponding account of the real remitter among the participants, the cover assets ID_i_1~ID_i_m in the corresponding account of the fake remitter i, and the committed value of the transfer amount corresponding to each payee among the participants;

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

[0009] Submit the signed remittance transaction M to the blockchain network; after the transaction is completed, the income balance in the corresponding account of each payee is increased by the corresponding transfer amount, the key images I_1~I_m are added to the historical key image set, and the to-be-spent assets ID_j_1~ID_j_m are maintained and recorded on the blockchain ledger as assets in the corresponding account of the real remitter.

[0010] According to a second aspect of one or more embodiments of this specification, a method for implementing a confidential blockchain transaction using a ring signature is proposed, including:

[0011] Receive a remittance transaction M, where each participant of the remittance transaction M has a corresponding account on the blockchain ledger, and the account includes an income balance whose value is recorded as a corresponding commitment value and a number of assets whose asset amount is recorded as an asset commitment; wherein the remittance transaction M is generated by the real remitter among the participants according to the to-be-spent assets ID_j_1 to ID_j_m in its corresponding account, the cover assets ID_i_1 to ID_i_m in the corresponding account of the fake remitter i, and the commitment value of the transfer amount corresponding to each payee among the participants;

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

[0013] Verify the linkable ring signature, which is generated by the real remitter based on its own private key x_j, public key P_j and the public key P_i held by the fake remitter i; wherein, when the linkable ring signature passes the verification, the remittance transaction M is confirmed as equal in input and output;

[0014] When the transaction execution conditions are met, the remittance transaction M is executed, so that the income balance in the corresponding account of each payee is increased by the corresponding transfer amount; the transaction execution conditions include: the key images I_1~I_m do not belong to the historical key image set and the linkable ring signature passes the verification; wherein, the key images I_1~I_m are added to the historical key image set after the transaction is completed, and the to-be-spent assets ID_j_1~ID_j_m are maintained and recorded on the blockchain ledger as assets in the corresponding account of the real remitter.

[0015] According to a third aspect of one or more embodiments of this specification, a device for implementing confidential blockchain transactions using ring signatures is proposed, including:

[0016] A participant determination unit determines all participants of the remittance transaction M, each participant having a corresponding account on the blockchain ledger, the account including a revenue balance whose value is recorded as a corresponding commitment value and a number of assets whose asset amount is recorded as an asset commitment;

[0017] The transaction assembly unit assembles the remittance transaction M according to the to-be-spent assets ID_j_1 to ID_j_m in the corresponding account of the real remitter among the participants, the cover assets ID_i_1 to ID_i_m in the corresponding account of the fake remitter i, and the committed value of the transfer amount corresponding to each payee among the participants;

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

[0019] The transaction submission unit submits the signed remittance transaction M to the blockchain network; wherein, after the transaction is completed, the income balance in the corresponding account of each payee is increased by the corresponding transfer amount, the key images I_1~I_m are added to the historical key image set, and the to-be-spent assets ID_j_1~ID_j_m are maintained and recorded on the blockchain ledger as assets in the corresponding account of the real remitter.

[0020] According to a fourth aspect of one or more embodiments of this specification, a device for implementing confidential blockchain transactions using ring signatures is proposed, including:

[0021] A transaction receiving unit receives a remittance transaction M, wherein each participant of the remittance transaction M has a corresponding account on the blockchain ledger, and the account includes an income balance whose value is recorded as a corresponding commitment value and a number of assets whose asset amount is recorded as an asset commitment; wherein the remittance transaction M is generated by the real remitter among the participants according to the to-be-spent assets ID_j_1 to ID_j_m in its corresponding account, the cover assets ID_i_1 to ID_i_m in the corresponding account of the fake remitter i, and the commitment value of the transfer amount corresponding to each payee among the participants;

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

[0023] A signature verification unit verifies the linkable ring signature, wherein the linkable ring signature is generated by the real remitter according to its own private key x_j, public key P_j and public key P_i held by the fake remitter i; wherein, when the linkable ring signature passes the verification, the remittance transaction M is confirmed as equal in input and output;

[0024] The transaction execution unit executes the remittance transaction M when the transaction execution conditions are met, so that the income balance in the corresponding account of each payee increases by the corresponding transfer amount; the transaction execution conditions include: the key images I_1~I_m do not belong to the historical key image set and the linkable ring signature passes the verification; wherein the key images I_1~I_m are added to the historical key image set after the transaction is completed, and the to-be-spent assets ID_j_1~ID_j_m are maintained and recorded on the blockchain ledger as assets in the corresponding account of the real remitter.

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

[0026] processor;

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

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

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

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

[0031] processor;

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

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

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

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

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

[0037] Figure 3 It is a flowchart of a method for implementing a confidential blockchain transaction using a ring signature provided by an exemplary embodiment.

[0038] Figure 4 It is a schematic diagram of implementing asset transfer between accounts provided by an exemplary embodiment.

[0039] Figure 5 It is a schematic diagram of an account model provided by an exemplary embodiment.

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

[0041] Figure 7 It is a flowchart of another method for implementing confidential blockchain transactions using ring signatures provided by an exemplary embodiment.

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

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

[0044] Fig.10 It is a block diagram of an implementation device for confidential blockchain transactions using ring signatures provided by an exemplary embodiment.

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

[0046] Fig.12 It is a block diagram of another implementation device of a confidential blockchain transaction using a ring signature provided by an exemplary embodiment. DETAILED DESCRIPTION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0063] In addition, users need to sign when initiating transactions in the blockchain network. For example, when user A wants to spend an asset held in the blockchain, he can initiate a blockchain transaction and sign it with the private key x_j held by user A. Correspondingly, the above signature can be verified through the public key P_j corresponding to the private key x_j held by user A. However, direct verification of the signature also exposes user A as the signatory of the corresponding signature, thereby leaking user A's privacy.

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

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

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

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

[0068] When the UTXO (Unspent Transaction Output) model is used to implement asset management, all assets under the model are transaction outputs of the corresponding blockchain transactions, and all assets generated on the blockchain network are managed in a unified manner, where each asset has a unique corresponding public-private key pair, and users can spend the corresponding assets through the public-private key pair they hold. For example, when an asset held by a signatory (such as the remitter in a remittance transaction) corresponds to a private key x_j and a public key P_j, the corresponding key-image can be generated according to the formula I = x_j × Hash (P_j). As long as the asset has been spent before, the blockchain node will record the key-image with the same value, thereby identifying the "double-spending" problem.

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

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

[0071] Figure 3 This is a flowchart of a method for implementing a confidential blockchain transaction using a ring signature provided by an exemplary embodiment. Figure 3 As shown, the method is applied to a client device and may include the following steps:

[0072] Step 302, all participants in the remittance transaction M are determined, each participant has a corresponding account on the blockchain ledger, and the account includes an income balance whose value is recorded as the corresponding commitment value and a number of assets whose asset amount is recorded as the asset commitment.

[0073] The blockchain ledger contains the accounts corresponding to all users in the blockchain network, and maintains the funds held by the corresponding users through the accounts. Figure 4 is a schematic diagram of an exemplary embodiment providing a method for transferring assets between accounts. Figure 4 The account A_j corresponding to the remitter and the account A_e corresponding to a payee are shown in FIG. Taking account A_j as an example, the account model used by the account includes: an "income balance" part and an "asset" part.

[0074] The income balance part is similar to the account model used in the related art, which is used to directly accumulate the amount of funds. For example, when the amount of funds corresponding to the income balance is Figure 4 When Ar_j is shown, for the purpose of keeping the amount of funds confidential, the commitment amount corresponding to the amount of funds Ar_j is actually recorded in the blockchain account book. For example, the commitment amount generated based on the amount of funds Ar_j and the random number r_Ar_j is PC(Ar_j,r_Ar_j). Due to the existence of the random number r_Ar_j, the commitment amount PC(Ar_j,r_Ar_j) generated by the amount of funds Ar_j is random. Except for the remitter who has the random number r_Ar_j, other users can only see the commitment amount PC(Ar_j,r_Ar_j), and cannot infer the corresponding amount of funds Ar_j based on it.

[0075] The asset part is similar to the UTXO model and is used to manage several assets separately. For example, the asset part can contain Figure 4 The asset ID_j_1, ID_j_2, etc. are shown. Among them, ID_j_1, ID_j_2, etc. are the asset identifiers of the corresponding assets, which are used to distinguish each asset, and the asset amounts of these assets are t_j_1, t_j_2, etc., but for the purpose of keeping the asset amount confidential, they are actually recorded in the blockchain ledger as the commitment amount corresponding to the asset amount. For example, the commitment amount generated by the asset amount t_j_1 and the random number r_j_1 is PC(t_j_1, r_j_1), and the commitment amount generated by the asset amount t_j_2 and the random number r_j_2 is PC(t_j_2, r_j_2), etc. Among them, the blockchain ledger can use a form similar to [identification, asset commitment] to record each asset in the asset part, for example, it can be recorded as follows Figure 4 [ID_j_1, PC(t_j_1, r_j_1)], [ID_j_2, PC(t_j_2, r_j_2)], etc. are shown in the figure, and this specification does not limit this. Among them, due to the existence of the random numbers r_j_1-r_j_2, the committed amount PC(t_j_1, r_j_1)-PC(t_j_2, r_j_2) generated by the asset amount t_j_1-t_j_2 is random. Except for the remitter who knows the random numbers r_j_1-r_j_2, other users can only see the committed amount PC(t_j_1, r_j_1)-PC(t_j_2, r_j_2), and cannot infer the corresponding asset amount t_j_1-t_j_2 based on it.

[0076] Similar to the above account A_j, Figure 4The account A_e shown also includes an income balance part and an asset part, where the income balance part is recorded on the blockchain ledger as the commitment amount PC(Ar_e,r_Ar_e) generated based on the amount of funds Ar_e and the random number r_Ar_e, and the asset part is recorded on the blockchain ledger as [ID_e_1,PC(t_e_1,r_e_1)], [ID_e_2,PC(t_e_2,r_e_2)], etc., where ID_e_1 and ID_e_2 are asset identifiers, the commitment amount PC(t_e_1,r_e_1) is generated by the asset amount t_e_1 and the random number r_e_1, and the commitment amount PC(t_e_2,r_e_2) is generated by the asset amount t_e_2 and the random number r_e_2.

[0077] Of course, the blockchain account book does not necessarily record assets in the form of [identification, asset commitment]. For example, when there are multiple asset types, assets can be recorded and stored in a form similar to [type, identification, asset commitment]. In the process of calculating asset amounts and executing transactions, the impact of asset types needs to be considered, such as the conversion ratio of asset amounts between different types of assets. Furthermore, in addition to directly recording "asset commitment", other information can also be stored at the same time; taking asset ID_j_1 as an example, it can be recorded as [ID_j_1, E(t_j_1, r_j_1)], where E(t_j_1, r_j_1) = [PC(t_j_1, r_j_1), E(t_j_1), E(r_j_1)], E(t_j_1) and E(r_j_1) are the homomorphic ciphertexts corresponding to the asset amount t_j_1 and the random number r_j_1, respectively, which can be obtained by encrypting the asset amount t_j_1 and the random number r_j_1 with the homomorphic encryption public key of the remitter (obtained by homomorphic encryption of the public key P_j). For ease of understanding, the following examples are given in the form of [identification, asset commitment].

[0078] Step 304, assemble the remittance transaction M according to the to-be-spent assets ID_j_1~ID_j_m in the corresponding account of the real remitter among the participants, the cover assets ID_i_1~ID_i_m in the corresponding account of the fake remitter i, and the committed value of the transfer amount corresponding to each payee among the participants.

[0079] As mentioned above, the assets to be spent ID_j_1~ID_j_m can be recorded on the blockchain ledger as [ID_j_1, PC(t_j_1, r_j_1)]~[ID_j_m, PC(t_j_m, r_j_m)], and the covering assets ID_i_1~ID_i_m can be recorded on the blockchain ledger as [ID_i_1, PC(t_i_1, r_i_1)]~[ID_i_m, PC(t_i_m, r_i_m)], where r_j_1~r_j_m and r_i_1~r_i_m are random numbers.

[0080] By including both the real remitter and the fake remitter i in the participants, and assembling the remittance transaction M based on the to-be-spent assets ID_j_1~ID_j_m in the corresponding account of the real remitter and the cover assets ID_i_1~ID_i_m in the corresponding account of the fake remitter i, and adding the linkable ring signature generated below, the fake remitter i can hide the identity of the real remitter, making it impossible for other users to determine which user among the "real remitter and the fake remitter i" has spent the assets.

[0081] The assets to be spent ID_j_1~ID_j_m can be any assets held by the real remitter, and the cover assets ID_i_1~ID_i_m can be any assets held by the fake remitter i. Of course, when actually selecting the assets to be spent ID_j_1~ID_j_m, it is also necessary to refer to the remittance amount involved in the remittance transaction M, and ensure that the sum of the asset amounts of the assets to be spent is not less than the remittance amount. The remittance amount is the amount that the remitter needs to transfer to each real payee. These amounts are determined in advance by the real remitter and each real payee through negotiation, or they can be determined by the real remitter itself.

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

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

[0084] For real payees and fake payees:

[0085] In one embodiment, the payee of the remittance transaction M may only include the real payee. In one case, when there is no change, the real payee only includes the initial remittance object, that is, the object initially determined to trade with the real remitter. At this time, the sum of the asset amounts t_j_1~t_j_m corresponding to the assets ID_j_1~ID_j_m to be spent is exactly equal to the sum of the transfer amounts corresponding to each initial remittance object, that is, there is no change. In another case, when there is change, the real payee includes the real remitter and the initial remittance object, and the transfer amount corresponding to the real remitter is the difference between the sum of the asset amounts t_j_1~t_j_m corresponding to the assets ID_j_1~ID_j_m to be spent and the sum of the transfer amounts corresponding to each initial remittance object, that is, the change amount.

[0086] In another embodiment, in addition to the real payee, the payee of the remittance transaction M may also include a false payee. In one case, the false payee may include the real remitter, but there is no change in this case. In another case, the false payee may include participants other than the real remitter and the real payee. By setting the transfer amount corresponding to the false payee to 0, the impact on the real payee can be avoided. At the same time, since the transfer amounts of all payees are corresponding homomorphic ciphertexts, the false payee can hide the identity of the real payee.

[0087] According to the actual situation, the identity of the real remitter can be hidden only by the false remitter, or the identity of the real payee can be further hidden by the false payee. In one embodiment, the participants of the remittance transaction M can include the real remitter, the real payee and the cover party different from the two at the same time. These users constitute a total of n participants, and the n participants all participate in the remittance and collection of the remittance transaction at the same time: for the real remitter, the real payee and the cover party are both false remitters; for the real payee, the real remitter and the cover party are both false payees, so that the identities of the real remitter and the real payee are hidden at the same time. Moreover, since each participant participates in the remittance and collection at the same time, the identity confusion between the remitter and the payee can be achieved, thereby further increasing the reliability of identity hiding.

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

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

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

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

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

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

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

[0095] Based on the homomorphic property, it can be determined that P”_i=r”_i×G+t”_i×H≠r”×G. It can be seen that the parameters P”_j and r” both uniquely correspond to the real remitter, and the parameter P”_i uniquely corresponds to the fake remitter i. Therefore, r” can be regarded as the pseudo private key corresponding to the real remitter, P”_j can be regarded as the pseudo public key corresponding to the real remitter, and P”_i can be regarded as the pseudo public key corresponding to the fake remitter i.

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

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

[0098] Step 308, submitting the signed remittance transaction M to the blockchain network; wherein, after the transaction is completed, the income balance in the corresponding account of each payee is increased by the corresponding transfer amount, the key images I_1~I_m are added to the historical key image set, and the to-be-spent assets ID_j_1~ID_j_m are maintained and recorded on the blockchain ledger as assets in the corresponding account of the real remitter.

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

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

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

[0102] After the remittance transaction M is completed, the transfer amount is remitted to each recipient's account. Figure 4 The account model shown makes the transfer amount actually transferred to the "income balance" of the corresponding account, so that the income balance increases by the corresponding transfer amount. Among them, for the false payee, since the transfer amount corresponding to the false payee is 0, the income balance of the corresponding account of the false payee is equivalent to no numerical change, and since the transfer amount is added to the "income balance" part instead of the "assets" part, it will not cause the assets with an asset amount of 0 to appear in the corresponding account of the false payee, avoiding the increase of account maintenance costs.

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

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

[0105] 2) Recipient and transfer amount: {[Q_1,PC(t'_1,r'_1)],[Q_2,PC(t'_2,r'_2)],…,[Q_u,PC(t'_u,r'_u)]}.

[0106] 3) Range proof RP_1~RP_u.

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

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

[0109] Based on Figure 4 In the account model shown, when the assets in the corresponding account of the participant are insufficient, at least a portion of the income balance in the corresponding account can be divided to generate corresponding assets. Figure 4 The account model shown can be further varied: for example, Figure 5 is a schematic diagram of an account model provided by an exemplary embodiment; Figure 5 As shown, in Figure 4On the basis of the "income balance" part and the "asset" part shown, the account model can further include a "main balance" part. Taking account A_j as an example, the amount of funds corresponding to the main balance of account A_j is Ac_j, and the amount of funds Ac_j is recorded as the corresponding commitment amount PC(Ac_j, r_Ac_j) on the blockchain ledger, where r_Ac_j is a random number; and the income balance is recorded as the commitment amount PC(Ar_j, r_Ar_j). Then, the relationship between the main balance, income balance, and assets in account A_j can include: the incoming resources for account A_j are merged into the income balance, at least a part of the main balance is divided to create assets, and at least a part of the funds of the income balance can be transferred to the main balance (for example, the income balance can be regularly merged into the main balance) to supplement the main balance, and the assets are used for transaction transfers to other accounts, thereby realizing the circulation of funds. Of course, in some cases, the main balance can also be used to absorb incoming funds, the income balance can also be used to create assets, and at least a part of the funds of the main balance can also be transferred to the income balance, and this specification does not limit this. The above-mentioned fund transfer, asset creation, asset consumption, etc. all need to be achieved by initiating corresponding blockchain transactions.

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

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

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

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

[0114] Step 604a, calculating the intermediate parameters L_j_d and R_j_d.

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

[0116] L_j_d=a_d×G

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0150] In the calculation process, s_2_d~s_(j-1)_d, s_2_(m+1)~s_(j-1)_(m+1) are involved, all of which are random numbers in the number field Z_q. In addition, c_2~c_(j-1) are involved in the calculation process, and the calculation process conforms to the following formula: c_i=Hash(M,L_(i-1)_1,R_(i-1)_1,……,L_(i-1)_(m+1),R_(i-1)_(m+1)).

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

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

[0153] Step 612: Generate a linkable ring signature.

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

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

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

[0157]

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

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

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

[0161] Step 702, receiving a remittance transaction M, wherein each participant of the remittance transaction M has a corresponding account on the blockchain ledger, and the account includes an income balance whose value is recorded as a corresponding commitment value, and a number of assets whose asset amounts are recorded as asset commitments; wherein the remittance transaction M is generated by the real remitter among the participants according to the to-be-spent assets ID_j_1~ID_j_m in its own corresponding account, the cover assets ID_i_1~ID_i_m in the corresponding account of the fake remitter i, and the commitment values ​​of the transfer amounts corresponding to the various payees among the participants.

[0162] As mentioned above, this manual uses the form of "account" to manage the assets held by users. Figure 4 In the account model shown, the account includes an "income balance" part and an "asset" part; Figure 5 In the account model shown, the account includes the "income balance" part, the "asset" part and the "main balance" part. Among them, the amount of funds corresponding to the "income balance" and the "main balance" are recorded as the corresponding commitment amount on the blockchain ledger, and the asset amount of each asset contained in the "asset" part is also recorded as the corresponding commitment amount on the blockchain ledger. For details, please refer to the above combined Figure 4 or Figure 5 The relevant description will not be repeated here.

[0163] For "assets", taking the assets to be spent ID_j_1~ID_j_m as an example, ID_j_1~ID_j_m are asset identifiers used to distinguish different assets; assuming that the asset amount of the assets to be spent ID_j_1~ID_j_m is t_j_1~t_j_m, then the blockchain ledger can record the asset commitment PC(t_j_1,r_j_1)~PC(t_j_m,r_j_m) corresponding to the asset amount t_j_1~t_j_m, where r_j_1~r_j_m are random numbers. Due to the existence of random numbers r_j_1~r_j_m, the asset commitment PC(t_j_1,r_j_1)~PC(t_j_m,r_j_m) generated by amounts t_j_1~t_j_m are random. Except for the real remitter who knows the random numbers r_j_1~r_j_m, other users can only see the asset commitment PC(t_j_1,r_j_1)~PC(t_j_m,r_j_m), and cannot infer the corresponding asset amounts t_j_1~t_j_m based on them.

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

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

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

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

[0168] For real payees and fake payees:

[0169] In one embodiment, the payee of the remittance transaction M may only include the real payee. In one case, when there is no change, the real payee only includes the initial remittance object, that is, the object initially determined to trade with the real remitter. At this time, the sum of the asset amounts t_j_1~t_j_m corresponding to the assets ID_j_1~ID_j_m to be spent is exactly equal to the sum of the transfer amounts corresponding to each initial remittance object, that is, there is no change. In another case, when there is change, the real payee includes the real remitter and the initial remittance object, and the transfer amount corresponding to the real remitter is the difference between the sum of the asset amounts t_j_1~t_j_m corresponding to the assets ID_j_1~ID_j_m to be spent and the sum of the transfer amounts corresponding to each initial remittance object, that is, the change amount.

[0170] In another embodiment, in addition to the real payee, the payee of the remittance transaction M may also include a false payee. In one case, the false payee may include the real remitter, but there is no change in this case. In another case, the false payee may include participants other than the real remitter and the real payee. By setting the transfer amount corresponding to the false payee to 0, the impact on the real payee can be avoided. At the same time, since the transfer amounts of all payees are corresponding homomorphic ciphertexts, the false payee can hide the identity of the real payee.

[0171] According to the actual situation, the identity of the real remitter can be hidden only by the false remitter, or the identity of the real payee can be further hidden by the false payee. In one embodiment, the participants of the remittance transaction M can include the real remitter, the real payee and the cover party different from the two at the same time. These users constitute a total of n participants, and the n participants all participate in the remittance and collection of the remittance transaction at the same time: for the real remitter, the real payee and the cover party are both false remitters; for the real payee, the real remitter and the cover party are both false payees, so that the identities of the real remitter and the real payee are hidden at the same time. Moreover, since each participant participates in the remittance and collection at the same time, the identity confusion between the remitter and the payee can be achieved, thereby further increasing the reliability of identity hiding.

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

[0173] After the remittance transaction M is completed, the transfer amount is remitted to each recipient's account. Figure 4 or Figure 5The account model shown makes the transfer amount actually transferred to the "income balance" of the corresponding account, so that the income balance increases by the corresponding transfer amount. Among them, for the false payee, since the transfer amount corresponding to the false payee is 0, the income balance of the corresponding account of the false payee is equivalent to no numerical change, and since the transfer amount is added to the "income balance" part instead of the "assets" part, it will not cause the assets with an asset amount of 0 to appear in the corresponding account of the false payee, avoiding the increase of account maintenance costs.

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

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

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

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

[0178] Step 704b, verifying the linkable ring signature, wherein the linkable ring signature is generated by the real remitter based on its own private key x_j, public key P_j and the public key P_i held by the fake remitter i; wherein, when the linkable ring signature passes the verification, the remittance transaction M is confirmed as having equal input and output.

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

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

[0181] Step 706, when the transaction execution conditions are met, execute the remittance transaction M, so that the income balance in the corresponding account of each payee increases by the corresponding transfer amount; the transaction execution conditions include: the key images I_1~I_m do not belong to the historical key image set, and the linkable ring signature passes the verification; wherein, the key images I_1~I_m are added to the historical key image set after the transaction is completed, and the to-be-spent assets ID_j_1~ID_j_m are maintained and recorded on the blockchain ledger as assets in the corresponding account of the real remitter.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0196]

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

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

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

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

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

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

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

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

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

[0206] Step 808, verify range proofs RP_1~RP_u.

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

[0208] Step 810, verify whether key images I_1~I_(m+1) already exist.

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

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

[0211] Please refer to Fig.10 In a software implementation, the implementation device of the confidential blockchain transaction using a ring signature may include:

[0212] The participant determination unit 1001 determines all participants of the remittance transaction M, each participant having a corresponding account on the blockchain ledger, the account including an income balance whose value is recorded as a corresponding commitment value and a number of assets whose asset amount is recorded as an asset commitment;

[0213] The transaction assembly unit 1002 assembles the remittance transaction M according to the to-be-spent assets ID_j_1-ID_j_m in the corresponding account of the real remitter among the participants, the cover assets ID_i_1-ID_i_m in the corresponding account of the fake remitter i, and the committed value of the transfer amount corresponding to each payee among the participants;

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

[0215] The transaction submission unit 1004 submits the signed remittance transaction M to the blockchain network; wherein, after the transaction is completed, the income balance in the corresponding account of each payee is increased by the corresponding transfer amount, the key images I_1~I_m are added to the historical key image set, and the to-be-spent assets ID_j_1~ID_j_m are maintained and recorded on the blockchain ledger as assets in the corresponding account of the real remitter.

[0216] Optionally, the false remittance party includes: participants other than the real remittance party and the real payee; or, the false remittance party includes: participants other than the real remittance party.

[0217] Optionally, the payee includes a real payee and a false payee; wherein the transfer amount corresponding to the false payee is 0.

[0218] Optionally, when there is no change, the real payee includes: the initial remittance object; when there is change, the real payee includes: the initial remittance object and the real remittance party; wherein the false payee includes: participants other than the real payee.

[0219] Optional,

[0220] The assets in the corresponding account of the participant include: assets generated by dividing at least a portion of the income balance in the corresponding account; or,

[0221] The participant's corresponding account also includes a main balance, which is recorded as a corresponding commitment value on the blockchain ledger; wherein the assets in the participant's corresponding account include: assets generated by dividing at least a portion of the main balance in the corresponding account.

[0222] Optionally, when the participant's corresponding account includes a main balance, the income balance in the corresponding account is also merged into the main balance in the corresponding account under the instruction of the merge command.

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

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

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

[0226] Optionally, also include:

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

[0228] Optionally, the signature generation unit 1003 is specifically used for:

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

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

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

[0232] Optionally, also include:

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

[0234] Optionally, the signature generation unit 1003 is specifically used for:

[0235] Generate the intermediate parameters L_j_d, R_j_d, L_j_(m+1), R_j_(m+1) corresponding to the real remitter, and the intermediate parameters L_i_d, R_i_d, L_i_(m+1), R_i_(m+1) corresponding to the fake remitter i, d∈[1,m]; among them, the intermediate parameters L_j_d and L_i_d conform to the circular value rule, and the intermediate parameters L_j_(m+1) and L_i_(m+1) conform to the circular value rule. The circular value rule, the intermediate parameters R_j_d and R_i_d comply with the circular value rule, the intermediate parameters R_j_(m+1) and R_i_(m+1) comply with the circular value 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), R_i_(m+1) are related to at least one selected random number and / or its derivative value;

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

[0237] Optional,

[0238] 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;

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

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

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

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

[0243] Optionally, also include:

[0244] The asset deletion unit 1007 initiates an asset deletion request to the blockchain network to delete at least a portion of the assets that have been spent in the corresponding account of the real remitter from the blockchain account book.

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

[0246] Please refer to Fig.12 In a software implementation, the implementation device of the confidential blockchain transaction using a ring signature may include:

[0247] The transaction receiving unit 1201 receives a remittance transaction M, wherein each participant of the remittance transaction M has a corresponding account on the blockchain ledger, and the account includes an income balance whose value is recorded as a corresponding commitment value and a number of assets whose asset amount is recorded as an asset commitment; wherein the remittance transaction M is generated by the real remitter among the participants according to the to-be-spent assets ID_j_1 to ID_j_m in its corresponding account, the cover assets ID_i_1 to ID_i_m in the corresponding account of the fake remitter i, and the commitment value of the transfer amount corresponding to each payee among the participants;

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

[0249] The signature verification unit 1203 verifies the linkable ring signature, which is generated by the real remitter according to its own private key x_j, public key P_j and the public key P_i held by the fake remitter i; wherein, when the linkable ring signature passes the verification, the remittance transaction M is confirmed as equal in input and output;

[0250] The transaction execution unit 1204 executes the remittance transaction M when the transaction execution conditions are met, so that the income balance in the corresponding account of each payee increases by the corresponding transfer amount; the transaction execution conditions include: the key images I_1~I_m do not belong to the historical key image set and the linkable ring signature passes the verification; wherein, the key images I_1~I_m are added to the historical key image set after the transaction is completed, and the to-be-spent assets ID_j_1~ID_j_m are maintained and recorded on the blockchain ledger as assets in the corresponding account of the real remitter.

[0251] Optionally, the false remittance party includes: participants other than the real remittance party and the real payee; or, the false remittance party includes: participants other than the real remittance party.

[0252] Optionally, the payee includes a real payee and a false payee; wherein the transfer amount corresponding to the false payee is 0.

[0253] Optionally, when there is no change, the real payee includes: the initial remittance object; when there is change, the real payee includes: the initial remittance object and the real remittance party; wherein the false payee includes: participants other than the real payee.

[0254] Optional,

[0255] The assets in the corresponding account of the participant include: assets generated by dividing at least a portion of the income balance in the corresponding account; or,

[0256] The participant's corresponding account also includes a main balance, which is recorded as a corresponding commitment value on the blockchain ledger; wherein the assets in the participant's corresponding account include: assets generated by dividing at least a portion of the main balance in the corresponding account.

[0257] Optionally, also include:

[0258] The balance merging unit 1205, when the corresponding account of the participant includes a main balance, merges the income balance in the corresponding account into the main balance in the corresponding account according to the merging command issued by the participant.

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

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

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

[0262] Optionally, also include:

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

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

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

[0266] Optionally, the linkable ring signature is generated by the real remitter according to its own private key x_j, public key P_j, pseudo private key r” and pseudo public key P”_j, and the public key P_i and pseudo public key P”_i corresponding to the fake remitter i, and 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)], pseudo private key r"=(r_j_1+…+r_j_m)-(r'_1+…+r'_u), pseudo public key P"_i=[PC{i,1}+…+PC{i,m}]-[PC(t'_1,r'_1)+…+PC(t'_u,r'_u)], i∈[1,j-1]∪[j+1,n];

[0267] Among them, asset identifiers ID_j_1~ID_j_m correspond to asset amounts t_j_1~t_j_m, random numbers r_j_1~r_j_m and asset commitments PC(t_j_1,r_j_1)~PC(t_j_m,r_j_m), covering assets ID_i_1~ID_i_m correspond to asset commitments PC{i,1}~PC{i,m}, and payees Q_1~Q_u correspond to transfer amounts t'_1~t'_u, random numbers r'_1~r'_u and transfer amount commitments PC(t'_1,r'_1)~PC(t'_u,r'_u), u≥1.

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

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

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

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

[0272] Optional,

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

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

[0275] The circular value rule between the intermediate parameters L_j_d and L_i_d includes: L_k_d = (s_k_d × G + c_k × P_k) mod p; wherein s_k_d belongs to the number field Z_q where the elliptic curve is located, and Hash() is a hash function from the elliptic curve to the number field Z_q;

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

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

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

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

[0280] Optionally, also include:

[0281] The asset deletion unit 1207 deletes at least a portion of the assets that have been spent in the corresponding account of any participant from the blockchain ledger according to an asset deletion request initiated by any participant to the blockchain network.

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

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

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

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

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

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

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

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

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

Claims

1. A method for implementing confidential blockchain transactions using ring signatures, comprising: Determine all participants in the remittance transaction M, each of whom has a corresponding account on the blockchain ledger, including a revenue balance whose value is recorded as the corresponding commitment value and a number of assets whose asset amount is recorded as the asset commitment; Assemble the remittance transaction M according to the to-be-spent assets ID_j_1~ID_j_m in the corresponding account of the real remitter among the participants, the cover assets ID_i_1~ID_i_m in the corresponding account of the fake remitter i, and the committed value of the transfer amount corresponding to each payee among the participants; Generate a linkable ring signature for the remittance transaction M according to the private key x_j, public key P_j held by the real remitter and the public key P_i held by the fake remitter i, wherein the linkable ring signature contains key images I_1~I_m, and the values ​​of the key images I_1~I_m are related to the private key x_j, public key P_j and asset identifiers ID_j_1~ID_j_m of the real remitter, so that the values ​​of the key images I_1~I_m correspond to the assets ID_j_1~ID_j_m to be spent one by one; Submit the signed remittance transaction M to the blockchain network; after the transaction is completed, the income balance in the corresponding account of each payee is increased by the corresponding transfer amount, the key images I_1~I_m are added to the historical key image set, and the to-be-spent assets ID_j_1~ID_j_m are maintained and recorded on the blockchain ledger as assets in the corresponding account of the real remitter.

2. According to the method of claim 1, the false remittance party comprises: Participants other than the real remitter and the real recipient; Alternatively, the false remittance remitter includes: a participant other than the real remittance remitter.

3. According to the method of claim 1, the payee includes a real payee and a fake payee; wherein, The transfer amount corresponding to the false recipient is 0.

4. The method according to claim 3, when there is no change, the real payee comprises: The initial remittance recipient; When there is change, the real payee includes: the initial remittance object and the real remittance party; wherein the false payee includes: participants other than the real payee.

5. The method according to claim 1, The assets in the participants’ corresponding accounts include: An asset created by dividing at least a portion of the income balance in the corresponding account; or, The participant's corresponding account also includes a main balance, which is recorded as a corresponding commitment value on the blockchain ledger; wherein the assets in the participant's corresponding account include: assets generated by dividing at least a portion of the main balance in the corresponding account.

6. The method according to claim 5, when the participant's corresponding account includes a main balance, the income balance in the corresponding account is also merged into the main balance in the corresponding account under the instruction of a merge command.

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

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

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

10. The method according to claim 9, further comprising: According to the pseudo private key r” and pseudo public key P”_j corresponding to the real remitter, a key image I_(m+1)=r”×Hash_G(P”_j) is generated; wherein the linkable ring signature also includes the key image I_(m+1).

11. The method according to claim 9, generating a linkable ring signature for the remittance transaction M according to the private key x_j, public key P_j, pseudo private key r", pseudo public key P"_j corresponding to the real remitter, and the public key P_i and pseudo public key P"_i corresponding to the fake remitter i, comprising: Generate the intermediate parameters L_j_d, R_j_d, L_j_(m+1), R_j_(m+1) corresponding to the real remitter, and the intermediate parameters L_i_d, R_i_d, L_i_(m+1), R_i_(m+1) corresponding to the fake remitter i, d∈[1,m]; among them, the intermediate parameters L_j_d and L_i_d conform to the circular value rule, and the intermediate parameters L_j_(m+1) and L_i_(m+1) conform to the circular value rule. The circular value rule, the intermediate parameters R_j_d and R_i_d comply with the circular value rule, the intermediate parameters R_j_(m+1) and R_i_(m+1) comply with the circular value 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), R_i_(m+1) are related to at least one selected random number and / or its derivative value; A linkable ring signature for the remittance transaction M is generated based on the selected random number and / or its derivative value.

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

13. The method according to claim 1, further comprising: Initiate an asset deletion request to the blockchain network to delete at least a portion of the assets that have been spent in the corresponding account of the real remitter from the blockchain ledger.

14. A method for implementing confidential blockchain transactions using ring signatures, comprising: Receive a remittance transaction M, where each participant of the remittance transaction M has a corresponding account on the blockchain ledger, and the account includes an income balance whose value is recorded as a corresponding commitment value and a number of assets whose asset amount is recorded as an asset commitment; wherein the remittance transaction M is generated by the real remitter among the participants according to the to-be-spent assets ID_j_1 to ID_j_m in its corresponding account, the cover assets ID_i_1 to ID_i_m in the corresponding account of the fake remitter i, and the commitment value of the transfer amount corresponding to each payee among the participants; Obtain the key images I_1~I_m contained in the linkable ring signature of the remittance transaction M, wherein the values ​​of the key images I_1~I_m are related to the private key x_j, the public key P_j and the asset identifiers ID_j_1~ID_j_m of the real remitter, so that the values ​​of the key images I_1~I_m correspond one to one with the assets ID_j_1~ID_j_m to be spent; Verify the linkable ring signature, which is generated by the real remitter based on its own private key x_j, public key P_j and the public key P_i held by the fake remitter i; wherein, when the linkable ring signature passes the verification, the remittance transaction M is confirmed as equal in input and output; When the transaction execution conditions are met, the remittance transaction M is executed, so that the income balance in the corresponding account of each payee is increased by the corresponding transfer amount; the transaction execution conditions include: the key images I_1~I_m do not belong to the historical key image set and the linkable ring signature passes the verification; wherein, the key images I_1~I_m are added to the historical key image set after the transaction is completed, and the to-be-spent assets ID_j_1~ID_j_m are maintained and recorded on the blockchain ledger as assets in the corresponding account of the real remitter.

15. The method according to claim 14, wherein the fake remittance remitter comprises: Participants other than the real remitter and the real recipient; Alternatively, the false remittance remitter includes: a participant other than the real remittance remitter.

16. The method according to claim 14, wherein the payee includes a real payee and a fake payee; wherein, The transfer amount corresponding to the false recipient is 0.

17. The method according to claim 16, when there is no change, the real payee comprises: The initial remittance recipient; When there is change, the real payee includes: the initial remittance object and the real remittance party; wherein the false payee includes: participants other than the real payee.

18. The method according to claim 14, The assets in the participants’ corresponding accounts include: An asset created by dividing at least a portion of the income balance in the corresponding account; or, The participant's corresponding account also includes a main balance, which is recorded as a corresponding commitment value on the blockchain ledger; wherein the assets in the participant's corresponding account include: assets generated by dividing at least a portion of the main balance in the corresponding account.

19. The method according to claim 18, further comprising: When the corresponding account of a participant includes a main balance, the income balance in the corresponding account will be merged into the main balance in the corresponding account according to the merge command issued by the participant.

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

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

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

23. The method according to claim 14, wherein the linkable ring signature is generated by the real remitter according to its own private key x_j, public key P_j, pseudo private key r" and pseudo public key P"_j, and the public key P_i and pseudo public key P"_i corresponding to the fake remitter i, and 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)], pseudo private key r"=(r_j_1+...+r_j_m)-(r'_1+...+r'_u), pseudo public key P"_i=[PC{i,1}+…+PC{i,m}]-[PC(t'_1,r'_1)+…+PC(t'_u,r'_u)], i∈[1,j-1]∪[j+1,n], i, j and n are positive integers, n≧2; in, Asset identifiers ID_j_1~ID_j_m correspond to asset amounts t_j_1~t_j_m, random numbers r_j_1~r_j_m and asset commitments PC(t_j_1,r_j_1)~PC(t_j_m,r_j_m), covering asset ID_i_1~ID_i_m correspond to asset commitments PC{i,1}~PC{i,m}, and payees Q_1~Q_u correspond to transfer amounts t'_1~t'_u, random numbers r'_1~r'_u and transfer amount commitments PC(t'_1,r'_1)~PC(t'_u,r'_u), u≥1.

24. The method according to claim 23, wherein the linkable ring signature further comprises a key image I_(m+1)=r"×Hash_G(P"_j); in, The transaction execution condition also includes: the key image I_(m+1) does not belong to the historical key image set.

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

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

27. The method of claim 14, further comprising: According to an asset deletion request initiated by any participant to the blockchain network, at least a portion of the assets spent in the corresponding account of any participant is deleted from the blockchain ledger.

28. A device for implementing confidential blockchain transactions using ring signatures, comprising: A participant determination unit determines all participants of the remittance transaction M, each participant having a corresponding account on the blockchain ledger, the account including a revenue balance whose value is recorded as a corresponding commitment value and a number of assets whose asset amount is recorded as an asset commitment; The transaction assembly unit assembles the remittance transaction M according to the to-be-spent assets ID_j_1 to ID_j_m in the corresponding account of the real remitter among the participants, the cover assets ID_i_1 to ID_i_m in the corresponding account of the fake remitter i, and the committed value of the transfer amount corresponding to each payee among the participants; The signature generation unit generates a linkable ring signature for the remittance transaction M according to the private key x_j and public key P_j held by the real remitter and the public key P_i held by the fake remitter i, wherein the linkable ring signature includes key images I_1 to I_m, and the values ​​of the key images I_1 to I_m are related to the private key x_j, public key P_j and asset identifiers ID_j_1 to ID_j_m of the real remitter, so that the values ​​of the key images I_1 to I_m correspond one to one with the assets ID_j_1 to ID_j_m to be spent; The transaction submission unit submits the signed remittance transaction M to the blockchain network; wherein, after the transaction is completed, the income balance in the corresponding account of each payee is increased by the corresponding transfer amount, the key images I_1~I_m are added to the historical key image set, and the to-be-spent assets ID_j_1~ID_j_m are maintained and recorded on the blockchain ledger as assets in the corresponding account of the real remitter.

29. A device for implementing confidential blockchain transactions using ring signatures, comprising: A transaction receiving unit receives a remittance transaction M, wherein each participant of the remittance transaction M has a corresponding account on the blockchain ledger, and the account includes an income balance whose value is recorded as a corresponding commitment value and a number of assets whose asset amount is recorded as an asset commitment; wherein the remittance transaction M is generated by the real remitter among the participants according to the to-be-spent assets ID_j_1 to ID_j_m in its corresponding account, the cover assets ID_i_1 to ID_i_m in the corresponding account of the fake remitter i, and the commitment value of the transfer amount corresponding to each payee among the participants; An image acquisition unit acquires key images I_1-I_m contained in the linkable ring signature of the remittance transaction M, wherein the values ​​of the key images I_1-I_m are related to the private key x_j, the public key P_j and the asset identifiers ID_j_1-ID_j_m of the real remitter, so that the values ​​of the key images I_1-I_m correspond to the assets ID_j_1-ID_j_m to be spent one by one; A signature verification unit verifies the linkable ring signature, wherein the linkable ring signature is generated by the real remitter according to its own private key x_j, public key P_j and public key P_i held by the fake remitter i; wherein, when the linkable ring signature passes the verification, the remittance transaction M is confirmed as equal in input and output; The transaction execution unit executes the remittance transaction M when the transaction execution conditions are met, so that the income balance in the corresponding account of each payee increases by the corresponding transfer amount; the transaction execution conditions include: the key images I_1~I_m do not belong to the historical key image set and the linkable ring signature passes the verification; wherein the key images I_1~I_m are added to the historical key image set after the transaction is completed, and the to-be-spent assets ID_j_1~ID_j_m are maintained and recorded on the blockchain ledger as assets in the corresponding account of the real remitter.

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

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

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

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

Images