A cross-border e-commerce order whole-link trusted data evidence method and system

Abstract

The application discloses a cross-border e-commerce order full-link credible data evidence storage method and system, relates to the technical field of cross-border e-commerce trade, and comprises the following steps: acquiring business event data in a cross-border order full link; determining the length of a window period according to the occurrence time point of the business event data and the evidence storage processing state; combining the length of the window period with the real-time load of the current evidence storage system to calculate the risk index of each business event data; executing different evidence storage strategies for each business event data according to the risk level to which the risk index belongs; and after executing the different evidence storage strategies, dynamically optimizing the calculation parameters of the risk index according to the actual evidence storage window period of the business event data and tampering detection results. The application achieves the technical effect of cross-border e-commerce order full-link credible data evidence storage.

Description

Technical Field

[0001] This application relates to the field of cross-border e-commerce trade technology, specifically to a method and system for reliable data storage of cross-border e-commerce orders across the entire supply chain. Background Technology

[0002] With the rapid development of global digital trade and the continuous expansion of the cross-border e-commerce industry, the entire order transaction chain has extended to multiple complex links that cross countries, entities, and systems, including commodity production, customs clearance, overseas warehousing, platform transactions, payment settlement, and after-sales rights protection. It is necessary to reliably store and prove the data of the entire chain of orders, from creation, payment, customs declaration, international transportation, overseas warehousing, receipt and fulfillment to after-sales rights protection.

[0003] Current methods for end-to-end evidence preservation in cross-border e-commerce often employ asynchronous processing by a centralized system, timed batch evidence preservation, or external callback triggering. This results in delays of several hours or even half a day between the occurrence of a business event and the final completion of evidence preservation, creating a significant time lag (i.e., a "window period"). Existing asynchronous or batch evidence preservation methods leave data unprotected during this window period, making it highly susceptible to tampering that is difficult to detect. This undermines the end-to-end trust system and makes evidence collection difficult in cross-border disputes. Summary of the Invention

[0004] To address the technical problem in related technologies where asynchronous processing by a central system, timed batch storage, or external callback triggering modes result in data being unprotected during the off-season, making it highly susceptible to tampering and difficult to detect, thereby undermining the trustworthy system across the entire chain and making it difficult to provide evidence in cross-border disputes, this application provides a method and system for trustworthy data storage across the entire chain of cross-border e-commerce orders.

[0005] The specific technical solution adopted is as follows: Acquire business event data throughout the entire cross-border order process; The length of the gap period is determined based on the occurrence time of the business event data and the status of evidence storage. By combining the length of the gap period with the real-time load of the current evidence storage system, the risk index of each business event data is calculated. Based on the risk level of the risk index, different evidence storage strategies are implemented for each business event data. The evidence storage strategies include evidence storage based on the real-time digital signatures of multiple participants corresponding to the business event data, and batch evidence storage after writing the business event data into the local buffer. After implementing different evidence preservation strategies, the calculation parameters of the risk index are dynamically optimized based on the actual evidence preservation window period of business event data and the tampering detection results.

[0006] In one possible implementation of this application, the length of the gap period is determined based on the occurrence time of the business event data and the status of evidence storage processing, including: Determine the completion time of the evidence storage of business event data based on the evidence storage processing status of the business event data. The length of the gap period is determined based on the difference between the time of completion of evidence storage and the time of occurrence.

[0007] In one possible implementation of this application, the risk index of each business event data is calculated by combining the length of the gap period with the real-time load of the current evidence storage system, including: The risk index of each business event data is calculated by weighting and integrating the length of the gap period and the real-time load of the current evidence storage system.

[0008] In one possible implementation of this application, before executing different evidence storage strategies for each business event data based on the risk level to which the risk index belongs, the method further includes: The risk index is compared with the first preset threshold and the second preset threshold, and the first preset threshold is greater than the second preset threshold. If the risk index is greater than or equal to the first preset threshold, the risk level corresponding to the current business event data will be set to a high risk level. If the risk index is greater than or equal to the second preset threshold and less than the first preset threshold, then the risk level corresponding to the current business event data will be set to the medium risk level. If the risk index is less than the second preset threshold, the risk level corresponding to the current business event data will be set to low risk level.

