Block chain-based building information sharing method, apparatus and device, and medium

Abstract

The invention discloses a building information sharing method based on a block chain, and the method comprises the steps: receiving building basic information from a plurality of data sources, and carrying out the formatting processing of the building basic information; performing digital signature operation on the formatted building basic information by adopting an asymmetric encryption algorithm; broadcasting the signed data packet to all related nodes in the block chain network, so that the nodes verify the data packet by adopting a consensus mechanism, and storing the verified data packet and the corresponding hash value into a new block; when a data updating request is received, performing identity permission verification on a requester by adopting a multi-factor authentication mode, updating the data based on a preset service rule after the verification is passed, and pushing an updating notification to a related service party after the updating is completed; according to the method, the data quality and the service reliability are remarkably improved, and a high-quality, standardized and credible data source is provided for the whole real estate registration system based on the block chain.

Description

Technical Field

[0001] This invention relates to the field of data sharing technology, and in particular to a blockchain-based method, apparatus, equipment, and medium for sharing building information. Background Technology

[0002] In the field of real estate registration, the building registration table serves as the core carrier for integrating physical information, ownership information, and transaction information of houses. It is the basic data support for carrying out business such as ownership identification, tax accounting, and financial credit. With the advancement of "Internet and government services", the sources of real estate registration data are becoming increasingly diverse, covering multiple departments such as housing and construction, planning, taxation, and finance. However, the problem of inconsistent data formats and significant differences in semantic standards among multiple departments poses a severe challenge to the construction and sharing of building registration tables.

[0003] Currently, while blockchain-based real estate registration systems can solve the problems of data tampering and trusted sharing, they have significant shortcomings in data processing: First, multi-source data is heterogeneous, with chaotic data formats and semantic ambiguities across departments, easily leading to format conflicts and consensus disagreements, making it difficult to provide a unified foundation for building property registers; second, poor data quality affects the accuracy of property registers and business security; and third, the lack of data validity verification means that structural problems can easily lead to consensus failures and contract anomalies, reducing system efficiency. As business demands for data increase, traditional models can no longer meet the blockchain's need for high-quality data. Therefore, there is an urgent need to build a property register construction and sharing solution that combines standardization, security, trustworthiness, and collaboration to overcome existing technological bottlenecks. Summary of the Invention

[0004] This invention provides a blockchain-based method for sharing property information, which can significantly improve data quality and business reliability, and provide a high-quality, standardized, and reliable data source for the entire blockchain-based real estate registration system.

[0005] In a first aspect, embodiments of the present invention provide a blockchain-based method for sharing property information, comprising: Receive basic building information from multiple data sources and format the basic building information; wherein, the basic building information includes, but is not limited to, project name, location, name of construction unit, start date and completion date; Asymmetric encryption algorithm is used to digitally sign the formatted basic information of the building. The signed data packet is broadcast to all relevant nodes in the blockchain network, so that the nodes can verify the data packet using a consensus mechanism and store the verified data packet and its corresponding hash value into a new block; When a data update request is received, a multi-factor authentication method is used to verify the identity and permissions of the requester. After the verification is successful, the data is updated based on preset business rules, and an update notification is pushed to the relevant business parties after the update is completed. The multi-factor authentication includes a combination of at least two of the following: biometric recognition, hardware token, and SMS verification code.

[0006] Furthermore, the formatting of the basic information of the building includes: Parse the received basic information about the properties and handle missing values ​​and outliers. The fields of the corrected data are mapped to standard fields using pre-configured mapping rules; the mapping rules are used to specify the correspondence between the data fields to be mapped and the standard fields in the data dictionary; Based on the pre-designed JSON Schema definition, the standard fields are filled in according to the correct hierarchical relationship to obtain a JSON object that conforms to the Schema specification; The JSON Schema validator is invoked to compare and validate the generated JSON object against the JSON Schema definition. Data that passes validation is retained, while data that fails validation is returned and an error log is logged.

[0007] Furthermore, the step of digitally signing the formatted building information using an asymmetric encryption algorithm includes: The formatted basic information of the building is input into a hash function for calculation, and the hash value is output. The hash value is encrypted using an asymmetric encryption algorithm to generate a digital signature; The formatted basic information of the building, digital signature, signer certificate, encryption algorithm identifier and timestamp are packaged to obtain the signed data packet.

[0008] Furthermore, broadcasting the signed data packet to all relevant nodes in the blockchain network, so that the nodes can verify the data packet using a consensus mechanism, and storing the verified data packet and its corresponding hash value in a new block, includes: The signed data packet is broadcast to all relevant nodes in the blockchain network so that the master node in the current network can verify the validity of the data packet and generate a Pre-Prepare message after the verification is successful. The Pre-Prepare message is then broadcast to all backup nodes. The backup node verifies the Pre-Prepare message, and broadcasts the Prepare message to the entire network upon successful verification. For any node in the network, when it collects Prepare messages from 2f other different nodes, it generates a Prepare certificate and broadcasts a Commit message to the entire network. When it collects Commit messages from 2f other different nodes, it generates a Commit certificate and stores the signed data packet and its corresponding hash value in a new block. Here, f is the maximum number of malicious nodes that the network can tolerate. After the storage operation is completed, a success message is sent to the client of the corresponding data source. When the client receives f+1 success messages from different nodes, it confirms that the signed data packet has been successfully stored in the blockchain.

[0009] Furthermore, the preset business rules include, but are not limited to, field-level permission control rules, mandatory change description rules, major modification secondary confirmation rules, change range thresholds, and manual review rules; The field-level permission control rule is used to verify whether the field to be updated in the data update request has update permission. If not, the data update request is rejected. The mandatory change description rule is used to verify whether the data update request contains a reason for the change. If not, the data update request is rejected. The major modification secondary confirmation rule is used to confirm whether the data update request is an update request that requires approval. If it is, the approval process is automatically triggered. The change magnitude threshold and manual review rules are used to calculate the change magnitude of key fields in the data update request relative to the original data, and automatically trigger the manual review process when the change magnitude exceeds the preset change magnitude threshold.

[0010] Furthermore, the method also includes: After the data update is completed, the updated data, along with the transaction hash, timestamp, operator identity, and update reason, will be recorded as a new data version. The data version before the update will be marked as a historical version and stored in the historical database.

