A method and system for reducing the number of times a blockchain transaction is chained by both parties of a transaction

Abstract

The application discloses a method and system for reducing the number of times of on-chain transactions of blockchain transactions between transaction parties, and the method comprises the following steps: a transaction payment party sends multiple iteration transactions to a transaction service party in sequence, each iteration transaction is a legal blockchain transaction, and the amount paid in the iteration transaction is the total amount of the amount to be paid up to the current iteration transaction; the multiple iteration transactions carry the same blockchain transaction serial number; when the end condition agreed by the transaction parties is met, the transaction service party uploads the last received iteration transaction to the blockchain. According to the application, the multiple transactions are collected by using the blockchain transaction serial number negotiated by the transaction parties, the transaction payment party does not send the transactions to the blockchain, but sends the transactions to the transaction service party for transaction collection, and when the end condition is met, the transaction service party uploads the last received iteration transaction to the blockchain, so that the multiple transactions of the transaction parties only need to perform one on-chain operation, and the number of times of on-chain transactions of the transaction parties is greatly reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchains, and particularly relates to a method and system for reducing the number of times of uploading blockchain transactions of transaction parties. BACKGROUND

[0002] Transaction parties use blockchain transactions to settle accounts or keep records. Since the transaction parties usually maintain a long transaction relationship to settle accounts or keep records for multiple times, they often conduct frequent transactions for a long time due to the characteristics of the transaction subject, such as to avoid the loss caused by a large transaction failure. The transaction parties usually conduct multiple transactions for a long time, and the amount of each transaction is controlled within the range of the loss that the transaction parties can accept. In the prior art, the payment party of a blockchain transaction uploads each transaction to a blockchain, and the payment amount in each transaction is only the payable amount of the transaction, and the payment to the transaction service party is realized through the blockchain. In the existing blockchain transaction mode, each transaction needs to be uploaded, but the uploading fee of the blockchain transaction is usually high, and the cumulative fee of frequent transaction uploading is considerable. SUMMARY

[0003] The present application solves the technical problems existing in the prior art and provides a method and system for reducing the number of times of uploading blockchain transactions of transaction parties.

[0004] To solve the above technical problems, the present application provides a method for reducing the number of times of uploading blockchain transactions of transaction parties, which comprises: a transaction payment party sends multiple iteration transactions to a transaction service party in sequence, each iteration transaction is a legal blockchain transaction, and the payment amount in the iteration transaction is the sum of the payable amounts up to the current iteration transaction; the multiple iteration transactions carry the same blockchain transaction serial number; and when the end condition agreed by the transaction parties is met, the transaction service party uploads the last received iteration transaction to a blockchain.

[0005] The present application has the beneficial effect that multiple transactions are collected by using the blockchain transaction serial number agreed by the transaction parties, that is, the transaction payment party does not directly send the transaction to the blockchain, but sends it to the transaction service party for transaction collection, and when the end condition is met, the transaction service party uploads the last received iteration transaction to the blockchain, that is, the multiple transactions of the transaction parties only perform one uploading operation, which greatly reduces the number of times of uploading transactions of the transaction parties, and since the transaction serial number information in the blockchain transaction has the anti-replay feature, the service party can avoid illegal profits caused by uploading multiple iteration transactions.

[0006] On the basis of the above technical solution, the present application can be further improved as follows.

[0007] Furthermore, the above technical solution also includes uploading the last received and correct iterative transaction to the blockchain when a payment anomaly occurs; wherein, the payment anomaly includes situations where the payer fails to pay within the time limit and situations where the payment amount within the iterative transaction is incorrect.

[0008] The beneficial effect of adopting the above-mentioned further solution is that when payment timeouts or payment amount errors occur in iterative transactions, the transaction service provider can upload the last received and normal iterative transaction to the blockchain to ensure that the transaction payer can obtain the payment amount accumulated in the corresponding iterative transaction in the event of payment anomalies.

