Blockchain-based Trusted Storage and Management System for Commercial Housing Information

Abstract

This invention relates to the fields of blockchain and intelligent decision-making technology, specifically to a blockchain-based trusted storage and management system for commercial housing information. Through the collaborative work of a data acquisition module, a preprocessing module, a hash processing module, an on-chain module, a calculation module, a management module, and a control module, it achieves trusted storage and effective management of commercial housing information. Furthermore, addressing the lack of optimization of system operating parameters for anomalies in existing blockchain management processes, the management module can automatically issue instructions to correct preprocessing parameters, on-chain parameters, and retransmit data based on different anomaly situations, thus preventing the continued occurrence of problems. This comprehensive management approach proposed in this invention not only ensures the authenticity and credibility of commercial housing information but also improves the efficiency and reliability of data management, effectively solving the shortcomings of existing blockchain management in handling data anomalies, and providing a more secure and reliable guarantee for the management and transaction of commercial housing information.

Description

Technical Field

[0001] This invention relates to the fields of blockchain and intelligent decision-making technology, specifically to a blockchain-based trusted storage and management system for commercial housing information. Background Technology

[0002] In today's internet age, online property searching has become one of the main ways people find housing. However, this process faces many difficulties. First, the authenticity of property information is hard to guarantee; many websites contain inaccurate, outdated, or incomplete information. Second, property information is scattered across multiple platforms, resulting in severe data fragmentation. Furthermore, the property transaction process is complex and risky. Traditional property transactions involve multiple steps, including signing contracts, paying deposits, loan approvals, and property transfer registration; even slight errors can lead to breaches of contract or financial risks. Moreover, property transactions also involve risks such as selling the same property multiple times or fraud, causing significant financial losses to homebuyers. Blockchain technology offers a new approach to solving the difficulties of online property searching. Its distributed ledger ensures the authenticity and immutability of property information, improving information credibility and reducing verification time. Simultaneously, it enables centralized management and sharing of property information, avoiding data fragmentation and improving search efficiency; putting commercial property listings on the blockchain has become an inevitable trend. As property listings are uploaded to the blockchain, problems arise as well. While blockchain data is immutable, inconsistencies can occur over time due to various reasons (such as network latency, node failures, and data updates). Therefore, proper management of on-chain data has become crucial. Currently, the common approach is for users to report data anomalies or for the database to periodically check and report them. Technicians then investigate the source of the anomalies based on the feedback and re-upload the data to the blockchain. However, this approach only addresses the anomalies without resolving the underlying causes, which may lead to the continued occurrence of subsequent problems.

[0003] Chinese patent CN119963301A discloses a blockchain-based rental management system, including a property quality assessment module, a tenant credit module, and a rental management module. The property quality assessment module stores historical rental data and calculates property quality coefficients to filter qualified rental properties. The tenant credit module records tenant rental history information, collects tenant credit scores, number of late payment payments, and number of contract terminations based on this history, calculates tenant risk scores, and assigns risk ratings to tenants. The rental management module prioritizes searches based on property quality coefficients, calculates recommended rental terms and tenant target rental terms, and calculates the final rental deposit, thus improving rental management efficiency and optimizing the tenant experience. While the system has achieved the on-chain recording of housing information, it has not considered the data management issues after on-chain recording. During long-term use, various problems are likely to arise. At this time, the only solution is to rely on re-uploading the data to the blockchain, which is not only inefficient and costly to maintain, but also has the potential to continue to occur because the root cause of the problem has not been addressed. How to identify and correct abnormal data while simultaneously identifying and correcting the cause of the anomaly has become a hot research topic. Summary of the Invention

[0004] This invention provides a blockchain-based trusted storage and management system for commercial housing information, which overcomes the problem that existing blockchain management systems only re-upload data when data anomalies are detected, without tracing and correcting the cause of the anomalies, leading to the continuous occurrence of anomalies.

[0005] Therefore, this invention provides a blockchain-based trusted storage and management system for commercial housing information, including:

[0006] The data acquisition module is used to collect commercial property information data;

[0007] The preprocessing module, which is connected to the acquisition module, is used to preprocess the acquired commercial housing information data to obtain several preprocessed data items, including filtering invalid information in the commercial housing information data based on a minimum length threshold and adding timestamps. The minimum length threshold refers to the shortest length of the data field to be retained.

[0008] A hash processing module, which is connected to the preprocessing module, is used to generate storage hash values ​​for each of the preprocessed data items based on a hash algorithm.

[0009] The on-chain module, which is connected to the preprocessing module and the hash processing module, is used to compress each preprocessed data item and its corresponding storage hash value, and upload it to the storage system and write it into the blockchain ledger after confirmation by the confirmation fast module.

[0010] The calculation module, which is connected to the on-chain module, is used to output the hash value corresponding to each preprocessed data item as the calculated hash value, and the proportion of preprocessed data items that fail to match in the total number of preprocessed data items as the failure matching proportion.

[0011] The management module, which is connected to the computing module and the on-chain module, is used to periodically match each of the computing hash values ​​with the corresponding storage hash values, and, when a matching failure is determined, to determine the reason for the failure based on the proportion of matching failures, and to issue instructions to correct the preprocessing parameters, on-chain parameters and retransmission based on the corresponding reason.

[0012] The control module, which is connected to the management module, the preprocessing module and the on-chain module, is used to correct the parameters of the corresponding module based on the correction instructions issued by the management module and issue a notification.

[0013] Furthermore, the management module is used to periodically match each calculated hash value with the corresponding stored hash value, and when a match is found to be successful, maintain the system parameters and continue to determine whether the next preprocessed data item matches, or when a match is found to be unsuccessful, determine the reason for the unsuccessful match based on the proportion of unsuccessful matches.

[0014] Furthermore, the management module is also used to determine the reason for the matching failure based on the matching failure ratio, and, when the matching failure ratio is less than or equal to the preset matching failure ratio, to determine the reason for the matching failure based on the hash value output of the commercial housing information data before and after preprocessing, or, when the matching failure ratio is greater than the preset matching failure ratio, to determine the reason for the failure based on the hash value length.

