CN113128989A

CN113128989A - Block chain transaction method and device, electronic equipment and storage medium

Info

Publication number: CN113128989A
Application number: CN202110391044.1A
Authority: CN
Inventors: 张文彬; 陈盛龙; 胡丹青; 蒋国飞; 马宝利; 马环宇; 闫雪冰; 陈春伟
Original assignee: Advanced New Technologies Co Ltd
Current assignee: Ant Chain Technology Co ltd
Priority date: 2019-02-01
Filing date: 2019-02-01
Publication date: 2021-07-16
Anticipated expiration: 2039-02-01
Also published as: CN110009323B; CN113128989B; CN110009323A

Abstract

One or more embodiments of this specification provide a blockchain transaction method and device, electronic device, and storage medium, which are applied to a sender's device. The method includes: determining a transaction to be transferred from the sender's account to the recipient's account. The transaction amount, the sender's account includes the sender's main balance with the committed amount, the sender's income balance with the promised amount, and the sender's expenditure balance with the promised amount, and the receiver's account includes the receiver with the promised amount. The main balance of the party, the receiver's income balance using the committed amount, and the receiver's expenditure balance in 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 After the transaction is completed, the payout balance of the sender deducts the public transaction amount, and the payout balance of the receiver increases the open transaction amount after the transaction is completed.

Description

Block chain transaction method and device, electronic equipment and storage medium

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method and an apparatus for blockchain transaction, an electronic device, and a storage medium.

Background

The blockchain can maintain a unified blockchain account book among all blockchain nodes by achieving consensus among all blockchain link nodes so as to permanently record transaction information occurring in the blockchain network. The blockchain ledger is fully open to facilitate viewing and validating historical data of transactions that have occurred at any time.

Disclosure of Invention

In view of this, one or more embodiments of the present disclosure provide a method and an apparatus for blockchain transaction, an electronic device, and a storage medium.

One or more embodiments of the present disclosure provide the following:

according to a first aspect of one or more embodiments of the present specification, there is provided a blockchain transaction method applied to a remitter device, the method including:

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.

According to a second aspect of one or more embodiments of the present specification, there is provided a blockchain transaction apparatus applied to a remitter device, the apparatus including:

a determining unit, configured to determine a transaction amount to be remitted from a remitter account to a recipient account, the remitter account including a remitter main balance using a commitment amount, a remitter income balance using the commitment amount, and a remitter expenditure balance using a plaintext amount, the recipient account including a recipient main balance using the commitment amount, a recipient income balance using the commitment amount, and a recipient expenditure balance using the plaintext amount;

and the submitting unit is used for submitting public transfer transaction to the 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 finished, and the public transaction amount is increased by the receiver expenditure balance after the transaction is finished.

According to a third aspect of one or more embodiments of the present specification, there is provided an electronic apparatus including:

a processor;

a memory for storing processor-executable instructions;

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

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

Drawings

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

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

FIG. 3 is a flow chart of a method for account creation provided by an exemplary embodiment.

Fig. 4 is a schematic diagram of a blockchain account structure according to an exemplary embodiment.

Fig. 5 is a flowchart of a blockchain transaction method according to an exemplary embodiment.

Fig. 6 is a flow diagram of a limited disclosure money transfer transaction conducted based on a payout balance, provided by an exemplary embodiment.

Fig. 7 is a diagram illustrating a change in account balance before and after a money transfer, 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 interaction diagram illustrating a primary balance supplementing a payout balance according to an exemplary embodiment.

Fig. 10 is a schematic diagram of an account balance change before and after a top-up according to an exemplary embodiment.

FIG. 11 is an interaction diagram illustrating a merge operation, according to an exemplary embodiment.

FIG. 12 is a diagram illustrating account balance changes before and after consolidation, according to an example embodiment.

Fig. 13 is a flowchart of another blockchain transaction method according to an example embodiment.

FIG. 14 is a flow diagram of a master balance based fully private money transfer transaction provided by an exemplary embodiment.

Fig. 15 is a schematic illustration of another account balance change before and after a money transfer, according to an example embodiment.

Fig. 16 is a flowchart of yet another blockchain transaction method according to an example embodiment.

Fig. 17 is a flow diagram of a public remittance transaction conducted based on a payout balance, provided by an exemplary embodiment.

Fig. 18 is a diagrammatic illustration of a change in account balance before and after a money transfer, according to an exemplary embodiment.

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

Fig. 20 is a block diagram of a blockchain transaction device according to an exemplary embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

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

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

computing devices

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

In some cases, the

computing devices

106, 108 may be nodes of a cloud computing system (not shown), or each

computing device

106, 108 may be a separate cloud computing system, including multiple computers interconnected by a network and operating as a distributed processing system.

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

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

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

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

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

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

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

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

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

In the technical scheme of the specification, a new account transaction form can be realized by improving the account structure in the block chain, so that concurrent transaction under an account model is realized on the premise of ensuring transaction privacy, and the transaction throughput is improved.

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

step 302, a blockchain transaction is received, wherein the type of the blockchain transaction is an account creation type.

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

In one embodiment, a blockchain transaction includes several fields. In an ethernet blockchain, for example, a blockchain transaction may typically include a from field, a to field, a data field, etc. to respectively represent an account address of a transaction initiator, a contract address of an intelligent contract to invoke, transaction-related content, etc. In the technical solution of the present specification, a type field may be set in the blockchain transaction, and the content included in the type field is used to indicate the type of the relevant blockchain transaction, so that the blockchain node may implement corresponding processing accordingly. For example, blockchain transactions may be labeled as account creation types, such that blockchain points may create new accounts accordingly.

Step 304, the blockchain transaction is executed to create a first account including an income balance in ciphertext amounts and an expenditure balance in plaintext amounts.

Two Transaction models, i.e., an UTXO (un-spent Transaction Output) model and an account model, are commonly used in blockchain networks. The typical application scene of the UTXO model is a bitcoin block chain, assets on the chain under the model exist in a transaction output mode, and when an uneconomical transaction output exists in a transaction, the uneconomical transaction output is owned by a private key holder; in use, one or more non-spent transaction outputs may be taken as input and one or more outputs may be designated, thereby forming a new one or more non-spent transaction outputs. Although the UTXO model is adopted by various block chain networks, the support for the intelligent contract is weak, which imposes a large limitation on the application scenario. The typical application scenario of the account model is an Etherhouse block chain, assets on the chain held by an account are represented as balance corresponding to an account address by creating the account under the model, each transfer transaction can transfer the assets from one 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 the complete intelligent contract function and has better scene expansibility.

