A blockchain-based three-industry data traceability interaction method and system

Abstract

The application relates to the technical field of data interaction, and discloses a three-industry data traceability interaction method and system based on a block chain, which comprises the following steps: collecting three-industry interaction full-scene information on the enterprise side, the industry side and the production line side, and constructing a multi-dimensional interaction feature Markov chain; generating an interaction value vector and a semantic label finite state machine based on the multi-dimensional interaction feature Markov chain; and executing resource dynamic scheduling and a trust feedback mechanism based on the interaction value vector and the semantic label finite state machine. The application solves the problem that the existing block chain three-industry data traceability interaction system cannot distinguish between effective data interaction and low-value requests, leading to high-value operation delay and system throughput efficiency reduction, realizes reasonable allocation of on-chain resources and positive incentives for data sharing, and improves the overall response efficiency of the system.

Description

Technical Field

[0001] This invention relates to the field of data interaction technology, and discloses a blockchain-based method and system for tracing and interacting data across three industries. Background Technology

[0002] Currently, blockchain technology is commonly used to build interactive systems for data traceability and interaction among enterprises, industries, and production lines. These systems use smart contracts as a core technical component, primarily for implementing access control and operational auditing during data interaction, ensuring that data interaction behavior complies with preset business rules. Simultaneously, blockchain technology's immutability and distributed nature guarantee the compliance of data shared and collaborated among multiple entities, supporting full traceability of the interaction process and meeting the participants' fundamental needs for data security and business transparency.

[0003] However, existing blockchain-based data traceability and interaction systems across industries have a critical shortcoming: they cannot distinguish between valid data interactions and exploratory or low-value data requests. This problem stems from the system's design assuming all authorized data requests are reasonable and high-value, lacking a mechanism to assess the actual value of data interactions. Consequently, on-chain resource allocation is not adjusted based on the value differences of requests. In actual operation, a large number of low-value data requests continuously consume on-chain computing and storage resources, causing high-value operations to face queuing delays during processing, thus reducing the overall system throughput efficiency. Solving this problem would improve the real-time processing of high-value operations, enhance the overall system response efficiency, and optimize the collaborative effect of data interaction across industries. Summary of the Invention

[0004] To overcome the aforementioned shortcomings of existing technologies, this invention provides a blockchain-based method and system for tracing and interacting data across three industries, including:

[0005] A blockchain-based method for tracing and interacting data across three industries includes:

[0006] S1: Collect information on the full-scene interaction of data from the three industries and construct a multi-dimensional interactive feature Markov chain;

[0007] S2: Generate an interaction value vector and a semantic label finite state machine based on a Markov chain with multi-dimensional interaction features;

[0008] S3: Based on the interaction value vector and semantic label finite state machine, it implements dynamic resource scheduling and trust feedback mechanisms to optimize on-chain interaction efficiency and shared incentives.

[0009] Furthermore, the steps for constructing a multi-dimensional interaction feature Markov chain include:

[0010] Collect interactive information from the enterprise side, industry side, and production line side across all scenarios, and integrate it to form a set of original interactive information from the three industries;

[0011] Based on the original information set of the three industries' interactions, a cleaned full dataset of the three industries' interactions is generated through data cleaning and spatiotemporal alignment.

[0012] Based on the cleaned full dataset of interactions between the three industries, feature extraction is performed to generate a multi-dimensional interaction feature set. The multi-dimensional interaction feature set includes four core feature dimensions: request subject feature dimension, data attribute feature dimension, business context feature dimension, and behavior time sequence feature dimension.

[0013] Based on the multi-dimensional interaction feature set, a model building operation is performed to generate a multi-dimensional interaction feature Markov chain.

[0014] Furthermore, the steps for performing the model building operation include:

[0015] Discretize the values ​​of each feature in the multi-dimensional interaction feature set to form a set of states of the multi-dimensional interaction feature Markov chain.

[0016] Calculate the transition probability matrix of a Markov chain with multi-dimensional interaction features;

[0017] Construct a multi-dimensional interaction feature Markov chain based on the state set and transition probability matrix; verify the effectiveness of the multi-dimensional interaction feature Markov chain.

[0018] Furthermore, the steps for generating the interaction value vector and semantic label finite state machine include:

[0019] Based on a pre-built historical high-value interaction sample library, the high-value contribution ratio of each feature dimension is calculated by the feature contribution backward inference method to obtain the feature dynamic weight coefficient set.

[0020] Based on the current interaction feature state vector and the feature dynamic weight coefficient set, the current interaction feature state vector is numerically transformed to obtain a numerical current interaction feature vector. Then, based on the numerical current interaction feature vector and the feature dynamic weight coefficient set, the two are weighted and summed to obtain the current interaction value score. Finally, based on the current interaction value score and the sub-scores of each feature dimension, the interaction value vector is constructed. The current interaction feature state vector is a vectorized representation of the matching state of the current request in the multi-dimensional interaction feature Markov chain. The sub-scores of each feature dimension are obtained by multiplying the numerical element of that feature dimension with the corresponding feature dynamic weight coefficient.

[0021] Collect semantic association data of the current interaction, combine the state transition probability of the Markov chain with the multi-dimensional interaction features, and use the semantic label candidate generation algorithm to generate a semantic label candidate set.

[0022] Based on the semantic label candidate set, semantic consistency verification is performed in conjunction with the pre-built business rule base to obtain the final semantic label; then, based on the final semantic label and the state transition probability of the Markov chain of multi-dimensional interaction features, a semantic label finite state machine is constructed.

[0023] Furthermore, the steps of the feature contribution backward deduction method include:

[0024] Extract the feature state vectors of all samples from the historical high-value interaction sample library, organize them according to the feature dimension to form the high-value sample feature state matrix, and obtain the high-value sample feature state matrix.

[0025] Based on the high-value sample feature state matrix, for each feature dimension in the matrix, the number of samples with high-value association values ​​under that feature dimension is counted, and the ratio of the number of samples with high-value association values ​​to the total number of high-value samples is calculated to obtain the high-value contribution ratio of each feature dimension.

[0026] Based on the proportion of high-value contributions of each feature dimension, the proportion of high-value contributions of all feature dimensions is normalized and integrated to obtain a set of dynamic feature weight coefficients.

[0027] Furthermore, the specific sub-steps of the semantic tag candidate generation algorithm are as follows:

[0028] Based on the request-associated task ID in the semantic association data, the business scenario corresponding to the request-associated task ID is matched to initially determine the candidate tag direction related to the business scenario and obtain the initial candidate tag direction;

[0029] Based on the business meaning dictionary of data fields in the initial candidate tag direction and semantic association data, determine the business purpose of the current requested data field, filter the initial candidate tag directions, retain the initial candidate tag directions that match the field purpose, and obtain the filtered candidate tag directions;

[0030] Based on the subject's historical semantic tag sequence in the candidate tag direction and semantic association data after filtering, analyze the high-frequency semantic tags that have appeared in the subject's historical semantic tag sequence in the past, and supplement the candidate tag direction after filtering to obtain the supplemented candidate tag direction.

[0031] Based on the state transition probabilities of the Markov chain with supplemented candidate label directions and multi-dimensional interaction features, the confidence level of each supplemented candidate label direction is calculated. The supplemented candidate label directions and their corresponding confidence levels are integrated to form a complete candidate label structure. All candidate label structures are integrated to obtain a semantic label candidate set.

[0032] Furthermore, the steps for semantic consistency verification are as follows:

[0033] S241: Traverse each candidate tag in the semantic tag candidate set, check whether the candidate tag conforms to all the rules in the business rule base, and obtain the candidate tags that pass the rule verification and the candidate tags that fail the rule verification.

[0034] S242: Based on the candidate labels that have passed the rule verification, select the candidate label with the highest confidence as the final semantic label; if there are multiple highest confidence labels with the same confidence, then combine the business urgency feature in the current interaction feature state vector to prioritize the selection of the label that matches the high urgency, and the label that matches the high urgency refers to the candidate label whose business urgency feature is "urgent".

