Method and apparatus for on-chain transaction data

Abstract

Embodiments of the present specification provide a method and device for on-chain transaction data. In the method, transaction data is generated; the generation time of the transaction data is determined; the on-chain trigger time corresponding to the transaction data is obtained according to the generation time; wherein the on-chain trigger times of different transaction data are not completely the same; the on-chain trigger time is carried in the corresponding transaction data and sent to the outside; the outside judges whether the current transaction data is uploaded to the block chain according to the on-chain trigger time carried in each transaction data, if yes, the transaction data is uploaded to the block chain. The method of the present specification can solve the problem of high concurrency access to the block chain.

Description

Technical Field

[0001] This specification relates to network information technology, and more particularly to methods and apparatus for uploading transaction data to the blockchain. Background Technology

[0002] Blockchain is an innovative technology combining distributed data storage, smart contracts, consensus mechanisms, and cryptographic algorithms. Its core mechanism leverages mathematical principles, rather than third parties, to create a new, trustworthy computing paradigm and collaboration model at low cost in an untrusted competitive environment. As a distributed ledger technology maintained by multiple parties, it features openness, tamper-proofness, anonymity, decentralization, and traceability, significantly expanding the breadth and depth of human collaboration.

[0003] In many business sectors, transaction data is uploaded to the blockchain for on-chain notarization. Currently, the method for uploading transactions to the blockchain is to upload the transaction data as soon as the transaction approver generates it. However, transaction approvers may generate a large amount of transaction data simultaneously within a short period, resulting in a high concurrency of access to the blockchain due to the need to upload a large amount of transaction data in a short time. Summary of the Invention

[0004] This specification describes one or more embodiments of a method and apparatus for uploading transaction data to the blockchain, which solves the problem of high-concurrency access when uploading transaction data to the blockchain.

[0005] Based on the first aspect, a method for uploading transaction data to the blockchain is provided, wherein...

[0006] Generate transaction data;

[0007] Determine when the transaction data was generated;

[0008] The on-chain trigger time corresponding to the transaction data is obtained based on the generation time; however, the on-chain trigger times for different transaction data are not exactly the same.

[0009] The on-chain trigger time is carried in the corresponding transaction data and sent to the outside for on-chain processing.

[0010] The step of obtaining the on-chain trigger time corresponding to the transaction data based on the generation time includes:

[0011] Obtain the first duration corresponding to the transaction data; wherein, the first duration is a time length value within a preset duration range, and the first duration of different transaction data is not exactly the same;

[0012] Add a first duration to the generation time to obtain the on-chain trigger time corresponding to the transaction data.

[0013] The step of obtaining the first duration corresponding to the transaction data includes: generating a random value within a preset duration range, and using the random value as the first duration corresponding to the transaction data.

[0014] The transaction approver shall execute the step of sending the on-chain time along with the corresponding transaction data to the outside world;

[0015] The external component includes an on-chain proxy device positioned between the blockchain and the transaction approval party.

[0016] According to the second aspect, a method for uploading transaction data to the blockchain is provided, which includes:

[0017] Receive transaction data;

[0018] Store the received transaction data;

[0019] Based on the on-chain trigger time carried in each stored transaction data, it is determined whether to upload the transaction data to the blockchain. The on-chain trigger times carried in different transaction data are not exactly the same.

[0020] If so, the transaction data will be uploaded to the blockchain.

[0021] The process, which occurs after receiving the transaction data and before storing the received transaction data, further includes:

[0022] Based on the on-chain trigger time carried in the currently received transaction data, determine whether to upload the transaction data to the blockchain. If yes, upload the transaction data to the blockchain; otherwise, execute the step of storing the received transaction data.

[0023] The determination of whether to upload the transaction data to the blockchain includes:

[0024] Determine if the on-chain trigger time carried in the transaction data is no later than the current time. If it is not later, determine that the transaction data should be uploaded to the blockchain now; otherwise, determine that the transaction data should not be uploaded to the blockchain now.

[0025] Specifically, every preset query duration period, the step of determining whether to upload the transaction data to the blockchain based on the on-chain trigger time carried in each stored transaction data is executed.

[0026] According to the third aspect, a device for uploading transaction data to the blockchain is provided, including:

[0027] The transaction data generation module is configured to generate transaction data.

