WO2023045532A1

WO2023045532A1 - Blockchain-based transaction processing

Info

Publication number: WO2023045532A1
Application number: PCT/CN2022/107785
Authority: WO
Inventors: 韩喆; 陈聪明
Original assignee: 蚂蚁区块链科技(上海)有限公司; 支付宝(杭州)信息技术有限公司
Priority date: 2021-09-24
Filing date: 2022-07-26
Publication date: 2023-03-30
Also published as: CN113781230A

Abstract

Disclosed is a blockchain-based transaction processing method. A first smart contract is deployed on a blockchain, the first smart contract being used for managing a service time window of at least one of a plurality of participants of a target transaction, the service time window of the at least one participant being used for indicating the time when the at least one participant can participate in the target transaction, and the at least one participant comprising a first participant. The method comprises: receiving a first invocation request of the first smart contract from the first participant, the first invocation request being used for setting a service time window of the first participant; and setting the service time window of the first participant according to the first invocation request.

Description

Blockchain-based transaction processing

technical field

The present disclosure relates to the technical field of block chains, in particular to a transaction processing method and device based on block chains.

Background technique

At present, in the scenario of blockchain transactions involving multiple parties, some transactions need to rely on participants to operate off-chain. In this case, the blockchain only ensures that the participants confirm the transaction on the chain, and the confirmation process of each participant depends on the participants completing the security review process in the internal system and submitting it to the blockchain to advance the transaction status.

If the on-chain state of the transaction needs to be confirmed by the participant, the off-chain service of the participant is not available, for example, if it is not within the time window for the participant to provide services, the transaction will not be accepted for a long time, and a large number of unavailable Completed transactions cause on-chain transactions to block.

Contents of the invention

In view of this, the present disclosure provides a blockchain-based transaction processing method and device to avoid on-chain transaction blocking caused by not being within the service time window of the participant.

In the first aspect, a transaction processing method based on a block chain is provided, and a first smart contract is deployed on the block chain, and the first smart contract is used to manage the participation of at least one of a plurality of participants in the target transaction The service time window of the party, the service time window of the at least one party is used to indicate the time when the at least one party can participate in the target transaction, the at least one party includes the first party, the method includes : Receive the first call request of the first smart contract from the first participant, the first call request is used to set the service time window of the first participant; according to the first call request, set The service time window of the first participant.

In the second aspect, a transaction processing method based on a block chain is provided, and a first smart contract is deployed on the block chain, and the first smart contract is used to manage the participation of at least one of a plurality of participants in the target transaction The service time window of the party, the service time window of the at least one party is used to indicate the time when the at least one party can participate in the target transaction, the at least one party includes the first party, and the method applies For the first participant, the method includes: sending a first call request of the first smart contract to the block chain, the first call request is used to set the service time of the first participant window.

In a third aspect, a block chain-based transaction processing device is provided, where a first smart contract is deployed on the block chain, and the first smart contract is used to manage the participation of at least one of a plurality of participants in the target transaction The service time window of the party, the service time window of the at least one party is used to indicate the time when the at least one party can participate in the target transaction, the at least one party includes the first party, and the device includes : a first receiving unit configured to receive a first call request of the first smart contract from the first participant, the first call request is used to set the service time window of the first participant; set A unit configured to set a service time window of the first participant according to the first call request.

In the fourth aspect, a block chain-based transaction processing device is provided, and a first smart contract is deployed on the block chain, and the first smart contract is used to manage the participation of at least one of the multiple participants in the target transaction. The service time window of the party, the service time window of the at least one party is used to indicate the time when the at least one party can participate in the target transaction, the at least one party includes the first party, and the device application For the first participant, the device includes: a sending unit configured to send a first call request of the first smart contract to the blockchain, the first call request is used to set the first A service time window for a party.

In the fifth aspect, there is provided a block chain-based transaction processing 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, so as to realize the The method described in one 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.

In the technical solution provided by the embodiments of the present disclosure, by deploying the first smart contract on the blockchain, it is ensured that the service time window of each participant of the target transaction can be managed on the blockchain, thereby avoiding The on-chain transaction blocking caused by the service time window.

Description of drawings

FIG. 1 is an example diagram of a blockchain system provided by an embodiment of the present disclosure.

FIG. 2 is a schematic diagram of a transaction involving multiple parties provided by an embodiment of the present disclosure.

FIG. 3 is an example diagram of a system architecture provided by an embodiment of the present disclosure.