[0035] S243: If all candidate labels fail the rule verification, the semantic label candidate generation algorithm is called again based on the current interaction feature state vector to generate a new set of semantic label candidates. The verification process from S241 to S242 is repeated until the final semantic label that meets the rules is obtained.

[0036] Furthermore, the dynamic resource scheduling and trust feedback mechanism includes:

[0037] By invoking the interaction value vector and semantic label finite state machine, the real-time resource status of the system is collected and integrated to form a basic dataset for resource scheduling;

[0038] Calculate the initial value of the request priority based on the interaction value vector in the resource scheduling basic dataset;

[0039] Based on the semantic label finite state machine in the resource scheduling basic dataset, the semantic scheduling correction factor is calculated and used to correct the initial value of the request priority, thus obtaining the corrected request priority.

[0040] Based on the corrected request priorities and the real-time resource status of the system, a dynamic resource quota allocation algorithm is used to calculate the request resource quota. The dynamic resource quota allocation algorithm includes: statistically analyzing the corrected request priorities of all pending requests in the current system, calculating the proportion of requests in each priority level (including very high, high, medium, and low); extracting the total allocable resources from the real-time resource status of the system, and setting resource allocation weights according to the priority levels; and combining the proportion of requests and the resource allocation weights to calculate the resource quota for each request, ultimately obtaining the request resource quota.

[0041] Based on the requested resource quota, a scheduling instruction is generated, which is then sent to each processing node in the blockchain and the scheduling execution result is obtained.

[0042] After the scheduling instruction is executed, data usage utility evidence is collected; the data usage utility evidence is a collection of data that proves the actual value of the data used by the requester, including the results of data application scenarios, business collaboration benefits and data reuse contributions;

[0043] Based on data usage utility evidence and interaction value vector, a data collaboration credit score calculation algorithm is used to update the requester's current data collaboration credit score and obtain the updated data collaboration credit score.

[0044] Based on the updated data collaboration credit score and data usage utility evidence, a trust feedback report is generated and the requester's data access permissions are adjusted, thus completing the trust feedback loop.

[0045] Furthermore, the method for updating the requester's current data collaboration credit score using the data collaboration credit score calculation algorithm is as follows:

[0046] Weights are assigned to three types of information for evidence of the utility of data use;

[0047] Convert the three types of information into quantitative scores;

[0048] The utility evidence weighted score is obtained by summing the quantitative score with the weighted average. The current interaction value score in the interaction value vector is converted into a credit score increment proportionally. Then, the historical credit score decay factor is introduced to calculate the updated data collaboration credit score. The calculation formula is: Updated data collaboration credit score = (current data collaboration credit score × decay factor) + utility evidence weighted score + credit score increment.

[0049] A blockchain-based data traceability and interaction system for three industries is provided to implement the aforementioned blockchain-based data traceability and interaction method for three industries. The system includes:

[0050] The Three-Industry Data Acquisition and Markov Chain Construction Module is used to collect information on the full-scenario interaction of data from the three industries and construct a multi-dimensional interactive feature Markov chain.

[0051] Value quantification and semantic attribution module: used to generate interaction value vectors and semantic label finite state machines based on multi-dimensional interaction feature Markov chains;

[0052] Resource Dynamic Scheduling and Trust Feedback Module: Based on value vectors and semantic finite state machines, this module executes resource dynamic scheduling and trust feedback mechanisms to optimize on-chain interaction efficiency and shared incentives.

[0053] Compared to existing technologies, the advantages of this invention are as follows: By collecting information from the entire interaction scenario across three industries and constructing a multi-dimensional interaction feature Markov chain, this invention fully captures key dimensional features such as the request subject, data attributes, business context, and behavioral sequence. This provides comprehensive structured data support for distinguishing between valid data interactions and low-value requests, avoiding misjudgments of value due to missing information. Based on the value quantification and semantic attribution algorithm running on this Markov chain, the generated interaction value vector can accurately quantify the value differences of different requests, fundamentally solving the problem of "treating all authorized requests equally" in existing systems. At the same time, the semantic tag finite state machine gives the on-chain interaction behavior clear business semantics, improving operational interpretability and facilitating compliance auditing.

[0054] The resource dynamic scheduling and trust feedback mechanism implemented on this basis allocates resources according to interaction value and semantic tags, ensuring that high-value operations receive priority access to on-chain resources, effectively avoiding queuing delays for high-value operations and improving the overall system throughput efficiency. Furthermore, trust feedback and credit score adjustments based on data usage utility construct a positive incentive cycle for data sharing, enhancing data providers' willingness to share and ensuring the sustainability of data interaction across industries. The overall solution requires no changes to the underlying blockchain architecture, balancing system compatibility and operational efficiency, achieving a dual improvement in the rational allocation of on-chain resources and the optimization of the data sharing ecosystem. Attached Figure Description

[0055] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the 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.

[0056] Figure 1 This is a flowchart of a blockchain-based data traceability and interaction method for three industries in this invention;

[0057] Figure 2 This is a flowchart of a semantic tag finite state machine in an embodiment of the present invention;

[0058] Figure 3 This is a flowchart of the trust feedback mechanism in an embodiment of the present invention;

[0059] Figure 4 This is a functional module diagram of a blockchain-based three-industry data traceability and interaction system according to the present invention. Detailed Implementation

[0060] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0061] Example 1:

[0062] Please see Figure 1 As shown, this embodiment provides a blockchain-based method for tracing and interacting data across three industries, including:

[0063] S1: Collect information on the full-scene interaction of data from the three industries and construct a multi-dimensional interactive feature Markov chain;

[0064] This step focuses on the blockchain-based data traceability and interaction scenario across three industries. First, it collects full-scenario interaction information from the enterprise side, industry side, and production line side, forming a raw information set of these three industries. This raw information set is a comprehensive dataset containing interaction information from the enterprise side, industry side, and production line side. The specific definitions and acquisition methods for each dimension of information are as follows:

[0065] The enterprise-side interaction information includes an enterprise identity identifier, data request type, request initiation timestamp, and associated business number. The enterprise identity identifier is a unique digital identity code of the enterprise participating in the data interaction within the blockchain system, generated after verification by the identity registration module of the blockchain node. The data request type is the category of data operation initiated by the enterprise, including data query, data writing, data modification, and report retrieval, determined by parsing the operation instruction field when calling the smart contract. The request initiation timestamp is the specific time when the enterprise sends the data request, accurate to the millisecond level, obtained through the time synchronization module of the blockchain system. The associated business number is the specific business item code corresponding to the data request, such as an emergency dispatch business number or a routine report business number, extracted from the business identifier field carried by the enterprise in the request.

[0066] The industry-side interaction information includes the industry collaboration scenario type, data sharing scope, and cross-organizational collaboration level. The industry collaboration scenario type refers to the industry cooperation scenario in which the data interaction takes place, including multimodal transport collaboration, supply chain traceability, and production line collaborative scheduling, which is determined by analyzing the industry business attributes associated with the data request. The data sharing scope refers to the number of enterprises or organizational ranges that the data in this interaction can cover, which is obtained by reading the preset permission scope field in the smart contract. The cross-organizational collaboration level refers to the degree of cooperation between the participating organizations, which is divided into three levels: core collaboration, general collaboration, and temporary collaboration, and is determined by comprehensively judging the frequency of historical collaboration and the degree of business relevance.

[0067] The production line-side interaction information includes production line equipment identifiers, data field types, data update frequency, and business urgency identifiers. The production line equipment identifier is a unique code for the production line equipment that generates or provides data, obtained through hardware identifier registration when the equipment connects to the blockchain. The data field type is the specific field category corresponding to the interactive data, including production line operating parameters, cargo loading / unloading time, and equipment fault information, determined through data dictionary matching. The data update frequency is the regular update interval for this type of production line data, categorized as real-time, minute-level, or hourly, determined by statistically analyzing historical data update intervals. The business urgency identifier indicates the urgency level of the business associated with the data request, categorized as urgent, regular, or low-frequency, marked in the request by the requesting enterprise based on business needs, and verified by the on-chain business verification module.