[0015] Furthermore, the management module is also used to determine the reason for the matching failure based on the hash value of the commercial housing information data output before and after preprocessing, and, when it is determined that the timestamp is abnormal, to determine the reason for the matching failure based on the absolute value of the difference between the evidence storage timestamp and the verification timestamp, or, when it is determined that the minimum length threshold is set unreasonably, to correct the minimum length threshold based on the ratio between the preset matching failure ratio and the matching failure ratio and retransmit the preprocessed data item that failed to match.

[0016] Furthermore, the management module is also used to determine the matching failure ratio based on the ratio between the preset matching failure ratio and the matching failure ratio, and to reduce the minimum length threshold based on the matching failure ratio, wherein the reduction of the minimum length threshold is proportional to the matching failure ratio.

[0017] Furthermore, the management module is also used to determine the absolute value of the timestamp difference based on the absolute value of the difference between the evidence storage timestamp and the verification timestamp, and to determine the reason for the matching failure based on the absolute value of the timestamp difference, and to issue a clock synchronization command when it is determined that the clock synchronization is abnormal, or to determine the correction method based on the minimum value of the difference between the timestamp of each matching failure data and the current timestamp when it is determined that the network is poor.

[0018] Furthermore, the management module is also used to determine the failure timestamp difference based on the difference between the timestamp of each failed preprocessed data item and the current timestamp, and to determine the minimum failure timestamp difference based on the minimum of each failure timestamp difference, to determine the correction method based on the minimum failure timestamp difference, and, when it is determined that the current network fluctuation is a factor, to correct the compression ratio based on the difference between the current delay jitter and the preset delay jitter and to issue an instruction to retransmit the failed preprocessed data item, or to issue an instruction to retransmit the failed preprocessed data item.

[0019] The compression ratio refers to the ratio of the compressed data size to the original data size, and the delay jitter refers to the difference between the maximum transmission delay and the minimum delay.

[0020] Furthermore, the management module is also used to determine a delay jitter difference based on the difference between the current delay jitter and the preset delay jitter, and to increase the compression ratio based on the delay jitter difference, wherein the increase in the compression ratio is proportional to the delay jitter difference.

[0021] Furthermore, the management module is also used to calculate the hash value length to determine the reason for failure, and, when it is determined to be a data rollback, to adjust the number of confirmation blocks based on the number of rollbacks per unit time and retransmit the preprocessed data items that failed to match, or to issue a hash algorithm version mismatch notification.

[0022] Furthermore, the management module is also used to determine the number of rollbacks based on the number of rollbacks per unit time, and to increase the number of confirmation blocks based on the number of rollbacks, wherein the increase in the number of confirmation blocks is proportional to the number of rollbacks.

[0023] Compared with existing technologies, the beneficial effects of this invention are that it provides a blockchain-based trusted storage and management system for commercial housing information. Through the collaborative work of a data acquisition module, a preprocessing module, a hash processing module, an on-chain module, a calculation module, a management module, and a control module, it achieves trusted storage and effective management of commercial housing information. The management module can automatically issue instructions to correct preprocessing parameters, on-chain parameters, and retransmit data based on different anomalies. The control module then corrects the parameters of the corresponding modules according to these instructions and issues notifications. This automated parameter correction and notification mechanism allows the system to dynamically adjust its working state according to actual conditions without frequent manual intervention, greatly improving the system's intelligence and adaptability. In summary, this system preprocesses the collected commercial housing information data, generates hash values, stores it on the blockchain, and uses periodic hash value matching to determine the correctness and integrity of the data. It promptly detects data anomalies and issues automated correction instructions, ensuring the authenticity and credibility of commercial housing information while effectively solving the shortcomings of existing blockchain management in handling data anomalies. This provides a more secure and reliable guarantee for the management and transaction of commercial housing information.

[0024] Furthermore, by periodically matching the calculated hash value with the stored hash value, maintaining system parameters when a match is successful, and determining the cause of failure based on the failure rate when a match fails, the system can more accurately identify data anomalies. This periodic checking and judgment mechanism can promptly detect data anomalies, thereby further improving the system's stability and reliability, and ensuring a more efficient and secure process for the credible storage and management of commercial property information.

[0025] Furthermore, when the proportion of failed matches is less than or equal to a preset value, the cause of the anomaly is determined by comparing the hash values ​​before and after preprocessing; when the proportion of failed matches is greater than the preset value, the cause is determined by the hash value length. This hierarchical judgment method can more comprehensively cover various possible anomalies, accurately locate the root cause of the problem, and thus provide a clear direction for subsequent parameter correction and problem solving. It effectively improves the system's intelligent decision-making ability and anomaly handling efficiency, reduces manual intervention, lowers maintenance costs, and enhances the overall performance and stability of the system.

[0026] Furthermore, when hash values ​​before and after preprocessing are inconsistent, the specific cause is determined by analyzing timestamp anomalies or unreasonable minimum length threshold settings; when hash value lengths are inconsistent, it is judged as data rollback or hash algorithm version mismatch. This detailed judgment logic enables the system to more accurately identify various anomalies and take corresponding corrective measures accordingly. This targeted correction method not only effectively solves current anomalies but also prevents similar problems from recurring, further improving the system's adaptability and stability, and ensuring a more reliable and efficient process for the credible storage and management of commercial property information.

[0027] Furthermore, by comparing the ratio of failed matches with a preset range, and adjusting the minimum length threshold using different correction thresholds for different ranges, the system can dynamically optimize preprocessing parameters based on actual anomalies. This dynamic adjustment mechanism effectively prevents valid data from being incorrectly filtered out due to an excessively high minimum length threshold, thereby reducing the failure rate and improving data availability and integrity. Simultaneously, by proportionally reducing the minimum length threshold to the ratio of failed matches, a smooth and reasonable parameter adjustment curve is achieved, avoiding system instability caused by excessive parameter jumps and ensuring stable operation during dynamic adjustments.