Fig. 4 is an example diagram of a first smart contract provided by an embodiment of the present disclosure.

FIG. 5 is a schematic flowchart of a transaction processing method based on blockchain provided by an embodiment of the present disclosure.

Fig. 6 is a schematic flowchart of setting a service time window of a first participant provided by an embodiment of the present disclosure.

Fig. 7 is a schematic flowchart of querying the service time window of the first participant provided by an embodiment of the present disclosure.

FIG. 8 is an exemplary diagram of another system architecture provided by an embodiment of the present disclosure.

Fig. 9 is a schematic structural diagram of a transaction processing device based on blockchain provided by an embodiment of the present disclosure.

FIG. 10 is a schematic structural diagram of a blockchain-based transaction processing device provided by another disclosed embodiment of the present disclosure.

Fig. 11 is a schematic structural diagram of a transaction processing device based on blockchain 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.

Blockchain is a distributed chain storage accounting technology based on cryptography technology. Blockchain technology can organize and maintain a large amount of data in a decentralized or multi-centralized manner. It has the characteristics of distributed, non-tamperable, traceable, safe and reliable, and has been widely used in many fields.

Fig. 1 is an example diagram of a blockchain system provided by an embodiment of the present disclosure. As shown in FIG. 1 , a blockchain system 100 may include a blockchain client (client for short) 110 and a blockchain network 120 . The blockchain network 120 may include multiple blockchain nodes (referred to as nodes), for example, node 120-A, node 120-B, node 120-C, ..., node 120-N in FIG. 1 .

The client 110 and/or the nodes in the blockchain network 120 may include various types of computing devices, such as smart phones, desktop computers, or servers. In some embodiments, the server may be an independent server or a server group, and the server group may be centralized or distributed. In some embodiments, the server may execute on a cloud platform.

The client 110 is a terminal that can use blockchain services. The client 110 can link to a certain node in the blockchain network 120 to obtain blockchain services. In some embodiments, the client 110 can obtain blockchain services by initiating a blockchain transaction (transaction for short, also called a request), that is, the client 110 can generate a transaction and send the generated transaction to the block chain network 120 .

Nodes in the blockchain network 120 may receive transactions broadcast in the blockchain network 120 . After receiving the transaction, the blockchain node can perform related operations according to the transaction content, that is, execute the transaction. For example, transferring funds (or assets) between accounts to perform remittance transactions. Another example is to query blockchain data to execute transactions for querying data. Alternatively, invoke (or execute) a smart contract deployed on the blockchain to execute a transaction that invokes the smart contract.

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. The essence of a smart contract is a piece of code running in the blockchain network to complete the business logic assigned by the user.

A smart contract can contain information about a transaction, and the resulting action will only be executed if the requirements are met. Smart contracts can execute traceable, irreversible and secure transactions.

As mentioned above, the blockchain has the characteristics of non-tampering, security and trustworthiness. Therefore, conducting transactions on the blockchain can solve the problem of mutual trust between transaction participants. Based on this, blockchain can be used as an important development direction in transaction scenarios involving multi-party participation. For example, blockchain can be widely used in fund transfer (such as remittance transactions), trade finance, equipment leasing and other transaction scenarios involving multi-party participation and natural distrust.

In the following, combined with Figure 2, a brief introduction will be given to blockchain transactions involving multiple parties. In the scenario shown in Figure 2, a transaction can have multiple parties. For example, the plurality of parties may include party A, which may be the initiator of the transaction. The multiple participants may also include participant B and participant C, and participant B and participant C may be the promoter or executor of the transaction.

Taking a remittance transaction involving fund transfer as an example, participant A may refer to the initiator of the remittance transaction (for example, the financial system of an enterprise), participant B may refer to the remittance bank, and participant C may refer to the beneficiary bank. Participant A can initiate a remittance request to the blockchain, requesting participant B to pay a certain amount of funds to a certain bank account of participant C from its corresponding bank account. In some embodiments, the remittance transaction may refer to cross-border remittance. In some embodiments, the remittance transaction may refer to inter-bank remittance.

Taking equipment leasing as an example, participant A may refer to the lessee (for example, a factory), participant B may refer to the lessor (for example, a leasing platform), and participant C may refer to the supplier. Participant A can initiate a lease request to the blockchain, requesting participant B to lease a certain device to participant A. After receiving the request, participant B needs to request participant C to send the device to participant A.