[0068] Specifically, the steps for collecting full-scene information on data interaction across the three industries and constructing a multi-dimensional interaction feature Markov chain are as follows:

[0069] S11: Collect data from the enterprise side, industry side, and production line side across the entire data interaction scenario, and integrate them to form a set of original information on the interaction of the three industries.

[0070] Specifically, through the distributed acquisition module of the blockchain node, interactive information of corresponding dimensions is obtained from enterprise-side interfaces, industry collaboration platforms, and production line equipment sensors: enterprise-side information is extracted by listening to smart contract call logs, industry-side information is synchronized through the API interface of the industry collaboration platform, and production line-side information is collected through the edge computing gateway and uploaded to the blockchain; the three types of information are initially associated according to "related business number + request initiation timestamp" to ensure that information of the same business is classified into the same record, and finally integrated to form a set of original interactive information of the three industries.

[0071] S12: Based on the original information set of the three industries' interactions, a cleaned full dataset of the three industries' interactions is generated through data cleaning and spatiotemporal alignment.

[0072] Specifically, to remove invalid data from the original information, eliminate spatiotemporal biases, and ensure the accuracy of subsequent feature extraction, the data cleaning and spatiotemporal alignment operation process is as follows:

[0073] S121: Process missing values ​​in the original information set of the three industries' interactions. For information with missing key fields such as enterprise identity identifier and production line equipment identifier, mark it as invalid information and remove it. For information with missing non-key fields such as data update frequency and business urgency identifier, use the historical average of the same type of business to fill in the missing values. That is, find historical interaction records with the same business type as the information and use the average value of the corresponding field in the historical records as the filling value to obtain the dataset after missing value processing.

[0074] S122: Based on the dataset after missing value processing, outliers are identified and corrected. Outliers are determined using the 3σ criterion, which involves calculating the mean and standard deviation of each numerical field (such as the time difference corresponding to the request initiation timestamp and the interval length corresponding to the data update frequency). Values ​​exceeding the mean ± 3 times the standard deviation are marked as outliers. For marked outliers, if the deviation is less than 20%, linear interpolation of the field values ​​at adjacent time points is used for correction. If the deviation is greater than or equal to 20%, it is marked as suspicious information and temporarily stored for further judgment based on subsequent business verification results, thus obtaining the dataset after outlier processing.

[0075] S123: Based on the dataset after outlier processing, spatiotemporal alignment is performed. Using the global timestamp of the blockchain system as a benchmark, the timestamps of the interaction information on the enterprise side, industry side, and production line side are uniformly converted into the global timestamp format to eliminate time deviations between different devices or systems. At the same time, based on the associated business number and the production line equipment identifier, spatial association relationships of information from different sources are established to ensure that the interaction information of the same business or the same equipment forms associated entries in the dataset, and finally generates a cleaned full dataset of interactions between the three industries.

[0076] S13: Based on the cleaned full dataset of interactions between the three industries, perform feature extraction operations to generate a multi-dimensional interaction feature set.

[0077] The multi-dimensional interaction feature set includes four core feature dimensions: request subject feature dimension, data attribute feature dimension, business context feature dimension, and behavior time sequence feature dimension. The extraction logic for each feature dimension is as follows:

[0078] (1) Request subject characteristic dimension: including subject historical interaction frequency, subject credit rating, and subject business type proportion. Subject historical interaction frequency is calculated by collecting the total number of on-chain interaction records of the subject (enterprise or device) in the past 30 days from the full dataset of interactions across the three industries after statistical cleaning; subject credit rating is assessed as A, B, C, or D based on compliance records in the subject's historical interactions (such as whether there are unauthorized requests or whether false business identifiers are provided) through the on-chain credit assessment module; subject business type proportion is calculated by classifying and statistically analyzing the number of emergency, regular, and low-frequency business requests initiated by the subject in the past 30 days, and calculating the proportion of each type of request to the total number of requests.

[0079] (2) Data attribute characteristic dimensions: including data sensitivity level, data field correlation, and data reuse rate. The data sensitivity level is determined as high sensitivity, medium sensitivity, or low sensitivity based on whether the data involves core enterprise parameters, personal information, or other attributes, combined with industry data sensitivity standards; the data field correlation is determined by calculating the ratio of the number of intersections between the data fields of this interaction and the data fields of the subject's historical requests to the total number of historical request fields; the data reuse rate is calculated by counting the number of request records for this type of data from different subjects in the past 7 days.

[0080] (3) Business context feature dimension: including the number of business collaboration participants, the historical completion time of the business, and the business risk coefficient. The number of business collaboration participants is obtained by matching the on-chain collaboration records with the associated business number and counting the number of cross-organizations participating in the business; the historical completion time of the business is obtained by statistically analyzing the average time interval from the initiation of the request to the on-chain confirmation of completion of the same business in the full dataset of interactions between the three industries after cleaning; the business risk coefficient is obtained by calculating the ratio of the number of abnormal records (such as data transmission failure and business interruption) in the historical interactions of the business to the total number of records.

[0081] (4) Behavioral timing characteristics dimension: including request time interval pattern, request sequence continuity, and request field change magnitude. The request time interval pattern is obtained by calculating the coefficient of variation (the ratio of standard deviation to mean) of the time interval for the subject to initiate similar requests; the request sequence continuity is obtained by analyzing the number of consecutive requests of the same business type in the subject's last 10 requests; the request field change magnitude is obtained by comparing the number of differences between the fields in the current request and the fields in the previous request.

[0082] By integrating the features from the four dimensions using the extraction logic described above, a multi-dimensional interactive feature set is generated.

[0083] S14: Based on the multi-dimensional interaction feature set, perform model building operations to generate a multi-dimensional interaction feature Markov chain.

[0084] The multi-dimensional interaction feature Markov chain is a state transition model that includes a set of states and a transition probability matrix. The set of states is composed of discrete combinations of the values ​​of each feature in the multi-dimensional interaction feature set, and the transition probability matrix represents the probability of transitions between states. Its construction process is as follows:

[0085] S141: Determine the state space of the Markov chain of multi-dimensional interaction features, and discretize the values ​​of each feature in the multi-dimensional interaction feature set: divide the subject's historical interaction frequency into three discrete values: high (>100 times / month), medium (30-100 times / month), and low (<30 times / month). The data sensitivity level is also classified as high sensitivity, medium sensitivity, and low sensitivity. Other features are discretized in a similar way. Combine the discrete values ​​of all features, and each combination corresponds to a unique state to form the state set of the Markov chain of multi-dimensional interaction features.

[0086] S142: Calculate the transition probability matrix of the Markov chain with multi-dimensional interaction features. The transition probability estimation method using the time-series sliding window is employed. The specific process is as follows:

[0087] (1) Set the sliding window size based on the amount of historical interaction data in the full dataset of the three industries after cleaning, and ensure that the window contains at least 1,000 consecutive interaction records to ensure the stability of probability estimation;

[0088] (2) Sort the interaction records in the cleaned full dataset of three-industry interactions by global timestamp to form a time-series interaction sequence;

[0089] (3) Slide the sliding window over the time-series interaction sequence. After each slide, count the number of records in the window that transition from state S_i to state S_j (S_i is the current state, and S_j is the state at the next time step).

[0090] (4) Calculate the transition probability P(S_j|S_i), which is the ratio of the number of records that transition from state S_i to state S_j to the total number of records that appear in state S_i;

[0091] (5) Repeat the sliding window operation until the entire time-series interaction sequence is covered. Take the average value of the same transition probability P(S_j|S_i) obtained from multiple calculations as the final state transition probability and integrate them to form a transition probability matrix.

