A real-time monitoring method and system for after-sales service quality based on blockchain

Abstract

The present invention provides a blockchain-based real-time monitoring method and system for after-sales service quality, relating to the technical field of after-sales service monitoring. The method includes the following steps: obtaining a node identifier and an upload requirement corresponding to the node identifier; controlling or prompting a service terminal to collect data for unstructured data and specified metadata according to the upload requirement corresponding to the node identifier based on the corresponding node identifier; generating a corresponding hash value as a unique identifier based on the unstructured data; combining the specified metadata and the corresponding unstructured data hash value as associated information into a structured data packet, and submitting it to a preset distributed ledger; monitoring updates to the service record status in real time, and using a smart contract deployed on the distributed ledger to verify the unstructured data hash value record associated with the current mandatory data association node. The method of the present invention significantly improves the credibility and utilization value of the unstructured information generated during the service process.

Description

Technical Field

[0001] The present invention relates to the field of after-sales service monitoring technology, and in particular to a blockchain-based after-sales service quality real-time monitoring method and system. Background Art

[0002] Providing after-sales service to users is an integral part of the product lifecycle. When a user experiences a malfunction in a purchased product during use, they typically initiate a repair request through the company's service channels. Upon receiving a user's repair request, the company's internal service management system intelligently assigns the service task to qualified service personnel based on a variety of factors, including the product type, the user's geographic location, and the skills and expertise of available service personnel. Upon receiving the assigned task, the service personnel proactively contact the user to negotiate and determine the specific time and location for the on-site service visit. They then travel to the user's location to provide on-site service, or, if conditions permit, provide service through remote guidance or other means.

[0003] During the service process, service personnel need to conduct comprehensive inspections of products experiencing anomalies, diagnose the cause of the malfunction, and perform operations such as troubleshooting, repairing, or replacing damaged parts. To ensure transparency and traceability of the service process, service personnel also need to record key information from the service process in detail. This information typically includes, but is not limited to, the specific time the service began, the time the service ended, a detailed description of the product malfunction, the treatment methods and steps taken, the part numbers used during the repair process, the number of parts used, etc. Upon completion of the service work, service personnel need to compile and submit a complete service report based on these records. After receiving the service report, users are typically required to confirm the service results and are invited to evaluate the entire service process and the service personnel's performance, including service attitude and problem-solving status.

[0004] To further enhance the authenticity of after-sales service data, ensure its immutability and traceability, and improve the objectivity and fairness of service quality evaluations, some companies have begun actively exploring and introducing distributed ledger technology (DLT). Under this new technical framework, a series of key data in the after-sales service process, such as details of user-initiated repair requests, service task dispatch information, actual service start and end times, service reports submitted by service personnel, user confirmation status of service results, and user-submitted service reviews, are collected through a specific data collection mechanism and recorded in a structured format on a distributed ledger. The core characteristics of a distributed ledger lie in its data structure and consensus mechanism design. Once data is successfully recorded on the ledger, any subsequent tampering becomes extremely difficult, thereby greatly enhancing the credibility of this critical service data.

[0005] Building on this foundation, enterprises further utilize smart contracts to automate business logic based on this trusted on-chain data. For example, a pre-set smart contract can automatically and accurately calculate service fees or evaluate and calculate service personnel's performance scores based on structured data recorded on the distributed ledger, such as the service type, actual service duration, and parts used during the repair process. If the user completes the service confirmation and evaluation within a pre-set timeframe, the smart contract can further trigger corresponding reward (for the service personnel) or penalty logic to incentivize high-quality service and curb inappropriate behavior. In the event of a service dispute, the immutable nature of key service process data recorded on the distributed ledger provides objective and reliable evidence for tracing the truth and facilitating fair arbitration.

[0006] However, in real-world after-sales service scenarios, some crucial information often exists in unstructured or semi-structured form, making it difficult to collect through standardized processes and directly adapt and store in the structured data fields pre-defined by distributed ledgers. For example, when service personnel address complex or rare faults, they may need to engage in lengthy and detailed communication with the user to explain the root cause, analyze various solutions, and obtain user consent. Unexpected emergencies may also arise during the service process, requiring the service personnel to temporarily adjust their solutions or implement emergency measures. When users evaluate a service, in addition to selecting a preset rating, they often provide extensive text descriptions of the service, the service personnel's communication attitude, and whether the issue was fully resolved. This unstructured or semi-structured information, such as service notes taken by service personnel on-site, detailed text entered in user reviews, photos taken during the service to document the on-site situation or fault point, and audio recordings to capture communication content or on-site sounds, is extremely valuable for a comprehensive and in-depth understanding of the entire service process, accurately assessing service quality, analyzing the underlying causes of complex issues, and continuously improving service processes and enhancing service personnel's skills.

