A blockchain-based reconciliation method, device, equipment and storage medium

Abstract

The present application proposes a reconciliation method, device, equipment and storage medium based on blockchain. Among them, the blockchain deploys a first smart contract for managing remittance business and a second smart contract for reconciliation. The method may include receiving any target remittance participant among multiple remittance participants related to the remittance business, and initiating a contract call transaction for the first smart contract. Among them, the call transaction includes confirmation information for the remittance information of the remittance business; in response to the call transaction, the first smart contract is called, the confirmation information is stored in the blockchain, and in response to the confirmation information of multiple remittance participants for the remittance information stored in the blockchain, the transaction status of the remittance business is updated to the transaction completion status; and, in response to the remittance business being in the transaction completion status, the reconciliation logic included in the second smart contract is called, and clearing and reconciliation is performed for multiple remittance participants based on the remittance information.

Description

Technical Field

[0001] The present application relates to computer technology, and in particular to a blockchain-based reconciliation method, apparatus, device and storage medium. Background Art

[0002] Remittance is a settlement method in which the payer pays the money to the payee through a payment institution using certain settlement tools (for example, remittance notes).

[0003] In the traditional remittance method, remittance can be completed between remittance institutions after the payee performs the remittance operation. This remittance method is not very secure, the remittance records are not convenient to save, the arrival time is long, and the remittance transaction status cannot be confirmed.

[0004] In addition, the participants in the remittance business (e.g., the receiving institution and the paying institution) need to reconcile accounts regularly (e.g., daily) based on the remittance amount. When reconciling accounts, the participants need to inquire about the amount of the remittance and then reconcile the accounts. This reconciliation method is not friendly to the participants. Summary of the invention

[0005] In view of this, the present application discloses a reconciliation method based on blockchain. The blockchain deploys a first smart contract for managing a remittance business; and a second smart contract associated with the first smart contract for reconciliation; the blockchain stores remittance information corresponding to the remittance business; and the first smart contract maintains a transaction status corresponding to the remittance business. The method may include: receiving a contract call transaction initiated by any target remittance participant among multiple remittance participants related to the remittance business for the first smart contract; wherein the contract call transaction includes confirmation information of the target remittance participant for the remittance information; in response to the contract call transaction, calling the state update logic included in the first smart contract, storing the confirmation information in the blockchain, and after the confirmation information is stored, determining whether the confirmation information of the multiple remittance participants for the remittance information is stored in the blockchain; if so, updating the transaction status to a transaction completion status; and, in response to the transaction status of the remittance business being a transaction completion status, further calling the reconciliation logic included in the second smart contract, and performing clearing and reconciliation corresponding to the remittance business for the multiple remittance participants based on the remittance amount in the remittance information.

[0006] In some embodiments, the method further includes: receiving a reconciliation statement query request initiated by any participant among the multiple remittance participants; in response to the reconciliation statement query request, sending the reconciliation statement corresponding to the participant maintained by the reconciliation contract to the participant, so that the participant performs reconciliation based on the reconciliation statement.

[0007] In some embodiments, the method further includes: receiving a block acquisition request initiated by any participant among the multiple remittance participants; the acquisition request includes time period information; in response to the block acquisition request, sending a block generated within the time period to the participant, so that the participant can determine whether the transaction status of the remittance business included in the block is a transaction completion status, and when the transaction status is a transaction completion status, update the reconciliation statement maintained by itself according to the remittance amount corresponding to the remittance business.

[0008] In some embodiments, the method also includes: in response to a status query request initiated by a first transaction subsystem corresponding to the remitter of the remittance business for the remittance business, sending the current transaction status of the remittance business to the first transaction subsystem, so that the first transaction subsystem determines whether the current transaction status is a transaction completion status, and performs a remittance operation to a second transaction subsystem corresponding to the payee when the current transaction status is a transaction completion status.

[0009] In some embodiments, the method also includes: in response to the first transaction subsystem determining that the current transaction status is a transaction completion status, freezing the funds corresponding to the remittance amount in the remitter account corresponding to the remittance party; before performing the remittance operation to the second transaction subsystem corresponding to the payee, it includes: unfreezing the funds corresponding to the remittance amount in the remitter account.

[0010] In some embodiments, the method also includes: receiving a creation request transaction initiated by the remittance party for a remittance business; in response to the creation request transaction, calling the initialization logic of the remittance transaction contract, creating a remittance business corresponding to the remittance party, and updating the transaction status corresponding to the remittance business to an initialization state; and / or, receiving a remittance information filling transaction initiated by the remittance party for the remittance business; the remittance information includes information of each participant participating in the remittance business; in response to the remittance information filling transaction, calling the filling logic of the remittance transaction contract, storing the remittance information in the storage space corresponding to the remittance business in the remittance transaction contract, and updating the transaction status to a state where the participant information is filled in.

[0011] In some embodiments, the method also includes: receiving a first query request initiated by a second transaction subsystem corresponding to the payee for the remittance business; in response to the first query request, sending the remittance information corresponding to the remittance business to the second transaction subsystem, so that the second transaction subsystem generates remittance confirmation information in response to the verification of the remittance information and stores it in the storage space to complete the preliminary verification of the remittance business.

[0012] In some embodiments, before sending the remittance information corresponding to the remittance business to the second transaction subsystem, it also includes: determining whether the second transaction subsystem corresponding to initiating the first query request is the second transaction subsystem indicated in the remittance information; if so, sending the remittance information corresponding to the remittance business to the second transaction subsystem.

[0013] In some embodiments, the method further includes: in response to completing the preliminary verification of the remittance business, updating the transaction status to a state where the remittance information is completed.

[0014] In some embodiments, the method also includes: receiving a second query request initiated by the remittance party for the remittance business; in response to the second query request, sending the remittance confirmation information corresponding to the remittance business to the remittance party, so that the remittance party generates a deduction request in response to the verification of the remittance confirmation information and stores the deduction request in the storage space.

[0015] In some embodiments, the method also includes: receiving a third query request initiated by the first transaction subsystem corresponding to the remitter for the remittance business; in response to the third query request, sending a deduction request corresponding to the remittance business to the first transaction subsystem, so that the first transaction subsystem responds to the verification of the deduction request, generates deduction request confirmation information and a funds remittance request and stores them in the storage space to complete the verification of the remittance business.

[0016] In some embodiments, the first transaction subsystem verifies the deduction request, including: the first transaction subsystem obtains remittance information and remittance confirmation information associated with the remittance business; performs a remittance verification on the remitter based on the remittance confirmation information, and performs an authenticity verification on the deduction request based on the remittance information and the remittance confirmation information.

[0017] In some embodiments, the remittance confirmation information includes the remittance account opened by the remitter in the first transaction subsystem and the remittance amount; the remittance verification of the remitter based on the remittance confirmation information includes: verifying whether the account balance of the remitter account in the remittance confirmation information reaches the remittance amount; if so, determining that the remittance verification of the remitter has passed; the authenticity verification of the deduction request based on the remittance information and the remittance confirmation information includes: identity authentication of a first digital signature included in the remittance information and a second digital signature included in the remittance confirmation information; if the identity corresponding to the first digital signature is the remitter and the identity corresponding to the second digital signature is the second transaction subsystem, determining that the authenticity verification of the deduction request has passed.

[0018] In some embodiments, the method also includes: receiving a fourth query request initiated by the second transaction subsystem for the remittance business; in response to the fourth query request, sending a fund remittance request corresponding to the remittance business to the second transaction subsystem, so that the second transaction subsystem responds to the verification of the fund remittance request, generates fund remittance confirmation information and stores it in the storage space to complete the secondary verification of the remittance business.

[0019] In some embodiments, the method further includes: in response to the fourth query request, sending a current transaction status corresponding to the remittance service to the second transaction subsystem, so that the second transaction subsystem verifies the current transaction status.

[0020] In some embodiments, the second transaction subsystem verifies the current transaction status, including: the second transaction subsystem determines whether the current transaction status is a state in which the remittance information is completed, and determines that the verification of the transaction status is passed when the current transaction status is a state in which the remittance information is completed; the second transaction subsystem verifies the fund remittance request, including: the second transaction subsystem obtains the remittance information, remittance confirmation information and deduction request associated with the remittance business; authenticates the first digital signature included in the remittance information, the second digital signature included in the remittance confirmation information, the third digital signature included in the deduction request, the fourth digital signature included in the deduction request and the fifth digital signature included in the fund remittance request; if the identity corresponding to the first digital signature and the third digital signature is the remitter, the identity corresponding to the second digital signature is the second transaction subsystem and the identity corresponding to the fourth digital signature and the fifth digital signature is the first transaction subsystem, it is determined that the verification of the fund remittance request is passed.