[0009] In one possible implementation of this application, different evidence preservation strategies are executed for each business event data based on the risk level to which the risk index belongs, including: If the risk level of the business event data is high, then an event anchor point is constructed and stored based on the real-time digital signatures of multiple participants corresponding to the business event data. If the risk level of the business event data is medium risk, the business event data will be written to the local buffer and real-time integrity monitoring will be performed until the preset period is reached, after which batch evidence storage will be performed. If the risk level of the business event data is low, the business event data will be written to the local buffer for batch storage, and the basic change log of the business event data will be retained.

[0010] In one possible implementation of this application, an event anchor is constructed and stored based on the real-time digital signatures of multiple participants corresponding to business event data, including: Extract the event data hash, event storage time, and anchor point hash corresponding to the previous business event data from the event source node corresponding to the current business event data; Based on the event data hash, the event storage time, the anchor point hash, and the business random number, generate a pre-stored certificate; Send the pre-stored certificate to multiple participants corresponding to the business event data, and receive the signature data fed back by multiple participants; If the number of participants in the signature data is greater than or equal to the preset consensus threshold, then an event anchor point is constructed and stored.

[0011] In one possible implementation of this application, business event data is written to a local buffer, and real-time integrity monitoring is performed until a preset period is reached, after which batch evidence storage is performed, including: Write all event metadata and temporary anchor hashes from the event source node corresponding to the business event data into the local buffer and perform real-time integrity monitoring. A hash tree is constructed based on multiple temporary anchor hashes within a preset period, and the root hash corresponding to the hash tree is submitted to the global evidence storage chain.

[0012] In one possible implementation of this application, the calculation parameters of the risk index are dynamically optimized based on the actual storage window period of business event data and the tampering detection results, including: The actual evidence storage gap period and business data tampering data of business events with different risk levels are obtained at preset time intervals. Based on the actual evidence storage gap period and business tampering data, the actual risk value of each business event data is calculated; The loss function value is calculated based on the difference between the actual risk value and the risk index. Based on the comparison between the loss function value and the preset loss threshold, the calculation parameters of the risk index are dynamically optimized.

[0013] In one possible implementation of this application, the calculation parameters of the risk index are dynamically optimized based on the comparison result between the loss function value and the preset loss threshold, including: Compare the loss function value with a preset loss threshold; If the loss function value is greater than the preset loss threshold, the difference between the actual risk value and the risk index does not meet the preset error standard. The weight coefficient of the risk index is then iteratively adjusted using the gradient descent method. If the loss function value is less than or equal to the preset loss threshold, the weighting coefficient of the risk index remains unchanged.

[0014] To achieve the above objectives, a trusted data storage system for the entire cross-border e-commerce order chain is also provided. The system includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it implements the steps of any of the aforementioned trusted data storage methods for the entire cross-border e-commerce order chain.

[0015] This application has, but is not limited to, the following technical effects: By acquiring business event data across the entire cross-border order chain, and quantifying the risk index of each business event data based on the length of its gap period, different evidence preservation strategies are implemented for different business event data according to the risk index. After implementing different evidence preservation strategies, the calculation parameters of the risk index are dynamically optimized based on the actual evidence preservation gap period of the business event data and the tampering detection results. This quantifies the risk of the gap period, and allows for real-time multi-party signature solidification or batch evidence preservation by writing business data of different risk levels into a local buffer. This effectively prevents data from being tampered with during the evidence preservation delay period, maintains a trustworthy system across the entire chain, and avoids difficulties in proving cross-border disputes. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the first embodiment of the trusted data storage method for the entire cross-border e-commerce order chain in this application. Figure 2 This is a schematic diagram of the device structure of the hardware operating environment involved in the embodiments of this application. Detailed Implementation

[0017] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0018] This application provides a method for end-to-end trusted data storage of cross-border e-commerce orders. In the first embodiment of this method, refer to... Figure 1 The methods include: Step S10: Obtain business event data throughout the entire cross-border order chain.

[0019] As an example, the trusted data storage method for the entire cross-border e-commerce order chain can also be applied to the trusted data storage system for the entire cross-border e-commerce order chain. The business event data can be the business data collected from each key business node in the entire cross-border order chain. By unifying the UTC time, the interference of cross-border time zone differences is eliminated, ensuring the consistency of time dimension calculation.

