Block chain-based trusted data sharing system in electronic commerce digital insight

Abstract

The invention discloses a trusted data sharing system based on a block chain in electronic commerce digital insight, and relates to the technical field of data sharing. The system comprises a block chain node networking-consensus verification module, a cross-chain state synchronization module, an on-chain and off-chain hybrid storage and index module and a digital insight service interface module. According to the invention, the blockchain node networking and consensus verification module ensures the real-time performance of data circulation by using the cross-chain state synchronization module, the on-chain and off-chain hybrid storage and index module ensures the consistency of global data, and finally, the digital insight service interface module externally provides trusted data service after aggregation verification. Therefore, efficient and reliable e-commerce full-link digital insights are supported, and the real-time performance of trusted data sharing in the e-commerce digital insights is improved. The problems of low real-time performance and consistency of credible data sharing in electronic commerce digital insight caused by mismatching of a consensus mechanism and a high-frequency scene and complex cross-chain collaborative verification exist in the prior art.

Description

Technical Field

[0001] This invention relates to the field of data sharing technology, and in particular to a blockchain-based trusted data sharing system for e-commerce digital insights. Background Technology

[0002] In e-commerce digital insights, the first step in identity trust and data encapsulation involves data providers (such as e-commerce platforms and logistics companies) using a cross-chain identity collaboration module to generate a decentralized identity credential (DID-UC) based on zero-knowledge proofs. This DID-UC is then synchronized to consortium blockchain nodes via a cross-chain oracle, ensuring the verifiability of participants' identities. Simultaneously, a data asset encapsulation module encapsulates product and user behavior data into structured DataPod objects, containing data ontology, metadata tags, and access control policies. After encapsulation, these objects are signed by consensus nodes to generate NFT (Non-Fungible Token) credentials.

[0003] Secondly, in the authorization application and encrypted transmission stages, the data user queries the required data through a unified directory. After initiating a usage application, both parties sign a digital contract based on a smart contract, clarifying the scope, frequency, and settlement rules of use. During the transmission phase, the smart routing relay module selects the optimal path through the Gossip (Gossip Protocol) protocol, splits the DataPod into encrypted data fragments, and transmits them relayed through multiple relay nodes. At the same time, quantum key distribution technology is used to build a secure channel.

[0004] Finally, in the compliant use and traceability settlement process, the data recipient uses the data within the data sandbox according to contractual permissions. Federated learning enables joint modeling, with only encrypted gradient updates uploaded; the original data remains within the domain. Differential privacy and secure multi-party computation technologies are integrated to protect privacy. The entire operation log is stored on the blockchain through the cross-domain traceability audit module, generating an immutable traceability graph through block retrieval. In the settlement process, the tokenized incentive settlement module automatically calculates resource consumption according to smart contracts, completing value transfer between platforms through Token-EBC (Token - Electronic Business Certificate), achieving a closed-loop incentive for data sharing.

[0005] For example, Chinese invention patent CN120707250A discloses a blockchain-based e-commerce multi-platform data interaction system and method, including a system operation terminal and a system monitoring terminal. The system operation terminal includes a cross-chain identity collaboration module, a data asset encapsulation module, an intelligent routing relay module, a distributed event processing module, a cross-domain traceability audit module, and a tokenized incentive settlement module. This invention generates zero-knowledge proof credentials when users register. When the platform needs to share data, it encapsulates product information, etc., into structured DataPods, selects the optimal path through the Gossip protocol, and transmits DataPods in encrypted sharding form. When a cross-platform transaction is triggered, an Event-Saga transaction chain is generated. The value generated by data interaction is settled in real time by the tokenized incentive settlement module, and the entire process is monitored by the cross-domain traceability audit module.

[0006] For example, Chinese invention patent CN116883012A discloses an e-commerce data processing method and system, which includes: when it is detected that the data of similar products in a certain delivery area meets the quantitative conditions, executing the product local processing service option; statistically analyzing the product data of users under the product local processing service option, and generating related product data between at least two products based on the correlation information of the product data; sharing the related product data to the purchase interface of each user corresponding to at least two products; and when it is detected that there are at least two parties' processing needs for related products in the related product data among users, performing qualification detection of related products in a set area within a certain delivery area.

[0007] The above-mentioned technology has at least the following technical problems: In existing technologies, firstly, the isolation problem of multi-chain architecture is prominent in e-commerce consortium blockchains. For example, retail e-commerce platforms build transaction chains based on Hyperledger Fabric to store consumer data such as user orders, payments, and reviews; while supply chain partners use Ethereum to build logistics chains to record logistics information such as warehousing, transportation, and receipt. This results in the inability to link consumer data and logistics data in real time. For example, when a user queries "order logistics progress," the order information in the transaction chain and the transportation node data in the logistics chain are difficult to match quickly. The end-to-end analysis of "consumer behavior - logistics fulfillment" required for digital insights cannot be completed efficiently, and even business problems such as inventory misjudgment and delivery delays caused by data synchronization delays occur. The data synchronization success rate drops significantly, and in some scenarios, there is even a risk of data loss or tampering.

[0008] The block storage and transaction processing capabilities of a single chain are completely inadequate to meet peak demand: on the one hand, the block size limit causes a large number of transactions to be backed up in the mempool, and the preemptive transaction strategies of users and bots further squeeze legitimate evidence storage requests, with some operation logs having to wait for hours or even days before being uploaded to the chain; on the other hand, block propagation delays exacerbate congestion, and the difference in the speed at which different nodes receive data causes temporary forks, requiring some transactions to be verified repeatedly, further reducing processing efficiency.

[0009] Secondly, the block storage and transaction processing capabilities of a single chain are completely inadequate to meet peak demand. On the one hand, the block size limit causes a large number of transactions to be backed up in the mempool, and the preemptive trading strategies of users and bots further squeeze legitimate evidence storage requests. Some operation logs have to wait for hours or even days before they can be uploaded to the chain. On the other hand, block propagation delays exacerbate congestion, and the difference in the speed at which different nodes receive data causes temporary forks. Some transactions need to be verified repeatedly, further reducing processing efficiency. For example, during a major promotion on an e-commerce platform, the data storage delay of cross-chain shared logistics nodes was long, making it impossible to quickly retrieve the complete logistics trajectory during after-sales rights protection. At the same time, a large number of unconfirmed transactions occupied node resources, causing the on-chain data query response time to soar from the normal millisecond level to tens of seconds, seriously affecting the real-time nature of digital insights.

[0010] Finally, in e-commerce cross-chain scenarios, data sharing needs to ensure cross-chain consistency and traceability. Sharding technology leads to fragmented data storage, increasing the complexity of cross-shard verification. Furthermore, the design intent of consensus algorithms is mismatched with the needs of e-commerce scenarios. Most consensus mechanisms are not designed for millisecond-level high-frequency transactions. High-frequency block creation puts enormous pressure on validators, leading to frequent issues such as validator misalignment and incorrect penalties, limiting throughput improvement. This results in low real-time performance and consistency of trusted data sharing in e-commerce digital insights due to the mismatch between consensus mechanisms and high-frequency scenarios, as well as the complexity of cross-chain collaborative verification. Summary of the Invention

[0011] To address the technical problems of low real-time performance and consistency of trusted data sharing in e-commerce digital insights caused by the mismatch between consensus mechanisms and high-frequency scenarios, and the complexity of cross-chain collaborative verification, this invention provides a blockchain-based trusted data sharing system for e-commerce digital insights. The technical solution is as follows: On one hand, it provides a blockchain-based trusted data sharing system for e-commerce digital insights. This system includes: a blockchain node networking-consensus verification module, a cross-chain state synchronization module, an on-chain / off-chain hybrid storage and indexing module, and a digital insight service interface module. The blockchain node networking-consensus verification module includes multiple node units that verify the identities of nodes joining the network. Verified nodes can participate in blockchain data interaction, enabling data consensus verification among nodes. The cross-chain state synchronization module obtains real-time parameters in e-commerce multi-chain and single-chain scenarios. Based on these parameters, it quantifies the efficiency of e-commerce cross-chain data synchronization from generation to completion of on-chain notarization and cross-chain synchronization, and its queryability. The system determines whether to implement intelligent control over cross-chain data synchronization to dynamically optimize resource allocation and improve the timeliness of e-commerce digital insights. The on-chain / off-chain hybrid storage and indexing module obtains consensus consistency parameters to achieve cross-chain data consensus consistency in e-commerce. This quantifies whether the verification results of shared data by multiple chain nodes are completely consistent. Based on the cross-chain data consensus consistency, the system determines whether to implement intelligent control over cross-chain data consistency to proactively prevent and resolve state forks and data conflicts in an asynchronous multi-chain environment. This provides a single source of fact for upper-layer digital insight analysis and ensures the reliability of cross-chain data. The digital insight service interface module receives and parses consensus-verified e-commerce business query requests, aggregates trusted data in parallel, embeds blockchain proofs, and outputs trusted e-commerce digital insight data results.

