Cargo order management method and system based on block chain

Abstract

The invention discloses a cargo order management method and system based on a block chain, and relates to the technical field of cargo order management, and the method comprises the following steps: S101, after an order request is received through a block chain network, triggering an intelligent contract to carry out order processing, and verifying the identity and order information of an order creator; step S102, if the order information passes verification, the smart contract executes an order input creation operation, nodes of the block chain network are consistent through a consensus algorithm, and validity of a new block is confirmed; and S103, in the process of executing the order creation operation, the smart contract inputs related data into the block chain, and the block chain data input process is monitored in real time. According to the method, through detailed risk assessment and flexible processing strategies of different risk periods, the control level of data entry consistency is effectively improved, and serious consequences possibly brought by inconsistent data are avoided.

Description

Technical Field

[0001] The present invention relates to the technical field of cargo order management, and in particular to a cargo order management method and system based on blockchain. Background Art

[0002] Blockchain-based cargo order management is a method that uses blockchain technology to optimize and enhance the tracking, verification, and management of cargo orders in the supply chain. First, blockchain is a decentralized distributed ledger technology that ensures transparency and traceability throughout the supply chain network. By linking order information together in the form of blocks, each block contains the information of the previous block as well as the new order data, establishing an unalterable historical record. This enables participants to share, verify, and update order status in real time, thereby reducing information asymmetry and misleading information and improving the overall credibility of the supply chain.

[0003] Secondly, the blockchain-based cargo order management system can also be automatically executed through smart contracts. Smart contracts are pre-programmed self-executing codes that automatically execute contract terms according to set conditions and trigger events. In cargo order management, smart contracts can automatically track the logistics process of orders, automatically trigger payments when goods arrive at their destination, and greatly simplify the order processing process and reduce the possibility of human intervention. Such a system improves the efficiency of order processing, reduces the probability of errors, and makes the entire supply chain more efficient and reliable.

[0004] The prior art has the following deficiencies:

[0005] Existing technologies cannot control and analyze the accuracy of smart contract data entry. When the data entry of smart contracts is inconsistent, it cannot be dealt with efficiently. During this period, the following serious consequences may occur:

[0006] Inconsistent data entry may lead to misunderstanding of order information by smart contracts. For example, if the quantity of goods entered is inconsistent with the actual quantity shipped, the smart contract may incorrectly update the order status, making the recorded order information inconsistent with the actual logistics situation, which may cause various links in the supply chain to make wrong decisions based on inaccurate information;

[0007] Inconsistent data may affect the triggering conditions of smart contracts for payments. If there are differences in the quantity or quality of goods, the smart contract may not be able to correctly determine when payment should be triggered, which may lead to incorrect payment timing, increase disputes, and damage trust between participants in the supply chain;

[0008] Data inconsistency may lead to disruption of the entire supply chain. For example, if the delivery address entered is incorrect, the goods may be sent to the wrong location, causing the supply chain to fail to operate normally. This disruption may lead to production stagnation and inventory backlogs, seriously affecting the company's economic benefits and reputation.

[0009] The above information disclosed in this Background section is only for enhancement of understanding of the background of the present disclosure and therefore it may contain information that does not constitute the prior art that is already known to one of ordinary skill in the art. Summary of the invention

[0010] The purpose of the present invention is to provide a blockchain-based cargo order management method and system, which monitors the data entry process in real time and divides the entry process into a safe period, a medium-risk period, and a high-risk period. This helps to evaluate the consistency of data entry in different time periods and adopt different processing strategies for medium-risk and high-risk periods to solve the problems in the above-mentioned background technology.

[0011] In order to achieve the above object, the present invention provides the following technical solution: a goods order management method based on blockchain, comprising the following steps:

[0012] Step S101: After receiving an order request through the blockchain network, trigger the smart contract to process the order and verify the identity of the order creator and the order information;

[0013] Step S102: If the order information is verified, the smart contract executes the order entry creation operation, and the nodes of the blockchain network reach a consensus through the consensus algorithm to confirm the validity of the new block;

[0014] Step S103: During the process of executing the order creation operation, the smart contract enters the relevant data into the blockchain, and by real-time monitoring the process of blockchain data entry, the data entry process is divided into a safe period, a medium-risk period, and a high-risk period according to the time series;

[0015] Step S104: For the medium-risk period, the consistency of data entry is evaluated through the hash value data verification mechanism, and the generated hash index is compared and analyzed with the preset hash index reference threshold to verify the consistency of data entry and determine whether transaction rollback is required;

[0016] Step S105: For high-risk periods, transactions are rolled back according to the real-time requirements of data entry, the execution status of the contract is rolled back to the previous legal state, the data is re-entered, and the data entry process is monitored again. Combined with step S104, it is determined whether the data is entered to avoid inconsistent data being entered into the blockchain.

[0017] Preferably, when the smart contract enters relevant data into the blockchain, the data entry process is divided into several fixed-time windows according to the time series, so that the time in the several fixed-time windows remains equal, and then the transaction information and data processing information when the data is entered in each fixed-time window are obtained, wherein the transaction information includes transaction fees, and the data processing information includes transaction throughput. After obtaining, the transaction fees and transaction throughput are processed to generate a transaction fee variation coefficient and a transaction throughput depression coefficient, and the fixed-time window when the data is entered is divided into a safe period, a medium-risk period, and a high-risk period by comparing the transaction fee variation coefficient and the transaction throughput depression coefficient with a preset reference threshold of the transaction fee variation coefficient and a preset reference threshold of the transaction throughput depression coefficient, respectively.

[0018] Preferably, the logic for obtaining the transaction fee change coefficient is as follows:

[0019] Assume that the fixed time window is Q. Within the fixed time window Q, the observed transaction fee sequence is {F1, F2, F3, …, F n}, where F k represents the transaction fee of the kth transaction, and n represents the number of transactions occurring within a fixed time window T;

[0020] For each transaction k, calculate the absolute rate of change R of its fee k , the calculation expression is: In the formula, R k It represents the absolute rate of change of the kth transaction fee relative to the previous transaction fee;

[0021] Calculate the average absolute change rate MAC within the fixed time window Q. The calculation expression is:

[0022] Calculate the transaction fee change coefficient. The calculation expression is: In the formula, CV represents the coefficient of variation of transaction fees.

[0023] Preferably, the logic for obtaining the transaction throughput depression coefficient is as follows:

[0024] Suppose the fixed time window is Q, the number of transactions, block generation time, transaction confirmation time and expected transaction throughput within the fixed time window Q are m, B, C and E respectively. In addition, the block generation time is the average time for the blockchain network to generate a new block, the transaction confirmation time is the average time from the initiation to the confirmation of the transaction, and the expected transaction throughput is the expected transaction throughput under normal circumstances, that is, the number of transactions that can be processed per second;

[0025] The actual transaction throughput TPS is calculated by the actual number of transactions m and the time window Q. The calculation expression is:

[0026] The transaction throughput depression value is calculated by the ratio between the actual transaction throughput TPS and the expected throughput E. The calculation expression is: In the formula, Low 吞吐 Indicates a low transaction throughput value;

[0027] The transaction processing time difference is calculated by the ratio of the block generation time B and the transaction confirmation time C. The calculation expression is: Where Time 差异 Indicates the transaction processing time difference value;

[0028] Calculate the transaction throughput downturn coefficient. The calculation expression is: Throug = Low 吞吐 *Time 差异 , where Throug represents the transaction throughput depression coefficient.

[0029] Preferably, the transaction fee variation coefficient and the transaction throughput depression coefficient obtained within the fixed time window during data entry are compared with the preset transaction fee variation coefficient reference threshold and the preset transaction throughput depression coefficient reference threshold, respectively, and the comparison results are as follows:

[0030] If the transaction fee change coefficient is greater than or equal to the transaction fee change coefficient reference threshold and the transaction throughput downturn coefficient is greater than or equal to the transaction throughput downturn coefficient reference threshold, the corresponding fixed time window is marked as a high-risk period, and the subsequent data entry situation is further analyzed;

[0031] If the transaction fee change coefficient is greater than or equal to the transaction fee change coefficient reference threshold and the transaction throughput downturn coefficient is less than the transaction throughput downturn coefficient reference threshold, or the transaction fee change coefficient is less than the transaction fee change coefficient reference threshold and the transaction throughput downturn coefficient is greater than or equal to the transaction throughput downturn coefficient reference threshold, then the corresponding fixed time window is marked as a medium-risk period, and the subsequent data entry situation is further analyzed;

[0032] If the transaction fee variation coefficient is less than the reference threshold of the transaction fee variation coefficient and the transaction throughput downturn coefficient is less than the reference threshold of the transaction throughput downturn coefficient, the corresponding fixed-time window will be marked as a safe period. After the corresponding data under the fixed-time window is entered, the data entry judgment of the next fixed-time window will continue.

[0033] Preferably, for the medium risk period, the consistency of data entry is evaluated through a hash value data verification mechanism, and the evaluation process is as follows:

[0034] Select SHA-256 as the algorithm for generating hash values;

[0035] Identify the data structures that need to be verified for consistency;

[0036] Serialize the data structure and convert it into a binary string;

[0037] Use the selected hash algorithm to perform hash calculation on the serialized data to generate a hash value;

[0038] Base64 encode the calculated hash value;

[0039] Map the binary representation of the hash value according to the Base64 encoding rules to generate a Base64-encoded string;

[0040] Select a portion of the Base64-encoded string as the final hash index.

[0041] Preferably, for the medium-risk period, the hash index generated within the fixed time window when the data is entered is compared with the preset hash index reference threshold, and the result of the comparison analysis is as follows:

[0042] If the hash index is greater than or equal to the hash index reference threshold, the corresponding fixed-length window will be marked as a high-risk period again;

[0043] If the hash index is less than the hash index reference threshold, the corresponding fixed-length window is marked as a normal window, and the data entry judgment for the next fixed-length window is continued.

[0044] Preferably, during high-risk periods, transactions are rolled back according to the real-time requirements of data entry, and the execution status of the contract is rolled back to the previous legal state. The steps for re-entering the data are as follows:

[0045] Execute transaction rollback to roll back the execution status of the smart contract to the previous legal state;

[0046] After rolling back to a legitimate state, re-enter the compromised data;

[0047] Submit the re-entered data to the blockchain, generate new transactions, and package them into blocks.

[0048] Preferably, when re-entering the data, the data entry process is monitored again, and the transaction fee variation coefficient and the transaction throughput depression coefficient generated within the fixed time window when the data is re-entered are obtained, and the transaction fee variation coefficient and the transaction throughput depression coefficient are compared with the preset transaction fee variation coefficient reference threshold and the preset transaction throughput depression coefficient reference threshold, respectively. The comparison results are as follows:

[0049] If the transaction fee change coefficient is less than the reference threshold of the transaction fee change coefficient and the transaction throughput depression coefficient is less than the reference threshold of the transaction throughput depression coefficient, the corresponding data under the fixed time window is temporarily determined to be enterable, and the transaction rollback and data re-entry process is confirmed to be completed, and it is verified whether the new data on the blockchain meets the real-time requirements. If it meets the real-time requirements, the enterable data is directly entered, and the data entry judgment of the next fixed time window is continued. If it does not meet the real-time requirements, the enterable data is not directly entered, and a warning is issued to inform the relevant personnel;

[0050] If the transaction fee variation coefficient is greater than or equal to the reference threshold of the transaction fee variation coefficient and the transaction throughput depression coefficient is less than the reference threshold of the transaction throughput depression coefficient, or the transaction fee variation coefficient is less than the reference threshold of the transaction fee variation coefficient and the transaction throughput depression coefficient is greater than or equal to the reference threshold of the transaction throughput depression coefficient, the operation of step S104 is performed again. If the hash index is less than the hash index reference threshold, the corresponding data under the fixed time window is also temporarily determined to be enterable, and the transaction rollback and data re-entry process are confirmed to be completed, and it is verified whether the new data on the blockchain meets the real-time requirements. If the real-time requirements are met, the enterable data is directly entered, and the data entry judgment of the next fixed time window is continued. If the real-time requirements are not met, the enterable data is not directly entered, and a warning is issued to inform the relevant personnel;