[0021] In some embodiments, the remittance operation to the second transaction subsystem corresponding to the payee includes: deducting funds corresponding to the remittance amount from the balance of the remitter's account opened by the remitter in the second transaction subsystem, and storing the corresponding deduction voucher in the blockchain after the deduction is successful; submitting a transfer request to the second transaction subsystem, wherein the transfer request includes a storage identifier corresponding to the deduction voucher, so that the second transaction subsystem obtains the deduction voucher stored in the blockchain according to the storage identifier, and authenticates the sixth digital signature included in the deduction voucher; if the identity of the sixth digital signature is the first transaction subsystem, the funds deducted from the remitter's account are received.

[0022] In some embodiments, the remittance service includes a cross-border remittance service; and / or, the remittance service includes a cross-border remittance service of the same currency.

[0023] In some embodiments, the multiple remittance participants include: a remittance party corresponding to the remittance business; a first transaction subsystem corresponding to the remittance party; and a second transaction subsystem corresponding to a payee designated by the remittance party.

[0024] The present application also discloses a reconciliation device based on blockchain, wherein the blockchain deploys a first smart contract for managing a remittance business; and a second smart contract associated with the first smart contract for reconciliation; the blockchain stores remittance information corresponding to the remittance business; and the first smart contract maintains a transaction status corresponding to the remittance business; the device comprises: a receiving module, receiving a contract call transaction initiated by any target remittance participant among multiple remittance participants related to the remittance business for the first smart contract; wherein the contract call transaction includes a request from the target remittance participant for the remittance information confirmation information; a calling module, in response to the contract calling transaction, calling the state update logic included in the first smart contract, storing the confirmation information in the blockchain, and after the confirmation information is stored, determining whether the confirmation information of the multiple remittance participants for the remittance information is stored in the blockchain; if so, updating the transaction status to a transaction completion status; and, in response to the transaction status of the remittance business being a transaction completion status, further calling the reconciliation logic included in the second smart contract, and based on the remittance amount in the remittance information, performing clearing and reconciliation corresponding to the remittance business for the multiple remittance participants.

[0025] The present application also discloses an electronic device, comprising: a processor; a memory for storing processor executable instructions; wherein the processor implements the reconciliation method as shown in any of the aforementioned embodiments by running the executable instructions.

[0026] The present application also discloses a computer-readable storage medium, wherein the storage medium stores a computer program, and the computer program is used to enable a processor to execute the reconciliation method as shown in any of the aforementioned embodiments.

[0027] In the scheme disclosed in the aforementioned embodiment, first, in response to a first smart contract call transaction initiated by any remittance participant, the state update logic included in the first smart contract can be called to store the confirmation information. The transparent and tamper-proof characteristics of the blockchain can be utilized to make the remittance information confirmation process traceable, thereby ensuring the traceability and reliability of the remittance business.

[0028] Second, after the confirmation information is stored, and when it is determined that the confirmation information of the multiple remittance participants regarding the remittance information is stored in the blockchain, the transaction status can be updated to the transaction completion status, so that the first smart contract can be used to maintain the remittance business transaction status, making it convenient for the remittance participants to confirm the current transaction status.

[0029] Third, in response to the transaction status of the remittance business being a transaction completion status, the reconciliation logic included in the second smart contract can be further called, and based on the remittance amount in the remittance information, the clearing and reconciliation corresponding to the remittance business can be performed for the multiple remittance participants, thereby utilizing the nesting between the first smart contract and the second smart contract, without the need for the participants to specifically maintain the reconciliation bill, and realizing automatic maintenance of the reconciliation bill.

[0030] It should be understood that both the general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] In order to more clearly illustrate the technical solutions in one or more embodiments of the present application or related technologies, the drawings required for use in the embodiments or related technology descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in one or more embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0032] Figure 1 A schematic diagram of creating a smart contract shown in this application;

[0033] Figure 2 A flowchart of a blockchain-based reconciliation method proposed in this application;

[0034] Figure 3 A cross-border remittance scenario diagram shown in this application;

[0035] Figure 4 An interactive flow chart of remittance information verification shown in this application;

[0036] Figure 5 A schematic diagram of a transaction status change shown in this application;

[0037] Figure 6 This is a schematic diagram of an interaction for verifying a fee deduction request shown in this application;

[0038] Figure 7 This is a schematic diagram of an interaction for verifying a fund remittance request shown in this application;

[0039] Figure 8A schematic diagram of a remittance operation method shown in this application;

[0040] Fig. 9 This is a schematic diagram of the structure of a blockchain-based account reconciliation device shown in this application;

[0041] Fig.10 A schematic diagram of the hardware structure of an electronic device shown in this application. DETAILED DESCRIPTION

[0042] The exemplary embodiments will be described in detail below, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are only examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

[0043] The terms used in this application are only for the purpose of describing specific embodiments and are not intended to limit this application. The singular forms of "a", "said" and "the" used in this application and the appended claims are also intended to include plural forms, unless the following clearly indicates other meanings. It should also be understood that the term "and / or" used in this article refers to and includes any or all possible combinations of one or more associated listed items. It should also be understood that the word "if" used in this article, depending on the context, can be interpreted as "at the time of" or "when" or "in response to determining".

[0044] Blockchain technology, also known as distributed ledger technology, is an emerging technology in which several computing devices jointly participate in "bookkeeping" and jointly maintain a complete distributed database. Blockchain technology has been widely used in many fields because of its decentralized, open and transparent characteristics, each computing device can participate in database records, and data can be quickly synchronized between computing devices.

[0045] Blockchain is generally divided into three types: public blockchain, private blockchain and consortium blockchain. In addition, there are many types of combinations, such as private blockchain + consortium blockchain, consortium blockchain + public blockchain and other different combinations. Among them, the public chain has the highest degree of decentralization. Public chains are represented by Bitcoin and Ethereum. Participants who join the public chain can read data records on the chain, participate in transactions, and compete for the right to record new blocks.

[0046] Moreover, each participant (i.e., node) can freely join and exit the network and perform related operations. On the contrary, the private chain has a network whose write permission is controlled by a certain organization or institution, and the data read permission is regulated by the organization. In simple terms, a private chain can be a weakly centralized system with strictly limited and few participating nodes. This type of blockchain is more suitable for internal use within a specific organization.

[0047] The consortium chain is a blockchain between the public chain and the private chain, which can achieve "partial decentralization". Each node in the consortium chain usually has a corresponding entity or organization; participants join the network through authorization and form a stakeholder alliance to jointly maintain the operation of the blockchain.

[0048] Whether it is a public chain, a private chain or a consortium chain, it may provide the function of smart contracts. Smart contracts on the blockchain are contracts that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code.

[0049] Taking Ethereum as an example, supporting users to create and call some complex logic in the Ethereum network is the biggest challenge that distinguishes Ethereum from Bitcoin blockchain technology. The core of Ethereum as a programmable blockchain is the Ethereum Virtual Machine (EVM), and each Ethereum node can run EVM. EVM is a Turing-complete virtual machine, which means that various complex logics can be implemented through it. Users publish and call smart contracts in Ethereum on EVM. In fact, the virtual machine directly runs the virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). Smart contracts deployed on the blockchain can be in the form of bytecode.

[0050] For example Figure 1 As shown in the figure, after Bob sends a transaction containing information about creating a smart contract to the Ethereum network, the EVM of node 1 can execute the transaction and generate the corresponding contract instance. Figure 1 The "0x68e12cf284..." in the transaction represents the address of this contract. The data field of the transaction can store bytecodes, and the to field of the transaction is an empty account. After the nodes reach an agreement through the consensus mechanism, the contract is successfully created and subsequent users can call this contract.

[0051] After the contract is created, a contract account corresponding to the smart contract appears on the blockchain with a specific address. The contract code and account storage will be saved in the contract account. The behavior of the smart contract is controlled by the contract code, while the smart contract account storage saves the state of the contract. In other words, the smart contract generates a virtual account on the blockchain that contains the contract code and account storage.

[0052] As mentioned above, the data field of the transaction that creates a smart contract can store the bytecode of the smart contract. The bytecode consists of a series of bytes, each of which can identify an operation. Based on development efficiency, readability and other considerations, developers can choose a high-level language to write smart contract code instead of writing bytecode directly. For example, high-level languages ​​such as SolIDity, Serpent, and LLL languages ​​can be used. For smart contract codes written in high-level languages, they can be compiled by a compiler to generate bytecode that can be deployed on the blockchain.

[0053] Taking the Solidity language as an example, the contracts written in it are very similar to classes in object-oriented programming languages. Multiple members can be declared in a contract, including state variables, functions, function modifiers, events, etc. State variables are values ​​permanently stored in the account storage of the smart contract, which are used to save the state of the contract.