[0020] As an example, one way to obtain business event data could be: Operational Basis: Cross-border orders involve multiple heterogeneous systems (e-commerce platforms, payment gateways, warehousing / logistics systems, etc.). Non-intrusive collection of business event data from key nodes is required to avoid impacting the stability of existing business systems. The operational method is as follows: 1. Deploy lightweight data collection probes on the API interfaces or server side of core systems such as order creation, payment, warehousing, logistics, and customs clearance to support data capture via HTTP / HTTPS protocols; 2. For manual operations (such as manual customs clearance review and handling of abnormal orders), deploy desktop data collection probes on the operation terminal to record operation triggers and completion actions; 3. The fields to be collected include: timestamp of business event occurrence, JSON content of business data, evidence storage process identifier (e.g., D0=order creation, D1=payment), source system code (S0=e-commerce platform), manual operation flag (F=1 for manual intervention, 0 for automatic processing), and manual operation time (T_manual, only recorded when F=1).

[0021] This allows for the acquisition of standardized data across all stages of the entire process, with each business event corresponding to a unique identifier and time information, ensuring data collection integrity of ≥99.9%.

[0022] As an example, cross-border scenarios involve multiple time zones (such as domestic merchants, European and American consumers, and Southeast Asian logistics providers). Inconsistent local timestamps can lead to errors of several hours in calculating gap periods, necessitating conversion to UTC standard time to ensure consistency. Firstly, the acquired business event data needs to be preprocessed, specifically: 1. Extract the timestamps of the collected business events. The system converts the local timestamp to UTC time using the built-in time zone mapping table (e.g., UTC+8 corresponds to East 8 zone). 2. Perform format validation on the collected data, filter invalid data (such as empty timestamps and missing link identifiers), and complete the missing system coding information; 3. Store the preprocessed data in a distributed time-series database, partitioned by stage identifier, with a query response time of ≤2 seconds.

[0023] Results show that a standardized business event dataset with unified UTC timestamps was obtained, which can be directly used for subsequent window period calculations and risk assessments.

[0024] This completes the collection and standardized preprocessing of full-link business event data, providing a reliable raw data foundation for subsequent analysis.

[0025] Step S20: Determine the length of the gap period based on the occurrence time of the business event data and the status of evidence storage.

[0026] As an example, existing cross-border e-commerce end-to-end evidence storage mostly adopts centralized asynchronous, batch, or callback-triggered methods, resulting in a delay of several hours to half a day from the occurrence of the business to the completion of evidence storage. During this window period, core data such as orders, payments, logistics, and customs declarations lack protection and are easily tampered with. Moreover, the cross-border participants are heterogeneous and independent, making it difficult to uniformly manage the window period. If data is tampered with at any stage, it will directly destroy the end-to-end trust system built on timestamps and hash chains.

[0027] Therefore, this application quantifies the length of the gap period based on the collected business event data and evidence storage system data, assesses the risk level by combining the multi-dimensional characteristics of cross-border scenarios, provides decision-making for differentiated evidence storage triggers, and establishes a dynamic baseline model to adapt to changes in cross-border scenarios.

[0028] As an example, the window period length represents the time interval between the occurrence time of any business event data and the evidence storage time. It is a core basic indicator for assessing the risk of data lack of protection, and the evidence storage completion timestamp needs to be accurately obtained.

[0029] Step S20 includes: Determine the completion time of the evidence storage of business event data based on the evidence storage processing status.

[0030] The length of the gap period is determined based on the difference between the time of completion of evidence storage and the time of occurrence.

[0031] As an example, by connecting to the consortium blockchain's evidence storage system via a RESTful API, the system obtains the evidence storage completion timestamp for the corresponding business event. Using the order number and stage identifier as unique keys, the system matches the occurrence time of the business event with the evidence storage completion time for the same business event, and calculates the window length of any business event data. The calculation formula is as follows: In the formula, This indicates the time point at which the evidence storage for a business event was completed. Indicates the point in time when the business event occurred; Events for which evidence storage has not been completed are marked as "Pending Evidence Storage". For now, let's record it as the current UTC time. The difference is updated in real time every 5 minutes. Based on this, a dataset of the window period length corresponding to each business event data is obtained, including the final window period of the evidence-verified events and the real-time window period of the events to be evidence-verified.

[0032] Step S30: Combine the length of the gap period with the real-time load of the current evidence storage system to calculate the risk index of each business event data.