[0028] The on-chain trigger time determination module is configured to determine the generation time of the transaction data; and obtain the on-chain trigger time corresponding to the transaction data based on the generation time; wherein the on-chain trigger times of different transaction data are not exactly the same;

[0029] The transaction data sending module is configured to send the on-chain trigger time along with the corresponding transaction data to an external entity for on-chain processing.

[0030] According to the fourth aspect, a device for uploading transaction data to the blockchain is provided, including:

[0031] The transaction data receiving module is configured to receive transaction data.

[0032] The transaction data storage module is configured to store received transaction data;

[0033] The on-chain processing module is configured to determine whether to upload the transaction data to the blockchain based on the on-chain trigger time carried in each stored transaction data. If so, the transaction data is uploaded to the blockchain.

[0034] According to a fifth aspect, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method described in any embodiment of this specification.

[0035] In the method and apparatus for uploading transaction data to the blockchain provided in the embodiments of this specification, when a transaction approver generates a transaction, it does not include the transaction's generation time in the transaction data. Instead, it first obtains the blockchain uploading trigger time based on the transaction's generation time, and then includes the blockchain uploading trigger time in the transaction data. Because the blockchain uploading trigger times obtained for different transaction data are not exactly the same, even if the transaction approver generates a large amount of transaction data simultaneously, it will not include the same transaction generation time in the large amount of transaction data, but rather carry slightly different blockchain uploading trigger times. Subsequently, when uploading this large amount of transaction data to the blockchain based on these slightly different blockchain uploading trigger times, the problem of high-concurrency access to the blockchain will not occur. It can be seen that the embodiments of this specification have performed peak smoothing processing of blockchain access, making the access time to the blockchain more balanced. Attached Figure Description

[0036] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0037] Figure 1 This is a flowchart of a financial leasing business using existing technology.

[0038] Figure 2 This is a schematic diagram of the system architecture used in one embodiment of this specification.

[0039] Figure 3 This is a schematic diagram of the system architecture used in a financial leasing business according to one embodiment of this specification.

[0040] Figure 4 This is a flowchart of a method for processing transaction data on the blockchain by the transaction approver in one embodiment of this specification.

[0041] Figure 5 This is a flowchart of a method for processing transaction data on-chain by an on-chain proxy device in one embodiment of this specification.

[0042] Figure 6 This is a flowchart of a transaction data uploading method executed by a blockchain, a transaction approver, and an on-chain agent device in one embodiment of this specification.

[0043] Figure 7 This is a schematic diagram of the structure of a transaction data uploading device in one embodiment of this specification.

[0044] Figure 8 This is a schematic diagram of the transaction data uploading device in another embodiment of this specification. Detailed Implementation

[0045] As mentioned earlier, in existing technologies, transaction approvers may generate a large amount of transaction data at the same time, resulting in a large amount of transaction data needing to be uploaded to the blockchain simultaneously, causing a problem of high-concurrency access to the blockchain.

[0046] For example, see Figure 1In financial leasing, the lessee is the transaction requester, and the funder is the transaction approver. Lessees 1 through N need to apply for loans from the funder, where N is a positive integer greater than 1. The loan transaction data needs to be uploaded to the blockchain for record-keeping. The timing of loan applications from different lessees is randomly distributed; for example, a lessee might apply for a loan from the funder on any day of the week. However, the funder's lending activity occurs at fixed times. For instance, the funder might process all loan applications from all lessees in the previous week at a fixed time, such as 10:00 AM every Monday. If N is 10,000, meaning there are 10,000 loan applications, the funder simultaneously generates transaction data for 10,000 loan applications. This 10,000 loan transaction data needs to be uploaded to the blockchain simultaneously, resulting in high concurrency access to the blockchain and placing extremely high demands on server processing performance and network bandwidth.

[0047] For financial leasing transactions like those mentioned above, the access time to the blockchain is uneven. For example, during the time when the funding party is lending and generating transaction data, the access volume to the blockchain is too high, leading to high concurrency issues. Conversely, during the time when the funding party is not lending and no transaction data is generated, the access volume to the blockchain is too low. Therefore, this application considers implementing peak-shaving processing for blockchain access to achieve a more balanced access time.

[0048] To facilitate understanding of the methods provided in this manual, the system architecture involved and applicable to this manual is first described. For example... Figure 2 As shown, the system architecture mainly includes four business roles: blockchain, on-chain agent, transaction approver, and transaction requester.