[0054] This application aims to propose a blockchain-based reconciliation method. On the one hand, the method uses smart contracts to supervise and promote remittance business and maintain transaction status, making the remittance process and transaction status traceable; on the other hand, the method can achieve automatic maintenance of reconciliation bills through the nesting of the first smart contract and the second smart contract.

[0055] In some embodiments, the reconciliation method can be applied to a remittance business system built on blockchain.

[0056] The remittance business system (hereinafter referred to as the business system) can be a system developed by the operator providing remittance services according to demand. The blockchain may include a number of node devices for performing consensus operations. The system may include a first transaction subsystem corresponding to the remitter (hereinafter referred to as the first system), and a second transaction subsystem corresponding to the payee (hereinafter referred to as the second system). The remittance business system can provide services for the first system, the second system, and the remitter (such as the remitter client) to complete the remittance.

[0057] In some embodiments, the remittance service may be a cross-border remittance service. The first system and the second system may be cross-border transaction systems. The remittance may include a cross-border remittance in the same currency, i.e., no currency conversion is involved.

[0058] The first system may be a system developed by a remittance institution corresponding to the remitter.

[0059] The remitter may be a user with a remittance demand. The remitter may interact with the first system, the second system or the business system through its corresponding client. The remitter may register in the blockchain in advance. After completing the registration, the remitter may receive a public-private key pair assigned to it by the blockchain. The remitter may broadcast the public key it holds in the blockchain, or may use the private key it holds to perform a digital signature.

[0060] The first system may be an institutional system such as a bank that conducts fund transaction business. It is understandable that the remitter may open a remitter account in the first system for storing the assets held by the remitter. The first system may be pre-registered in the blockchain. After completing the registration, the first system may receive a public-private key pair assigned to it by the blockchain. The first system may broadcast the public key it holds in the blockchain, or may use the private key it holds to perform digital signature.

[0061] The second system may be a system developed by a payment collection institution corresponding to the payment recipient.

[0062] The second system may be an institutional system such as a bank that performs payment collection business. It is understandable that the payee may open a payee account in the second system for storing the assets held by the payee. The second system may be pre-registered in the blockchain. After completing the registration, the second system may receive a public-private key pair assigned to it by the blockchain. The second system may broadcast the public key it holds in the blockchain, or may use the private key it holds to perform digital signature.

[0063] It is understandable that the roles of the first system and the second system can be interchangeable. For example, when the payee performs a remittance service, the second system can be the system performing the remittance service, and the first system can be the system performing the collection service.

[0064] In the present application, the parties involved in the remittance business may include the remitter, the first system (remittance institution), and the second system (receiving institution). In some embodiments, the parties may also include transaction regulators, recipients, and the like.

[0065] The blockchain may deploy a first smart contract for managing a remittance business; and a second smart contract associated with the first smart contract for reconciliation; the blockchain stores remittance information corresponding to the remittance business; and the first smart contract maintains a transaction status corresponding to the remittance business.

[0066] The first smart contract (hereinafter referred to as the remittance contract) may be a smart contract pre-deployed on the blockchain by the remittance service operator according to business needs. The contract may include a remittance logic for responding to a remittance request initiated by the remitter, enabling each participant in the remittance business to verify the remittance business, and responding to each participant verifying that the remittance operation is executed, and further calling the reconciliation logic of the second smart contract to update the reconciliation bill between each participant according to the amount represented by the remittance business.

[0067] The remittance logic may include initialization logic, evidence storage logic and call logic.

[0068] The initialization logic can be used to respond to a remittance service creation request initiated by the remitter, create a remittance service for the remitter, and allocate associated storage space for the remittance service in the contract account of the smart contract to store business information associated with the remittance service. For example, the business information may include account information of the participants in the remittance service, the remittance amount, remittance request information and verification information initiated by each participant for the remittance service, etc.

[0069] The evidence storage logic can be used to store business information related to the remittance business to promote the remittance business. For example, when the remitter deposits the remittance information to the smart contract, the second system can be further notified to verify the remittance information, thereby promoting the remittance business. For another example, when the remitter deposits the deduction request to the smart contract, the first system can be notified to verify the deduction request, thereby promoting the remittance business. It can be understood that when promoting the remittance business, in one way shown, the smart contract can publish a notification message to the blockchain when it detects that the remittance business needs to be promoted, so that the party receiving the notification message can obtain the notification message by monitoring or other methods. In another way shown, the remittance contract can return the ID corresponding to the remittance business and the contract account address and other information to the participant who calls the contract, and then the participant pushes the contract account address information and the remittance business ID information to the next participant through methods such as message push to complete the remittance business promotion.

[0070] The calling logic can be used to respond to the completion of the remittance and further call the second smart contract to complete the update of the reconciliation bill between the participants, thereby realizing automatic reconciliation.

[0071] In some embodiments, the remittance contract can maintain the transaction status corresponding to the remittance business. The transaction status may include a status identifier that characterizes the current transaction status of the remittance business. At this time, the remittance contract may also include a state update logic for switching the status identifier to a status identifier corresponding to the preset condition met in response to satisfying the preset condition. For example, the switching logic may include a corresponding relationship between several preset conditions and the status identifier. One of the preset conditions may call initialization logic for the remitter, and the status identifier may be switched to an identifier that characterizes the initialization state (for example, the number 0 identifies the initialization state) in response to satisfying the condition. In this example, each participant can determine the transaction status corresponding to the current remittance business by querying the status identifier of the remittance business, thereby facilitating the participants to understand the transaction status of the remittance business.

[0072] In some embodiments, the remittance contract may also include query logic for responding to a query request initiated by a participant, querying the business information or transaction status corresponding to the remittance business in the contract account and sending the queried information to the participant through a blockchain node device.

[0073] The second smart contract (hereinafter referred to as the reconciliation contract) can be developed by the operator and pre-deployed in the blockchain. The reconciliation contract may include reconciliation logic for updating the reconciliation statements between the participants according to the amount represented by the remittance business. In some embodiments, the reconciliation contract can be nested in the remittance contract in the form of a subroutine. When the remittance contract detects that all participants have completed verification, the reconciliation contract can be further called through a CALL instruction or the like to complete the reconciliation.

[0074] See also Figure 2 , Figure 2 A flowchart of a blockchain-based reconciliation method proposed in this application.

[0075] like Figure 2 As shown, the reconciliation method may include:

[0076] S202, receiving a contract call transaction initiated by any target remittance participant among multiple remittance participants related to the remittance business for the first smart contract; wherein the contract call transaction includes confirmation information of the target remittance participant for the remittance information.

[0077] The target remittance participant may be any one of a plurality of remittance participants. For example, the target remittance participant may be any one of the remitter, the first system and the second system.

[0078] Any remittance participant in the remittance business needs to confirm the remittance information stored in the blockchain. Only when all participants have confirmed the remittance information can the remittance be allowed. After any participant has confirmed the remittance information, it can send the contract call transaction to the business system through its corresponding remittance client. Among them, the transaction can include confirmation information for the remittance information.

[0079] S204, in response to the contract call transaction, calling the state update logic included in the first smart contract, storing the confirmation information in the blockchain, and after the confirmation information is stored, determining whether the confirmation information of the multiple remittance participants for the remittance information is stored in the blockchain; if so, updating the transaction status to a transaction completion status; and,

[0080] In response to the transaction status of the remittance business being a transaction completion status, the reconciliation logic included in the second smart contract is further called to perform clearing and reconciliation corresponding to the remittance business for the multiple remittance participants based on the remittance amount in the remittance information.

[0081] In some embodiments, the business system may first call the evidence logic in response to the contract call transaction to store the confirmation information in the blockchain. Then the state update logic may be further called to determine whether the blockchain has stored confirmation information including signature information corresponding to each of the multiple remittance participants. If the aforementioned confirmation information is stored in the blockchain. It can be determined that each participant has completed the confirmation of the remittance information and the remittance business can be executed. Among them, the remittance business can be executed on the blockchain or outside the blockchain. Regardless of whether the remittance business is executed off-chain or on-chain, the system can update the current transaction status to the transaction completion status through the state update logic.

[0082] In some embodiments, the state update logic may have call logic embedded therein. The business system may determine whether the current transaction state is a transaction completion state through the state update logic, and if so, may call the reconciliation logic included in the reconciliation contract through the call logic.

[0083] The business system can perform clearing and reconciliation corresponding to the remittance business for the multiple remittance participants based on the remittance amount in the remittance information through the reconciliation logic.

[0084] In some embodiments, the contract account of the reconciliation contract maintains reconciliation statements between different participants. For example, a reconciliation statement between two banking institutions participating in a remittance business can be maintained. When a remittance business is completed between the two banking institutions, the reconciliation contract can update the reconciliation statement according to the remittance amount represented by the remittance business (i.e., the remittance amount represented by the remittance information), thereby eliminating the need for the two banking institutions to participate in the bill maintenance, freeing up banking institutions and providing convenience for bank reconciliation.