In this transaction scenario involving multi-party participation, as an example, when the execution of all transactions can be completed on the chain, it is theoretically possible to pre-specify the trigger rules through the smart contract, so as to automatically complete the transaction on the chain.

As another example, when the blockchain is responsible for recording the transaction on the chain and advancing the transaction status, and the real transaction operation requires the cooperation of the participants off the chain (for example, in the remittance transaction, the participant B sends Participant C remits money; or, in the equipment leasing transaction, supplier C sends the equipment to participant A) off the chain. In fact, the transaction cannot be automatically promoted on the chain, but requires the participant to call the relevant smart Contract interface to advance transaction state.

That is to say, in some transaction scenarios involving multi-party participation, due to the internal supervision of the participants and other reasons, the participants need to operate the blockchain transactions off-chain. Therefore, the reliability of the blockchain to complete transactions only on the chain Authentication, which is to ensure that the participants actually confirmed the transaction. The confirmation process of each participant relies on the participant to complete the security review process in the internal system and submit it to the blockchain to automatically advance the transaction status. In this case, the participants need to call the relevant smart contract interface to advance the transaction state.

For example, in a scenario involving fund transfers, transaction reliability verification can be performed on the blockchain. The real fund transfer also depends on the participants operating off-chain, and the on-chain status of each transaction needs to be confirmed by the participants.

However, if the participant's off-chain service is unavailable when the on-chain state of the transaction needs to be confirmed by the participant, for example, it is not within the time window in which the participant can provide the service, which will cause the transaction state on the current blockchain to be unavailable. It may remain as "created, pending confirmation by the participant", until the participant's business system calls the smart contract interface to advance the transaction, the transaction can normally reach the final state on the chain. In other words, the completion of a transaction depends on the service capabilities of each participant, especially the time window in which services can be provided.

If the participant fails to confirm the transaction status in time after the transaction is initiated, the transaction will not be accepted for a long time, and in turn, a large number of unfinished transactions will cause transaction blockage on the chain.

In some embodiments, transaction congestion can affect customer experience. For example, in a remittance transaction involving fund transfer, after participant A initiates a request for a remittance transaction, the initiation time of the remittance transaction is not within the time window during which participant C can provide services, resulting in the occupation of funds for this remittance transaction. However, participant A is not aware of the situation, and cannot use the funds, which affects the customer experience.

Taking the scenario involving fund transfer as an example, in related technologies, in order to avoid the need for multi-party confirmation during the transaction process, the transaction can be carried out through the money transfer company. Quick Remittance Company can pre-deposit the account in the corresponding beneficiary bank first, so that the transaction involving multiple parties can be transformed into two independent intra-bank remittances (the remittance bank directly conducts intra-bank transfer and collection, and the beneficiary bank also directly conducts intra-bank transfer and remittance ).

With this scheme, although transactions involving multiple parties can be avoided by means of advance funds, the problem of multi-party confirmation can be avoided. However, when adopting this solution, Money Transfer needs to advance capital in advance. For some large-amount transfer scenarios, Money Transfer's advance capital cost is extremely high, which is not feasible.

In order to solve the above problems, the embodiments of the present disclosure provide a blockchain-based transaction processing method and device, so as to avoid on-chain transaction blocking caused by not being within the service time window of the participant.

Fig. 3 is an example diagram of a system architecture provided by an embodiment of the present disclosure. As shown in FIG. 3 , the system 300 may include a first participant 310 , a second participant 320 and a blockchain 330 . Both the first party 310 and the second party 320 belong to one of a plurality of parties to the target transaction.

The first participant 310 may be a promoter or an execution party of the target transaction. During the completion of a target transaction, multiple first participants 310 may promote or execute the target transaction.

During the process of completing the target transaction, the first participant 310 can operate the target transaction off-chain. In addition, the first participant 310 can also confirm the target transaction, and then submit the confirmation result to the blockchain to automatically advance the status of the target transaction.

The second party 320 may be the initiator of the targeted transaction. For example, the second participant 320 may initiate a remittance transaction on the blockchain.

The first participant 310 and the second participant 320 may be clients on the blockchain. The first participant 310 and the second participant 320 can send a smart contract call request to the block chain 330 (or block chain network) in the form of a transaction, and all nodes in the block chain 330 call and execute the corresponding smart contract.

The first participant 310 and the second participant 320 can communicate with the blockchain 330 . In some embodiments, there is no direct communication between the first party 310 and the second party 320 .