[0051] If the hash index is greater than or equal to the hash index reference threshold or the transaction fee variation coefficient is greater than or equal to the transaction fee variation coefficient reference threshold and the transaction throughput downturn coefficient is greater than or equal to the transaction throughput downturn coefficient reference threshold when the operation of step S104 occurs, the data is re-entered again. If the above two situations occur, or the data needs to be re-entered all the time, the transaction rollback and data re-entry process is confirmed to be completed after each judgment is completed, and it is verified whether the new data on the blockchain meets the real-time requirements. If the real-time requirements are met, the data that can be entered will be directly entered, and the data entry judgment of the next fixed time window will continue. If the real-time requirements are not met, the data that can be entered will not be directly entered, and a warning will be issued to notify relevant personnel.

[0052] The blockchain-based cargo order management system includes order triggering and verification modules, order execution and consensus confirmation modules, real-time monitoring and time division modules, medium-risk time verification modules, and high-risk time transaction rollback and re-entry modules;

[0053] The order triggering and verification module triggers the smart contract to process the order after receiving the order request through the blockchain network, and verifies the identity of the order creator and the order information;

[0054] Order execution and consensus confirmation module: if the order information is verified, the smart contract will execute the order entry creation operation, and the nodes of the blockchain network will reach a consensus through the consensus algorithm to confirm the validity of the new block;

[0055] Real-time monitoring and time division module: During the order creation process, the smart contract enters the relevant data into the blockchain. By real-time monitoring the blockchain data entry process, the data entry process is divided into safe period, medium-risk period, and high-risk period according to the time series;

[0056] The medium-risk period verification module evaluates the consistency of data entry during the medium-risk period through the hash value data verification mechanism, compares and analyzes the generated hash index with the pre-set hash index reference threshold, verifies the consistency of data entry, and determines whether transaction rollback is required;

[0057] The high-risk period transaction rollback and re-entry module, for high-risk periods, performs transaction rollback according to the real-time requirements of data entry, rolls back the execution status of the contract to the previous legal state, re-enters the data, and monitors the data entry process again. Combined with step S104, it determines whether to enter the data to avoid inconsistent data being entered into the blockchain.

[0058] In the above technical solution, the technical effects and advantages provided by the present invention are:

[0059] The present invention monitors the data entry process in real time and divides the entry process into safe period, medium risk period and high risk period, which helps to evaluate the consistency of data entry in different periods and adopt different processing strategies for medium risk and high risk periods;

[0060] The present invention uses a hash value data verification mechanism and a comparative analysis of transaction fees and throughput variation coefficients to identify medium-risk and high-risk periods. For medium-risk periods, consistency assessment is performed through hash value verification. For high-risk periods, a transaction rollback mechanism is used to roll back the contract status and re-enter the data to ensure data consistency.

[0061] The present invention can judge the risk of data entry more finely through detailed processing of the transaction fee variation coefficient and the throughput depression coefficient during high-risk periods, and adopts a method of dividing safe, medium-risk and high-risk periods according to thresholds, providing a more targeted risk management strategy, which helps to avoid further expansion of inconsistent data. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0063] Figure 1 The present invention is a flowchart of a method for managing goods orders based on blockchain.

[0064] Figure 2 This is a module diagram of the blockchain-based cargo order management method of the present invention. DETAILED DESCRIPTION

[0065] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in a variety of forms and should not be construed as limited to the examples set forth herein; rather, these example embodiments are provided so that the description of the present disclosure will be more comprehensive and complete, and the concept of the example embodiments will be fully conveyed to those skilled in the art.

[0066] The present invention provides Figure 1 The blockchain-based cargo order management method shown includes the following steps:

[0067] Step S101: After receiving an order request through the blockchain network, trigger the smart contract to process the order and verify the identity of the order creator and the order information;

[0068] Merchants or supply chain participants submit new goods order requests to the blockchain network through front-end applications or other interfaces. After receiving the order request, the blockchain network triggers the corresponding smart contract for processing. The smart contract first verifies the identity of the order creator to ensure that he or she has sufficient permissions to perform the order creation operation. Identity authentication can be based on mechanisms such as digital signatures and access control lists. Secondly, the order information is verified, including the quantity of goods, delivery address, price, etc., which helps prevent non-compliant order information from entering the blockchain.

[0069] Step S102: If the order information is verified, the smart contract executes the order entry creation operation, and the nodes of the blockchain network reach a consensus through the consensus algorithm to confirm the validity of the new block;

[0070] The nodes of the blockchain network reach agreement through a consensus algorithm to ensure the validity of new blocks. Different blockchain platforms use different consensus algorithms. Here are several common consensus algorithms and how they reach agreement:

[0071] Proof-of-Work (PoW): A node proves its contribution to the network by solving a mathematical problem of a certain difficulty, thereby having the right to propose a new block. Other nodes verify whether the proof of work is correct and confirm the node's proposal. The node that solves the problem first adds its proposed block to the blockchain. This competitive mechanism ensures that nodes continue to work hard to solve problems to gain power and reach consensus.

[0072] Proof-of-Stake (PoS): The proposal weight of a node is proportional to the amount of cryptocurrency it holds. Nodes holding more coins have a higher probability of proposing new blocks. Other nodes reach a consensus by verifying the node's proof of stake and proposal, confirming that the node with the largest stake has the right to propose a new block.

[0073] Delegated Proof-of-Stake (DPoS): Nodes elect a certain number of representatives through voting, and these representatives have the right to propose new blocks. Proof of Stake is combined with delegated voting. The elected representative nodes take turns to produce blocks, and other nodes verify and agree to ensure the efficient operation of the system.

[0074] Proof-of-Authority (PoA): The nodes of the blockchain are managed by known and authorized entities, and the authority to propose new blocks depends on their identity. The authorized entity signs the block, and other nodes verify the signature to ensure that only authorized nodes have the right to propose new blocks.

[0075] Practical Byzantine Fault Tolerance (PBFT): Nodes reach consensus by communicating with each other, even if there are a certain number of malicious nodes. Nodes communicate with each other, propose and vote, and when more than 2 / 3 of the nodes reach a consensus, the new block is accepted.