[0011] Furthermore, the method also includes: Periodically and randomly select a number of real estate registration data records; For each data record, the hash value is recalculated using the same hash algorithm as when the data record was uploaded to the blockchain. The calculated hash value is then compared with the hash value stored in the blockchain. A verification report is generated based on the comparison results, and an alarm message is generated when the comparison results are inconsistent.

[0012] Secondly, embodiments of the present invention provide a blockchain-based property information sharing device, comprising: The data preprocessing module is used to receive basic building information from multiple data sources and format the basic building information; wherein, the basic building information includes, but is not limited to, project name, location, name of construction unit, start date and completion date; The data encryption module is used to perform digital signature operations on the formatted basic information of the building using an asymmetric encryption algorithm. The data storage module is used to broadcast the signed data packet to all relevant nodes in the blockchain network, so that the nodes can verify the data packet using a consensus mechanism and store the verified data packet and its corresponding hash value into a new block; The data update module is used to verify the identity and permissions of the requester by using a multi-factor authentication method when a data update request is received. After the verification is successful, the data is updated based on preset business rules, and an update notification is pushed to the relevant business parties after the update is completed. The multi-factor authentication includes at least two of the following: biometric recognition, hardware token and SMS verification code.

[0013] Thirdly, embodiments of the present invention provide an electronic device, comprising: Memory, used to store computer programs; A processor for executing the computer program; Wherein, when the processor executes the computer program, it implements the blockchain-based property information sharing method described in any of the first aspects above.

[0014] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, which, when executed, implements the blockchain-based property information sharing method described in any of the first aspects above.

[0015] Compared with existing technologies, the blockchain-based property information sharing method provided in this invention has the following advantages: It receives basic property information from multiple data sources and formats the information; the basic property information includes, but is not limited to, project name, location, construction unit name, commencement date, and completion date; it uses an asymmetric encryption algorithm to digitally sign the formatted basic property information; it broadcasts the signed data packet to all relevant nodes in the blockchain network, enabling the nodes to verify the data packet using a consensus mechanism and store the verified data packet and its corresponding hash value in a new block; when a data update request is received, it uses multi-factor authentication to verify the requester's identity and permissions, updates the data based on preset business rules after successful verification, and pushes an update notification to relevant business parties after the update is completed; this invention can significantly improve data quality and business reliability, providing a high-quality, standardized, and reliable data source for the entire blockchain-based real estate registration system. Attached Figure Description

[0016] To more clearly illustrate the technical features of the embodiments of the present invention, the drawings used in the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating a blockchain-based method for sharing property information, as provided in an embodiment of the present invention. Figure 2 This is a schematic diagram of the structure of a blockchain-based building information sharing device provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

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

[0019] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein is for the purpose of describing embodiments of the invention only and is not intended to limit the invention.

[0021] In a first aspect, embodiments of the present invention provide a blockchain-based method for sharing property information, see [link to relevant documentation]. Figure 1 This is a flowchart illustrating an embodiment of a blockchain-based method for sharing property information provided by the present invention.

[0022] like Figure 1 As shown, the method includes the following steps: S1: Receive basic building information from multiple data sources and format the basic building information; wherein, the basic building information includes, but is not limited to, project name, location, name of construction unit, start date and completion date; S2: Use an asymmetric encryption algorithm to digitally sign the formatted basic information of the building; S3: Broadcast the signed data packet to all relevant nodes in the blockchain network so that the nodes can verify the data packet using a consensus mechanism and store the verified data packet and its corresponding hash value into a new block; S4: When a data update request is received, the requester's identity and permissions are verified using a multi-factor authentication method. After successful verification, the data is updated based on preset business rules, and an update notification is pushed to the relevant business parties after the update is completed. The multi-factor authentication includes a combination of at least two of the following: biometric recognition, hardware token, and SMS verification code.

[0023] In practice, basic building information from multiple data sources is received, formatted, and a unified standard data structure is generated. This basic building information includes, but is not limited to, project name, location, construction unit name, start date, and completion date. An asymmetric encryption algorithm is used to digitally sign the formatted basic building information, generating a signed data packet. The asymmetric encryption algorithm can be one of RSA, ECC, or SM2. The signed data packet is broadcast to all relevant nodes in the blockchain network, including data source nodes, business processing nodes, and regulatory nodes. The nodes use a consensus mechanism to verify the data packet and store the verified data packet and its corresponding hash value in a new blockchain block. The new block is associated with the previous block through the hash value, forming an immutable chain storage structure.

[0024] When a node in the blockchain network (usually a regulatory node or an authorized service node) receives a data update request, the processing flow immediately begins. This request is not a simple data packet, but a structured set of instructions, including the target data identifier (a unique identifier used to explicitly specify the real estate registration record to be updated, such as a key or unique hash value on the blockchain), the update operation content (the specific fields to be modified and their new values, for example, changing the "completion date" from "2023-09-28" to "2024-01-15"), a statement of the reason for the change (a text that requires the requester to explain the reason for the change, such as "the construction period was delayed due to the epidemic, and the completion was postponed with approval"), and the requester's identity credentials (evidence used to verify identity and permissions later).

[0025] The receiving node first needs to confirm "who initiated the request" and "whether they have the authority to initiate this request." Specifically, it uses multi-factor authentication (MFA) to verify the requester's identity and permissions. MFA is a method that verifies a user's identity by requiring two or more different types of authentication credentials, including at least two of biometric identification, hardware tokens, and SMS verification codes. This greatly enhances security and effectively prevents unauthorized access due to the theft of a single credential (such as a password only). The verification process is completed in a separate authentication service module, and the specific process is as follows: The first factor is the knowledge factor. The requester must first provide their account and password. The system verifies whether the account and password are correct. This factor is the basis for all subsequent verifications. The second factor: the possession factor or inheritance factor. After password verification, the system will require the requester to provide a second, completely different type of credential. Depending on the configuration and security level requirements, this credential must be a combination of at least two of the following: 1. Hardware Token (Possession Factor): The requester uses a dedicated physical device, such as a USB key or smart card. When the system issues a challenge command, the user needs to press the button on the token or insert it into the card reader to generate a one-time, dynamically changing verification code (Time-based One-Time Password, TOTP). The user enters this verification code into the system to complete the verification. This method is extremely secure because physical tokens are difficult to copy remotely. 2. SMS verification code (Possession Factor): The system sends an SMS containing a one-time verification code to the requester's pre-bound and verified mobile phone number. The requester needs to enter the verification code on the client. This method utilizes the physical possession of the "mobile phone SIM card", but its security is slightly lower than that of hardware tokens. The risk of SIM card hijacking needs to be prevented. 3. Biometric Recognition (Inherence Factor): The requester submits their biometric features through a device (such as a mobile phone, computer camera, or fingerprint sensor). The system compares these features with pre-stored biometric templates. Common methods include: fingerprint recognition (comparing fingerprint image features), facial recognition (capturing facial images through a camera and performing liveness detection and feature comparison with archived photos), and iris / voiceprint recognition (higher security, suitable for specific high-security scenarios). The advantage of this factor is that biometric features are closely bound to the user and are extremely difficult to forge or lose.