[0012] Beneficial effects

[0013] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following: By verifying the identities of multiple nodes joining the network, verified nodes can participate in blockchain data interaction, achieving data consensus verification among nodes. Real-time parameters are obtained from e-commerce multi-chain and single-chain scenarios. Based on these parameters, the real-time performance of e-commerce cross-chain data synchronization is determined. This quantifies the efficiency of target data (such as consumer order data, logistics node data, and operation logs) from generation to completion of on-chain notarization and cross-chain synchronization, making it queryable and retrievalable. The real-time performance of e-commerce cross-chain data synchronization determines whether to implement intelligent control of cross-chain data synchronization to dynamically optimize resource allocation and improve the timeliness of e-commerce digital insights. Finally, consensus parameters are obtained to achieve e-commerce cross-chain data consensus. Consistency is an indicator used to quantify whether the verification results of shared data (such as order-logistics related data and evidence logs) among multi-chain nodes (such as transaction chain and logistics chain nodes) are completely consistent. Based on the consensus consistency of e-commerce cross-chain data, it determines whether to implement intelligent control of e-commerce cross-chain data consistency to proactively prevent and resolve state forks and data conflicts in a multi-chain asynchronous environment. This provides a single source of fact for upper-layer digital insight analysis, ensures the reliability of cross-chain data, receives and parses consensus-verified e-commerce business query requests, aggregates trusted data in parallel, embeds blockchain proofs, and outputs trusted e-commerce digital insight data results, thereby improving the real-time sharing of trusted data in e-commerce digital insights.

[0014] The system dynamically adjusts the transaction on-chain confirmation latency threshold based on the number of cross-chain data shards used in e-commerce. By establishing a quantitative response relationship between the number of shards and the system's processing complexity, the system can intelligently relax latency requirements when the increased number of shards leads to a heavier burden on cross-shard verification and state synchronization, preventing a large number of legitimate transactions from being mistakenly judged as timeouts due to congestion. Conversely, when there are fewer shards and the cross-chain load is lighter, the latency standard is automatically tightened to fully exploit potential performance. This ensures that under dynamically changing network topology and load conditions, the system maintains an optimal balance between transaction processing success rate and overall system throughput, guaranteeing the smoothness of end-to-end data collaboration and business continuity. The system also adjusts the latency based on cross-chain bridge data relay delays. By dynamically adjusting the average latency tolerance window for e-commerce data synchronization and constructing an elastic timeout mechanism that is linked in real time with cross-chain transmission performance, the time tolerance boundary for end-to-end synchronization can be adaptively relaxed when the latency of the cross-chain bridge increases. This effectively absorbs the transmission degradation caused by relay network fluctuations, verification congestion, or peak load, and avoids a large amount of data that could eventually be successfully synchronized being prematurely judged as failed and triggering invalid retries or alarms due to rigid fixed timeout thresholds. Under the premise of ensuring eventual data consistency, the robustness, success rate, and overall resource utilization efficiency of the cross-chain synchronization process are significantly improved, thereby enhancing the real-time reliability of trusted data sharing in e-commerce digital insights.

[0015] By dynamically adjusting the block tolerance capacity threshold based on the mempool waiting time, a flexible block capacity control mechanism is constructed that is linked in real time to the intensity of transaction backlog. This allows for an intelligent, step-by-step temporary increase in the maximum number of transactions a single block can accommodate when the mempool waiting time significantly increases, indicating a bottleneck in network transaction processing. This controllably expands the processing batch size for a single consensus, accelerates the clearing of the mempool backlog, and effectively alleviates network congestion. While avoiding the indefinite deterioration of transaction confirmation delays due to fixed capacity limitations, security boundary constraints (such as propagation time monitoring) prevent new network forks or synchronization delays caused by excessively large blocks. This systematically optimizes the balance between transaction throughput, confirmation speed, and network stability under dynamic load. The block capacity threshold is also dynamically adjusted based on the on-chain data query response time. The block packaging interval window is designed to adjust the block production pace in real time, in conjunction with the data query service quality. This allows the system to intelligently and appropriately extend the block packaging interval when the query response time reaches the warning range due to node resource contention (such as excessive CPU and I / O being occupied by frequent block production and verification tasks). This frees up more computing and storage resources for all nodes to prioritize the processing capacity of the query service. Without excessively sacrificing the final transaction confirmation speed, this effectively alleviates the resource conflict between "block production" and "data service," ensuring efficient and stable response of on-chain historical and state data to analytical query requests. It also guarantees the real-time performance and user experience of upper-layer digital insight applications, thereby improving the real-time reliability of trusted data sharing in e-commerce digital insights. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A schematic diagram of the structure of a blockchain-based trusted data sharing system for e-commerce digital insights provided in this application embodiment; Figure 2 A flowchart illustrating the latency tolerance window optimization process of a blockchain-based trusted data sharing system for e-commerce digital insights provided in this application embodiment; Figure 3 A flowchart illustrating the block packaging interval optimization process of a blockchain-based trusted data sharing system for e-commerce digital insights provided in this application embodiment. Detailed Implementation

[0018] The technical solution provided in this application will now be described with reference to the accompanying drawings.

[0019] To facilitate understanding of the embodiments of this application, the following points will be explained first: First, in this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates an "or" relationship between the preceding and following related objects, but it does not exclude the possibility of indicating an "and" relationship; the specific meaning can be understood in context. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c; a and b; a and c; b and c; or a and b and c. Here, a, b, and c can be single or multiple.

[0020] Second, the use of prefixes such as "first" and "second" in this application is solely for the purpose of distinguishing and describing different things belonging to the same category, and does not constrain the order, size, or quantity of things. For example, "first message" and "second message" are simply different messages, and there is no chronological, size, or priority relationship between them.

[0021] In this embodiment of the invention, sometimes a subscript such as W1 may be written in a non-subscript form such as W1. When the difference is not emphasized, the meaning they express is the same.

[0022] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0023] like Figure 1 The diagram shown is a structural schematic of a blockchain-based trusted data sharing system for e-commerce digital insights provided in this application embodiment. The blockchain-based trusted data sharing system for e-commerce digital insights provided in this application embodiment includes: a blockchain node networking-consensus verification module, a cross-chain state synchronization module, an on-chain and off-chain hybrid storage and indexing module, and a digital insight service interface module.

[0024] The first module of this system, the Blockchain Node Networking-Consensus Verification Module, includes multiple node units, which correspond to e-commerce platform operators, data requesters, regulatory agencies, and third-party certification bodies, respectively. Each node unit establishes a communication connection through a P2P network. The Blockchain Node Networking Module has a built-in node identity authentication unit to verify the identities of multiple node units joining the network. Nodes that pass the verification can participate in blockchain data interaction to achieve data consensus verification among nodes.

[0025] It's important to explain that, firstly, the system receives node access requests from e-commerce platform operators, data requesters, regulatory agencies, and third-party certification bodies. Its built-in node identity authentication unit performs multi-dimensional identity verification and role authorization based on digital certificates and attribute credentials. Only nodes that pass verification receive the corresponding permission certificates and join the network. This ensures the legitimacy and trustworthiness of participating nodes from the outset, laying the foundation for subsequent data rights and responsibilities definition and trusted interaction. Next, authorized node units automatically discover and establish direct communication connections through peer-to-peer network protocols, forming a decentralized network topology. All communication links employ transport layer security encryption, not only avoiding single-point-of-failure risks but also ensuring the confidentiality and integrity of data transmission between nodes. Finally, during data interaction, this module drives each node to execute a predefined consensus protocol on the proposed shared data (such as a "delivered" logistics record). Through multiple rounds of interaction, including proposal, broadcasting, voting, and commitment, it ensures that a legally required number of nodes agree on data content, order, and state changes before recording it on the blockchain. This process ensures that any data's validity requires independent verification and collective endorsement from multiple parties, fundamentally preventing the possibility of unilateral data tampering and achieving high credibility and global consistency in data flow. Through the closed-loop operation of the above steps, this module successfully integrates dispersed and potentially distrustful e-commerce ecosystem participants into a co-governed, shared, and trustworthy verifiable data collaboration network, providing an indisputable single source of fact for upper-level digital insights.

