WO2023078158A1

WO2023078158A1 - Blockchain-based remittance path management

Info

Publication number: WO2023078158A1
Application number: PCT/CN2022/128000
Authority: WO
Inventors: 韩喆; 陈聪明
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2021-11-02
Filing date: 2022-10-27
Publication date: 2023-05-11
Also published as: CN113989045A

Abstract

The present disclosure provides a blockchain-based remittance path management method and apparatus. A first smart contract is stored on a blockchain, the first smart contract being used to manage an available remittance path of at least one participant of multiple participants in a target remittance transaction; the available remittance path of the at least one participant is used to indicate an available remittance path that can be provided by the at least one participant for the target remittance transaction, and the at least one participant comprises a first participant. The method comprises: receiving a first call request of the first smart contract from the first participant, the first call request being used to set the available remittance path of the first participant; maintaining the available remittance path of the first participant in the first smart contract according to the first call request.

Description

Blockchain-based remittance route management

technical field

The present disclosure relates to the technical field of blockchain, and in particular to a method and device for managing remittance routes based on blockchain.

Background technique

Currently, blockchain can serve remittance transactions by executing remittance transaction contracts. When the remittance initiator needs to initiate a target remittance transaction, the remittance initiator needs to first query the available remittance routes of the participants in the target remittance transaction through the centralized system of the financial platform. If the available remittance route queried by the remittance initiator matches the remittance route required by the target remittance transaction, the user can initiate the target remittance transaction on the blockchain by calling the remittance transaction contract. At this time, the blockchain The transaction result of the target remittance transaction can be recorded by executing the remittance transaction contract.

That is to say, the available remittance routes of the participants in the target remittance transaction are all maintained through the centralized system. In some cases, when the remittance initiator queries the available remittance routes through the centralized system, the centralized system may maintain incorrect remittance routes due to system errors, thus returning wrong results to the remittance initiator and reducing user experience . For example, the available remittance route of the original participant matches the remittance route required by the target remittance transaction, but due to an error in the centralized system, the maintenance of the available remittance route of the participant is wrong, and the available remittance route of the participant is recorded It is an unavailable remittance route, and an error result such as "does not match, or there is no available remittance route" is returned to the remittance initiator, resulting in the remittance initiator being unable to initiate the target remittance transaction and degrading user experience.

Contents of the invention

In view of this, the embodiments of the present disclosure are dedicated to providing a blockchain-based method for managing remittance routes, so as to reduce the possibility of errors occurring when the centralized system maintains available remittance routes and improve user experience.

In the first aspect, a blockchain-based method for managing remittance routes is provided, where a first smart contract is stored on the blockchain, and the first smart contract is used to manage the number of participants in the target remittance transaction. The available remittance route of at least one participant, the available remittance route of the at least one participant is used to indicate the available remittance route that the at least one participant can provide for the target remittance transaction, the at least one participant Including the first participant, the method includes: receiving a first call request of the first smart contract from the first participant, and the first call request is used to set the available remittance of the first participant according to the first call request, setting available remittance routes of the first participant in the first smart contract.

In the second aspect, a blockchain-based method for managing remittance routes is provided, where a first smart contract is stored on the blockchain, and the first smart contract is used to manage the number of participants in the target remittance transaction. The available remittance route of at least one participant, the available remittance route of the at least one participant is used to indicate the available remittance route that the at least one participant can provide for the target remittance transaction, the at least one participant Including the first participant, the method is applied to the first participant, and the method includes: obtaining the available remittance route of the first participant; sending the first smart contract to the block chain A first call request, where the first call request is used to set the available remittance routes of the first participant.

In the third aspect, a block chain-based remittance route management device is provided, where a first smart contract is stored on the block chain, and the first smart contract is used to manage the number of participants in the target remittance transaction. The available remittance route of at least one participant, the available remittance route of the at least one participant is used to indicate the available remittance route that the at least one participant can provide for the target remittance transaction, the at least one participant Including the first participant, the device includes: a receiving module, configured to receive a first call request of the first smart contract from the first participant, and the first call request is used to set the first participant available remittance routes of the party; a processing module configured to set the available remittance routes of the first participant in the first smart contract according to the first call request.

In the fourth aspect, a block chain-based remittance channel management device is provided, where a first smart contract is stored on the block chain, and the first smart contract is used to manage the number of participants in the target remittance transaction. The available remittance route of at least one participant, the available remittance route of the at least one participant is used to indicate the available remittance route that the at least one participant can provide for the target remittance transaction, the at least one participant Including the first participant, the device is applied to the first participant, and the device includes: an acquisition module, used to obtain the available remittance route of the first participant; a sending module, used to send to the district The block chain sends a first call request of the first smart contract, and the first call request is used to set an available remittance route of the first participant.

In the fifth aspect, there is provided a block chain-based remittance route management device, including a memory and a processor, wherein executable code is stored in the memory, and the processor is configured to execute the executable code to realize The method as described in the first aspect or the second aspect.

In a sixth aspect, a computer-readable storage medium is provided, on which executable code is stored, and when the executable code is executed, the method as described in the first aspect or the second aspect can be implemented.

In a seventh aspect, a computer program product is provided, including executable codes, and when the executable codes are executed, the method as described in the first aspect or the second aspect can be implemented.

The solution of the embodiment of the present disclosure is to maintain the available remittance routes of the participants in the target remittance transaction through the first smart contract on the blockchain, so that the participants as blockchain users can autonomously call the first smart contract Maintain available remittance routes in a timely manner. It avoids the traditional solution of using a centralized system to maintain the available remittance routes of the participants. Due to errors in the centralized system, the participants’ available remittance routes are wrong, which helps to reduce the time spent on maintaining the available remittance routes in the centralized system. Possibility of error occurs, improving user experience.