[0009] Furthermore, the above technical solution also includes the transaction payer prepaying a margin to a preset account. When an on-chain anomaly occurs, the transaction service provider sends the last received and normal iterative transaction information to a preset processing flow, and uses the preset processing flow to transfer the margin in the preset account. The on-chain anomaly includes situations where there is already a transaction of the transaction payer on the blockchain and the blockchain transaction number is the same as that of the current iterative transaction, causing the current iterative transaction to fail to be uploaded to the blockchain.

[0010] The beneficial effect of adopting the above-mentioned further scheme is that the transaction payer prepays a security deposit to a preset account. If an anomaly occurs on the blockchain where the transaction payer already has a transaction with the same blockchain transaction number as the current iteration transaction, preventing the current iteration transaction from being uploaded to the blockchain, the transaction service provider can send the transaction to a preset processing flow such as a smart contract to claim the receivable amount. Optionally, the transaction payer can also be penalized. Since the iteration transaction contains the transaction payer's cryptographic signature, the transaction payer cannot deny the information contained in the iteration transaction. This collateral mechanism effectively prevents fraud and repudiation by the payer.

[0011] Furthermore, the above technical solution also includes that when the payment time agreed upon by both parties is prepayment for services / goods, the paying party will not send the corresponding iterative transaction to the service provider before receiving the physical service / goods.

[0012] The beneficial effect of adopting the above-mentioned further solution is that the transaction payer sends the transaction directly to the transaction service provider, and the transaction payer does not send the corresponding iterative transaction to the transaction service provider before receiving the physical service / goods. The transaction service provider can only obtain the payment amount for the services / goods that have been provided, but cannot obtain the payment amount for the services / goods that have not yet been provided. The above method can effectively avoid fraud and repudiation by the transaction service provider.

[0013] Furthermore, the above technical solution also includes that when the payment time agreed upon by both parties to the transaction is a prepayment, the transaction service provider will not send the ordered service / goods to the transaction payer before receiving the corresponding iterative transaction.

[0014] The beneficial effect of adopting the above-mentioned further solution is that after receiving the iterative transaction, the transaction service provider sends the physical service / goods corresponding to the iterative transaction. This iterative transaction represents the payer's payment commitment, and payment can be fulfilled once it is recorded on the blockchain. Even if there is an anomaly on the blockchain, information can be submitted to the preset processing flow to claim the amount due, which can effectively prevent fraud and repudiation by the transaction payer.

[0015] To address the aforementioned technical problems, this invention provides a system for reducing the number of blockchain transactions uploaded to the blockchain by both parties, comprising: a transaction payer, a transaction service provider, and a blockchain; the transaction payer is used to sequentially send multiple iterative transactions to the transaction service provider, each iterative transaction being a valid blockchain transaction, and the amount paid within each iterative transaction being the sum of the amounts due up to the current iterative transaction; the multiple iterative transactions carry the same blockchain transaction sequence number; the transaction service provider is used to upload the last received iterative transaction to the blockchain when the termination conditions agreed upon by both parties are met.

[0016] Based on the above technical solution, the present invention can be further improved as follows.

[0017] Furthermore, the transaction service provider is also used to upload the last received and correct iterative transaction to the blockchain when a payment anomaly occurs; wherein, the payment anomaly includes situations where the payer fails to pay within the time limit and situations where the payment amount within the iterative transaction is incorrect.

[0018] Furthermore, the transaction payer is also used to prepay a margin to a preset account. When an on-chain anomaly occurs, the transaction service provider sends the last received and normal iterative transaction to a preset processing flow, and uses the preset processing flow to transfer the margin in the preset account. The on-chain anomaly includes situations where there is already a transaction of the transaction payer on the blockchain and the blockchain transaction number is the same as that of the current iterative transaction, causing the current iterative transaction to fail to be uploaded to the blockchain.

[0019] Furthermore, the above technical solution also includes that when the payment time agreed upon by both parties is prepayment for services / goods, the paying party will not send the corresponding iterative transaction to the service provider before receiving the physical service / goods.

[0020] Furthermore, the above technical solution also includes that when the payment time agreed upon by both parties to the transaction is a prepayment, the transaction service provider will not send the ordered service / goods to the transaction payer before receiving the corresponding iterative transaction.