[0026] As the second module of this system, the cross-chain state synchronization module is used to obtain real-time parameters in e-commerce multi-chain and single-chain scenarios. Based on the real-time parameters, the real-time performance of e-commerce cross-chain data synchronization is obtained. This is used to quantify the efficiency indicators of target data (such as consumer order data, logistics node data, and operation logs) from generation to completion of on-chain notarization and cross-chain synchronization, and its queryability. Based on the real-time performance of e-commerce cross-chain data synchronization, it is determined whether to perform intelligent control of cross-chain data synchronization to dynamically optimize resource allocation and improve the timeliness of e-commerce digital insights.

[0027] It should be noted that the specific steps to obtain real-time cross-chain data synchronization for e-commerce are as follows: Real-time parameters include cross-chain bridge data parsing time, mempool transaction backlog, and e-commerce data generation frequency. Specifically, cross-chain bridge data parsing time refers to the total time taken for the e-commerce cross-chain bridge to complete the entire process of data format conversion, hash validity verification, multi-chain protocol adaptation, and data sharding and reassembly after receiving data to be synchronized from the source chain (such as the e-commerce transaction chain or logistics chain). A built-in parsing process timer is used; when the cross-chain bridge receives data through the source chain's light client, the timer starts and terminates after completing the data format conversion, hash validity verification, multi-chain protocol adaptation, and data sharding and reassembly. The difference between the timer's termination timestamp and its start timestamp is recorded as the cross-chain bridge data parsing time. The mempool transaction backlog refers to the amount of data in the blockchain network's (single-chain or a chain involved in cross-chain transactions) mempool at a preset time. The total number of unconfirmed transactions awaiting packaging and on-chain by consensus nodes; the memory pool status data is invoked via node command line to filter and count the total number of unconfirmed transactions, and simultaneously categorized by transaction type (proof-of-existence, user transactions, cross-chain triggers) to extract the backlog of proof-of-existence transactions, record the timestamp and corresponding backlog amount for each query, and calculate the average backlog amount per unit time to obtain the memory pool transaction backlog; the e-commerce data generation frequency refers to the total amount of target data (including consumer order data, logistics node update data, operation log data, payment record data, etc.) generated within a preset unit time; the ratio of e-commerce data generated within a preset unit time obtained through order system logs to the preset unit time is recorded as the e-commerce data generation frequency.

[0028] The parsing time ratio factor is interactively processed with the parsing time benchmark value and the result of normalizing the cross-chain bridge data parsing time to obtain the parsing time impact value; the backlog amount ratio factor is interactively processed with the backlog amount benchmark value and the result of normalizing the mempool transaction backlog to obtain the backlog amount impact value; the generation frequency ratio factor is interactively processed with the generation frequency benchmark value and the result of normalizing the e-commerce data generation frequency to obtain the generation frequency impact value; the parsing time impact value, backlog amount impact value, and generation frequency impact value are superimposed to obtain the e-commerce cross-chain data synchronization real-time performance. The specific constraint expression for the e-commerce cross-chain data synchronization real-time performance is as follows: ; ; In the formula, W represents the real-time synchronization of cross-chain e-commerce data; c1 represents the parsing time ratio factor obtained from the data sharing database; c2 represents the backlog ratio factor obtained from the data sharing database; c3 represents the generation frequency ratio factor obtained from the data sharing database; S0 represents the parsing time baseline value obtained from the data sharing database; D0 represents the backlog baseline value obtained from the data sharing database; E0 represents the generation frequency baseline value obtained from the data sharing database; S represents the cross-chain bridge data parsing time; D represents the backlog of mempool transactions; and E represents the e-commerce data generation frequency.

[0029] It's important to explain that the data sharing database is a pre-built distributed collaborative storage system designed to support the efficient operation of a blockchain-based e-commerce trusted data sharing system. It's specifically designed for the persistent storage of various key shared data and governance parameters that have undergone consensus verification. This includes core data assets such as the entire transaction chain records (e.g., order hashes, payment vouchers, logistics nodes), data permission policies (e.g., access control lists, smart contract addresses), and system operating parameters (e.g., parsing time benchmarks, backlog benchmarks). The entry and updating of this data are not arbitrary unilateral decisions but are based on a multi-party consensus mechanism. Taking "order-logistics related data" as an example, its validity must be cross-verified and jointly signed by pre-defined verification nodes in the transaction chain and logistics chain according to the rules deployed in the smart contract, ensuring the data's trustworthiness, consistency, and tamper-proof nature. Meanwhile, considering the diversity of e-commerce business scenarios and the dynamic nature of alliance governance, all data permissions and rule parameters in the database are encapsulated through programmable smart contracts. Alliance members can authorize, adjust, and collaboratively upgrade the contract logic and parameters according to business development needs through predefined governance processes (such as multi-signature voting), ultimately achieving continuous optimization and alignment between data sharing strategies and business goals.

[0030] It should be noted that the higher the frequency of e-commerce data generation, the more evidence-based transaction requests flood into the blockchain within a preset unit of time, the more significant the backlog of unconfirmed transactions in the mempool, and the higher the backlog of transactions in the mempool. The higher the backlog of transactions in the mempool, the longer the delay in confirming evidence-based transactions on the blockchain, the later the cross-chain bridge receives data from the source chain, and the target chain may indirectly prolong the waiting time of the parsing process due to possible congestion, ultimately leading to an increase in the time consumed by cross-chain bridge data parsing. Meanwhile, there is a negative correlation between the data parsing time of cross-chain bridges and the real-time synchronization of e-commerce cross-chain data. The longer the data parsing time of cross-chain bridges, that is, the longer it takes for cross-chain bridges to parse single / batch data, the longer the total latency of data flow from the source chain to the target chain and becomes queryable, and the lower the real-time synchronization of e-commerce cross-chain data. There is also a negative correlation between the transaction backlog in the mempool and the real-time synchronization of e-commerce cross-chain data. The more transaction backlog in the mempool, that is, the higher the backlog of unconfirmed transactions in the mempool, the longer the delay in data notarization and on-chain, and the later the precondition for cross-chain synchronization (data completion and on-chain confirmation) is met, the lower the real-time synchronization of e-commerce cross-chain data. There is also a negative correlation between the e-commerce data generation frequency and the real-time synchronization of e-commerce cross-chain data. The higher the e-commerce data generation frequency, the more redundant notarized transactions cannot be packaged in time, the mempool backlog grows exponentially, and thus the lower the real-time synchronization of e-commerce cross-chain data.

[0031] Furthermore, the specific steps for determining whether to perform intelligent control of cross-chain data synchronization are as follows: If the real-time synchronization of cross-chain data in e-commerce is greater than or equal to the real-time synchronization reference value, then the intelligent control of cross-chain data synchronization will not be executed; otherwise, the confirmation latency threshold optimization and latency tolerance window optimization will be executed.

[0032] As further explained in detail, the specific steps for performing confirmation delay threshold optimization are as follows: S201 monitors the status of the e-commerce cross-chain network in real time, obtains the current number of e-commerce cross-chain data shards, and simultaneously obtains the baseline range of the number of shards and the baseline latency threshold for dynamic adjustment of the transaction on-chain confirmation latency threshold. It transforms the abstract concept of "sharding" into a measurable control input and provides a calibration benchmark based on historical best performance for subsequent judgments.

[0033] S202, input the current number of e-commerce cross-chain data shards, the shard number baseline range, and the real-time synchronization offset obtained in step S201 into the predefined shard number-latency threshold mapping relationship to obtain the current transaction on-chain confirmation latency threshold adjustment component (the current transaction on-chain confirmation latency threshold adjustment component includes the latency threshold increase and the latency threshold decrease). The shard number-latency threshold mapping relationship is configured to reflect the non-linear positive correlation between the number of e-commerce cross-chain data shards and the transaction on-chain confirmation latency threshold. The real-time synchronization offset represents the negative difference between the real-time synchronization of e-commerce cross-chain data and the real-time synchronization reference value. (The shard number baseline range is the empirical value of the number of shards corresponding to the optimal throughput-latency balance of the system under the preset load; the baseline latency threshold is the standard transaction on-chain confirmation latency upper limit determined by historical data statistics and system calibration under the shard number baseline range scenario.)