[0026] The requesting party submits the selected credentials sequentially. The authentication service verifies the validity of each credential item. Only when all required credentials are verified successfully is the entire MFA process considered successful. At this point, the system not only confirms the user's identity, but the successful authentication record itself also serves as strong proof of the legitimacy of this operation request. After identity verification, the system queries the user's role in the system based on the user's identity identifier (such as the OU field in the digital certificate or the username). The system has a pre-configured Role-Based Access Control (RBAC) model, and each role is assigned a series of specific operation permissions (for example, the "Municipal Housing and Construction Bureau Administrator" role may have the permission to "modify all fields"). Permissions (for example, a "developer user" role might only have the permission to "modify the completion date of their own project"). The system matches the current request's operation type (modification) and target field with the requester's role's permission list to determine if they have the permission to execute the update. If the requester is legitimate and has the permission, the data is updated based on preset business rules. When the data update transaction is successfully written to the blockchain and consensus is reached, the update push process is triggered. The notification is not simply announcing that the data has changed, but a structured message containing enough information for the receiving system to perform subsequent processing independently. A typical notification message (Payload) contains the following core elements: Event Type: Clearly identifies the nature of this notification, such as REAL_ESTATE_UPDATE, DATA_INVALIDATE, etc. Unique identifier for target data: The unique identifier (such as Key) or its hash value recorded on the blockchain in the updated property list, which allows the recipient to accurately locate the data; Change summary: Clearly describe which fields have changed and their old and new values; Blockchain transaction certificate: The transaction hash and block height that generated this update are the immutable "birth certificate" of this change. The receiving system can use this information to query the blockchain explorer to obtain more detailed transaction details and perform secondary verification. Timestamp: The exact time when the data change occurred; The hash value of the new version data: the receiver can use it to verify whether the data it pulled is complete and correct.

[0027] It should be noted that the methods for pushing update notifications to related business systems include message queue (MQ), RESTful API calls, or WebSocket pushes. The appropriate method can be chosen based on actual needs.

[0028] Specifically, the Message Queue (MQ) approach is an asynchronous, decoupled communication model. The sender (notification push system) and the receiver (business system) do not communicate directly, but rather through a message broker. The push system uses middleware components (such as RabbitMQ, Kafka, and RocketMQ) as intermediaries to relay messages. Once the push system publishes the constructed notification message to the specified message topic or queue, the task is considered complete, and there is no need to wait for the receiver to process it. Each business system, as a consumer, subscribes to relevant topics according to its own needs. The message broker is responsible for reliably distributing messages to all subscribers. The process is as follows: The push system establishes a connection with the message broker and publishes the structured notification message to the preset topic "Real Estate Data Update". The message broker receives the message and persists it to ensure that the message is not lost due to system restart. Related business systems such as the tax system, bank credit system, and housing provident fund management system, as independent consumers, have already subscribed to this topic. The message broker actively pushes the message to (or the consumer pulls it to) all online subscribers. After receiving the message, each business system parses and processes it, such as triggering internal database updates or generating pending tasks.

[0029] RESTful API calls are a synchronous request-response model. The push system acts as an HTTP client, actively calling the API endpoint provided by the business system for receiving notifications. The process is as follows: The push system constructs the notification message and uses it as the payload (body) of an HTTP POST request, usually encoded in JSON format. The push system initiates an HTTPS call to the API URL of the target business system. The business system's API interface service receives the request, performs authentication (usually through API keys, digital signatures, etc.), parses parameters, processes logic (such as updating the local cache), and immediately returns an HTTP response status code (e.g., 200 OK for success, 5xx for errors). The push system decides whether to log or trigger a retry mechanism based on the response status code.

[0030] WebSocket push is a full-duplex, low-latency real-time communication protocol that operates over a single TCP connection. It is suitable for high real-time scenarios where the server needs to actively push data to the client. The process is as follows: When the business system (as a WebSocket client) starts up, it establishes a persistent network connection with the push system (as a WebSocket server) and performs authentication. After the connection is established, the two parties can send and receive messages through the connection. Once a data update event occurs, the push server immediately "pushes" the notification message to the connected client through the established WebSocket connection. After receiving the message, the business system client processes it in real time and updates the front-end interface or internal state without repeated polling.

[0031] In summary, this invention receives and formats basic property information from multiple data sources, effectively resolving the format chaos and semantic ambiguity issues caused by heterogeneous multi-source data. It establishes a unified and standardized data foundation for property data tables, significantly improving data consistency and availability, avoiding processing errors caused by data incompatibility, and ensuring that subsequent business processes can proceed smoothly based on accurate and reliable data. Regarding data security, an asymmetric encryption algorithm is used to digitally sign the formatted data, making the data non-repudiable during transmission and storage. Any tampering will result in signature verification failure, effectively preventing malicious modification of the data and ensuring its authenticity and integrity. Simultaneously, the signed data packet is broadcast to the blockchain network and processed by the consensus mechanism. After verification, the data is stored in a new block. Leveraging the distributed ledger characteristics of blockchain, data is difficult to tamper with once it is on the chain, and the chain structure of each block provides a complete traceability path for the data, adding a solid defense to data security. When a data update request is received, a multi-factor authentication method, including at least two combinations of biometric recognition, hardware tokens, and SMS verification codes, is used to verify the identity and permissions of the requester. This multi-dimensional and high-strength authentication mechanism effectively prevents unauthorized users from forging identities to tamper with data, ensuring the credibility of the data update subject from the source and reducing the risk of internal violations and external attacks. This invention significantly improves data quality and business reliability, providing a high-quality, standardized, and reliable data source for the entire blockchain-based real estate registration system.