[0092] S143: Construct a multi-dimensional interaction feature Markov chain based on the state set and transition probability matrix; verify the effectiveness of the multi-dimensional interaction feature Markov chain by testing the no-aftereffect property of state transitions using the lag order test method (the probability distribution of future states depends only on the current state and is independent of earlier states): calculate the state transition probabilities with lags of 1, 2, and 3 respectively. If the difference between the transition probabilities of lags of 2 and 3 and the transition probability of lag of 1 is less than 5%, then the no-aftereffect property is satisfied and the model construction is effective; if the difference is greater than or equal to 5%, adjust the sliding window size and re-execute S142 to calculate the transition probabilities until the no-aftereffect property requirement is met, and finally obtain the multi-dimensional interaction feature Markov chain.

[0093] This step collects full-scenario information on data interaction across the three industries and constructs a multi-dimensional interaction feature Markov chain, providing comprehensive and structured foundational data support for subsequent value quantification and semantic attribution. From the perspective of solving core problems, firstly, the full-scenario information collection covers key dimensions such as the request subject, data attributes, business context, and behavioral sequence, enabling the complete capture of implicit features in data interaction and avoiding misjudgments of "effective data interaction" and "exploratory or low-value data requests" due to missing information. For example, features such as the frequency of historical interactions of the subject and the magnitude of changes in request fields can initially distinguish between repetitive queries and normal business requests. Secondly, the multi-dimensional interaction feature Markov chain can characterize the temporal evolution of interaction behavior, reflecting changes in the request subject's behavioral patterns through state transition probabilities. For example, if a subject frequently transitions from the "regular business request state," the Markov chain can depict the temporal evolution of interaction behavior. Reaching the "low-frequency field detection state" allows for early identification of tentative request trends, providing a predictive basis for subsequent resource scheduling. Furthermore, the multi-dimensional interactive feature set and Markov chain generated in this step can be directly used as input variables for subsequent steps, ensuring the continuity of the variable chain and avoiding computational deviations in subsequent value quantification algorithms due to insufficient basic data or structural chaos. At the same time, the design of feature dimensions takes into account the resource efficiency requirements, semantic interpretability, and trust feedback requirements in the main problem. For example, features such as data sensitivity level and subject credit level can provide a basis for value quantification and lay the foundation for semantic label generation and trust feedback mechanisms, achieving synergy in solving multiple problems.

[0094] For example, when a production line device initiates a "multimodal transport cargo loading and unloading time query" request, S1 first collects information from the enterprise side (enterprise identity identifier "ENT-001", data request type "data query"), industry side (industry collaboration scenario type "multimodal transport collaboration"), and production line side (production line device identifier "DEV-123", business urgency identifier "urgent") to form a set of original information from the three industries. After cleaning (removing invalid fields and aligning global timestamps) in S12, a cleaned dataset is obtained. S13 extracts features such as the device's main historical interaction frequency "medium (50 times / month)", data sensitivity level "low sensitivity", number of business collaboration participants "3", and request time interval pattern "variance coefficient 0.2" to generate a multi-dimensional interaction feature set. After discretizing the features, S14 calculates the state transition probability by combining historical data and constructs a multi-dimensional interaction feature Markov chain containing states such as "urgent query - low sensitivity data" to complete this step.

[0095] S2: Generate an interaction value vector and a semantic label finite state machine based on a Markov chain with multi-dimensional interaction features.

[0096] This step focuses on the value quantification and semantic attribution requirements of blockchain's three-industry data interaction. First, it calls the multi-dimensional interaction feature Markov chain generated by S1 to extract the feature state information corresponding to the current data request, obtaining the current interaction feature state vector. This current interaction feature state vector is a vectorized representation of the matching state of the current request in the multi-dimensional interaction feature Markov chain. Its dimensions are completely consistent with the feature dimensions in the multi-dimensional interaction feature set, including four sub-vectors: request subject feature sub-vector, data attribute feature sub-vector, business context feature sub-vector, and behavior time sequence feature sub-vector. The element value of each sub-vector corresponds to the discretized result of that feature dimension in the multi-dimensional interaction feature Markov chain. For example, the subject credit rating element in the request subject feature sub-vector may be "A", "B", "C", or "D". This is determined by matching the features of the current request with the state set of the multi-dimensional interaction feature Markov chain.

[0097] Specifically, the steps for generating the interaction value vector and the semantic label finite state machine are as follows:

[0098] S21: Based on a pre-built historical high-value interaction sample library, the weight coefficients of each feature dimension are calculated using the feature contribution backward deduction method to obtain a dynamic weight coefficient set of features.

[0099] The historical high-value interaction sample library is a dataset storing past high-value interaction records in the blockchain system (such as emergency dispatch instructions, production line anomaly alarm reports, and multimodal transport collaborative decision-making related interactions). High-value interactions are pre-labeled by business experts based on the strategic goals of industry-business synergy, and constructed by selecting records from on-chain historical interaction records that meet conditions such as urgent business urgency, data reuse rate higher than the industry average, and entity credit rating of A or B. The feature contribution reverse deduction method determines the weight by analyzing the contribution ratio of each feature in the high-value samples. Its specific sub-steps are as follows:

[0100] S211: Extract the feature state vectors of all samples from the historical high-value interaction sample library, and organize them according to the feature dimensions to form a high-value sample feature state matrix. Each row of the matrix corresponds to a feature state vector of a high-value sample, and each column corresponds to a feature dimension, thus obtaining the high-value sample feature state matrix.

[0101] S212: Based on the high-value sample feature state matrix, for each feature dimension in the matrix, count the number of samples with high-value correlation values ​​(such as medium sensitivity and low sensitivity of data sensitivity level in data attribute feature dimension, and urgent business urgency in business context feature dimension), calculate the ratio of the number of such samples to the total number of high-value samples, and obtain the high-value contribution ratio of each feature dimension.

[0102] S213: Based on the proportion of high-value contributions of each feature dimension, normalize the proportion of high-value contributions of all feature dimensions so that the sum of the weight coefficients of all feature dimensions is 1. The normalized result is the dynamic weight coefficient of each feature dimension. After integration, the dynamic weight coefficient set of features is obtained.

[0103] The advantage of this method is that it can dynamically adjust the weights based on the actual distribution of historical high-value interactions, avoiding misjudgments of value caused by fixed weights. For example, when the frequency of production line abnormal alarm interactions increases significantly within a certain period, the weight of the business urgency feature will automatically increase to adapt to the dynamic changes in business scenarios.

[0104] S22: Based on the current interaction feature state vector and the feature dynamic weight coefficient set generated in S21, perform a numerical transformation on the current interaction feature state vector to obtain a numerical current interaction feature vector; then, based on the numerical current interaction feature vector and the feature dynamic weight coefficient set, perform a weighted sum operation on the two to obtain the current interaction value score; finally, based on the current interaction value score and the sub-scores of each feature dimension, integrate and construct the interaction value vector.

[0105] The numerical current interaction feature vector is a vector that converts discrete values ​​in the current interaction feature state vector into numerical values. The conversion rule is determined by statistically analyzing the correlation between each discrete value in historical interactions and the actual business value. For example, high, medium, and low are converted to 3, 2, and 1 respectively, and A, B, C, and D are converted to 4, 3, 2, and 1 respectively. The current interaction value score is the overall value quantification result of the current interaction, obtained by multiplying each element of the numerical current interaction feature vector with the corresponding feature dynamic weight coefficient and then summing the results. The value range is 0-100. The interaction value vector is a vector containing overall value and dimensional value. The sub-score of each feature dimension is obtained by multiplying the numerical element of that feature dimension with the corresponding feature dynamic weight coefficient, which is used to intuitively present the contribution of each dimension to the overall value. The numerical element is the element corresponding to different dimensions in the numerical current interaction feature vector.

[0106] S23: Collect the semantic association data of the current interaction, combine it with the state transition probability of the Markov chain of multi-dimensional interaction features generated in S1, and use the semantic label candidate generation algorithm to generate a semantic label candidate set, thus obtaining the semantic label candidate set.