[0034] S203 states that if the number of cross-chain data shards for e-commerce is within the shard count baseline range, then the confirmation latency threshold optimization will not be performed. The shard count baseline range refers to the closed interval formed by the lower limit and upper limit of the shard count baseline. This avoids unnecessary adjustment disturbances within the stable operating range of the system, maintaining the stability and predictability of the strategy.

[0035] As a further specific explanation, the optimization of the confirmation latency threshold also includes: S204: If the number of e-commerce cross-chain data shards is less than the lower limit of the shard count baseline, the shard count deviation and real-time synchronization offset are input into the predefined shard count-latency threshold mapping relationship to obtain the latency threshold reduction. The difference between the transaction on-chain confirmation latency threshold and the latency threshold reduction is then processed to obtain the current transaction on-chain confirmation latency threshold. The shard count deviation represents the negative difference between the number of e-commerce cross-chain data shards and the lower limit of the shard count baseline. Actively tightening latency requirements incentivizes the system to explore potential performance under relaxed load conditions, allowing transactions to be confirmed within a shorter timeout window, thereby significantly improving the sensitivity of data synchronization and the smoothness of the user experience, and avoiding performance idleness.

[0036] S205: If the number of e-commerce cross-chain data shards exceeds the baseline upper limit for the number of shards, the shard number offset and the real-time synchronization offset are input into the predefined shard number-latency threshold mapping relationship to obtain the latency threshold adjustment. The transaction on-chain confirmation latency threshold is then added to the latency threshold adjustment to obtain the current transaction on-chain confirmation latency threshold. The shard number offset represents the positive difference between the number of e-commerce cross-chain data shards and the baseline upper limit for the number of shards. This intelligently and appropriately relaxes the latency tolerance, preventing a large number of legitimate transactions that could have been successfully confirmed within a slightly longer timeframe from being mistakenly judged as "timeout failures" due to rigid, strict time limits. This effectively reduces unnecessary transaction drop rates and retry overhead, maintaining the overall throughput and business continuity of the system under high complexity while ensuring eventual consistency.

[0037] In this embodiment, by dynamically adjusting the number of real-time shards as described above, this method constructs an elastic timeout mechanism that adaptively links with network topology complexity. This makes the transaction confirmation latency threshold no longer a fixed value, but a dynamic boundary that intelligently scales with the system's shard size (i.e., internal collaborative complexity). This resolves the contradiction in e-commerce multi-chain / sharding scenarios where a fixed latency threshold leads to "underutilization of performance under low load" versus "a large number of transactions being mistakenly killed due to collaborative latency under high load (high sharding)." It achieves an optimal balance between key indicators such as transaction processing success rate, system throughput, and data synchronization real-time performance in a dynamically changing network environment, providing a stable and efficient reliable data stream for upper-layer e-commerce digital insights.

[0038] It is necessary to understand that, such as Figure 2The diagram shown illustrates the latency tolerance window optimization flowchart for a blockchain-based trusted data sharing system in e-commerce digital insights provided in this application embodiment. The specific process is as follows: It begins with continuous monitoring of the cross-chain bridge relay latency. First, a judgment is made: if the monitored relay latency is less than or equal to a preset benchmark value, the cross-chain bridge performance is determined to be normal, the current tolerance window will be maintained, no optimization operation will be performed, and the process will end directly. If the relay latency is greater than the benchmark value, it indicates a transmission delay. The system will calculate the "relay latency deviation" (i.e., the positive difference between the actual latency and the benchmark value) and the "real-time synchronization offset," reflecting the overall synchronization pressure. Subsequently, a secondary judgment is made based on the severity of the deviation: if the deviation is less than or equal to a preset delay deviation threshold, it is judged as a mild or predictable fluctuation. In this case, the system calls a mapping function with a linear growth relationship, outputs a "gain delay tolerance window compensation value," and adds this compensation value to the original tolerance window, thereby appropriately relaxing the time limit to absorb the fluctuation. If the deviation is greater than the delay deviation threshold, it is judged as a significant delay that may lead to a synchronization chain breakage. In this case, the system calls a mapping function with an exponential growth relationship, outputs a "decay delay tolerance window compensation value," and subtracts this value from the original tolerance window, essentially tightening the window to accelerate failure judgment and trigger higher-level fault handling. Finally, regardless of whether the tolerance window is relaxed or tightened, the new tolerance window will be applied, and the process ends. The entire process realizes an intelligent elastic control mechanism with a graded, non-linear response based on the severity of delay.

[0039] As a further explanation, the specific steps for optimizing the latency tolerance window are as follows: Real-time monitoring of the cross-chain bridge's data relay channel; acquisition of the cross-chain bridge data relay latency within a preset period; comparison of the cross-chain bridge data relay latency with a baseline value; specifically: If the cross-link bridge data relay latency is less than or equal to the relay latency baseline, latency tolerance window optimization will not be performed, and the average latency tolerance window for e-commerce data synchronization will be maintained. This avoids unnecessary policy intervention when transmission conditions are good, maintains the simplicity and stability of system configuration, and eliminates the additional complexity that may be introduced by over-optimization.

[0040] If the cross-chain bridge data relay delay exceeds the relay delay baseline, the relay delay deviation and the real-time synchronization offset are input into a predefined relay delay-tolerance window mapping relationship to obtain a delay tolerance window compensation value. This mapping relationship is configured based on a non-linear response relationship, using the relay delay deviation and the real-time synchronization offset as input variables. Through weighted fusion, a non-negative window compensation value is output. The relay delay deviation represents the positive difference between the cross-chain bridge data relay delay and the relay delay baseline. This achieves precise perception and anomaly identification of this critical bottleneck point in the cross-chain bridge, ensuring that control actions are initiated only when necessary and targeting specific bottlenecks, thus improving the targeting and efficiency of resource utilization.

[0041] As a further explanation, the delay tolerance window optimization also includes: If the relay delay deviation is less than or equal to the delay deviation threshold, the relay delay-tolerance window mapping relationship increases linearly. The output gain delay tolerance window compensation value absorbs expected delay fluctuations. This compensation value is then superimposed on the current average delay tolerance window for e-commerce data synchronization to obtain the adjusted average delay tolerance window for e-commerce data synchronization. This effectively absorbs expected delay fluctuations caused by routine network jitter, brief congestion, or slight competition for processing resources, preventing many synchronization tasks that could have ultimately succeeded from being mistakenly judged as timeout failures. It significantly reduces invalid retries and error alarms caused by occasional fluctuations, improving the success rate and resource utilization of the synchronization process.

[0042] If the relay delay deviation exceeds the delay deviation threshold, the relay delay-tolerance window mapping relationship grows exponentially. A decaying delay tolerance window compensation value is output to address significant delays that could lead to synchronization chain breakage. The difference between the current average e-commerce data synchronization delay tolerance window and the decaying delay tolerance window compensation value is used to obtain the adjusted average e-commerce data synchronization delay tolerance window. On one hand, by significantly tightening the tolerance window, the system can more quickly determine synchronization failures, thereby immediately triggering higher-level failover mechanisms (such as switching to a backup cross-link bridge or manual intervention via alarms), preventing the system from exhausting resources or delaying critical business recovery during indefinite waiting. On the other hand, this fast-failure mechanism also protects subsequent data waiting for synchronization, preventing them from queuing on a known severely faulty channel, causing cascading delays and state chaos, and ensuring the overall responsiveness and maintainability of the system.

[0043] In this embodiment, through the aforementioned hierarchical dynamic adjustment based on the real-time performance of the cross-chain bridge, this method constructs an intelligent, elastic timeout system closely linked to the health status of cross-chain transmission. This makes the tolerance window for data synchronization no longer static and rigid, but intelligently expands and contracts according to the actual performance of the cross-chain bridge: providing a "buffer" to enhance resilience during minor fluctuations, and decisively "shrinking" to accelerate fault isolation and recovery during severe failures. This solves the dilemma of traditional fixed timeout mechanisms in cross-chain scenarios: setting it too strictly makes it susceptible to fluctuations and leads to misjudgments, while setting it too loosely results in sluggish responses during real failures. Ultimately, this method significantly improves the robustness, success rate, and observability of the data synchronization process in complex e-commerce cross-chain environments, providing a more stable and reliable data synchronization service guarantee for upper-layer businesses.

