Blockchain-based smart home data trustful detection method and system

Abstract

The application relates to the technical field of smart home and data security, in particular to a smart home data credible detection method and system based on a block chain; the method comprises the following steps: structurally mapping and extracting features of original event data at a device end, generating an integrity certificate by constructing a Merkle tree, and signing a three-section event fingerprint by using a device private key to complete credible packaging of data; constructing a family chain transaction based on the event fingerprint to perform low-delay initial commitment, and combining a double-slot credit model to perform real-time updating and dynamic adjustment of a sampling strategy on device credit; realizing multi-level credit cross verification and dynamic trust regulation by local credit aggregation of the family chain and cross verification of a neighborhood chain; and performing history credit weighted smoothing and trend prediction based on global credit output. The application effectively ensures that smart home data is non-tamperable, verifiable and traceable in the process of collection, transmission and storage, and improves automatic identification and collaborative response capability on abnormal behavior.

Description

Technical Field

[0001] This invention relates to the field of smart home and data security technology, specifically to a blockchain-based method and system for trustworthy smart home data detection. Background Technology

[0002] With the widespread application of smart home technology and the continuous deepening of the Internet of Things ecosystem, the scale of status and behavior data generated by multi-source heterogeneous devices in the home environment has increased significantly. This data is not only the foundation for realizing scenario-based intelligent services, but also puts forward higher requirements for data trust verification and cross-domain secure collaboration.

[0003] Chinese invention patent application CN120434043A discloses a smart home early warning method and system based on dual authentication. This method collects four key elements of early warning events through an edge computing gateway, encapsulates these elements into data packets, and transmits them to the gateway's cache for further processing. The system employs a dual authentication mechanism to ensure device access security at both the physical and logical layers, effectively preventing intrusion by unknown devices and reducing the risk of data leakage. For data storage, a collaborative on-chain and off-chain storage approach is adopted. On-chain storage utilizes the immutability of blockchain to ensure the authenticity and integrity of key event information, while off-chain storage uses distributed storage and encryption to protect the security of the original data. This comprehensive approach protects user data privacy and security, ensuring the security of smart home system data.

[0004] At the same time, the industry is actively exploring technical paths that combine distributed ledgers, lightweight cryptography and edge computing to build an end-to-end trusted data governance system. This system ensures the authenticity and integrity of data while also taking into account the real-time performance and availability of home-level applications. This trend is driving the exploration and development of flexible and collaborative trusted assurance methods for smart home scenarios. Summary of the Invention

[0005] The purpose of this invention is to address the problems existing in the background technology by proposing a blockchain-based method and system for reliable detection of smart home data.

[0006] The technical solution of this invention: a blockchain-based method for trusted detection of smart home data, comprising the following specific implementation steps:

[0007] S1. On the device side, the structured mapping and feature extraction of the original event data are completed. The integrity certificate is generated by constructing a Merkle tree and digitally signed using the device private key to form a three-segment event fingerprint containing an identity digest layer, an integrity layer and a feature layer, thereby achieving trusted encapsulation of the data.

[0008] S2. Construct family chain transactions based on three-stage event fingerprints and make low-latency initial commitments. At the same time, combine a dual-slot reputation model that includes short-term reputation and long-term reputation to update device reputation in real time, and dynamically adjust the data sampling strategy based on the updated reputation.

[0009] S3. By performing local reputation aggregation within the family chain and cross-validation between neighboring chains, multi-level reputation cross-validation and dynamic trust control can be achieved from within the family chain to the cross-chain area.

[0010] S4. Based on the global reputation output, the historical reputation of nodes is weighted and smoothed and trend prediction analysis is performed to achieve a two-layer early warning closed loop at the node and regional levels.

[0011] Preferably, the structured mapping and feature extraction of raw event data performed on the device side includes:

[0012] When a smart home device detects a status change event, it immediately collects raw event data containing timestamps, device identifiers, status values, and environmental parameters.

[0013] The original event data is uniformly converted into a standardized vector with a consistent format using a structured mapping function;

[0014] A lightweight autoencoder model is used to extract features from the normalized vector and compress it into a low-dimensional behavioral feature vector, while preserving event pattern information and achieving privacy protection.

[0015] Preferably, generating integrity credentials by constructing a Merkle tree includes:

[0016] The event data, after being structured and mapped, is divided into multiple data fragments of fixed length;

[0017] Calculate the hash value for each data shard separately;

[0018] A Merkle tree is constructed based on the hash values ​​of all fragments to generate a root hash value representing the integrity of the event;

[0019] The shard index of the data shard is stored for fast location and verification of off-chain data.

[0020] Preferably, the three-segment event fingerprint includes:

[0021] The device identifier and timestamp are hashed and combined to generate an identity digest layer;

[0022] Use Merkle tree root hash as the integrity layer;

[0023] Use low-dimensional behavioral feature vectors as the feature layer;

[0024] The three layers of information are combined and digitally signed using the device's private key to generate the final event fingerprint.

[0025] Preferably, family chain transactions based on three-stage event fingerprinting include:

[0026] The event fingerprint is packaged together with the device’s current local reputation snapshot, anti-replay random number, local entropy and transaction tag information to form a family chain transaction;

[0027] The transaction is verified by device digital signature and the consistency of event timestamp is checked at the home gateway layer.

[0028] The transaction is only gateway-signed and prepared for submission to the family chain when both verification and checks pass.

[0029] Preferably, real-time updates to device reputation, combining a dual-slot reputation model that includes both short-term and long-term reputation, include:

[0030] Based on the family chain transaction confirmation results and event fingerprint quality, a single event instant quality score is calculated;

[0031] An exponentially weighted moving average method is used to quickly update the short-term reputation of equipment based on real-time quality scores;

[0032] Every preset number of event windows, the device's long-term reputation is robustly updated based on the average short-term reputation within the window.

[0033] When the quality score of an event falls below the failure score threshold for m consecutive events, the device isolation mechanism is triggered and its short-term reputation is significantly reduced, where m is the set consecutive failure count threshold.

[0034] Preferably, the method of cross-validation through local reputation aggregation of the family chain and the neighborhood chain includes:

[0035] The short-term and long-term reputations of all devices are aggregated at the family chain gateway layer, and a weighted local reputation average is calculated by combining device weights and time decay factors.

[0036] The family chain gateway periodically exchanges hash-digested reputation snapshots with neighboring family chain gateways;

[0037] The cross-chain consistency coefficient is calculated by comparing the difference between the local average reputation and the neighboring chain average reputation.

[0038] When the reputation difference exceeds a set threshold, a reputation offset flag is triggered and a cross-confirmation process is initiated.

[0039] Preferably, dynamic trust regulation includes:

[0040] Calculate the trust adjustment coefficient for each device based on the cross-chain consistency coefficient and the individual node reputation deviation;

[0041] The trust weight of each device is dynamically updated based on the trust adjustment coefficient, and all weights are normalized.

[0042] The updated device weights and the overall reputation of the family chain will be uploaded to the regional control layer.

[0043] An exponential smoothing algorithm is used at the regional control layer to fuse the reputation information uploaded by each family chain to form a global reputation matrix.

[0044] Preferably, based on the global reputation output, the historical reputation of nodes is subjected to weighted smoothing and trend prediction analysis, including:

[0045] Extract the historical global reputation sequence of each node and apply time decay weighting to obtain a smoothed historical reputation value;

[0046] Based on the weighted historical reputation sequence, the reputation value of a node in the next time window is predicted by an exponentially weighted trend analysis model.

[0047] The offset difference between the predicted reputation value and the actual reputation value of the calculated node is compared with the dynamically adjusted warning threshold.

[0048] When the offset difference exceeds the warning threshold, a node-level warning signal is triggered;

[0049] The weighted reputation offset of all nodes within the family chain is aggregated to form a regional overall offset index;

[0050] Based on historical regional fluctuations, a regional-level early warning is triggered when the overall offset index exceeds a dynamic threshold calculated based on historical standard deviations.

[0051] The technical solution of this invention: A blockchain-based smart home data trust detection system, which is used to execute the above-mentioned blockchain-based smart home data trust detection method, comprising:

[0052] Memory;

[0053] processor;

[0054] A computer program stored in the memory and capable of running on the processor;

[0055] The processor executes a computer program to implement the aforementioned blockchain-based smart home data trust detection method.

[0056] Compared with the prior art, the above-mentioned technical solution of the present invention has the following beneficial technical effects:

[0057] This invention designs a blockchain-based smart home data trust detection method and system. By integrating structured mapping, feature extraction, and Merkle tree construction at the device end, combined with a three-stage event fingerprint generation technology, a trustworthy closed loop is achieved throughout the entire data collection process, from the source to the encapsulation, ensuring the immutability, traceability, and privacy protection of individual events. By constructing a family chain transaction and low-latency initial commitment mechanism, and introducing a dual-slot reputation model that integrates short-term and long-term behaviors, real-time evaluation and dynamic trust adjustment of device behavior are achieved, significantly improving the system's sensitivity to and response time to abnormal events. Through local reputation aggregation, neighbor chain cross-validation, and dynamic weight adjustment, multi-level reputation collaborative verification and self-organized trust propagation from within the family to cross-chain areas are achieved, effectively enhancing the system's overall robustness and fault tolerance when facing abnormal node behavior or data conflicts. Based on the global reputation matrix, historical trend prediction and offset warning are performed, constructing a two-layer warning closed loop from nodes to regions, enabling the system not only to identify current anomalies but also to predict potential risks, achieving proactive defense and collaborative autonomy in the trust management of smart home data. Attached Figure Description