[0076] Proof-of-Burn (PoB) cryptoeconomics: A node proves its commitment to the network by destroying a certain amount of cryptocurrency, thereby having the right to propose a new block. Other nodes verify the node's destruction evidence and confirm that the node with the largest amount of destruction has the right to propose a new block.

[0077] The above algorithms have different applicability, advantages and disadvantages in different scenarios. The selection of consensus algorithms is not specifically limited here, and can be selected based on the applicability and advantages of the actual scenario. The goal of the consensus algorithm is to ensure that network nodes can still reach a consensus on the validity of new blocks without the need for central control. Through various mechanisms, consensus algorithms help ensure the security, reliability and decentralization of the network.

[0078] Step S103: During the process of executing the order creation operation, the smart contract enters the relevant data into the blockchain, and by real-time monitoring the process of blockchain data entry, the data entry process is divided into a safe period, a medium-risk period, and a high-risk period according to the time series;

[0079] When the smart contract enters the relevant data into the blockchain, the data entry process is divided into several fixed-time windows according to the time series, so that the durations in the several fixed-time windows remain equal, and then the transaction information and data processing information at the time of data entry in each fixed-time window are obtained, wherein the transaction information includes the transaction fee, and the data processing information includes the transaction throughput. After obtaining, the transaction fee and the transaction throughput are processed to generate the transaction fee variation coefficient and the transaction throughput depression coefficient. The fixed-time window at the time of data entry is divided into a safe period, a medium-risk period, and a high-risk period by comparing the transaction fee variation coefficient and the transaction throughput depression coefficient with the pre-set reference threshold of the transaction fee variation coefficient and the pre-set reference threshold of the transaction throughput depression coefficient respectively;

[0080] Large changes in transaction fees may cause inconsistent data entry in smart contracts in blockchain-based cargo order management. The following is a detailed explanation of why large changes in transaction fees may affect data entry consistency:

[0081] Inconsistent execution costs: If transaction fees vary greatly, executing the same smart contract operation at different times may require paying different amounts of fees. This will result in inconsistent execution costs for the same operation at different points in time, making the execution of smart contracts economically unstable. The consistency principle requires that the same operation has similar costs at different times or environments.

[0082] Reduced predictability: Vastly changing fees may make it difficult for participants to predict the specific costs they will need to pay when executing smart contracts. Lack of cost predictability may cause participants in the supply chain to face uncertainty when making decisions, affecting their trust and reliability in the execution of smart contracts.

[0083] Transaction priority issues: Transactions with high handling fees may be prioritized, while transactions with low handling fees may face delays or be rejected. This may cause some orders to be processed more slowly, affecting the real-time nature of the orders. Consistency requires that under the same conditions, the same orders should have the same processing priority.

[0084] Cost premium problem: High fees may cause some nodes to be more willing to package and process transactions with high fees, while ignoring other transactions with low fees. This may lead to a cost premium problem, that is, some transactions may be delayed or unable to be included in the block, thus affecting the consistency of the entire order system.

[0085] Smart contract call issues: The call of some smart contracts may be affected by high handling fees, resulting in unstable execution of some contracts. High handling fees may prevent some smart contracts from being executed as expected, causing inconsistencies in the business logic in the supply chain.

[0086] Therefore, the greater the change in transaction fees within a fixed time window during data entry, the greater the risk of inconsistent data entry during data entry.

[0087] The logic for obtaining the transaction fee change coefficient is as follows:

[0088] Assume that the fixed time window is Q. Within the fixed time window Q, the observed transaction fee sequence is {F1, F2, F3, …, F n}, where F k represents the transaction fee of the kth transaction, and n represents the number of transactions occurring within a fixed time window T;

[0089] For each transaction k, calculate the absolute rate of change R of its fee k , the calculation expression is: In the formula, R k It represents the absolute rate of change of the kth transaction fee relative to the previous transaction fee;

[0090] It should be noted that if it is the first transaction, you can consider using the initial transaction fee (F0) or define the absolute change rate as 0.

[0091] Calculate the average absolute change rate MAC within the fixed time window Q. The calculation expression is:

[0092] Calculate the transaction fee change coefficient. The calculation expression is: In the formula, CV represents the coefficient of variation of transaction fees;

[0093] From the calculation expression of the transaction fee variation coefficient, it can be seen that the larger the performance value of the transaction fee variation coefficient generated within the fixed time window Q during data entry, the greater the amplitude of the transaction fee variation within the fixed time window Q during data entry, indicating that the risk of inconsistent data entry during data entry is greater; conversely, the smaller the risk of inconsistent data entry during data entry.

[0094] Low transaction throughput may lead to inconsistent data entry in smart contracts for blockchain-based cargo order management, as detailed below:

[0095] Transaction processing delays: Low transaction throughput may lead to transaction processing delays, that is, transactions cannot be packaged and confirmed in time. Smart contracts may need to wait for a long time to execute, which may lead to untimely updates of order status, resulting in consistency anomalies. For example, the status of some orders may be updated on the chain, while other orders may lag on the chain, affecting the real-time performance of the overall supply chain.

[0096] Uncertainty and predictability: Low transaction throughput makes it difficult for participants to predict when transactions will be confirmed. Lack of predictability may cause participants in the supply chain to face uncertainty in order execution. The difference in processing time for different orders may increase, which may lead to inconsistent updates of order status throughout the supply chain.

[0097] Smart contract execution order problem: In the case of low transaction throughput, there may be problems with the order of smart contract execution. If the smart contract execution of a certain order is later than other orders, it may cause abnormal execution of smart contracts that depend on the previous order status, destroying the business logic of the smart contract and threatening the consistency of data.

[0098] Double payment risk: Low transaction throughput may increase the risk of double payment. When processing order payments, due to the long transaction confirmation time, there is a possibility that users pay for the same order multiple times in a short period of time. This may cause inconsistencies in the payment system and affect the consistency of order status.

[0099] Network security issues: Low transaction throughput may increase the probability of successful network attacks. In the case of low transaction throughput, network attackers may be more likely to carry out malicious attacks, such as 51% attacks, thereby tampering with transaction records and undermining the consistency and reliability of orders.

[0100] Therefore, the lower the transaction throughput when trading within a fixed time window during data entry, the greater the risk of inconsistent data entry during data entry.