Description of drawings

FIG. 1 is a schematic diagram of a block chain architecture applicable to an embodiment of the present disclosure.

FIG. 2 is a schematic flow chart of an employer A initiating a target remittance transaction.

FIG. 3 is a schematic flowchart of a blockchain-based remittance route management method according to an embodiment of the present disclosure.

Fig. 4 is a schematic flow chart of the update process of the first smart contract according to the embodiment of the present disclosure.

Fig. 5 is a schematic flowchart of the process of using the first smart contract according to the embodiment of the present disclosure.

Fig. 6 is a schematic flowchart of the query process of the first smart contract according to the embodiment of the present disclosure.

Fig. 7 is a schematic structural diagram of a block chain-based remittance route management device according to an embodiment of the present disclosure.

Fig. 8 is a schematic structural diagram of a blockchain-based remittance route management device according to another embodiment of the present disclosure.

Fig. 9 is a schematic structural diagram of a blockchain-based remittance route management device provided by another embodiment of the present disclosure.

Fig. 10 is a schematic structural diagram of a blockchain-based remittance route management device provided by another embodiment of the present disclosure.

Detailed ways

The following will clearly and completely describe the technical solutions in the embodiments of the present disclosure with reference to the accompanying drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only some of the embodiments of the present disclosure, not all of them.

In order to facilitate the understanding of the solution of the present disclosure, the blockchain architecture applicable to the present disclosure and some concepts involved are introduced below in conjunction with FIG. 1 .

Blockchain architecture.

FIG. 1 is a schematic diagram of a block chain architecture applicable to an embodiment of the present disclosure. The architecture 100 shown in FIG. 1 includes blockchain nodes 110 and user nodes 120 .

Blockchain (Blockchain) is a typical distributed collaborative system. Multiple parties jointly maintain a growing distributed data record. The content and timing of these recorded data are protected by cryptography technology, making it difficult for any party to tamper, deny, or falsify.

In the blockchain, data (for example, packaged transaction data, transaction execution results, etc.) can be encapsulated in the form of blocks. Blocks can be linked to each other through forward applications to form a "chain", that is, a blockchain. In some implementations, each block records basic data such as the hash value of the previous block, the transaction set in this block, and the hash of this block.

Generally, the user node 120 of the blockchain can communicate with the blockchain node 110 through a client. In some cases, the user node 120 may send the data to be stored to one or more associated blockchain nodes 110 in a manner of submitting a transaction. Among them, a transaction can be understood as a transaction request on the blockchain, which is used to carry the structure of specific business operation data. All changes to the state of the world on the blockchain can be done based on transactions.

Correspondingly, after the blockchain node 110 verifies the validity of the data, it can broadcast the data to each blockchain node 110 in a network-wide broadcast manner. In this way, each blockchain node 110 records a full amount of consistent data.

For example, in the scenario of performing remittance transactions in the embodiments of the present disclosure, the aforementioned blockchain node 110 may be a node that performs remittance-related functions, for example, recording the transaction status of remittance transactions. Correspondingly, the above-mentioned user node 120 may include a user node located at the remittance initiator, for example, the user node 122 of the employer A. The above-mentioned user node 120 may also include a user node of a remittance institution performing remittance, for example, a user node 121 of a remittance bank. The above-mentioned user node 120 may also be a user node of a money collection institution that receives remittances, for example, a user node 123 of a beneficiary bank.

In some implementations, the aforementioned blockchain node 110 may be a server, or other devices with computing capabilities. The aforementioned user node 120 may be a server, a mobile terminal, or other devices with computing capabilities.

Smart Contracts.

A smart contract is a set of promises defined in digital form, including an agreement on which the parties to the contract can enforce those promises. In other words, a smart contract can be understood as a program deployed on a computer system. When the trigger conditions of the smart contract are met, the smart contract can be automatically executed.

The emergence of blockchain provides technical support for the realization of smart contracts. The smart contract is written into the blockchain in a digital form, and the characteristics of the blockchain technology ensure that the entire process of storage, reading, and execution of the smart contract is transparent, traceable, and unchangeable. On the other hand, a state machine system can be constructed by the consensus algorithm that comes with the blockchain, so that smart contracts can run efficiently.

In some implementations, the user can call the smart contract by submitting a transaction to the blockchain system, set the data recorded in the smart contract, and store the set smart contract in the blockchain. Correspondingly, when the specific conditions of the smart contract are triggered, the blockchain node can execute the smart contract, and record the execution result of the smart contract and the execution status of the smart contract.

Currently, blockchain can serve remittance transactions by executing remittance transaction contracts. When the remittance initiator needs to initiate a target remittance transaction, the remittance initiator needs to first query the available remittance routes of the participants in the target remittance transaction through the centralized system of the financial platform. Among them, the available remittance routes can be understood as the remittance transactions can be carried out The path between the payer and the payee. If the available remittance route queried by the remittance initiator matches the remittance route required by the target remittance transaction, the user can initiate the target remittance transaction on the blockchain by calling the remittance transaction contract. At this time, the blockchain The transaction result of the target remittance transaction can be recorded by executing the remittance transaction contract.

The following describes the process of initiating a target remittance transaction by taking the remittance initiator as an example of a target remittance transaction initiated by employer A in combination with Figure 2 . Assume that investor A needs to conduct a target remittance transaction to investor B, and the remittance channel required for the target remittance transaction is remittance institution A to remittance institution B. In addition, the available remittance routes of remittance institution A will be recorded in the centralized system.

In step S210, employer A needs to send an inquiry request to the centralized system to inquire about the available remittance routes of remittance institution A.

