A blockchain network-based multimodal transport resource data sharing method and system

Abstract

This invention belongs to the field of information sharing technology for multimodal transport, specifically relating to a method and system for sharing multimodal transport resource data based on a blockchain network. The method includes: classifying multimodal transport resource data by category to construct a shared interface containing data nodes; responding to call requests, generating a current state value based on the total number of calls and user input through a dynamic correction mechanism, determining the state level of the shared interface and the corresponding update operation; collecting usage feedback scores, comparing the data of data nodes with the usage feedback scores for consistency and matching degree evaluation, and accordingly performing replacement operations on data nodes or marking them as pending updates. This invention improves resource utilization efficiency and stability through a dynamic correction mechanism and differentiated management, ensures data accuracy and reliability through consistency comparison, and achieves forward-looking and timely data management based on score sequence evaluation, ensuring the long-term value of shared data.

Description

Technical Field

[0001] This invention belongs to the field of information sharing technology for multimodal transport, specifically relating to a method and system for sharing multimodal transport resource data based on a blockchain network. Background Technology

[0002] With the deepening development of global trade integration and supply chain management, multimodal transport, as a modern logistics system integrating various modes of transportation such as railways, highways, waterways and aviation, has become a key infrastructure supporting international trade and regional economic development.

[0003] Existing multimodal transport information sharing practices, even with the introduction of emerging technologies such as blockchain, still suffer from many inherent defects and technical bottlenecks. Performance bottlenecks exist in terms of data sharing efficiency and real-time performance. In traditional solutions, information from each participating party (such as freight companies, ports, and customs) is independent, forming "information silos," leading to high data exchange latency and poor consistency. Initial blockchain solutions often employ a simple and crude method of querying the entire dataset. As on-chain transaction records accumulate, querying the complete ledger contains a large amount of historical, expired, or obsolete data. This not only wastes significant network bandwidth and computing resources and affects the real-time performance of data acquisition, but existing methods also have deficiencies in data quality and availability, generally lacking a management mechanism for the lifecycle of on-chain data and failing to effectively distinguish between currently valid resource states and expired historical records. Summary of the Invention

[0004] This invention provides a method and system for sharing multimodal transport resource data based on a blockchain network, in order to address the shortcomings of existing technologies.

[0005] This invention provides a method for sharing multimodal transport resource data based on a blockchain network, comprising:

[0006] When the running status of the shared interface is detected to meet the first type of update triggering condition, the update operation corresponding to the first type of update triggering condition is executed; when the data quality of the data node in the shared interface is detected to meet the second type of update triggering condition, the update operation corresponding to the second type of update triggering condition is executed.

[0007] The steps for detecting that the running status of a shared interface meets the first type of update triggering conditions include: counting the number of calls to each shared interface to generate a total call count, obtaining the user input associated with the shared interface, and determining the status level of the shared interface based on the total call count, preset time parameters, and user input. The status level is used to indicate whether the running status of the shared interface meets the first type of update triggering conditions.

[0008] In a preferred technical solution, the steps for determining the status level of the shared interface based on the total number of calls, preset time parameters, and user input include:

[0009] Based on the total number of calls, preset time parameters, and user input, a dynamic correction mechanism is used to generate the current status value for each shared interface.

[0010] The current status value is compared with the preset first threshold and second threshold to determine the status level of the shared interface.

[0011] In a preferred technical solution, the steps for performing the update operation corresponding to the first type of update triggering condition include:

[0012] When the status level is determined to be busy, immediately perform an update operation on the shared interface, and...

[0013] When the status level is determined to be idle, an update operation is performed on the shared interface during the preset low data request period.

[0014] In a preferred technical solution, the step of generating the current state value through a dynamic correction mechanism includes:

[0015] During the evaluation period, the number of cumulative call actions is used to obtain the periodic call volume, and user input actions are recorded to obtain the user input volume. The ratio of user input volume to periodic call volume is calculated to obtain the input ratio. The input ratio and periodic call volume are stored as correction reference items. A preliminary state value is calculated based on the total number of calls, preset time parameters, and input ratio. The preliminary state value is then corrected using the correction reference items to generate the current state value.

[0016] In a preferred technical solution, the steps for detecting that the data quality of a data node meets the second type of update triggering condition include:

[0017] Collect user feedback scores on the data obtained through data nodes and form a score sequence.

[0018] The data at each data node is compared for consistency with the usage feedback score. If the comparison result indicates a consistency mismatch, then the second type of update trigger condition is determined to be met.

[0019] If the consistency comparison result is not a consistency mismatch, the matching degree of the data nodes is evaluated according to the scoring sequence. If the matching degree is lower than the preset matching threshold, it is determined that the second type of update triggering condition is met.

[0020] In a preferred technical solution, the steps for performing the update operation corresponding to the second type of update triggering condition include:

[0021] When the consistency comparison results in a consistency mismatch, a replacement operation is performed on the data node, and...

[0022] When the matching degree is lower than the preset matching threshold, the data node is marked as pending update, and a replacement operation is performed on the data node marked as pending update within the preset update period.

[0023] In a preferred embodiment, the method further includes, before performing monitoring: acquiring multimodal transport resource data, classifying the multimodal transport resource data according to its category, and constructing a shared interface for each category, wherein each shared interface contains at least one data node.

[0024] This invention also provides a multimodal transport resource data sharing system based on a blockchain network, used to implement the multimodal transport resource data sharing method based on a blockchain network described in any one of the above embodiments, comprising:

[0025] The state-aware unit monitors the call behavior and user input associated with the shared interface, and also monitors the usage feedback scores submitted by the caller based on the data obtained through the data node.

[0026] The update decision unit responds to the monitoring results of the status perception unit, and determines whether the running status of the shared interface meets the first type of update triggering conditions based on the calling behavior and user input, combined with the dynamic correction mechanism. Based on the user feedback score, it determines whether the data quality of the data node meets the second type of update triggering conditions. Based on the determination results of the first type of update triggering conditions or the second type of update triggering conditions, it generates the corresponding update instructions.

[0027] The instruction execution unit receives and executes the update instructions generated by the update decision unit to perform update or replacement operations on the shared interface or data node. The dynamic correction mechanism is configured to generate correction reference items based on the call volume and user input volume in the historical evaluation period, and feeds the correction reference items back to the update decision unit to correct the determination of the running status of the shared interface.

[0028] In a preferred technical solution, the update decision unit compares the current state value generated based on the call behavior and user input with a preset first threshold and a second threshold to determine whether the running state of the shared interface is busy or idle, and uses the busy or idle state as the first type of update trigger condition.

[0029] In a preferred technical solution, the update decision unit compares the data of the data node with the usage feedback score for consistency, and uses the result of consistency mismatch as a second type of update trigger condition, and...

[0030] In cases where there is no inconsistency mismatch, the matching degree of data nodes is evaluated, and results where the matching degree is lower than a preset matching threshold are used as the second type of update trigger condition. Beneficial effects

[0031] This invention introduces a dynamic correction mechanism, which comprehensively considers the total number of calls to the shared interface and the amount of user input to generate the current status value and determine the status level of the shared interface accordingly. This invention can realize differentiated management of the shared interface. By dynamically sensing the running status of the shared interface, it can execute corresponding update operations according to the status level, overcome the rigidity of traditional fixed resource allocation, and improve resource utilization efficiency and operational stability.

[0032] This invention identifies consistency mismatches by comparing the data of data nodes with usage feedback scores. When a consistency mismatch is identified, a replacement operation is performed on the data node. This method establishes a rapid quality monitoring closed loop, which can promptly detect and correct erroneous data, thereby effectively ensuring the accuracy and reliability of shared multimodal transport resource data and preventing the spread of erroneous data in the network.