[0007] Due to its diverse content formats (text, images, audio, etc.), complex structure, and potentially large volume, this unstructured or semi-structured information is difficult to store directly in the limited storage units of distributed ledgers designed primarily for structured data. It is also difficult for smart contracts, which rely on structured data for logical reasoning, to directly parse and utilize. A common approach is to store this unstructured information in an off-chain storage system (such as a distributed file system), and then record only a unique identifier pointing to the off-chain storage location, such as a hash of the data, in the on-chain distributed ledger. This approach can ensure the integrity of the information (i.e., if the off-chain data is modified, its hash value will change, causing the on-chain hash value to no longer match, thus enabling tampering detection). However, it does not fundamentally address the issue of ensuring the authenticity of this off-chain unstructured or semi-structured information. When submitting this unstructured information, service personnel or users may still be influenced by subjective factors, potentially leading to selective uploads and exaggeration of facts. For example, to prove their correctness, service personnel may selectively upload only photos or recordings that are favorable to them. Users expressing dissatisfaction may exaggerate service personnel errors in written reviews. Due to the lack of a rigorous, trusted collection and verification process during the generation and collection of this information, its original authenticity is questionable. Consequently, smart contracts cannot fully rely on the on-chain hash values ​​of this information for automated business processing (for example, it is impossible to determine whether a photo's content meets requirements based on its hash value). Service quality monitoring cannot fully trust and utilize this critical detail for comprehensive and in-depth analysis. In particular, in the event of service disputes, the authenticity of unstructured evidence stored off-chain often requires additional verification and corroboration through other independent channels, which undoubtedly increases the complexity and difficulty of dispute resolution.

[0008] Therefore, under the current after-sales service quality monitoring system that adopts distributed ledger and smart contract architecture, how to design an effective mechanism that can reliably capture, securely store, and reliably associate with on-chain structured service records, and ultimately effectively utilize the unstructured or semi-structured key information generated during these services, has become a key challenge to improving after-sales service quality monitoring capabilities, enhancing data credibility, and optimizing dispute resolution processes. Summary of the Invention

[0009] The purpose of this invention is to provide a blockchain-based real-time monitoring method and system for after-sales service quality. By forcibly associating unstructured data and its metadata at key nodes in the after-sales service process and using distributed ledgers and smart contracts for on-chain verification, the credibility and utilization value of unstructured information generated during the service process (such as photos, recordings, detailed notes, etc.) are significantly improved.

[0010] In a first aspect, the present invention provides a method for real-time monitoring of after-sales service quality based on blockchain, comprising the following steps:

[0011] Obtain the node identifier of the mandatory data association node preset in the service process, as well as the upload requirements corresponding to the node identifier, the upload requirements including the specified unstructured data type and upload quantity;

[0012] When the service terminal enters the mandatory data association node, based on the corresponding node identifier, the service terminal is controlled or prompted to collect data for unstructured data and specified metadata in accordance with the upload requirements corresponding to the node identifier; the specified metadata includes the ID identifier of the current service record status, the collection timestamp, the geographic location, the terminal device identifier, and the operator identifier;

[0013] Upload the unstructured data and specified metadata collected by the service terminal to a pre-established off-chain distributed file storage system, and generate a corresponding hash value as a unique identifier based on the unstructured data;

[0014] Combine the specified metadata and the corresponding unstructured data hash value as associated information into a structured data packet, and submit it as an on-chain transaction data to the preset distributed ledger;

[0015] Monitor the update of service record status in real time, and when the service record status attempts to advance from the current mandatory data association node to the next mandatory data association node, use the smart contract deployed on the distributed ledger to query the corresponding on-chain data through the ID identifier of the current service record status, and verify the unstructured data hash value record associated with the current mandatory data association node; if the verification passes, the service status is allowed to advance; if the verification fails, the service status is prevented from advancing, and the service record status is marked as an abnormal state.

[0016] The blockchain-based real-time after-sales service quality monitoring method provided by the present invention establishes a mandatory association mechanism in a product after-sales service quality monitoring system based on distributed ledgers and smart contracts to ensure that unstructured key information during the service process (such as on-site photos, recordings, etc.) can be reliably collected, tamper-proofed, and linked to the structured service records on the chain. Its existence can also be verified at the smart contract level, thereby improving the credibility and automated processing capabilities of this information when used as a basis for service quality assessment and dispute tracing.

[0017] In a second aspect, the present invention provides a blockchain-based real-time monitoring system for after-sales service quality, comprising:

[0018] An acquisition module is used to obtain the node identifier of the mandatory data association node preset in the service process, and the upload requirement corresponding to the node identifier, the upload requirement including the specified unstructured data type and upload quantity;

[0019] The collection module is used to control or prompt the service terminal to collect unstructured data and specified metadata according to the upload requirements corresponding to the node identifier when the service terminal enters the mandatory data association node; the specified metadata includes the ID identifier of the current service record status, the collection timestamp, the geographic location, the terminal device identifier, and the operator identifier;

[0020] A generation module is used to upload the unstructured data and specified metadata collected by the service terminal to a pre-established off-chain distributed file storage system, and generate a corresponding hash value as a unique identifier based on the unstructured data;

[0021] The transaction module is used to combine the specified metadata and the corresponding unstructured data hash value as associated information into a structured data packet, and submit it as an on-chain transaction data to the preset distributed ledger;

[0022] The verification module is used to monitor the update of the service record status in real time. When the service record status attempts to advance from the current mandatory data association node to the next mandatory data association node, it uses the smart contract deployed on the distributed ledger to query the corresponding on-chain data through the ID identifier of the current service record status and verify the unstructured data hash value record associated with the current mandatory data association node; if the verification passes, the service status is allowed to advance; if the verification fails, the service status is prevented from advancing and the service record status is marked as an abnormal state.

[0023] As can be seen from the above, the blockchain-based real-time after-sales service quality monitoring method provided by this invention transforms unstructured data from "optional and questionable" to "process-required, trustworthy, and verifiable on-chain" critical service evidence by mandatory collection and recording of metadata at key process points, collaborative storage and association between off-chain and on-chain data, and mandatory verification using smart contracts. This significantly improves the efficiency and reliability of service quality monitoring and dispute resolution. In this way, the collection of unstructured data is tightly coupled with the advancement of the service process, and the tamper-proof and automated verification characteristics of distributed ledgers and smart contracts are utilized to ensure the trustworthy association and on-chain traceability of unstructured data.

[0024] Other features and advantages of the present invention will be described in the following description, and in part will become apparent from the description, or will be understood by practicing the embodiments of the present invention. The purposes and other advantages of the present invention can be realized and obtained by the structures particularly pointed out in the written description and the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 A flowchart of a blockchain-based real-time monitoring method for after-sales service quality provided by an embodiment of the present invention.

[0026] Figure 2 A schematic diagram of the structure of a blockchain-based real-time monitoring system for after-sales service quality provided by an embodiment of the present invention.

[0027] Description of labels:

[0028] 100, acquisition module; 200, collection module; 300, generation module; 400, transaction module; 500, verification module. DETAILED DESCRIPTION

[0029] The technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of the embodiments. The components of the embodiments of the present invention generally described and shown in the drawings herein can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the claimed invention, but merely represents selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of the present invention.

[0030] It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings. At the same time, in the description of the present invention, the terms "first", "second", etc. are used only to distinguish the description and should not be understood as indicating or implying relative importance.

[0031] Reference Attachment Figure 1 The present invention provides a real-time monitoring method for after-sales service quality based on blockchain, comprising the following steps:

[0032] Obtain the node identifier of the mandatory data association node preset in the service process, as well as the upload requirements corresponding to the node identifier, the upload requirements including the specified unstructured data type and upload quantity;

[0033] When the service terminal enters the mandatory data association node, based on the corresponding node identifier, the service terminal is controlled or prompted to collect data for unstructured data and specified metadata in accordance with the upload requirements corresponding to the node identifier; the specified metadata includes the ID identifier of the current service record status, the collection timestamp, the geographic location, the terminal device identifier, and the operator identifier;

[0034] Upload the unstructured data and specified metadata collected by the service terminal to a pre-established off-chain distributed file storage system, and generate a corresponding hash value based on the unstructured data as a unique identifier (if someone attempts to modify the unstructured data stored off-chain, its hash value will change, causing it to no longer match the hash value recorded on the chain, thus allowing tampering to be detected);

[0035] The specified metadata and the corresponding unstructured data hash value are combined as associated information into a structured data package, and submitted as an on-chain transaction data to the preset distributed ledger. Once the distributed ledger confirms and records the transaction, an unalterable on-chain record is formed.

[0036] Monitor the update of service record status in real time, and when the service record status attempts to advance from the current mandatory data association node to the next mandatory data association node, use the smart contract deployed on the distributed ledger to query the corresponding on-chain data through the ID identifier of the current service record status, and verify the unstructured data hash value record associated with the current mandatory data association node; if the verification passes, the service status is allowed to advance; if the verification fails, the service status is prevented from advancing, and the service record status is marked as an abnormal state.

[0037] This method obtains the node identifier of the mandatory data association node preset in the service process, and the upload requirements corresponding to the node identifier, and the upload requirements include the specified unstructured data type and upload quantity. This step determines which links in the service process need to collect data, as well as the data type and quantity to be collected, thereby ensuring that data collection is carried out at the key links of the service process. Furthermore, when the service terminal enters the mandatory data association node, according to the corresponding node identifier, the service terminal is controlled or prompted to collect data for unstructured data and specified metadata in accordance with the upload requirements corresponding to the node identifier. The specified metadata includes the ID identifier of the current service record status, the collection timestamp, the geographic location, the terminal device identifier, and the operator identifier. This step obtains the unstructured evidence and its associated contextual information in the service process, providing a data basis for subsequent verification and tracing. Thus, the technical problem of trusted association of unstructured data is solved.

[0038] Specifically, this method addresses the technical challenges of trusted association and verification of unstructured data in the after-sales service process by forcibly collecting unstructured data and its associated metadata at specific nodes in the after-sales service process and recording the hash values ​​of this data on a distributed ledger. First, the method obtains the identifiers of the pre-set mandatory data association nodes in the service process and the corresponding upload requirements. This step sets the trigger conditions and content specifications for data collection. Next, when a service terminal arrives at one of these pre-set nodes, the method controls or prompts the terminal to collect unstructured data and specified metadata based on the node identifiers. The metadata includes the service record ID, collection time, geographic location, terminal device identifier, and operator identifier. This information provides the context for the generation of the unstructured data and associates it with the specific service record. The collected unstructured data and metadata are then uploaded to an off-chain distributed file storage system. The method calculates a hash value based on the unstructured data and uses the hash value as the data identifier. Off-chain storage addresses the problem of large amounts of unstructured data being unsuitable for direct on-chain storage, as the hash value provides proof of data integrity. Subsequently, the method combines the hash values ​​of the metadata and unstructured data into a structured data packet, which is submitted as an on-chain transaction to the pre-set distributed ledger. The characteristics of the distributed ledger ensure that these associated information and hash values ​​cannot be tampered with once recorded. This solves the technical problem of trusted association of unstructured data. Finally, the method monitors the status of the service record in real time. When the service record attempts to advance from the current mandatory data association node to the next mandatory data association node, the smart contract deployed on the distributed ledger is used to query the corresponding on-chain data using the ID identifier of the current service record status, and verify the unstructured data hash value record associated with the current mandatory data association node. If the verification passes, the service status is allowed to advance. If the verification fails, the service status is prevented from advancing, and the service record status is marked as an abnormal state. This step uses the tamper-proof hash value on the chain to verify the integrity of the off-chain data, and combines the verification results with the service process control to ensure that the service can only continue when the data is complete and the association is correct. This realizes automated control and anomaly detection of the service process based on trusted data, thereby solving the technical problem of trusted verification of unstructured data.

[0039] In some specific implementations, suppose a service worker is diagnosing a washing machine fault and the system requires them to upload a photo of the fault location. The service worker uses the service terminal application to take a photo of the damaged motor inside the washing machine. This photo file is unstructured data. The terminal application automatically records the specific time of the photo, the service worker's home address (geographic location), the service worker's phone model (terminal device identifier), and the service worker's employee ID (operator identifier). These are collected metadata.

[0040] Following these steps, the photo file and the collected metadata are uploaded to an off-chain distributed file storage system, such as a storage cluster built on IPFS (InterPlanetary File System) or Ceph. At the same time, the system calculates a hash value for the photo file, such as using the SHA-256 algorithm to generate a unique string of characters.

[0041] This process securely stores the photo itself (unstructured data) and the contextual information surrounding its capture (collection metadata), generating a unique hash value representing the photo's content. This hash value, along with the photo's association with the current service record and the "troubleshooting" node, is then recorded on the distributed ledger. If anyone attempts to modify the content of the off-chain photo, the hash value will change and no longer match the on-chain hash value, making the tampering detectable. Collected metadata can help determine whether the photo was taken at the time, location, and by the service provider, increasing the credibility of the photo as evidence. Off-chain distributed file storage systems can be implemented using a variety of technologies, including distributed storage solutions like IPFS, Ceph, and MinIO, or distributed storage architectures built on cloud storage services.

[0042] In other specific embodiments, assume a home appliance repair service with a service record ID of "SR789." The service process proceeds to the "Fault Diagnosis" node. The service personnel uses a terminal application to take a photo of the faulty component. According to this method, the terminal application calculates a hash value of the photo, such as "HashXYZ." At the same time, the terminal records the time the photo was taken (e.g., "2023-10-27 10:30:00"), the geographic location (e.g., "N31.2E121.5"), the terminal device identifier (e.g., "DeviceA"), and the service personnel identifier (e.g., "Tech001").

[0043] The purpose of this step is to combine this information: "SR789" (service record ID), "fault diagnosis" (current service node identifier), "HashXYZ" (unstructured data hash value), "2023-10-2710:30:00" (collection timestamp), "photo" (data type), and "Tech001" (operator identifier) ​​into a structured data packet, forming an on-chain transaction data and submitting it to the distributed ledger.

[0044] Once this transaction is confirmed and recorded by the distributed ledger, it forms an unalterable on-chain record, proving that at a specific time, at a specific place, and by a specific service personnel, a photo was associated with the "fault diagnosis" node for the service record "SR789", and its content is uniquely identified by "HashXYZ".

[0045] The specific implementation method of submitting this associated information to the distributed ledger can be: the service terminal application directly submits the transaction through the client interface of the distributed ledger; or the service terminal sends the data to the enterprise back-end service, which constructs and submits the transaction to the distributed ledger on its behalf.

[0046] Through this process, even if the original photo is stored off-chain, the hash value and associated metadata recorded on-chain provide immutable proof of the photo's existence, relevance, and partial authenticity. Subsequent smart contracts can query the on-chain record to confirm whether the "Fault Diagnosis" node in the service record "SR789" has been associated with the photo hash, and use this information to control the process. In the event of a dispute, the hash value and metadata recorded on-chain can be used to retrieve the photo from the off-chain storage system, and the metadata can be used to assist in verifying the photo's authenticity.

[0047] In some embodiments, when a service terminal enters a mandatory data association node, the service terminal is controlled or prompted to collect data for unstructured data and specified metadata according to the upload requirements corresponding to the node identifier according to the corresponding node identifier:

[0048] A1. When a service terminal enters a mandatory data association node, it scans the QR code corresponding to the node identifier and interprets it to obtain a data collection instruction. The data collection instruction includes the unstructured data type, quantity requirement, and metadata type.

[0049] A2. Determine the type of unstructured data according to the data collection instruction. If it is an image type, execute step A3. If it is an audio type, execute step A4.

[0050] A3. Activate the service terminal's camera, force the flash on, and prompt the operator to adjust the shooting angle. When the image clarity exceeds a preset threshold, capture a specified number of images and record the capture timestamp, geographic location, terminal device ID, and operator ID as metadata.

[0051] A4. Activate the service terminal's microphone, force noise reduction mode, and prompt the operator to record audio for a specified duration. The recording timestamp, geographic location, terminal device ID, and operator ID are also recorded as metadata.

[0052] Specifically, mandatory data association nodes in the after-sales service process, such as the repair completion node, are pre-set to require the collection of image evidence from the repair site. When a service terminal, such as a mobile device used by a maintenance worker, enters this node, it scans the QR code associated with the node to obtain data collection instructions. This instruction specifies the type and quantity of images to be collected (e.g., three), as well as the metadata to be recorded (service record ID, timestamp, location, device ID, and operator ID). Based on the instruction, the service terminal determines the data type as image and immediately launches the camera application, forcing the flash to activate to improve lighting conditions. The system prompts the operator to adjust the shooting angle and monitors image clarity in real time. Recording is permitted only when image clarity reaches a preset threshold (e.g., the image gradient variance calculated using the Laplace operator is greater than a certain value). The system controls the capture of the specified number of images and, with each successful capture, automatically records the current system time as a timestamp, obtains the geographic location through GPS or network positioning, and reads the unique identifier of the terminal device and the currently logged-in operator ID. This metadata is associated with the captured image. If the command requires audio capture, such as for recording communications with the user, the system activates the microphone application, forcibly turns on noise reduction, and prompts the operator to begin recording, while also setting a recording duration limit (e.g., 60 seconds). During or after recording, the system automatically records the start or end timestamp, geographic location, terminal device ID, and operator ID as metadata. This controlled collection process ensures that the unstructured data collected at key nodes meets preset requirements and is associated with the necessary contextual information, resolving issues such as uncontrollable data collection processes or substandard collection results.

[0053] In some embodiments, the steps of uploading the unstructured data and specified metadata collected by the service terminal to a pre-established off-chain distributed file storage system and generating a corresponding hash value as a unique identifier based on the unstructured data include:

[0054] Segment the unstructured data collected by the service terminal to generate multiple data blocks; wherein the data block strategy includes fixed-size blocks, content-based blocks, or data type-based blocks;

[0055] Upload multiple data blocks in parallel to the off-chain distributed file storage system. The off-chain distributed file storage system is the IPFS system. The IPFS system uses content addressing to store data blocks and generates a unique content identifier (CID) for each data block.

[0056] Based on the multiple content identifiers (CIDs) corresponding to the unstructured data, a Merkle tree is constructed. The leaf nodes of the Merkle tree are the content identifiers (CIDs), the intermediate nodes are the hash values ​​of the leaf node hash values ​​at each level, and the root node is the final Merkle root hash value.

[0057] The Merkle root hash value is used as the unique identifier of unstructured data for subsequent on-chain data verification.

[0058] This method first segments the collected unstructured data into multiple data chunks. The segmentation strategy can be fixed-size, content-based, or data type-based, depending on the data's characteristics. Data segmentation breaks large data chunks into smaller chunks for easier processing and distributed storage. These chunks are then uploaded in parallel to an off-chain distributed file storage system, specifically the IPFS system. The IPFS system uses content-addressing to generate unique identifiers (CIDs) based on the data content itself, ensuring that data with identical content has the same CID and supporting distributed data storage and retrieval. Each data chunk is assigned a unique CID after upload. A Merkle tree is then constructed using the CIDs corresponding to these chunks. A Merkle tree is a hash tree whose leaf nodes are the CIDs of the data chunks, and non-leaf nodes are the combined hashes of their child nodes' hash values. Ultimately, a unique Merkle root hash is generated. This Merkle root hash serves as the unique identifier for the entire unstructured data. This root hash represents the integrity of all data chunks. If any data block is modified or lost, its CID will change, causing the hash value of the corresponding path in the Merkle tree to change, and ultimately causing the Merkle root hash value to change.

[0059] Specifically, this technical solution addresses the problem of processing unstructured data and generating unique identifiers. When the amount of unstructured data is large, directly calculating the overall hash value is inefficient and difficult to manage in distributed storage. Unstructured data collected by service terminals is segmented into multiple data blocks. Data block partitioning strategies can be implemented using fixed-size, content-based, or data type-based blocks. This breaks large files into smaller blocks that can be processed in parallel. Multiple data blocks are uploaded in parallel to an off-chain distributed file storage system, the Interconnected File System (IPFS). The IPFS system uses content-addressed storage and generates a unique content identifier (CID) for each block. Parallel upload improves efficiency, while IPFS's content-addressed storage ensures unique data identification and distributed storage. A Merkle tree is constructed based on the multiple content identifiers (CIDs) corresponding to the unstructured data. The leaf nodes of the Merkle tree are the individual CIDs, the intermediate nodes are the hash values ​​of the leaf nodes, and the root node is the final Merkle root hash value. The Merkle tree structure aggregates the CIDs of all data blocks into a single root hash value. The Merkle root hash value is used as a unique identifier for unstructured data and is subsequently used for on-chain data verification. By simply storing and verifying this compact Merkle root hash value on-chain, the integrity of the entire unstructured data stored off-chain can be efficiently and reliably verified, thus solving the challenge of integrity verification for large-scale unstructured data.

[0060] In some embodiments, the steps of combining the specified metadata and the corresponding unstructured data hash value as associated information into a structured data packet and submitting the data packet as an on-chain transaction data to a preset distributed ledger include:

[0061] The transaction priority score is calculated based on the importance of the service record of the transaction to be submitted, the criticality of the data-related node, and the historical transaction congestion;

[0062] The Gas fee of the structured data packet is determined based on the transaction priority score. If the transaction priority score is higher than the preset first threshold, a high Gas fee is set; if the transaction priority score is lower than the preset second threshold, a low Gas fee is set, and the transaction is submitted during the network idle period.

[0063] Combine the specified metadata, the corresponding unstructured data hash value, and the gas fee set in the previous step into a structured data packet, sign the structured data packet, and generate on-chain transaction data;

[0064] Submit on-chain transaction data to the preset distributed ledger, and track the transaction confirmation progress in real time by monitoring the transaction pool status. If the transaction is not confirmed for a long time, the gas fee will be dynamically adjusted according to the current network congestion, and the transaction will be resubmitted until the transaction is confirmed and recorded by the distributed ledger.

[0065] Specifically, this solution optimizes the on-chain transaction submission process, solving the problem of dynamically adjusting transaction gas fees based on the urgency of service records and blockchain network congestion. This approach ensures the timely submission of critical service records while reducing overall transaction costs and improving system efficiency and availability. The solution first calculates a transaction priority score based on the priority of the service record to be submitted, the priority of the node associated with the data, and the network status of historical transactions. This scoring mechanism takes into account business needs and network status, prioritizing transactions based on priority. Furthermore, the calculated transaction priority score determines the transaction gas fee. High-priority transactions receive higher gas fees, increasing their probability of being packaged and confirmed, shortening transaction confirmation time. Low-priority transactions receive lower gas fees and are submitted during periods of low network load to reduce transaction fees. This leverages the blockchain network's gas mechanism, influencing transaction confirmation speed by paying different fees. Then, the specified metadata, unstructured data hash, and the determined gas fee are combined and signed to generate on-chain transaction data. This is the blockchain transaction construction process. Finally, the generated on-chain transaction data is submitted to the distributed ledger. The solution further incorporates mechanisms to monitor transaction pool status and track transaction confirmation progress. If a transaction confirmation takes longer than a preset time, the system adjusts the gas fee based on the current network load and resubmits the transaction. This adjustment and resubmission mechanism allows the system to adapt to fluctuations in network load and adjust transaction parameters until the transaction is confirmed and recorded on the distributed ledger. Through these steps, transaction gas fees are dynamically adjusted based on the urgency of the service record and blockchain network congestion, thereby ensuring that critical service records are uploaded to the blockchain in a timely manner, reducing overall transaction costs and improving system efficiency and availability.

[0066] In some specific implementations, for example, when a critical repair service involving product safety is completed and requires on-chain uploading of on-site photos and a repair report hash, the service record is marked as high-importance, and the corresponding mandatory data-associated node is also marked as critical. Based on this information and the current congestion level of the blockchain network's transaction pool, the system calculates a high transaction priority score. Based on this score, a higher gas fee is assigned to this transaction. Subsequently, metadata such as the service record ID, photo hash, and report hash are combined with the determined high gas fee to generate and sign the on-chain transaction data, which is then submitted to the distributed ledger. The system continuously monitors the transaction's status in the transaction pool. If a transaction is found to be delayed in confirmation for an extended period, the system dynamically calculates and adjusts the gas fee based on current real-time network congestion. For example, the gas price may be increased by a certain percentage and the transaction resubmitted. This ensures that the on-chain recording of critical service data is completed promptly, allowing the service process to proceed smoothly to the next stage. Furthermore, the priority score and dynamic adjustment mechanism avoid unnecessary gas expenditure and optimize resource utilization.

[0067] In some embodiments, the steps of combining the specified metadata and the corresponding unstructured data hash value as associated information into a structured data packet and submitting the data packet as an on-chain transaction data to a preset distributed ledger include:

[0068] Obtain the preset cross-chain interoperability protocol, which defines the data transmission standards, verification mechanism, and gas fee settlement method of the source and target chains;

[0069] Based on the service record ID, query the specified metadata and the corresponding unstructured data hash value on the source chain, and encapsulate the specified metadata and the corresponding hash value into a cross-chain transaction request in accordance with the data format specified by the cross-chain interoperability protocol;

[0070] Send the cross-chain transaction request to the preset cross-chain bridge node, and verify the legitimacy of the cross-chain transaction request through the cross-chain bridge node, including signature verification, data format verification, and gas fee verification;

[0071] If the verification is successful, the cross-chain bridge node forwards the cross-chain transaction request to the target chain. The smart contract on the target chain parses the cross-chain transaction request according to the cross-chain interoperability protocol, and writes the specified metadata and corresponding hash value into the target chain to complete the cross-chain data synchronization.

[0072] The cross-chain interoperability protocol, which can be obtained through configuration or registration, defines the rules for data exchange and validation between different distributed ledgers. Querying source chain data based on a service record ID can be accomplished by invoking a smart contract interface deployed on the source chain. This interface retrieves metadata and hash values ​​stored on-chain based on the provided service record ID. The queried data is encapsulated into a cross-chain transaction request, adhering to the protocol's defined data structure and encoding to ensure correct parsing by the target chain. Upon receiving the request, the cross-chain bridge node performs a series of validation logic, including checking the validity of the requester's digital signature, whether the data format carried in the request complies with the protocol specifications, and whether the required gas fees have been correctly paid or reserved. Once verification is successful, the bridge node is responsible for securely and reliably transmitting the request to the target chain network. The smart contract on the target chain is designed to receive and process requests from the cross-chain bridge node. It parses the request content according to the cross-chain interoperability protocol, extracts the service record ID, metadata, and hash value, and records this information as a new transaction or state update in the target chain's state database.

[0073] Specifically, this technical solution addresses the cross-chain sharing and consistency of critical after-sales service data when multiple heterogeneous distributed ledgers exist. First, by acquiring and adhering to a unified cross-chain interoperability protocol, a foundational standard for data communication between different chains is established. When specific service record data on a source chain needs to be synchronized or shared with a target chain, the system uses the service record's unique ID to precisely locate and extract the hash value of the metadata and unstructured data associated with the record on the source chain. This data is critical to the service process, and the hash value represents the integrity of the off-chain unstructured data. This extracted data is then encapsulated according to the specific format specified by the cross-chain interoperability protocol, forming a standard cross-chain transaction request packet. This request packet contains the data to be transmitted, as well as necessary routing and verification information. This cross-chain transaction request is then sent to one or a set of pre-defined cross-chain bridge nodes. These bridge nodes act as trust intermediaries connecting the source and target chains. Upon receiving the request, they rigorously check its validity according to the protocol to ensure its authenticity and integrity, preventing malicious or erroneous data transmission. After verification, the bridge node forwards the request to the target chain network. On the target chain, a pre-deployed smart contract receives and processes the request from the bridge node. This smart contract parses the request content according to the cross-chain interoperability protocol, extracts the service record ID, metadata, and hash value, and writes this information to the target chain's ledger as a new data record or an update to an existing record. This securely and reliably synchronizes critical service data from the source chain to the target chain, achieving cross-chain data sharing and consistency. This allows applications or participants on different chains to access and utilize this data, improving data interoperability and usability across the entire after-sales service quality monitoring system.

[0074] In some specific implementations, assume that the source chain is a consortium chain based on Ethereum, and the target chain is a permissioned chain based on Hyperledger Fabric. The cross-chain interoperability protocol can employ a message relay and verification mechanism, for example, defining a standard data packet structure containing a service record ID, metadata, a hash value, a source chain identifier, a timestamp, and the signature of the source chain's smart contract. A cross-chain bridge node can be a cluster of servers running a specific relay service that listens for cross-chain events issued by a specific smart contract on the source chain. When a smart contract on the source chain records new service data and triggers a cross-chain event, the relay service captures the event, retrieves the detailed data from the source chain, and constructs a cross-chain transaction request in accordance with the protocol format. This request is then sent to the bridge node. Upon receiving the request, the bridge node first verifies the validity of the signature of the source chain's smart contract to confirm that the data originates from a trusted contract on the source chain. It then checks whether the data packet format complies with the protocol. Once verified, the bridge node forwards the request to a specific smart contract on the target chain network. After receiving the request, the smart contract on the target chain parses the data packet, extracts the service record ID, metadata, and hash value, and writes it as a new record to the Fabric ledger's state database, for example, with the service record ID as the key and the metadata and hash value as the value. In this way, key after-sales service data on the source chain is synchronized to the target chain, allowing applications on the target chain to access this data for subsequent processing or analysis, such as cross-regional service data aggregation or auditing.

[0075] In certain embodiments, the steps of monitoring updates to the service record status in real time, and when the service record status attempts to advance from the current mandatory data association node to the next mandatory data association node, querying the corresponding on-chain data using the ID identifier of the current service record status using a smart contract deployed on a distributed ledger, and verifying the unstructured data hash value record associated with the current mandatory data association node include:

[0076] B1. When the service record status attempts to advance from the current mandatory data-associated node to the next node, the smart contract queries the on-chain data associated with the ID identifier of the current service record status. If the query result is empty, it executes step B2; if the query result is not empty, it executes step B3;

[0077] B2. The smart contract suspends the progress of the service recording status and sends a data re-recording instruction to the service terminal. The data re-recording instruction includes the node identifier of the current mandatory data association node, the type of unstructured data, the required quantity, and the metadata type. At the same time, a timer is started to record the re-recording waiting time;

[0078] B3. The smart contract extracts the hash value record of the unstructured data associated with the current mandatory data association node from the on-chain data, and retrieves the hash value corresponding to the ID identifier of the current service record status from the off-chain distributed file storage system. If the hash value of the off-chain record is consistent with the hash value of the on-chain record, step B31 is executed; if the hash value of the off-chain record is inconsistent with the hash value of the on-chain record, step B32 is executed.

[0079] B31. The smart contract allows the service status to be advanced to the next node, and records the advancement time and operator ID;

[0080] B32. The smart contract blocks the service from progressing and marks the service record status as abnormal. It also generates an exception report containing the service record ID, abnormal node ID, exception type (hash value mismatch), occurrence time, and operator ID. The exception report is then sent to the pre-set administrator account.

[0081] B4. The smart contract monitors the re-recording waiting time. If the re-recording waiting time exceeds the preset threshold, step B32 is executed. If the data re-uploaded by the service terminal is received within the preset threshold, step B3 is executed.

[0082] Specifically, this technical solution triggers a data integrity verification process via a smart contract deployed on the distributed ledger when a service record attempts to advance from the current mandatory data association node to the next node, addressing potential tampering or loss of critical unstructured data during the service process. The smart contract first queries the distributed ledger based on the service record's unique ID to verify whether the current mandatory data association node has recorded the required information, including the hash value of the unstructured data. If no corresponding record is found on the chain, indicating a potential problem with the data upload process at that node, the smart contract suspends the automatic advancement of the service process and sends a clear data re-entry instruction to the service terminal, prompting the operator to re-collect and upload the required data. A timer is also set to limit the completion time of the re-entry operation. If the data re-entry and upload are completed within the specified time, the process continues with the verification process. If a corresponding record exists on the chain, the smart contract extracts the hash value of the unstructured data recorded therein and compares it with the hash value calculated from the actual unstructured data retrieved from the off-chain distributed file storage system. This comparison is the core integrity verification step. If the two hash values ​​are consistent, it proves that the unstructured data stored off-chain has not been tampered with since it was uploaded and the hash value was recorded on-chain. The smart contract allows the service record status to be smoothly advanced to the next node and records the relevant advancement information. If the two hash values ​​are inconsistent, or the waiting time for re-recording exceeds the preset threshold and no valid data is received, it indicates that the data may have been tampered with or failed to be uploaded in time. The smart contract will prevent the advancement of the service status and mark the service record as an abnormal state. At the same time, it will automatically generate a report containing detailed abnormal information and send it to the administrator for processing. Therefore, by forcing on-chain and off-chain data consistency verification at key nodes, this solution ensures the authenticity and integrity of key unstructured data in the service process, prevents the advancement of processes based on false data, improves the credibility of after-sales service quality monitoring, and provides an automated processing and tracing mechanism for abnormal situations.

[0083] In some specific embodiments, assume a service process includes two mandatory data-linked nodes: "On-site Inspection" and "Troubleshooting." When a service worker completes the "On-site Inspection" and attempts to advance the service status to the "Troubleshooting" node at the service terminal, the system triggers a smart contract to perform verification. The smart contract first uses the service record ID to query on-chain data for records associated with the "On-site Inspection" node. If the query result is empty, the smart contract pauses the status advancement and sends a re-recording instruction to the service terminal, requesting the upload of on-site inspection photos and related metadata. It also starts a timer, for example, of 5 minutes. After the service worker uploads the data within 5 minutes, the process enters verification. If the on-chain query result is not empty, the smart contract extracts the hash value of the on-chain on-site inspection photo record, retrieves the corresponding photo data from the off-chain storage system, and calculates its hash value. The smart contract compares the on-chain hash value with the off-chain calculated hash value. If they match, the smart contract allows the service status to advance to the "Troubleshooting" node and records the advancement time. If there is any inconsistency, or the re-recording timer times out, the smart contract prevents the status from advancing, marks the service record as abnormal, generates an abnormality report, including the service record ID, the node "on-site detection", the abnormality type "hash value mismatch" or "re-recording timeout", the time of occurrence, the operator ID, and sends the report to the administrator account.

[0084] Reference Attachment Figure 2 The present invention provides a real-time monitoring system for after-sales service quality based on blockchain, comprising:

[0085] An acquisition module 100 is configured to acquire a node identifier of a mandatory data association node preset in a service process, and an upload requirement corresponding to the node identifier, wherein the upload requirement includes a specified unstructured data type and an upload quantity;

[0086] The collection module 200 is used to control or prompt the service terminal to collect unstructured data and specified metadata according to the upload requirements corresponding to the node identifier when the service terminal enters the mandatory data association node; the specified metadata includes the ID identifier of the current service record status, the collection timestamp, the geographic location, the terminal device identifier, and the operator identifier;

[0087] The generation module 300 is used to upload the unstructured data and specified metadata collected by the service terminal to a pre-established off-chain distributed file storage system, and generate a corresponding hash value as a unique identifier based on the unstructured data;

[0088] Transaction module 400, used to combine the specified metadata and the corresponding unstructured data hash value as associated information into a structured data packet, and submit it as an on-chain transaction data to a preset distributed ledger;

[0089] The verification module 500 is used to monitor the update of the service record status in real time. When the service record status attempts to advance from the current mandatory data association node to the next mandatory data association node, the smart contract deployed on the distributed ledger is used to query the corresponding on-chain data through the ID identifier of the current service record status, and verify the unstructured data hash value record associated with the current mandatory data association node; if the verification passes, the service status is allowed to advance; if the verification fails, the service status is prevented from advancing, and the service record status is marked as an abnormal state.

[0090] In this document, relational terms such as first and second, etc. are used merely to distinguish one entity or operation from another entity or operation, but do not necessarily require or imply any actual relationship or order between these entities or operations.

[0091] The foregoing description is merely an embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Those skilled in the art will readily appreciate that the present invention is susceptible to various modifications and variations. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.

Claims

1. A real-time monitoring method for after-sales service quality based on blockchain, characterized in that: The following steps are involved: Obtain the node identifier of the mandatory data association node preset in the service process, as well as the upload requirements corresponding to the node identifier, the upload requirements including the specified unstructured data type and upload quantity; When the service terminal enters the mandatory data association node, based on the corresponding node identifier, the service terminal is controlled or prompted to collect data for unstructured data and specified metadata in accordance with the upload requirements corresponding to the node identifier; the specified metadata includes the ID identifier of the current service record status, the collection timestamp, the geographic location, the terminal device identifier, and the operator identifier; Upload the unstructured data and specified metadata collected by the service terminal to a pre-established off-chain distributed file storage system, and generate a corresponding hash value as a unique identifier based on the unstructured data; Combine the specified metadata and the corresponding unstructured data hash value as associated information into a structured data packet, and submit it as an on-chain transaction data to the preset distributed ledger; Monitor the updates of service record status in real time. When the service record status attempts to advance from the current mandatory data association node to the next mandatory data association node, use the smart contract deployed on the distributed ledger to query the corresponding on-chain data through the ID of the current service record status and verify the unstructured data hash value record associated with the current mandatory data association node. If the verification passes, the service status is allowed to advance; If the verification fails, the service status will be stopped from advancing and the service record status will be marked as abnormal; The steps of uploading the unstructured data and specified metadata collected by the service terminal to a pre-established off-chain distributed file storage system and generating a corresponding hash value as a unique identifier based on the unstructured data include: Segment the unstructured data collected by the service terminal to generate multiple data blocks; data block strategies include fixed-size blocks, content-based blocks, or data type-based blocks; Upload multiple data blocks in parallel to the off-chain distributed file storage system. The off-chain distributed file storage system is the IPFS system. The IPFS system uses content addressing to store data blocks and generates a unique content identifier (CID) for each data block. Based on the multiple content identifiers (CIDs) corresponding to the unstructured data, a Merkle tree is constructed. The leaf nodes of the Merkle tree are the content identifiers (CIDs), the intermediate nodes are the hash values ​​of the leaf node hash values ​​at each level, and the root node is the final Merkle root hash value. The Merkle root hash value is used as the unique identifier of unstructured data for subsequent on-chain data verification.

2. The method for real-time monitoring of after-sales service quality based on blockchain according to claim 1 is characterized in that: When the service terminal enters the mandatory data association node, according to the corresponding node identifier, the service terminal is controlled or prompted to perform data collection for unstructured data and specified metadata according to the upload requirements corresponding to the node identifier: A1. When a service terminal enters a mandatory data association node, it scans the QR code corresponding to the node identifier and interprets it to obtain a data collection instruction. The data collection instruction includes the unstructured data type, quantity requirement, and metadata type. A2. Determine the type of unstructured data according to the data collection instruction. If it is an image type, execute step A3. If it is an audio type, execute step A4. A3. Activate the service terminal's camera, force the flash on, and prompt the operator to adjust the shooting angle. When the image clarity exceeds a preset threshold, capture a specified number of images and record the capture timestamp, geographic location, terminal device ID, and operator ID as metadata. A4. Activate the service terminal's microphone, force noise reduction mode, and prompt the operator to record audio for a specified duration. The recording timestamp, geographic location, terminal device ID, and operator ID are also recorded as metadata.

3. The method for real-time monitoring of after-sales service quality based on blockchain according to claim 1 is characterized in that: The steps of combining the specified metadata and the corresponding unstructured data hash value as associated information into a structured data packet and submitting it as an on-chain transaction data to the preset distributed ledger include: The transaction priority score is calculated based on the importance of the service record of the transaction to be submitted, the criticality of the data-related node, and the historical transaction congestion; The Gas fee of the structured data packet is determined based on the transaction priority score. If the transaction priority score is higher than the preset first threshold, a high Gas fee is set; if the transaction priority score is lower than the preset second threshold, a low Gas fee is set, and the transaction is submitted during the network idle period. Combine the specified metadata, the corresponding unstructured data hash value, and the gas fee set in the previous step into a structured data packet, sign the structured data packet, and generate on-chain transaction data; Submit on-chain transaction data to the preset distributed ledger, and track the transaction confirmation progress in real time by monitoring the transaction pool status. If the transaction is not confirmed for a long time, the gas fee will be dynamically adjusted according to the current network congestion, and the transaction will be resubmitted until the transaction is confirmed and recorded by the distributed ledger.

4. The method for real-time monitoring of after-sales service quality based on blockchain according to claim 1 is characterized in that: The steps of combining the specified metadata and the corresponding unstructured data hash value as associated information into a structured data packet and submitting it as an on-chain transaction data to the preset distributed ledger include: Obtain the preset cross-chain interoperability protocol; Based on the service record ID, query the specified metadata and the corresponding unstructured data hash value on the source chain, and encapsulate the specified metadata and the corresponding hash value into a cross-chain transaction request in accordance with the data format specified by the cross-chain interoperability protocol; Send the cross-chain transaction request to the preset cross-chain bridge node, and verify the legitimacy of the cross-chain transaction request through the cross-chain bridge node, including signature verification, data format verification, and gas fee verification; If the verification is successful, the cross-chain bridge node forwards the cross-chain transaction request to the target chain. The smart contract on the target chain parses the cross-chain transaction request according to the cross-chain interoperability protocol, and writes the specified metadata and corresponding hash value into the target chain to complete the cross-chain data synchronization.

5. The method for real-time monitoring of after-sales service quality based on blockchain according to claim 1 is characterized in that: The steps of monitoring the update of the service record status in real time and querying the corresponding on-chain data by the ID of the current service record status when the service record status attempts to advance from the current mandatory data association node to the next mandatory data association node using the smart contract deployed on the distributed ledger and verifying the unstructured data hash value record associated with the current mandatory data association node include: B1. When the service record status attempts to advance from the current mandatory data-associated node to the next node, the smart contract queries the on-chain data associated with the ID identifier of the current service record status. If the query result is empty, it executes step B2; if the query result is not empty, it executes step B3; B2. The smart contract suspends the progress of the service recording status and sends a data re-recording instruction to the service terminal. The data re-recording instruction includes the node identifier of the current mandatory data association node, the type of unstructured data, the required quantity, and the metadata type. At the same time, a timer is started to record the re-recording waiting time; B3. The smart contract extracts the hash value record of the unstructured data associated with the current mandatory data association node from the on-chain data, and retrieves the hash value corresponding to the ID identifier of the current service record status from the off-chain distributed file storage system. If the hash value of the off-chain record is consistent with the hash value of the on-chain record, step B31 is executed; if the hash value of the off-chain record is inconsistent with the hash value of the on-chain record, step B32 is executed. B31. The smart contract allows the service status to be advanced to the next node, and records the advancement time and operator ID; B32. The smart contract prevents the service status from advancing and marks the service record status as abnormal. It also generates an abnormality report and sends it to the preset administrator account.

6. The method for real-time monitoring of after-sales service quality based on blockchain according to claim 5 is characterized in that: Step B2 is followed by the following steps: B4. The smart contract monitors the re-recording waiting time. If the re-recording waiting time exceeds the preset threshold, step B32 is executed. If the data re-uploaded by the service terminal is received within the preset threshold, step B3 is executed.

7. The method for real-time monitoring of after-sales service quality based on blockchain according to claim 5 is characterized in that: The exception report contains the service record ID, exception node ID, exception type, occurrence time, and operator ID.

8. A blockchain-based after-sales service quality real-time monitoring system using the blockchain-based after-sales service quality real-time monitoring method according to any one of claims 1 to 7, characterized in that: include: An acquisition module is used to obtain the node identifier of the mandatory data association node preset in the service process, and the upload requirement corresponding to the node identifier, the upload requirement including the specified unstructured data type and upload quantity; The collection module is used to control or prompt the service terminal to collect unstructured data and specified metadata according to the upload requirements corresponding to the node identifier when the service terminal enters the mandatory data association node; the specified metadata includes the ID identifier of the current service record status, the collection timestamp, the geographic location, the terminal device identifier, and the operator identifier; A generation module is used to upload the unstructured data and specified metadata collected by the service terminal to a pre-established off-chain distributed file storage system, and generate a corresponding hash value as a unique identifier based on the unstructured data; The transaction module is used to combine the specified metadata and the corresponding unstructured data hash value as associated information into a structured data packet, and submit it as an on-chain transaction data to the preset distributed ledger; The verification module is used to monitor the update of the service record status in real time. When the service record status attempts to advance from the current mandatory data association node to the next mandatory data association node, it uses the smart contract deployed on the distributed ledger to query the corresponding on-chain data through the ID identifier of the current service record status and verify the unstructured data hash value record associated with the current mandatory data association node; If the verification passes, the service status is allowed to advance; if the verification fails, the service status is prevented from advancing and the service record status is marked as abnormal.

Images