In step S220, if the remittance route from remittance institution A to remittance institution B is not recorded in the available remittance route of remittance institution A, that is, the available remittance route of remittance institution A does not match the remittance route required by the target remittance transaction , employer A does not initiate a target remittance transaction to the blockchain.

In step S230, if the remittance route from remittance institution A to remittance institution B is recorded in the available remittance route of remittance institution A, that is, when the available remittance route of remittance institution A matches the remittance route required by the target remittance transaction , employer A can record the transaction status of the target remittance transaction executed off-chain by calling the remittance transaction contract in the blockchain. Wherein, the above-mentioned transaction status includes: waiting for confirmation by the counterparty, transaction success, transaction failure, etc.

In step S240, the blockchain executes the remittance transaction contract to record the transaction status of the target remittance transaction executed off-chain.

However, as mentioned above, the remittance routes available to the parties involved in the target remittance transaction are all maintained through a centralized system. In some cases, when the remittance initiator queries the available remittance routes through the centralized system, the centralized system may maintain incorrect remittance routes due to system errors, thus returning wrong results to the remittance initiator. For example, the available remittance route of the original participant matches the remittance route required by the target remittance transaction, but due to an error in the centralized system, the maintenance of the available remittance route of the participant is wrong, and the available remittance route of the participant is recorded It is an unavailable remittance route, and an error result such as "does not match, or there is no available remittance route" is returned to the remittance initiator, resulting in the remittance initiator being unable to initiate the target remittance transaction and degrading user experience.

On the other hand, due to the possibility of evil in the centralized system, maintaining the available remittance routes of the participants through the centralized system may reduce the security of the available remittance routes.

Therefore, in order to avoid the above problems, this disclosure provides a blockchain-based remittance route management method, that is, the first smart contract is used to maintain the available remittance routes of the above-mentioned participants on the blockchain, so that as a block The participants of the chain users can maintain the available remittance routes autonomously by calling the first smart contract, which is beneficial to reduce the possibility of errors when the centralized system maintains the available remittance routes and improve user experience.

On the other hand, maintaining the available remittance routes of the above-mentioned participants through the first smart contract on the block chain is conducive to improving the security of the available remittance routes.

The following describes the blockchain-based remittance route management method of the embodiment of the present disclosure with reference to FIG. 3 . For ease of understanding, the first smart contract in the embodiment of the present disclosure is introduced first.

The first smart contract is used to manage the available remittance routes of at least one of the multiple participants in the target remittance transaction. The available remittance route of at least one participant is used to indicate the available remittance route that at least one participant can provide for the target remittance transaction. Therefore, the first smart contract can also be called "Huilu Management Contract".

Assume that the remittance route required by the target remittance transaction is a remittance transaction from bank A to bank B, that is to say, multiple participants in the target remittance transaction include bank A and bank B. Table 1 shows a possible implementation of the first smart contract recording available remittance routes in the embodiment of the present disclosure.

Table 1

Referring to Table 1, the available remittance routes of Bank A and Bank B are recorded in the first smart contract. Among them, the available remittance routes of bank A include: the remittance route between bank A and bank B; the remittance route between bank A branch 1 and bank A branch 2. The available remittance routes of Bank B include: the remittance route between Bank B and Bank A; the remittance route between Bank B Branch 2 and Bank B Branch 3; and the remittance route between Bank B and Bank C.

It should be noted that the above available remittance routes are used to indicate the paths available for remittance transactions, and are not used to limit the direction of remittance when executing remittance transactions. For example, the available remittance route "Bank A-Bank B" can be used to indicate a remittance transaction between Bank A and Bank B, that is, remittances can be made from Bank A to Bank B, or from Bank B to Bank B A makes a remittance.

In addition, the first smart contract can also record the available remittance routes of other institutions, for example, the available remittance routes of Bank D can be recorded. The embodiment of the present disclosure does not limit this.

In some cases, the available remittance routes may have restrictions on the type of currency used for remittances. For example, for the available remittance route "Bank A-Bank B", the available remittance route only supports the remittance method of currency type 1 (for example, RMB). In this way, the types of currencies supported by each available remittance route can also be recorded in the above-mentioned first smart contract. For example, it can be recorded in the first smart contract according to the format of "bank A-bank B-currency type". Certainly, for an available remittance route with no restriction on currency types, the currency types supported by the available remittance route may not be recorded. The embodiment of the present disclosure does not limit this.

In order to facilitate the query of the first smart contract, a query interface can be set for the above-mentioned first smart contract, so that other users of the blockchain can query the available remittance routes recorded in the first smart contract through the query interface. In addition, in order to facilitate the update of the first smart contract, an update interface can also be set for the above-mentioned first smart contract, so that the participants can call the first smart contract through the update interface to update the available remittance routes recorded in the first smart contract to update. The query and update process of the above-mentioned first smart contract will be introduced below in conjunction with FIG. 4 to FIG. 6 , and will not be repeated here for the sake of brevity.

In addition, this disclosure does not limit the creation process of the above-mentioned first smart contract. The above-mentioned first smart contract can be created and deployed in the blockchain by the supplier of the blockchain, so that users of the blockchain (for example, the above-mentioned target The participant of the remittance transaction) is called by updating the interface, and the available remittance route of the participant is recorded in the first smart contract. Of course, the above-mentioned first smart contract can also be created and deployed in the blockchain by users of the blockchain. For example, it can be created by the participants of the target remittance transaction, so that the participants of the target During the contract process, the available remittance routes can be directly deployed on the blockchain together with the first smart contract.