[0032] In one optional implementation, the formatting of the building's basic information includes: Parse the received basic information about the properties and handle missing values ​​and outliers. The fields of the corrected data are mapped to standard fields using pre-configured mapping rules; the mapping rules are used to specify the correspondence between the data fields to be mapped and the standard fields in the data dictionary; Based on the pre-designed JSON Schema definition, the standard fields are filled in according to the correct hierarchical relationship to obtain a JSON object that conforms to the Schema specification; The JSON Schema validator is invoked to compare and validate the generated JSON object against the JSON Schema definition. Data that passes validation is retained, while data that fails validation is returned and an error log is logged.

[0033] Specifically, raw data is received from various data sources through pre-configured data interfaces (such as RESTful APIs, FTP clients, or database connectors). This raw data may exist in various forms, such as table records in relational databases (such as SQL query results), CSV / Excel files, XML documents, or JSON objects. The received data is initially parsed, extracting it from its original storage format that depends on a specific system or software, and converting it in memory into a neutral data structure that is easier for the program to process (such as dictionaries, key-value pair collections, or temporary objects) to prepare for subsequent deep cleaning and formatting.

[0034] During the data cleaning process, the system checks for missing values ​​in the data. For missing non-critical fields, it handles them according to the characteristics of the data and business rules, such as setting them to null, filling them with default values ​​(e.g., an unknown completion date can be temporarily set to a distant future date), or triggering a manual completion process. It detects and corrects outliers through a predefined rule base or simple algorithms. For example, it checks whether the "completion date" is earlier than the "start date" or whether the building area is negative. After an outlier is found, it can be automatically corrected or marked according to a trusted data source.

[0035] The data cleaning process, which addresses missing values, formatting issues, unit errors, code errors, and outliers, significantly reduces the risk of junk data entering the blockchain. This makes the real estate registration building list built based on the data more accurate and reliable, directly improving the accuracy and reliability of subsequent business processes such as tax calculation, ownership determination, and financial lending. It also reduces business risks and disputes caused by data errors, significantly improving data quality and business reliability.

[0036] Furthermore, a mapping rule is pre-configured to specify the correspondence between a field in the source data and a standard field in the data dictionary. The cleaned source data fields are then filled into the standard fields one by one, thereby eliminating semantic ambiguity and achieving true alignment.

[0037] Based on a pre-designed JSON Schema definition, aligned standard fields are filled in according to the correct hierarchical relationship to obtain a JSON object that conforms to the schema specification. The JSON Schema itself is a JSON object, acting as a data template or data contract. It clearly defines the structure that the final output data JSON object must follow, including the name, data type, format requirements, and whether each field in the object is required. For complex fields, such as "location", it is also an object, which contains subfields such as "province", "city", "district", and "street". The JSON Schema clearly describes this hierarchical relationship by defining "type": "object" and nested properties. At the same time, it can also define the maximum length of strings, the range of values ​​for numbers, the minimum number of elements in an array, etc., providing powerful validation capabilities for data validity.

[0038] Before the final output or the next step of encryption, the system calls the JSON Schema validator to compare and verify the generated JSON data object with the JSON Schema definition. Only data that passes the verification will be recognized as a qualified and uniformly formatted data structure and allowed to enter the subsequent signing and on-chain process. Data that fails the verification will be returned and an error log will be recorded, notifying the administrator to investigate the problem with the data source or mapping rules.

[0039] By using JSON Schema for mandatory data validation before data is added to the blockchain, a robust data quality firewall is built. Only data that has passed full verification and has a sound structure can enter the subsequent processes, thereby avoiding consensus failures, smart contract execution anomalies, or storage errors caused by data structure errors, and improving the stability and processing efficiency of the entire system.

[0040] In one optional implementation, the step of digitally signing the formatted building information using an asymmetric encryption algorithm includes: The formatted basic information of the building is input into a hash function for calculation, and the hash value is output. The hash value is encrypted using an asymmetric encryption algorithm to generate a digital signature; The formatted basic information of the building, digital signature, signer certificate, encryption algorithm identifier and timestamp are packaged to obtain the signed data packet.

