CN110033370B - Account creation method and device, electronic equipment and storage medium - Google Patents

Account creation method and device, electronic equipment and storage medium Download PDF

Info

Publication number
CN110033370B
CN110033370B CN201910105428.5A CN201910105428A CN110033370B CN 110033370 B CN110033370 B CN 110033370B CN 201910105428 A CN201910105428 A CN 201910105428A CN 110033370 B CN110033370 B CN 110033370B
Authority
CN
China
Prior art keywords
transaction
amount
balance
account
blockchain
Prior art date
Application number
CN201910105428.5A
Other languages
Chinese (zh)
Other versions
CN110033370A (en
Inventor
蒋国飞
陈盛龙
胡丹青
陈春伟
马宝利
马环宇
闫雪冰
张文彬
Original Assignee
阿里巴巴集团控股有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 阿里巴巴集团控股有限公司 filed Critical 阿里巴巴集团控股有限公司
Priority to CN201910105428.5A priority Critical patent/CN110033370B/en
Publication of CN110033370A publication Critical patent/CN110033370A/en
Application granted granted Critical
Publication of CN110033370B publication Critical patent/CN110033370B/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Exchange, e.g. stocks, commodities, derivatives or currency exchange

Abstract

One or more embodiments of the present specification provide an account creation method and apparatus, an electronic device, and a storage medium, which are applied to a blockchain node, where the method includes: receiving a blockchain transaction, wherein the type of the blockchain transaction is an account creation type; and executing the block chain transaction to create a first account, wherein the first account comprises an income balance adopting a ciphertext amount and an expenditure balance adopting a plaintext amount, and when the deduction amount is transferred from the expenditure balance in a plaintext form, the change making amount is transferred into the income balance in a ciphertext form, and the change making amount is the difference between the deduction amount and the transaction amount.

Description

Account creation 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 an account creation method and apparatus, 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 specification provide an account creation method and apparatus, 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 an account creation method applied to a blockchain node, the method including:

receiving a blockchain transaction, wherein the type of the blockchain transaction is an account creation type;

and executing the block chain transaction to create a first account, wherein the first account comprises an income balance adopting a ciphertext amount and an expenditure balance adopting a plaintext amount, and when the deduction amount is transferred from the expenditure balance in a plaintext form, the change making amount is transferred into the income balance in a ciphertext form, and the change making amount is the difference between the deduction amount and the transaction amount.

According to a second aspect of one or more embodiments of the present specification, there is provided an account creation apparatus applied to a blockchain node, the apparatus including:

the receiving unit is used for receiving the blockchain transaction, and the type of the blockchain transaction is an account creation type;

and the execution unit is used for executing the block chain transaction to create a first account, wherein the first account comprises an income balance adopting a ciphertext amount and an expenditure balance adopting a plaintext amount, and when the deduction amount is transferred from the expenditure balance in a plaintext form, the change making amount is transferred into the income balance in a ciphertext form, and the change making amount is the difference between the deduction amount and the transaction amount.

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:

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

In step 1402, 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.

In step 1403, the sink sends (r, T) to the receiver via 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.

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

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.

At step 1405, 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 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 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 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.

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

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 an account creation apparatus 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 account creation apparatus may include:

a receiving unit 2001, configured to receive a blockchain transaction, where a type of the blockchain transaction is an account creation type;

the executing unit 2002 is configured to execute the blockchain transaction to create a first account, where the first account includes an income balance using a ciphertext amount and an expenditure balance using a plaintext amount, and when the deduction amount is transferred from the expenditure balance in a plaintext form, the change-making amount is transferred to the income balance in a ciphertext form, where the change-making amount is a difference between the deduction amount and the transaction amount.

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 (11)

1. An account creation method applied to a blockchain node, the method comprising:
receiving a blockchain transaction, wherein the type of the blockchain transaction is an account creation type;
performing the blockchain transaction to create a first account comprising an income balance in the amount of ciphertext and a spending balance in the amount of plaintext, the income balance being registered as a corresponding balance commitment;
receiving a limited public transfer transaction, wherein the limited public transfer transaction comprises a transaction amount acceptance, an interval certification and a deduction amount corresponding to a transaction amount, the interval certification is used for proving that the transaction amount is not negative and the deduction amount is not less than the transaction amount, and the limited public transfer transaction is used for transferring money from the expenditure balance of the first account to a second account;
and executing the limited public transfer transaction, transferring the deduction amount from the expenditure balance in a clear text form, adding a deduction amount acceptance corresponding to the deduction amount to the income balance, subtracting the transaction amount acceptance and adding the transaction amount acceptance to the second account.
2. The method of claim 1, the revenue balances being registered as respective balance commitments; the method further comprises the following steps:
receiving an remittance transfer transaction, a transaction amount of the remittance transfer transaction being characterized as a corresponding transaction amount commitment for transferring money from a second account to the first account;
performing the money transfer transaction to credit the transaction amount commitment into the revenue balance, deduct the transaction amount from the second account, or the transaction amount commitment.
3. The method of claim 1, the first account further comprising a primary balance in ciphertext amounts, the primary balance being registered as a corresponding balance commitment; the method further comprises the following steps:
receiving a recharging transaction, wherein the recharging transaction comprises a recharging amount and an interval certificate, and the interval certificate is used for proving that the main balance is not less than the recharging amount;
and executing the recharging transaction so as to subtract a recharging amount commitment corresponding to the recharging amount from the main balance and count the recharging amount into the expenditure balance.
4. The method of claim 3, further comprising:
receiving a consolidated transaction, the consolidated transaction including a consolidated amount;
and executing the combined transaction to subtract the combined amount from the expenditure balance, to credit a combined amount commitment corresponding to the combined amount to the main balance, and/or to zero the income balance, to credit a balance commitment in which the income balance is registered to the main balance.
5. The method of claim 3, said primary balance being registered as a respective balance commitment; the method further comprises the following steps:
receiving a main balance transfer transaction, wherein the main balance transfer transaction comprises a transaction amount acceptance corresponding to a transaction amount and an interval certification, the interval certification is used for certifying that the transaction amount is not negative and the main balance is not less than the transaction amount, and the main balance transfer transaction is used for transferring money from the main balance of the first account to a second account;
executing the primary balance transfer transaction to subtract the transaction amount commitment from a balance commitment corresponding to the primary balance, credit the transaction amount or the transaction amount commitment into the second account.
6. The method of claim 1, wherein the deduction amount is selected from a set of alternative deduction amounts corresponding to the first account, the set of alternative deduction amounts comprising a plurality of alternative deduction amounts of a predetermined value.
7. The method of claim 1, further comprising:
receiving a public transfer transaction, the public transfer transaction including a transaction amount;
performing the public transfer transaction to debit the payout balance by subtracting the transaction amount, crediting the second account with the transaction amount.
8. The method of claim 1, the first account being an external account, a contract account, or an asset account.
9. An account creation apparatus applied to a blockchain node, the apparatus comprising:
the receiving unit is used for receiving the blockchain transaction, and the type of the blockchain transaction is an account creation type;
an execution unit to execute the blockchain transaction to create a first account including an income balance in a ciphertext amount and a spending balance in a plaintext amount, the income balance being registered as a corresponding balance commitment; receiving a limited public transfer transaction, wherein the limited public transfer transaction comprises a transaction amount acceptance, an interval certification and a deduction amount corresponding to a transaction amount, the interval certification is used for proving that the transaction amount is not negative and the deduction amount is not less than the transaction amount, and the limited public transfer transaction is used for transferring money from the expenditure balance of the first account to a second account; and executing the limited public transfer transaction, transferring the deduction amount from the expenditure balance in a clear text form, adding a deduction amount acceptance corresponding to the deduction amount to the income balance, subtracting the transaction amount acceptance and adding the transaction amount acceptance to the second account.
10. An electronic device, comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the method of any one of claims 1-8 by executing the executable instructions.
11. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of claims 1 to 8.
CN201910105428.5A 2019-02-01 2019-02-01 Account creation method and device, electronic equipment and storage medium CN110033370B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910105428.5A CN110033370B (en) 2019-02-01 2019-02-01 Account creation method and device, electronic equipment and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010532071.1A CN111784341A (en) 2019-02-01 2019-02-01 Block chain transaction method and device, electronic equipment and storage medium
CN201910105428.5A CN110033370B (en) 2019-02-01 2019-02-01 Account creation method and device, electronic equipment and storage medium

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN202010532071.1A Division CN111784341A (en) 2019-02-01 2019-02-01 Block chain transaction method and device, electronic equipment and storage medium

Publications (2)

Publication Number Publication Date
CN110033370A CN110033370A (en) 2019-07-19
CN110033370B true CN110033370B (en) 2020-04-24

Family

ID=67235629

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202010532071.1A CN111784341A (en) 2019-02-01 2019-02-01 Block chain transaction method and device, electronic equipment and storage medium
CN201910105428.5A CN110033370B (en) 2019-02-01 2019-02-01 Account creation method and device, electronic equipment and storage medium

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN202010532071.1A CN111784341A (en) 2019-02-01 2019-02-01 Block chain transaction method and device, electronic equipment and storage medium

Country Status (1)

Country Link
CN (2) CN111784341A (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106549749A (en) * 2016-12-06 2017-03-29 杭州趣链科技有限公司 A kind of block chain method for secret protection encrypted based on additive homomorphism
CN106982205A (en) * 2017-03-01 2017-07-25 中钞信用卡产业发展有限公司北京智能卡技术研究院 Digital asset treating method and apparatus based on block chain
CN107483181A (en) * 2017-08-28 2017-12-15 北京金股链科技有限公司 Measure of managing contract, device and terminal
CN109257182A (en) * 2018-10-24 2019-01-22 杭州趣链科技有限公司 A kind of block chain method for secret protection that the cryptography promise based on homomorphism is proved with Zero Knowledge range

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180365688A1 (en) * 2017-06-14 2018-12-20 International Business Machines Corporation Transaction execution and validation in a blockchain

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106549749A (en) * 2016-12-06 2017-03-29 杭州趣链科技有限公司 A kind of block chain method for secret protection encrypted based on additive homomorphism
CN106982205A (en) * 2017-03-01 2017-07-25 中钞信用卡产业发展有限公司北京智能卡技术研究院 Digital asset treating method and apparatus based on block chain
CN107483181A (en) * 2017-08-28 2017-12-15 北京金股链科技有限公司 Measure of managing contract, device and terminal
CN109257182A (en) * 2018-10-24 2019-01-22 杭州趣链科技有限公司 A kind of block chain method for secret protection that the cryptography promise based on homomorphism is proved with Zero Knowledge range

Also Published As

Publication number Publication date
CN111784341A (en) 2020-10-16
CN110033370A (en) 2019-07-19

Similar Documents

Publication Publication Date Title
JP6687715B2 (en) Method and system for fraud detection in blockchain-based transactions
JP6695960B2 (en) Method and system for processing blockchain-based transactions on an existing payment network
US9825931B2 (en) System for tracking and validation of an entity in a process data network
JP6794527B2 (en) Computer system using secure ledger distribution method and secure distributed ledger technology
Franco Understanding bitcoin
US20190378100A1 (en) System and method for transferring funds
KR20200129073A (en) The trading system and the method based on a blockchain
US10412060B2 (en) Token enrollment system and method
US20170372278A1 (en) Payment system for carrying out electronic settlements using blockchain technology
US20170236103A1 (en) Peer-to-Peer Financial Transactions Using A Private Distributed Ledger
US20200334645A1 (en) Resource transfer system
US10275772B2 (en) Cryptocurrency risk detection system
US10387878B2 (en) System for tracking transfer of resources in a process data network
US9836790B2 (en) Cryptocurrency transformation system
US10255600B2 (en) Cryptocurrency offline vault storage system
US20150371224A1 (en) Cryptocurrency infrastructure system
US10657502B2 (en) Systems and methods for performing financial transactions
US10693658B2 (en) Methods and systems for using digital signatures to create trusted digital asset transfers
US20190123892A1 (en) Systems and methods of self-forking blockchain protocol
US20170124645A1 (en) Trust based transaction system
US20190244186A1 (en) Electronic bill management method, apparatus, and storage medium
US10318936B2 (en) System and method for transferring funds
US10552556B2 (en) System and method for performance testing of scalable distributed network transactional databases
US20150356523A1 (en) Decentralized identity verification systems and methods
US8285640B2 (en) System and methods for facilitating fund transfers over a network

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20200923

Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Patentee after: Innovative advanced technology Co.,Ltd.

Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Patentee before: Advanced innovation technology Co., Ltd

Effective date of registration: 20200923

Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Patentee after: Advanced innovation technology Co., Ltd

Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands

Patentee before: Alibaba Group Holding Ltd.