A first smart contract can be deployed in the block chain 330, and the first smart contract can be used to manage the service time window of at least one of the multiple participants in the target transaction, wherein the service time window of at least one participant can be Used to indicate the time when the at least one participant can participate in the target transaction. For example, the first smart contract can be used to manage the service time window of the first party 310 .

In some embodiments, the first smart contract may contain 2 main interfaces. Calling the first interface may set its own service time window, for example, the first participant 310 may set its own service time window through the first interface. Calling the second interface can query the service time window of the first participant, for example, the second participant 320 can query the service time window of the first participant 310 through the second interface.

An example of the first smart contract is given below with reference to FIG. 4 . The first smart contract may include a first interface (or called, an interface for setting a service time window, setupServiceTimeWindow) and a second interface (or called, an interface for querying a service time window, queryServiceTimeWindow). The first smart contract may also include stored on-chain persistent data.

The first participant can call the first interface to create or update its own service time window information. When the first smart contract receives the calling request of the first interface, it can correspondingly create or update the content of the persistent data on the chain according to the calling request.

The present disclosure does not specifically limit the content of the on-chain persistent data stored in the first smart contract. As an example, the core on-chain persistent data in the first smart contract may include the information of the service time window of each first participant and the loop rule (loop_order) within the service time window.

For information about the service time window of the first participant, please refer to the part of "Persistent data association on the chain" shown in Fig. 4 . The information of the service time window of the first participant may include a series of time slice information (TimeSlice), and a service time window (ServiceTimeWindow) composed of combined information of these time slices.

As shown in FIG. 4 , each time slice may include a pair of start and end times and a corresponding time zone, and the start and end times are the corresponding service time windows of the first participant. For example, in the table representing time slices in FIG. 4 , the row with an id of 1 may indicate that the service time window of the first participant is 9:00-16:00 corresponding to the time zone GMT+8 (Eastern Eighth District).

The first participant or the second participant may call the second interface to query the service time window of a certain first participant, so as to confirm whether the first participant can provide services at a certain time point.

When calling the second interface of the first smart contract, the first smart contract can dynamically analyze the rules corresponding to each service time window. After the parsing is completed, it can be judged whether the current day in the time point to be matched (for example, the initiation time of the target transaction, the current time point, etc.) matches the date matching (day_match) rule in the time slice. After matching, further match the time point to be matched with the start and end time in the time slice. If they all match, it can be considered that the time point to be matched matches the time slice, and then it can be known whether each service time window matches.

In some embodiments, when creating the first smart contract, the date matching rules can be directly written into the first smart contract. In some embodiments, an input parameter can be added to the second interface, allowing the first participant to define its own corresponding date matching rules. For example, the judgment rules for weekends and weekdays are universal and can be directly written in the logic of the first smart contract, while various holidays will change dynamically, allowing the first participant to customize the settings.

The block chain-based transaction processing method provided by the embodiment of the present disclosure will be described in detail below with reference to FIG. 5 . The blockchain-based transaction processing method provided by the embodiments of the present disclosure can be applied to the system architecture shown in FIG. 3 . The method shown in Fig. 5 is described from the perspective of interaction between the first participant and the blockchain.

In step 510, the first participant sends a first invocation request of the first smart contract to the block chain.

The first call request may be used to set the service time window of the first participant. In some embodiments, the first call request may include the service time rules of the first participant. The service time rule can be used to indicate the time when the first participant can provide the service. As an example, the service time rule can indicate that the service is available or unavailable in a certain period of time. For example, the service time rule can take any of the following forms or Its combination: "Not available every Saturday 12:00 to every Sunday 18:00", "Not available on US holidays", or "Available every weekday 9:00-18:00".

In some embodiments, the first participant may send the first call request by calling an interface in the first smart contract. For example, the first participant can call the first interface in the first smart contract to set its own service time window.

In step 520, the blockchain sets the service time window of the first participant according to the first call request.

After receiving the first call request sent by the first participant, the blockchain can set the service time window of the first participant according to the first call request. For example, when the service time window of the first participant is not stored in the blockchain, the blockchain can create the service time window of the first participant in the blockchain according to the first call request; or, when the block chain When the service time window of the first participant has been stored in the chain, the block chain can update the service time window of the first participant stored in the block chain according to the first call request.

