CN110009323A - Block chain transaction method and device, electronic equipment and storage medium - Google Patents

Abstract

One or more embodiments of the present specification provide a blockchain transaction method and apparatus, an electronic device, and a storage medium, which are applied to a remitter device, where the method includes: determining a transaction amount to be remitted from a remittance account to a recipient account, the remittance account including a remittance primary balance using a commitment amount, a remittance income balance using the commitment amount, and a remittance expenditure balance of a plaintext amount, the recipient account including a recipient primary balance using the commitment amount, a recipient income balance using the commitment amount, and a recipient expenditure balance of the plaintext amount; and submitting public transfer transaction to a blockchain, wherein the public transfer transaction comprises a public transaction amount corresponding to the public transaction amount, so that the public transaction amount is deducted from the remittance expenditure balance after the transaction is completed, and the public transaction amount is increased after the transaction is completed by the receiver expenditure balance.

Description

Blockchain transaction method and device, electronic device, storage medium

technical field

One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a blockchain transaction method and device, electronic equipment, and storage medium.

Background technique

The blockchain can maintain a unified blockchain ledger among the blockchain nodes by reaching a consensus among the blockchain nodes to permanently record the transaction information that occurs in the blockchain network. The blockchain ledger is completely public, so that the historical data of the transactions that have occurred can be viewed and verified at any time.

SUMMARY OF THE INVENTION

In view of this, one or more embodiments of this specification provide a blockchain transaction method and device, an electronic device, and a storage medium.

One or more embodiments of this specification provide technical solutions as follows:

According to a first aspect of one or more embodiments of the present specification, a blockchain transaction method is proposed, applied to a sender device, and the method includes:

Determine the transaction amount to be remitted from the sender's account to the recipient's account, which includes the sender's main balance in the committed amount, the sender's income balance in the committed amount, and the sender's payout in the express amount Balance, the receiver's account includes the receiver's main balance using the committed amount, the receiver's income balance using the committed amount, and the receiver's expenditure balance using the clear text amount;

Submit a public transfer transaction to the blockchain, and the public transfer transaction includes the public transaction amount corresponding to the public transaction amount, so that the sender's expenditure balance deducts the public transaction amount and the recipient's expenditure after the transaction is completed. The balance is added to the public transaction amount after the transaction is completed.

According to a second aspect of one or more embodiments of the present specification, a blockchain transaction device is proposed, which is applied to a sender device, and the device includes:

A determination unit, which determines the transaction amount to be remitted from the sender's account to the receiver's account, where the sender's account includes the sender's main balance using the committed amount, the sender's income balance using the promised amount, and the clear-text amount of the remittance. The sender's expenditure balance, the receiver's account includes the receiver's main balance using the committed amount, the receiver's income balance using the committed amount, and the receiver's expenditure balance using the plaintext amount;

The submitting unit submits a public transfer transaction to the blockchain, where the public transfer transaction includes the public transaction amount corresponding to the public transaction amount, so that after the transaction is completed, the payout balance of the sender deducts the public transaction amount, the public transaction amount, and the The recipient payout balance increases the public transaction amount after the transaction is completed.

According to a third aspect of one or more embodiments of the present specification, an electronic device is proposed, including:

processor;

memory for storing processor-executable instructions;

Wherein, the processor implements the method according to the first aspect by executing the executable instructions.

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

Description of drawings

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

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

FIG. 3 is a flowchart of an account creation method provided by an exemplary embodiment.

FIG. 4 is a schematic diagram of a blockchain account structure provided by an exemplary embodiment.

Fig. 5 is a flowchart of a blockchain transaction method provided by an exemplary embodiment.

FIG. 6 is a flowchart of a limited disclosure remittance transaction based on a spending balance, provided by an exemplary embodiment.

FIG. 7 is a schematic diagram of changes in account balances before and after remittance according to an exemplary embodiment.

FIG. 8 is a schematic diagram of another blockchain account structure provided by an exemplary embodiment.

FIG. 9 is an interactive schematic diagram of recharging the spending balance with the main balance according to an exemplary embodiment.

FIG. 10 is a schematic diagram of changes in account balances before and after recharging provided by an exemplary embodiment.

FIG. 11 is an interactive schematic diagram of a merge operation provided by an exemplary embodiment.

FIG. 12 is a schematic diagram of changes in account balances before and after consolidation provided by an exemplary embodiment.

FIG. 13 is a flowchart of another blockchain transaction method provided by an exemplary embodiment.

FIG. 14 is a flow chart of a fully privacy-based remittance transaction based on a master balance provided by an exemplary embodiment.

FIG. 15 is a schematic diagram of another account balance change before and after remittance provided by an exemplary embodiment.

Fig. 16 is a flowchart of yet another blockchain transaction method provided by an exemplary embodiment.

FIG. 17 is a flow chart of a public remittance transaction implemented based on a spending balance provided by an exemplary embodiment.

FIG. 18 is a schematic diagram of another account balance change before and after remittance provided by an exemplary embodiment.

FIG. 19 is a schematic structural diagram of a device provided by an exemplary embodiment.

Fig. 20 is a block diagram of a blockchain transaction apparatus provided by an exemplary embodiment.

Detailed ways

Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. Where the following description refers to the drawings, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatus and methods consistent with some aspects of one or more embodiments of this specification, as recited in the appended claims.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than 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 also be combined into a single step in other embodiments. describe.

FIG. 1 is a schematic diagram of an example environment provided by an example embodiment. As shown in FIG. 1 , an example environment 100 allows entities to participate in a blockchain network 102 . The blockchain network 102 may be a public type, a private type or a consortium type of 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 It combines and connects to websites, user devices (eg, computing devices) and back-end systems. In one embodiment, the network 114 may be accessed through wired and/or wireless communications.

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 interconnected by a network and functioning as a distributed processing system Working on multiple computers.

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

In one embodiment, the computing devices 104 to 108 store blockchain ledgers corresponding to the blockchain network 102, respectively. Computing device 104 may be (or include) a web server for providing browser functionality that 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 instead monitor blockchain network 102 to determine when other nodes (eg, which may include computing devices 106-108) reach consensus and generate corresponding blocks accordingly Chain visualization user interface.

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

In response to the above request, computing device 104 may generate a blockchain visualization user interface (eg, a web page) based on the stored blockchain ledger, and transmit the generated blockchain visualization user interface to the requesting client device. If the blockchain network 102 is a private-type or consortium-type blockchain network, the request for the blockchain visualization user interface may include user authorization information before the blockchain visualization user interface is generated and sent to the requesting client device , the user authorization information can be verified by the computing device 104, and the corresponding blockchain visual user interface is returned after the verification is passed.

The blockchain visualization user interface may be displayed on the client device (eg, may be displayed in the user interface 116 shown in FIG. 1 ). When the blockchain ledger is updated, the display content of the user interface 116 may also be updated accordingly. In addition, user interaction with user interface 116 may result in requests for other user interfaces, such as displaying a block list, block details, transaction list, transaction details, account list, account details, contract list, contract details, or the user's interest in blocks The search result page, etc. generated by the chain network implementing the search.