[0085] In some embodiments, when any participant has a need to query a reconciliation bill, a reconciliation bill query request may be initiated to the business system. The business system may receive a reconciliation bill query request initiated by any participant; and in response to the reconciliation bill query request, send the reconciliation bill corresponding to the participant maintained by the second smart contract to the participant, so that the participant can reconcile based on the reconciliation bill.

[0086] In some of the illustrated methods, the reconciliation bill query request may include the identification of the participant initiating the request (e.g., identity ID). The business system may query the reconciliation bill corresponding to the participant maintained by the contract account of the reconciliation contract through the blockchain node device according to the identification of the participant. Then, the business system may send the queried reconciliation bill to the participant so that the participant can reconcile based on the bill. This allows the participant to easily obtain the reconciliation bill and complete the reconciliation.

[0087] In some of the methods shown, the business system can respond to the reconciliation bill query request and construct a reconciliation contract call transaction to call the query logic of the reconciliation contract, retrieve the reconciliation bill corresponding to the participant identifier from the contract account of the reconciliation contract, and publish the bill to the blockchain so that the participant can obtain the reconciliation bill through methods such as monitoring, thereby completing the reconciliation.

[0088] In the scheme, first, in response to a first smart contract call transaction initiated by any remittance participant, the state update logic included in the first smart contract can be called to store the confirmation information. The transparent and tamper-proof characteristics of the blockchain can be utilized to make the remittance information confirmation process traceable, thereby ensuring the traceability and reliability of the remittance business.

[0089] Second, after the confirmation information is stored, and when it is determined that the confirmation information of the multiple remittance participants regarding the remittance information is stored in the blockchain, the transaction status can be updated to the transaction completion status, so that the first smart contract can be used to maintain the remittance business transaction status, making it convenient for the remittance participants to confirm the current transaction status.

[0090] Third, in response to the transaction status of the remittance business being a transaction completion status, the reconciliation logic included in the second smart contract can be further called, and based on the remittance amount in the remittance information, the clearing and reconciliation corresponding to the remittance business can be performed for the multiple remittance participants, thereby utilizing the nesting between the first smart contract and the second smart contract, without the need for the participants to specifically maintain the reconciliation bill, and realizing automatic maintenance of the reconciliation bill.

[0091] In some embodiments, the correspondence between the status identifier and the transaction status may be preconfigured in the remittance contract, so that different status identifiers may be set according to different transaction statuses.

[0092] In some embodiments, when the first system needs to transfer remittance to the second system, a transaction status query request for the remittance business can be sent to the business system. The business system can respond to the status query request and send the current transaction status of the remittance business to the first system, so that the first system determines whether the current transaction status is a transaction completion status, and performs a remittance operation on the second system corresponding to the payee when the current transaction status is a transaction completion status.

[0093] In some embodiments, the business system may check the transaction status corresponding to the remittance business ID to be remitted, and then may send the transaction status to the first system to complete the subsequent remittance operation.

[0094] In some embodiments, the business system may construct a status query transaction, call the query logic included in the remittance contract, and obtain the transaction status of the remittance business to be remitted from the contract account of the contract. The business system may then send the transaction status to the first system to complete the subsequent remittance operation.

[0095] In this way, the transaction system can determine whether to perform a remittance operation based on the transaction status corresponding to the remittance business, thereby simplifying the process of the first system confirming the remittance business and further improving the remittance efficiency.

[0096] In some embodiments, each participant can also maintain a reconciliation statement by pulling blocks. The business system can receive a block acquisition request initiated by any participant. The acquisition request includes time period information. Then, the business system can respond to the block acquisition request and send the block generated within the time period to the participant, so that the participant can determine whether the transaction status of the remittance business included in the block is a transaction completion state, and when the transaction status is a transaction completion state, update the reconciliation statement maintained by itself according to the remittance amount corresponding to the remittance business.

[0097] The time period information may be a time interval consisting of a start time and an end time. In some embodiments, the start time may be the time when the block acquisition request was last sent, and the end time may be the time when the block acquisition request is currently sent.

[0098] In some embodiments, each participant can obtain the blocks of evidence from the blockchain chain by locally deploying SDK (Software Development Kit) or message subscription. For example, the first system corresponding to the remitter can send block acquisition requests to the business system regularly through SDK to obtain the newly generated blocks between two block acquisition requests. Then the first system can perform a preliminary screening of the blocks to obtain the blocks published for the remittance agreement. After that, it is determined whether the transaction status of the remittance business in the acquired block is the transaction completion status, and the remittance amount represented by the remittance business in the transaction completion status is updated according to the self-maintained reconciliation statement.

[0099] In some embodiments, a participant may maintain reconciliation statements for different other participants respectively. When updating the reconciliation statement, the corresponding reconciliation statement may be updated according to other participants represented by the remittance business.

[0100] Therefore, each participant can not only obtain the reconciliation statement by querying the reconciliation contract, but also maintain the reconciliation statement according to the remittance business with the transaction completion status, so that the statement maintained by the contract can be checked with the statement maintained by itself to ensure the reliability of the reconciliation process.

[0101] The following describes an embodiment in conjunction with a specific cross-border remittance scenario.

[0102] In the field of cross-border remittance, cross-border remittance is usually carried out through the SWIFT (Society Worldwide Interbank Financial Telecommunication) system. However, cross-border remittance using the SWIFT system has problems such as long arrival time and high handling fees.

[0103] Currently, Money Transfer also provides hourly cross-border remittance solutions through Money Transfer, but this requires the use of a system developed by Money Transfer, which carries a high risk. Remittance institutions generally do not trust the cross-border remittance services provided by Money Transfer.

[0104] See also Figure 3 , Figure 3 A cross-border remittance scenario diagram shown in this application.

[0105] Figure 3The remittance business system shown is a cross-border business system (hereinafter referred to as the business system) built on blockchain. The business system may include a blockchain network (hereinafter referred to as blockchain), a client corresponding to the remitter A (hereinafter referred to as the remitter A), a first system B, and a second system C.

[0106] The blockchain may include node devices corresponding to the remitter A, the first system B, and the second system C.

[0107] The blockchain may include a business service end (e.g., a BaaS (Backend as a Service) platform). The business service end may serve as a platform for external interaction of the blockchain, and may interact with remitter A, the first system B, and the second system C. For example, the business service end may receive a remittance service creation request initiated by remitter A, and initiate a remittance contract call transaction to the blockchain to complete the creation and initialization of the remittance service. For another example, the business service end may obtain from the blockchain a receipt of evidence returned by the blockchain to remitter A, and send the receipt to remitter A.

[0108] The remitter A is a user who has a remittance demand. The remitter registers on the blockchain and obtains a public and private key pair assigned by the blockchain.

[0109] The first system B may be the first system corresponding to the remitter A. The remitter A may open a remitter account in the first system.

[0110] The second system C may be the second system corresponding to the payee. The payee may open a payee account in the first system.

[0111] The remitter A, the first system B (hereinafter referred to as system B), and the second system C (hereinafter referred to as system C) can register in the blockchain and obtain the public and private key pairs assigned by the blockchain. The public key can be broadcast to each node included in the business system; the private key can be used for signing.

[0112] In some embodiments, cross-border remittances may include four verification processes, specifically including: remittance information verification between the remitter and system C; deduction request verification between the remitter and system B; fund remittance request verification between system B and system C; and, completion of the remittance operation between system B and system C.

[0113] In some embodiments, the remitter A can verify the remittance information with the system C. Figure 4 , Figure 4 This is an interactive flow chart of remittance information verification shown in this application. Figure 4 System B is not shown.

[0114] like Figure 4 As shown, when the remitter A has a remittance service demand, S41 can be executed to send a remittance service creation transaction to the blockchain for the remittance service. The blockchain can execute S42 to receive a creation request transaction initiated by the remitter for the remittance service. Then, in response to the creation request transaction, the initialization logic of the first smart contract is called to create a remittance service corresponding to the remitter, and the transaction status corresponding to the remittance service is updated to the initialization state.

[0115] In some embodiments, during the initialization process, the remittance contract can assign a unique ID to the remittance business, and allocate a storage space for the remittance business to store information related to the remittance business, such as a status identifier (in this case, an initialization status identifier), remittance information, etc.

[0116] See also Figure 5 , Figure 5 A schematic diagram of a transaction status change shown in this application.

[0117] like Figure 5 As shown, when the remitter triggers the remittance contract initialization logic, the remittance contract can switch the remittance business transaction state to the initialization state through the state update logic.

[0118] Afterwards, the remitter may generate (fill in) remittance information according to the remittance demand. The remittance information may represent the remittance amount.