Referring to Fig. 6, in some embodiments, after the block chain receives the first call request sent by the first participant, it can check the authority of the first participant to confirm whether the first call request is the corresponding first call request. It is sent by one participant, so as to ensure that each first participant can only call the interface to set its own service time window on the blockchain.

As an implementation, the first call request can include the digital signature of the first participant, that is, the first participant can use the private key of its own account on the blockchain to perform a digital signature when sending the first call request, After the block chain receives the first call request, it can verify the digital signature in the first call request based on the public key of the first participant stored in the first smart contract, where the public key is The public key corresponding to the private key used by the first participant to generate the digital signature. If the digital signature in the first call request passes the verification, it can be confirmed that the first call request is sent by the corresponding first participant, and the first participant can set its own service time window on the blockchain.

In some embodiments, after the authority verification of the first participant is passed, the blockchain can also verify the legality of the rules of the service time window submitted by the first participant. For example, you can check whether the rules of the first participant’s service time window are within your own support range; or, you can check whether the time point of the first participant’s service time window is legal; for another example, you can check whether the first participant Whether the corresponding holidays in the party’s service time window have been maintained in the first smart contract (for example, the first smart contract needs to pre-enter, for example, the specific time corresponding to American holidays).

When the authority of the first participant and the legality of the rules of the service time window of the first participant pass the verification, the blockchain can set the service time of the first participant based on the first call request sent by the first participant window; when the authority of the first participant or the legality of the rules of the service time window of the first participant fail to pass the verification, the blockchain can refuse to set the service time window of the first participant, and at the same time return to the first participant The result of a failed call.

The embodiment of the present disclosure ensures that the service time window of each participant of the target transaction can be managed on the blockchain by deploying the first smart contract on the blockchain, thereby avoiding failures due to not being within the service time window of the participant The resulting blockage of on-chain transactions.

In some embodiments, the multiple participants further include a second participant, and the second participant may send a second invocation request of the first smart contract to the blockchain. The second call request can be used to query the service time window of the first participant.

Fig. 7 is a schematic flowchart of querying the service time window of the first participant provided by an embodiment of the present disclosure. As shown in Figure 7, when the second participant needs to query the service time window of the first participant on the blockchain, the second participant can query by calling the second interface of the first smart contract. After the block chain receives the second call request from the second participant, it can return the query result of the service time window of the first participant to the second participant. In some embodiments, if the target transaction involves multiple first participants, the second participant can uniformly query the service time windows of the multiple first participants by calling the second interface of the first smart contract.

As an example, the query result of the service time window of the first participant sent to the second participant may be the service time window of the first participant. The blockchain can directly return the service time window of the first participant to the second participant, so that the second participant can determine when to initiate a transaction on the blockchain according to the service time window.

As another example, the second call request may include the initiation time of the target transaction, for example, it may be the current time point, or it may also be a time point at which a transaction is planned to be initiated. In this case, the query result of the first participant's service time window sent to the second participant may be used to indicate whether the initiation time of the target transaction is within the first participant's service time window. As an implementation, after the blockchain queries the service time window of the first participant based on the second call request, it can also determine whether the initiation time of the target transaction is within the service time window of the first participant. When the initiation time of the target transaction is within the service time window of the first participant, the query result returned by the blockchain to the second participant may be that the service is available; when the initiation time of the target transaction is within the service time window of the first participant When the party's service time window is outside, the query result returned by the blockchain to the second party may be, for example, that the service is unavailable.

As an implementation method, the smart contract and time calculation can be combined, and the dynamic calculation of the service time window can be dynamically expanded and calculated by using the characteristics of the dynamic calculation of the smart contract to determine whether the initiation time of the target transaction is within the first participant's service between windows. Specifically, after the blockchain receives the second invocation request of the first smart contract from the second participant, it can dynamically expand the service time window of the first participant into time periods according to the initiation time of the target transaction, and judge the target Whether the initiation time of the transaction is within the time period, and then return the query result of the service time window of the first participant to the second participant according to the judgment result.

An example of the block chain judging whether the initiation time of the target transaction is within the service time window of the first participant is given below.

