Multi-source data driven real estate registration method and system

Abstract

The invention provides a multi-source data driven real estate registration method and system, and the method comprises the steps: receiving a registration application, carrying out the basic verification, carrying out the screening of edge nodes in combination with load balancing processing, obtaining a target edge node, distributing the registration application to the target edge node, carrying out the local verification, and obtaining a verification result. A verification result and key registration data are transmitted through a quantum security communication channel; a data transmission confirmation receipt is obtained; the verification result and the key registration data are combined to carry out evidence storage; on-chain evidence storage feedback is obtained, an intelligent contract is triggered and executed according to the on-chain evidence storage feedback, and a contract execution result is obtained; according to the real estate registration method provided by the invention, the problems of insufficient security protection and the like in the prior art are solved through the real estate registration method, so that the security of the real estate registration service is improved.

Description

Technical Field

[0001] This invention relates to the field of data processing, and more specifically, to a multi-source data-driven method and system for real estate registration. Background Technology

[0002] With the deep integration of smart cities and digital government, the real estate transaction market is booming, and the demand for cross-regional ownership transfers and off-site mortgages continues to grow. Security monitoring scenarios are becoming increasingly complex and their coverage is expanding, placing increasingly stringent requirements on real estate registration services. However, the real estate registration process is characterized by high coupling of multi-source data, complex cross-domain node collaboration, and strong privacy concerns regarding sensitive data, requiring end-to-end data verification, secure transmission, and reliable evidence storage. Currently, existing technologies have many shortcomings in key aspects of the entire process, making it difficult to meet the needs of real-world scenarios. On the one hand, existing technologies mostly use traditional symmetric or asymmetric encryption techniques to process sensitive data, without implementing verification operations under encryption. This makes them prone to data leakage during decryption or long-term evidence storage security risks, resulting in a lack of reliable security support for subsequent business processing. On the other hand, the logic of cross-domain collaboration and resource allocation is one-sided. Existing technologies mostly rely on traditional network transmission for cross-domain data, without establishing highly secure communication channels and efficient collaborative verification mechanisms. Furthermore, business distribution does not fully consider the real-time performance and geographical distance of edge nodes, making it difficult to balance cross-domain data security and collaborative efficiency. At the same time, node load imbalance is prone to occur, resulting in long business processing cycles and poor system stability.

[0003] Therefore, there is an urgent need for a real estate registration method that is driven by multi-source data, securely encrypted and protected, highly efficient in cross-domain collaboration, and intelligent in trusted evidence storage, so as to solve the problems of insufficient security protection in existing technologies and improve the security of real estate registration business. Summary of the Invention

[0004] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide a multi-source data-driven method for real estate registration, the method comprising: Receive registration applications and perform basic verification. Based on the verified registration applications, and in conjunction with load balancing processing, filter edge nodes to obtain target edge nodes. The registration application is distributed to the target edge node for local verification, the verification results are obtained, and key registration data is obtained in combination with the business type; Establish a quantum-safe communication channel, transmit verification results and key registration data based on the quantum-safe communication channel, and obtain data transmission confirmation receipts; The verification results, key registration data, and data transmission confirmation receipt are submitted to the consortium blockchain network for storage, and on-chain storage feedback is obtained. Based on the on-chain storage feedback, the smart contract is triggered and executed to obtain the contract execution result. Securely store the contract execution results, obtain security credentials, verify the stored data in conjunction with the feedback, obtain aggregated registration data, and generate registration results.

[0005] As a further method of the present invention, receiving a registration application and performing basic verification, and based on the verified registration applications, filtering edge nodes in conjunction with load balancing processing to obtain target edge nodes, includes: Receive registration applications containing electronic materials, including information on the property owner, information on the location of the property, and electronically signed ownership certificates. The registration application is subject to basic verification, which includes document format verification and electronic signature verification. The registration applications that have passed the basic verification are load balanced using a weighted round-robin algorithm. The target edge nodes are selected by comprehensively considering the CPU utilization, memory usage, network bandwidth utilization, and geographical distance of the edge nodes. The target edge node must meet a preset performance threshold.

[0006] As a further method of the present invention, the registration application is distributed to the target edge node for local verification, the verification result is obtained, and key registration data is obtained in combination with the business type, including: The registration application is distributed to the target edge node, and the registration application is locally verified based on the target edge node, including the completeness of electronic materials and the compliance of the format. If the local verification passes, the local verification result is obtained; if the local verification fails, feedback is sent to the user. The integrity of the electronic materials includes the owner, location, area and ownership type of the real estate, and the compliance of the format means that it conforms to the electronic data specifications for real estate registration. If the business type of the registration application is involved, and the business type involves any of the following situations: cross-regional mortgage, cross-regional ownership transfer, or cross-regional household registration information, cross-domain data collaboration will be triggered to obtain the collaborative verification results. If the business type does not involve cross-domain operations, the sensitive registration information in the registration application will be encrypted and calculated to obtain encrypted registration data. Key registration data is composed of collaborative verification results and encrypted registration data.

[0007] As a further method of the present invention, a quantum-secure communication channel is established, and verification results and key registration data are transmitted based on the quantum-secure communication channel to obtain a data transmission confirmation receipt, including: A quantum-secure communication channel is established based on a quantum key distribution protocol to generate quantum keys between the target edge node and the collaborating edge node, and between the target edge node and the consortium chain node; Wherein, the collaborative edge node refers to other regional edge nodes that have cross-domain collaboration needs with the target edge node, and the consortium chain node refers to the authorized node that makes up the real estate registration consortium chain network; Verification results and key registration data are transmitted through a quantum-secure communication channel, and a data transmission confirmation receipt is obtained after the transmission is completed.

[0008] As a further method of the present invention, the verification results, key registration data, and data transmission confirmation receipt are submitted to the consortium blockchain for notarization, on-chain notarization feedback is obtained, and a smart contract is triggered and executed based on the on-chain notarization feedback to obtain the contract execution result, including: The verification results, key registration data, and data transmission confirmation receipts are submitted to the consortium blockchain nodes in the consortium blockchain network. The consortium blockchain nodes include real estate registration center nodes, edge computing nodes, government collaboration department nodes, and notary office nodes, and permissions are assigned to each consortium blockchain node. The consortium blockchain nodes use the PBFT consensus algorithm to store and collaboratively process the submitted verification results, key registration data, and data transmission confirmation receipts, and obtain on-chain evidence storage feedback. If the on-chain evidence storage feedback indicates successful storage, the smart contract in the consortium blockchain will be triggered and the contract content will be executed automatically to obtain the contract execution result. The contract content refers to completing on-chain evidence storage and uploading, synchronizing the evidence storage results to all nodes on the consortium blockchain, generating a unique identifier for real estate registration business, and obtaining the contract execution result after execution.