[0028] Furthermore, by calculating the absolute value of the difference between the evidence storage timestamp and the verification timestamp and comparing it with a preset value, the system can accurately determine whether the matching failure is due to a clock synchronization anomaly or a poor network connection. This precise judgment method allows the system to take corresponding corrective measures for different problems, effectively resolving current anomalies and preventing similar problems from recurring, thus further improving the system's adaptability and stability.

[0029] Furthermore, by comparing the minimum failure timestamp difference with preset values, and the latency jitter difference with preset values, the system can accurately determine the current network status and adjust the compression ratio or issue a retransmission command accordingly. This dynamic adjustment mechanism effectively addresses the impact of network fluctuations on data transmission, ensuring data accuracy and integrity. Simultaneously, by proportionally increasing the compression ratio to the latency jitter difference, a smooth and reasonable adaptive adjustment is achieved, avoiding system fluctuations or instability caused by excessive adjustments. This further improves system stability and reliability, ensuring a more efficient and secure process for the reliable storage and management of commercial property information.

[0030] Furthermore, by comparing the latency jitter difference with a preset range and adjusting the compression ratio using different correction thresholds for different ranges, the system can dynamically optimize data transmission parameters based on the current network conditions. This dynamic adjustment mechanism effectively addresses the impact of network fluctuations on data transmission, ensuring data accuracy and integrity. Simultaneously, by proportionally increasing the compression ratio to the latency jitter difference, a smooth and reasonable adaptive adjustment is achieved, preventing system fluctuations or instability caused by excessive adjustments.

[0031] Furthermore, by comparing the calculated hash value length with the stored hash value length, it is possible to accurately determine whether the failure is due to data rollback or a mismatch in hash algorithm versions. This precise judgment method allows the system to take appropriate corrective measures for different problems, effectively resolving the current anomaly while preventing similar problems from recurring.

[0032] Furthermore, by statistically analyzing the number of rollbacks per unit time and adjusting the number of confirmation blocks using different correction thresholds based on varying rollback ranges, the system can dynamically optimize data confirmation parameters according to the severity of on-chain instability. This dynamic adjustment mechanism effectively reduces the risk of data invalidation due to rollbacks, improving the security of final data confirmation. Simultaneously, by proportionalizing the increase in the number of confirmation blocks to the number of rollbacks, flexible and appropriate parameter adjustments are achieved, avoiding blind adjustments and further enhancing the system's intelligent decision-making and adaptive capabilities. Attached Figure Description

[0033] Figure 1 This is a system module diagram of the blockchain-based trusted storage and management system for commercial housing information in this embodiment of the invention;

[0034] Figure 2 This is a flowchart illustrating the workflow of the blockchain-based trusted storage and management system for commercial housing information in this embodiment of the invention.

[0035] Figure 3 This is a flowchart illustrating how the cause of a matching failure is determined based on the percentage of matching failures in an embodiment of the present invention.

[0036] Figure 4 This is a flowchart illustrating the process of increasing the number of confirmation blocks based on the number of rollbacks in an embodiment of the present invention. Detailed Implementation

[0037] To make the objectives and advantages of the present invention clearer, the present invention will be further described below with reference to embodiments; it should be understood that the specific embodiments described herein are merely for explaining the present invention and are not intended to limit the present invention.

[0038] Preferred embodiments of the present invention will now be described with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are merely illustrative of the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0039] Please see Figure 1 The diagram shown is a system module diagram of a blockchain-based trusted storage and management system for commercial housing information in an embodiment of the present invention. The system of the blockchain-based trusted storage and management system for commercial housing information in this invention includes a data acquisition module, a preprocessing module, a hash processing module, an on-chain module, a calculation module, a management module, and a control module.

[0040] The data acquisition module is used to collect commercial property information data;

[0041] The preprocessing module is connected to the acquisition module and is used to preprocess the acquired commercial housing information data to obtain several preprocessed data items, including filtering invalid information in the commercial housing information data based on a minimum length threshold and adding timestamps. The minimum length threshold refers to the shortest length of the data field to be retained.

[0042] A pre-processing hash processing module, which is connected to the preprocessing module, is used to generate storage hash values ​​for each of the preprocessed data items based on a hash algorithm;

[0043] The pre-processing module is connected to the preprocessing module and the hash processing module. It is used to compress each preprocessed data item and its corresponding storage hash value, and upload it to the storage system and write it into the blockchain ledger after confirmation by the confirmation module.

[0044] The preprocessing calculation module, which is connected to the on-chain module, is used to output the hash value corresponding to each preprocessed data item as the calculated hash value, and the proportion of preprocessed data items that fail to match in the total number of preprocessed data items as the matching failure proportion.

[0045] The preprocessing management module is connected to the calculation module and the on-chain module. It is used to periodically match each calculated hash value with the corresponding stored hash value. When a matching failure is determined, the reason for the failure is determined based on the proportion of matching failures, and instructions to correct the preprocessing parameters, on-chain parameters and retransmission are issued based on the corresponding reasons.

[0046] The preprocessing control module is connected to the management module, the preprocessing module, and the on-chain module, and is used to correct the parameters of the corresponding module based on the correction instructions issued by the management module.

[0047] The commercial property information data includes, but is not limited to, property address, building area, housing type, floor information, property description and use, property status, market pricing information, property ownership registration documents, real estate ownership certificate or other proof of legal ownership, ownership change records, property owner identity information, identity documents, scanned copies or electronic files of signed lease contracts, sales contracts, etc., relevant authorization or entrustment documents, property photos, property videos, and precise labeling of collection time, etc., which will not be elaborated further.

[0048] The minimum length threshold F ∈ [10, 50 bytes] refers to the fact that commercial property listings typically include fields such as address, area, price, and contact information. The effective information in these fields is usually no less than 10 bytes. At the same time, each field in commercial property listings needs to have sufficient length to fully express its content. Setting it to 50 bytes ensures that most of the descriptive information is retained, while avoiding excessively long invalid information from occupying storage space. This helps to effectively improve data availability and system stability, and improve data quality.