[0101] The logic for obtaining the transaction throughput depression coefficient is as follows:

[0102] Suppose the fixed time window is Q, the number of transactions, block generation time, transaction confirmation time and expected transaction throughput within the fixed time window Q are m, B, C and E respectively. In addition, the block generation time is the average time for the blockchain network to generate a new block, the transaction confirmation time is the average time from the initiation to the confirmation of the transaction, and the expected transaction throughput is the expected transaction throughput under normal circumstances, that is, the number of transactions that can be processed per second;

[0103] The actual transaction throughput TPS is calculated by the actual number of transactions m and the time window Q. The calculation expression is:

[0104] The transaction throughput depression value is calculated by the ratio between the actual transaction throughput TPS and the expected throughput E. The calculation expression is: In the formula, Low 吞吐 Indicates a low transaction throughput value;

[0105] The transaction processing time difference is calculated by the ratio of the block generation time B and the transaction confirmation time C. The calculation expression is: Where Time 差异 Indicates the transaction processing time difference value;

[0106] Calculate the transaction throughput downturn coefficient. The calculation expression is: Throug = Low 吞吐 *Time 差异 , where Throug represents the transaction throughput depression coefficient.

[0107] It can be seen from the calculation expression of the transaction throughput downturn coefficient that the larger the performance value of the transaction throughput downturn coefficient generated within the fixed time window Q during data entry, the greater the risk of inconsistent data entry during data entry; conversely, the smaller the risk of inconsistent data entry during data entry.

[0108] The transaction fee change coefficient and transaction throughput depression coefficient obtained within a fixed time window during data entry are compared with the pre-set transaction fee change coefficient reference threshold and the pre-set transaction throughput depression coefficient reference threshold, respectively. The comparison results are as follows:

[0109] If the transaction fee change coefficient is greater than or equal to the transaction fee change coefficient reference threshold and the transaction throughput downturn coefficient is greater than or equal to the transaction throughput downturn coefficient reference threshold, the corresponding fixed time window is marked as a high-risk period, and the subsequent data entry situation is further analyzed;

[0110] If the transaction fee change coefficient is greater than or equal to the transaction fee change coefficient reference threshold and the transaction throughput downturn coefficient is less than the transaction throughput downturn coefficient reference threshold, or the transaction fee change coefficient is less than the transaction fee change coefficient reference threshold and the transaction throughput downturn coefficient is greater than or equal to the transaction throughput downturn coefficient reference threshold, then the corresponding fixed time window is marked as a medium-risk period, and the subsequent data entry situation is further analyzed;

[0111] If the transaction fee variation coefficient is less than the reference threshold of the transaction fee variation coefficient and the transaction throughput downturn coefficient is less than the reference threshold of the transaction throughput downturn coefficient, the corresponding fixed-time window will be marked as a safe period. After the corresponding data under the fixed-time window is entered, the data entry judgment of the next fixed-time window will continue.

[0112] Step S104: For the medium-risk period, the consistency of data entry is evaluated through the hash value data verification mechanism, and the generated hash index is compared and analyzed with the preset hash index reference threshold to verify the consistency of data entry and determine whether transaction rollback is required;

[0113] For medium-risk periods, the consistency of data entry is evaluated through a hash value data verification mechanism. The evaluation process is as follows:

[0114] Select SHA-256 as the algorithm for generating hash values;

[0115] Identify the data structures that need to be verified for consistency;

[0116] The data structure that needs to be verified for consistency, such as a data block containing goods order information, this data block may include order number, product information, transaction time, etc., and can be set according to requirements.

[0117] Serialize the data structure and convert it into a binary string;

[0118] Serialization is to ensure that the same data input produces the same hash value.

[0119] Use the selected hash algorithm to perform hash calculation on the serialized data to generate a hash value;

[0120] This hash value is the unique identifier of the data, and even if the data changes slightly, the hash value will be very different.

[0121] Base64 encode the calculated hash value;

[0122] Base64 encoding is an encoding method that converts binary data into printable characters, mapping binary data into a string of readable characters according to certain rules.

[0123] Map the binary representation of the hash value according to the Base64 encoding rules to generate a Base64-encoded string;

[0124] Select a part of the Base64-encoded string as the final hash index;

[0125] The final hash index is the result after Base64 encoding and possible truncation of some characters. This hash index has a certain length and is represented by readable characters for easy storage and display.

[0126] For the medium-risk period, the hash index generated within the fixed time window when the data is entered is compared with the pre-set hash index reference threshold. The results of the comparison and analysis are as follows:

[0127] If the hash index is greater than or equal to the hash index reference threshold, the corresponding fixed-time window will be marked as a high-risk period again. When the corresponding fixed-time window is marked as a high-risk period during data entry, it means that the consistency of the data during data entry in the fixed-time window has been affected, and a physical rollback is required to eliminate the impact;

[0128] If the hash index is less than the hash index reference threshold, the corresponding fixed-length window will be marked as a normal window. When the corresponding fixed-length window is marked as a normal window during data entry, it indicates that the consistency of the data is not affected when the fixed-length window is entered. After the corresponding data under the fixed-length window is entered, the data entry judgment for the next fixed-length window will be continued.

[0129] The main function of judging data entry by hash value rather than directly selecting transaction rollback mechanism is to provide an efficient and real-time data consistency verification mechanism. This method calculates the hash value and compares it with the pre-set hash index reference threshold. It can instantly detect the integrity of the data without the need to immediately roll back the transaction. This not only reduces the system overhead and improves performance, but also allows the data consistency standard to be adjusted according to specific business needs by flexibly setting the hash index reference threshold.

[0130] Step S105: For high-risk periods, transactions are rolled back according to the real-time requirements of data entry, the execution status of the contract is rolled back to the previous legal state, the data is re-entered, and the data entry process is monitored again. Combined with step S104, it is determined whether the data is entered to avoid inconsistent data being entered into the blockchain;

[0131] For high-risk periods (including fixed time windows that are further determined as high-risk periods during medium-risk periods), transactions are rolled back based on the real-time requirements for data entry, and the execution status of the contract is rolled back to the previous legal state. The steps for re-entering data are as follows:

[0132] Execute transaction rollback to roll back the execution status of the smart contract to the previous legal state;

[0133] This includes information such as fallback smart contract internal variables, states, and execution pointers.

[0134] After rolling back to a legitimate state, re-enter the compromised data;

[0135] This may involve re-executing the order creation operation or performing other compensatory operations to ensure data consistency and integrity.

[0136] Submit the re-entered data to the blockchain, generate new transactions, and package them into blocks;

[0137] This ensures that the latest version of the data is recorded on the blockchain.

[0138] When re-entering the data, the data entry process is monitored again to obtain the transaction fee change coefficient and transaction throughput depression coefficient generated within the fixed time window when the data is re-entered, and the transaction fee change coefficient and transaction throughput depression coefficient are compared with the pre-set transaction fee change coefficient reference threshold and the pre-set transaction throughput depression coefficient reference threshold, respectively. The comparison results are as follows:

[0139] Case 1: If the transaction fee change coefficient is less than the reference threshold of the transaction fee change coefficient and the transaction throughput depression coefficient is less than the reference threshold of the transaction throughput depression coefficient, the corresponding data under the fixed time window is temporarily determined to be enterable, and the transaction rollback and data re-entry process is confirmed to be completed, and it is verified whether the new data on the blockchain meets the real-time requirements. If it meets the real-time requirements, the enterable data is directly entered, and the data entry judgment of the next fixed time window is continued. If it does not meet the real-time requirements, the enterable data is not directly entered, and a warning is issued to inform the relevant personnel, so that the relevant personnel can promptly discover possible abnormal problems during data entry;

[0140] Case 2: If the transaction fee variation coefficient is greater than or equal to the reference threshold of the transaction fee variation coefficient and the transaction throughput depression coefficient is less than the reference threshold of the transaction throughput depression coefficient, or the transaction fee variation coefficient is less than the reference threshold of the transaction fee variation coefficient and the transaction throughput depression coefficient is greater than or equal to the reference threshold of the transaction throughput depression coefficient, then the operation of step S104 is performed again. If the hash index is less than the hash index reference threshold, the corresponding data under the fixed time window is also temporarily determined to be enterable, and at the same time, the transaction rollback and data re-entry process is confirmed to be completed, and it is verified whether the new data on the blockchain meets the real-time requirements. If the real-time requirements are met, the enterable data is directly entered, and the data entry judgment of the next fixed time window is continued. If the real-time requirements are not met, the enterable data is not directly entered, and a warning is issued to inform the relevant personnel, so that the relevant personnel can promptly discover the abnormal problems that may exist during data entry;

[0141] When the hash index is greater than or equal to the hash index reference threshold in the above two situations, it means that when the data is re-entered, the data entry may have only experienced a sudden high-risk period abnormality within a fixed time window. After the transaction is rolled back and re-entered, the hidden danger can be eliminated.

[0142] Case 3: If the hash index is greater than or equal to the hash index reference threshold or the transaction fee variation coefficient is greater than or equal to the transaction fee variation coefficient reference threshold and the transaction throughput depression coefficient is greater than or equal to the transaction throughput depression coefficient reference threshold when the operation of step S104 occurs, the data is re-entered again. If the above two situations occur, or the data needs to be re-entered all the time, the transaction rollback and data re-entry process is confirmed to be completed after each judgment is completed, and it is verified whether the new data on the blockchain meets the real-time requirements. If the real-time requirements are met, the data that can be entered will be directly entered, and the data entry judgment of the next fixed time window will continue. If the real-time requirements are not met, the data that can be entered will not be directly entered, and a warning will be issued to notify relevant personnel to facilitate relevant personnel to promptly discover possible abnormal problems during data entry.

[0143] The explanation for confirming that the transaction rollback and data re-entry process is complete and verifying whether the new data on the blockchain meets the real-time requirements is as follows:

[0144] The duration used for each data entry judgment in each fixed time window is compared and analyzed with the real-time reference threshold under the fixed time window (the maximum duration allowed to meet the real-time requirement). If the duration used for each data entry judgment in each fixed time window is less than the real-time reference threshold under the fixed time window, it is judged that the real-time requirement is met. If the duration used for each data entry judgment in each fixed time window is greater than or equal to the real-time reference threshold under the fixed time window, it is judged that the real-time requirement is not met.

[0145] Take situation 1 as an example:

[0146] For high-risk periods, the corresponding data entry time during the high-risk period is recorded as the first time, the execution status of the contract is rolled back to the previous legal state, the data is re-entered, and the time of re-entering the data is recorded as the second time. The total data entry time is the sum of the first time and the second time. The total data entry time is compared and analyzed with the real-time reference threshold. If the total data entry time is less than the real-time reference threshold, the enterable data is directly entered, and the data entry judgment of the next fixed time window is continued. If the total data entry time is greater than or equal to the real-time reference threshold, the enterable data is not directly entered, and a warning is issued to inform relevant personnel, so that relevant personnel can promptly discover possible abnormal problems during data entry.

[0147] The blockchain-based cargo order management system includes order triggering and verification modules, order execution and consensus confirmation modules, real-time monitoring and time division modules, medium-risk time verification modules, and high-risk time transaction rollback and re-entry modules;

[0148] The order triggering and verification module triggers the smart contract to process the order after receiving the order request through the blockchain network, and verifies the identity of the order creator and the order information;

[0149] Order execution and consensus confirmation module: if the order information is verified, the smart contract will execute the order entry creation operation, and the nodes of the blockchain network will reach a consensus through the consensus algorithm to confirm the validity of the new block;

[0150] Real-time monitoring and time division module: During the order creation process, the smart contract enters the relevant data into the blockchain. By real-time monitoring the blockchain data entry process, the data entry process is divided into safe period, medium-risk period, and high-risk period according to the time series;

[0151] The medium-risk period verification module evaluates the consistency of data entry during the medium-risk period through the hash value data verification mechanism, compares and analyzes the generated hash index with the pre-set hash index reference threshold, verifies the consistency of data entry, and determines whether transaction rollback is required;