Figure 2 is a schematic diagram of a conceptual architecture provided by an exemplary embodiment. As shown in FIG. 2 , the conceptual architecture 200 includes an entity layer 202 , a managed services layer 204 and a blockchain network layer 206 . For example, the entity layer 202 may include three entities: Entity 1, Entity 2, and Entity 3, each of which has its own transaction management system 208.

In one embodiment, the managed services layer 204 may include an interface 210 corresponding to each transaction management system 208 . For example, each transaction management system 208 communicates with a respective interface 210 over a network (eg, network 114 in FIG. 1 ) using a protocol (eg, Hypertext Transfer Protocol Secure (HTTPS), etc.). In some examples, each interface 210 may provide a communication connection between the respective transaction management system 208 and the blockchain network layer 206 ; 212 Communications. In some examples, the communication between the interface 210 and the blockchain network layer 206 may be implemented using Remote Procedure Calls (RPCs). In some examples, interface 210 may provide transaction management system 208 with an API interface for accessing blockchain network 212 .

As described herein, the blockchain network 212 is provided in the form of a peer-to-peer network that includes a plurality of nodes 214, each of which is used to persist the blockchain ledger 216 formed by the blockchain data; Among them, only one blockchain ledger 216 is shown in FIG. 2 , but there may be multiple blockchain ledgers 216 or copies thereof in the blockchain network 212 , for example, each node 214 can maintain a separate blockchain Ledger 216 or a copy thereof.

It should be pointed out that the transaction described in this specification refers to a piece of data that is created by the user through the client of the blockchain and needs to be finally released to the distributed database of the blockchain. Among them, transactions in the blockchain can be divided into narrow transactions and broad transactions. A transaction in a narrow sense refers to a transfer of value issued by a user to the blockchain; for example, in the traditional Bitcoin blockchain network, a transaction can be a transfer initiated by a user in the blockchain. In a broad sense, a transaction refers to a piece of business data with business intent released 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 that have nothing to do with value transfer. Online business (such as rental business, vehicle scheduling business, insurance claim business, credit service, medical service, etc.), and in this type of alliance chain, the transaction can be a business with business intent published by the user in the alliance chain message or business request.

In the technical solution of this specification, by improving the account structure in the blockchain, a new account transaction form can be realized, so that concurrent transactions under the account model can be realized under the premise of ensuring transaction privacy, thereby improving transaction throughput. .

FIG. 3 is a flowchart of an account creation method provided by an exemplary embodiment. As shown in Figure 3, the method is applied to a blockchain node, and the method includes:

Step 302: Receive a blockchain transaction, where the type of the blockchain transaction is an account creation type.

In one embodiment, a user may generate a blockchain transaction at the client and submit the blockchain transaction to the blockchain node through the client for processing by the blockchain node.

In one embodiment, the blockchain transaction contains several fields. For example, in the Ethereum blockchain, a blockchain transaction can usually include a from field, a to field, a data field, etc., to indicate the account address of the transaction initiator, the contract address of the smart contract to be invoked, and transaction-related content, etc., respectively. In the technical solution of this specification, a type field can be set in the blockchain transaction, and the content contained in the type field is used to indicate the type of the relevant blockchain transaction, so that the blockchain node can perform corresponding processing accordingly. . For example, blockchain transactions can be marked as account creation types so that blockchain nodes can create new accounts accordingly.

Step 304: Execute the blockchain transaction to create a first account, where the first account includes an income balance in a ciphertext amount and a payout balance in a plaintext amount.

Two transaction models are usually used in the blockchain network, namely the UTXO (Unspent Transaction Output) model and the account model. The typical application scenario of the UTXO model is the Bitcoin blockchain. The assets on the chain under this model exist in the form of transaction outputs. When there is an unspent transaction output in a transaction, the unspent transaction output is held by the private key. It is owned by the owner; when used, one or more unspent transaction outputs can be used as input, and one or more outputs are specified, thereby forming a new one or more unspent transaction outputs. Although the UTXO model is adopted by a variety of blockchain networks, the support for smart contracts is weak, which limits the application scenarios. The typical application scenario of the account model is the Ethereum blockchain. Under this model, by creating an account, the on-chain assets held by the account are represented as the balance corresponding to the account address. Each transfer transaction can transfer assets from an account address to Another account address, and the transaction amount is directly updated to the balance corresponding to the account address. Compared with the UTXO model, the account model can support complete smart contract functions and has better scene scalability.

For the purpose of transaction privacy protection, improvements to blockchain transactions have been proposed in related technologies. Under the UTXO model, the transaction amount can be protected through homomorphic encryption or homomorphic commitment technology, and interval proof technology can be used to ensure that the output of the transaction is non-negative, etc. Under the account model, the transaction amount can be protected by homomorphic encryption or homomorphic commitment technology, and the interval proof technology can be used to ensure that the transaction amount is non-negative and the account balance is sufficient to pay.

Under the UTXO model, one or more transaction outputs are used as the input of a transfer transaction, and one or more new transaction outputs are formed after the transfer is completed. It can be seen that a transaction output can only be spent in one transfer transaction and cannot be spent by multiple transfer transactions, so that the interval proof generated for a transfer transaction is only related to the input of the transfer transaction and has nothing to do with the input of other transfer transactions , so the UTXO model naturally has high transaction concurrency. Under the account model, the input of each transaction is the account balance, the interval proof of each transaction is related to the account balance, and the account balance will be updated after each transaction, making all transactions under the same account It needs to be executed in sequence, that is, after a transaction ends and the account balance is updated, the interval proof can be generated for the next transaction and the next transaction can be triggered. Otherwise, the transaction will be agreed because the interval proof is illegal. Node refuses to execute. Therefore, when using privacy-preserving techniques with interval proofs under the account model, the throughput of transactions will be severely hindered.

In order to solve the concurrency problem under the account model and ensure sufficient support for smart contract functions, this specification proposes improvements to the account structure under the account model in related technologies so that it can be adapted to high-throughput concurrent transactions.

Accounts in the blockchain network can include external accounts and contract accounts, etc. External accounts are usually owned by users (individuals or institutions), while contract accounts correspond to smart contracts in the blockchain. The structures of various types of accounts are similar. For example, as shown in Figure 4, the Nonce field, the Balance field, the Code field, and the Storage field can be included. The value of the Nonce field of each account starts from 0, and the value of the Nonce field increases sequentially with the transactions initiated by the corresponding account, so that each transaction initiated by the account contains a different value of Nonce, so as to avoid repeated Let go of the attack. The Balance field is used to store the balance. The Code field is used to store the code of the smart contract, so the Code field of the external account is usually empty. The Storage field is used to store the value of the account at the corresponding node in the state tree.

Without considering privacy protection, the value of the Balance field is the plaintext balance held by the account. In the case of considering privacy protection, the balance of plaintext can be generated into the corresponding ciphertext commitment through a mechanism such as Pedersen commitment, so that only the ciphertext commitment is recorded on the blockchain ledger, and only the holder can decrypt the ciphertext commitment. ; However, in this case, due to the limitation of interval proof, it has the problem of insufficient concurrency mentioned above. In this manual, the structure of the Balance field is improved, and the Balance field is further divided, for example, the Balance field contains the income balance and the expenditure balance, and the income balance is recorded in the blockchain ledger as the ciphertext amount, and the payment balance is in The amount is recorded in plaintext in the blockchain ledger.