[0049] When compressing the preprocessed data and its corresponding hash value, the compression ratio is not limited in principle. Technicians can set it to 50%-75% as needed to improve the transmission rate while ensuring that the data can be completely restored. This will not be elaborated further.

[0050] Please participate Figure 2 The diagram shown illustrates the workflow of a blockchain-based trusted storage and management system for commercial housing information in this invention. The workflow of this blockchain-based trusted storage and management system for commercial housing information includes:

[0051] S1: The collected commercial property information data;

[0052] S2: The preprocessing module preprocesses the collected commercial property information data to obtain several preprocessed data items;

[0053] S3: The hash processing module generates a storage hash value for each of the preprocessed data items based on a hash algorithm;

[0054] S4: The on-chain module compresses each of the preprocessed data items and their corresponding storage hash values, and uploads them to the storage system and writes them into the blockchain ledger after confirmation by the confirmation fast module;

[0055] S5: The hash value corresponding to each preprocessed data item output by the calculation module is denoted as the calculated hash value, and the proportion of preprocessed data items that fail to match is denoted as the proportion of failed matches in the total number of preprocessed data items.

[0056] S6: The management module periodically matches each calculated hash value with the corresponding stored hash value, and when a matching failure is determined, the reason for the failure is determined based on the proportion of matching failures, and instructions to correct preprocessing parameters, on-chain parameters and retransmission are issued based on the corresponding reasons.

[0057] S7: The control module corrects the parameters of the corresponding module based on the correction instructions issued by the management module and issues a notification.

[0058] Furthermore, the management module is used to periodically match each calculated hash value with the corresponding stored hash value, and when a match is found to be successful, maintain the system parameters and continue to determine whether the next preprocessed data item matches, or when a match is found to be unsuccessful, determine the reason for the unsuccessful match based on the proportion of unsuccessful matches.

[0059] The principle behind hash value matching for determining data errors lies in the determinism and uniqueness of hash functions. The same input data will always produce the same hash value, while even minor data changes can lead to completely different hash values. By recalculating the hash value of preprocessed data items and comparing it with the stored hash value on the blockchain, the correctness and integrity of the data can be verified. If the hash values ​​match, the data has not been tampered with; if they do not match, it indicates an error. In blockchain notarization, the hash value serves as a unique identifier for the data content, and any modifications can be quickly detected. By statistically analyzing the percentage of hash values ​​that fail to match, the system can also make automatic decisions, such as correcting parameters or re-uploading the data. Hash value matching is a simple, efficient, and secure integrity verification method that ensures the authenticity and reliability of notarized data and enhances the reliability and security of the system.

[0060] Specifically, the process by which the management module periodically matches each calculated hash value with its corresponding stored hash value includes:

[0061] The management module obtains the calculated hash value from the calculation module based on each of the preprocessed data items, and obtains the storage hash value of the corresponding preprocessed data item in the on-chain module;

[0062] Compare the calculated hash value with the stored hash value;

[0063] If the calculated hash value is equal to the stored hash value, the management module determines that the match is successful, maintains the system parameters, and continues to calculate whether the next preprocessed data item matches.

[0064] If the calculated hash value is not equal to the stored hash value, the management module determines that the match has failed, and the management module determines the reason for the match failure based on the proportion of match failures.

[0065] Furthermore, the management module is also used to determine the reason for the matching failure based on the matching failure ratio, and, when the matching failure ratio is less than or equal to the preset matching failure ratio, to determine the reason for the matching failure based on the hash value output of the commercial housing information data before and after preprocessing, or, when the matching failure ratio is greater than the preset matching failure ratio, to determine the reason for the failure based on the hash value length.

[0066] In a blockchain-based commercial housing information trusted storage system, the failure rate refers to the proportion of data that fails to match within the total data volume. When the failure rate is low, it indicates that there are relatively few preprocessed data items that fail to match. This may be due to anomalies in a single or small number of data items during the preprocessing stage, or anomalies in a small number of data items during transmission due to network or clock issues. By comparing the hash values ​​of the data before and after preprocessing, specific data anomalies can be located, and preprocessing parameters can be optimized. Conversely, when the failure rate is too high, it often means that the hash algorithm version may be incompatible, or that data rollback has occurred, causing anomalies in all related data. In this case, by checking whether the hash value length is consistent, non-compliant hash results can be quickly screened, and systemic failures and data anomalies can be located. This strategy uses the failure rate as a starting point to divide the investigation levels and scope, ensuring accurate diagnosis of individual data anomalies and rapid response to overall system anomalies, thus improving the stability and reliability of the system.

[0067] Please see Figure 3 As shown, this is a flowchart illustrating how to determine the cause of a matching failure based on the proportion of matching failures in an embodiment of the present invention. The process of determining the cause of a matching failure based on the proportion of matching failures includes:

[0068] The management module obtains the matching failure rate A from the calculation module and compares it with the preset matching failure rate A1. The preset matching failure rate A1 is set to [3, 8%]. This range ensures high data quality and system reliability while providing a certain degree of fault tolerance to cope with unforeseen situations such as network fluctuations and node failures. In practical applications, the fields of commercial housing information are usually no less than 10 bytes, and the diversity of network environments also requires the system to have a certain degree of adaptability. For example, in financial blockchain systems, a low error tolerance rate (such as 1% to 5%) is usually set. Although commercial housing information blockchain systems also require high stability and data quality, they have a larger fault tolerance margin. Therefore, the preset matching failure rate is set to a value range of 3% to 8%.

[0069] If the matching failure rate A is less than or equal to the preset matching failure rate A1, the management module determines the reason for the matching failure based on the hash value output by the commercial housing information data before and after preprocessing.

[0070] If the failure rate A is greater than the preset failure rate A1, the management module determines the reason for the failure based on the hash value length.