[0107] The semantic association data is a dataset that helps interpret the meaning of the current interaction business, including the request-related task ID, a data field business meaning dictionary, and a subject's historical semantic tag sequence. The request-related task ID is the unique identifier of the business task to which the current request belongs, obtained by parsing the business header field in the current request data packet. The data field business meaning dictionary is a mapping table recording the business purpose corresponding to each data field, such as the cargo loading / unloading time field corresponding to transportation scheduling planning, and the equipment fault code field corresponding to production line maintenance and diagnosis; it is constructed by combining the business specifications of the three industries' data interaction with the data dictionary. The subject's historical semantic tag sequence is a sequence of semantic tags generated by the current request subject's past interactions, sorted by time, obtained by querying the subject's historical interaction logs in the blockchain. The semantic tag candidate generation algorithm is a method for generating candidate tags based on semantic association data and state transition probabilities, and its specific sub-steps are as follows:

[0108] S231: Based on the request-related task ID in the semantic association data, match the business scenario corresponding to the task ID, and initially determine 3-5 candidate label directions related to the scenario. For example, when matching the emergency transportation scheduling task ID, the candidate label directions are "emergency scheduling related query" and "scheduling data verification", thus obtaining the initial candidate label directions.

[0109] S232: Based on the business meaning dictionary of data fields in the initial candidate tag direction and semantic association data, determine the business purpose of the currently requested data field, filter the initial candidate tag directions, retain the tag directions that match the field purpose, and obtain the filtered candidate tag directions.

[0110] S233: Based on the subject's historical semantic tag sequence in the candidate tag direction and semantic association data after filtering, analyze the high-frequency semantic tags that have appeared in the subject's historical semantic tag sequence in the past, and supplement the candidate tag direction after filtering to obtain the supplemented candidate tag direction; specifically, select semantic tags that appear more than 30% of the total sequence length in the subject's historical semantic tag sequence as high-frequency semantic tags.

[0111] S234: Based on the state transition probability of the Markov chain with supplementary candidate label direction and multi-dimensional interaction features, calculate the confidence of each supplementary candidate label direction. The confidence value ranges from 0 to 1. Combine each supplementary candidate label direction with its corresponding confidence to form a complete candidate label. Integrate all candidate labels to obtain a semantic label candidate set.

[0112] S24: Based on the semantic label candidate set generated in S23, semantic consistency verification is performed in combination with the pre-built business rule base to obtain the final semantic label; then, based on the state transition logic of the Markov chain of the multi-dimensional interaction features generated in S1, a semantic label finite state machine is constructed.

[0113] The business rule base is a collection of rules for determining the rationality of semantic tags, including rules such as "requests with an urgent business urgency level must not use the semantic tag for routine report retrieval," "requests with data field relevance lower than the industry average threshold must not use the semantic tag for normal business queries," and "requests where the semantic tags of the subject's three historical interactions are all abnormal pattern detections must have their current semantic tag checked for abnormal relevance first." These rules are formulated by analyzing the business logic, risk scenarios, and compliance requirements of data interaction across the three industries. The state transition logic of the multi-dimensional interaction feature Markov chain refers to the set of transition probabilities and triggering feature dimension change rules between different multi-dimensional interaction feature states (composed of request subject features, data attribute features, business context features, and behavioral timing features) in the multi-dimensional interaction feature Markov chain, based on historical interaction data statistics. For example, when the business urgency feature changes from normal to urgent and the subject's historical interaction frequency feature changes from low to high, the probability and corresponding triggering conditions for the multi-dimensional interaction feature state to transition accordingly. The specific sub-steps of the semantic consistency verification are as follows:

[0114] S241: Iterate through each candidate tag in the semantic tag candidate set, and check whether each tag conforms to all rules in the business rule base to obtain candidate tags that pass the rule validation and candidate tags that fail the rule validation. Candidate tags that fail the rule validation are written to the audit log for subsequent business rule optimization and compliance auditing.

[0115] S242: Based on the candidate labels that have passed the rule verification, select the candidate label with the highest confidence as the final semantic label; if there are multiple highest confidence labels with the same confidence, then combine the business urgency feature in the current interaction feature state vector to prioritize the selection of the label that matches the high urgency, and select the candidate label with the business urgency feature of "urgent" as the label that matches the high urgency.

[0116] S243: If all candidate labels in S241 fail the rule verification, the semantic label candidate generation algorithm in S23 is called again based on the current interaction feature state vector to generate a new set of semantic label candidates. The verification process from S241 to S242 is repeated until the final semantic label that meets the rules is obtained.

[0117] Please see Figure 2As shown, the semantic label finite state machine is a finite state model describing the transition relationship of semantic labels, comprising four core parts: a state set, a transition function, an initial state, and a termination state. The state set consists of all possible final semantic labels in the blockchain three-industry data interaction scenario, such as "emergency dispatch related query," "routine report retrieval," "abnormal pattern detection," "production line collaborative decision query," and "data field verification." The transition function defines the triggering condition for transitioning from one semantic label state to another. This condition is jointly determined by the state transition probability of the multi-dimensional interaction feature Markov chain and the change of semantic related data. For example, when the current semantic label is "routine report retrieval" and the business urgency feature in the multi-dimensional interaction feature Markov chain transitions from normal to emergency, the semantic label is triggered to transition to "emergency dispatch related query." The initial state is the final semantic label of the current interaction. The termination state is the final semantic label updated after the interaction is completed, combined with the feedback of business results, and is determined by collecting the actual use of the current interaction data in subsequent business.

[0118] This step, through the interaction value vector and semantic label finite state machine generated by running value quantification and semantic attribution algorithms, has significant advantages in resolving core contradictions. For the problem of the master being unable to distinguish between valid data interactions and low-value data requests, the interaction value vector achieves precise quantification of interaction value through dynamic weight coefficients. High-value operations (such as emergency scheduling) have significantly higher value scores than low-value requests (such as repetitive report retrieval) due to increased weights for features such as "business urgency" and "data reuse rate," providing a clear value basis for subsequent resource scheduling and avoiding the crude approach of "treating all authorized requests equally." Regarding the lack of semantic interpretability in on-chain access behavior, the semantic label finite state machine not only generates clear business semantic labels for the current interaction but also tracks the dynamic changes in interaction semantics through state transition logic. This upgrades on-chain logs from "metadata streams" to "understandable business records," allowing auditors to grasp the business meaning of interactions without manual contextual review, thus solving the problem of compliance tracing becoming merely a formality. Meanwhile, the value quantification and semantic attribution algorithms are lightweight computations that rely only on existing data and rules for operation. They do not require changes to the underlying blockchain architecture or new hardware, thus balancing system compatibility and operational efficiency. Furthermore, the generated interactive value vector and semantic label finite state machine can be directly used as input variables in step three, ensuring the continuity of the variable chain of the entire method and providing complete data support for subsequent resource scheduling and trust feedback.

[0119] For example, when a production line operator initiates a data request to query the arrival time of multimodal transport goods, S2 first calls the multi-dimensional interaction feature Markov chain of S1 to extract the current interaction feature state vector of the request (where the business urgency is "urgent" and the subject credit rating is "A"); through S21 combined with the historical high-value interaction sample library, a feature dynamic weight coefficient set with business urgency as the highest weight is generated; S22 based on the coefficient set and the current interaction feature state vector, the current interaction value score is obtained and an interaction value vector is constructed; S23 based on the request associated task ID multimodal transport emergency dispatch 003, an initial candidate label direction is generated, and after data field filtering and historical label supplementation, a semantic label candidate set containing "emergency dispatch associated query" and "regular arrival time query" is obtained by combining the state transition probability; S24 based on the business rule base to verify the candidate set, determine "emergency dispatch associated query" as the final semantic label, and then combine the state transition logic of the multi-dimensional interaction feature Markov chain to construct a semantic label finite state machine to complete this step.