Based on the above-mentioned improved account structure, when the first account is used as the sender's account to transfer money to the second account as the receiver's account, the relevant transfer process will be introduced in conjunction with FIG. 5 . Fig. 5 is a flowchart of a blockchain transaction method provided by an exemplary embodiment. As shown in FIG. 5 , the method is applied to the equipment of the exporter, and the method includes:

Step 502: Determine the corresponding debit amount according to the limited public transaction amount to be remitted from the sender's account to the receiver's account; wherein the sender's account includes the income balance of the promised amount and the expenditure balance of the plaintext amount.

In one embodiment, this specification provides a limited disclosure type of transfer transaction mode, in which a transfer transaction with privacy protection can be implemented by adopting the income balance of the promised amount and the expenditure balance of the plaintext amount.

In one embodiment, the debit amount can be any value not less than the limited public transaction amount. For example, the sender's account may set alternative deduction amounts for various transfer scenarios according to the pre-defined upper limit of the transfer amount in each type of transfer scenario to form a set of alternative deduction amounts. Alternatively, the value of each alternative deduction amount may also be determined according to other methods, which is not limited in this specification. Then, simply select a deduction amount not less than the limited public transaction amount. Of course, it is also possible to temporarily generate a deduction amount based on the value of the limited public transaction amount. The value of the deduction amount should preferably have nothing to do with the limited public transaction amount itself. Otherwise, when the algorithm for generating the deduction amount is leaked, it may cause criminals to inversely deduce the value of the limited public transaction amount based on the value of the deduction amount.

Step 504, submit a limited public transfer transaction to the blockchain, the limited public transfer transaction includes the limited public transaction amount commitment corresponding to the limited public transaction amount, the deduction amount, and the amount used to prove that the transaction amount is non-negative and The deduction amount is not less than the interval proof of the limited public transaction amount.

In one embodiment, after the limited public transfer transaction is completed, the deduction amount can be deducted from the expenditure balance after the transaction is completed, and the deduction amount can be added to the income balance after the transaction is completed and the deduction amount is deducted. The limited public transaction amount (that is, the change amount is increased, and the value of the change amount is the difference between the deduction amount and the limited public transaction amount), and the recipient account increases the limited public transaction amount after the transaction is completed. Then, when the deduction amount is deducted from the expenditure balance, since the expenditure balance and the deduction amount are both in plaintext, it is not necessary to generate an interval proof of sufficient balance (the plaintext amount can be directly compared), so that between the transfer transaction and the remittance The balances of the outgoing accounts are unbound, enabling concurrent transactions under the account model. At the same time, since the income balance is in the form of the commitment amount, the amount of change added to the income balance is also recorded in the commitment amount, and because the limited public transaction amount is also expressed as the corresponding commitment amount, only the exposed amount is exposed in the entire transaction process. The deduction amount and the remaining amount in plaintext are all commitment amounts in the form of ciphertext, so it can ensure sufficient privacy protection while realizing concurrent transactions.

In one embodiment, when the limited open transaction amount is added to the recipient's account after the transaction is completed, if the recipient's account adopts the account structure of this specification, the limited open transaction amount can be added to the income balance of the recipient's account. . Specifically, since the income balance of the receiver's account is in the form of a committed amount, the limited public transaction amount will also be added to the income balance of the receiver's account in the form of a corresponding committed amount. Similarly, when the sender's balance of the sender's account increases, eg, when an account transfers money to the sender's account, the corresponding amount is added to the income balance of the sender's account.

It can be seen that by setting the income balance of the committed amount and the expenditure balance of the clear text amount in the account structure, not only can the concurrent transactions under the account model be realized while ensuring transaction privacy, but also the remittance transactions that the same account participates in can be transferred. The decoupling from the inward transaction ensures that the account of the sender can participate in the outward transaction and the inward transaction at the same time, which can improve the transaction throughput.

The implementation process of limited public transaction is described below by taking user A as the sender and user B as the receiver as examples. Fig. 6 is a flow chart of a limited public remittance transaction based on expenditure balance provided by an exemplary embodiment; as shown in Fig. 6, the interaction process between the sender, the receiver and the blockchain node may include: The following steps:

Step 601, the sender determines the transfer amount t.

In one embodiment, the sender refers to a role that remits resources such as money in a remittance transaction, and correspondingly, the receiver refers to a role that receives resources such as money in a remittance transaction. For example, the user equipment used by user A may be configured as the sender, and the user equipment used by user B may be configured as the receiver.

In one embodiment, when drafting the remittance transaction, the remittance amount t can be negotiated between the sender and the receiver. Of course, the sender can also determine the remittance amount t by itself, which will be confirmed by the receiver in subsequent steps.

Step 602, the sender determines the random number r corresponding to the remittance amount t.

In one embodiment, the sender can generate a random number r for the remittance amount t based on the Pedersen commitment mechanism, and the remittance commitment T=PC(t,r) corresponding to the remittance amount t, where PC() is a preset algorithm.

Step 603, the sender sends (r, t, T) to the receiver through the off-chain channel.

In one embodiment, by sending (r, t, T) through the off-chain channel instead of the blockchain network, the remittance random number r and the remittance amount t can be prevented from being recorded in the blockchain ledger, and the remittance amount can be ensured. tAgnostic other than the sender and receiver.

Step 604, the receiver verifies the received (r, t, T).

In one embodiment, the receiver can verify the remittance amount t to determine the amount of the remittance desired to be collected.

In one embodiment, the receiver can verify the remittance commitment T, that is, the receiver can calculate the random number r and the remittance amount t through the Perdersen commitment mechanism to verify whether the remittance commitment T=PC(t,r) is correct, If it is correct, it means that the verification is passed, otherwise the verification is not passed.

Step 605, after the receiver passes the verification, a signature is generated and returned to the sender.

In one embodiment, after the verification is passed, the receiver can use the receiver's private key to sign (A, B:T), generate a signature SigB and return it to the sender. The signature SigB indicates that the recipient agrees to implement the remittance transaction committed to T by user A's blockchain account 1 to user B's blockchain account 2.

Step 606, after receiving the signature SigB, the sender generates the interval proof PR according to the deduction amount L.

In one embodiment, the debit amount L is determined by the sender according to the transfer amount t. For example, the sender can maintain a number of deduction amounts L1 to Ln in advance, and the sender can choose a deduction amount L at will, as long as t≤L≤w, where w is user A's blockchain account The value of the spending balance in 1.

In one embodiment, the sender may determine the deduction amount L at any time before generating the interval proof PR, which is not limited in this specification.

In one embodiment, in order to ensure the successful completion of the remittance transaction, the blockchain node needs to determine that the remittance amount t and the deduction amount L satisfy the following conditions: 0≤t≤L; It can be used to verify whether the transaction meets the preset conditions in the text state. For example, the Bulletproofs scheme and the Borromean ring signature scheme in related technologies can be used in this specification to realize, but this specification does not limit this. The sender can use the interval proof technology to generate the interval proof PR for verification by the blockchain node in the subsequent process whether 0≤t≤L is satisfied.