[0021] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating a method for reducing the number of blockchain transactions between the transacting parties, as provided in an embodiment of the present invention.

[0023] Figure 2 This is a system block diagram for reducing the number of blockchain transactions between the transacting parties, as provided in an embodiment of the present invention. Detailed Implementation

[0024] The following specific examples illustrate the implementation of this disclosure. Those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0025] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0026] Figure 1 This is a flowchart illustrating a method for reducing the number of blockchain transactions between trading parties, provided in an embodiment of the present invention. Figure 1 As shown, the method includes:

[0027] S110, the transaction payer sequentially sends multiple iterative transactions to the transaction service provider. Each iterative transaction is a valid blockchain transaction, and the amount paid in each iterative transaction is the sum of the amounts due up to the current iterative transaction. The multiple iterative transactions carry the same blockchain transaction sequence number.

[0028] Blockchain transactions typically include an incrementing transaction sequence number parameter belonging to the payer, such as the payer nonce information in Ethereum transactions. This nonce identifies which transaction the payer belongs to, preventing duplicate or out-of-order transactions. This number monotonically increases, and the verification of transactions on the blockchain is strictly performed sequentially. For example, a transaction with a blockchain transaction sequence number of 2 cannot be confirmed by the blockchain before a transaction with a blockchain transaction sequence number of 1. Furthermore, if multiple blockchain transactions with the same sequence number of 2 have not been recorded on the blockchain, recording one of these transactions will prevent the other blockchain transactions with the same sequence number of 2 from being recorded. This invention can utilize the transaction sequence number parameter of the payer's blockchain account, agreed upon by both parties, to aggregate multiple transactions between them.

[0029] Each iterative transaction is a legitimate transaction on the blockchain, meaning that each iterative transaction possesses the signature, information integrity, and non-repudiation protection features required by blockchain exchanges for the payer's corresponding account. In this embodiment of the invention, an iterative transaction refers to a blockchain transaction whose sending source account is the payer, carrying the same blockchain transaction sequence number and whose payment amount is the sum of the amounts due up to the current iterative transaction.

[0030] In existing technologies, each blockchain transaction used for payment must be uploaded to the blockchain, i.e., the transaction is recorded on the chain. The payment amount in each transaction is only the amount due for that specific transaction, and payment to the transaction service provider is made through the blockchain. For example, if the payer and the service provider need to conduct three transactions, each with a payment amount of 1 yuan, then using the existing transaction method, the payer will send three blockchain transactions, each with a payment amount of 1 yuan, to the blockchain. Regardless of whether the transactions are uploaded by the payer itself or by the service provider or other parties, the number of times the transaction is recorded on the chain is three.

[0031] In this embodiment of the invention, to reduce the number of times transactions are recorded on the blockchain, the payer does not directly record the transaction on the blockchain. Instead, the payer sends the transaction to the service provider through iterative transactions, with each iterative transaction containing the total amount due up to the current iteration. For example, the payer sends three iterative transactions to the service provider: the first iterative transaction carries a payment of 1 yuan; the second iterative transaction carries a payment of 2 yuan; and the third iterative transaction carries a payment of 3 yuan. The service provider, upon determining the end of the iterative transactions according to the agreed-upon termination conditions, uploads the third iterative transaction to the blockchain. In other words, this embodiment of the invention achieves the same effect as multiple on-chain operations in the prior art with only a single on-chain operation.

[0032] Furthermore, the amount of each transaction can be different. For example, if the payer and service provider need to conduct three transactions, each with a different amount payable: 2 yuan, 1 yuan, and 5 yuan respectively, then using existing transaction methods, the payer would upload the payment to the blockchain in three separate transactions, i.e., three on-chain transactions. Using this patented technology, the payer sends three iterative transactions to the service provider: the first payment is 2 yuan, the second is 3 yuan, and the third is 8 yuan. Upon receiving these, the service provider only uploads the last iterative transaction to the blockchain, thus receiving a total of 8 yuan.