[0058] Figure 1 This is a flowchart of a blockchain-based smart home data trust detection method proposed in this invention. Detailed Implementation

[0059] Example 1, as Figure 1 As shown, the present invention proposes a blockchain-based smart home data trust detection method, which includes the following specific implementation steps:

[0060] S1. By completing the structured mapping, feature extraction, Merkle tree integrity verification, and three-segment signature fingerprint generation of the original events on the device side, a closed loop is achieved for the entire process of smart home data from collection to trusted encapsulation. A parallel mechanism for data trustworthiness and privacy protection is built locally to ensure that events are verifiable, traceable, and tamper-proof, laying a secure foundation for subsequent on-chain and trusted detection. Specifically:

[0061] S11. Upon detecting a status change, the device immediately collects raw event data and uses a structured mapping function to convert time, device ID, status value, and environmental parameters into standardized vectors, providing consistent input for subsequent feature extraction and hash digest.

[0062] When any smart home device (such as a door lock, temperature and humidity sensor, or video surveillance terminal) detects a state change event, the local control node immediately initiates the event capture mechanism, performs structured mapping on the raw data, and describes the event as: ;

[0063] Among them, Ei t represents the i-th event; i The local timestamp indicating the occurrence of the event is recorded by the device's internal RTC (Real-Time Clock); D i Indicates Device ID; V i This represents the raw event values ​​collected by the device, such as raw measurement data like temperature, switch status, current, and voltage; P i It represents event context information, including but not limited to network latency, signal strength, and ambient light.

[0064] Through structured mapping functions Normalize this data into a vector form with a fixed format:

[0065] ;

[0066] in, This represents an event structured mapping function that maps data from different device formats into a unified structure and outputs a standardized event vector. , , and The feature mapping sub-functions correspond to feature transformations of event values, context, device information, and time, respectively, achieving numerical normalization and comparability conversion for different fields; X i Represents the event vector after structured mapping;

[0067] S12. On the device side, a lightweight autoencoder model is used to extract features from the structured event data, transforming the original numerical values ​​into low-dimensional behavioral feature vectors, thus completing the pattern-preserving anonymized representation.

[0068] Extract behavioral feature vectors locally using a lightweight feature extraction network: ;

[0069] The model learns the behavioral characteristics of the device by minimizing the reconstruction error:

[0070] ;

[0071] Therefore: eigenvector F i It retains the pattern information of device state changes, but does not contain any reversible privacy content, and is an anonymous representation of event patterns;

[0072] in, This represents the autoencoder function, which performs dimensionality compression and feature reconstruction, learning internal patterns of events; L rec This represents the reconstruction loss function, which measures the accuracy of feature extraction. The smaller the value, the better the model retains the core features of the event. This represents the encoder function, which takes a high-dimensional input X... i Compressed into a low-dimensional latent space representation; The decoder function reconstructs the original space from the low-dimensional latent features to calculate the reconstruction error; F i The feature vector representing the event;

[0073] S13. Divide the event data into several fragments, calculate the hash of each fragment and construct a Merkle tree to generate the root hash value of the event as an integrity credential. Simultaneously, save the fragment index for rapid off-chain location, ensuring the tamper-proof and verifiable nature of the event content.

[0074] The original event vector X i Divide the data into several fixed-length fragments:

[0075] ;

[0076] And calculate the hash value for each shard: ;

[0077] Then, the event root hash is generated using the Merkle tree construction algorithm:

[0078] ;

[0079] Among them, S i This represents a set of event data shards, where X... i Divided into segments according to a fixed segment size k; s i,j h represents the j-th data fragment of the i-th event; i,j Indicates the fragment hash value; Represents the cryptographic hash function; in this embodiment, algorithms such as SHA-256, SM3, or BLAKE2 can be used. || represents the concatenation operator; R i This represents the Merkle tree root hash.

[0080] S14. The device identifier, timestamp, Merkle root hash, and feature vector are hashed and integrated, and signed with the device's private key to generate a three-part event fingerprint containing an identity digest layer, an integrity layer, and a feature layer. This achieves simultaneous assurance of data trustworthiness, behavioral verifiability, and identity traceability, providing a lightweight and trusted encapsulation for on-chain evidence storage.