[0033] As an example, the risk index is used to represent the degree of risk that any business event data may be tampered with during a window period. The higher the risk index, the more easily the business event data can be tampered with. By combining the window period length with the real-time load of the current evidence storage system, and using the real-time load as a dynamic adjustment factor, the risk index can reflect the current health status of the infrastructure.

[0034] Step S30 includes: The risk index of each business event data is calculated by weighting and integrating the length of the gap period and the real-time load of the current evidence storage system.

[0035] As an example, cross-border e-commerce evidence storage has an exposure window of several hours or even half a day—that is, the time period between the occurrence of a business event and the completion of evidence storage. During this window, the data is in an "unprotected and tamper-proof" state. However, not all events have the same level of risk during the window. Therefore, it is necessary to quantify the comprehensive risk of each event during the window and then calculate the risk index of each business event's data.

[0036] As an example, the risk index of the i-th business event data corresponds to the event. The calculation method is as follows: In the formula, Indicates the length of the gap period. This represents the real-time load, indicating the current resource utilization rate of the evidence storage system. Its value is fixed between [0, 1] (for example, 0.8 represents a load of 80%), and is usually the maximum value among CPU utilization, memory utilization, or the system's concurrent processing limit. , Represents the weighting coefficient, where, The value is greater than or equal to the first preset threshold, for example, k represents the preset time constant, which can be 300 to 1800 (in seconds) to avoid excessively rapid exponential decay.

[0037] The longer the window period, the longer the data is exposed to a tamperable state, and the greater the opportunity for attackers to find vulnerabilities or implement modifications. Furthermore, when the system load is too high, evidence processing may be delayed or queued, resulting in a larger actual evidence window period. At the same time, security monitoring may be degraded under high load, making it more difficult to detect tampering in real time.

[0038] Before step S40, the following are included: The risk index is compared with a first preset threshold and a second preset threshold, and the first preset threshold is greater than the second preset threshold.

[0039] If the risk index is greater than or equal to the first preset threshold, the risk level corresponding to the current business event data will be set to high risk level.

[0040] If the risk index is greater than or equal to the second preset threshold but less than the first preset threshold, the risk level corresponding to the current business event data will be set to medium risk level.

[0041] If the risk index is less than the second preset threshold, the risk level corresponding to the current business event data will be set to low risk level.

[0042] As an example, the first preset threshold can be 0.7, 0.8, etc., and can be changed according to the user's needs. There is no specific limitation.

[0043] As an example, the second preset threshold can be 0.3, 0.4, etc., and can be changed according to user needs; no specific limit is imposed.

[0044] As an example, taking a first preset threshold of 0.7 and a second preset threshold of 0.3 as an example, based on the risk index of the window period for different events obtained from the above calculation, the risks are classified. When, it indicates that the current risk level is high; when At that time, it was classified as a medium-risk level; when At that time, it is considered a low-risk level; then, the event is signed and solidified according to different risk levels.

[0045] Step S40: Based on the risk level of the risk index, execute different evidence storage strategies for each business event data. The evidence storage strategies include evidence storage based on the real-time digital signatures of multiple participants corresponding to the business event data, and batch evidence storage after writing the business event data into the local buffer. As an example, different evidence preservation strategies need to be implemented for business event data with different risk levels. For instance, high-risk business event data requires multi-party verification before evidence preservation. For medium-risk business event data, it is written to a local buffer, and data tampering is monitored in real time during batch evidence preservation. Low-risk business event data can be preserved normally. By using different evidence preservation strategies, real-time monitoring of data can be achieved while reducing resource waste.

[0046] Step S40 includes steps S41 to S43: Step S41: If the risk level of the business event data is high risk, then based on the real-time digital signatures of multiple participants corresponding to the business event data, construct event anchors and store evidence.

[0047] As an example, when the risk level of business event data is determined to be high-risk, the source node corresponding to the business event data is identified. Data extracted from the source node is used to generate a pre-stored certificate, which is then sent to all participants in the current event for confirmation. Subsequently, an event anchor is constructed and stored. The event anchor consists of the pre-stored certificate and signatures from multiple participants that meet a preset consensus threshold. It strongly binds the original business data, timestamps, and credit endorsements from multiple parties, serving as the unique and tamper-proof definite node for this business event in the evidence storage system.