Improvements to blockchain transactions are proposed in the related art for the purpose of transaction privacy protection. Under the UTXO model, the transaction amount can be protected through homomorphic encryption or homomorphic commitment technology, and the output of the transaction is ensured to be non-negative by using the interval certification technology. Under the account model, the transaction amount can be protected through homomorphic encryption or homomorphic commitment technology, and the interval certification technology is utilized to ensure that the transaction amount is not negative and the account balance is enough to pay.

Under the UTXO model, one or more transaction outputs are used as input for a transfer transaction, and one or more new transaction outputs are formed after the transfer is completed. It can be seen that one transaction output is spent only in one transfer transaction and cannot be spent by multiple transfer transactions, so that the interval proof generated for one transfer transaction is only related to the transfer transaction input and is not related to the input of other transfer transactions, and therefore the UTXO model has naturally high transaction concurrency. In the account model, the input of each transaction is the balance of the account, the interval certification of each transaction is related to the balance of the account, and the balance of the account is updated after each transaction, so that all transactions under the same account need to be executed in series in sequence, namely after one transaction is finished and the balance of the account is updated, the interval certification can be generated and the next transaction can be triggered to be executed aiming at the next transaction, otherwise, the transaction is rejected by the consensus node due to the illegal interval certification. Thus, when privacy preserving techniques with interval attestation are used under the account model, the throughput of transactions is severely hampered.

In order to solve the problem of concurrency under the account model and ensure sufficient support on the intelligent contract function, the specification provides improvement on the account structure under the account model in the related art so as to adapt to high-throughput concurrent transactions.

Accounts in the blockchain network may include external accounts, contract accounts, and the like. The external accounts are typically owned by the user (person or institution) while the contract accounts correspond to the smart contracts in the blockchain. The structure of each type of account is similar, and for example, as shown in fig. 4, the structure may include a Nonce field, a Balance field, a Code field, a Storage field, and the like. The value of the Nonce field of each account starts from 0, and the value of the Nonce field is sequentially increased along with the transaction initiated by the corresponding account, so that the Nonce values contained in each transaction initiated by the account are different, thereby avoiding replay attack. The Balance field is used to store the Balance. The Code field is used to hold the Code of the smart contract, and thus the Code field of the external account is typically empty. The Storage field is used for storing the value of the account at the corresponding node in the state tree.

The value of the Balance field is the plaintext Balance held by the account without considering privacy protection. Under the condition of privacy protection, a plaintext balance can be generated into a corresponding ciphertext commitment through a Pedersen commitment mechanism, so that only the ciphertext commitment is recorded on a block chain account book, and only a holder can decrypt the ciphertext commitment; however, in this case, there is a problem that the above-described concurrency is insufficient due to the limitation of the interval certification. In the description, a Balance field is structurally improved and further divided, for example, the Balance field includes income Balance and expenditure Balance, where the income Balance is recorded as a ciphertext amount in a block chain account book, and the payment Balance is recorded as a plaintext amount in the block chain account book.

Based on the above improved account structure, when the first account is used as an remitter account for transferring to the second account as a receiver account, the related transfer process will be described with reference to fig. 5. Fig. 5 is a flowchart of a blockchain transaction method according to an exemplary embodiment. As shown in fig. 5, the method is applied to an remitter device, and the method includes:

step 502, determining a corresponding deduction amount according to a limited public transaction amount to be remitted from a remittance account to a receiver account; wherein the remittance account includes an income balance using the commitment amount and a spending balance using the clear text amount.

In one embodiment, the present specification provides a limited disclosure type of transfer transaction mode in which transfer transactions with privacy protection can be conducted by employing an income balance of a commitment amount, and an expenditure balance of a clear text amount.

In one embodiment, the deduction amount may be any value not less than the limited public transaction amount. For example, the remitter account may respectively set the alternative deduction amount for each type of transfer scenario according to the predefined upper limit of the transfer amount in each type of transfer scenario, so as to form an alternative deduction amount set. Alternatively, the value of each alternative deduction amount may be determined in other manners, which is not limited in this specification. Then, only a deduction amount not less than the limited public transaction amount needs to be selected. Of course, a deduction amount may be temporarily generated based on the value of the limited public transaction amount. The deduction amount is preferably independent of the limited open transaction amount itself, otherwise when the deduction amount generating algorithm is disclosed, it may cause a lawless person to reversely deduce the value of the limited open transaction amount according to the deduction amount value.

Step 504, submitting limited public transfer transaction to a blockchain, wherein the limited public transfer transaction comprises a limited public transaction amount commitment corresponding to the limited public transaction amount, the deduction amount and an interval certification for proving that the transaction amount is not negative and the deduction amount is not less than the limited public transaction amount.

In one embodiment, after the limited public transfer transaction is completed, the debit balance may be deducted by the deduction amount after the transaction is completed, the income balance may be increased by the deduction amount and deducted by the limited public transaction amount after the transaction is completed (i.e., a change amount is added, and a value of the change amount is a difference between the deduction amount and the limited public transaction amount), and the limited public transaction amount may be increased by the account of the receiving party after the transaction is completed. Then, when the deduction amount is deducted from the expenditure balance, because the expenditure balance and the deduction amount both adopt a plaintext form, an interval certificate with sufficient balance (the plaintext amount can be directly compared) does not need to be generated, so that the tie between the account transfer transaction and the balance of the remittance account is realized, and the concurrent transaction can be realized under an account model. Meanwhile, the income balance is in the form of a committed amount, so the change amount added to the income balance is also recorded in the form of a committed amount, and the limited open transaction amount is also expressed as a corresponding committed amount, so only the deduction amount of a plaintext is exposed in the whole transaction process, and the rest amount is expressed as the committed amount in the form of a ciphertext, so that the concurrent transaction can be realized, and meanwhile, the sufficient privacy protection is ensured.