[0044] As the third module of this system, the cross-chain state synchronization module is used to obtain real-time parameters in e-commerce multi-chain and single-chain scenarios. Based on the real-time parameters, the real-time performance of e-commerce cross-chain data synchronization is obtained. This is used to quantify the efficiency indicators from generation to completion of on-chain notarization and cross-chain synchronization, which can be queried and called. Based on the real-time performance of e-commerce cross-chain data synchronization, it is determined whether to perform intelligent control of cross-chain data synchronization to dynamically optimize resource allocation and improve the timeliness of e-commerce digital insights.

[0045] It should be noted that the consensus parameters include the real-time performance of synchronization to be evaluated, the finality time of a single-chain block, and the response time of the consensus node. Specifically, the real-time performance of synchronization to be evaluated refers to the re-acquired e-commerce cross-chain data synchronization real-time performance if cross-chain data synchronization intelligent control has been implemented; otherwise, the current e-commerce cross-chain data synchronization real-time performance is recorded as the real-time performance to be evaluated. The finality time of a single-chain block refers to the total time elapsed from when a single block in the blockchain is packaged and generated by a consensus node (recorded as the start time) to when it reaches an irreversible state (i.e., all nodes in the network reach a consensus confirmation, and transactions within the block cannot be tampered with or rolled back). The packaging generation timestamp is obtained through the linkage of blockchain node logs and consensus network monitoring tools, i.e., the time when the block is created by the main packaging node and broadcast to the network. The system tracks the confirmation status of the block across all nodes in the network. When the preset consensus threshold is exceeded (e.g., a node writes the block to its local ledger and returns a "confirmation" response), the final confirmation timestamp is recorded. The difference between the final confirmation timestamp and the timestamp of the block generation is recorded as the finality time of the single-chain block. The consensus node response time refers to the average time taken for a single consensus node from receiving a transaction / block verification request (e.g., transaction hash verification, block signature verification) to completing the calculation and returning an agreement / rejection / pending verification result. The difference between the timestamp of the verification completion time of a single node recorded in the consensus request log and the timestamp of the verification request reception time is recorded as the consensus node response time.

[0046] The real-time scaling factor is interactively processed with the results of normalizing the synchronous real-time and real-time benchmark values ​​to be evaluated, resulting in a real-time impact value. The finality time scaling factor is interactively processed with the finality time benchmark value and the results of normalizing the finality time of a single-chain block, resulting in a finality time impact value. The response time scaling factor is interactively processed with the response time benchmark value and the results of normalizing the response time of consensus nodes, resulting in a response time impact value. The real-time impact value, the finality time impact value, and the response time impact value are then superimposed to obtain the e-commerce cross-chain data consensus consistency. The specific constraint expression for the e-commerce cross-chain data consensus consistency is as follows: ; ; In the formula, R represents the consensus consistency of cross-chain e-commerce data; k1 represents the real-time scaling factor obtained from the data sharing database; k2 represents the finality scaling factor obtained from the data sharing database; k3 represents the response time scaling factor obtained from the data sharing database; F0 represents the real-time benchmark value obtained from the data sharing database; Q0 represents the finality benchmark value obtained from the data sharing database; H0 represents the response time benchmark value obtained from the data sharing database; F represents the real-time performance to be evaluated; Q represents the finality time of a single-chain block; and H represents the response time of the consensus node.

[0047] It should be noted that the longer the consensus node response time, the longer the total time from the generation of a single block to achieving an "irreversible" state, and the longer the finality time of a single-chain block. The longer the finality time of a single-chain block, the longer the pre-waiting time for cross-chain synchronization, the longer the total time from data generation to the completion of cross-chain synchronization and its queryability, and the worse the real-time performance of the synchronization to be evaluated. The longer the consensus node response time, the worse the real-time performance of the synchronization to be evaluated is due to the extended intermediate transmission of the finality time of the single-chain block. There is a positive correlation between the real-time performance of the synchronization to be evaluated and the consistency of cross-chain data consensus in e-commerce. The higher the real-time performance of the synchronization to be evaluated, the less likely it is to receive unconfirmed temporary data or updated old data due to delays, resulting in consistent verification results and greater consistency of cross-chain data consensus in e-commerce. There is a negative correlation between the finality time of a single-chain block and the consistency of cross-chain data consensus in e-commerce. The longer the finality time of a single-chain block, the longer the cross-chain bridge needs to wait for the source chain data confirmation. During this period, the target chain may have received other unconfirmed data, causing data version conflicts (such as two versions of the logistics status of the same order: pending shipment and shipped), resulting in lower consistency of cross-chain data consensus in e-commerce. There is also a negative correlation between the response time of consensus nodes and the consistency of cross-chain data consensus in e-commerce. The longer the response time of consensus nodes, the more asynchronous the verification becomes. Nodes that complete verification first have already voted for confirmation, while nodes that complete verification later may receive outdated data (such as updated block information) due to network delays, leading to voting disagreements and lower consistency of cross-chain data consensus in e-commerce.

[0048] Furthermore, the specific steps for determining whether to implement intelligent control of cross-chain data consistency in e-commerce are as follows: If the consensus consistency of cross-chain e-commerce data is greater than or equal to the consensus consistency reference value, then the intelligent control of cross-chain e-commerce data consistency will not be implemented; otherwise, the tolerance capacity threshold optimization and block packaging interval optimization will be implemented.

[0049] As further explained in detail, the specific steps for performing tolerance capacity threshold optimization are as follows: S101 monitors the memory pool of blockchain nodes in real time and obtains the average waiting time of the memory pool within a preset time window; the average waiting time of the memory pool refers to the arithmetic average of the time taken for all confirmed transactions to be submitted and packaged into a block within the preset time window.

[0050] In step S102, the average waiting time of the memory pool obtained in step S101 is compared with the baseline waiting time value. Specifically, if the average waiting time of the memory pool is less than or equal to the baseline waiting time value, it is determined to be in a normal load state, and the tolerance capacity threshold optimization is not performed, maintaining the current block tolerance capacity threshold. If the average waiting time of the memory pool is greater than the baseline waiting time value, the tolerance capacity threshold optimization is performed, and the process proceeds to step S103. This avoids unnecessary parameter adjustments when the system is running smoothly, ensuring the stability of strategy execution and the principle of minimal intervention. It prevents unnecessary network fluctuations caused by over-regulation and establishes a clear and automatic regulation triggering mechanism. This ensures that the system can promptly initiate countermeasures when the front-end transaction load begins to have a substantial impact on user experience (latency), achieving a seamless connection from "perception" to "action."

[0051] S103 determines the load overload level based on the deviation between the average memory pool latency and the baseline latency value, as well as the consistency offset. The load overload level is obtained by mapping the deviation to a preset discrete level range, including low, medium, and high levels. Each load overload level corresponds to a predefined capacity adjustment coefficient. The consistency offset represents the negative difference between the consensus consistency of e-commerce cross-chain data and the consensus consistency reference value. This achieves a comprehensive assessment of congestion severity and system risk, ensuring that the control strategy not only focuses on throughput but also considers the core of the blockchain: consistency and security. This avoids the consensus instability risk that may result from blindly expanding capacity to increase processing speed.

[0052] As a further explanation, performing tolerance capacity threshold optimization also includes: S104, based on the capacity adjustment coefficient determined in step S203, dynamically adjust the baseline block tolerance capacity threshold to generate the current dynamic block tolerance capacity threshold, specifically as follows: If the overload level is low, the corresponding predefined capacity adjustment coefficient is the capacity level 1 gain coefficient. The current block tolerance capacity threshold is interactively processed with the capacity gain coefficient to obtain the adjusted block tolerance capacity threshold, thus slightly increasing the block tolerance capacity threshold. Without significantly changing the network propagation and verification burden, this slightly accelerates the emptying of the mempool, making it suitable for handling slight peaks in transaction volume and achieving proactive fine-tuning of resources.

[0053] If the load overload level is medium, the corresponding predefined capacity adjustment coefficient is the capacity secondary gain coefficient. The current block tolerance capacity threshold is interactively processed with the capacity secondary gain coefficient to obtain the adjusted block tolerance capacity threshold, which is increased by a moderate amount. When congestion is clear and persistent, more proactive measures are taken to expand processing capacity, effectively alleviating queuing pressure, significantly reducing the average transaction confirmation latency, thereby pulling the system back from the edge of performance degradation to a stable operating range and ensuring processing efficiency during peak business periods.