[0041] Specifically, before the signing operation begins, each data source entity authorized to submit data to the blockchain network (such as a city's natural resources and planning bureau or a real estate development company) must pre-generate an asymmetric key pair. This key pair consists of a private key and a public key. The private key is generated locally by the data submitter in a secure environment and must be kept extremely confidential and stored (usually using a hardware security module HSM or an encrypted keystore file), and must never be disclosed to any third party. The public key can be derived from the private key and can be publicly distributed. Depending on security requirements and policy requirements, one of the asymmetric encryption algorithms—RSA, ECC, or SM2—is chosen to generate the key pair. The RSA algorithm is based on the mathematical problem of factoring large integers and is technically mature. Widely used, if the RSA algorithm is selected, the system will generate a key pair of a specific length (such as 2048 bits or 4096 bits). The ECC (Elliptic Curve Cryptography) algorithm can provide security comparable to or even higher than that of RSA long keys with a shorter key length (such as 256 bits). It has the advantages of high computational efficiency and small storage space. If the ECC algorithm is selected, the system will generate a key pair on a selected elliptic curve (such as secp256k1, which is the curve used by Bitcoin and Ethereum). The SM2 algorithm is a commercial cryptographic algorithm released by the State Cryptography Administration of China. It belongs to the elliptic curve cryptography system. In scenarios that need to meet national cryptographic compliance requirements, this algorithm must be used. Its key length is similar to ECC, which is also 256 bits.

[0042] The standardized JSON data structure is taken as input and fed into a cryptographically secure hash function (such as SHA-256) for computation. The hash function outputs a unique hash value of fixed length (e.g., 256 bits for SHA-256). The hash value is then encrypted using an asymmetric encryption algorithm to generate a digital signature. The specific mathematical algorithm for the signature depends on the selected encryption scheme.

[0043] The final signed data packet is a structured data unit, including the following: Formatted basic information about the property: This information is retained so that all nodes can read and use the data content, reflecting the transparency of the blockchain; Digital signature: the signature result obtained from the above calculation; Signer certificate or public key identifier: In order to facilitate the verifier to obtain the correct public key, the data packet needs to contain the signer's identity information. This can be the signer's complete public key, or a certificate number or address (such as a blockchain address). Verifying nodes can use this identifier to query the corresponding public key from the chain or a trusted certificate directory service. Encryption Algorithm Identifier: Explicitly specifies the algorithm used to generate this signature (e.g., “RSA-SHA256”, “ECDSA-secp256k1-SHA256”, or “SM2-SM3”) so that the verifier can use the same algorithm process for verification; Timestamp: Records the time when the signature was generated, used to prevent replay attacks (i.e., old valid data packets being sent repeatedly) and to provide legal evidence.

[0044] In one optional implementation, broadcasting the signed data packet to all relevant nodes in the blockchain network, so that the nodes verify the data packet using a consensus mechanism, and storing the verified data packet and its corresponding hash value in a new block, includes: The signed data packet is broadcast to all relevant nodes in the blockchain network so that the master node in the current network can verify the validity of the data packet and generate a Pre-Prepare message after the verification is successful. The Pre-Prepare message is then broadcast to all backup nodes. The backup node verifies the Pre-Prepare message, and broadcasts the Prepare message to the entire network upon successful verification. For any node in the network, when it collects Prepare messages from 2f other different nodes, it generates a Prepare certificate and broadcasts a Commit message to the entire network. When it collects Commit messages from 2f other different nodes, it generates a Commit certificate and stores the signed data packet and its corresponding hash value in a new block. Here, f is the maximum number of malicious nodes that the network can tolerate. After the storage operation is completed, a success message is sent to the client of the corresponding data source. When the client receives f+1 success messages from different nodes, it confirms that the signed data packet has been successfully stored in the blockchain.

[0045] Specifically, the signed data packet is broadcast to all relevant nodes in the blockchain network. A consensus mechanism is used to determine whether the signed data packet is validly written into a block. The consensus mechanism can employ the Practical Byzantine Fault Tolerance (PBFT) algorithm. The specific process is as follows: First, the client (i.e., the data submitter system) broadcasts the constructed, signed data packet to the entire blockchain network. Upon receiving the request, the current master node performs a series of validity checks, using the public key provided in the data packet to verify the validity of its digital signature to confirm the authenticity and integrity of the data source, check whether the data format conforms to the JSON Schema specification, and whether the necessary fields are complete. If the verification passes, the master node assigns a unique, continuously incrementing sequence number (n) to the request, indicating the order of the request in the state machine log. Subsequently, the master node constructs a Pre-Prepare message, which includes: the client request itself, the newly assigned sequence number n, and the current view number (v, identifying which master node is currently active). The master node broadcasts this Pre-Prepare message to all backup nodes.

[0046] Upon receiving the Pre-Prepare message from the master node, each backup node does not accept it immediately. Instead, it independently performs the same verification process as the master node (signature verification, format checking, etc.). At the same time, it also checks whether the sequence number n is within a reasonable range and whether the view v is correct. Only when the backup node successfully verifies that the request in the Pre-Prepare message is valid and comes from a legitimate master node will it broadcast a Prepare message to the entire network. This message also contains the sequence number n, the view v, and the message's own signature to indicate its commitment.

[0047] Each node (including the primary node and other backup nodes) begins collecting and listening to Prepare messages sent by other nodes. When a node collects valid Prepare messages from 2f other different nodes for the same sequence number n and view v, plus the one it sent itself, it has proof of 2f+1 Prepare messages. This set constitutes a Prepare certificate, indicating that the majority of honest nodes in the network have reached a preliminary consensus on the requested sequence number, where f is the maximum number of malicious nodes the system can tolerate, and the total number of nodes in the network is 3f+1.

[0048] After collecting enough Prepare messages to form a certificate, each node broadcasts a Commit message to the entire network, announcing that it is ready to execute the request with sequence number n. The node also begins to collect Commit messages from other nodes. When it has collected 2f valid Commit messages for the same sequence number n and view v, plus its own, it has proof of 2f+1 Commit messages, forming a Commit certificate. This indicates that most honest nodes in the network have not only reached a consensus on the order but also confirmed that they will execute the request. Once a node has a Commit certificate, it knows that the network has officially reached a consensus and it can safely execute the request. Execution means packaging the signed data packet and its hash value and officially appending it to a new block in the local blockchain ledger. At this time, the data is persistently stored, the state machine state is updated, and after the node completes the execution, it sends a successful reply message to the client. After the client receives f+1 successful replies with the same content from different nodes, it can be sure that the request has been finally confirmed and recorded on the chain, completing this data on-chain operation.

[0049] In one optional implementation, the preset business rules include, but are not limited to, field-level permission control rules, mandatory change description rules, major modification secondary confirmation rules, change range thresholds, and manual review rules. The field-level permission control rule is used to verify whether the field to be updated in the data update request has update permission. If not, the data update request is rejected. The mandatory change description rule is used to verify whether the data update request contains a reason for the change. If not, the data update request is rejected. The major modification secondary confirmation rule is used to confirm whether the data update request is an update request that requires approval. If it is, the approval process is automatically triggered. The change magnitude threshold and manual review rules are used to calculate the change magnitude of key fields in the data update request relative to the original data, and automatically trigger the manual review process when the change magnitude exceeds the preset change magnitude threshold.

[0050] Specifically, update operations must be performed within a pre-defined business rule framework. These rules exist in the form of configurable strategies and are typically executed by smart contracts on the blockchain or off-chain business rule engines, including but not limited to the following rules: Rule 1: Field-level access control rule (only specific roles are allowed to modify specified fields). The rule engine will check the "update operation content" in the request to ensure that every field the requester attempts to modify is within the scope of their role's permissions. For example, the rule may stipulate that "the financial institution user role has no right to modify the 'location' field". Once an unauthorized operation is detected, the entire request will be rejected immediately.

[0051] Rule 2: Mandatory Change Explanation Rule (Modifications must include a reason for the change). The rule engine will check whether the request contains a non-empty "reason for change" field. If it is missing or the content is non-compliant (such as just meaningless characters), the request will be rejected. This rule ensures that every data change is traceable, providing key textual evidence for post-event auditing.

[0052] Rule 3: Major Modification Secondary Confirmation Rule. For predefined "major modification" operations (such as changing the name of the construction unit, significantly extending the completion date, etc.), the rule engine will trigger an additional approval workflow. The request will be set to the "pending approval" status and an approval task will be automatically generated and pushed to the administrator workbench of a node with higher authority (such as the provincial regulatory agency node). The original update operation will only continue to be executed after the approving party verifies and approves it through its own MFA.

[0053] Rule 4: Change Amount Threshold and Manual Review Rule. This rule is used to extract the change amount Δ of key fields in the request (e.g., the completion date is delayed by 100 days) and calculate its change magnitude relative to the original data (e.g., delayed by 33%). The calculated change magnitude is compared with a preset threshold (e.g., 20%). If the change magnitude exceeds the threshold, it is determined to be a high-risk operation, and the manual review process is automatically triggered. The update request will be suspended and sent to a manual review queue. The designated reviewer will conduct an offline verification of the rationality and authenticity of the change. The update will only continue after the reviewer approves the change and confirms it in the system.

[0054] In an optional implementation, the method further includes: After the data update is completed, the updated data, along with the transaction hash, timestamp, operator identity, and update reason, will be recorded as a new data version. The data version before the update will be marked as a historical version and stored in the historical database.

[0055] Specifically, after passing all verifications and rule checks, a substantive data update operation will be performed. The data update will not directly overwrite the original data. Instead, the updated data content, along with metadata such as the transaction hash, timestamp, operator identity, and reason for change, will be generated as a completely new data version and a new JSON data structure will be created. The original data version will be marked as a "historical version," and its pointer (hash value) will be stored in a special historical record area or the historical database of the state database in the blockchain. This process ensures the immutability and complete traceability of the data. That is, the old version is like being sealed and can never be modified or deleted. Furthermore, all changes to any record from its creation to its current state can be clearly retrieved and audited by traversing the historical version records, forming a complete data lifecycle chain.

[0056] In an optional implementation, the method further includes: Periodically and randomly select a number of real estate registration data records; For each data record, the hash value is recalculated using the same hash algorithm as when the data record was uploaded to the blockchain. The calculated hash value is then compared with the hash value stored in the blockchain. A verification report is generated based on the comparison results, and an alarm message is generated when the comparison results are inconsistent.

[0057] Specifically, a number of real estate registration data records will be randomly selected periodically. To ensure the fairness, comprehensiveness, and unpredictability of the verification (to prevent malicious nodes from preparing in advance), the selection of verification samples must follow the following randomness principles: Random source: A verifiable, unpredictable random number is usually used as the seed. This random number can be derived from the hash value of a specific block in the future (such as the hash of the block at task initiation height + 100). Because the block hash is unpredictable before it is generated, the fairness of randomness is guaranteed. Algorithm selection: Based on the random number seed, a specific number (e.g., 0.1% of the total) of records are randomly selected from the total range of all chain data records using a preset, defined algorithm (e.g., using the seed as input to the random number generator). These records constitute the sample set for this verification. Scope coverage: The algorithm design ensures that the sample set covers data written at different times and for different business types to a certain extent, in order to increase the comprehensiveness of the verification.

[0058] For each data record, based on the unique identifier in the sample set list, the complete data content of these records is read from the local state database (which stores the latest current value of the data). The hash value of the record is recalculated using the exact same hash algorithm as when the data was initially added to the chain. It should be noted that it is necessary to ensure that the hash algorithm and data serialization format (such as the sorting of JSON fields) are completely consistent with the initial calculation, otherwise the calculated hash value will be meaningless. This process is completed locally on the node and does not involve network transmission, thus ensuring efficiency and security.

[0059] The calculated hash value is compared with the hash value stored in the blockchain. The specific process is as follows: Comparison object: Instead of comparing data with other nodes, nodes compare data with records on the blockchain itself. Specifically, a node will find the transaction in which the record was originally written into the blockchain based on the transaction ID of the record, and obtain the original hash value stored at that time and agreed upon by the entire network from that transaction. This original hash value is permanently recorded in the block and is the "correct answer" recognized by all nodes. Comparison operation: The node compares the "locally recalculated hash value" with the "original hash value stored on the chain" one by one. If all the hash values ​​of the two records are completely consistent, it proves that the data stored locally by the node is completely consistent with the records of the blockchain global ledger, and the data is complete and consistent. If the hash values ​​of one or more records are found to be inconsistent, it is a serious alarm, meaning that the data stored locally by the node has been modified or corrupted, and is inconsistent with the truth confirmed by consensus.

[0060] Based on the comparison results, a verification report is generated and archived. The report includes at least the verification task ID, verification time, total number of records sampled, identifier of each record and its comparison result (consistent / inconsistent), and the digital signature of this node (proving that this report was generated by this node). All nodes submit this signed verification report to the scheduling center or store it directly on the blockchain. The scheduling center collects the reports from all nodes and generates a network-wide consistency verification summary report. The summary report and all individual reports from all nodes are assigned a transaction hash and stored on the blockchain or a secure audit log system, forming a permanent and tamper-proof audit trail for use in any future compliance checks or problem investigations.

[0061] This embodiment provides proactive data integrity assurance, going beyond the "immutability" assumption of blockchain. While blockchain itself ensures that data is difficult to tamper with once written, it cannot proactively detect whether local data on a single node is damaged or inconsistent due to storage failures, software errors, or malicious attacks. The periodic verification mechanism proactively and periodically samples and compares the data of all nodes, using cryptographic hash values ​​for self-auditing. This substantially verifies whether the replicas of the global ledger on each node are consistent. When the verification finds that the hash value of a node's data does not match the on-chain evidence, the system can immediately trigger an alarm, accurately locating the problematic node and data record. This allows maintenance personnel to respond quickly, notifying the node to synchronize data from trusted nodes in the network to repair its local state, thereby preventing the spread of "dirty data" and ensuring the eventual consistency of the data state of all nodes in the network, improving the maintainability and availability of the system.

[0062] Detailed reports for each verification, including sample records, comparison results, and signatures of each node, are permanently stored on the blockchain or in a security log, forming a transparent, traceable, and non-repudiable audit trail. This allows regulators, partners, or the public to be informed of the system's data consistency at any point in history without third-party intervention, which is highly beneficial for passing rigorous data security and audit compliance checks in the financial, government, and other fields.

[0063] In one optional implementation, the present invention also supports cross-chain data interaction, which is achieved through a light node bridge. The light node bridge can parse the data format of external chains and perform adaptive conversion. Through the light node bridge technology, cross-chain interaction can be achieved in a secure, efficient and reliable manner, upgrading the real estate registration system from an isolated data chain to a core infrastructure that supports multi-chain business collaboration, thereby improving the operational efficiency and trust level of the entire government and business ecosystem.

[0064] Secondly, embodiments of the present invention provide a blockchain-based property information sharing device, see [link to relevant documentation]. Figure 2 This is a schematic diagram of an embodiment of a blockchain-based building information sharing device provided by the present invention.

[0065] like Figure 2 As shown, the device includes: The data preprocessing module 21 is used to receive basic building information from multiple data sources and to format the basic building information; wherein, the basic building information includes, but is not limited to, project name, location, name of construction unit, start date and completion date; Data encryption module 22 is used to perform digital signature operation on the formatted basic information of the building using an asymmetric encryption algorithm; Data storage module 23 is used to broadcast the signed data packet to all relevant nodes in the blockchain network, so that the nodes can use a consensus mechanism to verify the data packet and store the verified data packet and its corresponding hash value into a new block; The data update module 24 is used to verify the identity and permissions of the requester by using a multi-factor authentication method when a data update request is received. After the verification is successful, the data is updated based on preset business rules, and an update notification is pushed to the relevant business parties after the update is completed. The multi-factor authentication includes at least two of the following: biometric recognition, hardware token and SMS verification code.

[0066] In one optional implementation, the formatting of the building's basic information includes: Parse the received basic information about the properties and handle missing values ​​and outliers. The fields of the corrected data are mapped to standard fields using pre-configured mapping rules; the mapping rules are used to specify the correspondence between the data fields to be mapped and the standard fields in the data dictionary; Based on the pre-designed JSON Schema definition, the standard fields are filled in according to the correct hierarchical relationship to obtain a JSON object that conforms to the Schema specification; The JSON Schema validator is invoked to compare and validate the generated JSON object against the JSON Schema definition. Data that passes validation is retained, while data that fails validation is returned and an error log is logged.

[0067] In one optional implementation, the step of digitally signing the formatted building information using an asymmetric encryption algorithm includes: The formatted basic information of the building is input into a hash function for calculation, and the hash value is output. The hash value is encrypted using an asymmetric encryption algorithm to generate a digital signature; The formatted basic information of the building, digital signature, signer certificate, encryption algorithm identifier and timestamp are packaged to obtain the signed data packet.

[0068] In one optional implementation, broadcasting the signed data packet to all relevant nodes in the blockchain network, so that the nodes verify the data packet using a consensus mechanism, and storing the verified data packet and its corresponding hash value in a new block, includes: The signed data packet is broadcast to all relevant nodes in the blockchain network so that the master node in the current network can verify the validity of the data packet and generate a Pre-Prepare message after the verification is successful. The Pre-Prepare message is then broadcast to all backup nodes. The backup node verifies the Pre-Prepare message, and broadcasts the Prepare message to the entire network upon successful verification. For any node in the network, when it collects Prepare messages from 2f other different nodes, it generates a Prepare certificate and broadcasts a Commit message to the entire network. When it collects Commit messages from 2f other different nodes, it generates a Commit certificate and stores the signed data packet and its corresponding hash value in a new block. Here, f is the maximum number of malicious nodes that the network can tolerate. After the storage operation is completed, a success message is sent to the client of the corresponding data source. When the client receives f+1 success messages from different nodes, it confirms that the signed data packet has been successfully stored in the blockchain.

[0069] In one optional implementation, the preset business rules include, but are not limited to, field-level permission control rules, mandatory change description rules, major modification secondary confirmation rules, change range thresholds, and manual review rules. The field-level permission control rule is used to verify whether the field to be updated in the data update request has update permission. If not, the data update request is rejected. The mandatory change description rule is used to verify whether the data update request contains a reason for the change. If not, the data update request is rejected. The major modification secondary confirmation rule is used to confirm whether the data update request is an update request that requires approval. If it is, the approval process is automatically triggered. The change magnitude threshold and manual review rules are used to calculate the change magnitude of key fields in the data update request relative to the original data, and automatically trigger the manual review process when the change magnitude exceeds the preset change magnitude threshold.

[0070] In an optional embodiment, the device is further configured to: After the data update is completed, the updated data, along with the transaction hash, timestamp, operator identity, and update reason, will be recorded as a new data version. The data version before the update will be marked as a historical version and stored in the historical database.

[0071] In an optional embodiment, the device is further configured to: Periodically and randomly select a number of real estate registration data records; For each data record, the hash value is recalculated using the same hash algorithm as when the data record was uploaded to the blockchain. The calculated hash value is then compared with the hash value stored in the blockchain. A verification report is generated based on the comparison results, and an alarm message is generated when the comparison results are inconsistent.

[0072] Thirdly, embodiments of the present invention provide an electronic device, see [link to previous document]. Figure 3 The diagram shown is a structural schematic of an electronic device provided in an embodiment of the present invention.

[0073] like Figure 3 As shown, the device includes: Memory 31 is used to store computer programs; Processor 32 is used to execute the computer program; When the processor 32 executes the computer program, it implements the blockchain-based property information sharing method as described in any of the above embodiments.

[0074] For example, the computer program may be divided into one or more modules / units, which are stored in the memory 31 and executed by the processor 32 to complete the present invention. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the electronic device.

[0075] The processor 32 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0076] The memory 31 can be used to store the computer programs and / or modules. The processor 32 implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory 31 and calling the data stored in the memory 31. The memory 31 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory 31 may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital card (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0077] It should be noted that the aforementioned electronic devices include, but are not limited to, processors and memory, as will be understood by those skilled in the art. Figure 3 The structural diagram is merely an example of the electronic device described above and does not constitute a limitation on the electronic device. It may include more components than shown in the diagram, or combine certain components, or use different components.