Fig. 3 is a schematic flow chart of a blockchain remittance channel management method according to an embodiment of the present disclosure. The method shown in FIG. 3 includes steps S310 to S330. The method shown in Figure 3 can be applied to the block chain architecture shown in Figure 1, so that the first participant in step S310 can be the user 120 of the block chain, for example, the user node 121 of the remittance bank or the receiving party User node 123 of the bank. Correspondingly, the blockchain nodes performing step S320 and step S330 may be one or more blockchain nodes 110 in the architecture 100 that can communicate with the user 120 .

In step S310, the first participant acquires available remittance routes of the first participant.

The above-mentioned available remittance routes of the first participant can be understood as the available remittance routes of the first participant to be linked. For example, it may be that the first party needs to update the available remittance routes. For another example, it may be an available remittance route newly created by the first participant.

In step S320, the blockchain node receives a first invocation request of the first smart contract from the first participant.

The above-mentioned first participant is one of the multiple participants participating in the target remittance transaction. The first participant may be the remittance bank that executes the target remittance transaction, and the first participant may also be the receiving bank that executes the target remittance transaction.

The above-mentioned first call request is used to set the available remittance routes of the first participant. In some implementations, the above setting can be understood as creation, and at this time, the first call request can be understood as being used to create an available remittance route for the first participant. In some other implementation manners, the above setting can be understood as an update, at this time, the first call request can be understood as being used to update the available remittance routes of the first participant.

In step S330, the blockchain node sets the available remittance routes of the first participant in the first smart contract according to the first call request.

Usually, in order to improve the security of the available remittance routes, before step S330, the blockchain node may perform user authentication on the first participant to determine that the first participant has the right to set the available remittance routes. For example, if the user on the chain of the first participation method is confirmed, and the role of the first participant is a bank, at this time, the first participant has the right to set the available remittance routes. In some implementations, the above user authentication can be implemented based on public keys and data signatures. Specifically, the blockchain node can store the public key of the first participant, and the first participant can use the private key of the first participant to digitally sign the available remittance route when setting up the available remittance route, In this way, when the blockchain node receives the available remittance route uploaded by the first participant, the blockchain node can use the public key of the first participant to verify the digital signature on the available remittance route. If the verification is passed, then The first participant has the right to set available remittance routes. On the contrary, if the verification fails, the first participant has no right to set available remittance routes.

In addition, in order to confirm the legitimacy of the available remittance routes set by the first participant, before step S330, the blockchain node may also verify the validity of the available remittance routes uploaded by the first participant. In some implementations, the block chain can determine the remitter and payee involved in the available remittance route according to the format of the available remittance route specified by the remittance route (for example, it may be the format shown in Table 1) Whether the party is a legal user on the chain, if both the remitter and the payee are legal users on the chain, the block chain node can determine that the available remittance route set by the first participant is legal, then the block chain Nodes can maintain available remittance routes in the first smart contract. On the contrary, if the remitter and/or the payee are not legal users on the chain, the blockchain node can determine that the available remittance route set by the first participant is illegal, then the blockchain node will not check the available remittance route road maintenance.

In some implementations, the above-mentioned blockchain nodes determine whether the remitter and payee involved in the available remittance route are legal on-chain users, which can be judged by whether the remitter and the payee have corresponding on-chain users . For example, the blockchain node can store the corresponding relationship between the user name on the chain of all users on the chain and the user name off the chain of the user, and the remitter and receiver of the above-mentioned available remittance routes use the remitter, The off-chain user name of the payee (for example, the name of the bank). At this time, the blockchain can determine whether the remitter and the payee are Have a corresponding user name on the chain, so as to determine whether the remitter and the payee are legal users on the chain.

In order to facilitate the understanding of the present disclosure, the update process of the first smart contract in the embodiment of the present disclosure will be introduced below by taking the update of the first smart contract as an example with reference to FIG. 4 . It should be noted that Figure 4 mainly introduces the method flow for updating the first smart contract. For related introductions about the first participant, the first smart contract, available remittance routes, user authentication, legality verification, etc., please refer to The above, for the sake of brevity, will not be repeated here.

Fig. 4 is a schematic flowchart of the updating process of the first smart contract according to the embodiment of the present disclosure. The method shown in FIG. 4 includes steps S410 to S460.

In step S410, the first participant sets an updated list of available remittance routes.

The first participant may input the first list of available remittance routes by calling the update interface of the first smart contract.

In step S420, the blockchain node performs user authentication on the first participant.

The above updated remittance route is digitally signed by the private key of the first participant. The blockchain node may verify the digital signature based on the public key of the first participant to determine that the first participant performs user authentication, and if the user authentication passes, step S430 may be executed. If the user authentication fails, the update fails, and step S440 is executed to end the update process.

In step S430, the blockchain node verifies the legitimacy of the available remittance routes in the list of available remittance routes.

If the legality verification is passed, step S450 is executed. If the validity verification fails, the update fails, and step S440 is performed.

In step S450, the blockchain node updates the available remittance routes in the first smart contract to the first available remittance route list.

In step S460, the first smart contract is updated successfully.

The block chain node can use the above-mentioned first available remittance route list as the data of the first smart contract, and persistently store it in the block chain.

It should be noted that, the present disclosure does not limit the execution sequence between the above step S420 and step S430. The above step S430 can also be executed before step S420. At this time, when the legality verification of step S430 is passed, step S420 can be executed, and only when the user authentication result of step S420 is also passed, step S450 can be continued . Of course, step S420 and step S430 can also be executed at the same time, that is, step S450 can be executed only when the user authentication result of step S420 and the legality verification of step S430 both pass.