[0119] The payee A can execute S43 to send the remittance information to the blockchain to fill in the transaction. In addition to the remittance amount, the remittance information can also include information about each participant in the remittance business. The participant information can include the system ID and public key information of the first system and the second system participating in the remittance business, as well as the account information opened by the payee and the remitter. It can be understood that the payee A can use the private key it holds to sign the remittance information and obtain the remittance information including the first digital signature.

[0120] The blockchain can execute S44, receive the remittance information filling transaction, and in response to the remittance information filling transaction, call the filling logic of the first smart contract, store the remittance information in the storage space corresponding to the remittance business in the first smart contract, and update the transaction status to the state where the participant information is filled in.

[0121] like Figure 5 As shown, illustratively, when the remitter completes filling in the remittance information, the remittance business status can be switched to a state where the participant information is completed.

[0122] Afterwards, the remitter may send the ID of the remittance service and the account address of the remittance contract to the system C. The system C may execute S45 according to the received ID and contract account address information, and initiate a first query request to the blockchain.

[0123] The blockchain can execute S46, and in response to the first query request, send the remittance information corresponding to the remittance business to the second system, so that the second system generates remittance confirmation information in response to the verification of the remittance information and stores it in the storage space to complete the preliminary verification of the remittance business.

[0124] In some embodiments, after obtaining the remittance information, the system C can use the corresponding public key of the remitter A to authenticate the digital signature included in the remittance information. If the verification is successful, it means that the digital signature is the remitter A, that is, the authenticity of the remittance information can be explained. Then, the system C can modify the remittance information according to other business rules such as deducting handling fees to generate remittance confirmation information. It is understandable that the remittance confirmation information can represent the handling fees that need to be deducted, and the amount actually received by the payee after deducting necessary expenses such as handling fees.

[0125] After generating the remittance confirmation information, the system C may execute S47 to store the remittance confirmation information in the blockchain by calling the evidence storage logic of the remittance contract. It is understandable that the system C may digitally sign the remittance confirmation information according to the private key held by it to obtain the remittance confirmation information including the second digital signature.

[0126] In some embodiments, in order to improve the credibility of the remittance process, before sending the remittance information corresponding to the remittance business to the second system, it can also be determined whether the second system corresponding to the initiator of the first query request is the second system indicated in the remittance information; if so, the remittance information corresponding to the remittance business is sent to the second system.

[0127] In some embodiments, the first query request can be authenticated by the public key of system C indicated by the remittance information stored by the remitter A. If the authentication is successful, it can be determined that the second system corresponding to the initiation of the first query request is the second system indicated in the remittance information.

[0128] In some embodiments, Figure 5 As shown, after system C passes the preliminary verification of the remittance information, the state update logic of the remittance contract can be called to update the transaction status to the state where the remittance information is completed.

[0129] In some embodiments, after system C completes the deposit of remittance confirmation information, it may notify remitter A.

[0130] The remitter A may execute S48 to send a second query request for the remittance business to the blockchain.

[0131] The blockchain can execute S49, receive the second query request, and in response to the second query request, send the remittance confirmation information corresponding to the remittance business to the remitter, so that the remitter generates a deduction request in response to the verification of the remittance confirmation information and stores the deduction request in the storage space.

[0132] In some embodiments, the remitter A may confirm the handling fee to be deducted and the amount actually received by the payee represented by the remittance confirmation information. If the confirmation is correct, the verification process for the remittance information is completed.

[0133] In the verification process, the remittance interaction information (including remittance information and remittance confirmation message) between the remitter A and the system C can be stored in the blockchain through the remittance contract, and the tamper-proof nature of the blockchain can be used to ensure the credibility of the remittance process.

[0134] In some embodiments, after completing the remittance information verification, the remitter A and the system B may verify the deduction request.

[0135] See also Figure 6 , Figure 6 An interactive diagram of a fee deduction request verification shown in this application. Figure 6 System C is not shown.

[0136] In some embodiments, the remitter A may execute S61, generate a deduction request according to the remittance confirmation information, and then deposit the deduction request in the storage space allocated for the remittance business by calling the evidence storage logic of the remittance contract. It is understandable that the remitter A may digitally sign the deduction request using the private key corresponding to the remitter A to obtain a deduction request including a third digital signature.

[0137] Afterwards, the remitter A may send the ID of the remittance business and the account address of the remittance contract to the system B. The system B may execute S62 according to the ID and the account address, and send a third query request to the blockchain for the remittance business.

[0138] The blockchain can execute S63, receive a third query request initiated by the first system corresponding to the remitter for the remittance business, and in response to the third query request, send a deduction request corresponding to the remittance business to the first system, so that the first system responds to the verification of the deduction request, generates a fund remittance request and stores it in the storage space to complete the verification of the remittance business.

[0139] In some embodiments, the third query request may query the remittance information stored by the remitter and the remittance confirmation information stored by system C. After obtaining the information, the system B may execute S64 to perform a remittance verification on the remitter based on the remittance confirmation information, and perform an authenticity verification on the deduction request based on the remittance information and the remittance confirmation information.

[0140] In some embodiments, the remittance confirmation information includes the remitter A account opened by the remitter A in the system B and the remittance amount. When performing remittance verification on the remitter A based on the remittance confirmation information, it can be verified whether the account balance of the remitter A account in the remittance information reaches the remittance amount; if so, it is determined that the remittance verification of the remitter A passes.

[0141] In some embodiments, the first digital signature included in the remittance information and the second digital signature included in the remittance confirmation information can be authenticated. For example, the first digital signature can be verified using the public key corresponding to the remitter A, and if the verification is successful, the identity of the first digital signature is determined to be the remitter A. Similarly, the second digital signature can be verified using the public key of system C.

[0142] If the identity corresponding to the first digital signature is the remitter A and the identity corresponding to the second digital signature is the system C, it is determined that the verification of the deduction request is successful.

[0143] If both verifications are successful, it can be confirmed that the verification of the deduction request is successful. It should be noted that the order of the two verifications is not limited in this application.

[0144] Afterwards, the system B may execute S65, and in response to the verification being passed, generate deduction request confirmation information based on the deduction request, and store the deduction request confirmation information in the storage space by calling the evidence storage logic of the remittance contract, thereby completing the confirmation process for the deduction request. It is understandable that the system B may digitally sign the deduction request using the private key it holds, and obtain the deduction request confirmation information including the fourth digital signature.

[0145] During the verification process of the deduction request, the remittance interaction information (including the deduction request and the deduction request confirmation information) between the remitter A and the system B is stored in the blockchain through the remittance contract. The tamper-proof nature of the blockchain can ensure the credibility of the remittance process.

[0146] In some embodiments, after completing the deduction request verification, system B and system C may perform a funds remittance request verification.

[0147] See also Figure 7 , Figure 7 This is a schematic diagram of an interaction for verifying a funds transfer request shown in this application. Figure 7 Remitter A is not shown.

[0148] After completing the verification of the deduction request, the system B may execute S71 to generate a fund remittance request according to the deduction request, and store the fund remittance request in the storage space. It is understandable that the system B may digitally sign the fund remittance request using the private key it holds, and obtain the fund remittance request including the fifth digital signature.

[0149] In some embodiments, in response to the remittance service verification being passed by the system B, the funds corresponding to the remittance amount in the remitter's account corresponding to the remitter may be frozen, thereby ensuring that there is sufficient amount in the remitter's account to complete the remittance.

[0150] In some embodiments, after completing the deposit of the funds remittance request, the system B may notify the system C. The system C may execute S72 to initiate a fourth query request to the blockchain for the remittance business.

[0151] The blockchain can execute S73, receive the fourth query request, and in response to the fourth query request, send the fund remittance request corresponding to the remittance business to the second system, so that the second system responds to the verification of the fund remittance request, generates fund remittance confirmation information and stores it in the storage space to complete the secondary verification of the remittance business.

[0152] In some embodiments, the fourth query request may include querying the current transaction status of the remittance business, the remittance information and deduction request stored by the remitter, the deduction request confirmation information stored by system B, and the remittance confirmation information stored by system C.

[0153] After obtaining the information, the system C may execute S74 to verify the current transaction status. In some embodiments, the second system determines whether the current transaction status is a state where the remittance information is filled in, and when the current transaction status is a state where the remittance information is filled in, it is determined that the transaction status has been verified.

[0154] On the other hand, the request for funds to be remitted can be verified. In some embodiments, the system C

[0155] The first digital signature included in the remittance information, the second digital signature included in the remittance confirmation information, the third digital signature included in the deduction request, the fourth digital signature included in the deduction request, and the fifth digital signature included in the funds remittance request can be authenticated. If the identity corresponding to the first digital signature and the third digital signature is the remitter, the identity corresponding to the second digital signature is the second system, and the identity corresponding to the fourth digital signature and the fifth digital signature is the first system, it is determined that the verification of the funds remittance request is passed.