In one embodiment, when the recipient account increases the limited public transaction amount after the transaction is completed, the limited public transaction amount may be increased to the revenue balance of the recipient account if the recipient account employs the account structure of the present specification. Specifically, because the revenue balance of the recipient account is in the form of a commitment amount, the limited public transaction amount is also added to the revenue balance of the recipient account in the form of a corresponding commitment amount. Similarly, when the remitter balance of the remitter account increases, such as when an account transfers to the remitter account, the corresponding amount is increased to the remitter account's revenue balance.

Therefore, by respectively setting the income balance of the commitment amount and the expenditure balance of the plaintext amount in the account structure, the concurrent transaction under the account model can be realized while the transaction privacy is ensured, the remittance transaction and the remittance transaction which are participated by the same account can be decoupled, the remittance party account can be ensured to participate in the remittance transaction and the remittance transaction simultaneously, and the transaction throughput can be improved.

The following describes an implementation process of limited public transaction by taking a user a as an remitter and a user B as a receiver as an example. FIG. 6 is a flow diagram of a limited disclosure money transfer transaction conducted based on a payout balance provided by an exemplary embodiment; as shown in fig. 6, the interaction process between the remitter, the recipient and the tile chain node may include the following steps:

step 601, the remitter determines the transfer amount t.

In one embodiment, the remitter plays a role in remitting money and other resources in the remittance transaction, and the receiver plays a role in receiving money and other resources in the remittance transaction. For example, a user device used by user a may be configured as an remitter, while a user device used by user B may be configured as a recipient.

In one embodiment, the transfer amount t may be negotiated between the transferor and the recipient at the time of the draft transaction. Of course, the remitter may also determine the remittance amount t by itself, which is confirmed by the receiver in the subsequent steps.

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

In one embodiment, the remitter may generate a random number r for the remittance amount T based on the Pedersen commitment mechanism, and then the remittance commitment T corresponding to the remittance amount T is PC (T, r), where PC () is a predetermined algorithm.

Step 603, the sink sends (r, T) to the receiver through the downlink channel.

In one embodiment, by sending (r, T) over a downlink channel instead of a blockchain network, the remittance random number r and the remittance amount T are prevented from being recorded in the blockchain ledger, ensuring that the remittance amount T is unknown except to the remitter and recipient.

In step 604, the receiver verifies the received (r, T).

In one embodiment, the recipient may validate the transfer amount t to determine the amount of the transfer desired to be charged.

In one embodiment, the recipient may verify the remittance acceptance T, that is, the recipient may calculate the random number r and the remittance amount T through the perfersen acceptance mechanism to verify whether the remittance acceptance T ═ PC (T, r) is correct, if so, the verification is passed, otherwise, the verification is not passed.

In step 605, after the verification is passed, the receiving party generates a signature and returns the signature to the remitting party.

In one embodiment, after verification is passed, the recipient may sign (A, B: T) with the recipient's private key, generate a signature SigB, and return to the exporter. The signature SigB indicates that the recipient agrees to conduct a committed T money transfer transaction from user a's blockchain account 1 to user B's blockchain account 2.

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

In one embodiment, the deduction amount L is determined by the remitter from the transfer amount t. For example, the remitter may have several deductions L1-Ln maintained in advance, and the remitter may choose a deduction L at will as long as t is not less than L and not more than w is ensured, where w is the value of the expenditure balance in the blockchain account 1 of the user a.

In one embodiment, the remitter may determine the deduction amount L at any time before generating the interval certificate PR, which is not limited by the present specification.

In one embodiment, to ensure that the money transfer transaction is successfully completed, the block link points may determine that the amount of money to be transferred t and the amount of money to be deducted L satisfy the following condition: t is more than or equal to 0 and less than or equal to L; the interval certification technology may enable the block chain node to verify whether the transaction meets the preset condition in the ciphertext state, for example, the specification may be implemented by using a bullletprofofs scheme, a Borromean ring signature scheme, and the like in the related art, which is not limited in the specification. The remitter can use an interval proof technology to generate an interval proof PR for verifying whether t is more than or equal to 0 and less than or equal to L or not by the block link point in the subsequent process.

In step 607, the remitter signs the transaction content (A, B: T, L, PR; SigB) to generate signature SigA.

In one embodiment, the transferor may sign the transaction content (A, B: T, L, PR; SigB) with the transferor's private key, generating signature SigA.

At step 608, the remittance submits the transaction to the blockchain.

In one embodiment, the remitter is configured as a blockchain client that can submit a remittance transaction to a blockchain node in the blockchain network and then be transmitted to all blockchain nodes in the blockchain network, and authenticate the remittance transaction by each blockchain node respectively, to perform a remittance operation when authentication is passed and to reject remittance when authentication is not passed.

In step 609, the block node checks whether the transaction has been executed.

In one embodiment, the blockchain node herein may represent any blockchain node in the blockchain network, i.e., each blockchain node in the blockchain network receives the money transfer transaction and performs verification through steps 609-612.

In one embodiment, after receiving the money transfer transaction, the blocklink point may verify that the money transfer transaction has been performed using a money transfer prevention mechanism; if so, execution of the money transfer transaction may be denied, otherwise, processing proceeds to step 610.

In step 610, the block chain nodes check the signature.

In one embodiment, the block node may check whether the signatures SigA, SigB included in the money transfer transaction are correct; if not, execution of the money transfer transaction may be denied, otherwise, flow proceeds to step 611.

In step 611, block link point check interval verification PR is performed.

In one embodiment, block link points may check the money transfer transaction against a span certificate PR contained therein based on a span certificate technique to determine if 0 ≦ t ≦ L is satisfied. If not, execution of the money transfer transaction may be denied, otherwise, processing proceeds to step 612.

In step 612, the block chain node checks whether the expense balance is sufficient.

In one embodiment, since the expenditure balance w of the blockchain account 1 is recorded in the blockchain account book in a clear text form, the blockchain link point can directly read the expenditure balance w of the blockchain account 1 and compare the expenditure balance w with the deduction amount L, so as to determine that the expenditure balance is sufficient when w is greater than or equal to L.