[0081] The three types of information mentioned above are weighted and integrated to generate the final event fingerprint:

[0082] ;

[0083] The final generated event fingerprint is defined as follows: ;

[0084] Among them, Sig i Indicates the event signature result; SK D Indicates the device's private key; This represents a digital signature function based on the device's private key; I i Represents an event fingerprint; This represents the meta-digest hash, which is a joint digest of device identity and time information; This represents a lightweight hash function used for meta-digest computation.

[0085] S2. Based on the event fingerprint generated in step S1, construct a family chain transaction and make a low-latency initial commitment. Simultaneously, combine a local dual-slot reputation model to update device reputation in real time. Transactions carry reputation snapshots and random entropy within the chain, improving on-chain trustworthiness. Furthermore, efficient monitoring and rapid response are ensured through adaptive sampling rates and edge-triggered mechanisms. Specifically:

[0086] S21. Transfer the event fingerprint I generated in step S1. i The transaction is packaged with local device reputation snapshots, random entropy, and tagging information into a home chain transaction. Signature verification, time consistency checks, and digest generation are performed locally on the gateway to ensure transaction uniqueness and event integrity. Only verified transactions can be submitted to the chain, guaranteeing the credibility of the initial commitment and the quality of on-chain evidence.

[0087] Constructing family chain transactions: ;

[0088] Among them, Tx fam This represents a transaction object (a packaged transaction record) on the family chain, constructed by the gateway after receiving the device fingerprint, and used as the unit to be submitted to the family chain for initial commitment; This represents a short-term local reputation snapshot of the device at the time of transaction submission; nonce represents a replay-prevention random number or an incrementing sequence (transaction unique identifier), generated by the gateway (which can be a counter or an encrypted random number) to prevent transaction replay, ensure ordering, or serve as part of a random seed; e local This represents local entropy, i.e., the random entropy / seed value at the gateway or device level. It is used to increase transaction unpredictability, prevent predictable sampling or replay attacks, and can be used as a seed for generating sampling indices; m flags This represents the transaction metadata marker, which is the set of metadata identifiers for a transaction, marking the transaction priority or subsequent processing strategy (whether to prioritize review, whether to trigger sampling, etc.).

[0089] Calculate the transaction summary and sign it locally:

[0090] ;

[0091] ;

[0092] Here, txhash represents the transaction digest hash (a unique, fixed-length digest of a transaction), which serves as an index key, proof, and reference identifier for the transaction in the local evidence repository and on the blockchain; This represents the hash function used to calculate the transaction digest; sig gw This indicates the gateway's digital signature of the transaction digest txhash; Indicates a digital signature algorithm; SK gw This represents the gateway's private key;

[0093] It should be noted that when generating Tx fam Beforehand, the following conditions must be verified locally:

[0094] Condition 1: Device signature verification, confirmation event fingerprint I i The source is reliable and has not been tampered with:

[0095] ;

[0096] If verification fails, it means that the fingerprint may have been tampered with or generated by an unauthorized device, and the transaction cannot be generated.

[0097] in, This represents the device's public key, used to verify the signature. This represents the signature verification function used to verify the Sig signature. i Is it related to the public key? Match the signature and output True if the signature is correct, and False if the signature is invalid or has been tampered with.

[0098] Condition 2: Time consistency check to ensure that the event timestamps are reasonable and that there are no obvious backtracking or future events: If the event time exceeds If the scope is limited, it is considered that there may be forgery or anomalies;

[0099] in, This represents the allowable time difference threshold, used to tolerate small clock skews; t gw Indicates the gateway's local time, used as a reference.

[0100] S22. Broadcast the signed family blockchain transaction to the family blockchain network, use a lightweight consensus algorithm (such as small-scale PBFT / RAFT) to complete the confirmation, and generate confirmation evidence containing block height, hash, and node signature. The confirmation result determines the validity of the transaction, providing a reliable anchor for subsequent reputation updates and asynchronous edge evidence collection, realizing transaction traceability and instant verification, that is:

[0101] Broadcast and wait for confirmation; define the confirmation determination function. :

[0102] ;

[0103] Block b is generated after the transaction is included:

[0104] ;

[0105] And return confirmation evidence:

[0106] ;