[0156] In some embodiments, if both verifications are passed, the system C may execute S75, generate funds remittance confirmation information and store it in the storage space to complete the secondary verification of the remittance business. It is logical that the system C may digitally sign the funds remittance confirmation information using the private key it holds, and obtain the funds remittance confirmation information including the sixth digital signature.

[0157] In some embodiments, Figure 5 As shown, all parties currently involved in the remittance business have completed the verification of the remittance business, and the storage space has also stored all the verification information. At this time, the remittance contract can switch the remittance business to a transaction completion state.

[0158] In the verification process, the verification information of the fund remittance request between system B and system C can be stored through the remittance contract to ensure the credibility of the remittance process.

[0159] In some embodiments, after the verification of the fund remittance request is completed, the remittance operation between system B and system C can be performed.

[0160] See also Figure 8 , Figure 8 A flowchart of a remittance operation method shown in this application. Figure 8 Remitter A is not shown.

[0161] In some embodiments, the system C may notify the system B that the verification has been completed. The system B may execute S81 to initiate a status query request for the remittance business to the block.

[0162] The blockchain may execute S82, in response to a status query request initiated by a first system corresponding to the remitter for the remittance business, sending the current transaction status of the remittance business to the first system, so that the first system determines whether the current transaction status is a transaction completion status, and performs a remittance operation to a second system corresponding to the payee when the current transaction status is a transaction completion status.

[0163] In some embodiments, the system B may unfreeze the funds in the remitter's account corresponding to the remittance amount and continue to complete the remittance operation.

[0164] In some embodiments, when a remittance operation is performed to the system C based on the remittance amount indicated by the funds remittance request confirmation information, the funds corresponding to the remittance amount can be deducted from the balance of the remitter A account opened by the remitter A in the system B, and the corresponding deduction voucher can be stored in the blockchain after the deduction is successful.

[0165] Then, a transfer request is submitted to the system C, wherein the transfer request includes the evidence identification corresponding to the deduction voucher.

[0166] After receiving the transfer request, the system C can obtain the deduction voucher stored in the blockchain according to the storage identifier. Then, the sixth digital signature included in the deduction voucher is authenticated, and if the identity of the sixth digital signature is that of the system B, the funds deducted from the account of the remitter A are received.

[0167] In this case, first, the transfer process can be recorded through the blockchain, so that the transparent and tamper-proof characteristics of the blockchain can be used to make the remittance process traceable, ensuring the traceability and reliability of the remittance business. Second, the transaction status of the remittance business can be maintained.

[0168] In some embodiments, when the remittance contract detects that the transaction status is a completed transaction status, it can further call the reconciliation logic of the reconciliation contract to update the maintained reconciliation statements of the system B and system C based on the remittance amount completed by the remittance business.

[0169] The system B or system C can obtain the reconciliation statement to complete the reconciliation between system B and system C by calling the query logic of the reconciliation contract, thereby realizing automatic reconciliation through the nesting of the remittance contract and the reconciliation contract.

[0170] Corresponding to any of the embodiments, the present application also proposes a blockchain-based reconciliation device 90. The blockchain deploys a first smart contract for managing a remittance business; and a second smart contract associated with the first smart contract for reconciliation; the blockchain stores remittance information corresponding to the remittance business; and the first smart contract maintains a transaction status corresponding to the remittance business.

[0171] See also Fig. 9 , Fig. 9 This is a schematic diagram of the structure of a blockchain-based reconciliation device shown in this application.

[0172] like Fig. 9 As shown, the device 90 may include:

[0173] A receiving module 91 receives a contract call transaction initiated by any target remittance participant among multiple remittance participants related to the remittance business for the first smart contract; wherein the contract call transaction includes confirmation information of the target remittance participant for the remittance information;

[0174] The calling module 92, in response to the contract calling transaction, calls the state update logic included in the first smart contract, stores the confirmation information in the blockchain, and after the confirmation information is stored, determines whether the confirmation information of the multiple remittance participants for the remittance information is stored in the blockchain; if so, updates the transaction status to a transaction completion status; and,

[0175] In response to the transaction status of the remittance business being a transaction completion status, the reconciliation logic included in the second smart contract is further called to perform clearing and reconciliation corresponding to the remittance business for the multiple remittance participants based on the remittance amount in the remittance information.

[0176] In some embodiments, the device 90 further comprises:

[0177] A first sending module 93 receives a reconciliation statement query request initiated by any participant among the multiple remittance participants;

[0178] In response to the reconciliation bill query request, the reconciliation bill corresponding to the participant maintained by the reconciliation contract is sent to the participant, so that the participant performs reconciliation based on the reconciliation bill.

[0179] In some embodiments, the device 90 further comprises:

[0180] A second sending module receives a block acquisition request initiated by any participant among the multiple remittance participants; the acquisition request includes time period information;

[0181] In response to the block acquisition request, the block generated within the time period is sent to the participant, so that the participant can determine whether the transaction status of the remittance business included in the block is a transaction completion status, and when the transaction status is a transaction completion status, update the reconciliation statement maintained by itself according to the remittance amount corresponding to the remittance business.

[0182] In some embodiments, the device 90 further comprises:

[0183] The third sending module, in response to a status query request initiated by the first transaction subsystem corresponding to the remitter of the remittance business for the remittance business, sends the current transaction status of the remittance business to the first transaction subsystem, so that the first transaction subsystem determines whether the current transaction status is a transaction completion status, and performs a remittance operation to the second transaction subsystem corresponding to the payee when the current transaction status is a transaction completion status.

[0184] In some embodiments, the device 90 further comprises:

[0185] A freezing module, in response to the first transaction subsystem determining that the current transaction state is a transaction completion state, freezing the funds corresponding to the remittance amount in the remitter account corresponding to the remitter;

[0186] The unfreezing module unfreezes the funds corresponding to the remittance amount in the remitter's account before performing the remittance operation to the second transaction subsystem corresponding to the payee.

[0187] In some embodiments, the device 90 further comprises:

[0188] A creation module receives a creation request transaction initiated by the remitter for the remittance business;

[0189] In response to the creation request transaction, calling the initialization logic of the remittance transaction contract, creating a remittance business corresponding to the remitter, and updating the transaction state corresponding to the remittance business to an initialization state; and / or,

[0190] The evidence storage module receives the remittance information initiated by the remitter for the remittance business and fills in the transaction; the remittance information includes the information of each party involved in the remittance business;

[0191] In response to the remittance information filling transaction, the filling logic of the remittance transaction contract is called, the remittance information is stored in the storage space corresponding to the remittance business in the remittance transaction contract, and the transaction status is updated to a state where the participant information is filled in.

[0192] In some embodiments, the device 90 further comprises:

[0193] A fourth sending module receives a first query request initiated by a second transaction subsystem corresponding to a payee for the remittance service;

[0194] In response to the first query request, the remittance information corresponding to the remittance business is sent to the second transaction subsystem, so that the second transaction subsystem generates remittance confirmation information in response to the verification of the remittance information and stores it in the storage space to complete the preliminary verification of the remittance business.

[0195] In some embodiments, the device 90 further comprises:

[0196] a determination module, which determines whether the second transaction subsystem corresponding to the initiation of the first query request is the second transaction subsystem indicated in the remittance information before sending the remittance information corresponding to the remittance business to the second transaction subsystem;

[0197] If yes, the remittance information corresponding to the remittance business is sent to the second transaction subsystem.

[0198] In some embodiments, the device 90 further comprises:

[0199] The updating module updates the transaction status to a state where the remittance information is filled in in response to completing the preliminary verification of the remittance business.

[0200] In some embodiments, the device 90 further comprises:

[0201] A fifth sending module, receiving a second query request initiated by the remitter for the remittance service;

[0202] In response to the second query request, the remittance confirmation information corresponding to the remittance business is sent to the remitter, so that the remitter generates a deduction request in response to the verification of the remittance confirmation information and stores the deduction request in the storage space.

[0203] In some embodiments, the device 90 further comprises:

[0204] A sixth sending module receives a third query request initiated by the first transaction subsystem corresponding to the remitter for the remittance business;

[0205] In response to the third query request, a deduction request corresponding to the remittance business is sent to the first transaction subsystem, so that the first transaction subsystem generates deduction request confirmation information and a fund remittance request in response to the verification of the deduction request and stores them in the storage space to complete the verification of the remittance business.

[0206] In some embodiments, the first transaction subsystem verifies the fee deduction request, including:

[0207] The first transaction subsystem obtains remittance information and remittance confirmation information associated with the remittance business;

[0208] The remittance verification is performed on the remitter based on the remittance confirmation information, and the authenticity of the deduction request is verified based on the remittance information and the remittance confirmation information.