[0009] As a further method of the present invention, secure notarization is performed based on the contract execution result to obtain a security certificate, and verification is performed in conjunction with notarization feedback to obtain summary registration data and generate registration results, including: Based on the contract execution result, and combined with the NTRU algorithm, the on-chain evidence data is encrypted twice, and the quantum key in the quantum-secure communication channel is bound and stored with the twice-encrypted evidence data to obtain a security certificate. The verification results, key registration data, and contract execution results are combined to form the registration data. The registration data, on-chain evidence feedback, and security credentials are checked for consistency. Once the check passes, the summary registration data is obtained, and the registration result is generated based on the summary registration data.

[0010] Furthermore, embodiments of the present invention also provide a multi-source data-driven real estate registration system, comprising: The verification module is used to perform basic verification on the registration application, distribute the registration application to the target edge node for local verification, obtain the verification result, perform verification based on security credentials and evidence feedback, obtain summary registration data and generate registration result; The filtering module filters edge nodes based on verified registration applications and in conjunction with load balancing processing to obtain target edge nodes; The processing module obtains key registration data based on verification results and business type, triggers and executes smart contracts based on on-chain evidence storage feedback, and obtains contract execution results. The building module is used to establish a quantum-safe communication channel; The transmission module transmits verification results and key registration data based on a quantum-secure communication channel and obtains a data transmission confirmation receipt. The notarization module securely notifies the contract execution results, obtains security credentials, submits the verification results, key registration data, and data transmission confirmation receipt to the consortium blockchain network for notarization, and obtains on-chain notarization feedback; based on the on-chain notarization feedback, it triggers and executes the smart contract to obtain the contract execution results. Attached Figure Description

[0011] Figure 1 This is a flowchart of the steps of a multi-source data-driven real estate registration method according to the present invention; Figure 2 This is a flowchart of the steps for obtaining contract execution results in a multi-source data-driven real estate registration method according to the present invention. Detailed Implementation

[0012] The present invention will be further described in detail below through specific embodiments. The following embodiments are merely descriptive and not limiting, and should not be used to limit the scope of protection of the present invention.

[0013] like Figure 1 and Figure 2 As shown, a multi-source data-driven method for real estate registration includes the following steps: Step 1: Receive registration applications and perform basic verification. Based on the verified registration applications, and in conjunction with load balancing processing, filter edge nodes to obtain target edge nodes.

[0014] Step 1 includes: The system receives registration applications containing electronic materials, including information on the property owner, the location of the property, and electronically signed ownership certificates.

[0015] The registration application undergoes basic verification, which includes document format verification and electronic signature verification.

[0016] The weighted round-robin algorithm is used to load balance the registration applications that have passed the basic verification. The target edge nodes are selected by comprehensively considering the CPU utilization, memory usage, network bandwidth utilization and geographical distance of the edge nodes.

[0017] The target edge node must meet a preset performance threshold.

[0018] Specifically, the system receives registration applications submitted by users through online government service platforms and government service apps, and automatically identifies and extracts electronic materials from the applications. The real estate owner information is the core basis for confirming the identity of the registration subject, covering basic identity information such as the owner's name, ID number, and contact information. The real estate location information is used to locate the registration target, including precise location information such as province, city, district, street address, and real estate unit number. The electronically signed ownership certificate is a legal document proving the current ownership status of the real estate, including the original real estate ownership certificate, sales contract, gift agreement, etc., and must be accompanied by a valid signature that conforms to national electronic signature standards. After receiving the application, the system automatically generates a unique application number for subsequent business tracking and data association throughout the entire process.

[0019] It should be noted that all information in this embodiment was obtained through legitimate channels and cannot be used for commercial purposes.

[0020] Furthermore, to ensure the readability and standardization of electronic materials, the system defaults to supporting PDF / OFDP standard files, and files that do not meet the format requirements are directly judged as failing verification. Electronic signature verification uses national cryptographic algorithms to verify the validity of signatures in electronic materials, including verifying whether the signature was issued by a legally authorized entity, whether the signature is complete and has not been tampered with, and whether the signature is within its validity period. Registration applications that pass verification will enter the subsequent load balancing screening stage, while those that fail verification will be promptly notified to the user of the specific reasons for failure, and an entry point for modifying and resubmitting the materials will be provided.

[0021] It should be noted that, in this embodiment, the preset edge node performance thresholds include CPU utilization below 50%, memory usage below 40%, and network bandwidth utilization below 60%. These thresholds are specifically determined based on the processing performance requirements of real estate registration services, edge node hardware configuration standards, and industry-standard performance optimization experience. This ensures that the target edge node has sufficient computing, storage, and network resources to efficiently process subsequent tasks such as local verification of registration applications, avoiding processing delays or failures due to insufficient node resources. It also avoids setting thresholds too strictly, resulting in too few selectable edge nodes and affecting the flexibility of load balancing, or setting them too leniently, leading to node overload and reduced overall business processing efficiency. The edge node performance thresholds can be adaptively adjusted under different processing performance requirements, edge node hardware configuration standards, and industry-standard performance optimization experience.

[0022] Furthermore, the system employs a load balancing algorithm based on weighted round-robin to screen edge nodes that have passed basic verification of registration applications. The screening process comprehensively considers four indicators: CPU utilization, memory usage, network bandwidth utilization, and geographical distance. Network bandwidth utilization reflects the node's current processing capacity, and geographical distance reflects data transmission latency; the closer the node is to the user, the lower the transmission latency. Simultaneously, the system presets an edge node performance threshold; only edge nodes meeting this threshold are eligible to be screened as target edge nodes. After normalizing each indicator, a comprehensive node score is calculated. The edge node with the highest score that meets the performance threshold is designated as the target edge node, responsible for subsequent local verification and other business processing of the registration application.