[0152] The high-risk period transaction rollback and re-entry module, for high-risk periods, performs transaction rollback according to the real-time requirements of data entry, rolls back the execution status of the contract to the previous legal state, re-enters the data, and monitors the data entry process again. Combined with step S104, it determines whether to enter the data to avoid inconsistent data being entered into the blockchain;

[0153] The blockchain-based cargo order management method provided in an embodiment of the present invention is implemented through the above-mentioned blockchain-based cargo order management system. The specific methods and processes of the blockchain-based cargo order management system are detailed in the above-mentioned blockchain-based cargo order management method embodiment, which will not be repeated here.

[0154] The present invention monitors the data entry process in real time and divides the entry process into safe period, medium risk period and high risk period, which helps to evaluate the consistency of data entry in different periods and adopt different processing strategies for medium risk and high risk periods;

[0155] The present invention uses a hash value data verification mechanism and a comparative analysis of transaction fees and throughput variation coefficients to identify medium-risk and high-risk periods. For medium-risk periods, consistency assessment is performed through hash value verification. For high-risk periods, a transaction rollback mechanism is used to roll back the contract status and re-enter the data to ensure data consistency.

[0156] The present invention can judge the risk of data entry more finely through detailed processing of the transaction fee variation coefficient and the throughput depression coefficient during high-risk periods, and adopts a method of dividing safe, medium-risk and high-risk periods according to thresholds, providing a more targeted risk management strategy, which helps to avoid further expansion of inconsistent data.

[0157] The above description is only by way of illustration of certain exemplary embodiments of the present invention. It is undoubted that those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the above drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

Claims

1. A method for managing goods orders based on blockchain, characterized in that: The following steps are involved: Step S101: After receiving an order request through the blockchain network, trigger the smart contract to process the order and verify the identity of the order creator and the order information; Step S102: If the order information is verified, the smart contract executes the order entry creation operation, and the nodes of the blockchain network reach a consensus through the consensus algorithm to confirm the validity of the new block; Step S103: During the process of executing the order creation operation, the smart contract enters the relevant data into the blockchain, and by real-time monitoring the process of blockchain data entry, the data entry process is divided into a safe period, a medium-risk period, and a high-risk period according to the time series; Step S104: For the medium-risk period, the consistency of data entry is evaluated through the hash value data verification mechanism, and the generated hash index is compared and analyzed with the preset hash index reference threshold to verify the consistency of data entry and determine whether transaction rollback is required; Step S105: For high-risk periods, transactions are rolled back according to the real-time requirements of data entry, the execution status of the contract is rolled back to the previous legal state, the data is re-entered, and the data entry process is monitored again. Combined with step S104, it is determined whether the data is entered to avoid inconsistent data being entered into the blockchain.

2. The blockchain-based cargo order management method according to claim 1 is characterized in that: When the smart contract enters relevant data into the blockchain, the data entry process is divided into several fixed-time windows according to the time series, so that the time in the several fixed-time windows remains equal, and then the transaction information and data processing information at the time of data entry in each fixed-time window are obtained, where the transaction information includes transaction fees, and the data processing information includes transaction throughput. After obtaining, the transaction fees and transaction throughput are processed to generate transaction fee variation coefficients and transaction throughput depression coefficients. The fixed-time window during data entry is divided into a safe period, a medium-risk period, and a high-risk period by comparing the transaction fee variation coefficient and the transaction throughput depression coefficient with the pre-set reference threshold of the transaction fee variation coefficient and the pre-set reference threshold of the transaction throughput depression coefficient.

3. The blockchain-based cargo order management method according to claim 2 is characterized in that: The logic for obtaining the transaction fee change coefficient is as follows: Assume that the fixed time window is Q. Within the fixed time window Q, the observed transaction fee sequence is {F1, F2, F3, …, F n }, where F k represents the transaction fee of the kth transaction, and n represents the number of transactions occurring within a fixed time window T; For each transaction k, calculate the absolute rate of change R of its fee k , the calculation expression is: In the formula, R k It represents the absolute rate of change of the kth transaction fee relative to the previous transaction fee; Calculate the average absolute change rate MAC within the fixed time window Q. The calculation expression is: Calculate the transaction fee change coefficient. The calculation expression is: In the formula, CV represents the coefficient of variation of transaction fees.

4. The blockchain-based cargo order management method according to claim 3 is characterized in that: The logic for obtaining the transaction throughput depression coefficient is as follows: Suppose the fixed time window is Q, the number of transactions, block generation time, transaction confirmation time and expected transaction throughput within the fixed time window Q are m, B, C and E respectively. In addition, the block generation time is the average time for the blockchain network to generate a new block, the transaction confirmation time is the average time from the initiation to the confirmation of the transaction, and the expected transaction throughput is the expected transaction throughput under normal circumstances, that is, the number of transactions that can be processed per second; The actual transaction throughput TPS is calculated by the actual number of transactions m and the time window Q. The calculation expression is: The transaction throughput depression value is calculated by the ratio between the actual transaction throughput TPS and the expected throughput E. The calculation expression is: In the formula, Low 吞吐 Indicates a low transaction throughput value; The transaction processing time difference is calculated by the ratio of the block generation time B and the transaction confirmation time C. The calculation expression is: Where Time 差异 Indicates the transaction processing time difference value; Calculate the transaction throughput downturn coefficient. The calculation expression is: Throug = Low 吞吐 *Time 差异 , where Throug represents the transaction throughput depression coefficient.

5. The blockchain-based cargo order management method according to claim 4 is characterized in that: The transaction fee change coefficient and transaction throughput depression coefficient obtained within a fixed time window during data entry are compared with the pre-set transaction fee change coefficient reference threshold and the pre-set transaction throughput depression coefficient reference threshold, respectively. The comparison results are as follows: If the transaction fee change coefficient is greater than or equal to the transaction fee change coefficient reference threshold and the transaction throughput downturn coefficient is greater than or equal to the transaction throughput downturn coefficient reference threshold, the corresponding fixed time window is marked as a high-risk period, and the subsequent data entry situation is further analyzed; If the transaction fee change coefficient is greater than or equal to the transaction fee change coefficient reference threshold and the transaction throughput downturn coefficient is less than the transaction throughput downturn coefficient reference threshold, or the transaction fee change coefficient is less than the transaction fee change coefficient reference threshold and the transaction throughput downturn coefficient is greater than or equal to the transaction throughput downturn coefficient reference threshold, then the corresponding fixed-time window is marked as a medium-risk period, and the subsequent data entry situation is further analyzed; If the transaction fee variation coefficient is less than the reference threshold of the transaction fee variation coefficient and the transaction throughput downturn coefficient is less than the reference threshold of the transaction throughput downturn coefficient, the corresponding fixed-time window will be marked as a safe period. After the corresponding data under the fixed-time window is entered, the data entry judgment of the next fixed-time window will continue.