[0049] In this context, the transaction requester is the party that requests to conduct the transaction, for example, see [link to relevant documentation]. Figure 3 The party requesting the transaction can be the aforementioned lessor, and the party approving the transaction is the one that can generate the transaction data that needs to be uploaded to the blockchain, such as see [reference needed]. Figure 3 The transaction approver can be any of the aforementioned funding providers capable of offering loans. The on-chain proxy device is positioned between the blockchain and the transaction approver, acting as an intermediary to upload the transaction data from the approver to the blockchain. This on-chain proxy device can be located in a device independent of both the blockchain and the transaction approver, such as in a dedicated blockchain transaction cache center; alternatively, it can also be located within the transaction approver itself.

[0050] It should be understood that Figure 2 The number of transaction requesters, blockchains, on-chain proxy devices, and transaction approvers shown in the diagram is merely illustrative. Any number can be selected and deployed as needed for implementation.

[0051] The transaction requester, the blockchain, the on-chain proxy device, and the transaction approver interact through a network. This network can include various connection types, such as wired or wireless communication links or fiber optic cables.

[0052] The changes to the transaction data on-chain method provided in the embodiments of this specification compared to existing technical methods mainly involve... Figure 2 The two business roles shown are the on-chain agent and the transaction approver. Therefore, the following describes the processing of transaction data on the blockchain by the on-chain agent and the transaction approver through different embodiments.

[0053] First, let's explain the process by which the transaction approver handles the transaction data during the on-chain process.

[0054] Figure 4 This is a flowchart illustrating a method used by the transaction approver during the on-chain processing of transaction data, as described in one embodiment of this specification. The entity executing this method is the transaction approver, such as the funding party mentioned above. It is understood that this method can also be executed by any device, equipment, platform, or cluster of devices with computing and processing capabilities. See also... Figure 4 The method includes:

[0055] Step 401: The transaction approver generates transaction data.

[0056] Step 403: The transaction approver determines the time when the transaction data is generated.

[0057] Step 405: The transaction approver obtains the on-chain trigger time corresponding to the transaction data based on the generation time; however, the on-chain trigger times for different transaction data are not exactly the same.

[0058] Step 407: The transaction approver sends the on-chain trigger time along with the corresponding transaction data to the external party for on-chain processing.

[0059] It can be seen that in the above Figure 4In the process illustrated, when a transaction approver generates a transaction, it does not include the transaction's generation time in the transaction data. Instead, it first obtains the on-chain trigger time based on the transaction's generation time, and then includes this trigger time in the transaction data. Because the on-chain trigger times obtained for different transaction data are not entirely the same, even if the transaction approver generates a large number of transaction data, such as 10,000 transactions, at the same generation time, these 10,000 transactions will not carry the same generation time, but rather carry slightly different on-chain trigger times. Subsequently, when these 10,000 transactions are uploaded to the blockchain based on these slightly different on-chain trigger times, the problem of high-concurrency access to the blockchain will not occur. Therefore, the method in this embodiment performs peak-shaving processing of blockchain access, resulting in a more balanced access time to the blockchain.

[0060] The following will illustrate this with specific examples. Figure 4 Each step in the process will be explained separately.

[0061] First, in step 401, the transaction approver generates transaction data.

[0062] In the embodiments of this specification, transaction data can be any type of business data that requires centralized approval, such as salary data when a company needs to pay salaries in a centralized manner, approval document data that an approval authority needs to issue in a centralized manner, or loan disbursement data in the aforementioned financial leasing business, etc.

[0063] The transaction approver typically generates the required transaction data for that period at regular intervals. Taking financial leasing as an example, the transaction adjudicator, i.e., the funding party, generates transaction data for all loans applied for by each lessee in the previous week every Monday at 10:00 AM.

[0064] Next, in step 403, the transaction approver determines the time when the transaction data was generated.

[0065] For example, the transaction data was generated by the current transaction approver at 10:00 AM on December 6, 2021.

[0066] Next, in step 405, the transaction approver obtains the on-chain trigger time corresponding to the transaction data based on the generation time; the on-chain trigger times for different transaction data are not exactly the same.