For example, when sending the second call request, the second participant can input the initiation time of the target transaction: 2021-07-18 15:00. After the block chain receives the second call request, it can first query the service time window of the first participant stored in the block chain, and then use the service time window of the first participant according to the initiation time of the input target transaction to expand. For example, the service time window of the first participant is queried as "services can be provided from 9:00-18:00 on weekdays or 12:00-20:00 on every Sunday", since the target transaction initiation time is 2021-07- 18 If this day falls on Sunday, the service time window on weekdays will not take effect. Then, according to the initiation time of the target transaction, the service time window of the first participant can be expanded to 2012-07-18 12:00-2021-07-18 20:00. After expanding the service time window of the first participant into a time period, the blockchain can automatically judge whether the initiation time of the target transaction is within this period after the service time window of the first participant is expanded, and send a report to the second party based on the judgment result. The second participant returns the query result of the service time window of the first participant. For example, in this example, if 2021-07-18 15:00 is within the period of 2012-07-18 12:00-2021-07-18 20:00, the query result of service availability can be returned to the second participant .

Before the second participant initiates the target transaction, he can first query the service time windows of all the first participants involved in the target transaction, and initiate the target transaction when the initiation time of the target transaction is within the service time windows of all first participants Transactions can avoid transaction congestion caused by the unavailability of the services of the first participant, thereby improving the timeliness of transaction processing on the chain.

In some embodiments, a second smart contract can also be deployed on the block chain, and the second smart contract can be used to execute the target transaction. The second smart contract may be, for example, a smart contract for a remittance transaction, or may be a smart contract for a rental transaction.

The second participant can send a first transaction execution request to the block chain, and the first transaction execution request can be used to request the first participant to execute the target transaction. The second participant can initiate the first transaction execution request by invoking the second smart contract.

For example, in the system architecture shown in FIG. 8, the second smart contract can be automatically associated with the first smart contract, so the second smart contract can call the first smart contract to query the service time window of the first participant. When the second participant initiates the first transaction execution request by calling the second smart contract, after the second smart contract receives the first transaction execution request, it can analyze the target transaction to confirm the participation of the first participant in the target transaction square. After the analysis of the first participant is completed, the second smart contract can directly call the first smart contract to check whether the initiation time of the first transaction execution request is within the service time window of the first participant. If the initiation of the first transaction execution request If the time is outside the service time window of the first participant, terminate the target transaction to avoid transaction blocking; if the initiation time of the first transaction execution request is within the service time window of the first participant, continue to advance the target transaction.

By automatically associating the second smart contract with the first smart contract, the second smart contract can directly call the first smart contract to query the service time window of the first participant, so that the service time window and the second smart contract on the chain can be automatically combination to further reduce user interaction costs.

The method embodiment of the present disclosure is described in detail above with reference to FIG. 1 to FIG. 8 , and the device embodiment of the present disclosure is described in detail below in conjunction with FIG. 9 to FIG. 11 . 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. 9 is a schematic structural diagram of a blockchain-based transaction processing device provided by an embodiment of the present disclosure. The transaction processing device 900 in FIG. 9 can be applied to a blockchain (or a node in a blockchain network). Wherein, a first smart contract is deployed on the block chain, and the first smart contract is used to manage the service time window of at least one of the multiple participants of the target transaction. The service time window of at least one participant is used to indicate the time when the at least one participant can participate in the target transaction. At least one participant includes a first participant, and the transaction processing apparatus 900 may include a first receiving unit 910 and a setting unit 920 . These units are described in detail below.

The first receiving unit 910 may be configured to receive a first call request of the first smart contract from the first participant, where the first call request is used to set the service time window of the first participant.

The setting unit 920 may be configured to set the service time window of the first participant according to the first call request.

Optionally, the multiple participants include a second participant, and the transaction processing apparatus 900 may further include a second receiving unit and a sending unit. The second receiving unit may be configured to receive a second call request of the first smart contract from the second participant, and the second call request is used to query the service time window of the first participant. The sending unit may be configured to send the query result of the service time window of the first participant to the second participant.

Optionally, the second call request includes the initiation time of the target transaction, and the query result is used to indicate whether the initiation time of the target transaction is within the service time window of the first participant.

Optionally, the multiple participants include the second participant, and the transaction processing apparatus 900 further includes a third receiving unit, a calling unit, and a terminating unit. The third receiving unit may be configured to receive a first transaction execution request from the second participant, where the first transaction execution request is used to request the first participant to execute the target transaction. The calling unit may be configured to call the first smart contract in response to the first transaction execution request to query whether the initiation time of the first transaction execution request is within the service time window of the first participant. The termination unit may be configured to terminate the target transaction if the initiation time of the first transaction execution request is outside the service time window of the first participant.