6. The blockchain-based cargo order management method according to claim 5 is characterized in that: For medium-risk periods, the consistency of data entry is evaluated through a hash value data verification mechanism. The evaluation process is as follows: Select SHA-256 as the algorithm for generating hash values; Identify the data structures that need to be verified for consistency; Serialize the data structure and convert it into a binary string; Use the selected hash algorithm to perform hash calculation on the serialized data to generate a hash value; Base64 encode the calculated hash value; Map the binary representation of the hash value according to the Base64 encoding rules to generate a Base64-encoded string; Select a portion of the Base64-encoded string as the final hash index.

7. The blockchain-based cargo order management method according to claim 6 is characterized in that: For the medium-risk period, the hash index generated within the fixed time window when the data is entered is compared with the pre-set hash index reference threshold. The results of the comparison and analysis are as follows: If the hash index is greater than or equal to the hash index reference threshold, the corresponding fixed-length window will be marked as a high-risk period again; If the hash index is less than the hash index reference threshold, the corresponding fixed-length window is marked as a normal window, and the data entry judgment for the next fixed-length window is continued.

8. The blockchain-based cargo order management method according to claim 5 is characterized in that: During high-risk periods, transactions are rolled back based on the real-time requirements for data entry, and the execution status of the contract is rolled back to the previous legal state. The steps for re-entering the data are as follows: Execute transaction rollback to roll back the execution status of the smart contract to the previous legal state; After rolling back to a legitimate state, re-enter the compromised data; Submit the re-entered data to the blockchain, generate new transactions, and package them into blocks.

9. The blockchain-based cargo order management method according to claim 5 is characterized in that: When re-entering the data, the data entry process is monitored again to obtain the transaction fee change coefficient and transaction throughput depression coefficient generated within the fixed time window when the data is re-entered, and the transaction fee change coefficient and transaction throughput depression coefficient are compared with the pre-set transaction fee change coefficient reference threshold and the pre-set transaction throughput depression coefficient reference threshold, respectively. The comparison results are as follows: If the transaction fee change coefficient is less than the reference threshold of the transaction fee change coefficient and the transaction throughput depression coefficient is less than the reference threshold of the transaction throughput depression coefficient, the corresponding data under the fixed time window is temporarily determined to be enterable, and the transaction rollback and data re-entry process is confirmed to be completed, and it is verified whether the new data on the blockchain meets the real-time requirements. If it meets the real-time requirements, the enterable data is directly entered, and the data entry judgment of the next fixed time window is continued. If it does not meet the real-time requirements, the enterable data is not directly entered, and a warning is issued to inform the relevant personnel; If the transaction fee variation coefficient is greater than or equal to the reference threshold of the transaction fee variation coefficient and the transaction throughput depression coefficient is less than the reference threshold of the transaction throughput depression coefficient, or the transaction fee variation coefficient is less than the reference threshold of the transaction fee variation coefficient and the transaction throughput depression coefficient is greater than or equal to the reference threshold of the transaction throughput depression coefficient, the operation of step S104 is performed again. If the hash index is less than the hash index reference threshold, the corresponding data under the fixed time window is also temporarily determined to be enterable, and the transaction rollback and data re-entry process are confirmed to be completed, and it is verified whether the new data on the blockchain meets the real-time requirements. If the real-time requirements are met, the enterable data is directly entered, and the data entry judgment of the next fixed time window is continued. If the real-time requirements are not met, the enterable data is not directly entered, and a warning is issued to inform the relevant personnel; If the hash index is greater than or equal to the hash index reference threshold or the transaction fee variation coefficient is greater than or equal to the transaction fee variation coefficient reference threshold and the transaction throughput downturn coefficient is greater than or equal to the transaction throughput downturn coefficient reference threshold when the operation of step S104 occurs, the data is re-entered again. If the above two situations occur, or the data needs to be re-entered all the time, the transaction rollback and data re-entry process is confirmed to be completed after each judgment is completed, and it is verified whether the new data on the blockchain meets the real-time requirements. If the real-time requirements are met, the data that can be entered will be directly entered, and the data entry judgment of the next fixed time window will continue. If the real-time requirements are not met, the data that can be entered will not be directly entered, and a warning will be issued to notify relevant personnel.

10. A goods order management system based on blockchain, used to implement the goods order management method based on blockchain as described in any one of claims 1 to 9 above, characterized in that: It includes order triggering and verification module, order execution and consensus confirmation module, real-time monitoring and time division module, medium-risk time verification module and high-risk time transaction rollback and re-entry module; The order triggering and verification module triggers the smart contract to process the order after receiving the order request through the blockchain network, and verifies the identity of the order creator and the order information; Order execution and consensus confirmation module: if the order information is verified, the smart contract will execute the order entry creation operation, and the nodes of the blockchain network will reach a consensus through the consensus algorithm to confirm the validity of the new block; Real-time monitoring and time division module: During the order creation process, the smart contract enters the relevant data into the blockchain. By real-time monitoring the blockchain data entry process, the data entry process is divided into safe period, medium-risk period, and high-risk period according to the time series; The medium-risk period verification module evaluates the consistency of data entry during the medium-risk period through the hash value data verification mechanism, compares and analyzes the generated hash index with the pre-set hash index reference threshold, verifies the consistency of data entry, and determines whether transaction rollback is required; The high-risk period transaction rollback and re-entry module, for high-risk periods, performs transaction rollback according to the real-time requirements of data entry, rolls back the execution status of the contract to the previous legal state, re-enters the data, and monitors the data entry process again. Combined with step S104, it determines whether to enter the data to avoid inconsistent data being entered into the blockchain.

Images