Step 607, the exporter signs the transaction content (A, B: T, L, PR; SigB) to generate a signature SigA.

In one embodiment, the sender can use the sender's private key to sign the transaction content (A, B: T, L, PR; SigB) to generate the signature SigA.

Step 608, the exporter submits the transaction to the blockchain.

In one embodiment, the remittance party is configured as a client of the blockchain, and can submit the remittance transaction to a certain blockchain node in the blockchain network, and then transmit it to all the blockchain nodes in the blockchain network. The blockchain node, and each blockchain node verifies the remittance transaction separately, so as to perform the remittance operation when the verification is passed, and reject the remittance when the verification fails.

Step 609, the blockchain node checks whether the transaction has been executed.

In one embodiment, the blockchain node here may represent any blockchain node in the blockchain network, that is, each blockchain node in the blockchain network will receive the above remittance transaction, and Operations such as verification are performed through steps 609 to 612 and the like.

In one embodiment, after receiving the above-mentioned remittance transaction, the blockchain node can use the anti-double-spending or anti-replay mechanism in the related art to verify whether the remittance transaction has been executed; if it has been executed, it can refuse to execute. The remittance transaction, otherwise, go to step 610.

Step 610, the blockchain node checks the signature.

In one embodiment, the blockchain node can check whether the signatures SigA and SigB included in the remittance transaction are correct; if not, the remittance transaction can be refused to be executed, otherwise, go to step 611 .

Step 611, the blockchain node checks the interval proof PR.

In one embodiment, the blockchain node may check the interval proof PR included in the remittance transaction based on the interval proof technology to determine whether 0≤t≤L is satisfied. If not satisfied, the remittance transaction can be rejected, otherwise, go to step 612.

Step 612, the blockchain node checks whether the spending balance is sufficient.

In one embodiment, since the expenditure balance w of the blockchain account 1 is recorded in the blockchain ledger in plaintext, the blockchain node can directly read the expenditure balance w of the blockchain account 1, and store the expenditure balance w of the blockchain account 1 directly. The disbursement balance w is compared with the debit amount L to determine that the disbursement balance is sufficient when w≥L.

Therefore, in step 606, the sender only needs to generate the above-mentioned interval proof PR for the transaction amount t and the deduction amount L, but does not need to generate the corresponding interval proof for the deduction amount L and the expenditure balance w, which can save the The generation process of interval proof can improve the efficiency of transaction generation, and it can save the verification process of interval proof and improve the execution efficiency of transaction.

Step 613: The blockchain node updates the blockchain accounts corresponding to user A and user B in the maintained blockchain ledger.

In one embodiment, after passing the verification in steps 609 to 612, the blockchain node can update the blockchain account 1 and the blockchain account 2 recorded in the blockchain ledger respectively, as shown in Figure 7:

In user A's blockchain account 1, the income balance before the transaction is v, which is recorded as the corresponding commitment amount PC(v,y) in the blockchain ledger, and the expenditure balance before the transaction is w. The chain ledger is recorded as the plaintext amount w. After the transaction is completed, the expenditure balance is deducted from the above-mentioned deduction amount L, so it is recorded as the plaintext amount w-L in the blockchain ledger, while the income balance is increased by the change amount, that is, the deduction amount L and the remittance amount t The difference is recorded in the blockchain ledger as the corresponding commitment amount PC(v,y)+PC(L,0)-PC(t,r), where PC(L,0) is the deduction amount L The corresponding commitment value (the pre-agreed random number is 0; of course, other agreed-upon values can also be used).

In user B's blockchain account 2, the income balance before the transaction is v', which is recorded as the corresponding commitment amount PC(v', y') in the blockchain ledger, and the expenditure balance before the transaction is w' , is recorded as the plaintext amount w' in the blockchain ledger. After the transaction is completed, the expenditure balance w' remains unchanged, while the income balance increases the remittance amount t, so it is recorded in the blockchain ledger as the corresponding commitment amount PC(v',y')+PC(t,r ).

As mentioned above, when the account contains the above-mentioned income balance and expenditure balance, high concurrent transfers under the account model can be achieved while ensuring transaction privacy. However, the amount of the outgoing balance is declining, as all incoming funds are credited to the incoming balance and all outgoing funds are deducted from the outgoing balance. In order to ensure that the amount of the spending balance is always sufficient to complete the transaction, the spending balance can be recharged periodically or at any time.

Although it is possible to recharge from the income balance to the expenditure balance, but: because the expenditure balance itself exists in the form of clear text, it actually exposes part of the privacy to a limited extent (indicating that the balance in the relevant account is not less than the value of the expenditure balance) , so users often do not want to make the amount of the spending balance too high to control and limit the scope of exposure to privacy. Then, when the account's outbound transactions are frequent and the transaction amount is large, the expenditure balance needs to be recharged frequently, resulting in the frequent participation of the income balance in the remittance and remittance (recharge) of funds, and even the inward transaction and recharge transaction. Corresponding impact, but lead to a decrease in efficiency.

Therefore, this specification proposes further improvements to the account structure shown in FIG. 4 . For example, as shown in FIG. 8, a main balance can be further added in the Balance field, so that the Balance field contains three balances in total: main balance, income balance and expenditure balance. Among them, the income balance is dedicated to receiving the transaction amount of the incoming transaction, the expenditure balance is dedicated to participating in the outgoing transaction, and the main balance is used to recharge the expenditure balance, so as to avoid the recharge task of the income balance and prevent the occurrence of the above-mentioned problems. influences.

FIG. 9 is an interactive schematic diagram of recharging the spending balance with the main balance according to an exemplary embodiment. As shown in Figure 9, the interaction process may include the following steps:

Step 901, the sender determines the recharge amount m.

In one embodiment, the recharge amount m may be any amount, as long as the amount of the main balance of the sender is sufficient. For example, a maximum water level can be set for the spending balance, and the recharge amount m can be the difference between the maximum water level and the remaining value of the spending balance.

Step 902, the exporter generates an interval proof RF.

In one embodiment, since the value u of the main balance is recorded as the corresponding commitment amount PC(u,x) in the blockchain ledger, where x is the random number corresponding to u, it is necessary to generate an interval proof RF to verify the The value u≥m used to verify the main balance.

Step 903: After the sender signs the transaction Topup(A:m,RF), submit it to the blockchain.

In one embodiment, taking the blockchain account 1 of the above-mentioned user A as an example, "A" in the above transaction represents the account address of the blockchain account 1, indicating that the expenditure balance of the blockchain account 1 needs to be processed. The recharge and recharge amount is m.

In one embodiment, a type field may be added to the transaction, and the sender may assign a value to the type field to mark the type of the submitted transaction when creating each transaction, so as to limit the limitations involved in this specification. Distinguish between public transfer transactions, top-up transactions, and merge transactions, master balance transfer transactions, and public transfer transactions as described below. For example, in the embodiment shown in FIG. 6 , the limited public transfer transaction can be marked by the value of “Transfer”, and the recharge transaction can be marked by the value of “Topup” here.

Step 904, the blockchain node verifies the transaction.

In one embodiment, the blockchain node can verify whether the signature of the transaction Topup(A:m,RF) is correct; if not, it can refuse to execute the transaction.