[0033] S120, when the termination conditions agreed upon by both parties to the transaction are met, the transaction service provider uploads the last received iterative transaction to the blockchain.

[0034] The two parties to the transaction agree on termination conditions based on the characteristics of different services / goods, such as the cyclical or incremental characteristics of the services / goods. Termination conditions can be set based on the total duration of continuous transactions, the total amount of money involved, the total number of transactions, or a certain period of waiting without any new transactions, or a combination of these conditions.

[0035] This invention utilizes a blockchain transaction sequence number negotiated by both parties to aggregate multiple transactions. That is, the transaction payer does not send the transaction directly to the blockchain, but sends it to the transaction service provider for transaction aggregation. When the termination condition is met, the transaction service provider uploads the last received iterative transaction to the blockchain. In other words, multiple transactions between the two parties only undergo one on-chain operation, which greatly reduces the number of times the transactions are uploaded to the blockchain.

[0036] Optionally, based on the above embodiments, the method for reducing the number of blockchain transactions between the two parties provided by the present invention further includes, when a payment anomaly occurs, the transaction service provider uploading the last received and correct iterative transaction to the blockchain; wherein, the payment anomaly includes situations where the payer fails to pay within the timeout period and situations where the payment amount within the iterative transaction is incorrect.

[0037] Both parties to a transaction can agree on a payment timeout for each product / service. For example, they can agree on a payment timeout duration, stipulating that the payer should send an iterative transaction to pay for the corresponding product / service within a certain timeframe. If no iterative transaction is sent within this agreed time, it is considered a payment timeout. Alternatively, they can agree to send an iterative transaction to complete payment before the next product / service is offered. If payment for the previous product / service is not completed when the next product / service begins to be offered, it is considered a payment timeout. For instance, if the payment for the last product / service times out, and the service provider has already received the iterative transaction for the previous last product / service, submitting this iterative transaction will allow them to receive the accumulated payment amounts for all products / services except the last one.

[0038] When a payment anomaly occurs, the transaction service provider uploads the last received and valid iterative transaction to the blockchain. For example, if the payer fails to pay within the timeout period for the 5th iterative transaction, the transaction service provider can upload the received 4th iterative transaction to the blockchain. Another example: if the 8th iterative transaction is the last iterative transaction, but the 8th iterative transaction itself contains an error (e.g., incorrect payment amount, but an incorrect transaction sequence number, which should be considered as not received because iterative transactions require consistent blockchain transaction sequences), then the transaction service provider can upload the 7th iterative transaction to the blockchain.

[0039] This invention can also set a payment anomaly tolerance level i (i is a positive integer greater than 1) for each service / product based on its characteristics. Typically, i is set to 1, meaning the transaction terminates upon the occurrence of one payment anomaly. However, it can be set to other values ​​as needed. For example, i = 2 allows for two incorrect iterative transactions. When a payment anomaly occurs, the transaction service provider submits the last valid and correct iterative transaction received to the blockchain. For instance, after the payer sends the third iterative transaction, no further iterative transactions are sent. Then, the service provider sends the fourth and fifth goods / services. If, before the service provider prepares to send the sixth goods / service, it has not yet received a valid fourth iterative transaction, the service provider ends the current iteration process and records the third iterative transaction on the blockchain to obtain revenue, or, if unable to record it on the blockchain, claims the revenue due from the pre-defined processing flow.

[0040] In this embodiment of the invention, when payment timeouts or payment amount errors occur within an iterative transaction, the transaction service provider can upload the last received and normal iterative transaction to the blockchain to ensure that the transaction payer can obtain the corresponding payment amount in the event of a payment anomaly.

[0041] Optionally, based on the above embodiments, the method for recording the number of blockchain transactions between the two parties provided in this embodiment of the invention further includes the transaction payer prepaying a margin to a preset account. When an on-chain anomaly occurs, the transaction service provider sends the last received and normal iterative transaction information to a preset processing flow. That is, the service provider sends a transaction to the preset processing flow for retrieval processing, wherein the corresponding complete iterative transaction is submitted as supplementary information in the transaction. In this way, the preset processing flow can use blockchain tools to sign the iterative transaction, verify the corresponding account, and verify the payment amount. The preset processing flow then uses the margin in the preset account to transfer funds. The on-chain anomaly includes situations where there is already a transaction on the blockchain with the same blockchain transaction number as the current iterative transaction from the transaction payer, causing the current iterative transaction to fail to be recorded on the blockchain.