[0107] Where ack_count represents the number of ACKs (acknowledgments) from participating nodes in the family chain for the transaction, i.e., the count of feedback from nodes after packaging / signing the transaction, used to determine whether the transaction has reached the consensus confirmation threshold; q represents the confirmation threshold (minimum necessary ACK count), which determines whether the transaction is considered confirmed; t gw_recv Indicates the local time when the gateway receives the final confirmation or acknowledgment feedback; T max 'b' represents the maximum confirmation delay threshold, i.e., the maximum allowable delay for determining whether a confirmation is timely; 'b' represents a block, i.e., a block containing transaction Tx. fam The block data structure (block header + transaction list + state changes, etc.); h prev `state_delta` represents the hash of the previous block, i.e., the hash value in the new block header pointing to the previous block; `state_delta` represents the difference between this transaction and the on-chain state (e.g., reputation table update, counter change); `ConfRec` represents the confirmation evidence structure generated after confirmation, used to prove that the transaction has been accepted on-chain and confirmed by node signature; b height This indicates the block height, i.e., the block's sequence number (height) in the chain; b hash This represents the block hash, also known as the block header hash, which serves as a digest identifier for the block content; timestamp. b The block timestamp represents the time when the block was generated / packaged; sig_nodes represents the node signature set, which is the set of signatures of participating nodes that signed the block or confirmation record. This represents the packaging function, which is the packaging operation that includes transactions into the block / chain (an internal function of the chain implementation);

[0108] S23. Based on the family chain confirmation results and fingerprint quality, the device reputation is updated in real time, constructing a dual-slot reputation model—short-term reputation (strong responsiveness, reflecting recent behavior) and long-term reputation (robustness, reflecting long-term performance). These two aspects work together to drive subsequent sampling rate and isolation strategies, namely:

[0109] Short-term reputation update: Calculates the immediate quality score for a single event, weighted by several quick inspection items:

[0110] ;

[0111] Among them, s i This represents the instantaneous quality score for a single event, i.e., the overall quality / credibility evaluation of a single event i. The value range is [0,1], with a larger value indicating a more credible and higher-quality event. sig The signature verification score represents the correctness of the device signature. In this embodiment, it is set to a binary value (1 = signature verification passed, 0 = failure). The metadata digest consistency score measures the consistency between the metadata digest H1 and the gateway / registration information, and its value is in the range [0,1]. R This indicates the previous reputation score, which is based on a previous reputation snapshot of the device (carried when the transaction was submitted). The prior confidence level of this event, with a value range of [0,1]; s F The fast consistency score of the feature layer is represented by F, which measures the feature vector F of this event. i Similarity to the device's recent behavior center or corresponding template, ranging from [0,1]; , , and This represents the sub-rating weight coefficient, corresponding to the four sub-ratings in the composite score. i Weight of time, ;

[0112] Short-term credit rating updated using an index-weighted method: ;

[0113] Long-term reputation update: Every W events of window size, calculate the average short-term reputation within the window and update the long-term reputation. ;

[0114] in, and α represents the old and new values ​​of short-term credit, i.e., the old value and the updated new value of the short-term credit of the equipment, both in the range of [0,1]; α represents the short-term credit smoothing coefficient. and These represent the old and new values ​​of long-term reputation, respectively, that is, the current and updated values ​​of the device's long-term reputation; This represents the short-term credit mean within the window, specifically the short-term credit value r within the selected window W. s The arithmetic mean;

[0115] It should be noted that if there are m consecutive failure counts (the set consecutive failure count threshold) times s i If the score is below the set failure score threshold, an alert is triggered, the action is isolated, and r is immediately... s Significantly lowered;

[0116] S24. Store the transaction confirmation evidence, updated reputation information, and shard index together in the local evidence repository. Dynamically adjust the reporting / sampling probability based on reputation, and immediately notify edge nodes in case of significant anomalies.

[0117] Create a local record:

[0118] ;

[0119] It is then written to an encrypted local database with the index key txhash;

[0120] Here, EE represents a local evidence entry, which is a comprehensive evidence record stored locally by the gateway / family chain node after the event is confirmed and the reputation update is completed. It includes, but is not limited to, transaction reference, confirmation evidence, shard index, reputation value, and action identifier fields. TxRef represents a transaction reference, which is a unique hash identifier pointing to the transaction submitted on the family chain for this event. ConfRec represents confirmation evidence, which is the confirmation evidence structure returned from the family chain, including but not limited to block height, block hash, block timestamp, and participating node signatures. Index represents a shard index table, which is the set of shard indexes generated in step S1 (including but not limited to the hash, shard number, and timestamp of each shard). action_flags represents a set of action identifiers, which are used to indicate the local actions to be taken for this event / device, such as normal, sample, isolate, audit, manual_review, etc.

[0121] Define the device reporting / sampling probability p sample Inverse relationship with reputation:

[0122] ;

[0123] If action_flags contains "isolate" or If the value is less than the set critical reputation threshold (0.3 in this example), a "high-priority alarm packet" is immediately sent to the edge node.

[0124] ;