Therefore, the remitter only needs to generate the interval proof PR for the transaction amount t and the deduction amount L in step 606, and does not need to generate a corresponding interval proof for the deduction amount L and the expenditure balance w, so that a generation process of the interval proof and generation efficiency of the transaction can be omitted, and a verification process of the interval proof and execution efficiency of the transaction can be omitted.

In step 613, the blockchain link point updates the blockchain accounts corresponding to the user a and the user B in the maintained blockchain account book.

In one embodiment, after passing the verification of steps 609-612, the blockchain link point can update the blockchain account 1 and the blockchain account 2 recorded in the blockchain account book, respectively, as shown in fig. 7:

in the blockchain account 1 of user a, the income balance before transaction is v, recorded in the blockchain ledger as the corresponding commitment amount PC (v, y), and the expenditure balance before transaction is w, recorded in the blockchain ledger as the plaintext amount w. After the transaction is completed, the balance of the expenditure is deducted by the deduction amount L, and is recorded as the plaintext amount w-L in the blockchain account, and the balance of the income is increased by the zero-finding amount, i.e. the difference between the deduction amount L and the remittance amount t, and is recorded as the corresponding commitment amount PC (v, y) + PC (L,0) -PC (t, r) in the blockchain account, wherein PC (L,0) is the commitment value corresponding to the deduction amount L (the random number adopted in advance is 0; of course, other agreed values can also be adopted).

In user B's blockchain account 2, the pre-transaction income balance is v', recorded in the blockchain ledger as the corresponding commitment amount PC (v ', y'), the pre-transaction expenditure balance is w ', recorded in the blockchain ledger as the plaintext amount w'. After the transaction is completed, the expenditure balance w ' is unchanged, while the income balance is increased by the remittance amount t, and is thus recorded in the blockchain ledger as the corresponding commitment amount PC (v ', y ') + PC (t, r).

As described above, when the account contains the income balance and the expenditure balance as described above, a high concurrent transfer under the account model can be achieved with the transaction privacy secured. However, the amount of the payout balance is decreasing because the funds remitted into the account are all credited into the income balance and the remitted funds are deducted from the payout balance. In order to ensure that the amount of the payout balance is always sufficient to complete the transaction, the payout balance may be recharged periodically or at any time.

Although it is possible to recharge from an income balance to an expense balance,: since the expense balance itself is in clear text, in fact exposing a limited degree of privacy (indicating that the balance in the relevant account is not less than the value of the expense balance), users often do not wish to make the amount of the expense balance too high to control and limit the exposure to privacy. Then, when the transaction of the account remitting to the outside is frequent and the transaction amount is large, the expenditure balance needs to be recharged frequently, which causes the income balance to participate in remitting and remitting (recharging) of the fund frequently, even causes the corresponding influence between the remitting transaction and the recharging transaction, and on the contrary, causes the efficiency to be reduced.

Thus, the present specification proposes further improvements to the account structure shown in fig. 4. For example, as shown in fig. 8, a main Balance may be further added to the Balance field, so that the Balance field contains three balances in total: a main balance, an income balance, and an expense balance. The income balance is specially used for collecting the transaction amount of the remittance transaction, the expenditure balance is specially used for participating in the remittance transaction, and the main balance is used for recharging the expenditure balance, so that the income balance is prevented from bearing the recharging task, and the influence is prevented.

FIG. 9 is an interaction diagram illustrating a primary balance supplementing a payout balance according to an exemplary embodiment. As shown in fig. 9, the interactive process may include the following steps:

in step 901, the remittance determines a recharge amount m.

In one embodiment, the recharge amount m may be any amount, as long as the amount of the primary balance of the remitter is sufficient. For example, a maximum level may be set for the payout balance, and the charge amount m may be the difference between the maximum level and the remaining value of the payout balance.

In step 902, the remitter generates an interval certificate RF.

In an embodiment, since the value u of the main balance is recorded as the corresponding commitment amount PC (u, x) in the blockchain book, where x is a random number corresponding to u, it is necessary to verify that the value u of the main balance is greater than or equal to m by generating the interval certificate RF.

In step 903, the remitter signs the transaction Top (A: m, RF) and submits the signed transaction to the blockchain.

In one embodiment, taking the blockchain account 1 of the user a as an example, the "a" in the transaction represents the account address of the blockchain account 1, which indicates that the expenditure balance of the blockchain account 1 needs to be charged with value m.

In one embodiment, a type field may be added to the transaction, and the remitter may distinguish between limited public transfer transactions, top-up transactions, and consolidated transactions, primary balance transfer transactions, public transfer transactions, etc. referred to in this specification by assigning a value to the type field to mark the type of transaction submitted when creating each transaction. For example, in the embodiment shown in FIG. 6, the limited public Transfer transaction may be labeled by taking the value "Transfer," while the top up transaction may be labeled here by taking the value "Top.

At step 904, the block link points verify the transaction.

In one embodiment, the chunk node may verify whether the signature of the transaction top (a: m, RF) is correct; if not, the transaction may be denied.

In one embodiment, the block link point may verify whether the recharge amount m of the transaction Top (A: m, RF) satisfies that m ≧ 0; if not, the transaction may be denied.

In one embodiment, a tile chain node may verify the interval certificate RF contained in the transaction Top (A: m, RF) to determine if 0 ≦ m ≦ u; if not, the transaction may be denied.

When all verifications have passed, the process can proceed to step 905.

In step 905, the block link points are updated.

In one embodiment, after passing the verification of step 904, the blockchain link point may update blockchain account 1 recorded in the blockchain ledger, as shown in fig. 10:

in the blockchain account 1 of the user a, the main balance before transaction is u, which is recorded in the blockchain ledger as the corresponding commitment amount PC (u, x), the income balance before transaction is v, which is recorded in the blockchain ledger as the corresponding commitment amount PC (v, y), and the expenditure balance before transaction is w, which is recorded in the blockchain ledger as the plaintext amount w.

After the transaction is completed, the main balance is deducted by the above-mentioned recharge amount m, and is thus recorded in the blockchain ledger as the corresponding commitment amount PC (u, x) -PC (m,0), and the expenditure balance w is increased by the recharge amount m, and is thus recorded in the blockchain ledger as the plaintext amount w + m; meanwhile, the value of income balance is unchanged.