[0120] S3: Based on value vectors and semantic finite state machines, it implements dynamic resource scheduling and trust feedback mechanisms to optimize on-chain interaction efficiency and shared incentives.

[0121] This step focuses on the resource optimization and trust incentive requirements for data interaction across the three sectors of the blockchain. First, it invokes the interaction value vector and semantic label finite state machine generated by S2, and, combined with the system's real-time resource status, initiates a dynamic resource scheduling process. The real-time system resource status is a collection of data on the computing resource occupancy rate, remaining storage resources, and network bandwidth utilization rate of each node in the blockchain network, calculated by aggregating the resource monitoring data reported by each node in real time. The computing resource occupancy rate is determined by a weighted average of the CPU and memory usage rates of the node's currently running tasks. The remaining storage resources are determined by the difference between the node's total storage capacity and the used storage capacity. The network bandwidth utilization rate is determined by the ratio of the node's current data transmission rate to its maximum bandwidth.

[0122] Specifically, the steps of the dynamic scheduling and trust feedback mechanism for execution resources are as follows:

[0123] S31: Call the interaction value vector and semantic label finite state machine generated by S2 to collect and integrate the real-time resource status of the system to form a basic dataset for resource scheduling.

[0124] Through the distributed data synchronization module of the blockchain, the interaction value vector (including the current interaction value score and sub-scores of each feature dimension) and the semantic label finite state machine (including the final semantic label and state transition probability) are extracted from the output of S2. At the same time, the computing resource occupancy rate, storage resource remaining amount, and network bandwidth utilization rate data are collected through the resource monitoring interface of each node. The data are then linked and integrated according to "node ID + collection timestamp" to form a basic dataset for resource scheduling, providing complete input for subsequent scheduling calculations.

[0125] S32: Calculate the initial value of the request priority based on the interaction value vector in the resource scheduling basic dataset.

[0126] Specifically, the calculation process for the initial value of the request priority is as follows:

[0127] S321: Extract the current interaction value score from the interaction value vector. The score ranges from 0 to 100 and is used directly as the core basis for priority calculation.

[0128] S322: Call the preset priority grading rules to map the current interaction value score to the corresponding priority level and obtain the initial value of the request priority. The priority levels are divided into four levels: very high, high, medium and low. The preset priority grading rules are formulated by statistically analyzing the processing response time and system resource consumption of historical high-value requests to ensure that high-value score requests correspond to higher priority levels. For example, when the current interaction value score is ≥80, it is mapped to very high priority; when 60≤score<80, it is mapped to high priority; when 40≤score<60, it is mapped to medium priority; and when the score<40, it is mapped to low priority.

[0129] S33: Based on the semantic label finite state machine in the resource scheduling basic dataset, calculate the semantic scheduling correction factor and use it to correct the initial value of the request priority to obtain the corrected request priority.

[0130] Specifically, to avoid misjudging priority based solely on value scores, priority needs to be adjusted in conjunction with business semantics. The method for calculating the corrected request priority is as follows:

[0131] S331: Extract the final semantic label of the current interaction from the semantic label finite state machine, query the pre-built semantic-correction factor mapping table, and obtain the initial correction coefficient; the semantic-correction factor mapping table is a table that records the association between different final semantic labels and their corresponding initial correction coefficients. It is constructed based on the business urgency, system resource consumption sensitivity, and historical resource scheduling effect data corresponding to various semantic labels. For example, when the final semantic label is "emergency scheduling association query", the initial correction coefficient is 1.2; when it is "routine report retrieval", it is 0.8; and when it is "abnormal mode detection", it is 1.1.

[0132] S332: Extract the transition probability of the current semantic label to other states from the semantic label finite state machine. If the probability of the current semantic label transitioning to an emergency label (such as "emergency scheduling related query" or "production line fault alarm response") is greater than a preset threshold (this threshold is determined through the correlation analysis between historical semantic transitions and business urgency, and is usually set to 0.6), then increase the initial correction coefficient to a temporary adjustment coefficient a (the value of a ranges from 0.1 to 0.3, and is determined through the relationship between "transition probability - resource demand increment" in historical scheduling data); if the probability of the current semantic label transitioning to a low-value label (such as "routine report retrieval" or "historical data backup query") is greater than a preset threshold, then decrease the initial correction coefficient a; if the transition probability does not reach the threshold, then keep the initial correction coefficient unchanged, and obtain the semantic scheduling correction factor.

[0133] S333: Multiply the current interaction value score corresponding to the initial request priority by the semantic scheduling correction factor to obtain the corrected value; then remap the corrected value according to the priority classification rule of S322 to obtain the corrected request priority. For example, the original score of 70 (high priority) is multiplied by 1.2 to get 84, and then remapped to extremely high priority.

[0134] S34: Based on the corrected request priority and the real-time resource status of the system, the request resource quota is calculated using a dynamic resource quota allocation algorithm to obtain the request resource quota.

[0135] Specifically, to achieve on-demand resource allocation, the resource allocation percentage for each request needs to be determined by combining priority and remaining resource availability. The process of the dynamic resource quota allocation algorithm is as follows:

[0136] S341: Calculate the corrected request priority of all pending requests in the current system, and calculate the percentage of requests with the four priority levels: extremely high, high, medium, and low. For example, extremely high priority requests account for 15%, high priority requests account for 25%, medium priority requests account for 40%, and low priority requests account for 20%.

[0137] S342: Extract the total allocable resources (including callable computing resources, remaining storage resources, and available network bandwidth) from the system's real-time resource status, and set resource allocation weights according to priority levels. The weights are set to 0.4 for extremely high priority, 0.3 for high priority, 0.2 for medium priority, and 0.1 for low priority, to ensure that high-priority requests receive more resource allocation.

[0138] S343: Calculate the resource quota for each request by combining the proportion of request quantity with the resource allocation weight; specifically, first allocate the total resource quota for each level according to the resource allocation weight, then allocate the quota evenly according to the number of requests in that level, while limiting the resource quota for low-priority requests to no more than 15% of the total system resources (this proportion is determined by the relationship between the historical resource consumption of low-value requests and system efficiency), to avoid low-value requests from excessively occupying resources, and finally obtain the request resource quota.

[0139] S35: Generate scheduling instructions based on the requested resource quota, send them to each processing node in the blockchain, and obtain the scheduling execution results.

[0140] S351: Generate a scheduling instruction based on the revised request priority and request resource quota. The instruction includes information such as the request processing order (sorted from high to low according to the revised priority), the resource allocation quota for each node (e.g., node A is allocated 30% of the computing resources for extremely high priority requests), and the node allocation identifier (specifying the node ID that processes the request).

[0141] S352: The scheduling instructions are synchronized to each processing node through the consensus mechanism of the blockchain. The control node allocates resources and processes requests according to the instructions. After the request is processed, the scheduling execution results fed back by each node are collected. The results include data such as request processing delay time, actual resource usage, and business processing success rate.

[0142] S353: Verify the scheduling execution result. If the processing delay of extremely high and high priority requests exceeds the preset threshold (e.g., extremely high priority delay > 500ms), then readjust the semantic scheduling correction factor (e.g., increase the correction coefficient of the emergency category label) and the resource allocation weight (e.g., increase the weight of extremely high priority to 0.45). Repeat S33 to S342 until the scheduling execution result meets the preset requirements.

[0143] S36: After the resource scheduling is completed, collect data usage utility evidence to provide a basis for trust feedback and obtain data usage utility evidence.

[0144] The data utility evidence refers to a collection of data proving the actual value of the data used by the requester. This data includes three categories: data application scenario results, business collaboration benefits, and data reuse contributions. The collection process is as follows:

[0145] S361: By parsing the result logs of subsequent business operations of the requester, the results of data application scenarios can be obtained, such as whether the scheduling decision based on the query data was successful and whether the production line abnormal alarm was accurate (success is recorded as a valid result, and failure is recorded as an invalid result).