[0078] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed, implements the blockchain-based property information sharing method described in any of the above embodiments.

[0079] It should be understood that the implementation of all or part of the processes in the above-described blockchain-based property information sharing method can also be accomplished by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium. When executed by a processor, the computer program can implement the steps of the above-described blockchain-based property information sharing method. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0080] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. It should be noted that, for those skilled in the art, several equivalent obvious modifications and / or equivalent substitutions can be made without departing from the technical principles of the present invention, and these obvious modifications and / or equivalent substitutions should also be considered within the scope of protection of the present invention.

Claims

1. A blockchain-based method for sharing property information, characterized in that, include: Receive basic building information from multiple data sources and format the basic building information; wherein, the basic building information includes, but is not limited to, project name, location, name of construction unit, start date and completion date; Asymmetric encryption algorithm is used to digitally sign the formatted basic information of the building. The signed data packet is broadcast to all relevant nodes in the blockchain network, so that the nodes can verify the data packet using a consensus mechanism and store the verified data packet and its corresponding hash value into a new block; When a data update request is received, a multi-factor authentication method is used to verify the identity and permissions of the requester. After the verification is successful, the data is updated based on preset business rules, and an update notification is pushed to the relevant business parties after the update is completed. The multi-factor authentication includes a combination of at least two of the following: biometric recognition, hardware token, and SMS verification code.