As the expenditure balance in the account continuously participates in remittance transaction, and the main balance continuously charges to the expenditure balance, the main balance is gradually reduced; when the main balance is reduced to a certain degree or reduced to 0, the expenditure balance cannot be continuously maintained to participate in the remittance transaction, so that the funds obtained from the income balance can be transferred into the main balance, so as to maintain the account to continuously participate in the remittance transaction.

FIG. 11 is an interaction diagram illustrating a merge operation, according to an exemplary embodiment. As shown in fig. 11, the interactive process may include the following steps:

in step 1101, the remitter determines the withdrawal amount n.

In one embodiment, the merge operation is used to transfer all funds of the income balance, a specified funds of the expense balance, which may be in an amount specified by the withdrawal amount n described above, into the main balance. If the withdrawal amount n is 0, it is equivalent to only transferring the income amount to the main balance, or n may be set to any other value, which is not limited in the present specification.

Step 1102, the remitter signs the transaction Merge (A: n) and submits the signed transaction Merge to the blockchain.

In an embodiment, taking the blockchain account 1 of the user a as an example, the "a" in the transaction represents an account address of the blockchain account 1, which indicates that a merging operation needs to be performed on the blockchain account 1, specifically, an income balance is completely transferred to a main balance, and a fund n in an expenditure balance is transferred to the main balance. And Merge indicates that the current transaction type is a Merge transaction for conducting a Merge operation against blockchain account 1.

In one embodiment, because the income balance is transferred into the main balance in its entirety, rather than into part, interval proofs need not be generated for part of the income balance; the extracted amount n and the expenditure balance are plaintext, and the generation of interval proof is not needed.

At step 1103, the block link points verify the transaction.

In one embodiment, the chunk node may verify whether the signature of the transaction Merge (A: n) is correct; if not, the transaction may be denied.

In one embodiment, the block link point may verify whether the extraction amount n of the transaction Merge (a: n) satisfies 1 ≦ n ≦ w, w being a value of the expenditure balance; if not, the transaction may be denied.

When all verifications have passed, step 1104 may be entered.

In step 1104, the block link points update the accounts.

In one embodiment, after verification through step 1103, the blockchain link point may update blockchain account 1 recorded in the blockchain ledger, as shown in fig. 12:

After the transaction is completed, the revenue balance becomes 0; the main balance is increased by the total amount of the income balance and the withdrawal amount n described above, and is thus recorded in the blockchain ledger as the corresponding commitment amount PC (u, x) + PC (v, y) + PC (n,0), while the expenditure balance w is decreased by the withdrawal amount n, and is thus recorded in the blockchain ledger as the plaintext amount w-n.

Although in the embodiments provided herein, the main balance, income balance, and expenditure balance of an account may be involved in remittance transactions, income balance in remittance transactions (income balance also charges a zero amount in remittance transactions), and main balance in the above-described recharge and merge transactions by using the expenditure balance, it does not mean that each balance can only participate in the above-described types of transactions. For example, the account structure of the present specification may also be compatible with: the participation of the main balance in the main balance transfer transaction of remitted funds, the participation of the payout balance in the open transfer transaction, etc., are described separately below.

Fig. 13 is a flowchart of another blockchain transaction method according to an example embodiment. As shown in fig. 13, the method is applied to an remitter device, and the method includes:

step 1302, determining a transaction amount to be remitted from a remitter account to a recipient account, the remitter account including a remitter primary balance with a commitment amount, a remitter revenue balance with the commitment amount, and a remitter payout balance with a cleartext amount, the recipient account including a recipient primary balance with the commitment amount, a recipient revenue balance with the commitment amount, and a recipient payout balance with the cleartext amount.

In an embodiment, the remitter account and the receiver account both adopt the account structures as shown in fig. 8, which are the remitter main balance, the remitter income balance and the remitter expenditure balance in the remitter account, and the receiver main balance, the receiver income balance and the receiver expenditure balance in the receiver account, respectively.

Step 1304, submitting a main balance transfer transaction to a blockchain, wherein the main balance transfer transaction comprises a transaction amount acceptance corresponding to the transaction amount and an interval certification used for proving that the transaction amount is not negative and the main balance of the remittance party is not less than the transaction amount, so that the transaction amount is deducted from the main balance of the remittance party after the transaction is completed, and the transaction amount is increased by the income balance of the receiving party after the transaction is completed.

In an embodiment, because the main balance of the remittance party and the income balance of the receiving party are both recorded in the blockchain account book in the form of committed amount, the data leakage can be avoided in the transaction process through the main balance transfer transaction, and the privacy and safety of the data are ensured.

In one embodiment, the remittance may compare the transaction amount with the alternative deduction amount contained in the above-mentioned alternative deduction amount set; if all the alternative deductions are less than the transaction amount, the remittance creates and submits the above-described main balance transfer transaction, and if any alternative deduction not less than the transaction amount exists, the remittance may create and submit a limited public transfer transaction, so that the remittance of the balance and the remittance of the remittance participate in implementing a limited public type transfer operation by the remittance of the embodiment shown in fig. 5, contributing to high concurrency.

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

In one embodiment, since the remitter main balance and the remitter expenditure balance are independent of each other, the remitter may even initiate different transactions through the remitter main balance and the remitter expenditure balance, respectively, at the same time. For example, limited public transfer transactions with smaller amounts of balance participation may be paid out by the remitter party, while major balance transfer transactions with larger amounts may be participated in by the remitter party's major balance to improve transaction efficiency.

The following describes an implementation process of limited public transaction by taking a user a as an remitter and a user B as a receiver as an example. FIG. 14 is a flow diagram of a master balance based fully private money transfer transaction provided by an exemplary embodiment; as shown in fig. 14, the interaction process between the remitter, the recipient and the tile chain node may include the following steps:

at step 1401, the remitter determines the transfer amount t.

In step 1402, the remitter determines a random number r corresponding to the remittance amount t.

In step 1403, the sink sends (r, T) to the receiver via the downlink channel.

The receiver verifies the received (r, T), step 1404.

At step 1405, after the verification is passed, the receiving party generates a signature and returns the signature to the remitting party.

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