[0048] Step S41 includes: Extract the event data hash, event storage time, and anchor point hash corresponding to the previous business event data from the event source node corresponding to the current business event data.

[0049] Based on the event data hash, the event storage time, the anchor hash, and the business random number, a pre-stored certificate is generated.

[0050] As an example, pre-deposited certificates Represented as: In the formula, Represents a random number. Represents event data hash, This is the timestamp of the current evidence storage moment obtained from an authoritative time server, which is also the event evidence storage moment. This represents the anchor hash corresponding to the previous business event data. The anchor hash is a fixed-length hash value generated for each business event, used to uniquely identify the evidence anchor point of the event after it has been solidified through multi-party signatures. It represents the digital fingerprint of the event evidence certificate. It determines whether there is previous business event data. If not, the preset initial genesis hash is used as the preceding anchor hash. If it exists, the anchor hash corresponding to the previous business event data is extracted.

[0051] The pre-stored certificate is sent to multiple participants corresponding to the business event data, and the signature data fed back by multiple participants is received.

[0052] As an example, The data is sent to all relevant parties involved in the event (such as buyers, sellers, platforms, logistics providers, customs, etc.). Each party verifies the authenticity of the data within 50ms of receiving it and uses its own private key. Generate signature data Returned to the event source node, where, The fixed-length digital digest (fingerprint) obtained after hashing the pre-stored evidence credential (FH) is defined as the hash value of the pre-stored evidence credential FH, i.e. .

[0053] If the number of participants in the signature data is greater than or equal to the preset consensus threshold, then an event anchor point is constructed and stored.

[0054] As an example, the preset consensus threshold can be 3, 4, etc., such as at least 3 different participants including the platform. After collecting the signature data, an event anchor is constructed, and then the anchor hash of the current event is calculated. The anchor hash is the digital fingerprint of the business event after it has been signed and solidified. The calculation formula is: anchor hash = Hash(FH || ΣSigp), where || represents byte concatenation, and ΣSigp represents the set of all received signatures from the participants.

[0055] Step S42: If the risk level of the business event data is medium risk, the business event data is written to the local buffer and real-time integrity monitoring is performed until the preset period is reached, after which batch evidence is stored.

[0056] As an example, for business event data of medium risk level, real-time integrity monitoring is performed during the evidence storage process. If any process is detected attempting to modify a data block in the buffer, the system immediately records the change log, raises the risk level of the event to high risk, triggers the immediate solidification process, and sends the change log to all participants as evidence.

[0057] Step S42 includes: Write all event metadata and temporary anchor hashes from the event source node corresponding to the business event data into the local buffer and perform real-time integrity monitoring.

[0058] As an example, all event metadata and temporary anchor hashes in the event source node corresponding to the business event data are written to the local buffer, and a "pending certificate" notification is sent to the coordinating node. During the writing process, real-time integrity monitoring is performed, and the temporary anchor hash is generated based on the event data hash, current timestamp, and source node signature of the business event data.

[0059] A hash tree is constructed based on multiple temporary anchor hashes within a preset period, and the root hash corresponding to the hash tree is submitted to the global evidence storage chain.

[0060] As an example, the preset period can be 30 seconds, 40 seconds, etc., and there is no specific limitation.

[0061] As an example, the coordinating node collects the anchor hashes of all medium-risk events within the current period every 30 seconds (preset period) and constructs a Merkle tree. The Merkle tree is a hash tree data structure. The bottom nodes store the hash values ​​of each independent event. Adjacent hash values ​​are merged to calculate the hash of the upper level. This process is repeated layer by layer upwards, and finally a unique root hash is generated at the top.

[0062] The root hash is submitted to the global evidence storage chain. Any change to any data at the bottom level of the hash tree will cause the top root hash to change. After the batch submission is completed, the evidence storage completion time is recorded. When the root hash is confirmed in the global evidence storage chain, the coordinating node returns the evidence storage receipt to the source node, and the source node releases the data block space corresponding to its local buffer accordingly.

[0063] Step S43: If the risk level of the business event data is low, the business event data is written to the local buffer for batch storage and the basic change log of the business event data is retained.

[0064] As an example, for low-risk business event data, the system performs batch storage without enabling real-time monitoring, but retains basic change logs.

[0065] Step S50: After executing different evidence preservation strategies, dynamically optimize the calculation parameters of the risk index based on the actual evidence preservation window period of the business event data and the tampering detection results.