[0054] If the overload level is high, the corresponding predefined capacity adjustment coefficient is the capacity level 3 gain coefficient. The current block tolerance capacity threshold is interactively processed with the capacity level 3 gain coefficient to obtain an adjusted block tolerance capacity threshold, significantly increasing it. In emergency situations involving transaction surges that could potentially cause system paralysis, the maximum elastic scaling solution is activated to quickly digest backlogged transactions with maximum available capacity, prioritizing the restoration of system throughput and preventing business failures or user experience crashes due to indefinite transaction backlogs.

[0055] In this embodiment, by dynamically adjusting the memory pool waiting time, this method constructs an elastic block capacity control system that intelligently links with the real-time transaction load intensity. This allows the block's "throughput valve" to be smoothly and controllably adjusted automatically based on the most direct pressure signal—queue latency. This solves the dilemma faced by fixed block capacity when dealing with dynamic e-commerce loads: too small a capacity leads to congestion during peak periods, while too large a capacity increases unnecessary network and storage overhead during normal times and may affect consensus speed. Ultimately, this method achieves a multi-objective balance of maintaining high efficiency and low consumption under normal conditions, intelligent elastic scaling during peak periods, and prioritizing availability in extreme situations, significantly improving the overall performance, stability, and resource efficiency of the blockchain network under variable e-commerce loads.

[0056] It is necessary to understand that, such as Figure 3The diagram shows the block packaging interval optimization process of the blockchain-based trusted data sharing system in e-commerce digital insight provided in this application embodiment. The specific process is as follows: starting from continuously monitoring the response time of on-chain data queries, and immediately comparing it with the preset performance benchmark interval, the process is divided into three paths based on the comparison result: if the response time is less than or equal to the lower limit of the query response time benchmark, the query performance is determined to be in the comfortable range, and the system believes that the current block production and query service resource competition is in a healthy balance state. Therefore, no optimization is performed, the existing block packaging interval configuration is maintained, and the process ends directly; if the response time is between the lower limit and the upper limit of the benchmark, the query performance is determined to have entered the warning range, indicating that the query service has begun to feel the pressure of resource competition. The system automatically optimizes the block packaging interval: First, it inputs the current query response time and the consistency offset (reflecting consensus stability) into a predefined "response time-interval window mapping relationship." This relationship comprehensively assesses query pressure and system security boundaries, outputting an interval window adjustment coefficient. Next, the system multiplies the current block packaging interval window by this adjustment coefficient to calculate a new, longer block packaging interval. Finally, this adjusted interval window is applied, aiming to improve query response time by reducing the frequency of new block production and freeing up more computational and I / O resources for the data query service. If the response time is greater than or equal to the upper limit of the query response time baseline, the query performance is deemed to have exceeded the warning threshold, facing a serious risk of degradation. In this case, while automatically executing the above optimization steps, the system simultaneously sends warning messages to pre-defined maintenance personnel, indicating the need for manual attention or the potential initiation of higher-level troubleshooting and intervention measures. This process implements a hierarchical, human-machine collaborative intelligent control mechanism that proactively and dynamically optimizes resource allocation while ensuring the core functions of blockchain consensus, guaranteeing the availability and response performance of the data query service.

[0057] As a further explanation, the specific steps for optimizing the block packing interval are as follows: Deploy monitoring probes on the full blockchain node to obtain the on-chain data query response time within a preset period; the on-chain data query response time refers to the time elapsed from when the query request is received by the node to when a complete and finally confirmed data result is returned.

[0058] If the on-chain data query response time is less than or equal to the lower limit of the query response time benchmark, the query performance is considered to be in a comfortable range, and no block packaging interval optimization is performed. When the data query service experience is excellent, the existing block production rhythm is maintained to ensure that transaction throughput and confirmation speed are not affected, following the optimization principle of "no disturbance unless necessary" and maintaining the stability of the system's core processing logic.

[0059] If the on-chain data query response time is within the baseline range, the query performance is determined to have entered the warning zone, and block packaging interval optimization is performed. The baseline range for query response time refers to the open interval formed by the lower and upper limits of the baseline query response time. This establishes a proactive early warning and intervention mechanism. It enables the system to take proactive measures to prevent further escalation of problems before the query service experience deteriorates to an unacceptable level (crossing the bottom line), reflecting a shift in operational philosophy from "passively responding to faults" to "proactively maintaining service quality."

[0060] If the on-chain data query response time is greater than or equal to the baseline upper limit, the query performance is deemed to have exceeded the warning threshold, and a warning message is sent to the designated maintenance personnel. This adds a channel for manual supervision and emergency intervention to the automatic control mechanism. When automatic control may be insufficient to handle extreme situations or requires combination with other complex operations, timely alerts ensure that critical business data services receive the highest priority attention and processing, forming a dual protection system combining automatic and manual intervention.

[0061] The specific steps for optimizing the block packing interval are as follows: Input the on-chain data query response time and consistency offset into the response time-interval window mapping relationship to obtain the interval window adjustment coefficient. Then, interact with the current block packing interval window to obtain the adjusted block packing interval window.

[0062] In this embodiment, by appropriately reducing the frequency of new block generation (i.e., extending the block interval), the periodic impact of a series of high CPU / IO-consuming tasks such as block packaging, verification, propagation, and state updates on node computing and storage resources is effectively reduced. This is equivalent to "ceding" more continuous processing resources to the data query service on the node, thereby significantly improving the response speed of complex or concurrent queries and alleviating query queuing and latency caused by resource contention. This adjustment is not carried out in isolation; it introduces a consistency offset as a correction factor. This means that when deciding how much to extend the interval, the current consensus health of the blockchain network is considered simultaneously. If the consensus itself is at risk of latency, the adjustment coefficient will be suppressed to prevent excessively extending the block interval to improve queries, which could potentially lead to new systemic problems such as slow transaction confirmation or unstable consensus. This achieves a fine balance and synergistic optimization between "improving query service quality" and "maintaining the core consensus performance of the blockchain." Through the above dynamic interval adjustment guided by query response time, this method constructs a resource-aware and service quality-driven adaptive blockchain production cycle system. It innovatively feeds back the performance metrics of the data service layer to the core parameters (packaging interval) of the blockchain's underlying layer. This transforms blockchain nodes from single-function transaction processors into balanced service platforms capable of intelligently allocating resources and balancing "write operations" (on-chain operations) and "read operations" (queries). It solves the problem of transaction processing peaks squeezing data query services in resource-constrained node environments, ensuring that even during periods of high transaction activity, digital insight applications relying on on-chain queries, such as historical data analysis and real-time monitoring dashboards, can still obtain timely and reliable data responses. This guarantees the continuous and stable output of value from blockchain-based e-commerce data, enhancing the practicality and service level of the entire trusted data sharing system.

[0063] The fourth module of this system, the Digital Insight Service Interface Module, is used to receive and parse consensus-verified e-commerce business query requests, aggregate trusted data in parallel, embed blockchain proofs, and output trusted e-commerce digital insight data results.