[0033] This invention uses feedback scoring to form a scoring sequence and evaluates the matching degree of data nodes accordingly. If the matching degree is lower than a preset matching threshold, the data node is marked as pending update, and a replacement operation is performed on the data node within a preset update period. Through this time-series-based evaluation, this invention achieves proactive data timeliness management. This scheme can proactively identify data that is gradually losing its timeliness through scoring trends and update it at opportune times, ensuring data updates while avoiding performance impact on the system, thereby enhancing the long-term value of shared data. Attached Figure Description

[0034] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation Example 1

[0035] This embodiment provides a multimodal transport resource data sharing method based on a blockchain network. It aims to address the technical challenges of diverse data sources, inconsistent data quality, and difficulty in guaranteeing sharing efficiency in multimodal transport scenarios by constructing a dynamic evaluation and quality feedback mechanism. This will improve the effectiveness, efficiency, and security of multi-party collaboration. The method mainly includes the following steps:

[0036] We receive multimodal transport resource data uploaded in the form of data files from various data providers, such as shipping companies, railway departments, or warehousing centers. These data files vary in format, including spreadsheets, XML documents, or proprietary message formats. The content covers container status, capacity availability, port operation time windows, etc. To achieve standardized processing, we extract key parameters from the data file content, such as container number, current location coordinates, cargo type, and estimated arrival time, and mark these key parameters as data tags.

[0037] Based on data tags, preset standard templates are invoked. Each standard template corresponds to a specific resource data category; for example, there are standard templates specifically for cold chain container data. Key fields, such as temperature records, humidity levels, and door open status, are extracted from the standard templates. These key fields are then matched with the data files to classify the multimodal transport resource data, transforming the raw data into a unified format and laying the foundation for subsequent sharing and access.

[0038] After classification, a shared interface is built for each category. Each shared interface logically corresponds to a smart contract or a set of API endpoints in the blockchain network and contains at least one data node. The data node refers to a standardized data record stored in a distributed ledger or off-chain storage system. The shared interface is managed uniformly as a bridge between the application layer and the blockchain storage layer to ensure the integrity and security of subsequent calls.

[0039] Every data query or read request initiated by a user or other module to the shared interface is recorded as a call request. Every successful call request is recorded as a call action. The number of call actions for each shared interface is continuously accumulated and counted to generate the total number of calls to the shared interface. It should be noted that this total number of calls is a basic indicator for measuring the popularity and usage frequency of the interface.

[0040] To accurately assess the actual load and data value of the interface, this method introduces a dynamic correction mechanism. This mechanism is a comprehensive consideration of call frequency and user input volume to dynamically correct the interface status evaluation value. It aims to more accurately reflect the actual load and data value of the interface. This mechanism not only considers call frequency but also introduces user input volume as a key correction factor. It should be noted that user input volume refers to the amount of data associated with the shared interface that is actively updated, corrected, or confirmed by users, which reflects the real interactivity and timeliness of the data.

[0041] First, define the evaluation period, for example, every 10 minutes. Within each evaluation period, accumulate the number of calls to obtain the periodic call volume. Record the user input behaviors related to the interface data, for example, the carrier updates the transportation status of goods to obtain the user input volume within the evaluation period. Calculate the ratio of user input volume to periodic call volume to obtain the input ratio.

[0042] Before the start of the next evaluation cycle, the input ratio of this cycle and the cycle call amount are stored together as a correction reference item, which is used as a data item for subsequent correction of the initial state value.

[0043] When generating the current status value, the initial status value is first calculated based on the total number of calls, preset time parameters, and input ratio using a preset calculation formula. The initial status value is then corrected using a correction reference to generate the current status value. For example, if the current call volume surges but the historical input ratio continues to decline, the dynamic correction mechanism will appropriately lower the final current status value to prevent misjudgment of the interface status due to temporary, low-value automatic polling.