[0066] As an example, after implementing different evidence preservation strategies, it is also necessary to dynamically optimize the weighting coefficients of the risk index based on the actual tampering detection results, in order to modify potential vulnerabilities and ensure that the calculated risk index can accurately reflect the real risks.

[0067] Step S50 includes: The system retrieves data on business events of different risk levels at preset time intervals, including the actual evidence storage gaps and data tampering.

[0068] Based on the actual evidence storage gap period and business data tampering, the actual risk value of each business event data is calculated.

[0069] As an example, the preset time period can be 24 hours, and the system will calculate the actual evidence storage gap period for business event data of each risk level every 24 hours. This includes business tampering data such as the number of tampering attempts detected during the window period and the tampering success rate (i.e., the proportion of tampered data that was not captured by the change log).

[0070] As an example, taking the data of the j-th business event as an example, the actual risk value The calculation method can be: In the formula, The actual period of evidence preservation for subsequent records. The tampering indicator function (sets to 1 if event j is tampered with but not captured by the log during the empty window, otherwise sets to 0). and Preset constant weights (e.g.) =0.5, =0.5, guaranteeing (between 0 and 1) This represents the preset time constant, with a recommended value of 300 to 1800 (in seconds), defining the system's baseline exposure time.

[0071] The loss function value is calculated based on the difference between the actual risk value and the risk index.

[0072] As an example, the loss function value represents the result of calculating the loss function L, which is expressed as: ² in, This indicates the total number of events within a preset time period. Indicates the risk index. This represents the actual risk value.

[0073] Based on the comparison between the loss function value and the preset loss threshold, the calculation parameters of the risk index are dynamically optimized.

[0074] As an example, the preset loss threshold is expressed as The value ranges from 0.05 to 0.1. When the loss function value > 0.05, it means that the root mean square error between the predicted and actual values ​​reaches approximately 22% (√0.05). In engineering terms, this indicates a significant deviation in the current risk assessment, triggering gradient descent to optimize the weight coefficients. and This is reasonable and insightful, particularly in the use of gradient descent to adjust the coefficient of the open-ended option in the risk index. Perform one-dimensional unidirectional iterative adjustment, with fixed load-related evaluation weights. Unchanged. (Regarding) After iterative adjustments, and Perform normalization (the normalization method can be the sigmoid function) and enforce constraints. .

[0075] The step of dynamically optimizing the calculation parameters of the risk index based on the comparison between the loss function value and the preset loss threshold includes: Compare the loss function value with a preset loss threshold; If the loss function value is greater than the preset loss threshold, the difference between the actual risk value and the risk index does not meet the preset error standard. The weight coefficient of the risk index is then iteratively adjusted using the gradient descent method. As an example, the loss function value > This indicates that the current risk assessment is significantly biased, and priority should be given to reducing the window period between high-risk events and adjusting the weights in the risk index calculation formula. and Dynamic iterative adjustments are performed, using gradient descent, a well-known technique that will not be elaborated upon here.

[0076] If the loss function value is less than or equal to the preset loss threshold, the weighting coefficient of the risk index remains unchanged.

[0077] As an example, if the loss function value This indicates that the risk assessment is accurate and the evidence preservation strategy is reasonable. The current weights remain unchanged, and only the baseline of the actual evidence preservation window period for each risk level is updated synchronously.

[0078] Furthermore, the system establishes an anomaly warning mechanism. When the loss function L continues to rise for two consecutive statistical periods, or the tampering success rate of a certain risk level event exceeds 5% (based on experience), the system will immediately trigger an alert, notifying operations and maintenance personnel to investigate the evidence storage link, system load, and participant signature verification process, and promptly fix potential vulnerabilities.

[0079] If a cross-border participant is detected to have frequent tampering attempts or signature anomalies, that participant will be added to an anomaly list, its data interaction permissions will be restricted, and the information will be synchronized to all related participants and regulatory agencies to ensure the authority of the end-to-end evidence storage system.