In one embodiment, the blockchain node can verify whether the recharge amount m of the transaction Topup(A:m,RF) satisfies m≥0; if it is not correct, the transaction can be refused to be executed.

In one embodiment, the blockchain node can verify the interval proof RF contained in the transaction Topup(A:m,RF) to determine whether 0≤m≤u is satisfied; if it is incorrect, the transaction can be refused to execute.

After all the verifications are passed, step 905 may be entered.

Step 905, the blockchain node updates the account.

In one embodiment, after passing the verification in step 904, the blockchain node can update the blockchain account 1 recorded in the blockchain ledger, as shown in Figure 10:

In user A's blockchain account 1, the main balance before the transaction is u, which is recorded as the corresponding committed amount PC(u,x) in the blockchain ledger, and the income balance before the transaction is v. The corresponding commitment amount PC(v,y) is recorded in the chain ledger, and the expenditure balance before the transaction is w, which is recorded as the plaintext amount w in the blockchain ledger.

After the transaction is completed, the main balance is deducted from the above-mentioned recharge amount m, so it is recorded in the blockchain ledger as the corresponding committed amount PC(u,x)-PC(m,0), while the expenditure balance w increases The recharge amount m is thus recorded as the plaintext amount w+m in the blockchain ledger; at the same time, the value of the income balance remains unchanged.

As the expenditure balance in the account continues to participate in remittance transactions, and the main balance continues to recharge the expenditure balance, the main balance will gradually decrease. outgoing transactions, so the funds obtained in the income balance can be transferred to the main balance in order to maintain the account continuously participating in outgoing transactions.

FIG. 11 is an interactive schematic diagram of a merge operation provided by an exemplary embodiment. As shown in Figure 11, the interaction process may include the following steps:

Step 1101, the sender determines the amount n to be withdrawn.

In one embodiment, the merging operation is used to transfer all the funds of the income balance and the specified funds of the expenditure balance in the account to the main balance, and the amount of the specified funds can be specified by the above-mentioned withdrawal amount n. If the withdrawal amount n is 0, it is equivalent to transferring only the funds of the income amount to the main balance, or n can be set to any other value, which is not limited in this specification.

Step 1102, after the sender signs the transaction Merge(A:n), and submits it to the blockchain.

In one embodiment, taking the blockchain account 1 of the above-mentioned user A as an example, "A" in the above transaction represents the account address of the blockchain account 1, indicating that a merge operation needs to be performed on the blockchain account 1, Specifically, all the income balance is transferred to the main balance, and the funds n in the expenditure balance are transferred to the main balance. Merge indicates that the current transaction type is a merge transaction, which is used to implement a merge operation for blockchain account 1.

In one embodiment, since the entire income balance is transferred to the main balance instead of part of it, there is no need to generate an interval certificate for part of the income balance; and the withdrawal amount n and the expenditure balance are both plaintext, and there is no need to generate an interval certificate. .

Step 1103, the blockchain node verifies the transaction.

In one embodiment, the blockchain node may verify that the signature of the transaction Merge(A:n) is correct; if not, the transaction may be refused to execute.

In one embodiment, the blockchain node can verify whether the withdrawal amount n of the transaction Merge(A:n) satisfies 1≤n≤w, where w is the value of the spending balance; if it is incorrect, the transaction can be rejected.

When all the verifications are passed, the process can go to step 1104 .

Step 1104, the blockchain node updates the account.

In one embodiment, after passing the verification in step 1103, the blockchain node can update the blockchain account 1 recorded in the blockchain ledger, as shown in Figure 12:

In user A's blockchain account 1, the main balance before the transaction is u, which is recorded as the corresponding committed amount PC(u,x) in the blockchain ledger, and the income balance before the transaction is v. The corresponding commitment amount PC(v,y) is recorded in the chain ledger, and the expenditure balance before the transaction is w, which is recorded as the plaintext amount w in the blockchain ledger.

After the transaction is completed, the income balance becomes 0; the main balance increases the total funds of the income balance and the above-mentioned withdrawal amount n, so it is recorded in the blockchain ledger as the corresponding committed amount PC(u,x)+PC( v,y)+PC(n,0), and the expenditure balance w reduces the withdrawal amount n, so it is recorded as the plaintext amount w-n in the blockchain ledger.

Although in the embodiments provided in this specification, for the main balance, income balance, and expenditure balance contained in the account, it is possible to use the expenditure balance to participate in the outgoing transaction, and the income balance to participate in the inward transaction (the income balance is also collected in the outgoing transaction). change), the main balance participates in the above-mentioned recharge transactions and merger transactions, but it does not mean that each balance can only participate in the above-mentioned types of transactions. For example, the account structure of this manual can also be compatible: the main balance participating in the main balance transfer transaction of remitted funds, and the expenditure balance participating in the public transfer transaction, etc., which will be introduced separately below.

FIG. 13 is a flowchart of another blockchain transaction method provided by an exemplary embodiment. As shown in Figure 13, the method is applied to the exporter device, and the method includes:

Step 1302: Determine the transaction amount to be remitted from the sender's account to the receiver's account, where the sender's account includes the sender's main balance using the committed amount, the sender's income balance using the promised amount, and the clear-text amount of the remittance. The sender's expenditure balance, the receiver's account includes the receiver's main balance in the committed amount, the receiver's income balance in the committed amount, and the receiver's expenditure balance in the plaintext amount.

In one embodiment, the account of the sender and the account of the receiver all adopt the account structure shown in Figure 8, which are the master balance of the sender, the income balance of the sender, and the expenditure balance of the sender in the account of the sender respectively. , the receiver's main balance, the receiver's income balance, and the receiver's payout balance in the receiver's account.

Step 1304, submit the main balance transfer transaction to the blockchain, the main balance transfer transaction includes the transaction amount commitment corresponding to the transaction amount and the transaction amount used to prove that the transaction amount is not negative and the main balance of the sender is not less than the specified amount. The interval proof of the transaction amount, so that the main balance of the sender deducts the transaction amount after the transaction is completed, and the income balance of the receiver increases the transaction amount after the transaction is completed.

In one embodiment, since the main balance of the sender and the income balance of the receiver are recorded in the blockchain ledger in the form of a committed amount, it can be ensured that no data will occur during the transaction through the above-mentioned transfer transaction of the main balance. Leakage, thereby ensuring the privacy and security of data.

In one embodiment, the sending party can compare the transaction amount with the alternative deduction amounts included in the set of alternative deduction amounts described above; if all the alternative deduction amounts are less than the transaction amount, the remittance The sender creates and submits the above-mentioned main balance transfer transaction. If there is any alternative deduction amount not less than the transaction amount, the sender can create and submit a limited public transfer transaction, so that through the embodiment shown in FIG. 5, by The outgoing balance of the sender and the inward balance of the sender participate in the implementation of limited public type transfer operations, which helps to achieve high concurrency.

In one embodiment, the sender may determine to select the above-mentioned main balance transfer transaction, limited public transfer transaction or other types of transfer transactions according to the user's setting operation.

