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 flowchart of a block chain-based remittance method according to an exemplary embodiment, applied to a customer premise equipment of a block chain, in which an account balance of a customer account is divided into at least a reserve balance and a spare balance; wherein the user account includes a dynamically updated reserve fund list; the reserve money list includes a plurality of reserve money amounts.
The block chain in the above embodiments may specifically refer to a P2P network system with a distributed data storage structure, which is achieved by a consensus mechanism, where data in the block chain is distributed in temporally consecutive blocks (blocks), and the latter block contains data digests of the former block, and full backup of data of all or part of nodes is achieved according to different specific consensus mechanisms (such as POW, POS, DPOS, PBFT, and so on). It is well known to those skilled in the art that, since the blockchain system operates under a corresponding consensus mechanism, data that has been included in the blockchain database is difficult to be tampered with by any node, for example, a blockchain with Pow consensus is adopted, and it is possible to tamper with existing data only by an attack that requires at least 51% of effort on the whole network, so that the blockchain system has characteristics that other centralized database systems cannot reasonably guarantee data security and tamper resistance. It can be seen that in the embodiments provided herein, remittance transactions and other transactions that are included in the distributed databases of the blockchain are not susceptible to attack or tampering, thereby proving the transactions issued to the distributed databases of the blockchain.
The customer premise equipment for executing the method for remittance based on a blockchain according to this embodiment may be a node equipment of the blockchain, or a customer premise equipment connected to the node equipment of the blockchain, and is not limited in this specification.
The block chain is used as a general decentralized platform for managing state conversion of objects, a user account is a stateful object, the content included in the user account can be the content included in the state of the user account, and the user account provided by the specification comprises account balance information and a reserve fund list for supporting remittance transactions. In this description, to support the user's ability to send money transfer transactions without suspension, a dynamically updated reserve money list is included in the user's account, the reserve money list including a plurality of reserve money amounts.
The multiple reserve amounts may be allocated in different money transfer transactions, providing proof of each money transfer transaction as being sufficient to pay its amount of money. It should be noted that the "account" described in this specification is not limited to the external all account (EOA) and the Contract account (Contract), and also does not limit the specific expression of the reserve fund list, as long as the data organization form, such as the one-dimensional table, the two-dimensional table, the tree data structure, etc., containing or managing the plurality of reserve fund amounts all belong to the reserve fund list described in this specification. The values of the reserve balance and the reserve balance described in this specification may not be displayed in the user account status of the blockchain, but may be displayed or managed by the user client; of course, the values of the reserve balance and the reserve balance may be displayed in the user account status of the blockchain, and are not limited in this specification.
As shown in FIG. 1, the above money transfer method may include the steps of:
102, responding to a remittance operation initiated by a user, and distributing corresponding reserve money amount for the remittance amount submitted by the user according to the current reserve money list;
and 104, constructing a remittance transaction based on the remittance amount and the allocated reserve amount, and issuing the remittance transaction to the blockchain so as to deduct the remittance amount from the account balance and the reserve balance after the remittance transaction is verified by the node equipment in the blockchain.
In the above embodiments, the amount of the reserve amount corresponding to the amount of the remittance is at least one and the sum of the reserve amounts corresponding to the amount of the remittance should be no less than the amount of the remittance for the transaction, thereby providing evidence of sufficient payment for the remittance transaction. For example, the current reserve money list includes four reserve money amounts {5,10,15,20}, and for a remittance transaction with a remittance amount of 10, the user equipment may select one reserve money amount 10 (or 15 or 20) from the four reserve money amounts, and allocate the one reserve money amount 10 (or 15 or 20) to the remittance transaction; corresponding to the remittance transaction with the remittance amount of 12, the user terminal device may select one reserve amount 15 (or 20) from the four reserve amounts, allocate the one reserve amount 15 (or 20) to the remittance transaction, or may select two reserve amounts 5 and 10 (or 5 and 15) from the four reserve amounts, allocate the two reserve amounts 15 (or 20) to the remittance transaction, and provide a verification proof that the remittance transaction is sufficiently paid by using the sum of the two reserve amounts.
In one embodiment, the transferor user and the recipient user may agree to transfer (or transfer) asset credentials corresponding to the amount of the money transfer from the transferor blockchain account to the recipient blockchain account. The asset voucher may correspond to an intelligent asset such as a token (token) and a digital asset in a blockchain, and may also correspond to an off-chain asset such as cash, securities, coupons and real estate outside the blockchain, which is not limited in this specification.
After the remittance transaction is established, the remittance transaction is sent to the block chain by the user terminal equipment, and verification of the node equipment in the block chain is received. Since the blockchain-based money transfer method provided by the present specification can be applied to blockchains based on multiple types of consensus mechanisms, the present specification does not limit the number and types of blockchain nodes performing verification on the money transfer transaction, nor the content or flow involved in the verification. However, those skilled in the art will appreciate that the verification includes at least verifying that the sum of the reserve amounts in the money transfer transaction is greater than or equal to the money transfer amount of the money transfer transaction to verify that the user account has a sufficient balance to cover the money transfer transaction. And after the remittance transaction is verified by the node equipment of the block chain, deducting the remittance amount from the account balance and the reserve balance of the user.
Fig. 2 illustrates the process of creating and updating the reserve fund list in the above embodiment, which can be summarized as two interconnected loop steps as shown in fig. 2:
step A, obtaining the balance of the current reserve fund, and obtaining a reserve fund list according to the balance of the current reserve fund;
and step B, dynamically monitoring whether the amount of reserve money available for distribution in the current reserve money list is lower than a preset threshold value, if so, switching the current reserve balance into the reserve money balance, and then executing the step A.
After the user registers as a user of the block chain, the user may divide the account balance into at least an initialized reserve balance and an initialized spare balance, and the user equipment first performs the process described in the above step a based on the initialized reserve balance.
The current spare balance can generate a spare sum in a new spare sum list after switching; optionally, before being triggered to generate a new reserve fund list, the reserve balance may serve as a remittance balance to support a user initiating a separate (non-concurrent) remittance transaction, or as a collection balance to receive remittance from another account to the user account; furthermore, when the account balance includes two or more spare balances, some of the spare balances may not participate in money transfer or collection, but only be static balances, so as to be triggered to divide the reserve amount in the new reserve list at an appropriate time (for example, when the reserve amount available for allocation in the reserve list generated based on the original reserve balance is lower than a preset threshold, or when a new reserve list construction instruction sent by the user is received).
In an embodiment, the process of obtaining the reserve fund list according to the current reserve fund balance in step a includes:
dividing the balance of the current reserve fund to obtain a plurality of reserve fund amounts, and constructing a reserve fund list to establish a transaction based on the plurality of reserve fund amounts obtained by dividing;
issuing the reserve fund list creation transaction to a blockchain to build a reserve fund list based on the plurality of reserve fund amounts obtained by the dividing at the user account after the reserve fund list creation transaction is verified by a node device in the blockchain.
In the above embodiment, the current reserve fund balance may be divided to obtain a plurality of reserve fund amounts, and in order to ensure that the plurality of reserve fund amounts are subjected to the consensus verification by the blockchain node, the sum of the plurality of reserve fund amounts divided based on the current reserve fund balance included in the reserve fund list creation transaction should not be greater than the reserve fund balance. Since the blockchain-based remittance method provided by the present specification can be applied to blockchains based on multiple types of consensus mechanisms, the present specification does not limit the number and types of blockchain nodes performing verification on the reserve fund list creation transaction, nor the content or flow involved in the verification. However, it will be appreciated by those skilled in the art that the verification at least comprises verifying that the sum of the reserve amounts in the reserve list creation transaction is less than or equal to the current reserve balance (or that at least the sum of the reserve amounts in the reserve list creation transaction is less than or equal to the current account balance when the reserve balance is not displayed in the user's account status) to verify the validity of the reserve balance. And after the reserve fund list creation transaction is verified by the node equipment of the blockchain, constructing a reserve fund list on the user account based on a plurality of reserve fund amounts obtained by the division and included in the reserve fund list creation transaction.
In another embodiment, the obtaining the reserve fund list according to the current reserve fund balance includes:
dividing the balance of the current reserve fund to obtain a plurality of reserve fund amounts, constructing a reserve fund list based on the plurality of reserve fund amounts obtained by dividing, and constructing a reserve fund list to establish a transaction based on the reserve fund list;
and issuing the reserve fund list creation transaction to the blockchain so as to update the reserve fund list to the user account after the reserve fund list creation transaction is verified by the node equipment in the blockchain.
In the above embodiment, the current reserve balance may be divided into a plurality of reserve amounts, a reserve list may be constructed based on the plurality of reserve amounts, and the reserve list including the plurality of reserve amounts divided based on the current reserve balance may be included in the reserve list creation transaction. In order to ensure that the plurality of reserve money amounts are subjected to consensus verification of the blockchain nodes, the sum of the plurality of reserve money amounts which are obtained by dividing the reserve money balance at present and are contained in the reserve money list creation transaction should not be larger than the reserve money balance. Since the blockchain-based remittance method provided by the present specification can be applied to blockchains based on multiple types of consensus mechanisms, the present specification does not limit the number and types of blockchain nodes performing verification on the reserve fund list creation transaction, nor the content or flow involved in the verification. However, it will be appreciated by those skilled in the art that the verification at least comprises verifying that the sum of the reserve amounts in the reserve list creation transaction is less than or equal to the current reserve balance (or that at least the sum of the reserve amounts in the reserve list creation transaction is less than or equal to the current account balance when the reserve balance is not displayed in the user's account status) to verify the validity of the reserve balance. And when the reserve fund list creation transaction is verified by the node equipment of the blockchain, updating the reserve fund list included in the reserve fund list creation transaction to the user account.
It will be appreciated by those skilled in the art that each reserve amount in the reserve list provides a balance credential sufficient for payment for a money transfer transaction that cannot be verified by the blockchain node based on repeated assignment of the same reserve amount. As more and more money transfer transactions are issued, less and less reserve money is available for allocation in the current reserve list in the user account. In order to avoid suspending sending of the remittance transaction when switching to prepare the new reserve money list, a threshold may be set for the amount of reserve money available for distribution in the existing reserve money list, where the threshold may be a total amount threshold of the amount of reserve money (i.e. a maximum remittance amount threshold that the amount of reserve money available for remaining is payable), or a number threshold of the amount of reserve money (i.e. a number threshold that the amount of reserve money available for remaining is maximum and is also available for sending of the remittance transaction), and when the user equipment dynamically monitors that the amount of reserve money available for distribution in the existing reserve money list is lower than the preset threshold, the process described in step a in the above embodiment is performed after switching the current reserve balance to the reserve balance. Optionally, the step of switching the current reserve balance to the reserve balance may be triggered by an instruction from the user.
The process of releasing, identifying and verifying the common knowledge of the node devices (including the customer premise equipment) of the blockchain, and updating the new reserve fund list in the state of the customer account usually requires a certain time, and the specific consumption time is related to the common knowledge mechanism, the block-out frequency, and the like of the blockchain. During this time, if the user has a need to send a new money transfer transaction, the money transfer transaction may still be constructed based on the amount of reserve available for allocation in the current reserve list, since the current reserve list in the user's account is still in effect. After the new reserve fund list is updated to the user account, the new reserve fund list can be used as the current reserve fund list in the user account, and the user can construct a remittance transaction based on the current reserve fund list and issue the remittance transaction to the blockchain; correspondingly, after the remittance transaction is verified by the node device in the blockchain, the remittance amount is deducted from the account balance and the switched reserve balance.
The money transfer method provided by the specification maximizes transaction throughput without suspending money transfer transactions because there is always a list of available reserve funds in the user's account.
In an illustrative embodiment, to resolve the reserve amount available for allocation in the reserve amount list, the use status of the reserve amount in the reserve amount list may be flagged. When a money transfer transaction including a reserve amount is validated by the node device in the blockchain and the money transfer transaction is recorded in the distributed database of the blockchain and the account balance of the remitter user of the money transfer transaction is updated, the reserve amount included in the money transfer transaction should be identified as used in the reserve list of the remitter account (state 3), as is well known to those skilled in the art, the money transfer transaction recorded in the distributed database of the blockchain may be referred to as a "completed money transfer transaction". For a new outstanding remittance transaction, the node devices in the blockchain may verify whether the reserve amount in the new outstanding remittance transaction is in use in the reserve list of the remitter user account: if in the used state, the verification fails and the corresponding new outstanding money transfer transaction may be returned; if not, the item verifies. Similarly, when the new money transfer transaction is validated and updated in the blockchain distributed database, the blockchain node should also update the reserve amount contained in the new money transfer transaction to "used status" in the reserve list of the remitter user account.
Preferably, the customer premise equipment may also mark the amount of the reserve money that has not been used, i.e., has not been allocated to any money transfer transaction, as unused in the reserve money list (state 1); once allocated for a money transfer transaction, a reserve amount may be identified in the reserve list of the user account as used (state 2), i.e., the reserve amount is identified in the current reserve list maintained at the user terminal as used (state 2). Thus, the customer premises equipment can only allocate the reserve amount in the unused state (state 1) for a new money transfer transaction and immediately change the allocated reserve amount locally to the used state (state 2) after allocation to prevent duplicate allocation of the same reserve amount.
In an illustrative embodiment, after the reserve fund list is obtained based on the current reserve fund balance, the reserve fund balance before switching is switched to the reserve balance.
After the user-side device obtains the reserve fund list according to the current reserve fund amount according to the process described in the above embodiment, at this time, since the new reserve fund list is already available as the current reserve fund list for the new money transfer transaction, the original reserve fund list may stop being used as the money transfer transaction, and accordingly, the original reserve fund balance may be switched to the standby balance to construct the new reserve fund list based on the current reserve balance when the reserve fund amount in the existing current reserve fund list is lower than the preset threshold or a new reserve fund list construction instruction is received.
Preferably, in order to optimally manage the balances in the user account, the backup balance described in the present specification may be used as a collection balance, and when the money transfer transaction initiated by another user to the user account is verified by the node device of the blockchain, the money transfer amount in the money transfer transaction is added to the collection balance and the account balance.
In order to protect the account privacy and safety of users in block chains, in some existing block chains, the account balance of the users and the transaction amount of remittance transactions are encrypted; the money transfer methods provided herein may also be used in a privacy mode blockchain.
In an illustrative embodiment, the account balance of the blockchain user account, the amount of the reserve money in the reserve list, and the amount of the money transfer in the money transfer transaction initiated by the user device are all pre-encrypted. Since the amount of money and the reserve amount of money included in the remittance transaction are encrypted, to ensure that the blocky point can verify that the reserve amount of money allocated to the remittance transaction is sufficient to pay the remittance, the remittance transaction should further include a first zero knowledge proof to prove that the sum of the reserve amounts of money included in the remittance transaction is greater than or equal to the amount of money of the remittance transaction.
Accordingly, since the account balance of the user account and the reserve money amounts obtained by the user based on the reserve money balance after switching are encrypted in advance, in order to ensure that the block link point can verify that the sum of the reserve money amounts included in the reserve money list creation transaction does not exceed the account balance of the user, the reserve money list creation transaction should further include a second zero-knowledge proof for proving that the sum of the reserve money amounts divided based on the reserve money balance after switching is less than or equal to the account balance of the user.
Zero-knowledge proof, generally refers to the ability of the prover (authenticatee) to convince the verifier that some assertion is correct without providing the verifier with any useful information. In this specification, the customer premise equipment may confirm whether the sum of the reserve amounts allocated for the remittance transaction is greater than or equal to the specific value of the remittance amount by providing the first zero-knowledge proof that the node (verifier) in the blockchain can believe that the sum of the specific values of the reserve amounts allocated for the remittance transaction is greater than or equal to the specific value of the remittance amount without knowing the remittance amount and the specific value of the reserve amount, that is, by performing zero-knowledge verification on the first zero-knowledge proof by the node (verifier) in the blockchain based on a zero-knowledge proof algorithm to confirm that the sum of the reserve amounts allocated for the remittance transaction is greater than or equal to the remittance amount. Similarly, the customer premise equipment may provide the second zero-knowledge proof, so that the node (verifier) in the block chain may trust whether the sum of the reserve amounts included in the reserve list creation transaction is not greater than the account balance of the customer account without knowing the account balance of the customer account and the actual value (plaintext) of the reserve amount included in the reserve list creation transaction.
In an illustrated embodiment, when the reserve balance and the spare balance in the user account are also displayed in the state of the user account, that is, other nodes on the blockchain may obtain the reserve balance and the spare balance of the user device by querying the state of the user account, in order to protect the privacy and the security of the user account, the reserve balance and the spare balance of the user account are also encrypted in advance, where the second zero-knowledge proof may be used to prove that the sum of the reserve amounts divided based on the switched reserve balance is less than or equal to the switched reserve balance. Since the reserve fund balance after the switching is obtained by dividing based on the account balance, and the reserve fund balance is necessarily smaller than the account balance, the second zero knowledge proof can also provide an effective proof that the sum of reserve fund amounts contained in the block link point verification reserve fund list creation transaction is not larger than the account balance.
The present specification does not limit the type of the cryptographic encryption algorithm, and may include an addition homomorphic encryption algorithm or a fully homomorphic encryption algorithm, and may further include a homomorphic Commitment algorithm (e.g., Pederson committee, etc.), as long as it is ensured that the encryption algorithm can satisfy the addition homomorphic and can support the zero knowledge proof that a plaintext data belongs to a certain interval, so that the encrypted remittance amount can be directly deducted from the account balance (or reserve balance) of the encrypted remittance user, and the encrypted remittance amount can be directly increased from the account balance of the encrypted recipient user.
For example, the above-described blockchain may support the Pedersen commit Commitment algorithm based on elliptic curves to ensure that the encrypted amount in the blockchain can be verified in the encrypted state for the range of amounts and that additive homomorphism can be achieved.
The present specification does not limit the specific types of the first zero-knowledge Proof and the second zero-knowledge Proof, and for example, a Range Proof (Range Proof) technique in the related art, such as the bulletprofs scheme or the zksnark universal zero-knowledge Proof technique, may be used.
In yet another illustrative embodiment, to prevent a user node in the blockchain from malicious attack on the blockchain, the money transfer transaction may further include a third zero knowledge proof to prove that the amount of money is greater than or equal to zero, and the third zero knowledge proof may be generated based on the encrypted amount of money, so that the node (verifier) in the blockchain can verify that the amount of money of the money transfer transaction is not less than zero without knowing the actual value (plaintext) of the amount of money.
In yet another illustrative embodiment, to prevent the user node in the blockchain from generating reserve money amounts that are invalid, a fourth zero knowledge proof that proves that each reserve money amount included in the reserve money list creation transaction is greater than or equal to zero may also be included in the reserve money list creation transaction, and the fourth zero knowledge proof may be generated based on the respective reserve money amounts, such that the node (verifier) in the blockchain may verify that each reserve money amount included in the reserve money list creation transaction is greater than or equal to zero without knowing the actual value (plaintext) of the respective reserve money amount.
In another embodiment of the present disclosure, the remittance transaction and the reserve list creation transaction may further include a digital signature made by the ue based on a private key of the user account for verifying the electronic signature by a node of the block chain, so as to prevent other nodes from falsifying as a remitter to issue the first transaction, issue an error message, and maliciously disturb the transaction order.
The remittance method based on the blockchain provided by the specification is characterized in that account balance of a user account is at least divided into reserve fund balance and standby balance, a reserve fund list containing a plurality of reserve fund amounts is constructed based on the reserve fund balance, and a payable certificate is provided for concurrent remittance transactions of the user account; when the available reserve fund amount in the reserve fund list is lower than a preset threshold value or a new reserve fund list building instruction is received, switching the reserve balance into a reserve fund month, and building a new reserve fund list containing a plurality of reserve fund amounts based on the switched reserve fund balance; after the new reserve fund list is validated by the blockchain node and updated to the user account, the user account then constructs a new money transfer transaction based on the new reserve fund list. During the process of switching the prepared fund list, the remittance transaction can still be constructed based on the original prepared fund list without pause; the process of switching the balance of the reserve money and creating the new reserve money list can be executed circularly along with the use condition of the current reserve money list (whether the amount of the reserve money available for distribution is lower than a preset threshold value) or the construction instruction of the new reserve money list which should be received, so that the transaction of sending remittance does not need to be suspended in the whole process, the concurrency of the transaction is improved, the transaction interruption is avoided, and the throughput of the blockchain transaction is maximized.
For ease of understanding, the technical solutions of the present specification will be described in detail below by taking a remittance transaction in a blockchain network as an example. Fig. 3 is a schematic diagram of a money transfer transaction and a reserve list transaction in a blockchain network, according to an exemplary embodiment. Assuming that the remitter device used by the user a is the user device 1, for example, a user account corresponding to the user a is logged in the user device 1; similarly, the receiver device used by user B is user device 2. The ue 1 may run a client program with a blockchain, so that the ue 1 has a corresponding blockchain link point in the blockchain network, such as the node 1 shown in fig. 2. Similarly, the ue 2 may run a client program with a blockchain, so that the ue 2 has a corresponding blockchain link point in the blockchain network, such as the node 2 shown in fig. 3. Other blockchain nodes, such as node i shown in fig. 3, also exist in the blockchain network. Through the node 1, the node 2, the node i and the like, remittance transactions between the user A and the user B and preparatory fund list creation transactions sent by the user A can be implemented through a blockchain network, relevant transaction information can be recorded into blockchain accounts respectively maintained by each blockchain link point, tampering can be avoided, and follow-up checking is facilitated.
For example, a block chain remittance is made by user a to user B. After registering an account, user a should first send a reserve fund list creation transaction to initialize the reserve fund list in his account. In this specification, a "user" may be represented as a logged-in user account, and the user account may actually belong to an individual or an organization, which is not limited in this specification.
As shown in fig. 5, in the above block chain, the account balance s _ a of the user a is divided into two sub-balances: s _ a _1 and s _ a _2, the account balance s _ B of user B is also divided into two sub-balances: s _ B _1 and s _ B _ 2. The account balance s _ a, sub-balances s _ a _1 and s _ a _2 of user a and the account balance s _ B, sub-balances s _ B _1 and s _ B _2 of user B are encrypted based on an encryption algorithm:
S_A=HE(s_A),S_A_1=HE(s_A_1),S_A_2=HE(s_A_2);
S_B=HE(s_B),S_B_1=HE(s_B_1),S_B_2=HE(s_B_2)。
in one embodiment, the encryption algorithm may be the Pederson Commitment homomorphic Commitment algorithm.
Initially, the sub-balance s _ a _1 is used as the reserve balance, s _ a _2 is used as the balance, the sub-balance s _ B _1 is used as the reserve balance, and s _ B _2 is used as the balance.
FIG. 4 illustrates user A setting a preparatory gold list MAAnd based on the prepared gold list MAA process of initiating a money transfer transaction. Setting a prepared gold list M for user AAComprises the following steps:
step 401, user A builds a reserve fund list MAThe above prepared gold list MAComprising a plurality of reserve money amounts M divided by the user A for the sub-balance s _ A _1 and encrypted by the homomorphic encryption algorithm HE based on the aboveA[1],MA[2],…,MA[LA]And will be listed above in the above prepared gold listThe reserve money amount MA[1],MA[2],…,MA[LA]Is marked as "unused state".
In specific implementation, the user a may divide the sub-balance s _ a _1 or a part of the sub-balance s _ a _1 to obtain the plaintext m of the above-mentioned multiple reserve amountsa[1],ma[2],…,ma[LA]And encrypting the multiple reserve money amounts based on the homomorphic encryption algorithm to obtain a reserve money amount ciphertext MA[1],MA[2],…,MA[LA](ii) a User A can also directly divide ciphertext S _ A _1 of sub-balance S _ A _1 to obtain MA[1],MA[2],…,MA[LA]And based on the homomorphic encryption algorithm, carrying out inverse operation to obtain the plaintext m corresponding to the reserved fund amount ciphertexta[1],ma[2],…,ma[LA]. User A can use the clear text m of the reserve money amounta[1],ma[2],…,ma[LA]And ciphertext MA[1],MA[2],…,MA[LA]The corresponding relationship is stored independently to facilitate user a in selecting the appropriate reserve amount in a particular money transfer transaction. Or, the user a may only store the plaintext of the reserve fund amount at the local user side, and the user side periodically synchronizes the account data from the blockchain, and may obtain the used reserve fund amount after decrypting the encrypted data acquired from the blockchain.
Step 402, user A generates zero knowledge proof PF [ s _ A _1 ≧ (m)a[1]+ma[2]+…+ma[LA])]For proving the above-mentioned preliminary gold list MAM in (1)A[1],MA[2],…,MA[LA]Corresponding reserve amount ma[1],ma[2],…,ma[LA]The sum is less than or equal to the sub-balance s _ A _1 of the user A, and the zero knowledge proves that PF [ s _ A _1 ] is more than or equal to (m)a[1]+ma[2]+…+ma[LA])]Amount m of reserve money not useda[1],ma[2],…,ma[L-A]And s _ A _1A value that makes the verifier believe ma[1],ma[2],…,ma[LA]The sum is less than or equal to s _ A _ 1. In one embodiment, the zero knowledge proof of PF [ s _ A _1 ≧ ma[1]+ma[2]+…+ma[LA])]General zero knowledge proof techniques such as zksnark or interval proof techniques such as Bulletprofo schemes can be used.
In step 403, user A generates a zero knowledge proof PF (m)a[i]Not less than 0) to prove the above-mentioned list of reserve gold MAM in (1)A[1],MA[2],…,MA[LA]Corresponding reserve amount ma[1],ma[2],…,ma[LA]Are not less than zero. The above zero knowledge proof PF (m)a[i]Not less than 0) without using reserve money ma[i]Can make the verifier believe ma[i]Is more than or equal to 0. In one embodiment, the zero knowledge proof PF (m) isa[i]Not less than 0) can use Borromean ring signature scheme or zksnark and other universal zero knowledge proof technical schemes and other interval proof techniques.
In step 404, user A bases on MA、PF[s_A_1≥(ma[1]+ma[2]+…+ma[L-A])]、PF(ma[i]Not less than 0) generating the digital signature Sign As。
In step 405, user A sends transaction T to the blockchainsTo determine the above-mentioned prepared gold list MAThe above transaction TsComprising MA、PF[s_A_1≥(ma[1]+ma[2]+…+ma[LA])]、PF(ma[i]Not less than 0), wherein 1<=i<L _ A, and SignAs。
In step 406, the node of the block chain receives the transaction Ts。
Step 407, the node of the block chain executes the transaction TsElectronic signature Sign A ofsAnd if the verification is passed, executing the next step.
Step 408, the nodes of the block chain prove that the algorithm is more than or equal to (m) for PF [ s _ A _1 ] based on zero knowledgea[1]+ma[2]+…+ma[LA])]Performing zero knowledge validation to confirmma[1],ma[2],…,ma[LA]Whether the sum is less than or equal to the sub-balance s _ A _1 of the user A; if so, the next step is performed.
409, the nodes of the block chain prove algorithm to PF (m) based on zero knowledgea[i]≧ 0) to confirm (m)a[i]Not less than 0, wherein 1<=i<L _ A, if yes, the next step is executed.
At step 410, the nodes of the blockchain will pass the verified transaction TsReceiving and recording the distributed database of the block chain and listing the prepared gold MAAnd updating the account status of the user A.
To this end, the node of the blockchain completes the prepared gold list M for user aAIs updated, as is well known to those skilled in the art, in setting up or updating the prepared gold list M for user aAMay also include many other verification steps, such as verification against replay, etc., which are not limited herein; moreover, the present specification does not limit the sequence of generating the certificates or the electronic signatures, nor the sequence of verifying the certificates or the electronic signatures in the transaction Ts proposed by the remitter by the nodes in the blockchain, and fig. 4 is only one embodiment of the method for setting the prepared fund list of the user provided by the present specification, and the present specification is not limited thereto. The setup process of the prepared fund list MB in the account of the user B is similar to the above-mentioned process of steps 401 to 410, and is not described herein again.
The blockchain in fig. 4 performs the process of user a transferring money to user B as follows:
step 411, the user A generates remittance amount ciphertext S based on the homomorphic encryption algorithmtHE (s _ t), where s _ t is the amount of money the user a transfers to the user B.
In step 412, user A prepares gold list MASelecting an unused plaintext mA[k]Cryptogram M of reserve amount sufficient for payment of remittance amount s _ tA[k]And the cryptograph M of the reserve money amountA[k]Marking as used, so that MA[k]Can no longer be assigned to other new sinksIn a money transaction.
In step 413, user A generates a zero knowledge proof Pf (m)A[k]≧ s _ t) for proving MA[k]Corresponding reserve amount mA[k]Enough to pay the amount of the money remittance s _ t; the above zero knowledge proof Pf (m)A[k]Not less than s _ t) without using mA[k]And s _ t, i.e., to make the verifier believe mA[k]≥s_t。
Step 414, the user A generates a zero knowledge proof Pf (s _ t is more than or equal to 0) for proving that the remittance amount s _ t is not less than zero; the zero knowledge proof Pf (s _ t ≧ 0) described above can make the verifier believe s _ t ≧ 0 without using the value of s _ t.
Step 415, user A bases St, MA[k]、Pf(mA[k]≧ s _ t), Pf (s _ t ≧ 0) generate digital signature SignAt。
User A sends 416 transaction T to the blockchaintTo transfer money to user B, transaction TtComprising St、MA[k]、Pf(mA[k]≧ s _ t), Pf (s _ t ≧ 0), and Sign AtThe above is in a ciphertext state, thereby protecting the privacy of the money transfer transaction of user A, B.
Step 417, the node of the block chain receives the transaction Tt。
In step 418, the nodes of the blockchain execute the transaction TtElectronic signature Sign A oftAnd if the verification is passed, executing the next step.
Step 419, the node of the blockchain verifies the above TtM contained inA[k]Whether it is in a used state; if not, the next step is executed.
In step 420, the nodes of the blockchain prove algorithm to PF (m) based on zero knowledgea[k]≧ s _ t) to validate MA[k]Whether the corresponding reserve amount is greater than or equal to the remittance amount; if so, the next step is performed.
Step 421, the node of the block chain performs zero knowledge verification on PF (S _ t is greater than or equal to 0) based on zero knowledge proof algorithm to confirm remittance amount ciphertext S of the remittance transactiontThe corresponding actual value of the money amount is not less than zero; if so, the mobile terminal can be started,the next step is performed.
At step 422, the node of the blockchain will pass the verified transaction TtRecording the account balance ciphertext S into the distributed database of the block chain, and deducting the remittance amount ciphertext S from the account balance ciphertext S _ A and the sub-account balance ciphertext S _ A _1 of the user A based on homomorphic operation propertytAdding the remittance amount ciphertext S in the account balance ciphertext S _ B and the sub-account balance ciphertext S _ B _2 of the user B based on homomorphic operation propertytUpdating the account balance of the user A to (s _ A-s _ t), the remittance sub-account balance of A to (s _ A _1-s _ t), the account balance of the user B to (s _ B + s _ t), and the remittance sub-account balance of B to (s _ B _2+ s _ t); and lists M the prepared gold of user AAMiddle MA[k]The corresponding state is changed to the used state.
In addition, as is well known to those skilled in the art, many other verification steps may be included in the actual implementation of the money transfer transaction, such as verification against replay, and the like, without limitation; in addition, the specification does not limit the sequence of generating each certificate or electronic signature, nor does the specification limit the transaction T proposed by the node pair sink-out party in the block chaintFig. 4 is merely one embodiment of the block chain based remittance method provided in this specification, and the specification is not limited thereto.
Although the use of consecutive numbers in fig. 4 indicates that user a initiated the setup of the reserve gold list and that user a remitted to user B, this does not indicate that user a needs to setup the reserve gold list in his account before each initiation of the remittance transaction. It is well known to those skilled in the art that users need to initially set up a list of funds reserved in their accounts prior to the first money transfer transaction after registering as a user of the blockchain; when the encrypted reserve amount in the reserve amount list is used up or the reserve amount corresponding to the remaining encrypted reserve amount is no longer sufficient to pay for the next remittance transaction, the user needs to reset the reserve amount list in the account; the user can also periodically update the prepared gold list according to the specific requirements of the user.
As the remittance transactions sent by user a increase, the reserve fund list MAThe amount of reserve money available in (1) is gradually reduced, and the device node of user a monitors the reserve money list MAThe sum of the values of the reserve money amounts available in (A) or a list M of monitored reserve moneyAWhen the sum of the above values or the sum of the numbers is lower than a set threshold value, the user A switches the sub-accounts s _ A _1 and s _ A _2 to each other, and generates a new reserve fund list M based on the new reserve fund balance s _ A _2A'. New preparatory gold list MAThe construction process of' is similar to that of step 401-410, and will not be described herein, MA' after being updated to the account of user A, the original reserve fund list M will be replacedATo provide payable proof as a new valid reserve list for the money transfer transaction.
Fig. 2 illustrates the process of creating and updating the reserve money list in the account of the user a, and it can be seen from fig. 2 that, through the cyclic switching of the balance of the sub-account, a valid reserve money list always exists in the account of the user a to provide a plurality of reserve money amounts for the concurrent money transfer transaction, so that the user a does not need to suspend the money transfer transaction to update the reserve money list, and the maximized concurrent submission and execution of the money transfer transaction are ensured. Moreover, in the remittance transaction method provided in this embodiment, since the two sub-account balances for remittance and for collection are set respectively, assuming that while user a performs remittance transaction to B, other user C is also initiating remittance transaction to user a, all of these transactions can be submitted and performed at the same time; because the zero knowledge utilized throughout the transaction is only relevant to the amount of reserve funds associated, the balance of the account may be increased or decreased as desired.
It is noted that as shown in FIG. 5, the subaccount balance S _ A _2 of user A is initially used as a cash collection transaction when the user device monitors the reserve fund list MAWhen the reserve fund amount is lower than a preset threshold value, the functions of the sub-account balance S _ A _1 and the sub-account balance S _ A _2 need to be switched, wherein S _ A _1 is used as the collection balance, and S _ A _2 is used as the reserve fund balance. The balance of S _ A _2 as reserve fund is used to execute new reserveBefore constructing the gold list, the user equipment needs to wait for a period of time until the transactions sent by other users to the sub-account balance S _ A _2 of the user A on the block chain before the switching are updated and displayed after the account balance S _ A and the sub-account balance S _ A _2 of the user A are displayed, and after the value of the sub-account balance S _ A _2 is not changed, a new prepared gold list is constructed based on S _ A _2, so that the PF [ S _ A _2 ] generated based on the value of S _ A _2 is not less than (m _ A _ 2) due to the change of the value of S _ A _2a[1]+ma[2]+…+ma[LA])]The verification of the blockchain node cannot be passed. The waiting time may depend on the blocking frequency of the block chain, for example, about 3-5 blocking times.
FIG. 6 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 6, at the hardware level, the apparatus includes a processor 602, an internal bus 604, a network interface 606, a memory 608 and a non-volatile memory 610, but may also include hardware required for other services. The processor 602 reads a corresponding computer program from the non-volatile memory 610 into the memory 608 and then runs the computer program to form a blockchain transaction 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. 7, the present specification further provides a block chain-based remittance apparatus 70, applied to a customer premise device of a block chain, wherein an account balance of a customer account is divided into at least a reserve balance and a spare balance; wherein the user account includes a dynamically updated reserve fund list; the reserve money list includes a plurality of reserve money amounts;
the device 70 comprises:
a reserve amount allocation unit 702 that allocates a corresponding reserve amount to the amount of money to be remitted by the user based on the current reserve list provided by the reserve list creation unit 704 in response to the remittance operation initiated by the user;
a remittance transaction construction and issuance unit 706 that constructs a remittance transaction based on the remittance amount and the allocated reserve amount and issues the remittance transaction to a blockchain to deduct the remittance amount from both the account balance and the reserve balance after the remittance transaction is verified by a node device in the blockchain;
wherein the preparatory gold list creation unit 704 includes:
a reserve fund list generating module 7042, configured to obtain a current reserve fund balance and obtain a reserve fund list according to the current reserve fund balance;
the reserve fund list monitoring module 7044 dynamically monitors whether the reserve fund amount available for allocation in the current reserve fund list is lower than a preset threshold.
In an illustrated embodiment, the preparatory gold list generation module 7042:
dividing the balance of the current reserve fund to obtain a plurality of reserve fund amounts, and constructing a reserve fund list to establish a transaction based on the plurality of reserve fund amounts obtained by dividing;
issuing the reserve fund list creation transaction to a blockchain to build a reserve fund list based on the plurality of reserve fund amounts obtained by the dividing at the user account after the reserve fund list creation transaction is verified by a node device in the blockchain.
In an illustrated embodiment, the preparatory gold list generation module 7042:
dividing the balance of the current reserve fund to obtain a plurality of reserve fund amounts, constructing a reserve fund list based on the plurality of reserve fund amounts obtained by dividing, and constructing a reserve fund list to establish a transaction based on the reserve fund list;
and issuing the reserve fund list creation transaction to the blockchain so as to update the reserve fund list to the user account after the reserve fund list creation transaction is verified by the node equipment in the blockchain.
In an illustrated embodiment, the apparatus 70 further comprises:
the switching unit 708 switches the reserve balance before switching to the reserve balance after obtaining the reserve list from the current reserve balance.
In an illustrated embodiment, the alternate balance is a collection balance; when other users initiate money transfer transactions of the user accounts and are verified by the node devices of the block chain, the money transfer amount in the money transfer transactions is increased to the collection balance and the account balance.
In an illustrated embodiment, the account balance of the user account, the reserve amount, and the remittance amount are all pre-encrypted;
the remittance transaction further comprises a first zero knowledge proof to prove that the sum of the reserve amounts included for the remittance transaction is greater than or equal to the remittance amount of the remittance transaction;
the reserve list creation transaction further includes a second zero knowledge proof to prove that a sum of reserve amounts divided based on the switched reserve balance is less than or equal to the user's account balance.
In an illustrative embodiment, the reserve balance and the reserve balance of the user account are pre-encrypted, and the second zero knowledge proves that the sum of the reserve amounts divided based on the switched reserve balance is less than or equal to the switched reserve balance.
In an illustrative embodiment, the money transfer transaction further includes a third zero proof of knowledge to demonstrate that the money transfer amount is greater than or equal to zero.
In an illustrated embodiment, the reserve fund list creation transaction further comprises a fourth zero knowledge proof to prove that the reserve fund amounts divided based on the switched reserve fund balances are all greater than or equal to zero.
The implementation processes of the functions and actions of each unit and module in the apparatus are specifically described in the implementation processes of the corresponding steps in the method, and related parts may be referred to part of the description of the method embodiment, which is not described herein again.
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.
Corresponding to the method embodiment, the embodiment of the present specification further provides a computer device, which includes a memory and a processor. Wherein the memory has stored thereon a computer program executable by the processor; the processor, when executing the stored computer program, performs the steps of the blockchain-based money transfer method of the embodiments of the present specification. For a detailed description of the steps of the blockchain-based money transfer method, reference is made to the preceding contents, which are not repeated.
In correspondence with the above method embodiments, embodiments of the present specification also provide a computer-readable storage medium having stored thereon computer programs, which, when executed by a processor, perform the steps of the blockchain-based money transfer method in the embodiments of the present specification. For a detailed description of the steps of the blockchain-based money transfer method, reference is made to the preceding contents, which are not repeated.
The above description is only a preferred embodiment of the present disclosure, and should not be taken as limiting the present disclosure, and any modifications, equivalents, improvements, etc. made within the spirit and principle of the present disclosure should be included in the scope of the present disclosure.
In a typical configuration, a computing device 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 tape magnetic disk storage 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.
As will be appreciated by one skilled in the art, embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer-usable program code embodied therein.