Optionally, a second smart contract is deployed on the block chain, and the second smart contract is used to execute the target transaction.

Optionally, the transaction processing device 900 further includes a first verification unit and a second verification unit. The first verification unit may be configured to verify the authority of the first participant. The second verification unit may be configured to verify the legality of the rule of the service time window of the first participant. The setting unit 920 may be further configured to set the service time window of the first participant in response to the authority and rule validity check being passed.

Optionally, the first call request includes the digital signature of the first participant, and the first verification unit may be further configured to verify the digital signature based on the public key of the first participant stored in the first smart contract. verification, wherein the public key is the public key corresponding to the private key used by the first participant to generate the digital signature.

Fig. 10 is a schematic structural diagram of a blockchain-based transaction processing device provided by another embodiment of the present disclosure. A first smart contract is deployed on the block chain, and the first smart contract is used to manage the service time window of at least one of the multiple participants of the target transaction. Wherein, the service time window of at least one participant is used to indicate the time when the at least one participant can participate in the target transaction. At least one participant includes the first participant, and the transaction processing apparatus 1000 in FIG. 10 can be applied to the first participant. The transaction processing device 1000 may include a sending unit 1010 . The sending unit 1010 will be described in detail below.

The sending unit 1010 may be configured to send a first call request of the first smart contract to the blockchain, where the first call request is used to set the service time window of the first participant.

Optionally, the first call request includes a digital signature of the first participant, and the digital signature is generated by the first participant using a private key.

Fig. 11 is a schematic structural diagram of a blockchain-based transaction processing device provided by another embodiment of the present disclosure. The transaction processing apparatus 1100 shown in FIG. 11 may be a computing device with computing functions, for example, the transaction processing apparatus 1100 may be a server. The transaction processor 1100 may include a memory 1110 and a processor 1120 . Memory 1110 may be used to store executable code. The processor 1120 can be used to execute the executable code stored in the memory 1110, so as to realize the steps in the various methods described above. In some embodiments, the transaction processing apparatus 1100 may further include a network interface 1130 through which data exchange between the processor 1120 and external devices may be realized.

In the foregoing embodiments, all or part may be implemented by software, hardware, firmware or other arbitrary combinations. 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 via 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 accessed 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 (such as a floppy disk, a hard disk, a magnetic tape), an optical medium (such as a digital video disc (Digital Video Disc, DVD)), or a semiconductor medium (such as a solid state disk (Solid State Disk, SSD)), etc. .

Those skilled in the art can appreciate that the units and algorithm steps of the examples described in conjunction with the embodiments of the present disclosure can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed by hardware or software depends on the specific application and design constraints of the technical solution. Skilled artisans may implement the described functionality using different methods for each particular application, but such implementation should not be considered beyond the scope of the present disclosure.

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 unit in each embodiment of the present disclosure may be integrated into one processing unit, each unit may exist separately physically, or two or more units may be integrated into one unit.

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 transaction processing method based on a block chain, where a first smart contract is deployed on the block chain, and the first smart contract is used to manage the service time window of at least one of the multiple participants of the target transaction , the service time window of the at least one participant is used to indicate the time when the at least one participant can participate in the target transaction, the at least one participant includes the first participant,

The methods include:

receiving a first invocation request of the first smart contract from the first participant, the first invocation request being used to set a service time window of the first participant;

Set the service time window of the first participant according to the first call request.
The method of claim 1, the plurality of parties comprising a second party,

The method also includes:

receiving a second call request of the first smart contract from the second participant, where the second call request is used to query the service time window of the first participant;

sending the query result of the service time window of the first participant to the second participant.
The method of claim 1, the plurality of parties comprising a second party,

The method also includes:

receiving a first transaction execution request from the second party, the first transaction execution request requesting the first party to execute the target transaction;

In response to the first transaction execution request, calling the first smart contract to query whether the initiation time of the first transaction execution request is within the service time window of the first participant;

If the initiation time of the first transaction execution request is outside the service time window of the first participant, the target transaction is terminated.
The method according to claim 2, wherein the second call request includes the initiation time of the target transaction, and the query result is used to indicate whether the initiation time of the target transaction is within the service time of the first participant window.
The method according to claim 4, after receiving the second invocation request of the first smart contract from the second participant, the method further comprises:

dynamically expand the service time window of the first participant into time periods according to the initiation time of the target transaction;