[0023] In some possible implementations, suppose Mr. Zhang needs to transfer the ownership of a property under his name in City A to City B. He submits a registration application through the City B government affairs APP. The system simultaneously receives the electronic materials he uploads, including scanned copies of both sides of Mr. Zhang's ID card, the detailed address and property unit number of the property in City A, an electronic scanned copy of the original property ownership certificate including the electronic seal of the property registration center, and the second-hand housing sales contract signed by both parties. After receiving the application, the system generates an application number BDC20240601001 and sends it back to Mr. Zhang. The system then processes the application number BDC20240601001 submitted by Mr. Zhang. Registration application 240601001 underwent basic verification. The document format verification confirmed that all electronic materials uploaded by Zhang were in PDF format and met the preset standards. The electronic signature verification, using the national cryptographic SM2 algorithm, confirmed that the electronic signature of the A City Real Estate Registration Center on the original real estate certificate was a legally authorized signature, complete and unaltered, and within its validity period. The electronic signatures of both parties on the second-hand housing sales contract also passed validity verification. Therefore, Zhang's registration application passed the basic verification. After Zhang's registration application passed the basic verification, the system retrieved three alternative borderline registration applications within the jurisdiction of B City. Real-time data for the nodes includes node 1 (CPU utilization 42%, memory utilization 35%, bandwidth utilization 52%, 5km from Zhang's location), node 2 (CPU utilization 58%, memory utilization 38%, bandwidth utilization 48%, 3km from Zhang's location), and node 3 (CPU utilization 38%, memory utilization 32%, bandwidth utilization 45%, 6km from Zhang's location). Node 2, which does not meet the preset edge node performance threshold, is excluded. Then, nodes 1 and 3 are normalized and scored. Specifically, this process includes... The real-time data acquired at point 3 is normalized using a min-max normalization method to obtain normalized data, including node 1 (1, 0, 1, 1) and node 3 (0, 1, 0, 0). Then, weights are assigned, including CPU utilization 0.3, memory usage 0.2, network bandwidth utilization 0.2, and geographical distance 0.3. Finally, node 1's comprehensive score is 0.8, and node 3's comprehensive score is 0.2. Since node 1's comprehensive score is higher than node 3's and meets all performance thresholds, it is identified as the target edge node and is responsible for processing Zhang's application for ownership transfer registration.

[0024] It should be noted that the real-time weight allocation is set in conjunction with the processing requirements of real estate registration business. CPU utilization has the highest weight because core businesses such as local verification and data encryption have high requirements for node computing power and are key factors affecting business processing efficiency. In order to shorten data transmission latency and improve the response speed of user business processing, the weight of geographical distance is set to be as high as that of CPU utilization. The weights of memory utilization and bandwidth utilization are next and the same. They affect the data storage capacity and data transmission stability of the node, respectively, and are important auxiliary factors to ensure the smooth operation of business. Therefore, in this embodiment, the weights can be set as CPU utilization 0.3, memory utilization 0.2, network bandwidth utilization 0.2, and geographical distance 0.3.

[0025] Step 2: Distribute the registration application to the target edge node for local verification, obtain the verification results, and obtain key registration data in combination with the business type.

[0026] Step 2 includes: The registration application is distributed to the target edge node, and the target edge node performs local verification on the registration application, including the completeness of electronic materials and the compliance of the format. If the local verification passes, the local verification result is obtained; if the local verification fails, feedback is sent to the user.

[0027] The integrity of the electronic materials includes the owner, location, area, and ownership type of the real estate, and the compliance of the format means that it conforms to the electronic data specifications for real estate registration.

[0028] If the business type of the registration application is involved, such as cross-regional mortgage, cross-regional ownership transfer, or cross-regional household registration information, cross-domain data collaboration will be triggered to obtain the collaborative verification results.

[0029] If the business type does not involve cross-domain operations, the sensitive registration information in the registration application will be encrypted and calculated to obtain encrypted registration data.

[0030] Key registration data is composed of collaborative verification results and encrypted registration data.

[0031] Specifically, the system distributes the registration application and related electronic materials to the target edge node in their entirety. The node initiates a local verification process, including the completeness of the electronic materials and their format compliance. The verification of the completeness of the electronic materials focuses on the owner, location of the real estate, area, and type of ownership, thereby ensuring that no key information necessary for the registration is missing. The format compliance verification includes a comprehensive check of the field naming, data format, and coding standards of the electronic materials. After the verification is completed, if both the completeness and compliance meet the requirements, a local verification result of "verified" is generated. If any dimension fails to meet the requirements, such as missing real estate area information or non-compliant data format, a verification result of "failed" is generated, and the missing or non-compliant item is located. Feedback is sent to the user through the government affairs APP, guiding the user to supplement the materials and resubmit.

[0032] Furthermore, the system extracts business type information from the registration application. The preset business types that need to trigger cross-domain data collaboration are three situations: off-site mortgage, cross-regional ownership transfer, and off-site household registration information verification. If the current business is determined to belong to one of the above three situations, the system will automatically trigger the cross-domain data collaboration process, in which the target edge node sends a collaboration request to the corresponding regional collaborative edge node. The request message must include core information such as the application number, the owner's unique ID, the collaborative node code, and the request node's consortium blockchain identity signature. After receiving the request, the collaborative edge node first verifies the validity of the request node's consortium blockchain identity signature and node permissions. After the verification is passed, it retrieves the relevant data stored locally for collaborative verification. After the verification is completed, a collaborative verification result is generated and fed back to the target edge node.

[0033] Furthermore, when the system determines that the business type does not involve cross-domain operations, it focuses on encrypting sensitive registration information in the registration application. The scope of the sensitive registration information is preset to include core information involving personal privacy or property security, such as the owner's identity information, real estate area calculation data, and mortgage amount data. The encryption calculation adopts the BGV homomorphic encryption method to realize information comparison and numerical calculation in the encrypted state. Subsequent verification operations can be completed without decryption. The preset parameters during the encryption process are a polynomial ring dimension of 2048, a large prime modulus size of 1024 bits, and an encryption depth of 3, thereby ensuring a balance between encryption strength and computational efficiency. After encryption is completed, encrypted registration data is generated for subsequent data transmission and evidence storage.

[0034] Taking the encryption of Zhang's house area calculation data of 120m2 as an example, the encryption process specifically includes: combining preset parameters such as polynomial ring dimension of 2048, large prime modulus of 1024 bits, and encryption depth of 3, the system initializes the BGV encryption core parameters, generates a polynomial ring R=Zq[x] / (xN+1), where R represents the polynomial ring, N=2048 is the polynomial ring dimension, q=21024 is the 1024-bit large prime modulus, Z represents the set of integers, Zq represents the set of integer residue classes modulo q, x represents the indeterminate element of the polynomial, and a key pair is generated, including a public key pk and a private key sk. The private key is a sparse polynomial within the ring, and the public key consists of the encryption evaluation key evk and the relinearization key rlk, adapting to the subsequent homomorphic operation requirements. Then, the plaintext data to be encrypted is converted into a plaintext polynomial m(x) within the polynomial ring R, such as 120m². Because BGV encryption is optimized for integer operations, 120 is directly mapped to an integer within the ring, and then converted into a polynomial of degree no more than N-1 through binary expansion, i.e., m(x) = 120x0, ensuring that the plaintext data adapts to the polynomial ring structure. The public key pk is used to encrypt the plaintext polynomial m(x), specifically by injecting random noise to achieve semantic security. The calculation is c(x) = pk1·u(x) + pk2·e(x) + m(x), where u(x) is a random polynomial within the ring used for obfuscation, e(x) is a small-noise polynomial within the ring with a preset noise range of [-5, 5] to ensure encryption security, and pk1 and pk2 are the two core components of the public key pk. Substituting the parameters: assuming u(x) is a randomly generated sparse polynomial, e(x) takes a noise value of 3, and pk1 and pk2 are pre-generated polynomials within the ring, then c(x) = pk1·u(x) + pk2·3 + 120·x0, and the generated c(x) is 120m2. The encrypted polynomial is obtained by the following steps: Because the coefficients of the encrypted polynomial are large, the system compresses the ciphertext through a modulus switching operation, reducing the modulus of the ciphertext coefficients from q=21024 to a sub-modulus q1=264 suitable for subsequent transmission. This reduces the amount of data transmitted while maintaining encryption strength. After compression, the final ciphertext c1(x) is output, which is the encrypted area calculation data. For sensitive character information such as Zhang's ID number in the case, the characters are first converted into integers corresponding to ASCII codes, such as 1 corresponding to 49 and Zhang corresponding to 24352. Then, the above steps are repeated to complete the encryption, ultimately generating encrypted registration data in a unified format.