[0071] Furthermore, the management module is also used to determine the reason for the matching failure based on the hash value of the commercial housing information data output before and after preprocessing, and, when it is determined that the timestamp is abnormal, to determine the reason for the matching failure based on the absolute value of the difference between the evidence storage timestamp and the verification timestamp, or, when it is determined that the minimum length threshold is set unreasonably, to correct the minimum length threshold based on the ratio between the preset matching failure ratio and the matching failure ratio and retransmit the preprocessed data item that failed to match.

[0072] The management module determines the reason for matching failure based on the hash values ​​output by the commercial property information data before and after preprocessing. This allows for quick identification of the cause of the failure. By comparing the hash values ​​output by the commercial property information data before and after preprocessing, the invention can accurately pinpoint whether any anomalies have occurred in the preprocessing stage, ensuring the authenticity and integrity of the data uploaded to the blockchain. When the hash values ​​output by the data before and after preprocessing are consistent, it indicates that the current anomaly may be due to problems with the timestamps of some data items that incorporate timestamps into the hash values, causing a few preprocessed data items to fail to match. Conversely, when the hash values ​​output by the commercial property information data before and after preprocessing are inconsistent, it indicates that some important information was mistakenly filtered out during the data preprocessing process, thus affecting the data. Therefore, it is necessary to adjust the minimum length threshold in this case to avoid affecting the integrity of the information.

[0073] Specifically, the process by which the management module determines the reason for the matching failure based on the hash values ​​output from the commercial property information data before and after preprocessing includes:

[0074] The calculation module outputs a calculated hash value based on the commercial housing information data corresponding to the preprocessed data items that failed to match, and compares the calculated hash value with the calculated hash value output by the preprocessed data items.

[0075] If the calculated hash value of the commercial property information data output is consistent with the calculated hash value of the preprocessed data item output, it is determined that the timestamp is abnormal. The management module determines the reason for the matching failure based on the absolute value of the difference between the evidence storage timestamp and the verification timestamp.

[0076] If the calculated hash value of the commercial property information data output is inconsistent with the calculated hash value of the preprocessed data item output, it is determined that the minimum length threshold setting is unreasonable. The minimum length threshold is corrected based on the ratio between the preset matching failure rate and the matching failure rate. The management module corrects the minimum length threshold based on the ratio between the preset matching failure rate and the matching failure rate, and retransmits the preprocessed data item that failed to match.

[0077] Furthermore, the management module is also used to determine the matching failure ratio based on the ratio between the preset matching failure ratio and the matching failure ratio, and to reduce the minimum length threshold based on the matching failure ratio, wherein the reduction of the minimum length threshold is proportional to the matching failure ratio.

[0078] The failure rate ratio refers to the ratio between the actual failure rate and the preset failure rate. This ratio directly reflects the deviation between the severity of current data matching failures and the expected or set threshold. Dynamically adjusting the minimum length threshold based on this ratio, with the reduction in the minimum length threshold proportional to the ratio, is a flexible data filtering strategy designed to address the severity of data matching failures. A high failure rate ratio indicates that a significant amount of valid data is being incorrectly filtered due to an excessively high minimum length threshold, leading to hash matching failures. Appropriately lowering the minimum length threshold relaxes the filtering conditions, allowing shorter but valid data fields to enter subsequent processing. This reduces the loss of valid data, lowers the failure rate, and improves the overall availability and integrity of the system's data. Furthermore, proportionalizing the reduction in the minimum length threshold to the failure rate ratio achieves a smooth and reasonable parameter adjustment curve. This adjustment method avoids system instability caused by excessive parameter jumps, ensuring stable operation during dynamic adjustments. This design not only enhances the system's intelligent decision-making capabilities but also supports continuous optimization and self-correction, reducing human intervention and improving the system's robustness and ease of maintenance.

[0079] Specifically, the process by which the management module reduces the minimum length threshold based on the ratio of failed matches includes:

[0080] The management module determines the matching failure ratio B based on the ratio between the preset matching failure ratio and the actual matching failure ratio, and compares the matching failure ratio B with the set first preset matching failure ratio B1 and second preset matching failure ratio B2. The first preset matching failure ratio B1 is set to [1.1, 2.5] and the second preset matching failure ratio B2 is set to [2.5, 5]. In the above, the preset matching failure ratio is set to a range of 3%-8%. To ensure that the correction magnitude matches the actual deviation from the ideal, referring to blockchain application cases (financial field) and industry standards, the first preset matching failure ratio B1 is set to [1.1, 2.5] and the second preset matching failure ratio B2 is set to [2.5, 5], so as to ensure that the system can make reasonable and effective adjustments.

[0081] If the matching failure ratio B is less than or equal to the first preset matching failure ratio B1, then the management module uses a first minimum length correction threshold α1 to correct the minimum length threshold F, and the corrected minimum length threshold F' = Wherein, the first minimum length correction threshold α1 is set to 0.95;

[0082] If the failure rate B is greater than the first preset failure rate B1 and less than or equal to the second preset failure rate B2, then the management module uses a second minimum length correction threshold α2 to correct the minimum length threshold F. The corrected minimum length threshold F' = Wherein, the second minimum length correction threshold α2 is set to 0.89;

[0083] If the matching failure ratio B is greater than the second preset matching failure ratio B2, then the management module uses a third minimum length correction threshold α3 to correct the minimum length threshold F, and the corrected minimum length threshold F' = The third minimum length correction threshold α3 is set to 0.8.

[0084] Furthermore, the management module is also used to determine the absolute value of the timestamp difference based on the absolute value of the difference between the evidence storage timestamp and the verification timestamp, and to determine the reason for the matching failure based on the absolute value of the timestamp difference, and to issue a clock synchronization command when it is determined that the clock synchronization is abnormal, or to determine the correction method based on the minimum value of the difference between the timestamp of each matching failure data and the current timestamp when it is determined that the network is poor.