In one embodiment, since the main balance of the sender and the expenditure balance of the sender belong to two independent parts, the sender can even initiate different transactions through the main balance of the sender and the payment balance of the sender at the same time. For example, it is possible to participate in limited public transfer transactions with a small amount through the payout balance of the sender, and participate in the transfer transaction with a larger amount of the main balance through the main balance of the sender, so as to improve transaction efficiency.

The implementation process of limited public transaction is described below by taking user A as the sender and user B as the receiver as examples. Fig. 14 is a flow chart of a fully private remittance transaction based on the main balance provided by an exemplary embodiment; as shown in Fig. 14, the interaction process between the sender, the receiver and the blockchain node may include: The following steps:

Step 1401, the sender determines the transfer amount t.

In one embodiment, the sender refers to a role that remits resources such as money in a remittance transaction, and correspondingly, the receiver refers to a role that receives resources such as money in a remittance transaction. For example, the user equipment used by user A may be configured as the sender, and the user equipment used by user B may be configured as the receiver.

In one embodiment, when drafting the remittance transaction, the remittance amount t can be negotiated between the sender and the receiver. Of course, the sender can also determine the remittance amount t by itself, which will be confirmed by the receiver in subsequent steps.

Step 1402, the sender determines the random number r corresponding to the remittance amount t.

In one embodiment, the sender can generate a random number r for the remittance amount t based on the Pedersen commitment mechanism, and the remittance commitment T=PC(t,r) corresponding to the remittance amount t, where PC() is a preset algorithm.

Step 1403, the sender sends (r, t, T) to the receiver through the off-chain channel.

In one embodiment, by sending (r, t, T) through the off-chain channel instead of the blockchain network, the remittance random number r and the remittance amount t can be prevented from being recorded in the blockchain ledger, and the remittance amount can be ensured. tAgnostic other than the sender and receiver.

Step 1404, the receiver verifies the received (r, t, T).

In one embodiment, the receiver can verify the remittance amount t to determine the amount of the remittance desired to be collected.

In one embodiment, the receiver can verify the remittance commitment T, that is, the receiver can calculate the random number r and the remittance amount t through the Perdersen commitment mechanism to verify whether the remittance commitment T=PC(t,r) is correct, If it is correct, it means that the verification is passed, otherwise the verification is not passed.

Step 1405, after the receiver passes the verification, generates a signature and returns to the sender.

In one embodiment, after the verification is passed, the receiver can use the receiver's private key to sign (A, B:T), generate a signature SigB and return it to the sender. The signature SigB indicates that the recipient agrees to implement the remittance transaction committed to T by user A's blockchain account 1 to user B's blockchain account 2.

Step 1406, after receiving the signature SigB, the sender generates an interval proof RP according to the main balance u.

In one embodiment, in order to ensure the successful completion of the remittance transaction, the blockchain node needs to determine that the remittance amount t and the main balance u meet the following conditions: 0≤t≤u; Verify whether the transaction meets the preset conditions in the state. For example, the Bulletproofs scheme and the Borromean ring signature scheme in related technologies can be used in this manual to realize, but this manual does not limit this. The sender can use the interval proof technology to generate the interval proof RP for verification by the blockchain node in the subsequent process whether 0≤t≤u is satisfied.

Step 1407, the exporter signs the transaction content PrimaryTransfer(A, B: T, RP; SigB) to generate the signature SigA.

In one embodiment, the sender may use the sender's private key to sign the transaction content PrimaryTransfer(A,B:T,RP; SigB) to generate the signature SigA.

Among them, PrimaryTransfer is used to indicate that the transaction type is a primary balance transfer transaction (or referred to as a primary balance remittance transaction).

Step 1408, the exporter submits the transaction to the blockchain.

In one embodiment, the remittance party is configured as a client of the blockchain, and can submit the remittance transaction to a certain blockchain node in the blockchain network, and then transmit it to all the blockchain nodes in the blockchain network. The blockchain node, and each blockchain node verifies the remittance transaction separately, so as to perform the remittance operation when the verification is passed, and reject the remittance when the verification fails.

Step 1409, the blockchain node checks whether the transaction has been executed.

In one embodiment, the blockchain node here may represent any blockchain node in the blockchain network, that is, each blockchain node in the blockchain network will receive the above remittance transaction, and Verification and other operations are performed through steps 1409 to 1411 and the like.

In one embodiment, after receiving the above-mentioned remittance transaction, the blockchain node can use the anti-double-spending or anti-replay mechanism in the related art to verify whether the remittance transaction has been executed; if it has been executed, it can refuse to execute. The remittance transaction, otherwise, go to step 1410.

Step 1410, the blockchain node checks the signature.

In one embodiment, the blockchain node can check whether the signatures SigA and SigB contained in the remittance transaction are correct; if they are incorrect, the remittance transaction can be refused to be executed, otherwise, go to step 1411 .

Step 1411, the blockchain node checks the interval proof RP.

In one embodiment, the blockchain node may check the interval proof RP included in the remittance transaction based on the interval proof technology to determine whether 0≤t≤u is satisfied. If not satisfied, the remittance transaction can be rejected, otherwise, go to step 1412.

Step 1412: The blockchain node updates the blockchain accounts corresponding to user A and user B in the maintained blockchain ledger.

In one embodiment, after passing the verification in steps 1409 to 1411, the blockchain node can update the blockchain account 1 and the blockchain account 2 recorded in the blockchain ledger respectively, as shown in Figure 15:

In user A's blockchain account 1, the main balance before the transaction is u, which is recorded as the corresponding committed amount PC(u,x) in the blockchain ledger, and the income balance before the transaction is v. The corresponding commitment amount PC(v,y) is recorded in the chain ledger, and the expenditure balance before the transaction is w, which is recorded as the plaintext amount w in the blockchain ledger. After the transaction is completed, the main balance is deducted from the above-mentioned transaction amount t, so it is recorded in the blockchain ledger as the corresponding committed amount PC(u,x)-PC(t,r), while the income balance v, expenditure The balance w remains unchanged.

In user B's blockchain account 2, the main balance before the transaction is u', which is recorded as the corresponding commitment amount PC(u',x') in the blockchain ledger, and the income balance before the transaction is v' , is recorded as the corresponding commitment amount PC(v', y') in the blockchain ledger, the expenditure balance before the transaction is w', and is recorded as the plaintext amount w' in the blockchain ledger. After the transaction is completed, the main balance is u', the expenditure balance w' remains unchanged, and the income balance increases the remittance amount t, so it is recorded in the blockchain ledger as the corresponding commitment amount PC(v',y') +PC(t,r).

Fig. 16 is a flowchart of yet another blockchain transaction method provided by an exemplary embodiment. As shown in Figure 16, the method is applied to the exporter device, and the method includes:

Step 1602: Determine the transaction amount to be remitted from the sender's account to the receiver's account, where the sender's account includes the sender's main balance using the committed amount, the sender's income balance using the promised amount, and the clear-text amount. The sender's expenditure balance, the receiver's account includes the receiver's main balance in the committed amount, the receiver's income balance in the committed amount, and the receiver's expenditure balance in the plaintext amount.

In one embodiment, the account of the sender and the account of the receiver all adopt the account structure shown in Figure 8, which are the master balance of the sender, the income balance of the sender, and the expenditure balance of the sender in the account of the sender respectively. , the receiver's main balance, the receiver's income balance, and the receiver's payout balance in the receiver's account.