[0035] It should be noted that traditional encryption schemes, such as symmetric and asymmetric encryption, require decryption before data processing. Sensitive data may be leaked during decryption. In contrast, BGV homomorphic encryption supports direct computation in the encrypted state, allowing for information comparison and numerical verification without exposing the original sensitive data. Furthermore, compared to other homomorphic encryption schemes like BFV and CKKS, BGV offers more stable support for integer operations, flexible encryption depth configuration, and pre-defined polynomial ring dimensions and large prime modulus parameters. This ensures strong security against quantum computing attacks while maintaining business processing efficiency, preventing delays in the registration process due to overly complex encryption operations. Thus, BGV homomorphic encryption achieves a balance between encryption strength, computational efficiency, and operational support.

[0036] In some possible embodiments, assuming the system distributes Zhang's registration application to target edge node 1, node 1 initiates local verification, including confirming that the electronic materials contain Zhang's owner information, property location information, building area and ownership type, and finding no missing core fields; simultaneously, it compares the data with GB / T... The 38541-2020 standard confirms that the field naming and data format of all electronic materials comply with the specifications, such as the correct format of the real estate unit number coding and the conformity of the legal classification of ownership type markings. Upon verification, node 1 generates a locally verified result and synchronizes it to the system. The system identifies Zhang's registration business type as a cross-regional ownership transfer, specifically a transfer from City A to City B, which requires triggering cross-domain data collaboration. Target edge node 1 sends a collaboration request to the corresponding collaborative edge node in City A. The request message includes the application number BDC20240601001, Zhang's ID number (i.e., the unique ID of the owner), the collaborative edge node code AZY-001 in City A, and node 1's consortium blockchain identity signature. After receiving the request, the collaborative edge node in City A verifies node 1's signature through the consortium blockchain. The system, having the necessary collaborative request permissions, retrieves the original registration information of Zhang's property in City A from its local storage. It confirms that the property is free from mortgages, seizures, or other restrictions on transfer, completes the collaborative verification, generates a collaborative verification result indicating that the property is unrestricted for transfer, and sends this result back to the target edge node 1 in City B. Since Zhang's property ownership transfer registration is within City B, which is a non-cross-domain transaction, the system triggers a sensitive information encryption process. It first obtains sensitive information including Zhang's ID number, contact information, and property area calculation data. The system uses a BGV homomorphic encryption scheme, encrypting the aforementioned sensitive information according to preset parameters: a polynomial ring dimension of 2048, a large prime modulus of 1024 bits, and an encryption depth of 3. This generates encrypted registration data, including the encrypted ID number (xxx***xxx) and the encrypted area calculation data.

[0037] Step 3: Establish a quantum-secure communication channel, transmit verification results and key registration data based on the quantum-secure communication channel, and obtain a data transmission confirmation receipt.

[0038] Step 3 includes: A quantum-secure communication channel is established based on a quantum key distribution protocol, generating quantum keys between the target edge node and the collaborating edge node, and between the target edge node and the consortium chain node.

[0039] Wherein, the collaborative edge node refers to other regional edge nodes that have cross-domain collaboration needs with the target edge node, and the consortium chain node refers to the authorized node that makes up the real estate registration consortium chain network.

[0040] Verification results and key registration data are transmitted through a quantum-secure communication channel, and a data transmission confirmation receipt is obtained after the transmission is completed.

[0041] Specifically, the system can establish a quantum-secure communication channel using the BB84 quantum key distribution protocol. This protocol utilizes quantum mechanical principles, such as the non-cloning property of photon polarization states, to generate keys. The channel establishment range is determined according to business needs, specifically between target edge nodes and collaborating edge nodes to meet cross-domain data transmission requirements, and between target edge nodes and consortium blockchain nodes to meet data storage and transmission requirements. Quantum keys are generated synchronously during channel establishment, with key generation scenarios precisely matching sensitive data transmission needs, namely, cross-domain collaborative sensitive data transmission and transmission of core information on real estate ownership. Furthermore, to ensure key security, a one-time pad strategy is adopted, and the quantum key is regenerated before each sensitive data transmission. If an interruption occurs during transmission, the system automatically triggers the key regeneration and distribution process.

[0042] The process of establishing a quantum-secure communication channel based on a quantum key distribution protocol includes the following steps: The communicating parties, such as the target edge node and the cooperating edge node, first agree on two sets of orthogonal photon polarization state basis sets for encoding binary information, typically a horizontal / vertical basis set and a 45° / 135° basis set. They also agree on the communication rules of a classical communication channel for subsequent basis set alignment, error checking, etc. The transmitting end, such as target edge node 1, randomly selects a basis set and prepares a single-photon sequence corresponding to the polarization state according to a preset key bit sequence. Then, it sends the single-photon sequence to the receiving end through the quantum channel. For example, if the transmitting end selects a horizontal / vertical basis set and needs to send bit 0, it prepares a horizontally polarized single photon; if it selects a 45° / 135° basis set and needs to send bit 1, it prepares a 135° polarized single photon. When receiving the single-photon sequence, the receiving end randomly selects one of the two agreed-upon basis sets to measure each single photon and records the bit value corresponding to the measured polarization state and the used... The measurement basis set is used in the following steps: The receiver informs the transmitter of its measurement basis set sequence via a classical communication channel. The transmitter compares its own transmitted basis set sequence with the receiver's measurement basis set sequence, retaining the bit sequences corresponding to the positions where the basis sets match as the original key, and discarding the bit sequences corresponding to the positions where the basis sets do not match. The transmitter randomly selects a portion of bits from the original key as a checksum and informs the receiver via the classical channel. Both parties compare the checksums and calculate the bit error rate. If the bit error rate exceeds a preset threshold, such as 10%, it is determined that there is eavesdropping or interference in the quantum channel, and the current key generation is terminated and the protocol is re-executed. If the bit error rate is within a safe range, the original key is processed using a privacy amplification algorithm, such as a general hash algorithm, to remove information that may be obtained by eavesdroppers and generate the final secure quantum key. After both parties complete the sharing of the secure quantum key, this quantum key is used as the session key, and a symmetric encryption algorithm is used to encrypt and protect sensitive data transmitted subsequently, such as verification results and key registration data.