As mentioned above, in the process of initiating a traditional remittance transaction, the remittance initiator needs to first query the available remittance routes of the participants in the decentralized system. However, in some cases, the remittance initiator may not first query the available remittance routes according to the process, but directly initiates the first transaction execution request on the chain to request the first participant to execute the target remittance transaction. At this time, if the remittance route required by the target remittance transaction does not match the available remittance route of the first participant, the first participant needs to confirm that the available remittance route does not match the remittance route required by the target remittance transaction, Then the first transaction initiated on the chain can be closed. However, if the first participant fails to confirm in time, the transaction status of the first transaction will remain stagnant and will be in the state of "waiting for the confirmation of the first participant". In this way, the remittance initiator cannot timely know the final execution result of the first transaction , reducing the user experience.

In order to avoid the above problems, the present disclosure also provides a block chain remittance route management method, which matches the available remittance route recorded in the first smart contract with the remittance route required by the target remittance transaction, and obtains the matching result. And based on the matching results, the transaction status of the first transaction is automatically promoted, avoiding the stagnation of the transaction status of the first transaction due to the failure of the first participant to confirm in time under the traditional remittance transaction submission method, and the inability to know the first transaction in time for the convenience of remittance initiation The final execution result is conducive to improving user experience.

Continuing to refer to FIG. 3 , the above method may further include step S340 to step S360 .

In step S340, a first transaction execution request is received from the second participant, and the first transaction execution request is used to request the first participant to execute the target remittance transaction.

The above-mentioned second participant may be the initiator of the target remittance transaction, for example, it may be the investor A introduced above.

In step S350, in response to the first transaction execution request, the first smart contract is invoked to query whether the remittance route required by the target remittance transaction matches the available remittance route of the first participant.

If the remittance route required by the target remittance transaction matches the available remittance route of the first participant, it can be understood that the remittance route required by the target remittance transaction is included in the available remittance route of the first participant. For example, the remittance route required for the target remittance transaction is remittance from bank A to bank B. At this time, if bank A is the first participant, and referring to Table 1, it can be seen that the available remittance route of bank A includes "bank A -Bank B", then the available remittance route of Bank A matches the remittance route required by the target remittance transaction.

If the remittance route required by the target remittance transaction does not match the remittance route available to the first participant, it can be understood that the remittance route required by the target remittance transaction is not included in the available remittance routes of the first participant. For example, the remittance route required for the target remittance transaction is remittance from bank A to bank C. At this time, if bank A is the first participant, and referring to Table 1, it can be seen that the available remittance route of the bank does not include "bank A-Bank C"'s remittance route, then the available remittance route of Bank A does not match the remittance route required by the target remittance transaction.

In step S360, if the remittance route required by the target remittance transaction does not match the available remittance route of the first participant, the target remittance transaction is terminated.

The above termination of the target remittance transaction can be understood as setting the transaction status of the first transaction as terminated.

In some implementation manners, in the solution described above in conjunction with steps S340 to S360, a target remittance transaction can be initiated to the blockchain by calling a contract. That is to say, the above-mentioned second participant can request the first participant to execute the target remittance transaction by calling the contract. In other words, the above-mentioned first transaction execution request is an invocation request of the second smart contract, the second smart contract is used to execute the target remittance transaction, and the state of the second smart contract is used to represent the transaction status of the target remittance transaction. Therefore, the second smart contract is also called "remittance transaction contract". Wherein, the second smart contract may include transaction information of the target remittance transaction. For example, information on the originator of the target remittance transaction, information on the payee of the target remittance transaction, the remittance route required by the target remittance transaction, and transaction details of the target remittance transaction.

In order to associate the above matching result with the state of the second smart contract, the address of the first smart contract can be set in the second smart contract, so that in the process of executing the second smart contract, the address of the first smart contract can be called based on the address. A smart contract to check whether the remittance route required for the target remittance transaction matches the available remittance route of the first participant. If the remittance route required by the target remittance transaction does not match the available remittance routes of the first party, the target remittance transaction may be terminated and the state of the second smart contract may be set to closed. If the remittance route required by the target remittance transaction matches the remittance route available to the first party, then the state of the second smart contract can be advanced to the next state (eg, waiting for the party to confirm the current transaction).

As mentioned above, all participants on the blockchain can act as users of the blockchain and set their own available remittance routes by calling the first smart contract. That is to say, the first smart contract will record the available remittance routes of multiple participants. At this time, in some cases, there may be remittance route 1 that is an available remittance route for participant 1, but the remittance Remittance route 1 is not an available remittance route for participant 2. At this time, if only the available remittance route of participant 1 is matched during the matching process, the matching result becomes a match, but in fact, remittance route 1 is not an available remittance route, which will result in the target remittance transaction fail.

Suppose remittance route 1 was originally an available remittance route between Bank A and Bank B, but due to some reasons, Bank B and Bank A need to update the available remittance route, and update remittance route 1 to an unavailable remittance route sink road. However, only bank B is updated successfully, and bank A is not updated successfully. At this time, although remittance route 1 is no longer an available remittance route between bank A and bank B, it is still recorded in the available remittance route in bank A . At this time, if the remittance route required for the initiated target remittance transaction happens to be available remittance route 1, and only the available remittance route of Bank A is used for matching, the matching result will be a match, which will lead to Target money transfer transaction failed.

Therefore, in order to improve the accuracy of the above matching results, the remittance route required by the target remittance transaction can be used in the matching process to match with the available remittance routes of multiple participants in the target remittance transaction. If the matching result is a match, the remittance route is the real available remittance route. Continue to refer to the scene of remittance route 1 above. At this time, match remittance route 1 with the available remittance routes of bank A and bank B respectively, then remittance route 1 and the available remittance route of bank A The matching result of the remittance route is a match, and the matching result of the remittance route 1 and the available remittance routes of Bank A is a mismatch. Finally, the matching result corresponding to the remittance route 1 becomes a mismatch, then the target remittance can be directly terminated trade.