Step 1604: Submit a public transfer transaction to the blockchain, where the public transfer transaction includes the public transaction amount corresponding to the public transaction amount, so that the payout balance of the sender deducts the public transaction amount, the The recipient payout balance increases the public transaction amount after the transaction is completed.

In one embodiment, when the value of the payout balance of the sender is recorded as a plaintext value, this plaintext value can be sacrificed in exchange for high concurrency of the transfer transaction. When the sender accepts the above settings, it means that the sender is between privacy protection and transaction efficiency, allowing to sacrifice some privacy in exchange for higher transaction efficiency. For small transfers, the transfer can be performed directly between the sender's spending balance and the receiver's spending balance by submitting the above-mentioned public transfer transaction. This process is similar to the transfer operation in the related technology where privacy protection is not implemented. Since there is no need to implement various complex processing operations such as encryption, generation of interval proofs, and verification of interval proofs, transaction efficiency can be greatly improved.

In one embodiment, privacy type setting information may be obtained, and the privacy type setting information may be temporarily set by the user according to actual needs, or set to take effect for a long time. When the privacy type setting information is a non-private type, it indicates that the user values transaction efficiency relatively more, so the public transfer transaction can be submitted to the blockchain based on the above. When the privacy type setting information is the private type, it indicates that the user values privacy relatively more. Therefore, based on the embodiment shown in FIG. 5 or FIG. 13 , a limited public transfer transaction or a main balance transfer transaction can be submitted to the blockchain.

Among them, for private scenarios, the user can further set the selection of limited public transfer transactions or main balance transfer transactions; or as mentioned above, limited public transfer transactions can be preferred, and when the sender's spending balance is less than the transaction amount , the main balance transfer transaction is selected, and the embodiment shown in FIG. 13 may be referred to here, which will not be repeated here.

The implementation process of limited public transaction is described below by taking user A as the sender and user B as the receiver as examples. Fig. 17 is a flow chart of a public remittance transaction implemented based on the expenditure balance provided by an exemplary embodiment; as shown in Fig. 17, the interaction process between the sender, the receiver and the blockchain node may include the following steps :

Step 1701, the sender determines the transfer amount t.

In one embodiment, the sender refers to a role that remits resources such as money in a remittance transaction, and correspondingly, the receiver refers to a role that receives resources such as money in a remittance transaction. For example, the user equipment used by user A may be configured as the sender, and the user equipment used by user B may be configured as the receiver.

In one embodiment, when drafting the remittance transaction, the remittance amount t can be negotiated between the sender and the receiver. Of course, the sender can also determine the remittance amount t by itself.

Step 1702, the exporter signs the transaction content OpenTransfer(A,B:t), generates a signature SigA, and submits the transaction.

In one embodiment, the exporter can use the private key of the exporter to sign the transaction content OpenTransfer(A,B:t) to generate the signature SigA.

Among them, OpenTransfer is used to indicate that the transaction type is an open transfer transaction (or called, an open remittance transaction).

Step 1703, the blockchain node verifies the transaction.

In one embodiment, after receiving the above-mentioned remittance transaction, the blockchain node can use the anti-double-spending or anti-replay mechanism in the related art to verify whether the remittance transaction has been executed; if it has been executed, it can refuse to execute. The remittance transaction, otherwise, go to step 1704.

In one embodiment, the blockchain node can check whether the signature SigA contained in the remittance transaction is correct; if it is incorrect, it can refuse to execute the remittance transaction, otherwise, go to step 1704 .

Step 1704: The blockchain node updates the blockchain accounts corresponding to user A and user B in the maintained blockchain ledger.

In one embodiment, after passing the verification in step 1703, the blockchain node can respectively update the blockchain account 1 and blockchain account 2 recorded in the blockchain ledger, as shown in Figure 18:

In user A's blockchain account 1, the main balance before the transaction is u, which is recorded as the corresponding committed amount PC(u,x) in the blockchain ledger, and the income balance before the transaction is v. The corresponding commitment amount PC(v,y) is recorded in the chain ledger, and the expenditure balance before the transaction is w, which is recorded as the plaintext amount w in the blockchain ledger. After the transaction is completed, the expenditure balance w is deducted from the above-mentioned transaction amount t, so it is recorded as the corresponding plaintext amount w-t in the blockchain ledger, while the income balance v and the main balance u remain unchanged.

In user B's blockchain account 2, the main balance before the transaction is u', which is recorded as the corresponding commitment amount PC(u',x') in the blockchain ledger, and the income balance before the transaction is v' , is recorded as the corresponding commitment amount PC(v', y') in the blockchain ledger, the expenditure balance before the transaction is w', and is recorded as the plaintext amount w' in the blockchain ledger. After the transaction is completed, the main balance is u', the income balance is v' unchanged, and the expenditure balance w' increases the remittance amount t, so it is recorded as the corresponding plaintext amount w'+t in the blockchain ledger.

Fig. 19 is a schematic structural diagram of a device provided by an exemplary embodiment. Referring to FIG. 19, at the hardware level, the device includes a processor 1902, an internal bus 1904, a network interface 1906, a memory 1908 and a non-volatile memory 1910, and of course may also include hardware required for other services. The processor 1902 reads the corresponding computer program from the non-volatile memory 1910 into the memory 1908 and then executes it, forming a blockchain transaction device on a 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 to say, the execution subjects of the following processing procedures are not limited to each Logic unit, which can also be hardware or logic device.

Referring to FIG. 20, in a software implementation, the blockchain transaction device may include:

Determining unit 2001, determining the transaction amount to be remitted from the sender's account to the receiver's account, where the sender's account includes the sender's main balance using the committed amount, the sender's income balance using the promised amount, and the clear text amount. The sender's expenditure balance, the receiver's account includes the receiver's main balance using the committed amount, the receiver's income balance using the committed amount, and the receiver's expenditure balance using the clear text amount;

Submitting unit 2002, submits a public transfer transaction to the blockchain, where the public transfer transaction includes the public transaction amount corresponding to the public transaction amount, so that after the transaction is completed, the payment balance of the sender deducts the public transaction amount, the amount of the public transaction amount, and the transaction amount. The recipient payout balance increases the open transaction amount after the transaction is completed.

The systems, devices, modules or units described in the above embodiments may be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, email sending and receiving device, game control desktop, tablet, wearable device, or a combination of any of these devices.

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

Memory may include non-persistent memory in computer readable media, random access memory (RAM) and/or non-volatile memory in the form of, for example, read only memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media includes both persistent and non-permanent, removable and non-removable media, and storage of information may be implemented by any method or technology. Information may be computer readable instructions, data structures, modules of programs, 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 tape cartridges, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves.

It should also be noted that the terms "comprising", "comprising" or any other variation thereof are intended to encompass a non-exclusive inclusion such that a process, method, article or device comprising a series of elements includes not only those elements, but also Other elements not expressly listed, or which are inherent to such a process, method, article of manufacture, or apparatus are also included. Without further limitation, an element qualified by the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, article of manufacture, or device that includes the element.