In one embodiment, to ensure that the money transfer transaction is completed successfully, the block link points may determine that the money transfer amount t and the main balance u satisfy the following conditions: t is more than or equal to 0 and less than or equal to u; the interval certification technology may enable the block chain node to verify whether the transaction meets the preset condition in the ciphertext state, for example, the specification may be implemented by using a bullletprofofs scheme, a Borromean ring signature scheme, and the like in the related art, which is not limited in the specification. The remitter can use the interval proving technology to generate an interval proving RP for verifying whether t is more than or equal to 0 and less than or equal to u in the subsequent process by the block link points.

In step 1407, the remittance signs the transaction content PrimaryTransfer (A, B: T, RP; SigB) to generate a signature SigA.

In one embodiment, the exporter may sign the transaction content PrimaryTransfer (A, B: T, RP; SigB) with the exporter's private key, generating signature SigA.

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

At step 1408, the remittance submits the transaction to the blockchain.

In step 1409, the block nodes check whether the transaction has been executed.

In one embodiment, the blockchain node herein may represent any blockchain node in the blockchain network, i.e., each blockchain node in the blockchain network receives the money transfer transaction and performs authentication through steps 1409-1411.

In one embodiment, after receiving the money transfer transaction, the blocklink point may verify that the money transfer transaction has been performed using a money transfer prevention mechanism; if so, execution of the money transfer transaction may be denied, otherwise, the process proceeds to step 1410.

At step 1410, the block chain nodes check for signatures.

In one embodiment, the block node may check whether the signatures SigA, SigB included in the money transfer transaction are correct; if not, the money transfer transaction may be denied, otherwise, the process proceeds to step 1411.

In step 1411, the block link point check interval proves RP.

In one embodiment, the blockchain node may check the money transfer transaction's included zone attestation RP based on zone attestation techniques to determine if 0 ≦ t ≦ u. If not, execution of the money transfer transaction may be denied, otherwise, flow proceeds to step 1412.

In step 1412, the blockchain link points update the blockchain accounts corresponding to the user a and the user B in the maintained blockchain account book.

In one embodiment, after passing the verification of steps 1409-1411, the blockchain link points can update the blockchain account 1 and the blockchain account 2 recorded in the blockchain account book, respectively, as shown in fig. 15:

in the blockchain account 1 of the user a, the main balance before transaction is u, which is recorded in the blockchain ledger as the corresponding commitment amount PC (u, x), the income balance before transaction is v, which is recorded in the blockchain ledger as the corresponding commitment amount PC (v, y), and the expenditure balance before transaction is w, which is recorded in the blockchain ledger as the plaintext amount w. After the transaction is completed, the main balance is deducted by the transaction amount t, and is recorded as the corresponding commitment amount PC (u, x) -PC (t, r) in the blockchain ledger, while the income balance v and the expenditure balance w are unchanged.

In the blockchain account 2 of the user B, the principal balance before transaction is u ', recorded in the blockchain ledger as the corresponding commitment amount PC (u', x '), the income balance before transaction is v', recorded in the blockchain ledger as the corresponding commitment amount PC (v ', y'), the expenditure balance before transaction is w ', recorded in the blockchain ledger as the plaintext amount w'. After the transaction is completed, the main balance u ', the payout balance w' is unchanged, and the income balance is increased by the remittance amount t, and thus 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 according to an example embodiment. As shown in fig. 16, the method is applied to an remitter device, and the method includes:

step 1602, determining a transaction amount to be remitted from a remitter account to a recipient account, the remitter account including a remitter primary balance with a commitment amount, a remitter revenue balance with the commitment amount, and a remitter payout balance with a plaintext amount, the recipient account including a recipient primary balance with the commitment amount, a recipient revenue balance with the commitment amount, and a recipient payout balance with the plaintext amount.

Step 1604, submitting a public transfer transaction to the blockchain, the public transfer transaction including a public transaction amount corresponding to the public transaction amount, so that the remittance expenditure balance deducts the public transaction amount after the transaction is completed, and the receiver expenditure balance increases the public transaction amount after the transaction is completed.

In one embodiment, when the value of the remittance payout balance is recorded as a plaintext value, the high concurrency of the transfer transaction may be traded for by sacrificing the plaintext value. When the remitter receives the setting, the remitter is shown to be between privacy protection and transaction efficiency, and higher transaction efficiency is allowed to be exchanged by sacrificing partial privacy, so that in some scenes, for example, for partial independent transfer with small amount of money, the remitter can directly implement transfer between the remitter expenditure balance and the receiver expenditure balance by submitting the public transfer transaction, the process is similar to the transfer operation in the related technology without privacy protection scenes, and the transaction efficiency can be greatly improved because various complex processing operations such as encryption, generation interval certification, verification interval certification and the like are not required to be implemented.

In one embodiment, the privacy type setting information may be acquired, and the privacy type setting information may be temporarily set by the user according to actual needs or set to be effective for a long time. When the privacy type setting information is a non-privacy type, it indicates that the user relatively pays more attention to the transaction efficiency, and thus the public transfer transaction can be submitted to the blockchain based on the above. And when the privacy type setting information is the privacy type, it indicates that the user relatively pays more attention to privacy, so that the limited public transfer transaction or the primary balance transfer transaction may be submitted to the blockchain based on the embodiment shown in fig. 5 or 13.

Wherein, under the scene of private type, the user can further set and select limited public transfer transaction or main balance transfer transaction; alternatively, as described above, the limited public transfer transaction may be selected preferably, and the main balance transfer transaction may be selected when the remittance payout balance is less than the transaction amount, which may be referred to as the embodiment shown in fig. 13 and will not be described herein again.

The following describes an implementation process of limited public transaction by taking a user a as an remitter and a user B as a receiver as an example. FIG. 17 is a flow diagram of a public remittance transaction conducted based on a payout balance, provided by an exemplary embodiment; as shown in fig. 17, the interaction process between the remitter, the recipient and the tile chain node may include the following steps:

at step 1701, the remitter determines the transfer amount t.

In one embodiment, the transfer amount t may be negotiated between the transferor and the recipient at the time of the draft transaction. Of course, the remitter may also determine the remittance amount t by itself.

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

In one embodiment, the exporter may sign the transaction content OpenTransfer (a, B: t) with the exporter's private key, generating signature SigA.