[0043] Furthermore, the system categorizes and organizes the data to be transmitted, defining the scope of transmitted data as verification results and key registration data. The verification results include local verification results and collaborative verification results. The key registration data includes collaborative verification results and non-sensitive core information for cross-domain services, and encrypted registration data for non-cross-domain services. Then, a quantum key is provided to encrypt the transmitted data, which is transmitted through a quantum-secure communication channel to ensure that the data is not stolen or tampered with during transmission. After the data transmission is completed, the receiving end performs integrity verification on the received data. After confirming that the data is complete and unaltered, a data transmission confirmation receipt is generated. The receipt information includes core elements such as the application number, the list of transmitted data, the transmission time, and the signature of the receiving end, and is fed back to the sending end, i.e., the target edge node.

[0044] In some possible embodiments, for Zhang's cross-domain property transfer registration business, the system uses the BB84 protocol to establish a quantum-secure communication channel, including establishing a channel between the target edge node 1 in City B and the collaborating edge node in City A for transmitting sensitive data related to cross-domain collaboration, and establishing a channel between the target edge node 1 and the consortium blockchain node in City B; wherein, the collaborating edge node in City A is another regional edge node that has cross-domain collaboration needs with the target edge node 1, and the consortium blockchain node in City B is an authorized real estate registration center node with data storage authority; the system organizes Zhang's transmitted data, including local verification results, collaborative verification results, and key registration data, encrypts this data using a quantum key, and transmits it to the collaborating edge node in City A and the consortium blockchain node in City B respectively through the quantum-secure communication channel; after receiving the data, the collaborating edge node in City A verifies and confirms that the data is complete and tamper-proof, and generates a data list including application number BDC20240601001, transmission data list, and transmission time 2025-012-01. At 10:30:00, a transmission confirmation receipt with the node signature is sent to the target edge node 1. After receiving the data, the B City consortium chain node completes the same verification process, generates the corresponding transmission confirmation receipt, and sends it back. After the target edge node 1 successfully receives both receipts, it confirms that the data transmission is complete.

[0045] Step 4: Submit the verification results, key registration data, and data transmission confirmation receipt to the consortium blockchain network for notarization, obtain on-chain notarization feedback, trigger and execute the smart contract based on the on-chain notarization feedback, and obtain the contract execution result.

[0046] Step 4 includes: The verification results, key registration data, and data transmission confirmation receipts are submitted to the consortium blockchain nodes in the consortium blockchain network. These consortium blockchain nodes include real estate registration center nodes, edge computing nodes, government collaboration department nodes, and notary office nodes, and permissions are assigned to each consortium blockchain node.

[0047] The consortium blockchain nodes use the PBFT consensus algorithm to store and collaboratively process the submitted verification results, key registration data, and data transmission confirmation receipts, and obtain on-chain evidence storage feedback.

[0048] If the on-chain evidence storage feedback indicates successful storage, the smart contract in the consortium blockchain will be triggered and the contract content will be automatically executed to obtain the contract execution result.

[0049] The contract content refers to completing on-chain evidence storage and uploading, synchronizing the evidence storage results to all nodes on the consortium blockchain, generating a unique identifier for real estate registration business, and obtaining the contract execution result after execution.

[0050] Specifically, the system organizes the verification results, key registration data, and data transmission confirmation receipts into a standardized set of evidence-based data and submits it to the real estate registration consortium blockchain network. This consortium blockchain network consists of multiple authorized nodes, including real estate registration center nodes, edge computing nodes, government collaboration department nodes, and notary office nodes. Each node must be authorized by the consortium before joining the network. To ensure data security and controllable permissions, the system assigns differentiated permissions to different types of nodes. Real estate registration center nodes, as core management nodes, have data writing rights and are responsible for the input and management of core on-chain data. Edge computing nodes, including target edge nodes and collaborative edge nodes, have data verification rights and are responsible for pre-verifying the data submitted to the blockchain. Government collaboration department nodes have targeted query rights and can only query on-chain data related to their department's business. Notary office nodes have evidence verification rights and are responsible for verifying the legality and completeness of the on-chain evidence-based data.

[0051] It should be noted that, in this embodiment, the consortium blockchain network includes authorized nodes such as the B City Real Estate Registration Center node, Target Edge Node 1, A City Collaboration Edge Node, B City Tax Department node, and B City Notary Office node.

[0052] Furthermore, the consortium blockchain nodes employ the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm for consensus verification. This algorithm possesses high fault tolerance characteristics, ensuring the correctness of the consensus even when some nodes malfunction. During the consensus process, a preset consensus threshold is set at more than 2 / 3 of the effective nodes in the consortium blockchain. This means that more than 2 / 3 of the effective nodes must reach a consensus on the legality and completeness of the evidence storage data before consensus can be achieved. Simultaneously, a preset block generation time of 10 seconds is used to ensure evidence storage efficiency. After receiving the evidence storage data, each consortium blockchain node independently verifies the data, including the legality of the data source, data completeness, and consistency with business logic, and participates in consensus voting with the verification results. When the preset consensus threshold is reached, the system packages the evidence storage data into a block and writes it to the consortium blockchain, completing evidence storage and collaborative processing. Subsequently, on-chain evidence storage feedback is generated, containing core elements such as evidence storage status, evidence storage block number, and evidence storage time. If the consensus threshold is not reached, evidence storage failure feedback is generated, along with the specific reason.

[0053] The explanation regarding the consensus threshold setting includes the following: To balance the fault tolerance of the consortium blockchain with the credibility of the stored data, and to meet the security requirements of real estate registration services, a threshold needs to be set for consensus nodes. Since the fault tolerance limit of the PBFT algorithm is (n-1) / 3, where n is the number of valid nodes, setting a consensus threshold of more than 2 / 3 can effectively withstand malicious attacks or abnormal failures from up to 1 / 3 of the nodes, such as node offline, data tampering, or spoofing, ensuring that a correct consensus result can still be achieved even when some nodes are unreliable. Furthermore, real estate registration data is core government data, directly related to the property security of owners, and therefore requires extremely high data credibility. A high threshold of 2 / 3 or more can prevent a few nodes from manipulating the consensus result, ensuring the legality and authority of the evidence data. At the same time, considering that the consortium blockchain nodes are distributed in different regions, such as registration centers and government department nodes across cities, if the threshold is set to full node consensus, the evidence storage efficiency may be low due to delays or temporary failures of individual nodes. The 2 / 3 threshold can ensure security while taking into account the evidence storage efficiency and matching the timeliness requirements of real estate registration business. Therefore, in this embodiment, the consensus threshold can be set to 2 / 3 of the number of effective nodes in the consortium blockchain. That is, more than 2 / 3 of the effective nodes must reach a consensus on the legality and integrity of the evidence data in order to complete the consensus.