[0080] This application provides a method for trusted data storage across the entire cross-border e-commerce order chain. By acquiring business event data from the entire cross-border order chain, and quantifying the risk index of each business event data based on the length of its gap period, different storage strategies are implemented for different business event data according to the risk index. After implementing different storage strategies, the calculation parameters of the risk index are dynamically optimized based on the actual storage gap period of the business event data and the tampering detection results, thereby quantifying the risk of the gap period. Business data with different risk levels are then immediately multi-party signed and solidified or written to a local buffer for batch storage, effectively preventing data tampering during the storage delay period, maintaining a trusted system across the entire chain, and avoiding difficulties in proving cross-border disputes.

[0081] This application embodiment also provides a cross-border e-commerce order end-to-end trusted data storage system. The system includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it implements the steps of any of the above-mentioned cross-border e-commerce order end-to-end trusted data storage methods.

[0082] Reference Figure 2 , Figure 2 This is a schematic diagram of the device structure of the hardware operating environment involved in the embodiments of this application.

[0083] like Figure 2 As shown, the trusted data storage device for the entire cross-border e-commerce order chain may include: a processor 1001, a memory 1003, and a communication bus 1002. The communication bus 1002 is used to realize the connection and communication between the processor 1001 and the memory 1003.

[0084] Optionally, the trusted data storage device for the entire cross-border e-commerce order chain may also include a user interface, a network interface, a camera, RF (Radio Frequency) circuitry, sensors, a WiFi module, etc. The user interface may include a display screen and an input submodule such as a keyboard; optional user interfaces may also include standard wired or wireless interfaces. The network interface may include standard wired or wireless interfaces (such as a Wi-Fi interface).

[0085] Those skilled in the art will understand that Figure 2 The structure of the trusted data storage device for the entire cross-border e-commerce order chain shown in the figure does not constitute a limitation on the trusted data storage device for the entire cross-border e-commerce order chain. It may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0086] like Figure 2 As shown, the memory 1003, serving as a storage medium, may include an operating system, a network communication module, and a trusted data storage program for the entire cross-border e-commerce order chain. The operating system is a program that manages and controls the hardware and software resources of the trusted data storage device for the entire cross-border e-commerce order chain, supporting the operation of the trusted data storage program for the entire cross-border e-commerce order chain and other software and / or programs. The network communication module is used to enable communication between the various components within the memory 1003, as well as communication with other hardware and software in the trusted data storage system for the entire cross-border e-commerce order chain.

[0087] exist Figure 2 In the cross-border e-commerce order end-to-end trusted data storage device shown, the processor 1001 is used to execute the cross-border e-commerce order end-to-end trusted data storage program stored in the memory 1003 to implement the steps of the cross-border e-commerce order end-to-end trusted data storage method described above.

[0088] The specific implementation method of the cross-border e-commerce order end-to-end trusted data storage device in this application is basically the same as the embodiments of the above-mentioned cross-border e-commerce order end-to-end trusted data storage method, and will not be repeated here.

[0089] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0090] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0091] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0092] The above are merely preferred embodiments of this application and do not limit the scope of this application. Any equivalent structural or procedural transformations made based on the description and drawings of this application, or direct or indirect applications in other related technical fields, are similarly included within the scope of protection of this application.

[0093] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. The processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0094] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

Claims

1. A method for trusted data storage and notarization of cross-border e-commerce orders across the entire supply chain, characterized in that, The method includes: Acquire business event data throughout the entire cross-border order process; The length of the real-time window period is determined based on the occurrence time of the business event data and the evidence storage processing status. By combining the real-time window period length with the real-time load of the current evidence storage system, the risk index of each business event data is calculated. Based on the risk level of the risk index, different evidence storage strategies are executed for each of the business event data. The evidence storage strategies include evidence storage based on the real-time digital signatures of multiple participants corresponding to the business event data, and batch evidence storage after writing the business event data into a local buffer. After implementing different evidence preservation strategies, the calculation parameters of the risk index are dynamically optimized based on the actual evidence preservation window period of the business event data and the tampering detection results.

2. The method for trusted data storage of cross-border e-commerce orders across the entire supply chain as described in claim 1, characterized in that, The step of determining the length of the real-time window period based on the occurrence time of the business event data and the evidence storage processing status includes: Based on the evidence storage processing status of the business event data, the business event data is determined to be either an event that has been stored or an event that is pending evidence storage. If the business event data is a documented event, then extract the documented event completion time; if the business event data is a documented event, then extract the current time. The length of the real-time window period is determined based on the difference between the current time point and the time point of occurrence.