2. The blockchain-based method for sharing property information as described in claim 1, characterized in that, The formatting process for the basic information of the building includes: Parse the received basic information about the properties and handle missing values ​​and outliers. The fields of the corrected data are mapped to standard fields using pre-configured mapping rules; the mapping rules are used to specify the correspondence between the data fields to be mapped and the standard fields in the data dictionary; Based on the pre-designed JSON Schema definition, the standard fields are filled in according to the correct hierarchical relationship to obtain a JSON object that conforms to the Schema specification; The JSON Schema validator is invoked to compare and validate the generated JSON object against the JSON Schema definition. Data that passes validation is retained, while data that fails validation is returned and an error log is logged.

3. The blockchain-based method for sharing property information as described in claim 1, characterized in that, The process of digitally signing the formatted basic information of the building using an asymmetric encryption algorithm includes: The formatted basic information of the building is input into a hash function for calculation, and the hash value is output. The hash value is encrypted using an asymmetric encryption algorithm to generate a digital signature; The formatted basic information of the building, digital signature, signer certificate, encryption algorithm identifier and timestamp are packaged to obtain the signed data packet.

4. The blockchain-based method for sharing property information as described in claim 1, characterized in that, The step of broadcasting the signed data packet to all relevant nodes in the blockchain network, so that the nodes can verify the data packet using a consensus mechanism, and store the verified data packet and its corresponding hash value in a new block, includes: The signed data packet is broadcast to all relevant nodes in the blockchain network so that the master node in the current network can verify the validity of the data packet and generate a Pre-Prepare message after the verification is successful. The Pre-Prepare message is then broadcast to all backup nodes. The backup node verifies the Pre-Prepare message, and broadcasts the Prepare message to the entire network upon successful verification. For any node in the network, when it collects Prepare messages from 2f other different nodes, it generates a Prepare certificate and broadcasts a Commit message to the entire network. When it collects Commit messages from 2f other different nodes, it generates a Commit certificate and stores the signed data packet and its corresponding hash value in a new block. Here, f is the maximum number of malicious nodes that the network can tolerate. After the storage operation is completed, a success message is sent to the client of the corresponding data source. When the client receives f+1 success messages from different nodes, it confirms that the signed data packet has been successfully stored in the blockchain.