[0054] Furthermore, the smart contract is a pre-deployed, automatically executable code program on the consortium blockchain. Its triggering conditions are preset to successful on-chain notarization, successful local verification, successful cross-domain collaborative verification, and valid quantum key verification. The smart contract is only triggered to execute when all conditions are met. When the on-chain notarization feedback indicates successful notarization, and all other triggering conditions are met, the system automatically triggers the execution of the smart contract. The contract execution content completes the final on-chain confirmation of the notarized information; the notarization result is synchronized to all nodes on the consortium blockchain; a unique identifier for the real estate registration business is generated; after the smart contract is executed, a contract execution result is generated, which includes information such as execution status, unique business identifier, and a list of synchronized nodes.

[0055] In some possible embodiments, the system compiles Zhang's local verification results, collaborative verification results, key registration data, and two data transmission confirmation receipts into a data set for evidence storage, and submits it to the real estate registration consortium blockchain network. Simultaneously, permissions are assigned to each node: the B City Real Estate Registration Center node has the right to write data, responsible for recording Zhang's evidence storage data onto the chain; Target Edge Node 1 and the A City Collaborating Edge Node have the right to verify data, having completed the preliminary verification of the evidence storage data; the B City Tax Department node has the right to conduct targeted queries, only able to query on-chain data related to Zhang's real estate transaction; the B City Notary Office node has the right to verify evidence storage, and can subsequently verify the legality of the evidence storage data. For Zhang's evidence storage data, the six valid nodes in the consortium blockchain network, including the B City Registration Center node, Target Edge Node 1, A City Collaborating Edge Node, B City Tax Node, B City Notary Office node, and another edge node in B City, use the PBFT consensus algorithm to conduct consensus verification. After independent verification by each node, it is found that... All parties agreed that the evidence-stored data was legal and complete, consistent with Zhang's cross-domain ownership transfer business logic, achieving a 6 / 6 consensus vote, exceeding the 2 / 3 consensus threshold. The system completed block packaging within 10 seconds, writing Zhang's evidence-stored data into the consortium blockchain, generating block number BQK20240601005, and generating on-chain evidence-stored success feedback, which was synchronized to target edge node 1. Since Zhang's on-chain evidence-stored feedback indicated successful evidence-stored data, and other triggering conditions such as local verification passed, cross-domain collaborative verification passed, and quantum key verification valid were met, the system triggered the real estate registration smart contract in the consortium blockchain. The contract automatically executed preset content, including confirming that Zhang's evidence-stored data had been successfully uploaded to the chain; synchronizing the evidence-stored result to all 6 valid nodes in the consortium blockchain; generating a unique identifier for the real estate registration business, BDC-YW20240601001; after execution, the smart contract generated a successful execution result, including the unique business identifier and a list of all nodes that had completed the synchronization, and fed it back to the system.

[0056] Step 5: Securely store the contract execution results, obtain security credentials, verify the stored data in conjunction with the feedback, obtain the summary registration data, and generate the registration results.

[0057] Step 5 includes: Based on the contract execution result, and combined with the NTRU algorithm, the on-chain evidence data is encrypted a second time, and the quantum key in the quantum-secure communication channel is bound to the encrypted evidence data for storage to obtain a security certificate.

[0058] The verification results, key registration data, and contract execution results are combined to form the registration data.

[0059] The registration data, on-chain evidence feedback, and security credentials are checked for consistency. Once the check passes, the summary registration data is obtained, and the registration result is generated based on the summary registration data.

[0060] Specifically, based on the contract execution result, the system determines the scope of on-chain evidence storage data that requires secondary encryption, namely the core data such as the verification results, key registration data, and transmission confirmation receipts already written into the consortium blockchain in step 4. Secondary encryption is performed using the post-quantum cryptography NTRU algorithm, which is capable of resisting quantum computing attacks and effectively compensates for the security deficiencies of traditional encryption algorithms in the quantum era. After encryption, the system binds the quantum key in the quantum-secure communication channel with the secondary-encrypted evidence storage data, forming a dual security protection mechanism of secondary-encrypted data and quantum key. This ensures that even if the secondary-encrypted data is cracked, the original data cannot be obtained without the corresponding quantum key. After secondary encryption and binding storage are completed, the system generates a security certificate containing core elements such as encryption status, key binding information, evidence storage location, and generation time, which are used for subsequent consistency verification.

[0061] The process of performing secondary encryption using the post-quantum cryptography NTRU algorithm includes the following steps: the system first initializes the NTRU encryption core parameters, setting the polynomial ring as R=Z. q [x] / (x n-1), where R, q, Z, x, and n are all consistent with the physical meaning in step S2-3, but this step presets n=256, sets small integer modulo p and q, p=3, q=256, p and q are coprime, and then generates a key pair of private and public keys; converts the on-chain evidence storage data that needs to be encrypted twice into an integer sequence, and then maps it into a plaintext polynomial m(x) in the polynomial ring R, requiring the coefficients of the plaintext polynomial m(x) to be in the range of [-p / 2, p / 2], i.e. [-1, 1], to ensure that the plaintext is adapted to the input requirements of NTRU encryption; generates a random sparse polynomial r(x), the non-zero coefficients of which are also ±1, and the number of non-zero coefficients is preset to a fixed value, which is preset to 3 in this scheme), used to inject noise to To ensure the security of encrypted semantics and prevent identical plaintext from corresponding to identical ciphertext, encryption operations are performed based on the public key h(x), the plaintext polynomial m(x), and the random polynomial r(x), specifically represented as c(x) = r(x)·h(x) + m(x). Assuming r(x) is a sparse polynomial with 32 non-zero coefficients, h(x) is a public key polynomial pre-generated by the system, and m(x) is the encoded collaborative verification result polynomial, the ciphertext polynomial c(x) is finally obtained through polynomial multiplication and addition operations. This polynomial is the collaborative verification result data after secondary encryption. The above steps are repeated for all on-chain evidence storage data that requires secondary encryption. After completing the secondary encryption of all data, all ciphertext polynomials are integrated into a standardized ciphertext data set. Specifically, the central server acts as the verification entity, extracting registration data, on-chain evidence feedback, and security credentials for consistency verification. This verification includes the consistency between registration data and on-chain evidence data, the correlation between security credentials and registration data, and the consistency between evidence feedback and contract execution results. If the verification passes, the system determines the registration data as the aggregated registration data. If the verification fails, a data retransmission mechanism is triggered, requiring relevant nodes to re-upload the data and verify it again.