[0209] In some embodiments, the remittance confirmation information includes the remittance account opened by the remitter in the first transaction subsystem and the remittance amount;

[0210] The performing remittance verification on the remitter based on the remittance confirmation information comprises:

[0211] Verifying whether the account balance of the remitter's account in the remittance confirmation information reaches the remittance amount; if so, determining that the remittance verification of the remitter has passed;

[0212] The performing authenticity verification on the deduction request based on the remittance information and the remittance confirmation information includes:

[0213] Authentication of the first digital signature included in the remittance information and the second digital signature included in the remittance confirmation information;

[0214] If the identity corresponding to the first digital signature is the remitter and the identity corresponding to the second digital signature is the second transaction subsystem, it is determined that the authenticity verification of the deduction request has passed.

[0215] In some embodiments, the device 90 further comprises:

[0216] a seventh sending module, receiving a fourth query request initiated by the second transaction subsystem for the remittance business;

[0217] In response to the fourth query request, a fund remittance request corresponding to the remittance business is sent to the second transaction subsystem, so that the second transaction subsystem generates fund remittance confirmation information in response to the verification of the fund remittance request and stores it in the storage space to complete the secondary verification of the remittance business.

[0218] In some embodiments, the device 90 further comprises:

[0219] An eighth sending module, in response to the fourth query request, sends the current transaction status corresponding to the remittance business to the second transaction subsystem, so that the second transaction subsystem verifies the current transaction status.

[0220] In some embodiments, the second transaction subsystem verifies the current transaction status, including:

[0221] The second transaction subsystem determines whether the current transaction status is a state where the remittance information is filled in, and determines that the verification of the transaction status is passed when the current transaction status is a state where the remittance information is filled in;

[0222] The second transaction subsystem verifies the fund remittance request, including:

[0223] The second transaction subsystem obtains remittance information, remittance confirmation information and deduction request associated with the remittance business;

[0224] Authentication is performed on the first digital signature included in the remittance information, the second digital signature included in the remittance confirmation information, the third digital signature included in the deduction request, the fourth digital signature included in the deduction request, and the fifth digital signature included in the funds remittance request;

[0225] If the identities corresponding to the first digital signature and the third digital signature are the remitter, the identity corresponding to the second digital signature is the second transaction subsystem, and the identities corresponding to the fourth digital signature and the fifth digital signature are the first transaction subsystem, it is determined that the verification of the funds remittance request is successful.

[0226] In some embodiments, the remittance operation to the second transaction subsystem corresponding to the payee includes:

[0227] Deducting funds corresponding to the remittance amount from the remitter's account balance opened in the second transaction subsystem, and storing the corresponding deduction voucher in the blockchain after the deduction is successful;

[0228] Submit a transfer request to the second transaction subsystem, wherein the transfer request includes a storage identifier corresponding to the deduction voucher, so that the second transaction subsystem obtains the deduction voucher stored in the blockchain according to the storage identifier, and authenticates the sixth digital signature included in the deduction voucher; if the identity of the sixth digital signature is that of the first transaction subsystem, the funds deducted from the remitter's account are received.

[0229] In some embodiments, the remittance service includes a cross-border remittance service; and / or, the remittance service includes a cross-border remittance service of the same currency.

[0230] In some embodiments, the plurality of remittance participants include:

[0231] The remitter corresponding to the remittance business;

[0232] A first transaction subsystem corresponding to the remitter;

[0233] A second transaction subsystem corresponding to the payee designated by the remitter.

[0234] The embodiment of the reconciliation device shown in the present application can be applied to an electronic device. Accordingly, the present application discloses an electronic device, which may include: a processor.

[0235] Memory used to store processor-executable instructions.

[0236] The processor is configured to call the executable instructions stored in the memory to implement the reconciliation method shown in any of the aforementioned embodiments.

[0237] See also Fig.10 , Fig.10 A schematic diagram of the hardware structure of an electronic device shown in this application.

[0238] like Fig.10 As shown, the electronic device may include a processor for executing instructions, a network interface for network connection, a memory for storing operating data for the processor, and a non-volatile memory for storing instructions corresponding to the reconciliation device.

[0239] The embodiments of the device can be implemented by software, hardware or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by the processor of the electronic device in which it is located reading the corresponding computer program instructions in the non-volatile memory into the memory and running them. From the hardware level, in addition to Fig.10 In addition to the processor, memory, network interface, and non-volatile memory shown, the electronic device in which the device in the embodiment is located may also include other hardware according to the actual function of the electronic device, which will not be described in detail.

[0240] It is understandable that, in order to improve the processing speed, the corresponding instructions of the reconciliation device can also be directly stored in the memory, which is not limited here.

[0241] The present application proposes a computer-readable storage medium, which stores a computer program. The computer program can be used to enable a processor to execute the reconciliation method shown in any of the aforementioned embodiments.

[0242] Those skilled in the art will appreciate that one or more embodiments of the present application may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present application may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, one or more embodiments of the present application may take the form of a computer program product implemented in one or more computer-usable storage media (which may include but are not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0243] The term "and / or" in the present application means at least one of the two. For example, "A and / or B" may include three options: A, B, and "A and B".

[0244] Each embodiment in the present application is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the data processing device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

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

[0246] Embodiments of the subject matter and functional operations described in this application may be implemented in the following: digital electronic circuits, tangibly embodied computer software or firmware, computer hardware that may include the structures disclosed in this application and their structural equivalents, or a combination of one or more of them. Embodiments of the subject matter described in this application may be implemented as one or more computer programs, i.e., one or more modules in computer program instructions encoded in a tangible non-temporary program carrier to be executed by a data processing device or to control the operation of a parameter processing device. Alternatively or additionally, program instructions may be encoded in an artificially generated propagation signal, such as a machine-generated electrical, optical or electromagnetic signal, which is generated to encode information and transmit it to a suitable receiver device for execution by a data processing device. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them.

[0247] The processes and logic flows described in this application can be performed by one or more programmable computers executing one or more computer programs to perform corresponding functions by operating on input data and generating output. The processes and logic flows can also be performed by special purpose logic circuits, such as FPGAs (field programmable gate arrays) or ASICs (application specific integrated circuits), and the apparatus can also be implemented as special purpose logic circuits.

[0248] A computer suitable for executing a computer program may include, for example, a general and / or special purpose microprocessor, or any other type of central processing unit. Typically, the central processing unit will receive instructions and data from a read-only memory and / or a random access memory. The basic components of a computer may include a central processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more large-capacity storage devices for storing data, such as a disk, a magneto-optical disk, or an optical disk, or the computer will be operably coupled to this large-capacity storage device to receive data from it or to transmit data to it, or both. However, a computer does not necessarily have such a device. In addition, a computer may be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive, to name a few.