[0146] S362: Compare changes in business metrics before and after data use, and calculate business collaboration benefits, such as the percentage increase in multi-organizational collaboration efficiency and the reduction in operating costs after data use. This is determined by calculating the difference between historical and real-time metric data from the business system.

[0147] S363: Query the subsequent flow and business task records of the data in the blockchain to obtain the data reuse contribution, such as whether the data is used for federated model training or cross-enterprise data collaborative analysis (one effective reuse is counted as one contribution).

[0148] By integrating the three types of information, we can obtain evidence of the effectiveness of data use.

[0149] S37: Based on data usage utility evidence and interaction value vector, a data collaboration credit score calculation algorithm is used to update the requester's current data collaboration credit score and obtain the updated data collaboration credit score.

[0150] The data collaboration credit score is a quantitative indicator that measures the quality of the requester's data usage and the credibility of the collaboration. Its calculation process is as follows:

[0151] S371: Set weights for the three types of information that provide evidence of the utility of data use: business collaboration benefits are weighted at 0.4, data application scenario results are weighted at 0.3, and data reuse contribution is weighted at 0.3. These weights are determined by analyzing the degree of influence of each type of information on the data provider's perceived value.

[0152] S372: Convert the three types of information into quantitative scores (each with a maximum score of 100). For example, the percentage of successful times in the data application scenario results × 100 is the score for this type; the efficiency improvement ratio in business collaboration benefits × 100 is the score for this type; and the effective reuse count in data reuse contribution × 10 is the score for this type (maximum 100).

[0153] S373: Calculate the utility evidence weighted score (sum of various scores × corresponding weights), convert the current interaction value score in the interaction value vector into a credit score increment at a ratio of 1:10 (e.g., a score of 80 is converted into an increment of 8 points), and then introduce the historical credit score decay factor. The optimal value of this factor is 0.95-0.99. The longer the credit score has not been updated, the greater the decay. This factor is determined through credit score timeliness analysis. Finally, the updated data collaboration credit score is calculated as "Updated data collaboration credit score = (current data collaboration credit score × decay factor) + utility evidence weighted score + credit score increment".

[0154] S38: Based on the updated data collaboration credit score and data usage utility evidence, generate a trust feedback report and adjust the requester's data access permissions to complete the trust feedback loop.

[0155] Specifically, the trust feedback and permission adjustment process is as follows:

[0156] S381: Integrate the data requester's identity (unified identity URI), data usage scenario (final semantic tag), utility evidence details (quantified scores of the three types of information), and updated data collaboration credit score to generate a trust feedback report; send the report to the corresponding data provider through the blockchain's encrypted transmission channel to ensure information immutability and privacy security.

[0157] S382: Invoke the pre-built data permission association rules and adjust the requester's subsequent data access permissions according to the updated data collaboration credit score; the data permission association rules are a set of rules that set the correspondence between credit score and access range and access frequency. For example, when the credit score is ≥800, the requester can access highly sensitive data and the access frequency limit is relaxed to 10 times per hour; when the credit score is 600≤credit score<800, the requester can access moderately sensitive data and the access frequency is limited to 5 times per hour; when the credit score is <600, the requester can only access low-sensitivity data and the access frequency is limited to 2 times per hour.

[0158] S383: Synchronize the permission adjustment results (including the adjusted access scope and frequency limits) to the blockchain's permission management module for permission verification of subsequent requests, completing the trust feedback mechanism. For an example of the trust feedback mechanism, please refer to [link / reference]. Figure 3 .

[0159] This step fundamentally solves the main problems by implementing dynamic resource scheduling and a trust feedback mechanism. From a resource scheduling perspective, dynamic priority adjustment based on interactive value vectors and semantic tag finite state machines breaks the traditional model of "treating all authorized requests equally," allowing high-value requests (such as emergency scheduling instructions and production line anomaly alarms) to obtain resources first, effectively reducing their on-chain queuing delays and improving the overall system throughput efficiency. This process does not require changes to the underlying blockchain architecture; it only achieves value-perceived resource allocation through lightweight algorithms, adapting to the dynamic changes in business data interaction across the three industries. From a trust feedback perspective, the collection of evidence of data usage utility and the updating of data collaboration credit scores build a transparent value feedback loop for data providers, solving the problem of "one-way payment without feedback." The association between credit scores and data permissions forms a positive incentive cycle of "high-quality requests to high credit scores to higher permissions," significantly enhancing the data provider's willingness to share and ensuring the sustainability of data sharing across the three industries. In addition, the entire mechanism has dynamic adaptability, such as automatically compressing the resource quota of low-value requests when system resources are scarce, and adjusting priorities through semantic correction factors when business scenarios change, so as to ensure that a balance between efficiency and fairness can be achieved in different operating states.

[0160] For example, a multimodal transport company initiates a "production line cargo inventory data query" request. S3 first calls the interaction value vector (current interaction value score 75) from S2 and the semantic label finite state machine (final semantic label "emergency scheduling associated query"), combined with the system's real-time resource status (computation resource utilization rate 30%, sufficient storage) to form a basic dataset; S32 maps the score 75 to high priority (initial value of request priority); S33 queries the semantic-correction factor mapping table to obtain an initial coefficient of 1.2. Since the probability of the current label transitioning to the emergency category is 0.7 > 0.6, after increasing a = 0.1, the semantic scheduling correction factor is obtained as 1.3, 75 × 1.3 = 97.5, and the mapping is re-applied. The priority is set to extremely high (corrected request priority); S34 calculates resource quotas with an extremely high priority weight of 0.4, generates scheduling instructions, and the nodes process them first. The scheduling execution result shows a delay of 300ms (meets the threshold); subsequently, utility evidence is collected (successful scheduling decision, 15% improvement in collaboration efficiency, no reuse), and a utility weighted score of 62 is calculated, with a credit score increment of 7.5. The initial credit score is 500 × 0.98 (decay factor) + 62 + 7.5 = 559.5 (updated credit score); a trust feedback report is generated and sent to the production line data provider. Based on the credit score of 559.5, the enterprise's permissions are adjusted to "accessible to moderately sensitive data, 5 times per hour", completing this step.

[0161] Example 2:

[0162] This embodiment, based on Embodiment 1, provides a blockchain-based data traceability and interaction system for three industries, such as... Figure 4 As shown, it includes:

[0163] The Three-Industry Data Acquisition and Markov Chain Construction Module is used to collect information on the full-scenario interaction of data from the three industries and construct a multi-dimensional interactive feature Markov chain.

[0164] Value quantification and semantic attribution module: used to generate interaction value vectors and semantic label finite state machines based on multi-dimensional interaction feature Markov chains;

[0165] Resource Dynamic Scheduling and Trust Feedback Module: Based on value vectors and semantic finite state machines, this module executes resource dynamic scheduling and trust feedback mechanisms to optimize on-chain interaction efficiency and shared incentives.

Claims