[0067] For example, taking financial leasing as an example, the transaction approver, i.e., the funding party, generates 10,000 transaction data entries for 10,000 loan applications submitted by lessee 1 to lessee N. The generation time for each of these 10,000 transaction data entries is 10:00 AM on December 6, 2021. The transaction approver will then generate 10,000 on-chain trigger times for each of these 10,000 transaction data entries; these 10,000 on-chain trigger times are not entirely identical.

[0068] In one embodiment of this specification, the specific implementation process of step 405 includes:

[0069] Step 4051: The transaction approver obtains the first duration corresponding to the transaction data; wherein, the first duration is a time length value within a preset duration range, and the first duration of different transaction data is not exactly the same;

[0070] Step 4053: The transaction approver adds a first duration to the generation time to obtain the on-chain trigger time corresponding to the transaction data.

[0071] Specifically, step 4051 can be implemented using a random number generator. In this case, step 4051 includes: the transaction approver generating a random value within a preset time range and using the random value as the first time range corresponding to the transaction data.

[0072] The aforementioned preset duration range can be determined based on the amount of transaction data generated and / or the acceptable time adjustment range. For example, if the amount of transaction data generated is too large and the acceptable time adjustment range is too long, the transaction data can be distributed over a longer period of time, such as within one day. In this case, the preset duration range is 24 hours, and the range of random values ​​is greater than 0 and less than or equal to 24 hours. Alternatively, if the amount of transaction data generated is not too large and the acceptable time adjustment range is too short, the transaction data can be distributed over a relatively short period of time, such as within 1 hour. In this case, the preset duration range is 1 hour, and the range of random values ​​is greater than 0 and less than or equal to 1 hour.

[0073] For example, suppose there are 10,000 transaction records, all generated at 10:00 AM on December 6, 2021, with a preset duration of 1 hour. For transaction data 1, if the transaction approver generates a random value within the 1-hour range, say 30 seconds, then the on-chain trigger time for transaction data 1 would be 10:00:30 AM on December 6, 2021. For transaction data 2, if the transaction approver generates a random value within the 1-hour range, say 5 seconds, then the on-chain trigger time for transaction data 2 would be 10:00:05 AM on December 6, 2021. For transaction data 3, if the transaction approver generates a random value within the 1-hour range, say 50 minutes, then the on-chain trigger time for transaction data 3 would be 10:50:00 AM on December 6, 2021, and so on, until 10,000 on-chain trigger times are generated for the 10,000 transaction records. Because this is achieved by adding random values, the 10,000 on-chain trigger times for the 10,000 transaction records will be essentially different.

[0074] Next, in step 407, the transaction approver sends the on-chain trigger time along with the corresponding transaction data to the outside for on-chain processing.

[0075] In this embodiment, an on-chain proxy device can be pre-set between the transaction approver and the blockchain system. This proxy device is responsible for handling the on-chain processing of various transaction data. Therefore, in step 407, the external component can include: an on-chain proxy device set up between the blockchain and the transaction approver. That is, the transaction approver sends the on-chain trigger time along with the corresponding transaction data to the on-chain proxy device, so that the proxy device can perform on-chain processing.

[0076] In one embodiment of this specification, the transmitted transaction data can be encrypted to ensure security. This allows the transaction approver to pre-obtain the private key from a public-private key pair, while the on-chain proxy device obtains the public key from the same pair. Thus, in step 407, the transaction approver uses the private key to sign the transaction data carrying the on-chain trigger time before sending it to the on-chain proxy device.

[0077] The following explains how the on-chain proxy device processes transaction data during the on-chain process.

[0078] Figure 5 This is a flowchart illustrating the processing method of the on-chain proxy device during the on-chain transaction data uploading process in one embodiment of this specification. The on-chain proxy device is the executing entity of this method. It can be understood that this method can also be executed by any device, equipment, platform, or device cluster with computing and processing capabilities.

[0079] See Figure 5 The method includes:

[0080] Step 501: The on-chain agent device receives transaction data.

[0081] Step 503: The on-chain proxy device stores the received transaction data.

[0082] Step 505: The on-chain agent device determines whether to upload the transaction data to the blockchain based on the on-chain trigger time carried in each stored transaction data. If yes, proceed to step 507; otherwise, return to step 505. Note that the on-chain trigger times carried in different transaction data are not exactly the same.

[0083] Step 507: The on-chain agent device uploads the transaction data to the blockchain.