5. The blockchain-based method for sharing property information as described in claim 1, characterized in that, The preset business rules include, but are not limited to, field-level permission control rules, mandatory change description rules, major modification secondary confirmation rules, change range thresholds, and manual review rules. The field-level permission control rule is used to verify whether the field to be updated in the data update request has update permission. If not, the data update request is rejected. The mandatory change description rule is used to verify whether the data update request contains a reason for the change. If not, the data update request is rejected. The major modification secondary confirmation rule is used to confirm whether the data update request is an update request that requires approval. If it is, the approval process is automatically triggered. The change magnitude threshold and manual review rules are used to calculate the change magnitude of key fields in the data update request relative to the original data, and automatically trigger the manual review process when the change magnitude exceeds the preset change magnitude threshold.

6. The blockchain-based method for sharing property information as described in claim 1, characterized in that, The method further includes: After the data update is completed, the updated data, along with the transaction hash, timestamp, operator identity, and update reason, will be recorded as a new data version. The data version before the update will be marked as a historical version and stored in the historical database.

7. The blockchain-based method for sharing property information as described in claim 1, characterized in that, The method further includes: Periodically and randomly select a number of real estate registration data records; For each data record, the hash value is recalculated using the same hash algorithm as when the data record was uploaded to the blockchain. The calculated hash value is then compared with the hash value stored in the blockchain. A verification report is generated based on the comparison results, and an alarm message is generated when the comparison results are inconsistent.

8. A blockchain-based property information sharing device, characterized in that, include: The data preprocessing module is used to receive basic building information from multiple data sources and format the basic building information; wherein, the basic building information includes, but is not limited to, project name, location, name of construction unit, start date and completion date; The data encryption module is used to perform digital signature operations on the formatted basic information of the building using an asymmetric encryption algorithm. The data storage module is used to broadcast the signed data packet to all relevant nodes in the blockchain network, so that the nodes can verify the data packet using a consensus mechanism and store the verified data packet and its corresponding hash value into a new block; The data update module is used to verify the identity and permissions of the requester by using a multi-factor authentication method when a data update request is received. After the verification is successful, the data is updated based on preset business rules, and an update notification is pushed to the relevant business parties after the update is completed. The multi-factor authentication includes at least two of the following: biometric recognition, hardware token and SMS verification code.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program; Wherein, when the processor executes the computer program, it implements the blockchain-based property information sharing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the blockchain-based property information sharing method as described in any one of claims 1 to 7.

Images