In order to facilitate understanding of the present disclosure, the following uses the example of invoking the first smart contract during the execution of the second smart contract, and introduces the process of using the first smart contract in the embodiment of the present disclosure with reference to FIG. 5 . It should be noted that Figure 5 mainly introduces the method flow of using the first smart contract. For related introductions about the first participant, the first smart contract, available remittance routes, user authentication, and legality verification, please refer to the above , for the sake of brevity, will not be repeated here.

Fig. 5 is a schematic flowchart of the process of using the first smart contract according to the embodiment of the present disclosure. The method shown in FIG. 5 includes steps S510 to S590.

In step S510, the remittance initiator sends a call request of the second smart contract to the block chain node.

The call request is used to request the first participant to execute the target remittance transaction. Wherein, the remittance route required for the target remittance transaction is the remittance route between the first participant and the second participant.

In step S520, the blockchain node performs user authentication on the remittance initiator.

The above-mentioned remittance initiator will use the private key to sign the invocation request of the second smart contract. Correspondingly, after receiving the invocation request of the above-mentioned second smart contract, the blockchain node can use the public key of the remittance initiator to digitally sign authenticating. If the user authentication result is passed, step S530 is executed. If the user authentication result is not passed, step S540 is executed to close the target remittance transaction.

In step S530, the blockchain node checks the validity of the second smart contract.

The above legality check is used to check whether the transaction parameters of the target remittance transaction are complete. For example, it is necessary to specify in the second smart contract the remittance institution of the target remittance transaction, the on-chain account of the remittance institution, the remittance currency involved in the target remittance transaction, and other information.

If the result of the legality check is passed, step S550 is executed. If the legitimacy verification result is passed, step S540 is executed to close the target remittance transaction.

In step S550, the remittance route required by the target remittance transaction is extracted from the second smart contract.

In step S560, the block chain node invokes the first smart contract to query whether the remittance route required by the target remittance transaction matches the available remittance routes of the remittance institution and the remittance institution respectively.

In the process of executing the second smart contract, the query interface of the first smart contract can be automatically called twice to respectively query whether the available remittance channels of the remittance institution and the available remittance channels of the receiving institution are the same as those required by the target remittance transaction. Remittance route matching. If both the available remittance channels of the remittance institution and the available remittance channels of the payee institution match the remittance channels required by the target remittance transaction, step S570 is performed. If the available remittance routes of the remittance institution and/or the available remittance routes of the payee institution do not match the remittance routes required by the target remittance transaction, step S540 is executed to close the target remittance transaction.

In step S570, the blockchain node advances the state of the second smart contract to "waiting for the participant to confirm the current transaction".

In step S580, the participants in the target remittance transaction confirm the target remittance transaction corresponding to the second smart contract.

The participants in the target remittance transaction can obtain the transaction information of the target remittance transaction recorded in the second smart contract from the block chain node by means of pulling block analysis. When the participants in the target remittance transaction confirm that the off-chain remittance transaction is executed correctly based on the transaction information of the target remittance transaction, they can call the confirmation interface of the second smart contract to confirm the target remittance transaction.

In step S590, it is confirmed whether all participants in the target remittance transaction confirm.

After receiving confirmation from the participants in the target remittance transaction, the second smart contract automatically triggers the processing logic to inquire whether all the participants in the target remittance transaction have confirmed the target remittance transaction. If all the participants in the target remittance transaction confirm, the second smart contract automatically advances to the final state, indicating that the target remittance transaction is successful, ie step S600.

It should be noted that the present disclosure does not limit the execution sequence between the above step S520 and step S530. The above step S530 can also be executed before step S520. At this time, when the legality verification of step S530 is passed, step S520 can be executed, and only when the user authentication result of step S520 is also passed, step S550 can be continued . Of course, step S520 and step S530 can also be executed at the same time, that is, only when the user authentication result of step S520 and the legality verification of step S530 both pass, step S550 can be executed.

Taking the method of calling the first smart contract by the second smart contract as an example, the process of using the first smart contract in the embodiment of the present disclosure is introduced with reference to FIG. 5 . In the embodiment of the present disclosure, the available remittance routes can also be queried only through the query interface of the first smart contract. The query process of the first smart contract in the embodiment of the present disclosure is introduced below with reference to FIG. 6 . It should be noted that Figure 6 mainly introduces the method flow of using the first smart contract. For the introduction of the first participant, the first smart contract, and available remittance channels, please refer to the above. repeat.

Fig. 6 is a schematic flowchart of the query process of the first smart contract according to the embodiment of the present disclosure. The method shown in FIG. 6 includes steps S610 to S620.

In step S610, the block chain node receives the second call request of the first smart contract from the third participant, and the second call request is used to query the available remittance routes of the first participant.

In step S620, the blockchain node returns the available remittance routes of the first participant to the third participant.

The method embodiment of the present disclosure is described in detail above with reference to FIG. 1 to FIG. 6 , and the device embodiment of the present disclosure is described in detail below in conjunction with FIG. 7 to FIG. 10 . It should be understood that the descriptions of the method embodiments correspond to the descriptions of the device embodiments, therefore, for parts not described in detail, reference may be made to the foregoing method embodiments.

Fig. 7 is a schematic structural diagram of a block chain-based remittance route management device according to an embodiment of the present disclosure. The device shown in Figure 7 may be a blockchain node on a blockchain, on which a first smart contract is stored, and the first smart contract is used to manage the participation of at least one of the multiple participants in the target remittance transaction The available remittance route of the party, the available remittance route of at least one participant is used to indicate the available remittance route that at least one participant can provide for the target remittance transaction, and the at least one participant includes the first participant. The foregoing apparatus 700 includes: a receiving module 710 and a processing module 720 .