[0085] The absolute value of the timestamp difference refers to the absolute value of the difference between the evidence storage timestamp and the verification timestamp. The evidence storage timestamp represents the time when the data is uploaded to the blockchain or generated, while the verification timestamp is the time when the data is verified. Therefore, the absolute value of the timestamp difference reflects the time synchronization status or transmission delay. When the absolute value of the timestamp difference is small, it is often due to the server time not being fully synchronized or clock drift. Therefore, it is judged that the clock synchronization is abnormal. At this time, by calling the clock synchronization command, the clock drift can be corrected to ensure time consistency and effective data verification. When the absolute value of the timestamp difference is large, it may be due to poor network conditions causing data transmission delay or abnormality. In this case, it is necessary to further determine the correction method based on the time of the abnormality to obtain the best correction effect.

[0086] Specifically, the process by which the management module determines the reason for matching failure based on the absolute value of the timestamp difference includes:

[0087] The management module determines the absolute value of the timestamp difference T based on the absolute value of the difference between the evidence storage timestamp and the verification timestamp, and compares the absolute value of the timestamp difference T with the preset absolute value of the timestamp difference T1. The preset absolute value of the timestamp difference T1 is set to [1, 10s]. In actual applications, protocols such as NTP are usually used to achieve clock synchronization between different servers. However, due to the actual network conditions, clock drift may occur. But taking the NTP protocol as an example, its server time synchronization error can usually be controlled within 10 seconds. Therefore, the value range of the preset absolute value of the timestamp difference T1 is set to 1-10s.

[0088] If the absolute value of the timestamp difference T is less than or equal to the absolute value of the preset timestamp difference T1, the management module determines that the current clock synchronization is abnormal and issues a clock synchronization command.

[0089] If the absolute value of the timestamp difference T is greater than the absolute value of the preset timestamp difference T1, the management module determines that the network is not good, and the management module determines the correction method based on the minimum value of the difference between the timestamp of each failed matching data and the current timestamp.

[0090] Furthermore, the management module is also used to determine the failure timestamp difference based on the difference between the timestamp of each failed preprocessed data item and the current timestamp, and to determine the minimum failure timestamp difference based on the minimum of each failure timestamp difference, to determine the correction method based on the minimum failure timestamp difference, and, when it is determined that the current network fluctuation is a factor, to correct the compression ratio based on the difference between the current delay jitter and the preset delay jitter and to issue an instruction to retransmit the failed preprocessed data item, or to issue an instruction to retransmit the failed preprocessed data item.

[0091] The compression ratio refers to the ratio of the compressed data size to the original data size, and the delay jitter refers to the difference between the maximum transmission delay and the minimum delay.

[0092] When a data matching failure is determined to be due to network delays, since this system performs periodic verification, the preprocessed data item that failed to match may be a preprocessed data item currently being transmitted or a preprocessed data item transmitted previously. When the data item that failed to match is a data item currently being transmitted, in addition to retransmitting the data, the compression ratio of the transmitted data should also be optimized to reduce the impact of network fluctuations on the transmitted data. The minimum failure timestamp difference is the minimum value among all failure timestamp differences, which reflects the degree of timestamp deviation of the data item whose time is closest to the current system time among all the data items that failed to match, thus providing a basis for whether to correct the current network state.

[0093] Specifically, the process by which the management module determines the correction method based on the minimum failure timestamp difference includes:

[0094] The management module determines the failure timestamp difference based on the difference between the timestamp of each failed preprocessed data item and the current timestamp;

[0095] The management module determines the minimum failure timestamp difference MINC based on the minimum value among the failure timestamp differences, and compares the minimum failure timestamp difference MINC with the preset minimum failure timestamp difference MINC1. Setting the preset minimum failure timestamp difference MINC1∈(10, 60s] helps to judge the network status in the past minute based on the differentiation of clock synchronization problems, so as to better correct the network transmission situation.

[0096] If the minimum failure timestamp difference MINC is less than or equal to the preset minimum failure timestamp difference MINC1, the management module determines that the current network is fluctuating. The management module adjusts the compression ratio based on the difference between the current latency jitter and the preset latency jitter and issues an instruction to retransmit the matching failed data.

[0097] If the minimum failure timestamp difference MINC is less than or equal to the preset minimum failure timestamp difference MINC1, the management module issues an instruction to retransmit the matching failed data.

[0098] Furthermore, the management module is also used to determine a delay jitter difference based on the difference between the current delay jitter and the preset delay jitter, and to increase the compression ratio based on the delay jitter difference, wherein the increase in the compression ratio is proportional to the delay jitter difference.

[0099] Latency jitter is defined as the difference between the maximum and minimum transmission delay of the network. The latency jitter difference refers to the difference between the current latency jitter and the preset latency jitter. The latency jitter difference reflects the difference between the currently monitored latency jitter and the system's preset reference latency jitter. A large difference indicates that the network jitter is obvious and has a more serious impact, requiring more significant adjustments to deal with it. A small difference indicates that the network fluctuation is relatively slight, and the corresponding adjustment range is naturally smaller, avoiding unnecessary adjustments that would burden the system. Making the adjustment range proportional to the difference is conducive to achieving smooth and reasonable adaptive adjustment, and avoiding system fluctuations or instability caused by excessive adjustments.

[0100] Specifically, the process by which the management module increases the compression ratio based on the latency jitter difference includes:

[0101] The management module determines the delay jitter difference D based on the difference between the current delay jitter and the preset delay jitter, and compares the delay jitter difference D with the first preset delay jitter difference D1 and the second preset delay jitter difference D2. The first preset delay jitter difference D1 is set to [50, 100ms], and the second preset delay jitter difference D2 is set to (100, 140ms]. In most normal network environments, delay jitter (i.e., the difference between the maximum and minimum transmission delay) is usually within 50 milliseconds. When the delay jitter exceeds 50 milliseconds but is less than or equal to 100 milliseconds, it indicates significant fluctuations in the network environment. When the delay jitter is greater than 140 milliseconds, it indicates severe network fluctuations, requiring a higher compression ratio to ensure data transmission. Therefore, the first preset delay jitter difference D1 is set to [50, 100ms], and the second preset delay jitter difference D2 is set to (100, 140ms].