Among other things, OpenTransfer is used to indicate that the transaction type is a public transfer transaction (or, referred to as a public remittance transaction).

Step 1703, the block link points verify the transaction.

In one embodiment, after receiving the money transfer transaction, the blocklink point may verify that the money transfer transaction has been performed using a money transfer prevention mechanism; if so, execution of the money transfer transaction may be denied, otherwise, execution proceeds to step 1704.

In one embodiment, the block node may check whether the signature SigA included in the money transfer transaction is correct; if not, execution of the money transfer transaction may be denied, otherwise, execution proceeds to step 1704.

In step 1704, the blockchain link point updates the blockchain accounts corresponding to the user a and the user B in the maintained blockchain account book.

In one embodiment, after passing the verification of step 1703, the blockchain link points may update the blockchain account 1 and the blockchain account 2 recorded in the blockchain account book, respectively, as shown in fig. 18:

in the blockchain account 1 of the user a, the main balance before transaction is u, which is recorded in the blockchain ledger as the corresponding commitment amount PC (u, x), the income balance before transaction is v, which is recorded in the blockchain ledger as the corresponding commitment amount PC (v, y), and the expenditure balance before transaction is w, which is recorded in the blockchain ledger as the plaintext amount w. After the transaction is completed, the expenditure balance w is deducted by the transaction amount t, and is recorded as a corresponding plaintext amount w-t in the blockchain account, while the income balance v and the main balance u are unchanged.

In the blockchain account 2 of the user B, the principal balance before transaction is u ', recorded in the blockchain ledger as the corresponding commitment amount PC (u', x '), the income balance before transaction is v', recorded in the blockchain ledger as the corresponding commitment amount PC (v ', y'), the expenditure balance before transaction is w ', recorded in the blockchain ledger as the plaintext amount w'. After the transaction is completed, the main balance u ', income balance v' are unchanged, and the expenditure balance w 'is increased by the remittance amount t, and thus recorded in the blockchain ledger as the corresponding plaintext amount w' + t.

FIG. 19 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 19, at the hardware level, the apparatus includes a processor 1902, an internal bus 1904, a network interface 1906, a memory 1908, and a non-volatile memory 1910, although other hardware required by the service may be included. The processor 1902 reads a corresponding computer program from the non-volatile memory 1910 into the memory 1908 and then runs, forming a blockchain transaction device on a logical level. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Referring to fig. 20, in a software implementation, the blockchain transaction apparatus may include:

a determining unit 2001 for determining a transaction amount to be remitted from a remitter account into a receiver account, the remitter account including a remitter main balance using a commitment amount, a remitter income balance using the commitment amount, and a remitter expenditure balance of a plaintext amount, the receiver account including a receiver main balance using the commitment amount, a receiver income balance using the commitment amount, and a receiver expenditure balance of the plaintext amount;

a submitting unit 2002 that submits a public transfer transaction to the blockchain, the public transfer transaction including a public transaction amount corresponding to the public transaction amount, such that the remittance expenditure balance deducts the public transaction amount after the transaction is completed, and the receiver expenditure balance increases the public transaction amount after the transaction is completed.

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

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

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

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

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

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

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

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

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

Claims

1. A block chain transaction method, applied to an exporter device, the method comprising:

Determine the transaction amount to be remitted from the sender's account to the recipient's account, the sender's account including the sender's income balance in the committed amount and the sender's expenditure balance in the express amount, the receiver account including the use of the commitment The recipient's income balance of the amount and the recipient's expenditure balance of the plaintext amount;

Obtain privacy type setting information;

When the initiation condition of the limited public transfer transaction is satisfied, the limited public transfer transaction is submitted to the blockchain, and the limited public transfer transaction includes the transaction amount commitment and the deduction amount corresponding to the transaction amount, which are used to prove the The interval proof that the transaction amount is non-negative and the deduction amount is not less than the transaction amount, so that the deduction amount is deducted from the balance of the sender's expenditure after the transaction is completed, and the income balance of the sender is after the transaction is completed. The difference between the debit amount and the transaction amount is increased, the income balance of the receiver is increased after the transaction is completed, and the transaction amount is increased, and the initiation condition of the limited public transfer transaction includes the privacy type setting information is a private type.

2. The method according to claim 1, the initiation condition of the limited public transfer transaction further comprises at least one of the following:

The user sets to select limited public transfer transactions, the limited public transfer transactions are set to be preferred, the balance of the sender's expenditure is not less than the transaction amount, and the set of alternative deduction amounts corresponding to the sender's account The alternative debit amount of any predetermined value within the range is not less than the transaction amount.

3. The method of claim 2, wherein the sender's account includes a sender's main balance in a committed amount, and the recipient's account includes a receiver's main balance in a committed amount; the method further comprises:

When the privacy type setting information is the private type and the initiation condition of the main balance transfer transaction is satisfied, the main balance transfer transaction is submitted to the blockchain, and the main balance transfer transaction includes the transaction amount corresponding to the transaction amount Commitment and interval proof used to prove that the transaction amount is non-negative and the main balance of the sender is not less than the transaction amount, so that the main balance of the sender deducts the transaction amount, the receiver’s main balance after the transaction is completed After the transaction is completed, the income balance of the party increases the transaction amount, and the initiation conditions of the main balance transfer transaction include at least one of the following: the user sets the main balance transfer transaction to be selected, and the main balance transfer transaction is set to be preferred. In addition, the balance of expenditure of the sender is less than the transaction amount, and the alternative deduction amounts of several predetermined values in the set of alternative deduction amounts corresponding to the account of the sender are all smaller than the transaction amount.

4. The method of claim 1, further comprising:

When the privacy type setting information is a non-private type, a public transfer transaction is submitted to the blockchain, and the public transfer transaction includes the public transaction amount corresponding to the transaction amount, so that the payment balance of the sender is completed after the transaction is completed. After deducting the public transaction amount, the recipient's expenditure balance increases the public transaction amount after the transaction is completed.

5. The method of claim 1, further comprising:

acquiring a set of alternative deduction amounts corresponding to the sender's account, where the set of alternative deduction amounts includes a number of alternative deduction amounts of predetermined values;

Any alternative deduction amount not less than the transaction amount is selected as the deduction amount.