The receiving module 710 may be configured to receive a first call request of the first smart contract from the first participant, and the first call request is used to set an available remittance route of the first participant.

The processing module 720 may be configured to set the available remittance routes of the first participant in the first smart contract according to the first call request.

Optionally, in some embodiments, the multiple participants include the second participant, and the receiving module 710 may also be configured to receive a first transaction execution request from the second participant, the first transaction execution request is used to request the first The participant executes the target remittance transaction; the processing module 720 may be configured to, in response to the first transaction execution request, invoke the first smart contract to query whether the remittance route required for the target remittance transaction and the available remittance route of the first participant matching; and, if the remittance route required by the target remittance transaction does not match the remittance route available to the first party, terminating the target remittance transaction.

Optionally, in some embodiments, the multiple participants include a third participant, and the receiving module 710 may be configured to receive a second invocation request of the first smart contract from the third participant, and the second invocation request is used to query Available remittance routes of the first participant; the processing module 720 may be configured to return the available remittance routes of the first participant to the third participant.

Optionally, in some embodiments, the receiving module 710 may be configured to receive a third call request of the first smart contract from the first participant, and the third call request is used to update the available remittance routes of the first participant; The processing module 720 may be configured to update the available remittance routes of the first participant in the first smart contract based on the third call request.

Optionally, in some embodiments, the first smart contract is also used to manage the types of currencies supported by the available remittance routes of the first participant.

Fig. 8 is a schematic structural diagram of a blockchain-based remittance route management device according to another embodiment of the present disclosure. A first smart contract is stored on the block chain, and the first smart contract is used to manage the available remittance route of at least one of the multiple participants in the target remittance transaction, and the available remittance route of at least one participant is used for An available remittance route that at least one participant can provide for the target remittance transaction is indicated, the at least one participant includes the first participant, and the device is applied to the first participant. The device 800 includes: an acquiring module 810 and a sending module 820 .

The obtaining module 810 is configured to obtain the available remittance channels of the first participant; the sending module 820 is configured to send the first call request of the first smart contract to the blockchain, and the first call request is used to set the first participant The available remittance routes of the party.

Optionally, in some embodiments, the sending module 820 may be configured to send a third call request of the first smart contract to the blockchain, where the third call request is used to update the available remittance routes of the first participant.

Fig. 9 is a schematic structural diagram of a blockchain-based remittance route management device provided by another embodiment of the present disclosure. The device 900 shown in FIG. 9 may be any blockchain node in the blockchain. The apparatus 900 may be, for example, a computing device with a computing function. For example, device 900 may be a server. The apparatus 900 may include a memory 910 and a processor 920 . Memory 910 may be used to store executable code. The processor 920 can be used to execute the executable code stored in the memory 910, so as to realize the steps in the various methods described above. In some embodiments, the apparatus 900 may further include a network interface 930 through which data exchange between the processor 920 and external devices may be implemented.

Fig. 10 is a schematic structural diagram of a blockchain-based remittance route management device provided by another embodiment of the present disclosure. The apparatus 1000 shown in FIG. 10 may be a node where a client in the blockchain resides. The apparatus 1000 may be, for example, a computing device with computing functions. For example, the device 1000 may be a server or a mobile terminal. The apparatus 1000 may include a memory 1010 and a processor 1020 . Memory 1010 may be used to store executable code. The processor 1020 can be used to execute the executable code stored in the memory 1010, so as to realize the steps in the various methods described above. In some embodiments, the apparatus 900 may further include a network interface 1030 through which data exchange between the processor 1020 and external devices may be implemented.