[0125] Where, p sample p0 represents the sampling / reporting probability, the probability value (0-1) at which a device or gateway decides whether to report the raw fragment (or more evidence) to the edge / cloud; p0 represents the baseline sampling rate, which is the defined minimum normal sampling probability. η represents the sampling sensitivity coefficient, which controls the sensitivity of the sampling probability to reputation degradation; η represents the nonlinear amplification exponent; Alert represents the alarm packet, which is a message packet sent to the edge / operations or user when a high-priority event (isolation / important anomaly) is triggered; reason_code represents the trigger reason code, an enumerated code indicating the alarm reason (e.g., 01=signature failure, 02=time drift, 03=feature anomaly, 04=continuous failure).

[0126] S3. Through local reputation aggregation in the family chain, cross-validation in the neighborhood chain, dynamic weight adjustment, and global synchronous closed loop, multi-level reputation cross-validation and dynamic trust control from local to global are achieved, ensuring the credibility of smart home data and the robustness of the system. Simultaneously, it enhances the automatic identification and adaptation capabilities to abnormal nodes. Specifically:

[0127] S31. At the home chain gateway layer, the short-term and long-term reputation values ​​of each device are combined with weights and time decay coefficients to generate a weighted local reputation average, forming a local reputation vector aggregation. This ensures that the reputation within the home chain reflects recent dynamic behavior, improving the credibility and sensitivity of local data.

[0128] In step S2, each family chain node has generated a short-term reputation r s With long-term reputation l To achieve trusted fusion across nodes, a local reputation vector set is constructed at the home gateway layer:

[0129] ;

[0130] The gateway uses time decay and weight normalization to form a weighted local reputation average for the current family chain layer: ;

[0131] Where, r s,i r represents the short-term reputation value of the i-th device; l,i τ represents the long-term reputation value of the i-th device; i This represents the timestamp of the reputation update for the i-th device; R represents the node weight, characterizing the importance of a device in the local trust structure; n represents the total number of devices; loc Represents a local reputation vector set; This represents the weighted local reputation average of the family chain layer; Indicates the creditworthiness decay coefficient; t cur Indicates the current time;

[0132] S32. By sharing digested reputation snapshots among neighboring chains, cross-chain cross-validation is achieved to detect reputation differences in family chains, calculate consistency coefficients, identify offset or abnormal nodes, provide criteria for dynamic trust adjustment, and realize multi-chain collaborative verification, i.e.:

[0133] Construct a neighborhood chain cross-validation mechanism, with each family chain gateway G k Periodically with adjacent chain G k-1 G k+1 Shared, summarized reputation snapshots: ;

[0134] The neighbor chain receives Then, the reputation difference detection function is used:

[0135] ;

[0136] like This triggers the reputation offset marking and cross-confirmation tasks, further calculating the cross-chain consistency coefficient: ;

[0137] in, This represents the reputation snapshot summary generated by the k-th family chain gateway; t sync Indicates alignment and synchronization timestamps; δ k,j This represents the reputation difference between family chain k and neighbor chain j. Indicates the threshold for reputational discrepancies; This represents the weighted local reputation average of the k-th family chain; C represents the weighted local reputation average of neighborhood chain j; align M represents the cross-chain consistency coefficient; E represents the number of neighboring chain pairs, i.e., the number of neighboring chains connected to the current chain; and E represents the neighboring chain connection set.

[0138] S33. Based on the cross-chain consistency coefficient and node deviation, adaptively adjust the trust weight of each device and perform normalization processing to achieve dynamic trust propagation and feedback. This increases the weight of highly consistent nodes and decreases the weight of abnormal nodes, forming a self-organizing trust distribution and optimizing the overall network reputation structure.

[0139] When a cross-chain reputation shift or node anomaly is detected, the system enters a dynamic trust weight adjustment phase; for each node i, its adjustment coefficient is calculated:

[0140] ;

[0141] The node's new trust weight is updated as follows: And perform normalization on all nodes;

[0142] Where, θ i This represents the trust adjustment coefficient for node i; δ represents the trust integration balance coefficient; i This represents the deviation of node i from the local reputation mean; This represents the updated weight of node i; This represents the weight of node i before the update;

[0143] S34. Upload the comprehensive reputation of each family chain and the updated node weights to the regional control layer. Use exponential smoothing to form a global reputation matrix, assess its sparsity and stability, trigger checks on deviating nodes, and achieve full-domain reputation synchronization and closed-loop self-consistency.

[0144] Perform a global reputation synchronization operation to upload the overall reputation and node weight of each family chain to the upper-level regional trust control layer. The upper-level nodes then use exponential smoothing to form a global reputation matrix.