[0062] It should be noted that this embodiment involves two encryption steps. The first encryption focuses on protecting sensitive data during business processing. It encrypts original sensitive registration information that has not yet been stored on the blockchain, such as the owner's ID number and the original data for calculating the house area, thereby ensuring the security of this data before it is verified locally and transmitted to the consortium blockchain. The second encryption focuses on strengthening the protection of long-term on-chain storage. It encrypts core data that has already been stored on the blockchain, such as verification results and key registration data, adding an extra security barrier for long-term data storage and addressing potential security risks during long-term storage. The first encryption uses a homomorphic encryption algorithm, which supports direct computation in the encrypted state. Subsequent information comparison, numerical verification, and other business operations can be completed without decryption, adapting to the complex data processing involved in the business process. Application requirements; Secondary encryption is a non-homomorphic encryption algorithm that does not support encrypted state operations, resulting in higher encryption / decryption efficiency and lighter computation, adapting to the performance requirements of secondary encryption of large amounts of evidence data stored on the chain; Meanwhile, the polynomial ring of primary encryption uses a large prime modulus to ensure high encryption strength, and also needs to be configured with encryption depth to adapt to multiple rounds of homomorphic operations; The polynomial ring of secondary encryption uses two small integer moduli, resulting in lower polynomial degree and smaller modulus value, significantly reducing computational complexity; Primary encryption is a single encryption protection, and the encrypted data can be directly used for subsequent transmission and business processing; Secondary encryption is the core component of dual protection, and the encrypted data needs to be bound to a quantum key for storage, forming a dual security mechanism of secondary encrypted data and quantum key. Decryption can only be achieved by simultaneously obtaining the ciphertext and the corresponding quantum key, resulting in a higher level of security.

[0063] In some possible embodiments, the system extracts on-chain evidence storage data based on Zhang's contract execution result, including local verification results, collaborative verification results, key registration data, and transmission confirmation receipts. This data is then encrypted a second time using the NTRU algorithm. The quantum key generated by the quantum-secure communication channel is bound to the second-encrypted evidence storage data and stored in the designated secure storage area of ​​the consortium blockchain. The system generates a security certificate, whose information is double-encrypted, the key is successfully bound, and the evidence storage location is the auxiliary storage area of ​​block BQK20240601005, with a generation time of 2025-06-01. At 10:45:00, the data is synchronized to the central server. The B City Real Estate Registration Center server extracts Zhang's registration data, on-chain evidence feedback, and security credentials for consistency verification. The verification confirms that the registration data is completely consistent with the on-chain evidence data, the encrypted data corresponding to the security credentials is Zhang's registration data, and the evidence storage success status matches the contract execution success status. The verification passes, and the registration data is determined to be the summary registration data. The system generates registration results based on the summary registration data, clearly indicating the registration completion status, including core information of the electronic real estate ownership certificate, including certificate number, owner, property information, and business processing serial number. Subsequently, the system sends feedback to Zhang via the B City Government Affairs APP and SMS notification, while providing a download link for the electronic real estate ownership certificate.

[0064] Specifically, a multi-source data-driven real estate registration system includes: The verification module is used to perform basic verification on the registration application, distribute the registration application to the target edge node for local verification, obtain the verification result, perform verification based on security credentials and evidence feedback, obtain summary registration data and generate registration result; The filtering module filters edge nodes based on verified registration applications and in conjunction with load balancing processing to obtain target edge nodes; The processing module obtains key registration data based on verification results and business type, triggers and executes smart contracts based on on-chain evidence storage feedback, and obtains contract execution results. The building module is used to establish a quantum-safe communication channel; The transmission module transmits verification results and key registration data based on a quantum-secure communication channel and obtains a data transmission confirmation receipt. The notarization module securely notifies the contract execution results, obtains security credentials, submits the verification results, key registration data, and data transmission confirmation receipt to the consortium blockchain network for notarization, and obtains on-chain notarization feedback; based on the on-chain notarization feedback, it triggers and executes the smart contract to obtain the contract execution results.

[0065] The specific usage and function of this embodiment are explained below: First, registration applications are received and basic verification is performed. Based on the verified applications, edge nodes are screened using load balancing to identify target edge nodes. Registration applications are then distributed to these target edge nodes for local verification, and verification results are obtained. Key registration data is then extracted based on the business type. Next, a quantum-secure communication channel is established to transmit the verification results and key registration data, obtaining a data transmission confirmation receipt. Finally, the verification results, key registration data, and data transmission confirmation receipt are submitted to the consortium blockchain network for notarization, obtaining on-chain notarization feedback. Based on this feedback, a smart contract is triggered and executed, and the contract execution result is obtained. Finally, the contract execution... The process involves securely storing the registration results, obtaining security credentials, and verifying them using the stored evidence feedback. This process then summarizes the registration data and generates the registration results. By employing a triple security protection mechanism—BGV homomorphic encryption, NTRU secondary encryption, and quantum-secure communication—the security of data storage is enhanced. Furthermore, by clearly defining cross-domain collaboration trigger conditions and establishing an efficient collaborative verification mechanism between target edge nodes and collaborating edge nodes, combined with a quantum-secure communication channel, secure and rapid cross-domain data transmission is achieved. This shortens the processing cycle for cross-domain registration services, thereby improving cross-domain collaboration efficiency. This real estate registration method addresses the insufficient security protection in existing technologies, thus enhancing the security of real estate registration services.

[0066] This embodiment provides an electronic device, which may include: at least one processor, at least one network interface, a user interface, a memory, and at least one communication bus.

[0067] The following is a detailed introduction to the various components of the electronic device: The communication bus can be used to enable communication between the various components mentioned above.

[0068] The user interface may include buttons, and optional user interfaces may also include standard wired interfaces and wireless interfaces.

[0069] The network interface may include, but is not limited to, Bluetooth modules, NFC modules, Wi-Fi modules, etc.

[0070] The processor may include one or more processing cores. It connects various parts of the electronic device via various interfaces and lines, executing instructions, programs, code sets, or instruction sets stored in memory, and accessing data stored in memory to perform various functions and process data. Optionally, the processor can be implemented using at least one hardware form of DSP, FPGA, or PLA. The processor can integrate one or more of the following: CPU, GPU, and modem, for example, one or more digital signal processors (DSPs) or one or more field-programmable gate arrays (FPGAs). The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip without being integrated into the processor.

[0071] The memory may include RAM or ROM. Optionally, the memory may include a non-transitory computer-readable medium. The memory may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (e.g., touch function, sound playback function, image playback function, etc.), instructions for implementing the various method embodiments described above, etc.; the data storage area may store data involved in the various method embodiments described above, etc. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor. The memory, as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an evaluation application. The processor may be used to call the evaluation application stored in the memory and execute the method steps mentioned in the foregoing embodiments.