It should be understood that, in the embodiment of the present disclosure, the processor may adopt a general-purpose central processing unit (central processing unit, CPU), and the processor may also be other general-purpose processors, digital signal processors (digital signal processor, DSP) , application specific integrated circuit (ASIC), off-the-shelf programmable gate array (field programmable gate array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc., for executing related programs, so as to realize the technical solutions provided by the embodiments of the present disclosure.

The memory, which can include read only memory and random access memory, provides instructions and data to the processor. A portion of the processor may also include non-volatile random access memory. For example, the processor may also store device type information.

In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in a processor or an instruction in the form of software. The method for requesting uplink transmission resources disclosed in the embodiments of the present disclosure may be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor. The software module can be located in a mature storage medium in the field such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, register. The storage medium is located in the memory, and the processor reads the information in the memory, and completes the steps of the above method in combination with its hardware. To avoid repetition, no detailed description is given here.

It should be understood that the term "and/or" in this article is only an association relationship describing associated objects, which means that there may be three relationships, for example, A and/or B may mean: A exists alone, and A and B exist at the same time , there are three cases of B alone. In addition, the character "/" in this article generally indicates that the contextual objects are an "or" relationship.

It should be understood that in various embodiments of the present disclosure, the sequence numbers of the above-mentioned processes do not mean the order of execution, and the execution order of the processes should be determined by their functions and internal logic, rather than by the embodiments of the present disclosure. The implementation process constitutes any limitation.

In the several embodiments provided in the present disclosure, it should be understood that the disclosed systems, devices and methods may be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or May be integrated into another system, or some features may be ignored, or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional module in each embodiment of the present disclosure may be integrated into one module, each module may exist independently, or two or more modules may be integrated into one module.

In the above embodiments, all or part of them may be implemented by software, hardware, firmware or any combination thereof. When implemented using software, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the computer, all or part of the processes or functions according to the embodiments of the present disclosure will be generated. The computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website, computer, server or data center Transmission to another website site, computer, server or data center by wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that can be read by a computer, or a data storage device such as a server or a data center integrated with one or more available media. The available medium may be a magnetic medium, (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a digital versatile disc (digital video disc, DVD)) or a semiconductor medium (for example, a solid state disk (solid state disk, SSD) )wait.

The above is only a specific implementation of the present disclosure, but the scope of protection of the present disclosure is not limited thereto. Anyone skilled in the art can easily think of changes or substitutions within the technical scope of the present disclosure. should fall within the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be determined by the protection scope of the claims.

Claims

A method for managing remittance routes based on a block chain, where a first smart contract is stored on the block chain, and the first smart contract is used to manage at least one of a plurality of participants in a target remittance transaction Available remittance routes, the available remittance routes of the at least one participant are used to indicate the available remittance routes that the at least one participant can provide for the target remittance transaction, the at least one participant includes the first participant ,

The methods include:

receiving a first call request of the first smart contract from the first participant, where the first call request is used to set an available remittance route of the first participant;

According to the first call request, the available remittance routes of the first participant are set in the first smart contract.
The method of claim 1, the plurality of participants comprising a second participant, the method further comprising:

receiving a first transaction execution request from the second participant, the first transaction execution request for requesting the first participant to execute the target remittance transaction;

In response to the first transaction execution request, calling the first smart contract to query whether the remittance route required for the target remittance transaction matches the available remittance route of the first participant;

If the remittance route required by the target remittance transaction does not match the available remittance route of the first participant, the target remittance transaction is terminated.
The method of claim 1, the plurality of participants comprising a third participant, the method further comprising:

receiving a second call request of the first smart contract from the third participant, where the second call request is used to inquire about available remittance routes of the first participant;

The available remittance routes of the first participant are returned to the third participant.
The method according to claim 1, said method further comprising:

receiving a third call request of the first smart contract from the first participant, where the third call request is used to update the available remittance routes of the first participant;

Based on the third call request, the available remittance routes of the first participant are updated in the first smart contract.
The method according to any one of claims 1-4, wherein the first smart contract is further used to manage the types of currencies supported by the available remittance routes of the first participant.
A method for managing remittance routes based on a block chain, where a first smart contract is stored on the block chain, and the first smart contract is used to manage at least one of a plurality of participants in a target remittance transaction Available remittance routes, the available remittance routes of the at least one participant are used to indicate the available remittance routes that the at least one participant can provide for the target remittance transaction, the at least one participant includes the first participant , the method is applied to the first party,

The methods include:

Obtain the available remittance routes of the first participant;

Sending a first call request of the first smart contract to the block chain, where the first call request is used to set an available remittance route of the first participant.
The method of claim 6, further comprising:

Sending a third call request of the first smart contract to the block chain, where the third call request is used to update available remittance routes of the first participant.
The method according to claim 6 or 7, wherein the first smart contract is further used to manage the types of currencies supported by the available remittance routes of the first participant.
A block chain-based remittance management device, the first smart contract is stored on the block chain, and the first smart contract is used to manage at least one of the multiple participants in the target remittance transaction Available remittance routes, the available remittance routes of the at least one participant are used to indicate the available remittance routes that the at least one participant can provide for the target remittance transaction, the at least one participant includes the first participant ,

The devices include:

The receiving module is configured to receive a first call request of the first smart contract from the first participant, and the first call request is used to set an available remittance route of the first participant;

The processing module is configured to set the available remittance routes of the first participant in the first smart contract according to the first call request.
The apparatus of claim 9, said plurality of participants comprising a second participant,

The receiving module is configured to receive a first transaction execution request from the second participant, and the first transaction execution request is used to request the first participant to execute the target remittance transaction;

The processing module is configured to call the first smart contract in response to the first transaction execution request to query the remittance route required for the target remittance transaction and the available remittance of the first participant. Whether the road matches;

The processing module is configured to terminate the target remittance transaction if the remittance route required by the target remittance transaction does not match the available remittance route of the first participant.
The apparatus of claim 9, said plurality of participants comprising a third participant,

The receiving module is configured to receive a second call request of the first smart contract from the third participant, and the second call request is used to inquire about available remittance routes of the first participant;

The processing module is configured to return the available remittance routes of the first participant to the third participant.
The device according to claim 9,

The receiving module is configured to receive a third call request of the first smart contract from the first participant, and the third call request is used to update the available remittance routes of the first participant;

The processing module is configured to update the available remittance routes of the first participant in the first smart contract based on the third call request.
The device according to any one of claims 9-12, wherein the first smart contract is further used to manage the types of currencies supported by the available remittance routes of the first participant.
A block chain-based remittance management device, the first smart contract is stored on the block chain, and the first smart contract is used to manage at least one of the multiple participants in the target remittance transaction Available remittance routes, the available remittance routes of the at least one participant are used to indicate the available remittance routes that the at least one participant can provide for the target remittance transaction, the at least one participant includes the first participant , the device is applied to the first participant,

The devices include:

An acquisition module configured to acquire the available remittance routes of the first participant;

The sending module is configured to send the first call request of the first smart contract to the block chain, and the first call request is used to set the available remittance routes of the first participant.
The device according to claim 14,

The sending module is configured to send a third call request of the first smart contract to the blockchain, where the third call request is used to update the available remittance routes of the first participant.
The device according to claim 14 or 15, wherein the first smart contract is further used to manage the types of currencies supported by the available remittance routes of the first participant.
A blockchain-based remittance route management device, comprising a memory and a processor, wherein executable code is stored in the memory, and the processor is configured to execute the executable code, so as to realize claims 1-5 any one of the methods described.
A block chain-based remittance route management device, comprising a memory and a processor, wherein executable code is stored in the memory, and the processor is configured to execute the executable code, so as to realize claims 6-8 any one of the methods described.