[0145] ;

[0146] Among them, R global Represents the global reputation matrix; Indicates the global smoothing parameter; This represents the latest local reputation vector aggregated from each family chain; This represents the global reputation vector calculated in the previous round (time step t).

[0147] S4. Based on the global reputation output of step S3, through historical reputation weighted smoothing, trend prediction, offset difference calculation, and node and regional level early warning, a closed loop for predicting and warning of node reputation offset in the smart home system is completed, ensuring that local anomalies can be identified in a timely manner and a coordinated response can be made across the entire domain. Specifically:

[0148] S41. Time-decay weighted smoothing is applied to the historical global reputation sequence of each node to form a sensitive and robust weighted historical reputation value. By strengthening the impact of recent behavior and preserving long-term trends, a reliable data foundation is provided for subsequent node reputation shift predictions.

[0149] Obtain the global reputation matrix R of each family chain node. global and node weight The historical reputation of each node will be extracted and smoothed: ;

[0150] in, α represents the historical reputation weighted value of node i at the current time t; K represents the historical window length, i.e., the number of past periods participating in the trend calculation; k This represents the historical weighting coefficient, used to emphasize the impact of recent credit fluctuations, and can be adjusted based on time decay or adaptive trend. ;r i (tk) represents the global reputation value of node i in the k-th time window in the past, derived from R. global Time series;

[0151] S42. Construct a node offset trend model using a weighted historical reputation sequence, and predict the reputation value for the next time window by adaptively fusing historical information and smoothed mean, i.e.:

[0152] Using historical weighted reputation sequence A node offset model is constructed through exponentially weighted trend analysis: ;

[0153] in, This represents the predicted reputation value for node i in the next time window. This represents the trend sensitivity coefficient, which controls the proportion of historical information integrated with the smoothed mean. This represents the average reputation value of node i within the historical window;

[0154] S43. Calculate the offset difference between the predicted reputation and the actual reputation of the node, and compare it with a dynamically adjusted early warning threshold. When the offset exceeds the threshold, a node-level early warning is triggered, achieving difference-sensitive and noise-resistant local anomaly identification, i.e.:

[0155] For each node, calculate the difference between the predicted offset and the current actual value:

[0156] ;

[0157] And compare with the dynamic threshold: If If the value exceeds the dynamic threshold, an early warning signal will be triggered.

[0158] in, This represents the node reputation offset, characterizing the difference between the prediction and the actual outcome.

[0159] S44. The offsets of each node are aggregated according to their weights to form a regional overall offset index. This index, combined with historical regional fluctuations, generates a dynamic early warning strategy, achieving a two-tiered early warning loop at both the node and regional levels. This allows for coordinated responses to local anomalies, improving the robustness and operability of overall reputation management.

[0160] Offset of each node By weight In summary, this forms the overall offset metric for the family chain or the regional chain: ;

[0161] Combining the historical standard deviation of blockchain fluctuations Generate regional early warning strategies: If If so, a regional-level early warning will be triggered;

[0162] in, This indicates an overall reputation offset indicator for a region or family chain. This indicates the safety factor and controls trigger sensitivity.

[0163] Example 2: The present invention proposes a blockchain-based smart home data trust detection system, which is used to execute the blockchain-based smart home data trust detection method proposed in Example 1, including:

[0164] Memory;

[0165] processor;

[0166] A computer program stored in the memory and capable of running on the processor;

[0167] The processor executes a computer program to implement a blockchain-based smart home data trust detection method as described in Embodiment 1 above.

[0168] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited thereto. Various changes can be made within the scope of knowledge possessed by those skilled in the art without departing from the spirit of the present invention.

Claims

1. A blockchain-based method for verifying the trustworthiness of smart home data, characterized in that, The specific implementation steps include the following: S1. On the device side, the structured mapping and feature extraction of the original event data are completed. The integrity certificate is generated by constructing a Merkle tree and digitally signed using the device private key to form a three-segment event fingerprint containing an identity digest layer, an integrity layer and a feature layer, thereby achieving trusted encapsulation of the data. S2. Construct family chain transactions based on three-stage event fingerprints and make low-latency initial commitments. At the same time, combine a dual-slot reputation model that includes short-term reputation and long-term reputation to update device reputation in real time, and dynamically adjust the data sampling strategy based on the updated reputation. Among these, the real-time updating of equipment reputation by combining a dual-slot reputation model that includes both short-term and long-term reputation includes: Based on the family chain transaction confirmation results and event fingerprint quality, a single event instant quality score is calculated; An exponentially weighted moving average method is used to quickly update the short-term reputation of equipment based on real-time quality scores; Every preset number of event windows, the device's long-term reputation is robustly updated based on the average short-term reputation within the window. When the quality score of an event is lower than the failure score threshold for m consecutive events, the device isolation mechanism is triggered and its short-term reputation is significantly reduced, where m is the set consecutive failure count threshold. S3. By performing local reputation aggregation within the family chain and cross-validation between neighboring chains, multi-level reputation cross-validation and dynamic trust control can be achieved from within the family chain to the cross-chain area. S4. Based on the global reputation output, perform weighted smoothing and trend prediction analysis on the historical reputation of nodes to complete a two-layer early warning closed loop at the node and regional levels.