1.A blockchain-based three-industry data traceability interaction method, characterized in that, The method comprises: Collecting three-industry data interaction full-scene information, and constructing a multi-dimensional interaction feature Markov chain; Based on the multi-dimensional interaction feature Markov chain, an interaction value vector and a semantic label finite state machine are generated; Based on the interaction value vector and the semantic label finite state machine, a resource dynamic scheduling and trust feedback mechanism is executed to optimize the interaction efficiency and shared incentive on the chain; The step of generating the interaction value vector and the semantic label finite state machine comprises: Based on the pre-constructed historical high-value interaction sample library, the feature contribution degree reverse deduction method is used to calculate the high-value contribution proportion of each feature dimension to obtain a feature dynamic weight coefficient set; Based on the current interaction feature state vector and the feature dynamic weight coefficient set, numerical conversion is performed on the current interaction feature state vector to obtain a numerical current interaction feature vector; then based on the numerical current interaction feature vector and the feature dynamic weight coefficient set, weighted summation operation is performed on the two to obtain a current interaction value score; finally, based on the current interaction value score and the sub-score of each feature dimension, an interaction value vector is constructed; the current interaction feature state vector is a vectorized expression of the matching state of the current request in the multi-dimensional interaction feature Markov chain; the sub-score of each feature dimension is obtained by multiplying the numerical element of the feature dimension by the corresponding feature dynamic weight coefficient; Collecting semantic correlation data of the current interaction, combining the state transition probability of the multi-dimensional interaction feature Markov chain, and using a semantic label candidate generation algorithm to generate a semantic label candidate set to obtain the semantic label candidate set; Based on the semantic label candidate set, a semantic consistency check is performed in combination with the pre-constructed business rule library to obtain a final semantic label; then based on the final semantic label and the state transition probability of the multi-dimensional interaction feature Markov chain, a semantic label finite state machine is constructed. 2.The blockchain-based three-industry data traceability interaction method according to claim 1, characterized in that, The step of constructing the multi-dimensional interaction feature Markov chain comprises: Collecting interaction full-scene information on the enterprise side, the industry side and the production line side, and integrating to form a three-industry interaction original information set; Based on the three-industry interaction original information set, through data cleaning and space-time alignment, a cleaned three-industry interaction full data set is generated; Based on the cleaned three-industry interaction full data set, a feature extraction operation is performed to generate a multi-dimensional interaction feature set; the multi-dimensional interaction feature set comprises four core feature dimensions, i.e., a request subject feature dimension, a data attribute feature dimension, a business context feature dimension and a behavior time sequence feature dimension; Based on the multi-dimensional interaction feature set, a model construction operation is performed to generate a multi-dimensional interaction feature Markov chain. 3.The blockchain-based three-industry data traceability interaction method according to claim 2, characterized in that, The step of performing the model construction operation comprises: Discretizing the values of each feature in the multi-dimensional interaction feature set to form a state set of the multi-dimensional interaction feature Markov chain; Calculating a transition probability matrix of the multi-dimensional interaction feature Markov chain; Based on the state set and the transition probability matrix, the multi-dimensional interaction feature Markov chain is constructed; and the effectiveness of the multi-dimensional interaction feature Markov chain is verified. 4.The blockchain-based three-industry data traceability interaction method according to claim 3, characterized in that, The step of the feature contribution degree reverse deduction method comprises: Extract the feature state vector of all samples from the historical high-value interaction sample library, organize the high-value sample feature state matrix according to the feature dimension, and obtain the high-value sample feature state matrix; Based on the high-value sample feature state matrix, the number of samples with a high-value correlation value in each feature dimension is counted, and the ratio of the number of samples with a high-value correlation value to the total number of high-value samples is calculated to obtain the high-value contribution proportion of each feature dimension; Based on the high-value contribution proportion of each feature dimension, the high-value contribution proportions of all feature dimensions are normalized to obtain the feature dynamic weight coefficient set. 5.The blockchain-based three-industry data traceability interaction method according to claim 4, characterized in that, The specific sub-steps of the semantic label candidate generation algorithm are: Based on the request association task ID in the semantic association data, the business scenario corresponding to the request association task ID is matched, the initial candidate label direction related to the business scenario is determined, and the initial candidate label direction is obtained; Based on the initial candidate label direction and the data field business meaning dictionary in the semantic association data, the business purpose of the current request data field is judged, the initial candidate label direction is filtered, and the initial candidate label direction matching the field purpose is retained to obtain the filtered candidate label direction; Based on the filtered candidate label direction and the subject historical semantic label sequence in the semantic association data, the high-frequency semantic labels appearing in the subject historical semantic label sequence are analyzed, the high-frequency semantic labels are supplemented to the filtered candidate label direction, and the supplemented candidate label direction is obtained; Based on the supplemented candidate label direction and the state transition probability of the multi-dimensional interaction feature Markov chain, the confidence of each supplemented candidate label direction is calculated, the supplemented candidate label direction and the corresponding confidence are integrated to form a complete candidate label, and all candidate labels are integrated to obtain a semantic label candidate set. 6.The blockchain-based three-industry data traceability interaction method according to claim 5, characterized in that, The steps of the semantic consistency verification are: S241: Each candidate label in the semantic label candidate set is traversed, and whether the candidate label meets all rules in the business rule library is checked one by one to obtain candidate labels that pass the rule verification and candidate labels that do not pass the rule verification; S242: Based on the candidate labels that pass the rule verification, the candidate label with the highest confidence is selected as the final semantic label; if there are multiple highest confidence labels with the same confidence, the label matching the high urgency is preferentially selected in combination with the business urgency feature in the current interaction feature state vector, and the label matching the high urgency is the candidate label with the business urgency feature "urgent"; S243: If all candidate labels do not pass the rule verification, the semantic label candidate generation algorithm is called again based on the current interaction feature state vector to generate a new semantic label candidate set, and the verification process of S241 to S242 is repeated until the final semantic label that meets the rules is obtained. 7.The blockchain-based three-industry data traceability interaction method according to claim 6, characterized in that, The resource dynamic scheduling and trust feedback mechanism includes: Call the interaction value vector and the semantic label finite state machine to collect and integrate the real-time resource state of the system to form a resource scheduling basic data set; Based on the interaction value vector in the resource scheduling basic data set, the request priority initial value is calculated; Based on the semantic tag finite state machine in the resource scheduling basic data set, a semantic scheduling correction factor is calculated, and the request priority initial value is corrected by using the semantic scheduling correction factor to obtain a corrected request priority; Based on the corrected request priority and the real-time resource state of the system, a request resource quota is calculated by using a resource quota dynamic allocation algorithm; the resource quota dynamic allocation algorithm includes: the corrected request priorities of all pending requests in the current system are counted, the request quantity proportions of each priority level are calculated, and the priority levels include very high, high, medium, and low; the total allocatable resource amount is extracted from the real-time resource state of the system, and resource allocation weights are set according to the priority levels; the resource quota of each request is calculated by combining the request quantity proportions and the resource allocation weights, and finally the request resource quota is obtained; Based on the request resource quota, a scheduling instruction is generated and sent to each processing node of the blockchain to obtain a scheduling execution result; After the scheduling instruction is executed, data use utility evidence is collected; the data use utility evidence is a set of data proving the actual use value of the requestor, including data application scenario results, business synergy benefits, and data reuse contributions; Based on the data use utility evidence and the interaction value vector, a data collaboration credit score calculation algorithm is used to update the current data collaboration credit score of the requestor to obtain an updated data collaboration credit score; Based on the updated data collaboration credit score and the data use utility evidence, a trust feedback report is generated and the data access permission of the requestor is adjusted to complete the trust feedback closed loop. 8.The blockchain-based three-industry data traceability interaction method according to claim 7, characterized in that, The method for updating the current data collaboration credit score of the requestor by using the data collaboration credit score calculation algorithm is: Setting weights for the three types of information of the data use utility evidence; Converting the three types of information into quantitative scores; Summing the quantitative scores and the weights to obtain a utility evidence weighted score, converting the current interaction value score in the interaction value vector into a credit score increment in proportion, and introducing a historical credit score decay factor to calculate the updated data collaboration credit score, and the calculation formula is: updated data collaboration credit score = (current data collaboration credit score x decay factor) + utility evidence weighted score + credit score increment. 9.A blockchain-based three-industry data traceability interaction system for implementing the blockchain-based three-industry data traceability interaction method of any one of claims 1-8, characterized in that, The system includes: A three-industry data collection and Markov chain construction module for collecting three-industry data interaction full-scene information and constructing a multi-dimensional interaction feature Markov chain; A value quantification and semantic attribution module for generating an interaction value vector and a semantic tag finite state machine based on the multi-dimensional interaction feature Markov chain; A resource dynamic scheduling and trust feedback module for executing a resource dynamic scheduling and trust feedback mechanism based on the value vector and the semantic finite state machine to optimize the interaction efficiency and sharing incentives on the chain.

Images