[0044] It should be noted that the preliminary state value refers to the initial state evaluation value calculated only based on the total number of calls, preset time parameters, and input ratios before dynamic correction. The current state value refers to the final state value generated after correcting the preliminary state value using correction reference items, reflecting the current load and value of the shared interface.

[0045] The current state value generated through a dynamic correction mechanism is compared with preset first and second thresholds to determine the state level of the shared interface, such as stable, busy, or idle. To achieve intelligent resource scheduling and avoid executing non-urgent update tasks during peak periods, the specific judgment logic is as follows:

[0046] If the current state value is greater than the first threshold and less than the second threshold, the state level is determined to be a stable state. When the state level is a stable state, no update operation is performed on the shared interface.

[0047] If the current status value is greater than the second threshold, the status level is determined to be busy. When the status level is busy, an update command is generated and sent to immediately perform update operations on the shared interface, such as scaling up by adding redundant data nodes or migrating to a more powerful server.

[0048] If the current status value is less than the first threshold, the status level is determined to be idle. When the status level is idle, the shared interface is updated during the preset low data request period, so as to complete the maintenance without affecting the user experience.

[0049] To ensure the quality of shared data, this method establishes a two-layer quality monitoring and replacement mechanism to handle two situations: data content errors and data quality degradation. It combines a dual monitoring process of consistency comparison and matching degree assessment to handle the quality assurance mechanism for two situations: fundamental data content errors and gradual data quality degradation.

[0050] Collect usage feedback scores from callers regarding the data obtained through data nodes, and arrange these scores in chronological order to form a score sequence.

[0051] It should be noted that the feedback score refers to the subjective evaluation score given by the data user regarding the quality of the data obtained through the data node.

[0052] The first layer of monitoring involves comparing the data of the data node with the user feedback score for consistency. Specifically, this involves inputting the data of the data node and the user feedback score into a preset comparison model. If the consistency result output by the comparison model is inconsistent, it is determined to be a consistency mismatch. This situation indicates that there is a fundamental error in the data provided by the node. At this time, a replacement operation is performed on the data node, such as replacing the content of the file linked to the data node. In this application, consistency comparison refers to the process of inputting the data of the data node and the user feedback score into the comparison model to determine whether there is a fundamental contradiction or error between the two.

[0053] Specifically, the comparison model refers to a computational model used to determine whether there is a logical contradiction between the content of data records and user feedback, and its specific definition is as follows:

[0054] Input: Data from data nodes (Represented as a set of structured features), using feedback scoring (Represented as a feature vector containing rating values ​​and text keywords).

[0055] Output: Consistent results .

[0056] In the formula: (Consistency Result): The judgment result output by the model is used to indicate whether there is a logical contradiction between the data and the feedback;

[0057] (Pattern detection function): used to detect the pattern. A function that returns 1 if the data status is "delivered" but the feedback rating is "not received" is detected; otherwise, it returns 0.

[0058] (Mode Weight): Corresponding to the first The severity weight of each logical contradiction pattern;

[0059] (Consistency Threshold): The threshold used to determine whether a "discrepancy" exists based on the cumulative weighted inconsistency score;

[0060] (Total number of patterns): The total number of predefined logical contradiction patterns.

[0061] The second layer of monitoring: If the consistency comparison result is not a consistency mismatch, the regular quality assessment process is initiated. To identify potential data quality issues, such as outdated data or data that no longer meets user needs, trend analysis is performed on the scoring sequence. Specifically, a scoring curve is generated based on the scoring sequence, and the scoring curve is input into a preset evaluation model to generate trend parameters. The trend parameters are used to characterize the changing trend of data usage evaluation. The trend parameters are compared with a preset offset limit. If the trend parameters are greater than the offset limit, it is determined that there is an anomaly in the scoring, and an alarm is triggered for manual analysis.