[0084] It can be seen that in the above Figure 5 In the process shown, after receiving transaction data, the on-chain proxy device does not directly upload the transaction data to the blockchain. Instead, it first determines whether the transaction data needs to be uploaded based on the on-chain trigger time carried in the transaction data. Because the on-chain trigger times of different transaction data are not exactly the same, when the on-chain proxy device uploads a large amount of transaction data to the blockchain based on these different on-chain trigger times, a large number of transaction data will not be uploaded to the blockchain simultaneously. In other words, the problem of high-concurrency access to the blockchain will not occur. It can be seen that the method of the embodiments in this specification performs peak smoothing processing of blockchain access, making the access time to the blockchain more balanced.

[0085] The following will illustrate this with specific examples. Figure 5 Each step in the process will be explained separately.

[0086] First, in step 501, the on-chain proxy device receives each transaction data.

[0087] For business data that requires centralized approval, such as salary data when a company needs to pay salaries in a centralized manner, approval document data that an approval authority needs to issue in a centralized manner, or loan disbursement data in the aforementioned financial leasing business, since the transaction approval party generates and sends a large amount of transaction data at once, such as 10,000 transaction data, then in this step 501, the on-chain agent device will simultaneously receive the 10,000 transaction data.

[0088] Here, if the transaction approver performed private key signing on the transaction data in step 407 above, then in step 501, the on-chain proxy device will use the public key to verify the legality of each transaction data when it receives it. If it is legal, it will continue to execute step 503 and subsequent processing.

[0089] After receiving each transaction data in step 501, and before storing the transaction data in step 503 below, step 502 can be further executed: The on-chain proxy device determines whether to upload the transaction data to the blockchain based on the on-chain trigger time carried in each currently received transaction data. If yes, the transaction data is uploaded to the blockchain; otherwise, step 503 is executed.

[0090] Next, in step 503, the on-chain proxy device stores the received transaction data.

[0091] In step 503, the storage method can be caching, such as forming a blockchain transaction cache list.

[0092] Next, in steps 505 to 507, the on-chain agent device determines whether to upload the transaction data to the blockchain based on the on-chain trigger time carried in each stored transaction data. If yes, the transaction data is uploaded to the blockchain; otherwise, it returns to step 505.

[0093] In one embodiment of this specification, in steps 502 and 505 above, the process by which the on-chain proxy device determines whether to upload the transaction data to the blockchain may include: the on-chain proxy device determining whether the on-chain trigger time carried in the transaction data is no later than the current time. If it is not later, it determines that the transaction data should be uploaded to the blockchain; otherwise, it determines that the transaction data should not be uploaded to the blockchain. For example, if the on-chain processing device parses a transaction data showing an on-chain trigger time of 10:20:00 on December 6, 2021, while the current time in the on-chain proxy device is 10:00:50 on December 6, 2021, then the on-chain trigger time is later than the current time, and the transaction data is cached. For example, if the on-chain processing device parses a transaction data and finds that the on-chain trigger time is 10:00:03 on December 6, 2021, while the current time in the on-chain proxy device is 10:00:53 on December 6, 2021, then the on-chain trigger time is no later than the current time, and the transaction data will be uploaded to the blockchain.

[0094] In one embodiment of this specification, the on-chain proxy device executes step 505, which involves determining whether to upload the transaction data to the blockchain based on the on-chain trigger time carried in each stored transaction data, every preset query duration period, such as 2 minutes.

[0095] The following section explains the method for uploading transaction data to the blockchain, combining the processes of blockchain, transaction approval, and on-chain proxy devices. See also... Figure 6 The method includes:

[0096] Step 601: The transaction approver generates transaction data and adds a random value within a preset time range to the generation time of the transaction data to obtain the on-chain trigger time corresponding to the transaction data.

[0097] Step 603: The transaction approver includes the on-chain trigger time in the corresponding transaction data, signs it with the private key, and sends it to the on-chain agent device.

[0098] Step 605: After receiving the transaction data, the on-chain proxy device uses the public key to verify the legality of the transaction data. If it is not legal, the transaction data will not be processed for on-chain processing. If it is legal, the on-chain trigger time carried in the transaction data will be parsed. If the parsed on-chain trigger time is not later than the current time, the transaction data will be uploaded to the blockchain. If it is later than the current time, the transaction data will be cached.