[0102] If the delay jitter difference D is less than or equal to the first preset delay jitter difference D1, the management module uses the first compression ratio correction threshold β1 to correct the compression ratio Z, and the corrected compression ratio Z' = Z × β1, wherein the first compression ratio correction threshold β1 is set to 1.02.

[0103] If the delay jitter difference D is greater than the first preset delay jitter difference D1 and less than or equal to the second preset delay jitter difference D2, then the management module uses the second compression ratio correction threshold β2 to correct the compression ratio Z, and the corrected compression ratio Z' = Z × β2, wherein the second compression ratio correction threshold β2 is set to 1.05;

[0104] If the delay jitter difference D is greater than the second preset delay jitter difference D2, the management module uses the third compression ratio correction threshold β3 to correct the compression ratio Z. The corrected compression ratio Z' = Z × β3, where the third compression ratio correction threshold β3 is set to 1.11.

[0105] Furthermore, the management module is also used to determine the cause of failure based on the calculated hash value length, and when it is determined to be a data rollback, to adjust the number of confirmation blocks based on the number of rollbacks per unit time and retransmit the preprocessed data items that failed to match, or to issue a hash algorithm version mismatch notification.

[0106] The hash value length is deterministic. Common hash algorithms (such as MD5, SHA-1, SHA-256, SHA-3) output hash values ​​of fixed length. If the hash value length does not match when the actual match fails, it means that there may be a difference between the algorithm used to calculate the hash value when it was added to the chain and the current algorithm used to calculate the hash value. Therefore, a hash algorithm version mismatch notification is output in this case. However, if a lot of data still cannot be matched even when the hash algorithm version matches, it may be that a data rollback has occurred, causing all related data to be abnormal. In this case, it is necessary to adjust the number of confirmation blocks to reduce the occurrence of data rollback.

[0107] Specifically, the process by which the management module determines the cause of failure based on the hash value length includes:

[0108] The management module obtains the length of the corresponding hash value calculated by the calculation module and the length of the corresponding data hash value in the on-chain module, and compares them. In principle, the length of the hash value is not limited. Technical personnel can set the length of the hash value according to the hash algorithm used. For example, the length of the MD5 hash value is 16 bytes, the length of the SHA-1 hash value is 20 bytes, and the length of the SHA-256 hash value is 32 bytes, etc., which will not be elaborated here.

[0109] If the length of the corresponding data hash value calculated by the calculation module is equal to the length of the corresponding data hash value of the on-chain module, the management module determines that the data should be rolled back. The management module adjusts the number of confirmation blocks based on the number of rollbacks per unit time and retransmits the preprocessed data items that failed to match.

[0110] If the length of the corresponding data hash value calculated by the calculation module is not equal to the length of the corresponding data hash value of the on-chain module, the management module determines that the hash algorithm version is mismatched and issues a hash algorithm version mismatch notification.

[0111] Furthermore, the management module is also used to determine the number of rollbacks based on the number of rollbacks per unit time, and to increase the number of confirmation blocks based on the number of rollbacks, wherein the increase in the number of confirmation blocks is proportional to the number of rollbacks.

[0112] Blockchain rollback refers to the phenomenon where some blocks on the chain are revoked due to chain forks or other reasons. The rollback count refers to the number of times a blockchain rollback occurs within a unit of time. By statistically analyzing the number of block rollbacks within a unit of time, the severity of on-chain instability can be quantified. Increasing the number of confirmation blocks based on the rollback count, and ensuring that the increase in the number of confirmation blocks is proportional to the number of rollbacks, helps to improve the security of final data confirmation by dynamically adjusting the number of confirmation blocks, reducing the risk of data invalidity caused by rollbacks. The proportionality between the increase in the number of confirmation blocks and the number of rollbacks ensures the flexibility and appropriateness of parameter adjustments, avoiding blind adjustments. This mechanism reflects the system's intelligent feedback control capability, enabling the evidence storage system to automatically optimize parameter configurations based on the on-chain status, thereby enhancing the security and credibility of evidence storage, and improving the overall robustness and business continuity of the system.

[0113] Please see Figure 4 As shown, this is a flowchart illustrating the process of increasing the number of confirmation blocks based on the number of rollbacks in an embodiment of the present invention. The process of increasing the number of confirmation blocks based on the number of rollbacks in an embodiment of the present invention includes:

[0114] The management module determines the rollback count N based on the number of rollbacks per unit time, and compares the rollback count N with the set first preset rollback count N1 and second preset rollback count N2. The first preset rollback count N1 is set to [2, 4], and the second preset rollback count N2 is set to [4, 6]. The unit time length is set to [15, 30 days]. Under normal user operation, the system rarely rolls back. However, the storage and verification of commercial housing information usually involves multiple nodes and multiple users, so rollbacks are inevitable. Therefore, the value range of the first preset rollback count N1 is set to 2-4 times, and the value range of the second preset rollback count N2 is set to 4-6 times, so as to better provide a correction standard for the current rollback situation in the system.

[0115] If the number of rollbacks N is less than or equal to the first preset number of rollbacks N1, then the management module uses the first confirmation block correction threshold θ1 to correct the number of confirmation blocks Q, and the corrected number of confirmation blocks Q' = The first confirmation block correction threshold θ1 is set to 1.05.

[0116] If the number of rollbacks N is greater than the first preset rollback number N1 and less than or equal to the second preset rollback number N2, then the management module uses the second confirmation block correction threshold θ2 to correct the number of confirmation blocks Q, and the corrected number of confirmation blocks Q' = The second confirmation block correction threshold θ2 is set to 1.12.

[0117] If the number of rollbacks N is greater than the second preset number of rollbacks N2, then the management module uses the third confirmation block correction threshold θ3 to correct the number of confirmation blocks Q, and the corrected number of confirmation blocks Q' = The third confirmation block correction threshold θ3 is set to 1.2.