[0062] Input: rating sequence ,in At discrete time points User feedback rating.

[0063] Output: Trend parameters .

[0064] Mathematical formula: The formula calculates the time. As an independent variable, rating The slope of the fitted line obtained after performing simple linear regression on the scatter plot sequence as the dependent variable.

[0065] In the formula:

[0066] (Trend parameter): Represents the linear trend of the rating sequence over time. Positive values ​​indicate that the ratings tend to increase, while negative values ​​indicate that the ratings tend to decrease.

[0067] (Sequence length): The total number of data points in the scoring sequence.

[0068] (Moment rating): At the time index... User feedback rating.

[0069] (Time Index): The time-order index of the rating in the sequence, from 1 to N.

[0070] In routine evaluation, the matching degree of data nodes is assessed based on the scoring sequence. This process involves processing the scoring sequence to output matching relationship parameter values, comparing these values ​​with a preset matching benchmark value, and determining that the matching degree is below a preset matching threshold if the matching relationship parameter value is less than the benchmark value. In this case, the data node is marked as pending update, and the time of marking the data node is recorded as the delay start point. Based on the delay start point and a preset delay duration, the time for performing the replacement operation is determined, and the replacement operation for the data node marked as pending update is performed at the specified time within the preset update period. This delay processing mechanism aims to avoid unnecessary node replacements due to accidental scoring fluctuations, thereby enhancing stability.

[0071] This solution is applicable to collaborative logistics management platforms involving multiple independent nodes, and can improve sharing efficiency and user satisfaction, especially in scenarios with complex multimodal transport resources and frequent data interaction. Example 2

[0072] This embodiment provides a multimodal transport resource data sharing system based on a blockchain network, used to execute the multimodal transport resource data sharing method based on a blockchain network described in the above embodiment. By dynamically monitoring the operating status of the sharing interface and the data quality of the data nodes, and triggering corresponding update operations based on the monitoring results, the sharing efficiency and reliability can be improved.

[0073] In this embodiment, the multimodal transport resource data sharing system based on a blockchain network includes: an interface construction unit, a status awareness unit, an update decision unit, and an instruction execution unit.

[0074] The interface construction unit performs the initialization operations before operation. This unit first obtains multimodal transport resource data, classifies the multimodal transport resource data according to its category (e.g., by mode of transport, region, and cargo type), and builds an independent shared interface for each category. Each shared interface contains at least one data node.

[0075] The State Awareness Unit continuously monitors various key indicators during system operation. This unit performs the following operations: monitors the call behavior associated with each shared interface to accumulate the number of call behaviors, records the amount of user input generated during the call process, this monitoring provides raw data for subsequently determining the first type of update trigger conditions, collects and records the usage feedback scores submitted by the caller after obtaining data through the data node, and forms these scores into a score sequence required for subsequent processing.

[0076] The update decision unit responds to the monitoring results of the state awareness unit and determines whether the update triggering conditions are met. The specific workflow of this unit is as follows: For the determination of the first type of update triggering conditions, this unit receives the call behavior and user input provided by the state awareness unit. It accumulates and counts the number of call behaviors of each shared interface to generate the total number of calls. Based on the total number of calls, preset time parameters, and user input, this unit generates the current state value for each shared interface through a dynamic correction mechanism.

[0077] The specific implementation of the dynamic correction mechanism includes: within each evaluation cycle, the cumulative number of calls is used to obtain the cycle call amount, user input is recorded to obtain the user input amount, the ratio of the two is calculated to obtain the input ratio, and the input ratio and the cycle call amount are stored as correction reference items. When generating the current state value, the unit first calculates the preliminary state value, and then uses the correction reference items to correct the preliminary state value to obtain the current state value.

[0078] The unit compares the current status value with the preset first threshold and second threshold to determine the status level of the shared interface. For example, it determines whether the running status is busy or idle. If it is determined to be one of these two states, it determines that the running status meets the first type of update triggering condition and generates the corresponding update instruction.