6. The method according to claim 1 or 3, wherein the transaction amount commitment is calculated by a preset encryption algorithm according to the transaction amount and the transaction random number; the method further comprises:

Before submitting the main balance transfer transaction or the limited public transfer transaction, the transaction amount, the transaction amount commitment, and the transaction nonce are sent to the recipient device through an off-chain channel for the recipient device The device verifies the correspondence between the transaction amount commitment, the transaction random number and the transaction amount;

Receive the receiver's signature returned by the receiver's device to add to the main balance transfer transaction or the limited public transfer transaction; wherein the receiver's signature is verified by the receiver's device in the corresponding relationship generated later.

7. The method of claim 1, wherein when the sender balance of the sender account increases, a corresponding amount is added to the sender revenue balance.

8. The method of claim 1, the sender account comprising a sender master balance in a committed amount, the recipient account comprising a recipient master balance in a committed amount; the method further comprising:

Submit a recharge transaction to the blockchain, and the recharge transaction includes the recharge amount and the interval proof used to prove that the main balance of the sender is not less than the recharge amount, so that the main balance of the sender will be deducted after the transaction is completed. The recharge amount and the spending balance of the sender will increase the recharge amount after the transaction is completed.

9. The method of claim 8, further comprising:

Submitting a merged transaction to the blockchain, the merged transaction including the merged amount;

Wherein, after the transaction is completed, the balance of the sender's expenditure is deducted from the combined amount, the main balance of the sender is increased by the combined amount after the transaction is completed, and/or the balance of the sender's income is after the transaction is completed. Cleared, the main balance of the sender increases the income balance after the transaction is completed.

10. A blockchain transaction method, applied to a blockchain node, the method comprising:

Receive a limited public transfer transaction, the limited public transfer transaction is submitted by the sender device when the initiation condition of the limited public transfer transaction is satisfied, and the initiation condition of the limited public transfer transaction includes: the privacy type setting information is private type; and, the sender device is used to determine the transaction amount to be transferred from the sender account to the receiver account, the sender account including the sender revenue balance in the committed amount and the remittance amount in the clear The sender's expenditure balance, the receiver's account includes the receiver's income balance in the promised amount and the receiver's expenditure balance in the clear text amount;

Execute the limited public transfer transaction, where the limited public transfer transaction includes a transaction amount commitment corresponding to the transaction amount, a deduction amount, which is used to prove that the transaction amount is not negative and the deduction amount is not less than the transaction amount. The interval proof, so that the deduction amount is deducted after the transaction is completed from the expenditure balance of the sender, and the difference between the deduction amount and the transaction amount is added to the income balance of the sender after the transaction is completed. . The receiver's income balance increases the transaction amount after the transaction is completed.

11. The method according to claim 10, the initiation condition of the limited public transfer transaction further comprises at least one of the following:

12. The method of claim 11, the sender account comprising a sender master balance in a committed amount and the recipient account comprising a recipient master balance in a committed amount; the method further comprising:

Receive a main balance transfer transaction, the main balance transfer transaction is submitted by the sender device when the privacy type setting information is a private type and the initiation condition of the main balance transfer transaction is satisfied, and the main balance transfer transaction is The transaction initiation conditions include at least one of the following: the main balance transfer transaction is set to be selected by the user, the main balance transfer transaction is set to be preferred, and the outgoing balance of the sender is less than the transaction amount, and the sender The alternative deduction amounts of several predetermined values in the set of alternative deduction amounts corresponding to the party's account are all smaller than the transaction amount;

Execute the main balance transfer transaction, where the main balance transfer transaction includes a transaction amount commitment corresponding to the transaction amount and an interval used to prove that the transaction amount is non-negative and the sender's main balance is not less than the transaction amount Proof, 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.

13. The method of claim 10, further comprising:

receiving a public transfer transaction, which is submitted by the sender device when the privacy type setting information is a non-private type;

Execute the public transfer transaction, where the public transfer transaction includes the public transaction amount corresponding to the transaction amount, so that after the transaction is completed, the payout balance of the sender is deducted from the open transaction amount, and the payout balance of the receiver is in the transaction. Increase the stated public transaction amount upon completion.

14. The method of claim 10, the sender account comprising a sender master balance in a committed amount and the recipient account comprising a recipient master balance in a committed amount; the method further comprising:

receiving a recharge transaction submitted by the remittance device, the recharge transaction includes a recharge amount and an interval certificate used to prove that the main balance of the remittance party is not less than the recharge amount;

The recharge transaction is performed, so that the recharge amount is deducted from the main balance of the sender after the transaction is completed, and the recharge amount is added to the expenditure balance of the sender after the transaction is completed.

15. The method of claim 14, further comprising:

receiving a merged transaction submitted by the sender device, the merged transaction including a merged amount;

executing the combined transaction such that the sender payout balance deducts the combined amount after the transaction is completed, the sender master balance increases the combined amount after the transaction is completed, and/or the sender The income balance is cleared after the transaction is completed, and the main balance of the sender increases the income balance after the transaction is completed.

16. A block chain transaction device, applied to equipment of an exporter, the device comprising:

A determination unit, which determines the transaction amount to be remitted from the sender's account to the recipient's account, where the sender's account includes the sender's income balance using the committed amount and the sender's expenditure balance in the plaintext amount, and the receiver's account Including the recipient's income balance in the promised amount and the recipient's expenditure balance in the express amount;

The submitting unit obtains the privacy type setting information; when the initiation condition of the limited public transfer transaction is satisfied, the limited public transfer transaction is submitted to the blockchain, and the limited public transfer transaction includes the transaction amount commitment corresponding to the transaction amount , the deduction amount, the interval proof used to prove that the transaction amount is not negative and the deduction amount is not less than the transaction amount, so that the payment balance of the sender is deducted from the deduction amount and the deduction amount after the transaction is completed. The income balance of the sender increases the difference between the deduction amount and the transaction amount after the transaction is completed, and the income balance of the receiver increases the transaction amount after the transaction is completed. The initiation condition includes that the privacy type setting information is a privacy type.

17. An electronic device comprising:

processor;

memory for storing processor-executable instructions;

Wherein, the processor implements the method of any one of claims 1-15 by executing the executable instructions.

18. A computer-readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method of any of claims 1-15.