[0064] It's important to explain that, as a key service layer connecting the underlying trusted data sharing infrastructure with upper-layer business applications, this module efficiently transforms the trust capabilities of blockchain into business-usable data services through a standardized process. First, the module receives query requests from authorized data analysis platforms or business applications (e.g., "Analyze the sales-logistics timeliness relationship of product A in East China this quarter"). The interface immediately performs identity authentication and permission verification on the request, ensuring the requester has the legitimate identity and corresponding permissions to access the target data, and accurately parses the business semantics and data scope of the query. This constructs the first line of security for data access, ensuring that sensitive business data is only accessed within authorized limits through strict access control, eliminating the risk of data misuse and leakage at the entry point, and complying with e-commerce data compliance requirements. Next, the parsed query is broken down into multiple sub-tasks, and the module initiates parallel collaborative calls to the underlying on-chain and off-chain hybrid storage and indexing module and the cross-chain state synchronization module. Instead of simply pulling raw data, it intelligently aggregates data fragments from different business chains (such as transaction chains and logistics chains) that have been verified by their respective consensus mechanisms. Based on the immutable relationships stored on the chain (such as the binding of transaction hashes to logistics tracking numbers), it reassembles these fragments into a complete and coherent business view (such as a complete order chain including order placement, payment, all logistics nodes, and delivery status). It completely hides the complex technical details of underlying multi-chain, cross-chain, and hybrid on-chain and off-chain storage from upper-layer applications, providing a "one-stop" experience for obtaining globally related data. It ensures that the data returned to analysts is cross-domain integrated and logically self-consistent, eliminating the tedious data alignment and cleaning work on the business side and greatly improving data preparation efficiency. Secondly, when returning the aggregated data result set, the module automatically embeds blockchain proofs into the results. These proofs include verifiable credentials such as the transaction hash of the source chain where the key data resides, the block height, the Merkle proof path, and the signature digests of relevant verification nodes. This directly transmits the "immutability" and "verifiability" characteristics of blockchain from the technical layer to the business data results themselves. Upon receiving data, data analysts or decision-making systems can independently and offline verify the authenticity, integrity, and freshness of the data using the accompanying cryptographic proofs, without needing to trust the data service interface itself. This ensures that the final digital insights are built on a solid, auditable, and debatable foundation, greatly enhancing the credibility and decision support value of the analysis results. Finally, the module returns the encapsulated insight data results, complete with trusted proofs, to the requester via a standardized API. Simultaneously, all steps of this process are recorded in the audit log and integrated with the system's overall SLA monitoring system. This transforms the originally complex and professional blockchain data interaction into a high-level data service as simple, efficient, and reliable as calling a regular cloud service API.It significantly lowers the barrier for data analysts to utilize blockchain-based trusted data, enabling enterprises to quickly build and iterate advanced digital insight applications such as real-time risk control, precision marketing, and supply chain optimization based on end-to-end trusted data, truly promoting the value circulation and deep empowerment of data elements in a trusted environment.

[0065] The various features and processes described above can be used independently of each other or can be combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of this disclosure. Furthermore, certain method or process blocks may be omitted in some embodiments. The methods and processes described herein are not limited to any particular order, and the blocks or states associated with them may be performed in other suitable orders. For example, the described blocks or states may be performed in an order different from the order specifically disclosed, or multiple blocks or states may be combined in a single block or state. Example blocks or states may be performed serially, in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed example embodiments. The exemplary systems and components described herein may be configured differently from those described. For example, elements may be added to, removed from, or rearranged compared to the disclosed example embodiments.

[0066] The various operations of the example methods described herein can be performed at least in part by an algorithm. This algorithm can be contained in program code or instructions stored in memory (e.g., the aforementioned non-transitory computer-readable storage medium). Such an algorithm may include a machine learning algorithm. In some embodiments, the machine learning algorithm may not be explicitly programmed into the computer to perform the function, but can learn from training data to create a predictive model that performs the function.

[0067] The various operations of the example methods described herein can be performed, at least in part, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors can constitute the engine of a processor implementation that operates to perform one or more of the operations or functions described herein.

[0068] Similarly, the methods described herein can be implemented at least in part by a processor, where one or more specific processors are examples of hardware. For example, at least some operations of a method can be performed by one or more processors or an engine implemented by a processor. Furthermore, one or more processors can also be operated to support the performance of related operations in a “cloud computing” environment or as “Software as a Service” (SaaS). For example, at least some operations can be performed by a set of computers (as an example of a machine including processors), where these operations are accessible via a network (e.g., the Internet) and via one or more suitable interfaces (e.g., application programming interfaces (APIs)).

[0069] The performance of certain operations can be distributed across processors, residing not only within a single machine but also deployed across multiple machines. In some example embodiments, the processor or processor-implemented engine may reside in a single geographic location (e.g., within a home environment, office environment, or server cluster). In other example embodiments, the processor or processor-implemented engine may be distributed across multiple geographic locations.

[0070] In this specification, multiple instances may implement components, operations, or structures described as single instances. Although individual operations of one or more methods are shown and described as separate operations, one or more of the separate operations may be performed simultaneously and do not need to be performed in the order shown. Structures and functions presented as separate components in the example configuration may be implemented as composite structures or components. Similarly, structures and functions presented as single components may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of this document.

[0071] While an overview of the subject matter has been described with reference to specific example embodiments, various modifications and changes can be made to these embodiments without departing from the broader scope of embodiments of this disclosure. Such embodiments of the subject matter are referred to herein, individually or collectively, by the term "invention," and are used for convenience only and are not intended to limit the scope of this application to any single disclosure or concept, should more than one disclosure or concept be disclosed in fact.

[0072] The embodiments described herein have been described in sufficient detail to enable those skilled in the art to practice the disclosed teachings. Other embodiments may be used and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. Therefore, the detailed description should not be construed as limiting, and the scope of the various embodiments is defined only by the appended claims and the full scope of their equivalents.

Claims

1. A blockchain-based trusted data sharing system for e-commerce digital insights, characterized in that: This includes a blockchain node networking and consensus verification module, a cross-chain state synchronization module, an on-chain and off-chain hybrid storage and indexing module, and a digital insight service interface module. The blockchain node networking-consensus verification module includes multiple node units, which verify the identities of multiple node units joining the network. Nodes that pass the verification can participate in blockchain data interaction, which is used to realize data consensus verification between nodes. The cross-chain state synchronization module is used to obtain real-time parameters in e-commerce multi-chain and single-chain scenarios. Based on the real-time parameters, the real-time performance of e-commerce cross-chain data synchronization is obtained. This is used to quantify the efficiency indicators from generation to completion of on-chain notarization and cross-chain synchronization, which can be queried and called. Based on the real-time performance of e-commerce cross-chain data synchronization, it is determined whether to perform intelligent control of cross-chain data synchronization to dynamically optimize resource allocation and improve the timeliness of e-commerce digital insights. The on-chain and off-chain hybrid storage and indexing module is used to obtain consensus consistency parameters to obtain e-commerce cross-chain data consensus consistency, and is used to quantify whether the verification results of shared data by multiple chain nodes are completely consistent. Based on the e-commerce cross-chain data consensus consistency, it determines whether to execute e-commerce cross-chain data consistency intelligent control to proactively prevent and resolve state forks and data conflicts in a multi-chain asynchronous environment, thereby providing a single source of fact for upper-layer digital insight analysis and ensuring the reliability of cross-chain data. The digital insight service interface module is used to receive and parse consensus-verified e-commerce business query requests, aggregate trusted data in parallel, embed blockchain proofs, and output trusted e-commerce digital insight data results.

2. The blockchain-based trusted data sharing system for e-commerce digital insights as described in claim 1, characterized in that, The specific steps to achieve real-time synchronization of cross-chain e-commerce data are as follows: The real-time parameters include cross-chain bridge data parsing time, memory pool transaction backlog, and e-commerce data generation frequency. The parsing time ratio factor is interactively processed with the parsing time baseline value and the result of normalization of cross-link bridge data parsing time to obtain the parsing time impact value. The backlog ratio factor is interactively processed with the backlog benchmark value and the result of normalization of the mempool transaction backlog to obtain the backlog impact value. The generation frequency scaling factor is interactively processed with the generation frequency benchmark value and the result of e-commerce data generation frequency normalization to obtain the generation frequency influence value. The impact values ​​of parsing time, backlog, and generation frequency are superimposed to obtain the real-time synchronization of cross-chain e-commerce data. The specific steps for determining whether to perform cross-chain data synchronization intelligent control are as follows: If the real-time synchronization of cross-chain data in e-commerce is greater than or equal to the real-time synchronization reference value, then the intelligent control of cross-chain data synchronization will not be executed; otherwise, the confirmation latency threshold optimization and latency tolerance window optimization will be executed.

3. The blockchain-based trusted data sharing system for e-commerce digital insights as described in claim 2, characterized in that, The specific steps for optimizing the execution confirmation delay threshold are as follows: S201, monitor the status of the e-commerce cross-chain network in real time, obtain the current number of e-commerce cross-chain data shards, and simultaneously obtain the shard number benchmark range and benchmark latency threshold that are dynamically adjusted with the transaction on-chain confirmation latency threshold. S202, the current number of e-commerce cross-chain data shards, the shard number benchmark range, and the real-time synchronization offset obtained in step S201 are input into the predefined shard number-latency threshold mapping relationship to obtain the current transaction on-chain confirmation latency threshold adjustment component. The shard number-latency threshold mapping relationship is configured to reflect the non-linear positive correlation between the number of e-commerce cross-chain data shards and the transaction on-chain confirmation latency threshold. The real-time synchronization offset represents the degree of negative deviation between the real-time synchronization of e-commerce cross-chain data and the real-time synchronization reference value. S203, if the number of cross-chain data shards in e-commerce is within the shard count baseline range, then the confirmation delay threshold optimization will not be performed. The shard count baseline range represents the closed interval formed by the lower limit of the shard count baseline and the upper limit of the shard count baseline.