[0249] Computer readable media suitable for storing computer program instructions and data may include all forms of non-volatile memory, media and memory devices, such as semiconductor memory devices (e.g., EPROM, EEPROM and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated in, special purpose logic circuits.

[0250] Although the application includes many specific implementation details, these should not be interpreted as limiting any disclosed scope or the scope of protection claimed, but are mainly used to describe the features of specific disclosed specific embodiments. Certain features described in multiple embodiments in the application can also be implemented in combination in a single embodiment. On the other hand, the various features described in a single embodiment can also be implemented separately in multiple embodiments or implemented with any suitable sub-combination. In addition, although the feature can work in some combinations as described and even initially claim protection, one or more features from the claimed combination can be removed from the combination in some cases, and the claimed combination can point to a variation of a sub-combination or a sub-combination.

[0251] Similarly, although operations are depicted in a particular order in the accompanying drawings, this should not be understood as requiring that these operations be performed in the particular order shown or performed sequentially, or requiring that all illustrated operations be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. In addition, the separation of various system modules and components in the described embodiments should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product, or packaged into multiple software products.

[0252] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the particular order or sequential order shown to achieve the desired results. In some implementations, multitasking and parallel processing may be advantageous.

[0253] The above are only preferred embodiments of one or more embodiments of the present application and are not intended to limit one or more embodiments of the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of the present application should be included in the scope of protection of one or more embodiments of the present application.

Claims

1. A reconciliation method based on blockchain, wherein the blockchain deploys a first smart contract for managing a remittance business; and a second smart contract associated with the first smart contract for remittance reconciliation; the blockchain stores remittance information corresponding to the remittance business; And, the first smart contract maintains a transaction status corresponding to the remittance business; The method comprises: Receiving a contract call transaction initiated by any target remittance participant among multiple remittance participants related to the remittance business for the first smart contract; wherein the contract call transaction includes confirmation information of the target remittance participant for the remittance information; In response to the contract call transaction, the state update logic included in the first smart contract is called, the confirmation information is stored in the blockchain, and after the confirmation information is stored, it is determined whether the confirmation information of the multiple remittance participants for the remittance information is stored in the blockchain; if so, the transaction status is updated to a transaction completion status; and, in response to the transaction status of the remittance business being a transaction completion status, the reconciliation logic included in the second smart contract is further called, and based on the remittance amount in the remittance information, the clearing and reconciliation corresponding to the remittance business is performed for the multiple remittance participants.

2. The method according to claim 1, further comprising: Receiving a reconciliation statement query request initiated by any participant among the multiple remittance participants; In response to the reconciliation statement query request, the reconciliation statement corresponding to the participant maintained by the second smart contract is sent to the participant, so that the participant performs reconciliation based on the reconciliation statement.

3. The method according to claim 1, further comprising: Receiving a block acquisition request initiated by any participant among the multiple remittance participants; the acquisition request includes time period information; In response to the block acquisition request, the block generated within the time period is sent to the participant, so that the participant can determine whether the transaction status of the remittance business included in the block is a transaction completion status, and when the transaction status is a transaction completion status, update the reconciliation statement maintained by itself according to the remittance amount corresponding to the remittance business.

4. The method according to claim 1, further comprising: In response to a status query request initiated by a first transaction subsystem corresponding to the remitter of the remittance business for the remittance business, the current transaction status of the remittance business is sent to the first transaction subsystem, so that the first transaction subsystem determines whether the current transaction status is a transaction completion status, and performs a remittance operation on a second transaction subsystem corresponding to the payee when the current transaction status is a transaction completion status.

5. The method according to claim 4, further comprising: In response to the first transaction subsystem determining that the current transaction state is a transaction completion state, freezing the funds corresponding to the remittance amount in the remitter account corresponding to the remitter; Before the remittance operation is performed to the second transaction subsystem corresponding to the payee, the method includes: The funds corresponding to the remittance amount in the remitter's account are unfrozen.

6. The method according to claim 1, further comprising: Receive a creation request transaction initiated by the remitter for the remittance business; In response to the creation request transaction, calling the initialization logic of the first smart contract, creating a remittance service corresponding to the remitter, and updating the transaction status corresponding to the remittance service to an initialization status; and / or, Receive the remittance information initiated by the remitter for the remittance business and fill in the transaction; the remittance information includes information of each party involved in the remittance business; In response to the remittance information filling transaction, the filling logic of the first smart contract is called, the remittance information is stored in the storage space corresponding to the remittance business in the first smart contract, and the transaction status is updated to a state in which the participant information is filled.

7. The method according to claim 6, further comprising: Receiving a first query request initiated by a second transaction subsystem corresponding to a payee for the remittance service; In response to the first query request, the remittance information corresponding to the remittance business is sent to the second transaction subsystem, so that the second transaction subsystem generates remittance confirmation information in response to the verification of the remittance information and stores it in the storage space to complete the preliminary verification of the remittance business.

8. The method according to claim 7, before sending the remittance information corresponding to the remittance service to the second transaction subsystem, further comprising: Determine whether the second transaction subsystem corresponding to the initiation of the first query request is the second transaction subsystem indicated in the remittance information; If yes, the remittance information corresponding to the remittance business is sent to the second transaction subsystem.

9. The method according to claim 8, further comprising: In response to completing the preliminary verification of the remittance service, the transaction status is updated to a state in which the remittance information is completed.

10. The method according to claim 9, further comprising: receiving a second query request initiated by the remitter for the remittance service; In response to the second query request, the remittance confirmation information corresponding to the remittance business is sent to the remitter, so that the remitter generates a deduction request in response to the verification of the remittance confirmation information and stores the deduction request in the storage space.

11. The method according to claim 10, further comprising: receiving a third query request initiated by the first transaction subsystem corresponding to the remitter for the remittance service; In response to the third query request, a deduction request corresponding to the remittance business is sent to the first transaction subsystem, so that the first transaction subsystem generates deduction request confirmation information and a fund remittance request in response to the verification of the deduction request and stores them in the storage space to complete the verification of the remittance business.

12. The method according to claim 11, wherein the first transaction subsystem verifies the fee deduction request, comprising: The first transaction subsystem obtains remittance information and remittance confirmation information associated with the remittance business; The remittance verification is performed on the remitter based on the remittance confirmation information, and the authenticity of the deduction request is verified based on the remittance information and the remittance confirmation information.

13. The method according to claim 12, wherein the remittance confirmation information includes the remittance account opened by the remitter in the first transaction subsystem and the remittance amount; The performing remittance verification on the remitter based on the remittance confirmation information comprises: Verifying whether the account balance of the remitter's account in the remittance confirmation information reaches the remittance amount; If yes, determining that the remittance verification of the remitter has passed; The performing authenticity verification on the deduction request based on the remittance information and the remittance confirmation information includes: Authentication of the first digital signature included in the remittance information and the second digital signature included in the remittance confirmation information; If the identity corresponding to the first digital signature is the remitter and the identity corresponding to the second digital signature is the second transaction subsystem, it is determined that the authenticity verification of the deduction request has passed.

14. The method according to claim 11, further comprising: receiving a fourth query request initiated by the second transaction subsystem for the remittance service; In response to the fourth query request, a fund remittance request corresponding to the remittance business is sent to the second transaction subsystem, so that the second transaction subsystem generates fund remittance confirmation information in response to the verification of the fund remittance request and stores it in the storage space to complete the secondary verification of the remittance business.

15. The method according to claim 14, further comprising: In response to the fourth query request, the current transaction status corresponding to the remittance service is sent to the second transaction subsystem, so that the second transaction subsystem verifies the current transaction status.

16. The method according to claim 15, wherein the second transaction subsystem verifies the current transaction status, comprising: The second transaction subsystem determines whether the current transaction status is a state where the remittance information is filled in, and determines that the verification of the transaction status is passed when the current transaction status is a state where the remittance information is filled in; The second transaction subsystem verifies the fund remittance request, including: The second transaction subsystem obtains remittance information, remittance confirmation information and deduction request associated with the remittance business; Authentication is performed on the first digital signature included in the remittance information, the second digital signature included in the remittance confirmation information, the third digital signature included in the deduction request, the fourth digital signature included in the deduction request, and the fifth digital signature included in the funds remittance request; If the identities corresponding to the first digital signature and the third digital signature are the remitter, the identity corresponding to the second digital signature is the second transaction subsystem, and the identities corresponding to the fourth digital signature and the fifth digital signature are the first transaction subsystem, it is determined that the verification of the funds remittance request is successful.

17. The method according to claim 5, wherein the remittance operation to the second transaction subsystem corresponding to the payee comprises: Deducting funds corresponding to the remittance amount from the remitter's account balance opened in the second transaction subsystem, and storing the corresponding deduction voucher in the blockchain after the deduction is successful; Submit a transfer request to the second transaction subsystem, wherein the transfer request includes a storage identifier corresponding to the deduction voucher, so that the second transaction subsystem obtains the deduction voucher stored in the blockchain according to the storage identifier, and authenticates the sixth digital signature included in the deduction voucher; if the identity of the sixth digital signature is that of the first transaction subsystem, the funds deducted from the remitter's account are received.

18. The method according to claim 1, wherein the remittance service comprises a cross-border remittance service.

19. The method according to claim 1, wherein the plurality of remittance participants include: The remitter corresponding to the remittance business; A first transaction subsystem corresponding to the remitter; A second transaction subsystem corresponding to the payee designated by the remitter.

20. A reconciliation device based on blockchain, wherein the blockchain deploys a first smart contract for managing a remittance business; and a second smart contract associated with the first smart contract for remittance reconciliation; the blockchain stores remittance information corresponding to the remittance business; And, the first smart contract maintains a transaction status corresponding to the remittance business; The device comprises: A receiving module receives a contract call transaction initiated by any target remittance participant among multiple remittance participants related to the remittance business for the first smart contract; wherein the contract call transaction includes confirmation information of the target remittance participant for the remittance information; A calling module, in response to the contract calling transaction, calls the state update logic included in the first smart contract, stores the confirmation information in the blockchain, and after the confirmation information is stored, determines whether the confirmation information of the multiple remittance participants for the remittance information is stored in the blockchain; if so, updates the transaction status to a transaction completion status; and, In response to the transaction status of the remittance business being a transaction completion status, the reconciliation logic included in the second smart contract is further called to perform clearing and reconciliation corresponding to the remittance business for the multiple remittance participants based on the remittance amount in the remittance information.

21. An electronic device, comprising: processor; a memory for storing processor-executable instructions; The processor implements the reconciliation method as described in any one of claims 1 to 19 by running the executable instructions.

22. A computer-readable storage medium storing a computer program, wherein the computer program is used to enable a processor to execute the reconciliation method according to any one of claims 1 to 19.

Images