[0099] Step 607: The on-chain proxy device asynchronously traverses all cached transaction data every 2 minutes. If the on-chain trigger time carried in a transaction is no later than the current time, the transaction data is uploaded to the blockchain.

[0100] Step 609: The on-chain agent device receives the on-chain result of the transaction data returned by the blockchain, and then asynchronously returns the on-chain result to the transaction approver.

[0101] In one embodiment of this specification, a device for uploading transaction data to the blockchain is provided, which is set in the transaction approver. See [link to relevant documentation]. Figure 7 The device includes:

[0102] The transaction data generation module 701 is configured to generate transaction data.

[0103] The on-chain trigger time determination module 702 is configured to determine the generation time of the transaction data; and obtain the on-chain trigger time corresponding to the transaction data based on the generation time; wherein the on-chain trigger times of different transaction data are not exactly the same;

[0104] The transaction data sending module 703 is configured to send the on-chain trigger time in the corresponding transaction data to the outside for on-chain processing.

[0105] In one embodiment of this specification, for Figure 7 The device shown, set in the transaction approver, includes an on-chain trigger time determination module 702, configured to obtain a first duration corresponding to the transaction data; wherein the first duration is a time length value within a preset duration range, and the first duration of different transaction data is not exactly the same; the on-chain trigger time corresponding to the transaction data is obtained by adding the first duration to the generation time.

[0106] In one embodiment of this specification, for Figure 7 The device shown, set in the transaction approver, includes an on-chain trigger time determination module 702, which is configured to generate a random value within a preset time range and use this random value as the first time range corresponding to the transaction data.

[0107] In one embodiment of this specification, for Figure 7 The device shown is located in the transaction approval party. The transaction data sending module 703 is configured to send the on-chain trigger time in the corresponding transaction data to the on-chain agent device.

[0108] In one embodiment of this specification, for Figure 7 The device shown, located in the transaction approver, includes a transaction data sending module 703, which is configured to sign the transaction data using the private key in the public-private key pair and send the signed transaction data to the on-chain proxy device.

[0109] In one embodiment of this specification, a device for uploading transaction data to the blockchain is provided, which is set in an on-chain proxy device. See [link to relevant documentation]. Figure 8 The device includes:

[0110] The transaction data receiving module 801 is configured to receive transaction data.

[0111] The transaction data storage module 802 is configured to store the received transaction data;

[0112] The on-chain processing module 803 is configured to determine whether to upload the transaction data to the blockchain based on the on-chain trigger time carried in each transaction data stored in the transaction data storage module 802. If so, the transaction data is uploaded to the blockchain.

[0113] In one embodiment of this specification, for Figure 8 The device shown, set in the on-chain proxy device, has a transaction data receiving module 801 further configured to verify the legality of the received transaction data using the public key in the public-private key pair. If the data is legal, the transaction data storage module 802 stores the received transaction data.

[0114] In one embodiment of this specification, for Figure 8 The device shown is set in the on-chain proxy device. The on-chain processing module 803 is configured to determine whether to upload the transaction data to the blockchain based on the on-chain trigger time carried in the transaction data currently received by the transaction data receiving module 801. If yes, the transaction data is uploaded to the blockchain; otherwise, the transaction data is stored in the transaction data storage module 802.

[0115] In one embodiment of this specification, for Figure 8The device shown is set in the on-chain proxy device. The on-chain processing module 803 is configured to determine whether the on-chain trigger time carried in the transaction data is no later than the current time. If it is not later, it determines that the transaction data should be uploaded to the blockchain at the current time; otherwise, it determines that the transaction data should not be uploaded to the blockchain at the current time.

[0116] In one embodiment of this specification, for Figure 8 The device shown is set in the on-chain proxy device. The on-chain processing module 803 is configured to determine whether to upload the transaction data to the blockchain at preset query duration intervals, based on the on-chain trigger time carried in each transaction data stored in the transaction data storage module 802.

[0117] This specification provides, in one embodiment, a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the methods of any embodiment in the specification.

[0118] This specification provides a computing device according to one embodiment, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to perform the method of any embodiment of the specification.

[0119] It is understood that the structures illustrated in the embodiments of this specification do not constitute a specific limitation on the apparatus of the embodiments of this specification. In other embodiments of the specification, the above-described apparatus may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0120] The information interaction and execution process between the modules in the above-mentioned device and system are based on the same concept as the method embodiments in this specification, and the specific details can be found in the descriptions in the method embodiments in this specification, so they will not be repeated here.