It is judged whether the initiation time of the target transaction is within the time period.
According to the method of claim 1, a second smart contract is deployed on the block chain, and the second smart contract is used to execute the target transaction.
The method according to claim 1, after receiving the first invocation request of the first smart contract from the first participant, the method further comprises:

Verifying the authority of the first participant;

Verifying the legitimacy of the rule of the service time window of the first participant;

The setting the service time window of the first participant according to the first call request includes:

In response to passing the validity check of the authority and the rule, setting a service time window of the first participant.
The method according to claim 7, wherein the first call request includes the digital signature of the first participant,

The verifying the authority of the first participant includes:

The digital signature is verified based on the public key of the first participant stored in the first smart contract, wherein the public key is used by the first participant to generate the digital signature The public key corresponding to the private key.
A transaction processing method based on a block chain, where a first smart contract is deployed on the block chain, and the first smart contract is used to manage the service time window of at least one of the multiple participants of the target transaction , the service time window of the at least one participant is used to indicate the time when the at least one participant can participate in the target transaction, the at least one participant includes the first participant, the method is applied to the first participants,

The methods include:

Sending a first call request of the first smart contract to the block chain, where the first call request is used to set a service time window of the first participant.
According to the method according to claim 9, a second smart contract is deployed on the block chain, and the second smart contract is used to execute the target transaction.
According to the method according to claim 9, the first call request includes the digital signature of the first participant, and the digital signature is generated by the first participant using a private key.
A block chain-based transaction processing device, the block chain is deployed with a first smart contract, the first smart contract is used to manage the service time window of at least one of the multiple participants in the target transaction , the service time window of the at least one participant is used to indicate the time when the at least one participant can participate in the target transaction, the at least one participant includes the first participant,

The devices include:

The first receiving unit is configured to receive a first call request of the first smart contract from the first participant, the first call request is used to set a service time window of the first participant;

A setting unit configured to set the service time window of the first participant according to the first call request.
The apparatus of claim 12, the plurality of participants comprising a second participant,

The device also includes:

The second receiving unit is configured to receive a second call request of the first smart contract from the second participant, the second call request is used to query the service time window of the first participant;

A sending unit configured to send the query result of the service time window of the first participant to the second participant.
The apparatus of claim 12, the plurality of participants comprising a second participant,

The device also includes:

A third receiving unit configured to receive a first transaction execution request from the second participant, the first transaction execution request being used to request the first participant to execute the target transaction;

The calling unit is configured to call the first smart contract in response to the first transaction execution request to query whether the initiation time of the first transaction execution request is within the service time window of the first participant;

A termination unit configured to terminate the target transaction if the initiation time of the first transaction execution request is outside the service time window of the first participant.
The device according to claim 13, wherein the second call request includes the initiation time of the target transaction, and the query result is used to indicate whether the initiation time of the target transaction is within the service time of the first participant window.
The apparatus of claim 15, further comprising:

The expansion unit is configured to dynamically expand the service time window of the first participant into time periods according to the initiation time of the target transaction;

A judging unit configured to judge whether the initiation time of the target transaction is within the time period.
The device according to claim 12, a second smart contract is deployed on the block chain, and the second smart contract is used to execute the target transaction.
The apparatus of claim 12, further comprising:

a first verification unit configured to verify the authority of the first participant;

The second verification unit is configured to verify the legality of the rules of the service time window of the first participant;

The setting unit is further configured to set the service time window of the first participant in response to passing the validity check of the authority and the rule.
The device according to claim 18, the first call request includes the digital signature of the first participant,

The first verification unit is further configured to verify the digital signature based on the public key of the first participant stored in the first smart contract, wherein the public key is the The public key corresponding to the private key used by the first participant to generate the digital signature.
A block chain-based transaction processing device, the block chain is deployed with a first smart contract, the first smart contract is used to manage the service time window of at least one of the multiple participants in the target transaction , the service time window of the at least one participant is used to indicate the time when the at least one participant can participate in the target transaction, the at least one participant includes the first participant, the device is applied to the first participants,

The devices include:

A sending unit configured to send a first call request of the first smart contract to the block chain, where the first call request is used to set a service time window of the first participant.
According to the transaction processing device according to claim 20, a second smart contract is deployed on the block chain, and the second smart contract is used to execute the target transaction.
The apparatus according to claim 20, wherein the first call request includes the digital signature of the first participant, and the digital signature is generated by the first participant using a private key.
A block chain-based transaction processing 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 any of claims 1-11 one of the methods described.