[0042] A malicious transaction occurs when a payer sends a transaction to another account using the blockchain transaction number of the current iteration transaction. Malicious transactions can undermine the validity of the current transaction. If a malicious transaction is confirmed on the blockchain before the current transaction, the current transaction becomes invalid, and the transaction service provider cannot receive the payment from the payer. For example, if account A and account B are conducting an iteration transaction using blockchain transaction number 2, and during the transaction, account A sends a blockchain transaction using blockchain transaction number 2 to account C, and account C uploads that transaction to the blockchain, or account A directly uploads the blockchain transaction with blockchain transaction number 2 to the blockchain, then account B's iteration transaction with blockchain transaction number 2 cannot be uploaded to the blockchain, resulting in an on-chain anomaly.

[0043] This invention provides a collateral mechanism whereby the transaction payer prepays a margin to a pre-set account. In the event of an on-chain anomaly, the transaction service provider can send the last received, valid iterative transaction as additional transaction information to a pre-set processing flow (which may be a smart contract). The pre-set processing flow then uses this margin to reclaim the owed amount. The pre-set processing flow verifies and confirms the authenticity of the payer's account signature, the completeness of the information, and the payment amount within the iterative transaction based on the complete original iterative transaction information submitted by the service provider. Optionally, it can also penalize the transaction payer. Furthermore, since iterative transactions are also blockchain transactions, they include the payer's signature and are protected for the integrity of the transaction information, making it impossible for the payer to deny the transaction. This collateral mechanism effectively prevents fraud and repudiation by the payer.

[0044] Both parties in a transaction can synchronize payment methods for each product / service. Payment remains the same as before; this embodiment of the invention does not change the payment method, but both parties need to be aware of the payment method for each transaction. For example, according to conventional payment habits: if A buys bananas from store B and needs to pay 1 unit, an iterative transaction is submitted. If A then buys apples from store B and needs to pay 5 units, an updated iterative transaction needs to be submitted. Alternatively, a service charged by time can be implemented, where both parties agree to iterative transaction payments at equal intervals. Another option is a service charged by quantity, where a new iterative transaction payment is made after a certain number of service uses.

[0045] The two parties to the transaction can agree on the timing of payment for each good / service. The timing of payment can be either prepayment or prepayment for the good / service, and the choice needs to be made based on the specific implementation or left to the two parties to choose.

[0046] Optionally, based on the above embodiments, the method for reducing the number of blockchain transactions between the two parties provided by the embodiments of the present invention further includes that when the payment time agreed upon by the two parties is prepayment for services / goods, the payment party does not send the corresponding iterative transaction to the service provider before receiving the physical service / goods.

[0047] In this embodiment of the invention, the transaction payer sends the transaction directly to the transaction service provider, and the transaction payer does not send the corresponding iterative transaction to the transaction service provider before receiving the physical service / goods. The transaction service provider can only obtain the payment amount for the services / goods already provided, but cannot obtain the payment amount for the services / goods that have not yet been provided. The above method can effectively avoid fraud and repudiation by the transaction service provider.

[0048] Optionally, based on the above embodiments, the method for reducing the number of blockchain transactions between the two parties provided by the present invention further includes that when the payment time agreed upon by the two parties is a prepayment, the transaction service provider does not send the ordered service / goods to the transaction payer before receiving the iterative transaction corresponding to the ordered service / goods.

[0049] In this embodiment of the invention, after receiving the iterative transaction, the transaction service provider sends the physical service / goods corresponding to the iterative transaction. This iterative transaction represents the payer's payment commitment, and payment can be fulfilled once it is recorded on the blockchain. Even if there is an anomaly on the blockchain, information can be submitted to a preset processing procedure to claim the amount due, which can effectively prevent fraud and repudiation by the transaction payer.