The foregoing describes specific embodiments of the present specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments and still achieve desirable results. Additionally, the processes depicted in the figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

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

It will be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, such information should not be limited by these terms. These terms are only used to distinguish the same type of information from each other. For example, 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 without departing from the scope of one or more embodiments of the present specification. Depending on the context, the word "if" as used herein can be interpreted as "at the time of" or "when" or "in response to determining."

The above descriptions are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. All within the spirit and principles of one or more embodiments of this specification, Any modifications, equivalent replacements, improvements, etc. made should be included within the protection scope of one or more embodiments of this specification.

Claims (13)

1. a kind of block chain method of commerce is applied to remittance abroad method, apparatus, which comprises

Determination will import the turnover of recipient's account from remittance abroad side's account, and remittance abroad side's account includes using committed amount The main remaining sum in remittance abroad side, remaining sum paid using the remittance abroad side that the remittance abroad side of committed amount takes in remaining sum and plaintext number, it is described to connect Debit's account includes the main remaining sum of recipient using committed amount, the income remaining sum of the recipient using committed amount and plaintext number Recipient pay remaining sum；

Open money transfer transactions are submitted to block chain, the open money transfer transactions include the corresponding open transaction of the open transaction volume Volume, so that remittance abroad side expenditure remaining sum deducts the open transaction volume after completion of transactions, the recipient pays remaining sum and exists Increase the open transaction volume after the completion of transaction.

2. according to the method described in claim 1,

Further include: obtain privacy type set information；

It is described to submit open money transfer transactions to block chain, comprising: when the privacy type set information is non-secret type, to Block chain submits the open money transfer transactions.

3. according to the method described in claim 2, further include:

When the privacy type set information is secret type, main cancellation of balances of accounts transaction, the main remaining sum are submitted to block chain Money transfer transactions include that the corresponding turnover of the turnover is promised to undertake and for proving that the turnover is non-negative and the remittance abroad side master Remaining sum is proved not less than the section of the turnover, so that the main remaining sum in the remittance abroad side deducts the transaction after completion of transactions Volume, the recipient take in remaining sum and increase the turnover after completion of transactions.

4. according to the method described in claim 2, further include:

When the privacy type set information is secret type, limited open money transfer transactions are submitted to block chain, it is described limited Open money transfer transactions include the corresponding turnover promise of the turnover, volume of withholing, for proving that the turnover is non-negative and institute State the volume of withholing proves not less than the section of the turnover, so that described in remittance abroad side expenditure remaining sum deducts after completion of transactions Volume, the remittance abroad side income remaining sum of withholing withhold described in increasing after completion of transactions and volume and deduct the turnover, the reception Side's income remaining sum increases the turnover after completion of transactions.

5. according to the method described in claim 4, further include:

The corresponding volume set of alternatively withholing of remittance abroad side's account is obtained, the volume set of alternatively withholing includes several predetermined values Alternatively withhold volume；

It chooses and alternatively withholds volume not less than any of the turnover, using as the volume of withholing.

6. according to the method described in claim 2, further include:

When the privacy type set information is secret type, the corresponding volume collection of alternatively withholing of remittance abroad side's account is obtained It closes, the volume set of alternatively withholing includes the volume of alternatively withholing of several predetermined values；

When the alternative volume of withholing is respectively less than the turnover, main cancellation of balances of accounts transaction, the main remaining sum are submitted to block chain Money transfer transactions include that the corresponding turnover of the turnover is promised to undertake and for proving that the turnover is non-negative and the remittance abroad side master Remaining sum is proved not less than the section of the turnover, so that the main remaining sum in the remittance abroad side deducts the transaction after completion of transactions Volume, the recipient take in remaining sum and increase the turnover after completion of transactions；

When any volume of alternatively withholing is not less than the turnover, any alternative volume of withholing is chosen for the volume of withholing；To area Block chain submits limited open money transfer transactions, the limited open money transfer transactions include the corresponding turnover of the turnover promise to undertake, Withhold volume, prove for proving that the turnover is non-negative and the volume of withholing is not less than the section of the turnover so that described Remittance abroad side expenditure remaining sum deducts after completion of transactions described in withhold volume, the remittance abroad side take in remaining sum increase institute after completion of transactions It states the volume of withholing and deducts the turnover, the recipient takes in remaining sum and increases the turnover after completion of transactions.

7. the method according to any one of claim 3-6, the turnover is promised to undertake as predetermined encryption algorithm according to Turnover and transaction random number are calculated；The method also includes:

Before submitting the main cancellation of balances of accounts transaction or the limited open money transfer transactions, by the turnover, the transaction Volume, which is promised to undertake, is sent to receiver equipment by chain outer tunnel with the transaction random number, as described in receiver equipment verifying Corresponding relationship between turnover promise, the transaction random number and the turnover；

Recipient's signature that the receiver equipment returns is received, to be added to the main cancellation of balances of accounts transaction or the limited public affairs It opens in money transfer transactions；Wherein, recipient's signature is generated after the corresponding relationship is by verifying by the receiver equipment.

8. according to the method described in claim 1, when remittance abroad side's account remittance abroad kelly-up volume increase when, corresponding amount of money quilt Increase to remittance abroad side's income remaining sum.

9. according to the method described in claim 1, further include:

Recharging payment is submitted to block chain, the recharging payment includes to supplement volume with money and for proving that the main remaining sum in the remittance abroad side is not small Proved in the section for supplementing volume with money so that the main remaining sum in the remittance abroad side deduct after completion of transactions described in supplement volume, the remittance with money Out side expenditure remaining sum increase after completion of transactions described in supplement volume with money.

10. according to the method described in claim 9,

It is submitted to block chain and merges transaction, the merging transaction includes merging volume；

Wherein, remaining sum deducts the merging volume to remittance abroad side's expenditure after completion of transactions, the main remaining sum in the remittance abroad side is being traded Increase after the completion the merging volume and/or the remittance abroad side income remaining sum reset after completion of transactions, the main remaining sum in the remittance abroad side Increase the income remaining sum after completion of transactions.

11. a kind of block chain the transaction device, is applied to remittance abroad method, apparatus, described device includes:

Determination unit, determination will import the turnover of recipient's account from remittance abroad side's account, and remittance abroad side's account includes adopting It is taken in the main remaining sum in the remittance abroad side of committed amount, using the remittance abroad side of committed amount more than remaining sum and remittance abroad side's expenditure of plaintext number Volume, recipient's account include the main remaining sum of recipient using committed amount, the income remaining sum of the recipient using committed amount Remaining sum is paid with the recipient of plaintext number；

Unit is submitted, submits open money transfer transactions to block chain, the open money transfer transactions are corresponding comprising the open transaction volume Open transaction volume so that the remittance abroad side expenditure remaining sum deduct the open transaction volume, the recipient after completion of transactions Expenditure remaining sum increases the open transaction volume after completion of transactions.

12. a kind of electronic equipment, comprising:

Processor；

Memory for storage processor executable instruction；

Wherein, the processor is by running the executable instruction to realize such as side of any of claims 1-10 Method.

13. a kind of computer readable storage medium, is stored thereon with computer instruction, realized such as when which is executed by processor The step of any one of claim 1-10 the method.