[0118] In summary, the blockchain-based trusted storage and management system for commercial housing information of this invention ensures the authenticity and immutability of housing information through blockchain technology. It also employs a dynamic parameter adjustment mechanism, such as dynamically adjusting the minimum length threshold based on the proportion of failed matches and adjusting the compression ratio based on latency jitter differences, effectively improving data quality and system stability. The system can automatically detect data anomalies and accurately pinpoint the causes, such as judging data integrity through hash value matching and determining algorithm version compatibility based on hash value length, thereby achieving automatic correction, improving data management efficiency, and reducing maintenance costs. These innovations not only enhance user trust in housing information but also improve user experience, making the system more competitive in the real estate transaction market and providing strong guarantees for efficient and secure real estate transactions.

[0119] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

Claims

1. A blockchain-based commercial housing source information credible storage and management system, characterized in that, include, The data acquisition module is used to collect commercial property information data; A preprocessing module, connected to the acquisition module, is used to preprocess the acquired commercial property information data to obtain several preprocessed data items. This includes filtering invalid information in commercial property listings based on a minimum length threshold and adding timestamps. The minimum length threshold refers to the shortest length of the data field to be retained. A hash processing module, which is connected to the preprocessing module, is used to generate storage hash values ​​for each of the preprocessed data items based on a hash algorithm. The on-chain module, which is connected to the preprocessing module and the hash processing module, is used to compress each preprocessed data item and its corresponding storage hash value, and upload it to the storage system and write it into the blockchain ledger after confirmation by the confirmation block. The calculation module, which is connected to the on-chain module, is used to output the hash value corresponding to each preprocessed data item as the calculated hash value, and the proportion of preprocessed data items that fail to match in the total number of preprocessed data items as the failure matching proportion. The management module, which is connected to the computing module and the on-chain module, is used to periodically match each of the computing hash values ​​with the corresponding storage hash values, and, when a matching failure is determined, to determine the reason for the failure based on the proportion of matching failures, and to issue instructions to correct the preprocessing parameters, on-chain parameters and retransmission based on the corresponding reason. The control module, which is connected to the management module, the preprocessing module and the on-chain module, is used to correct the parameters of the corresponding module based on the correction instructions issued by the management module and issue a notification.

2. The trusted recordal and management system according to claim 1, wherein, The management module is used to periodically match each calculated hash value with the corresponding stored hash value, and, when a match is successful, maintain the system parameters and continue to determine whether the next preprocessed data item matches, or, when a match fails, determine the reason for the match failure based on the proportion of match failures.

3. The trusted recordal and management system according to claim 2, wherein, The management module is also used to determine the reason for the matching failure based on the matching failure ratio, and, when the matching failure ratio is less than or equal to the preset matching failure ratio, to determine the reason for the matching failure based on the hash value output of the commercial housing information data before and after preprocessing, or, when the matching failure ratio is greater than the preset matching failure ratio, to determine the reason for the failure based on the hash value length.

4. The trusted recordal and management system according to claim 3, wherein, The management module is also used to determine the reason for the matching failure based on the hash value of the commercial housing information data output before and after preprocessing, and, when it is determined that the timestamp is abnormal, to determine the reason for the matching failure based on the absolute value of the difference between the evidence storage timestamp and the verification timestamp, or, when it is determined that the minimum length threshold is set unreasonably, to correct the minimum length threshold based on the ratio between the preset matching failure ratio and the matching failure ratio and retransmit the preprocessed data item that failed to match.

5. The trusted evidence storage and management system according to claim 4, characterized in that, The management module is also used to determine the matching failure ratio based on the ratio between the preset matching failure ratio and the matching failure ratio, and to reduce the minimum length threshold based on the matching failure ratio, wherein the reduction of the minimum length threshold is proportional to the matching failure ratio.

6. The trusted evidence storage and management system according to claim 4, characterized in that, The management module is also used to determine the absolute value of the timestamp difference based on the absolute value of the difference between the evidence storage timestamp and the verification timestamp, and to determine the reason for the matching failure based on the absolute value of the timestamp difference, and to issue a clock synchronization command when it is determined that the clock synchronization is abnormal, or to determine the correction method based on the minimum value of the difference between the timestamp of each matching failure data and the current timestamp when it is determined that the network is poor.

7. The trusted evidence storage and management system according to claim 6, characterized in that, The management module is also used to determine the failure timestamp difference based on the difference between the timestamp of each failed preprocessed data item and the current timestamp, and to determine the minimum failure timestamp difference based on the minimum of the failure timestamp differences, to determine the correction method based on the minimum failure timestamp difference, and, when it is determined that the current network fluctuation is a factor, to correct the compression ratio based on the difference between the current delay jitter and the preset delay jitter and to issue an instruction to retransmit the failed preprocessed data item, or to issue an instruction to retransmit the failed preprocessed data item. The compression ratio refers to the ratio of the compressed data size to the original data size, and the delay jitter refers to the difference between the maximum transmission delay and the minimum delay.

8. The trusted evidence storage and management system according to claim 7, characterized in that, The management module is also used to determine the delay jitter difference based on the difference between the current delay jitter and the preset delay jitter, and to increase the compression ratio based on the delay jitter difference, wherein the increase in the compression ratio is proportional to the delay jitter difference.

9. The trusted evidence storage and management system according to claim 3, characterized in that, The management module is also used to calculate the hash value length to determine the reason for failure, and, when it is determined to be a data rollback, to adjust the number of confirmation blocks based on the number of rollbacks per unit time and retransmit the preprocessed data items that failed to match, or to issue a hash algorithm version mismatch notification.

10. The trusted evidence storage and management system according to claim 9, characterized in that, The management module is also used to determine the number of rollbacks based on the number of rollbacks per unit time, and to increase the number of confirmation blocks based on the number of rollbacks, wherein the increase in the number of confirmation blocks is proportional to the number of rollbacks.

Images