[0121] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0122] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in this invention can be implemented using hardware, software, widgets, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0123] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method of on-chain transaction data, wherein, The transaction data chaining method is executed by a transaction approval party; N pieces of transaction data are generated at the same generation time; N is a positive integer greater than 1; The generation time of the N pieces of transaction data is determined; For each piece of transaction data, a random value within a preset time range is generated; the random values of different transaction data are not completely the same; For each piece of transaction data, the random value of the transaction data is added to the generation time to obtain the chaining trigger time corresponding to the transaction data; the chaining trigger times of different transaction data are not completely the same; The chaining trigger time is carried in the corresponding transaction data and sent to the outside for chaining processing.

2. The method of claim 1, wherein the step of sending the chaining trigger time carried in the corresponding transaction data to the outside for chaining processing is executed by a transaction approval party; The exterior comprises: A chaining agent device is arranged between the blockchain and the transaction approval party.

3. A method of on-chain transaction data, wherein, The transaction data chaining method is executed by a transaction approval party; comprising: Receiving each transaction data; Storing the received transaction data; According to the chaining trigger time carried in each stored transaction data, it is judged whether the transaction data is currently uploaded to the blockchain or not, wherein the chaining trigger times carried in different transaction data are not completely the same; wherein the method for obtaining the chaining trigger time carried in the transaction data comprises: for each piece of transaction data, a random value within a preset time range is generated; wherein the random values of different transaction data are not completely the same; for each piece of transaction data, the random value of the transaction data is added to the generation time to obtain the chaining trigger time corresponding to the transaction data; If yes, the transaction data is uploaded to the blockchain; The judgment of whether the transaction data is currently uploaded to the blockchain or not comprises: Judging whether the chaining trigger time carried in the transaction data is not later than the current time, if not, it is determined that the transaction data is currently uploaded to the blockchain, otherwise, it is determined that the transaction data is not currently uploaded to the blockchain.

4. The method of claim 3, wherein, After receiving each transaction data and before storing the received transaction data, further comprising: According to the chaining trigger time carried in the currently received transaction data, it is judged whether the transaction data is currently uploaded to the blockchain or not, if yes, the transaction data is uploaded to the blockchain, if not, the step of storing the received transaction data is executed.

5. The method of claim 3, wherein, Every preset query time period, the step of judging whether the transaction data is currently uploaded to the blockchain according to the chaining trigger time carried in each stored transaction data is executed.

6. A transaction data chaining device arranged in a transaction approval party, comprising: A transaction data generation module configured to generate N pieces of transaction data at the same generation time; N is a positive integer greater than 1; The upper chain trigger time determination module is configured to determine the generation time of the N pieces of transaction data; for each piece of transaction data, a random value within a preset time range is generated; wherein the random values of different pieces of transaction data are not completely the same; for each piece of transaction data, the random value of the transaction data is added to the generation time to obtain the upper chain trigger time corresponding to the transaction data; wherein the upper chain trigger times of different pieces of transaction data are not completely the same; The transaction data sending module is configured to send the upper chain trigger time in the corresponding transaction data to the outside for upper chain processing.

7. An apparatus for transaction data upper chain, provided in an upper chain agent apparatus, the upper chain agent apparatus being located between a block chain and a transaction approval party; comprising: A transaction data receiving module configured to receive each piece of transaction data; A transaction data storage module configured to store the received transaction data; An upper chain processing module configured to determine whether to upload each piece of stored transaction data to the block chain according to the upper chain trigger time carried in the transaction data, if yes, the transaction data is uploaded to the block chain; wherein the method for obtaining the upper chain trigger time carried in the transaction data comprises: for each piece of transaction data, a random value within a preset time range is generated; wherein the random values of different pieces of transaction data are not completely the same; for each piece of transaction data, the random value of the transaction data is added to the generation time to obtain the upper chain trigger time corresponding to the transaction data; Wherein, the upper chain processing module is configured to determine whether the upper chain trigger time carried in the transaction data is not later than the current time, if yes, it is determined to upload the transaction data to the block chain at present, otherwise, it is determined not to upload the transaction data to the block chain at present.

8. A computing device comprising a memory and a processor, the memory storing executable code, and the processor executing the executable code to implement the method of any one of claims 1-5.

Images