[0050] The following specific example illustrates the method of the present invention for reducing the number of blockchain transactions between the two parties.

[0051] Let Tab(i) represent a transaction sent from account A to account B, where i represents the transaction sequence number. For example, the second transaction of account A is denoted as Tab(2).

[0052] Typically, account A needs to send multiple transactions to account B. Without loss of generality, let's assume account A's current transaction sequence number is 2. Taking sending 3 transactions as an example, account A needs to send 3 transactions to the blockchain: Tab(2), Tab(3), and Tab(4). Assuming each transaction contains a transfer of 1 yuan, a total of 3 yuan will be sent.

[0053] When using the method provided in this embodiment of the invention to reduce the number of blockchain transactions between the transacting parties, when A sends the first iterative transaction to B, the blockchain transaction number is 2, and the payment amount is the payment amount corresponding to Tab(2), i.e., the payment amount is 1 yuan; when A sends the second iterative transaction to B, the blockchain transaction number is also 2, and the payment amount is the sum of the amount due up to the current transaction, i.e., the sum of the transaction amounts of Tab(2) and Tab(3), i.e., the payment amount is 2 yuan; when A sends the third iterative transaction to B, the blockchain transaction number is also 2, and the payment amount is the sum of the amount due up to the current transaction, i.e., the sum of the transaction amounts of Tab(2), Tab(3), and Tab(4), i.e., the payment amount is 3 yuan. When B receives 3 transactions and finds that the agreed end conditions of this round have been met, it puts the last iterative transaction sent by A on the blockchain. In this embodiment of the invention, A does not send transactions to the blockchain, but sends iterative transactions to B, which can effectively avoid putting every transaction on the blockchain and greatly reduce the number of times it is put on the blockchain.

[0054] This invention effectively avoids multiple transactions being recorded on the blockchain. Since A sends a transaction to B, B only needs the last transaction recorded on the blockchain to receive the equivalent transfer amount. Therefore, B cannot gain additional benefits from recording multiple transactions sent by A on the blockchain, and thus has no incentive to record intermediate transactions. This is because if B records intermediate transactions (usually meaning those confirmed by the blockchain), then, due to the same transaction sequence number, subsequent transactions sent by A cannot be confirmed by B through the blockchain. B, having provided more goods / services, would not receive the due payment.

[0055] Handling of payment party repudiation: This embodiment of the invention designs a collateral mechanism, such as a smart contract. First, A sends a deposit to the smart contract. When A and B conduct iterative transactions and a malicious transaction occurs, B can send the iterative transaction sent to him by A as supplementary information in the transaction to the smart contract to claim the amount due. At the same time, optional, A can be punished.

[0056] To prevent service providers from committing fraud or denying payment, the payer will not send new iterative transactions until the physical service / goods have been received.

[0057] like Figure 2 As shown, this embodiment of the invention provides a system for reducing the number of blockchain transactions uploaded to the blockchain by both parties, including: a transaction payer, a transaction service provider, and a blockchain; the transaction payer is used to send multiple iterative transactions to the transaction service provider in sequence, each of the iterative transactions being a valid blockchain transaction, and the amount paid in each iterative transaction being the sum of the amounts due up to the current iterative transaction; the multiple iterative transactions carry the same blockchain transaction sequence number; the transaction service provider is used to upload the last received iterative transaction to the blockchain when the termination conditions agreed upon by both parties are met.

[0058] Optionally, the transaction service provider is also used to upload the last received and correct iterative transaction to the blockchain when a payment anomaly occurs; wherein the payment anomaly includes situations where the payer fails to pay within the time limit and situations where the payment amount within the iterative transaction is incorrect.

[0059] Optionally, the transaction payer is also used to prepay a margin to a preset account. When an on-chain anomaly occurs, the transaction service provider sends the last received and normal iterative transaction to a preset processing flow, and uses the preset processing flow to transfer the margin in the preset account. The on-chain anomaly includes situations where there is already a transaction of the transaction payer on the blockchain and the blockchain transaction number is the same as that of the current iterative transaction, causing the current iterative transaction to fail to be uploaded to the blockchain.