[0079] Regarding the determination of the second type of update triggering condition: This unit receives a scoring sequence provided by the state awareness unit. This unit compares the data of the data node with the usage feedback score for consistency. If the comparison result is a consistency mismatch, it is directly determined that the second type of update triggering condition is met. If the consistency comparison result is not a consistency mismatch, this unit further evaluates the matching degree of the data node according to the scoring sequence. If the matching degree is lower than the preset matching threshold, it is also determined that the second type of update triggering condition is met. When either determination is met, this unit generates the corresponding update instruction.

[0080] The instruction execution unit receives and executes the update instructions generated by the update decision unit. This unit performs different operations based on the instruction content:

[0081] When an update instruction is received due to the shared interface being identified as busy, the unit immediately performs update operations on the shared interface, such as adding resources or optimizing routes to cope with high load. When an update instruction is received due to the shared interface being identified as idle, the unit performs update operations on the shared interface during a preset low data request period, such as performing routine maintenance or version upgrades, to avoid affecting user experience.

[0082] When an update instruction is received due to a mismatch between data and scores, the unit performs a replacement operation on the corresponding data node, that is, replaces the currently failed node with a new data node of higher quality.

[0083] When an update instruction is received due to a data node matching degree being lower than a preset matching threshold, the unit first marks the data node as pending update and then performs a replacement operation on all data nodes marked as pending update within a preset update period.

[0084] Through the collaborative work of the aforementioned interface construction unit, state perception unit, update decision unit, and instruction execution unit, the multimodal transport resource data sharing system based on a blockchain network provided in this embodiment achieves intelligent and automated management and maintenance of shared interfaces and data nodes. This ensures the stable operation of data sharing services under high loads while also guaranteeing the continuous reliability of the provided data quality. It is particularly suitable for multimodal transport information interaction platforms that have high requirements for data timeliness, accuracy, and service availability.

[0085] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for sharing multimodal transport resource data based on a blockchain network, characterized in that, include: When the running status of the shared interface is detected to meet the first type of update triggering condition, the update operation corresponding to the first type of update triggering condition is executed. When the data quality of the data node in the shared interface is detected to meet the second type of update triggering condition, the update operation corresponding to the second type of update triggering condition is executed. The monitoring of the shared interface's operating status meeting the first type of update triggering conditions includes: counting the number of calls to each shared interface to generate a total call count, obtaining the user input associated with the shared interface, and determining the status level of the shared interface based on the total call count, preset time parameters, and user input. The status level is used to indicate whether the shared interface's operating status meets the first type of update triggering conditions. User input refers to the amount of data associated with the shared interface that has been actively updated, corrected, or confirmed by users. The monitoring of data node data quality meeting the second type of update triggering conditions includes: collecting usage feedback scores from callers for data obtained through data nodes and forming a score sequence; comparing the data of data nodes with the usage feedback scores for consistency; if the comparison result is a consistency mismatch, it is determined that the second type of update triggering condition is met; if the consistency comparison result is not a consistency mismatch, the matching degree of data nodes is evaluated according to the score sequence; if the matching degree is lower than a preset matching threshold, it is determined that the second type of update triggering condition is met. Among them, consistency comparison refers to inputting the data from data nodes and the user feedback scores into the comparison model. The comparison model is used to determine whether there are logical contradictions between the data record content and the user feedback, and its specific definition is as follows: Input: Data from data nodes This is represented as a set of structured features, using feedback scoring. , represented as a feature vector containing rating values ​​and text keywords; Output: Consistency results ; ； In the formula: Consistency Result: The judgment result output by the model is used to indicate whether there is a logical contradiction between the data and the feedback; For pattern detection functions: used to detect the first... A function that defines a predefined logical contradiction pattern; if the pattern is detected, it returns 1; otherwise, it returns 0. For pattern weights: corresponding to the first The severity weight of each logical contradiction pattern; Consistency threshold: A threshold used to determine whether a cumulative weighted inconsistency score constitutes a discrepancy; Total number of patterns: The total number of predefined logical contradiction patterns.