[0072] It should be noted that the above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0073] The above embodiments can be implemented, in whole or in part, through software, hardware (such as circuits), firmware, or any other combination thereof.

[0074] When implemented using software, the above embodiments can be implemented in whole or in part as a computer program product, which includes one or more computer instructions or computer programs; when the computer instructions or computer programs are loaded or executed on a computer, the processes or functions described in the embodiments of the present invention are generated in whole or in part.

[0075] It is understood that the computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device; the computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via transmission methods such as infrared, wireless, or microwave; the computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0076] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0077] It should be understood that, in the embodiments of the present invention, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0078] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A multi-source data-driven method for real estate registration, characterized in that, It includes the following steps: Receive registration applications and perform basic verification. Based on the verified registration applications, and in conjunction with load balancing processing, filter edge nodes to obtain target edge nodes. The registration application is distributed to the target edge node for local verification, the verification results are obtained, and key registration data is obtained in combination with the business type; Establish a quantum-safe communication channel, transmit verification results and key registration data based on the quantum-safe communication channel, and obtain data transmission confirmation receipts; The verification results, key registration data, and data transmission confirmation receipt are submitted to the consortium blockchain network for storage, and on-chain storage feedback is obtained. Based on the on-chain storage feedback, the smart contract is triggered and executed to obtain the contract execution result. Securely store the contract execution results, obtain security credentials, verify the stored data in conjunction with the feedback, obtain aggregated registration data, and generate registration results.

2. The multi-source data-driven real estate registration method according to claim 1, characterized in that, The system receives registration applications and performs basic verification. Based on the verified applications, and in conjunction with load balancing, it filters edge nodes to obtain target edge nodes, including: Receive registration applications containing electronic materials, including information on the property owner, information on the location of the property, and electronically signed ownership certificates. The registration application is subject to basic verification, which includes document format verification and electronic signature verification. The registration applications that have passed the basic verification are load balanced using a weighted round-robin algorithm. The target edge nodes are selected by comprehensively considering the CPU utilization, memory usage, network bandwidth utilization, and geographical distance of the edge nodes. The target edge node must meet a preset performance threshold.

3. The multi-source data-driven real estate registration method according to claim 1, characterized in that, The registration application is distributed to the target edge node for local verification, the verification results are obtained, and key registration data is retrieved based on the business type, including: The registration application is distributed to the target edge node, and the registration application is locally verified based on the target edge node, including the completeness of electronic materials and the compliance of the format. If the local verification passes, the local verification result is obtained; if the local verification fails, feedback is sent to the user. The integrity of the electronic materials includes the owner, location, area and ownership type of the real estate, and the compliance of the format means that it conforms to the electronic data specifications for real estate registration. If the business type of the registration application is involved, such as cross-regional mortgage, cross-regional ownership transfer, or cross-regional household registration information, cross-domain data collaboration will be triggered to obtain the collaborative verification results. If the business type does not involve cross-domain operations, the sensitive registration information in the registration application will be encrypted and calculated to obtain encrypted registration data. Key registration data is composed of collaborative verification results and encrypted registration data.

4. The multi-source data-driven real estate registration method according to claim 1, characterized in that, Establish a quantum-secure communication channel, transmit verification results and key registration data based on the quantum-secure communication channel, and obtain data transmission confirmation receipts, including: A quantum-secure communication channel is established based on a quantum key distribution protocol to generate quantum keys between the target edge node and the collaborating edge node, and between the target edge node and the consortium chain node. Wherein, the collaborative edge node refers to other regional edge nodes that have cross-domain collaboration needs with the target edge node, and the consortium chain node refers to the authorized node that makes up the real estate registration consortium chain network; Verification results and key registration data are transmitted through a quantum-secure communication channel, and a data transmission confirmation receipt is obtained after the transmission is completed.

5. The multi-source data-driven real estate registration method according to claim 1, characterized in that, The verification results, key registration data, and data transmission confirmation receipts are submitted to the consortium blockchain for notarization. On-chain notarization feedback is obtained, and a smart contract is triggered and executed based on this feedback to obtain the contract execution results, including: The verification results, key registration data, and data transmission confirmation receipts are submitted to the consortium blockchain nodes in the consortium blockchain network. The consortium blockchain nodes include real estate registration center nodes, edge computing nodes, government collaboration department nodes, and notary office nodes, and permissions are assigned to each consortium blockchain node. The consortium blockchain nodes use the PBFT consensus algorithm to store and collaboratively process the submitted verification results, key registration data, and data transmission confirmation receipts, and obtain on-chain evidence storage feedback. If the on-chain evidence storage feedback indicates successful storage, the smart contract in the consortium blockchain will be triggered and the contract content will be executed automatically to obtain the contract execution result. The contract content refers to completing on-chain evidence storage and uploading, synchronizing the evidence storage results to all nodes on the consortium blockchain, generating a unique identifier for real estate registration business, and obtaining the contract execution result after execution.

6. The multi-source data-driven real estate registration method according to claim 1, characterized in that, Securely store evidence based on the contract execution result, obtain security credentials, verify the evidence storage feedback, obtain summary registration data, and generate registration results, including: Based on the contract execution result, and combined with the NTRU algorithm, the on-chain evidence data is encrypted twice, and the quantum key in the quantum-secure communication channel is bound and stored with the twice-encrypted evidence data to obtain a security certificate. The verification results, key registration data, and contract execution results are combined to form the registration data. The registration data, on-chain evidence feedback, and security credentials are checked for consistency. Once the check passes, the summary registration data is obtained, and the registration result is generated based on the summary registration data.

7. A multi-source data-driven real estate registration system, used to implement the method described in any one of claims 1-6, characterized in that, include: The verification module is used to perform basic verification on the registration application, distribute the registration application to the target edge node for local verification, obtain the verification result, perform verification based on security credentials and evidence feedback, obtain summary registration data and generate registration result; The filtering module filters edge nodes based on verified registration applications and in conjunction with load balancing processing to obtain target edge nodes; The processing module obtains key registration data based on verification results and business type, triggers and executes smart contracts based on on-chain evidence storage feedback, and obtains contract execution results. The building module is used to establish a quantum-safe communication channel; The transmission module transmits verification results and key registration data based on a quantum-secure communication channel and obtains a data transmission confirmation receipt. The notarization module securely notifies the contract execution results, obtains security credentials, submits the verification results, key registration data, and data transmission confirmation receipt to the consortium blockchain network for notarization, and obtains on-chain notarization feedback; based on the on-chain notarization feedback, it triggers and executes the smart contract to obtain the contract execution results.

Images