[0060] Optionally, when the payment timing agreed upon by both parties is prepayment for services / goods, the paying party will not send the corresponding iterative transaction to the service provider before receiving the physical service / goods.

[0061] Optionally, when the payment time agreed upon by both parties is a prepayment, the transaction service provider shall not send the ordered service / goods to the transaction payer before receiving the corresponding iterative transaction.

[0062] In this embodiment of the invention, each iterative transaction is a legitimate transaction on the blockchain, carrying the same blockchain transaction sequence number. This number is temporarily collected by the transaction service provider until the service ends or a payment anomaly occurs, and then submitted to the blockchain to ensure that only one iterative transaction can be legitimately uploaded to the blockchain. Alternatively, in the event of an upload anomaly, it can be submitted as additional information to a predetermined processing flow / smart contract by the service provider to claim the owed amount.

[0063] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for reducing the number of blockchain transactions between transacting parties, characterized in that, include: The transaction payer sends multiple iterative transactions to the transaction service provider in sequence. Each iterative transaction is a legitimate blockchain transaction, and the amount paid in each iterative transaction is the sum of the amounts due up to the current iterative transaction. Multiple iterative transactions carry the same blockchain transaction sequence number; When the termination conditions agreed upon by both parties to the transaction are met, the transaction service provider will upload the last received iterative transaction to the blockchain; This also includes ensuring that, in the event of a payment anomaly, the transaction service provider uploads the last received and correct iterative transaction to the blockchain. The payment anomalies include situations where the payer fails to make payment within the time limit and situations where the payment amount is incorrect within the iterative transaction. It also includes the transaction payer prepaying a margin to a preset account. When an on-chain anomaly occurs, the transaction service provider sends the last received and normal iterative transaction information to a preset processing flow, and uses the preset processing flow to operate the margin in the preset account for transfer. The abnormal on-chain situation includes situations where there is already a transaction on the blockchain with the same blockchain transaction number as the transaction in this iteration, which prevents the transaction in this iteration from being uploaded to the blockchain.

2. The method according to claim 1, characterized in that, This also includes the provision that when the payment time agreed upon by both parties is for prepaid services / goods, the paying party will not send the corresponding iterative transaction to the service provider before receiving the physical service / goods.

3. The method according to claim 1, characterized in that, This also includes the provision that when the payment time agreed upon by both parties is a prepayment, the service provider will not send the ordered service / goods to the payer before receiving the corresponding iterative transaction.

4. A system for reducing the number of blockchain transactions between transacting parties, characterized in that, include: Transaction payers, transaction service providers, and blockchain; The transaction payer is used to send multiple iterative transactions to the transaction service provider in sequence. Each iterative transaction is a legitimate blockchain transaction, and the amount paid in the iterative transaction is the sum of the amounts due up to the current iterative transaction. Multiple iterative transactions carry the same blockchain transaction sequence number; The transaction service provider is used to upload the last received iterative transaction to the blockchain when the termination conditions agreed upon by both parties to the transaction are met. The transaction service provider is also used to upload the last received and correct iterative transaction to the blockchain when a payment anomaly occurs. The transaction payer is also used to prepay a margin to a preset account. When an on-chain anomaly occurs, the transaction service provider sends the last received and normal iterative transaction to a preset processing flow, and uses the preset processing flow to transfer the margin in the preset account. The abnormal on-chain situation includes situations where there is already a transaction on the blockchain by the payment party and the blockchain transaction number is the same as that of the transaction in this iteration, which causes the transaction in this iteration to fail to be uploaded to the blockchain.

5. The system according to claim 4, characterized in that, This also includes the provision that when the payment time agreed upon by both parties is for prepaid services / goods, the paying party will not send the corresponding iterative transaction to the service provider before receiving the physical service / goods.

6. The system according to claim 4, characterized in that, This also includes the provision that when the payment time agreed upon by both parties is a prepayment, the service provider will not send the ordered service / goods to the payer before receiving the corresponding iterative transaction.

Images