4. The blockchain-based trusted data sharing system for e-commerce digital insights as described in claim 3, characterized in that, The optimization of the execution confirmation delay threshold also includes: S204, if the number of e-commerce cross-chain data shards is less than the lower limit of the shard number baseline, the shard number deviation and the real-time synchronization offset are input into the predefined shard number-latency threshold mapping relationship to obtain the latency threshold reduction amount. The difference between the transaction on-chain confirmation latency threshold and the latency threshold reduction amount is processed to obtain the current transaction on-chain confirmation latency threshold. The shard number deviation amount represents the degree of negative deviation between the number of e-commerce cross-chain data shards and the lower limit of the shard number baseline. S205, if the number of e-commerce cross-chain data shards is greater than the upper limit of the shard number baseline, then the shard number offset and the real-time synchronization offset are input into the predefined shard number-latency threshold mapping relationship to obtain the latency threshold adjustment amount. The transaction on-chain confirmation latency threshold and the latency threshold adjustment amount are superimposed to obtain the current transaction on-chain confirmation latency threshold. The shard number offset represents the degree of positive deviation between the number of e-commerce cross-chain data shards and the upper limit of the shard number baseline.

5. The blockchain-based trusted data sharing system for e-commerce digital insights as described in claim 2, characterized in that, The specific steps for optimizing the delay tolerance window are as follows: Real-time monitoring of the cross-chain bridge's data relay channel; acquisition of the cross-chain bridge data relay latency within a preset period; comparison of the cross-chain bridge data relay latency with a baseline value; specifically: If the cross-chain bridge data relay delay is less than or equal to the relay delay baseline value, the delay tolerance window optimization will not be performed, and the average delay tolerance window for e-commerce data synchronization will be maintained. If the cross-link bridge data relay delay is greater than the relay delay baseline value, the relay delay deviation and the real-time synchronization offset are input into a predefined relay delay-tolerance window mapping relationship to obtain a delay tolerance window compensation value. The relay delay-tolerance window mapping relationship is configured based on a nonlinear response relationship, using the relay delay deviation and the real-time synchronization offset as input variables, and outputting a non-negative window compensation value through weighted fusion. The relay delay deviation represents the degree of positive deviation between the cross-link bridge data relay delay and the relay delay baseline value.

6. The blockchain-based trusted data sharing system for e-commerce digital insights as described in claim 5, characterized in that, The delay tolerance window optimization also includes: If the relay delay deviation is less than or equal to the delay deviation threshold, the relay delay-tolerance window mapping relationship increases linearly. The output gain delay tolerance window compensation value is used to absorb the expected delay fluctuations. The gain delay tolerance window compensation value is superimposed with the current e-commerce data synchronization average delay tolerance window to obtain the adjusted e-commerce data synchronization average delay tolerance window. If the relay delay deviation is greater than the delay deviation threshold, the relay delay-tolerance window mapping relationship grows exponentially. The attenuation delay tolerance window compensation value is output to cope with the significant delay that causes the synchronization chain to break. The difference between the current e-commerce data synchronization average delay tolerance window and the attenuation delay tolerance window compensation value is processed to obtain the adjusted e-commerce data synchronization average delay tolerance window.

7. The blockchain-based trusted data sharing system for e-commerce digital insights as described in claim 1, characterized in that, The consensus consistency parameters include the real-time synchronization to be evaluated, the finality time of a single-chain block, and the response time of the consensus node. The real-time scaling factor is interactively processed with the results of normalizing the synchronous real-time and real-time benchmark values ​​to be evaluated to obtain the real-time impact value. The finality time scaling factor is interactively processed with the finality time benchmark value and the result of normalizing the finality time of a single-chain block to obtain the finality time impact value. The response time scaling factor is interactively processed with the response time baseline value and the result of consensus node response time normalization to obtain the response time impact value. The impact values ​​of real-time performance, finality, and response time are superimposed to obtain the consensus consistency of cross-chain data in e-commerce. The specific steps for determining whether to perform intelligent control of cross-chain data consistency in e-commerce are as follows: If the consensus consistency of cross-chain e-commerce data is greater than or equal to the consensus consistency reference value, then the intelligent control of cross-chain e-commerce data consistency will not be implemented; otherwise, the tolerance capacity threshold optimization and block packaging interval optimization will be implemented.

8. The blockchain-based trusted data sharing system for e-commerce digital insights as described in claim 7, characterized in that, The specific steps for performing tolerance capacity threshold optimization are as follows: S101, Real-time monitoring of the memory pool of blockchain nodes to obtain the average waiting time of the memory pool within a preset time window; the average waiting time of the memory pool refers to the arithmetic average of the time taken for all confirmed transactions to be submitted and packaged into a block within the preset time window. S102, compare the average waiting time of the memory pool obtained in step S101 with the waiting time baseline value. Specifically: if the average waiting time of the memory pool is less than or equal to the waiting time baseline value, it is determined that it is in a normal load state, and the tolerance capacity threshold optimization is not performed, and the current block tolerance capacity threshold is maintained; if the average waiting time of the memory pool is greater than the waiting time baseline value, the tolerance capacity threshold optimization is performed, and the process proceeds to step S103. S103, determine the load overload level based on the deviation between the average waiting time of the memory pool and the waiting time reference value, as well as the consistency offset. The load overload level is obtained by mapping the deviation to a preset discrete level range. The load overload level includes low level, medium level and high level, and each load overload level corresponds to a predefined capacity adjustment coefficient. The consistency offset represents the degree of negative deviation between the consistency of e-commerce cross-chain data consensus and the consensus consistency reference value.

9. The blockchain-based trusted data sharing system for e-commerce digital insights as described in claim 8, characterized in that, The optimization of the tolerance capacity threshold also includes: S104, based on the capacity adjustment coefficient determined in step S203, the baseline block tolerance capacity threshold is dynamically adjusted to generate the current dynamic block tolerance capacity threshold, specifically as follows: If the overload level is low, the corresponding predefined capacity adjustment coefficient is the capacity level 1 gain coefficient. The current block tolerance capacity threshold and the capacity gain coefficient are interacted to obtain the adjusted block tolerance capacity threshold, so as to slightly increase the block tolerance capacity threshold. If the load overload level is medium, the corresponding predefined capacity adjustment coefficient is the capacity secondary gain coefficient. The current block tolerance capacity threshold is interactively processed with the capacity secondary gain coefficient to obtain the adjusted block tolerance capacity threshold, which is increased by a moderate amount. If the overload level is high, the corresponding predefined capacity adjustment coefficient is the capacity level 3 gain coefficient. The current block tolerance capacity threshold is interactively processed with the capacity level 3 gain coefficient to obtain the adjusted block tolerance capacity threshold, thereby significantly improving the block tolerance capacity threshold.

10. The blockchain-based trusted data sharing system for e-commerce digital insights as described in claim 7, characterized in that, The specific steps for optimizing the block packing interval are as follows: A monitoring probe is deployed on the full node of the blockchain to obtain the on-chain data query response time within a preset period; the on-chain data query response time refers to the time elapsed from when the query request is received by the node to when a complete and finally confirmed data result is returned. If the on-chain data query response time is less than or equal to the lower limit of the query response time benchmark, the query performance is determined to be in the comfortable range, and no block packing interval optimization is performed. If the on-chain data query response time is within the query response time benchmark range, the query performance is determined to have entered the warning range, and block packaging interval optimization is performed. The query response time benchmark range refers to the open interval formed by the lower limit of the query response time benchmark and the upper limit of the query response time benchmark. If the on-chain data query response time is greater than or equal to the upper limit of the query response time benchmark, it is determined that the query performance has exceeded the warning threshold, and a warning message is sent to the preset operation and maintenance personnel. The specific steps for optimizing the block packing interval are as follows: Input the on-chain data query response time and consistency offset into the response time-interval window mapping relationship to obtain the interval window adjustment coefficient. Then, interact with the current block packing interval window to obtain the adjusted block packing interval window.

Images