3. The method for trusted data storage of cross-border e-commerce orders across the entire supply chain as described in claim 2, characterized in that, The step of combining the real-time window period length with the real-time load of the current evidence storage system to calculate the risk index of each business event data includes: The risk index of each business event data is calculated by weighting and fusing the real-time window period length and the real-time load of the current evidence storage system.

4. The method for trusted data storage and evidence preservation of cross-border e-commerce orders across the entire supply chain as described in claim 1, characterized in that, Before implementing different evidence preservation strategies for each business event data based on the risk level of the risk index, the method further includes: The risk index is compared with a first preset threshold and a second preset threshold, wherein the first preset threshold is greater than the second preset threshold; If the risk index is greater than or equal to the first preset threshold, the risk level corresponding to the current business event data is set to a high risk level. If the risk index is greater than or equal to the second preset threshold and less than the first preset threshold, then the risk level corresponding to the current business event data is set to the medium risk level. If the risk index is less than the second preset threshold, the risk level corresponding to the current business event data will be set to low risk level.

5. The method for trusted data storage of cross-border e-commerce orders across the entire supply chain as described in claim 4, characterized in that, The step of implementing different evidence storage strategies for each business event data based on the risk level of the risk index includes: If the risk level of the business event data is high risk, then an event anchor point is constructed and stored based on the real-time digital signatures of multiple participants corresponding to the business event data. If the risk level of the business event data is medium risk, the business event data will be written to the local buffer and real-time integrity monitoring will be performed until the preset period is reached, after which batch evidence storage will be performed. If the risk level of the business event data is low, the business event data will be written to the local buffer for batch storage and the basic change log of the business event data will be retained.

6. The method for trusted data storage of cross-border e-commerce orders across the entire supply chain as described in claim 5, characterized in that, The process of constructing event anchors and storing evidence based on real-time digital signatures of multiple participants corresponding to business event data includes: Extract the event data hash, event storage time, and anchor point hash corresponding to the previous business event data from the event source node corresponding to the current business event data; Based on the event data hash, event storage time, anchor point hash, and business random number, a pre-stored certificate is generated. The pre-stored certificate is sent to multiple participants corresponding to the business event data, and the signature data fed back by the multiple participants is received. If the number of participants in the signature data is greater than or equal to a preset consensus threshold, then an event anchor point is constructed and stored.

7. The method for trusted data storage of cross-border e-commerce orders across the entire supply chain as described in claim 5, characterized in that, The step of writing business event data to a local buffer and performing real-time integrity monitoring until a preset period is reached, followed by batch storage of evidence, includes: Write all event metadata and temporary anchor hashes from the event source node corresponding to the business event data into the local buffer and perform real-time integrity monitoring. A hash tree is constructed based on multiple temporary anchor hashes within a preset period, and the root hash corresponding to the hash tree is submitted to the global evidence storage chain.

8. The method for trusted data storage and notarization of cross-border e-commerce orders across the entire supply chain as described in claim 1, characterized in that, The step of dynamically optimizing the calculation parameters of the risk index based on the actual evidence storage window period of the business event data and the tampering detection results includes: The actual evidence storage gap period and business tampering data of business event data with different risk levels are obtained at preset time intervals. The actual evidence storage gap period is calculated based on the difference between the evidence storage completion time and the occurrence time of the business event data. Based on the actual evidence storage gap period and the business tampering data, the actual risk value of each of the business event data is calculated. The loss function value is calculated based on the difference between the actual risk value and the risk index. Based on the comparison between the loss function value and the preset loss threshold, the calculation parameters of the risk index are dynamically optimized.

9. The method for trusted data storage and evidence preservation of cross-border e-commerce orders across the entire supply chain as described in claim 8, characterized in that, The dynamic optimization of the calculation parameters of the risk index based on the comparison result between the loss function value and the preset loss threshold includes: The loss function value is compared with a preset loss threshold; If the loss function value is greater than the preset loss threshold, then the difference between the actual risk value and the risk index does not meet the preset error standard, and the weight coefficient of the risk index is iteratively adjusted by the gradient descent method. If the loss function value is less than or equal to the preset loss threshold, the weighting coefficient of the risk index remains unchanged.

10. A trusted data storage system for the entire cross-border e-commerce order chain, characterized in that, The system includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the method as described in any one of claims 1 to 9.

Images