2. The method for sharing multimodal transport resource data based on a blockchain network according to claim 1, characterized in that, Determining the status level of a shared interface based on total calls, preset time parameters, and user input includes: generating a current status value for each shared interface using a dynamic correction mechanism based on total calls, preset time parameters, and user input; and comparing the current status value with preset first and second thresholds to determine the status level of the shared interface.

3. The method for sharing multimodal transport resource data based on a blockchain network according to claim 2, characterized in that, The update operations corresponding to the first type of update triggering conditions include: when the status level is determined to be busy, immediately perform an update operation on the shared interface; and when the status level is determined to be idle, perform an update operation on the shared interface during a preset low data request period.

4. The method for sharing multimodal transport resource data based on a blockchain network according to claim 2, characterized in that, The current state value is generated through a dynamic correction mechanism, which includes: accumulating the number of calls within the evaluation period to obtain the periodic call volume, recording user input behavior to obtain the user input volume, calculating the ratio of user input volume to periodic call volume to obtain the input ratio, storing the input ratio and periodic call volume as correction reference items, calculating a preliminary state value based on the total call volume, preset time parameters, and the input ratio, and correcting the preliminary state value using the correction reference items to generate the current state value.

5. A method for sharing multimodal transport resource data based on a blockchain network according to claim 4, characterized in that, The update operations corresponding to the second type of update triggering conditions include: when the consistency comparison result is a consistency mismatch, performing a replacement operation for the data node; and when the matching degree is lower than a preset matching threshold, marking the data node as pending update and performing a replacement operation for the data node marked as pending update within a preset update period.

6. The method for sharing multimodal transport resource data based on a blockchain network according to claim 1, characterized in that, The method also includes, before performing monitoring: acquiring multimodal transport resource data and classifying it according to the category to which the multimodal transport resource data belongs, and building a shared interface for each category, wherein each shared interface contains at least one data node.

7. A multimodal transport resource data sharing system based on a blockchain network, characterized in that, A method for sharing multimodal transport resource data based on a blockchain network as described in any one of claims 1-6, comprising: The state-aware unit monitors the call behavior and user input associated with the shared interface, and also monitors the usage feedback scores submitted by the caller based on the data obtained through the data node. The update decision unit responds to the monitoring results of the status perception unit, and determines whether the running status of the shared interface meets the first type of update triggering conditions based on the calling behavior and user input, combined with the dynamic correction mechanism. Based on the user feedback score, it determines whether the data quality of the data node meets the second type of update triggering conditions. Based on the determination results of the first type of update triggering conditions or the second type of update triggering conditions, it generates the corresponding update instructions. The instruction execution unit receives and executes the update instructions generated by the update decision unit to perform update or replacement operations on the shared interface or data node. The dynamic correction mechanism is configured to generate correction reference items based on the call volume and user input volume in the historical evaluation period, and feeds the correction reference items back to the update decision unit to correct the determination of the running status of the shared interface.

8. A multimodal transport resource data sharing system based on a blockchain network according to claim 7, characterized in that, The update decision unit compares the current state value generated based on the call behavior and user input with the preset first threshold and second threshold to determine whether the running state of the shared interface is busy or idle, and uses the busy or idle state as the first type of update trigger condition.

9. A multimodal transport resource data sharing system based on a blockchain network according to claim 8, characterized in that, The update decision unit compares the data of the data nodes with the usage feedback scores for consistency, and uses the result of consistency mismatch as the second type of update trigger condition. In the case of no consistency mismatch, it evaluates the matching degree of the data nodes and uses the result of matching degree below the preset matching threshold as the second type of update trigger condition.

Images