2. The blockchain-based smart home data trust detection method according to claim 1, characterized in that, The structured mapping and feature extraction of raw event data at the device end includes: When a smart home device detects a status change event, it immediately collects raw event data containing timestamps, device identifiers, status values, and environmental parameters. The original event data is uniformly converted into a standardized vector with a consistent format using a structured mapping function; A lightweight autoencoder model is used to extract features from the normalized vector and compress it into a low-dimensional behavioral feature vector, while preserving event pattern information and achieving privacy protection.

3. The blockchain-based smart home data trust detection method according to claim 2, characterized in that, Generating integrity credentials by constructing a Merkle tree includes: The event data, after being structured and mapped, is divided into multiple data fragments of fixed length; Calculate the hash value for each data shard separately; A Merkle tree is constructed based on the hash values ​​of all fragments to generate a root hash value representing the integrity of the event; The shard index of the data shard is stored for fast location and verification of off-chain data.

4. The blockchain-based smart home data trust detection method according to claim 3, characterized in that, The three-stage event fingerprint includes: The device identifier and timestamp are hashed and combined to generate an identity digest layer; Use Merkle tree root hash as the integrity layer; Use low-dimensional behavioral feature vectors as the feature layer; The three layers of information are combined and digitally signed using the device's private key to generate the final event fingerprint.

5. The blockchain-based smart home data trust detection method according to claim 4, characterized in that, Family chain transactions built based on three-stage event fingerprinting include: The event fingerprint is packaged together with the device’s current local reputation snapshot, anti-replay random number, local entropy and transaction tag information to form a family chain transaction; The transaction is verified by device digital signature and the consistency of event timestamp is checked at the home gateway layer. The transaction is only gateway-signed and prepared for submission to the family chain when both verification and checks pass.

6. The blockchain-based smart home data trust detection method according to claim 5, characterized in that, The verification process involves local reputation aggregation within the family blockchain and cross-validation with neighboring blockchains, including: The short-term and long-term reputations of all devices are aggregated at the family chain gateway layer, and a weighted local reputation average is calculated by combining device weights and time decay factors. The family chain gateway periodically exchanges hash-digested reputation snapshots with neighboring family chain gateways; The cross-chain consistency coefficient is calculated by comparing the difference between the local average reputation and the neighboring chain average reputation. When the reputation difference exceeds a set threshold, a reputation offset flag is triggered and a cross-confirmation process is initiated.

7. The blockchain-based smart home data trust detection method according to claim 6, characterized in that, Dynamic trust regulation includes: Calculate the trust adjustment coefficient for each device based on the cross-chain consistency coefficient and the individual node reputation deviation; The trust weight of each device is dynamically updated based on the trust adjustment coefficient, and all weights are normalized. The updated device weights and the overall reputation of the family chain will be uploaded to the regional control layer. An exponential smoothing algorithm is used at the regional control layer to fuse the reputation information uploaded by each family chain to form a global reputation matrix.

8. The blockchain-based smart home data trust detection method according to claim 7, characterized in that, Based on the global reputation output, the historical reputation of nodes is weighted, smoothed, and trend predicted, including: Extract the historical global reputation sequence of each node and apply time decay weighting to obtain a smoothed historical reputation value; Based on the weighted historical reputation sequence, the reputation value of a node in the next time window is predicted by an exponentially weighted trend analysis model. The offset difference between the predicted reputation value and the actual reputation value of the calculated node is compared with the dynamically adjusted warning threshold. When the offset difference exceeds the warning threshold, a node-level warning signal is triggered; The weighted reputation offset of all nodes within the family chain is aggregated to form a regional overall offset index; Based on historical regional fluctuations, a regional-level early warning is triggered when the overall offset index exceeds a dynamic threshold calculated based on historical standard deviations.

9. A blockchain-based smart home data trust detection system, characterized in that, include: Memory; processor; A computer program stored in the memory and capable of running on the processor; The processor executes a computer program to implement the blockchain-based smart home data trust detection method as described in any one of claims 1 to 8.

Images