Authority survey process automation system based on intelligent contract

Abstract

The invention relates to the technical field of administrative process automation management, and particularly discloses a smart contract-based authority survey process automation system, which comprises a task initialization module used for generating a unique task identifier and starting an authority verification process; the distributed query module queries the government affair database in parallel through an oracle alliance network; the consensus verification module is used for verifying the consistency of query results by adopting a Byzantine fault-tolerant consensus mechanism and cooperatively generating a threshold signature; the state synchronization module is used for atomizing and synchronizing the threshold signature to an intelligent contract and government affair database to realize on-chain state propulsion and off-chain resource locking; and the process completion module is used for automatically triggering government affair database state unlocking when the process is finished.

Description

Technical Field

[0001] This invention relates to the field of administrative process automation management technology, specifically to a smart contract-based automated system for property rights investigation processes. Background Technology

[0002] Property rights investigation, a core component of real estate management, involves collaborative work among multiple government departments, including natural resources, taxation, and planning. Traditional processes heavily rely on paper documents and manual verification, resulting in inefficiency, insufficient transparency, and a high risk of errors. With the development of blockchain technology, existing solutions attempt to automate processes through smart contracts, encoding property rights verification rules into executable logic to improve efficiency and reliability. However, blockchain systems and existing government databases are on heterogeneous platforms, presenting technical bottlenecks in data interaction and state synchronization.

[0003] Existing blockchain-based land ownership investigation systems often rely on centralized oracles or simple data interfaces to achieve cross-platform collaboration, which has the following drawbacks: the operation of on-chain smart contracts and off-chain government databases lacks atomicity guarantees, and the states of the two parties are easily inconsistent due to network latency or node failure. Centralized oracles may become a single point of failure or a source of risk for data tampering, and cannot ensure the credibility and resistance to attacks of data in distributed scenarios. Summary of the Invention

[0004] The purpose of this invention is to provide an automated system for the ownership investigation process based on smart contracts, in order to solve the problems mentioned above.

[0005] The objective of this invention can be achieved through the following technical solutions: A smart contract-based automated system for property rights investigation processes includes: The task initialization module is used to receive ownership investigation requests and generate a unique task identifier, and initiate the ownership verification process associated with the task identifier through a smart contract deployed in the blockchain network. The distributed query module receives verification requests sent by the smart contract through an oracle alliance network composed of multiple independent nodes. Each node initiates a query operation in parallel with the government database based on the received request and obtains the query results. The consensus verification module, within the oracle alliance network, uses a Byzantine fault-tolerant consensus mechanism to verify the consistency of query results obtained by each node. When a consensus is reached, each node collaborates to generate a threshold signature. The state synchronization module is used to synchronously send threshold signatures to smart contracts and government databases, including: Once the threshold signature sent to the smart contract is verified, the ownership verification process is initiated. The threshold signature sent to the government database is used to perform state locking operations, enabling real-time synchronization between the government database resource status and the blockchain verification status; The process completion module is used to send a status unlocking command to the government database via a smart contract when the land ownership investigation process is completed on the blockchain network, thereby completing cross-system status synchronization.

[0006] As a further aspect of the present invention: the initiation of the ownership verification process associated with the task identifier specifically includes: When receiving a property rights survey request, a task identifier with spatiotemporal uniqueness is generated. The request timestamp, digital digest of real estate geographic coordinates, blockchain, and latest block hash are superimposed in a three-layer calculation to form an unpredictable and non-repeatable identifier sequence. The generated task identifier is bidirectionally bound to real estate resource information. A mapping table between resource information feature vectors and identifiers is constructed, and the digital fingerprint of the mapping table is stored in the distributed ledger of the blockchain. The smart contract automatically activates the corresponding title verification workflow by parsing the feature parameters in the task identifier. The workflow intelligently matches the preset verification rule set according to the real estate type and initializes the verification state machine to the state to be verified. At the same time the verification process is initiated, the smart contract creates a dedicated state storage area on the blockchain. The storage area uses a Merkle tree structure to record all state change trajectories during the verification process.

[0007] As a further aspect of the present invention: the specific operations for obtaining the query results include: The Oracle Consortium Network adopts a hierarchical query strategy, parsing verification requests into core data items and auxiliary data items. The core data items are queried in parallel by all nodes, while the auxiliary data items are queried according to the characteristics of the nodes. When each query node initiates a query to the government database, it establishes a secure channel through two-way authentication based on blockchain digital certificates and embeds a digital signature of the task identifier in the query request. After each node obtains the query results, it first performs data format standardization processing locally, converting the heterogeneous data returned by different government databases into a unified structured data format; The node combines the standardized query results with its metadata into a data packet to be verified, which includes the query timestamp, data source identifier, and processing summary.

[0008] As a further aspect of the present invention: the query results also include a query quality assessment mechanism. After a node completes a query operation, it automatically generates a query quality report, which includes evaluation indicators in three dimensions: response latency, data integrity, and format compliance. The node submits the query results and the quality report together to the consensus verification module of the Oracle Consortium Network, where the quality report serves as an auxiliary decision-making basis for consensus verification. During the consensus verification process, the system prioritizes selecting node data with higher query quality assessment scores as benchmark references, and marks and performs secondary verification on abnormal query results. The system dynamically adjusts node query permissions based on historical query quality assessment results, and downgrades nodes with low-quality queries.

[0009] As a further aspect of the present invention: the adoption of a Byzantine fault-tolerant consensus mechanism to verify the consistency of query results obtained by each node specifically includes: The query results submitted by each node are converted into standardized feature vectors, and a data consistency relationship graph between nodes is established by calculating the similarity distance between feature vectors. A multi-round voting mechanism is used for consensus verification. In each round of voting, nodes evaluate the credibility of the query results of neighboring nodes and vote based on the local data consistency graph. After each round of voting, the voting weights of each node are adjusted, with higher weights given to nodes that consistently provide consistent results and weight decay applied to nodes that output abnormal results. After a preset number of rounds of iterative voting, when more than a threshold of nodes reach a consensus on a query result, the system determines that a valid consensus has been reached and marks the query result as trustworthy data.

[0010] As a further aspect of the present invention: when consensus is reached, the nodes collaboratively generate a threshold signature, specifically including: After confirming that a valid consensus has been reached, the system designates the node with the highest credibility weight as the signature coordinator, which is responsible for initializing the threshold signature generation process. Each participating node uses its own private key shard to digitally sign the consensus query result, generating a personal signature shard, and submits the signature shard to the signature coordinator; Once the signature coordinator has collected a sufficient number of valid signature fragments, these fragments are combined into a complete threshold signature. The system verifies the generated threshold signature to ensure that it can pass the verification of the corresponding public key, and outputs the verified threshold signature as a valid credential of the consensus result.

[0011] As a further aspect of the present invention: the step of synchronously sending the threshold signature to the smart contract and the government database specifically includes: The atomic broadcast protocol is used to simultaneously distribute threshold signatures to smart contracts and government database systems, ensuring that both systems receive valid threshold signatures at the same time, or neither receives them at all. After receiving the threshold signature, the smart contract verifies the integrity and validity of the signature. The verification process includes signature format check, issuer authentication, and timeliness verification. Once the signature verification is successful, the ownership verification status will be advanced from the current state to the next legal state, and the state transition transaction will be recorded on the blockchain. The smart contract generates a state transition proof, which includes the new state value, the state transition timestamp, and a threshold signature digest that has been verified.

[0012] As a further aspect of the present invention: the threshold signature sent to the government database is used to perform a state locking operation, specifically including: After receiving the threshold signature, the government database first verifies the validity of the signature and confirms that the signature comes from a legitimate oracle consortium network. After the signature verification is successful, the government database sets a temporary lock status on the target real estate record. The lock status includes a task identifier, a lock timestamp, and expected unlock conditions. The government database generates a lock status certificate and returns a digital summary of the lock status certificate to the status synchronization module, which then records the summary on the blockchain. The status synchronization module continuously monitors the status of the ownership verification process on the blockchain. When it detects that the process is completed or terminated, it automatically triggers the unlocking command of the government database.

[0013] As a further aspect of the present invention: the step of sending a status unlock command to the government database via a smart contract specifically includes: When the smart contract detects that the ownership investigation process is completed, it automatically generates a structured status unlock instruction, which includes a task identifier, a process completion timestamp, and a blockchain transaction hash. A transactional message queue is used to transmit status unlocking commands to the government database, ensuring that commands are not lost or duplicated during transmission and that a strict order is maintained. After the government database performs the status unlocking operation, it generates a digital receipt containing the unlocking timestamp and operation status, and returns the encrypted digest of the digital receipt to the smart contract. The smart contract verifies the validity of the digital receipt, confirms that the government database status unlocking operation is completed, and records the final status synchronization completion event on the blockchain.

[0014] The beneficial effects of this invention are: (1) This invention encapsulates the distribution of threshold signatures, the advancement of on-chain state, and the locking of off-chain database into a single logical atomic operation through an atomic broadcast protocol and a two-way state synchronization mechanism. Specifically, the state synchronization module ensures that the smart contract and the government database either receive and process the threshold signature simultaneously, or neither receives it; after the government database executes the lock, it generates a certificate and stores it on the blockchain; when the process is completed, the smart contract automatically triggers the unlock. This series of designs ensures that the resource states of the blockchain and the government database remain synchronized in real time throughout the entire ownership verification lifecycle, thereby avoiding business interruptions and data errors caused by state splits and improving the reliability and business continuity of the system.

[0015] (2) This invention establishes a decentralized, trusted data verification system by constructing an oracle consortium network composed of multiple independent nodes and introducing a Byzantine fault-tolerant consensus mechanism and threshold signature technology. The failure or malicious behavior of a single or a few nodes will not affect the overall output of the system. After data is obtained through distributed querying, consensus must be reached through multiple rounds of voting within the network, and finally, multiple nodes collaborate to generate a threshold signature as a valid credential. This allows smart contracts to trust not any single node, but rather the final result generated by cryptographically guaranteed collective consensus. Attached Figure Description

[0016] The invention will now be further described with reference to the accompanying drawings.

[0017] Figure 1 This is a flowchart of the system 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] Please see Figure 1 As shown, this invention is an automated system for property rights investigation processes based on smart contracts, comprising: The task initialization module is used to receive ownership investigation requests and generate a unique task identifier, and initiate the ownership verification process associated with the task identifier through a smart contract deployed in the blockchain network. The distributed query module receives verification requests sent by the smart contract through an oracle alliance network composed of multiple independent nodes. Each node initiates a query operation in parallel with the government database based on the received request and obtains the query results. The consensus verification module, within the oracle alliance network, uses a Byzantine fault-tolerant consensus mechanism to verify the consistency of query results obtained by each node. When a consensus is reached, each node collaborates to generate a threshold signature. The state synchronization module is used to synchronously send threshold signatures to smart contracts and government databases, including: Once the threshold signature sent to the smart contract is verified, the ownership verification process is initiated. The threshold signature sent to the government database is used to perform state locking operations, enabling real-time synchronization between the government database resource status and the blockchain verification status; The process completion module is used to send a status unlocking command to the government database via a smart contract when the land ownership investigation process is completed on the blockchain network, thereby completing cross-system status synchronization.

[0020] In the task initialization module, during the stage of receiving property rights survey requests, the system acquires complete real estate information data through various data acquisition devices. The specific data acquisition process includes: using professional surveying equipment equipped with a global navigation satellite system to collect precise geographic coordinates of the real estate; using a high-precision laser rangefinder to obtain building boundary dimensions; and using a digital measuring camera to capture on-site real-world images of the real estate. Simultaneously, the system extracts historical registration records, owner information, and neighbor relationship data for the real estate from the real estate registration system. All collected data is transmitted to the system's data processing center via an encrypted data transmission channel, employing digital signature technology during transmission to ensure data integrity and authenticity. The data processing center performs format and logical checks on the received data, verifying the completeness of data items and the rationality of data values. Data items that do not meet the specifications are marked and required to be re-collected. The verified data is categorized and stored in a temporary database, preparing for the subsequent generation of task identifiers.

[0021] In the task identifier generation phase, the system employs a multi-source data fusion algorithm to create a spatiotemporally unique identifier sequence. The specific generation process is as follows: First, three core elements are extracted from the verified data: the precise timestamp of the data acquisition device, the standardized digital digest of the real estate's geographic coordinates, and a hash value fragment from the latest confirmed block of the blockchain network. The timestamp uses an international standard format, accurate to the millisecond level; the geographic coordinate digital digest is generated by converting latitude and longitude coordinates to a unified standard coordinate system and then standardizing it; the blockchain hash value is taken from a specific length fragment in the header of the latest block of the current blockchain. The system combines these data elements according to a preset arrangement order to form a composite data sequence. Subsequently, a cryptographic hash operation is performed on this data sequence to generate a fixed-length numerical sequence as the task identifier. The entire generation process is conducted in a secure and encrypted environment to ensure that intermediate results are not leaked. The generated task identifier is immediately registered in the system's identifier management registry, and the detailed timestamp and related parameters are recorded.

[0022] During the binding relationship establishment phase, the system bidirectionally associates the generated task identifier with real estate resource information. The specific implementation process includes: first, constructing a feature vector for the real estate resource information, which contains standardized data across multiple dimensions such as geographical location, building structure, and ownership characteristics. The system establishes a mapping table between the task identifier and the feature vector, employing a hierarchical index structure to support fast querying and verification. Each record in the mapping table contains complete association information, including the task identifier, feature vector digest, binding timestamp, and operator digital signature. After completing the mapping table construction, the system calculates the digital fingerprint of the table and generates a unique digest value using a cryptographic hash function. This digital fingerprint, along with the task identifier, timestamp, and other information, is submitted to the blockchain network and recorded in the distributed ledger through smart contract execution. The record on the blockchain contains the complete information of the digital fingerprint, the submission timestamp, and the transaction hash, forming an immutable binding proof.

[0023] During the activation of the verification workflow, the smart contract automatically initiates the corresponding title verification process by parsing the feature parameters in the task identifier. The smart contract first verifies the legality and validity of the task identifier, checking whether it has been registered on the blockchain and is not currently in use. Then, based on the real estate type characteristics encoded in the task identifier, the smart contract selects an applicable set of verification rules from a pre-defined rule base. The rule selection process is based on a feature matching algorithm, comprehensively considering factors such as the real estate's use type, building structure, and geographical location. The selected set of verification rules includes specific verification items such as area calculation rules, boundary point verification rules, and adjacent relationship verification rules. The smart contract initializes the verification state machine according to the rule set, setting the initial state to "pending verification" and configuring state transition conditions and corresponding processing logic. State machine initialization includes setting timeout parameters, defining state transition events, and configuring exception handling mechanisms, establishing a complete operational framework for the subsequent automated verification process.

[0024] During the state storage creation phase, smart contracts establish a dedicated state storage structure on the blockchain to record the verification process. This storage area uses a Merkle tree structure to organize data. The leaf nodes of the tree store various state data generated during the verification process, including measurement data verification results, ownership information verification records, and adjacent relationship confirmation information. Each state change generates a new leaf node and establishes a link with its parent node through a hash pointer. The root hash value of the Merkle tree is periodically updated and recorded in the blockchain's transaction records, ensuring the verifiability and immutability of the entire state change history. The state storage area also includes metadata management, responsible for recording the time sequence of state changes, operator identity information, and explanations of the reasons for the changes. The storage area has an access control mechanism; only authorized participants can write state data, but all participants can verify the integrity of the state data. This design ensures both data security and process transparency, providing reliable technical guarantees for ownership verification.

[0025] In the distributed query module, during the hierarchical query strategy execution phase, after receiving the verification request from the smart contract, the oracle consortium network first performs structured parsing of the request content. The system categorizes the query requirements within the request into two levels: core data items and auxiliary data items, based on the importance and difficulty of data retrieval. Core data items include key property rights information such as real estate registration status, property owner information, and land use nature. This data is queried in parallel by all available nodes in the consortium network, improving the reliability and completeness of the query results through multi-source data collection. Auxiliary data items include supplementary information such as historical transaction records, neighbor relationship information, and planning restrictions. This data is allocated for querying based on the characteristics and expertise of each node. Specifically, the allocation process involves the system first analyzing the type and data coverage of the government database connected to each node, and then assigning different auxiliary data query tasks to the most suitable node based on the matching results between the query content and the node's expertise. After the query tasks are allocated, the system generates a query task allocation table, recording the data items each node is responsible for querying and their query priority. This allocation table is shared within the consortium network to ensure that each node clearly understands its query responsibilities.

[0026] During the secure query channel establishment phase, each query node needs to establish a secure and reliable communication connection before initiating a query operation to the government database. The specific process for establishing a secure channel is as follows: First, the query node presents its identity credentials based on a blockchain digital certificate to the target government database. This certificate is uniformly issued by the consortium network and contains key information such as the node's unique identifier, public key information, and certificate validity period. After verifying the validity of the node's certificate, the government database returns its own server certificate to the query node, completing the two-way authentication process. Based on the successful certificate verification, both parties negotiate and generate a session key using an asymmetric encryption algorithm. All subsequent query requests and returned data will be encrypted and transmitted using this session key. When constructing a specific query request, the query node embeds a digital signature of the task identifier in the request message header. This signature is generated by encrypting the task identifier and query timestamp using the node's private key. After receiving the query request, the government database can verify the digital signature to confirm the legitimacy and integrity of the query request, preventing the query request from being tampered with during transmission.

[0027] During the data format standardization phase, after each query node retrieves the original query results from the government database, it needs to convert the heterogeneous data returned from different data sources into a unified structured format. The specific operations of standardization include: First, the node performs syntax parsing on the original data, identifying each field and its value. Then, according to the system's predefined field mapping rules, it converts the source data fields into corresponding fields in the standard data model. For numerical data, the system standardizes the units of measurement and precision requirements; for example, it standardizes the area unit to square meters and the monetary unit to yuan, retaining two decimal places. For text data, the system performs character set conversion, uniformly converting all text content to UTF-8 encoding format while removing redundant spaces and special characters. For date and time data, the system uniformly adopts the ISO 8601 standard format. During the data conversion process, the node records detailed conversion logs, including the original data values, the converted data values, and the applied conversion rules. These logs serve as important evidence for data quality assessment. After completing the format conversion, the node also performs logical validation on the data, checking whether the data values ​​are within a reasonable range and whether there are logical contradictions between fields.

[0028] During the query result encapsulation phase, nodes combine the standardized query results with relevant metadata into a data packet to be verified. The main body of the data packet contains the standardized query result data, including all fields and their values ​​obtained from the government database. The metadata portion contains a complete record of the query process, specifically including the query start timestamp, query completion timestamp, query duration, the government database identifier from which the data originated, the interface version number used for the query, and the query operator identifier. In addition, the data packet includes a processing summary, recording all transformation operations and verification results performed during data standardization. After assembling the data packet, the node calculates its hash value and digitally signs the hash value using its private key to ensure the integrity and authenticity of the data packet. The signed data packet is temporarily stored in the node's secure cache, awaiting submission to the consensus verification module for further processing. Each data packet is assigned a unique sequence number, which is associated with a task identifier and used to track the processing status of the data packet in subsequent processes.

[0029] During the query quality assessment mechanism execution phase, nodes automatically generate detailed query quality reports after completing query operations. The quality assessment includes three dimensions: response latency, which calculates query time by recording the time difference between the query request sending time and the result return time, and compares it with a preset reasonable time threshold; data integrity, which measures the fill rate of each field in the returned data, statistically analyzing the ratio of the actual number of filled fields to the required number; and format compliance, which assesses the degree of difference between the original data and the standard format, recording the number of fields requiring conversion and the data correction during the conversion process. The assessment results for each dimension are quantified into specific scores, and then a comprehensive quality score is generated according to a preset weighting formula. During the quality score calculation, the system considers the characteristics of different data types and sets different scoring weights for different types of queries. For example, for core rights and obligations data, the weight of data integrity is set higher; while for auxiliary reference data, the weight of response latency may be relatively higher.

[0030] During the quality report submission and usage phase, nodes package their query results and quality reports together and submit them to the consensus verification module of the Oracle Consortium Network. The quality report serves as a crucial auxiliary decision-making basis for consensus verification, playing a key role in the consensus formation process. Upon receiving the data submitted by each node, the consensus verification module first analyzes the various indicators in the quality report, paying particular attention to query results with low scores in a particular dimension. The system prioritizes node data with higher quality assessment scores as benchmarks, assigning these data higher weight during the consensus process. For query results with significantly low quality scores, the system marks them as anomalous data and initiates a secondary verification process. Secondary verification may include specific measures such as re-querying and multi-node cross-verification. Simultaneously, the system records the quality assessment results of each query, establishing a historical archive of node query quality. This historical data will serve as an important basis for subsequent node permission adjustments.

[0031] During the dynamic adjustment phase of node permissions, the system continuously optimizes node query permissions based on historical query quality assessment results. The specific process is as follows: the system periodically calculates the average query quality score of each node over a certain time period and classifies nodes into different trust levels according to the score. For nodes that consistently receive high ratings, the system gradually expands their query permission scope, allowing them to participate in more types of data query tasks. For nodes with consistently low query quality scores, the system implements a gradual downgrade process, first restricting their eligibility to participate in core data queries, and then suspending some of their query permissions as appropriate. Permission adjustment decisions are based on complete historical quality assessment data, using a sliding window algorithm to calculate recent quality trends to ensure the accuracy and fairness of the adjustment decisions. Each permission adjustment is logged in detail, including the quality data on which the adjustment was based, the permission changes before and after the adjustment, and the execution time. Through this dynamic adjustment mechanism, the system can continuously optimize the overall query performance of the consortium network, ensuring the quality and reliability of ownership verification data.

[0032] In the consensus verification module, during the data preprocessing and feature vector generation phases, the module first standardizes the query results data submitted by each node. The system converts each node's query results data into a unified-dimensional feature vector according to preset feature extraction rules. The feature vector consists of numerical representations of multiple dimensions, including real estate registration status features, property owner information features, and land use characteristics. For numerical data, the system directly normalizes it and uses it as one dimension of the feature vector; for categorical data, the system converts it into multiple binary feature dimensions using one-hot encoding; for textual data, the system uses feature hashing technology to map it into a fixed-dimensional numerical representation. When generating feature vectors, the system preserves the semantic information of the original data to ensure that the feature vectors accurately reflect the substantive content of the query results. After completing the feature vector conversion, the system generates a corresponding feature vector identifier for each node's data. This identifier is associated with the node's identity information and timestamp for subsequent tracing and verification.

[0033] In the similarity calculation and consistency graph construction phase, the system establishes data consistency relationships between nodes by calculating the similarity distance between feature vectors. The similarity calculation employs a multi-dimensional weighted similarity algorithm. This algorithm first calculates the similarity for each dimension of the feature vectors, then assigns different weights based on the importance of each dimension, and finally sums the weighted similarity scores to obtain the overall similarity score. For numerical dimensions, the relative error method is used, measuring the similarity by calculating the ratio of the numerical difference between two feature vectors in that dimension to their average value. For categorical dimensions, the exact matching method is used, awarding full marks for identical vectors and zero marks for different vectors. For textual dimensions, the edit distance method is used, measuring the similarity by calculating the minimum number of operations required to convert one piece of text into another. Based on the calculated similarity matrix, the system constructs a data consistency graph, where nodes represent query nodes, edges represent the degree of data consistency between nodes, and the weight of the edge is the similarity score.

[0034] During the multi-round voting mechanism execution phase, the system initiates the Byzantine Fault Tolerance consensus voting process. At the start of the first round, each node assesses the credibility of the query results from neighboring nodes based on its locally stored data consistency graph. The assessment process includes: each node first calculates the similarity score between its own feature vector and the feature vectors of neighboring nodes, and then classifies neighboring nodes into three categories—trustworthy nodes, suspicious nodes, and untrustworthy nodes—based on a preset similarity threshold. Nodes generate voting opinions based on the classification results: they vote in favor of the query results from trusted nodes, against the query results from untrustworthy nodes, and abstain from voting on the query results from suspicious nodes. Nodes digitally sign the voting data packet containing their voting opinions and broadcast it throughout the network. In the second and subsequent voting rounds, nodes collect voting information from other nodes, analyze the voting distribution in the network, and adjust their voting stance according to the majority principle. Each voting round has a fixed time window; nodes must complete their voting operations within the specified time. Nodes that fail to vote within the time limit are considered to have abstained in that round.

[0035] During the dynamic weight adjustment mechanism execution phase, the system adjusts the voting weight of nodes in real time based on their historical performance and current voting status. The weight adjustment algorithm is based on a comprehensive calculation of a node's long-term reputation and short-term performance. Long-term reputation is calculated by statistically analyzing a node's voting accuracy and data quality score over a certain period; short-term performance is measured by evaluating a node's voting consistency and data reliability within the current consensus period. The system combines long-term reputation and short-term performance in a preset ratio to generate a comprehensive weight score for each node. For nodes with higher comprehensive weight scores, the system appropriately increases their voting weight, giving them greater influence in the consensus process; for nodes with lower comprehensive weight scores, the system correspondingly decreases their voting weight to reduce potential negative impacts. The weight adjustment process is executed immediately after each voting round, and the adjustment results are notified to all nodes through a secure channel. The system also establishes a weight anomaly monitoring mechanism. When a node's weight fluctuates drastically, a review process is automatically triggered to verify the node's data.

[0036] During the consensus confirmation and trusted data labeling phase, after a preset number of rounds of iterative voting, the system confirms whether a valid consensus has been reached based on the voting results. The specific consensus confirmation process is as follows: the system tallies the voting results of all nodes for each query result and calculates the weighted approval vote ratio for each query result. The weighted approval vote ratio is calculated by adding the voting weights of the nodes supporting the result and then dividing by the sum of the weights of all participating nodes. When the weighted approval vote ratio for a query result exceeds a preset consensus threshold, the system determines that the network has reached a valid consensus on that query result. After consensus is reached, the system labels the query result as trusted data and records detailed information about the consensus process, including the list of participating nodes, the voting opinions of each node, and the calculation result of the weighted approval vote ratio. This information is stored on the blockchain, forming an immutable consensus record. Simultaneously, the system updates the reputation score of each node, rewarding nodes that perform well during the consensus process and deducting reputation points from nodes that perform poorly.

[0037] During the initialization phase of the threshold signature generation process, the system initiates the generation process after confirming a valid consensus. First, the system selects the node with the highest weight as the signature coordinator based on the weight scores of each node in the current round. The signature coordinator is responsible for initializing the entire signature generation process, specifically including: generating a unique identifier for this signature session, determining the list of nodes participating in the signature generation, and setting signature parameters, including the signature algorithm and the required threshold number of signature fragments. The signature coordinator distributes the signature session parameters to all participating nodes through a secure channel and starts a signature timer to ensure that all nodes complete the signing operation within the specified time limit. The signature coordinator also needs to verify the legitimacy of the participating nodes, ensuring that only authorized nodes can participate in the threshold signature generation process. During the initialization process, the signature coordinator records detailed log information, including session establishment time, the list of participating nodes, and signature parameter settings. These logs will serve as the basis for subsequent auditing.

[0038] During the signature fragment generation and submission phase, after receiving the signature session parameters, each participating node uses its own private key fragment to digitally sign the consensus-reached query result. The specific process for signature fragment generation is as follows: First, the node serializes the consensus-confirmed query result data into a standard byte sequence. Then, it uses its private key fragment to perform a digital signature operation on this byte sequence, generating a personal signature fragment. The signature operation employs a system-preset digital signature algorithm to ensure the security and reliability of the generated signature. The node securely encapsulates the generated signature fragment. The encapsulated data packet contains the signature fragment itself, the node's identity identifier, a signature timestamp, and a session identifier. The node encrypts the data packet using the signature coordinator's public key and submits it to the signature coordinator through a secure channel. During the submission process, the node retains a local copy of the signature fragment and records the submission time for subsequent verification and traceability.

[0039] During the signature synthesis and verification phase, after the signature coordinator collects a sufficient number of valid signature fragments, it performs a threshold signature synthesis operation. The coordinator first verifies the validity of the received signature fragments, including checking the format specifications, verifying the digital signature, and confirming the association between the fragments and the current session. Verified signature fragments are added to the synthesis set, while invalid fragments are discarded and recorded. When the number of collected valid signature fragments reaches a system-preset threshold, the coordinator uses a threshold signature synthesis algorithm to synthesize these fragments into a complete threshold signature. The synthesis algorithm, based on the secret sharing principle, reconstructs the signature result corresponding to the complete signature key through polynomial interpolation. After synthesis, the coordinator standardizes the format of the generated threshold signature and adds necessary metadata information, including the synthesis time, the list of participating nodes, and the version of the synthesis algorithm used. Finally, the coordinator uses a system-preset verification public key to verify the threshold signature, ensuring that the signature can pass cryptographic verification and prove that it is indeed a valid signature generated by a legitimate number of nodes. The verified threshold signature serves as a valid credential of the consensus result and is output to the subsequent state synchronization module for processing.

[0040] In the state synchronization module, during the atomic broadcast protocol execution phase, the module employs a distributed atomic broadcast algorithm to simultaneously distribute the threshold signature to both the smart contract and the government database system. The specific implementation process is as follows: The system first establishes two independent communication channels, connecting the blockchain network and the government database system respectively. Before initiating the broadcast, the state synchronization module encapsulates the threshold signature data and necessary metadata into a standardized data packet, which includes the complete threshold signature, task identifier, timestamp, and sequence number. Subsequently, the system initiates a two-phase commit protocol: In the first phase, it sends a preparation request to both target systems and waits for their confirmation signals; in the second phase, after receiving confirmation from all target systems, it simultaneously sends a commit instruction containing the threshold signature to both systems. Throughout the broadcast process, the system maintains a transaction state machine to monitor the transmission status of the two channels in real time. If either channel fails to return a confirmation response within a preset time, the system will terminate the entire broadcast process and record a detailed interruption log. This mechanism ensures the atomicity of transactions in the distributed system; that is, the two target systems either receive the complete threshold signature data simultaneously or neither receives any data, effectively avoiding the problem of inconsistent states between systems.

[0041] During the smart contract verification phase, upon receiving a threshold signature, the smart contract executes a rigorous multi-layered verification process. The first layer is signature format checking. The smart contract parses the received data packet and checks whether the threshold signature's data structure conforms to predetermined specifications, including basic elements such as signature length, encoding format, and field integrity. The second layer is issuer authentication. The smart contract uses the public key registered with the oracle consortium network to perform cryptographic verification of the threshold signature, confirming that the signature was indeed generated by a legitimate node cluster. During verification, the smart contract compares the issuer identifier in the signature with the consortium network registration information and checks whether the certificate chain used for the signature is complete and valid. The third layer is timeliness verification. The smart contract checks the time difference between the signature timestamp and the current blockchain time to ensure the signature is within a valid time window. Simultaneously, the smart contract verifies the uniqueness of the signature sequence number to prevent replay attacks. Each layer of verification has detailed verification log records, including verification time, verification result, and verification parameters used. Failure at any layer will terminate the entire verification process, and the reason for the failure will be recorded on the blockchain for subsequent analysis.

[0042] During the state transition execution phase, after the threshold signature verification passes, the smart contract advances the property rights verification process according to preset state transition rules. The specific process is as follows: the smart contract first reads the current state value for property rights verification from the current state database, and then, based on the verified query results and a preset business rule database, determines the next legitimate state target. The state transition rules are implemented using a finite state machine model, and each state transition requires specific preconditions. For example, transitioning from the "pending review" state to the "approved" state requires meeting multiple conditions, such as normal property registration status, complete tax payment records, and compliance with planned use requirements. During state transition execution, the smart contract creates a new state record on the blockchain. This record contains the new state value, a state transition timestamp, the threshold signature digest that triggered the transition, and related business data hashes. The state record is permanently stored using blockchain transactions, forming an immutable process record. Simultaneously, the smart contract updates the state index to ensure the system can quickly retrieve the latest state information.

[0043] During the state proof generation phase, the smart contract creates a verifiable credential containing complete state transition information. The state transition proof generation process includes: the smart contract first collecting all key data related to the state transition, including the state value before the transition, the state value after the transition, the state transition timestamp, the threshold signature digest triggering the transition, and the list of nodes participating in the consensus. Then, the smart contract serializes this data according to a standard format to generate a structured proof document. The proof document is protected using a layered encryption mechanism; core state data is encrypted using a symmetric encryption algorithm, while the integrity of the document is guaranteed by the smart contract's digital signature. For ease of verification, the smart contract also generates a digital digest of the proof document, calculated using a cryptographic hash function, ensuring uniqueness and tamper-proof properties. The complete proof document and its digital digest are recorded on the blockchain, with the digital digest serving as an index key for convenient subsequent quick retrieval and verification. This design ensures both the integrity of the proof information and improves system processing efficiency.

[0044] During the government database verification phase, the government database executes a strict identity verification process upon receiving the threshold signature. The verification process begins with packet parsing; the government database first parses the received data packet, extracting the threshold signature and related verification information. Subsequently, the system connects to the oracle consortium network's certificate service to obtain a currently valid consortium network public key certificate. Using this public key certificate, the government database performs cryptographic verification of the threshold signature, confirming its authenticity and integrity. The verification algorithm employs a standard digital signature verification process, including signature format parsing, signature value extraction, and verification calculation. In addition to basic cryptographic verification, the government database also checks whether the consortium network identifier in the signature is on a trusted whitelist and verifies the validity of the signature timestamp to ensure the signature is within a reasonable timeframe. All verification steps are logged in detail, including verification time, verification certificate used, verification result, and other key information. Successfully verified threshold signatures are marked as valid and enter the subsequent state locking process; failed signatures trigger an exception handling mechanism, notifying the system administrator for manual intervention.

[0045] During the state locking phase, after the threshold signature verification passes, the government database performs a temporary lock operation on the target real estate record. The specific implementation process is as follows: the system first locates the specific real estate record based on the task identifier, and then sets a lock identifier in a specific field of that record. The lock identifier contains several elements: the task identifier is used to associate with the specific title verification process, the lock start timestamp records the start time of the lock, and the expected unlock conditions define the automatic release conditions of the lock. While setting the lock state, the system records detailed context information about the lock, including the locking operator, the reason for the lock, and the relevant blockchain transaction hash. To ensure data consistency, the locking operation is executed in a transactional manner; it either succeeds entirely or is rolled back entirely. While in the locked state, the government database restricts specific modification operations on the real estate record, but allows queries and read-only access to continue normally. The system also starts a lock timer to ensure that the unlocking process is automatically triggered when the expected unlock time is reached, preventing resources from being locked indefinitely.

[0046] During the lock-up credential generation phase, the government database creates a verifiable lock-up status credential. The credential generation process includes: the system collecting all key information about the lock-up operation, including the locked property identifier, lock-up time, lock-up period, lock-up reason, and operator information. This data is encoded according to a standard format to generate a structured credential document. Then, the system calculates a digital digest of the credential document, generated using a cryptographic hash function, which uniquely represents the credential content. The government database digitally signs the digital digest using its private key, generating a digital signature for the credential. The complete lock-up status credential consists of the original credential document and the digital signature. The government database returns the digital digest of the credential to the status synchronization module, while simultaneously storing the complete credential information in local secure storage. Upon receiving the digital digest, the status synchronization module records it on the blockchain, forming an immutable record. This two-way record mechanism ensures the verifiability and traceability of the lock-up status.

[0047] During the status monitoring and unlocking phases, the status synchronization module establishes a continuous status monitoring mechanism. The monitoring system periodically polls the status of the property rights verification process on the blockchain, tracking the status changes of each task in real time. The monitoring process is implemented as follows: the system maintains a status listener that subscribes to all events related to property rights verification on the blockchain. When a status change is detected, the listener immediately obtains the latest status information and compares it with the locked status in the government database. The system sets up multiple monitoring triggers, including process completion triggers, process termination triggers, and timeout triggers. When the completion or termination of the property rights verification process is detected, the system automatically constructs an unlocking command, which includes necessary information such as the task identifier, unlocking timestamp, and unlocking reason. The unlocking command is sent to the government database through a secure channel, and the government database executes the unlocking operation after verifying the command's legitimacy. The unlocking operation is also executed in a transactional manner to ensure data consistency. Detailed logs are maintained throughout the monitoring and unlocking process, including status detection time, trigger conditions, and executed unlocking operations, providing complete audit trails for system operation and maintenance.

[0048] In the process completion module, during the state unlock instruction generation phase, the smart contract continuously monitors state changes on the blockchain to detect the completion status of the land ownership investigation process. The specific detection mechanism is as follows: The smart contract maintains a state listener that scans the blockchain in real time for state update events related to the land ownership investigation. When a state field change to "completed," the system initiates a multi-condition verification process. First, it checks the validity of the digital signature of the state change transaction to confirm it originates from a legitimate operating node; then, it verifies the compliance of the state transition to ensure it conforms to preset state transition rules; finally, it checks whether the associated task identifier matches the current process. After confirming that all conditions for process completion are met, the smart contract begins constructing a structured state unlock instruction. This instruction uses a hierarchical data structure. The top layer contains core metadata such as the task identifier, process completion timestamp, and blockchain transaction hash; the middle layer contains specific parameters for the unlock operation, including the target government database identifier, unlock scope definition, and priority settings; the bottom layer contains digital signatures and verification information to ensure the integrity and authenticity of the instruction. The smart contract uses its private key to digitally sign the complete instruction and appends the signature to the end of the instruction, forming the final transmittable state unlock instruction data packet.

[0049] During the command transmission phase, the system employs a message queue mechanism with transaction guarantees to transmit status unlock commands. The message queue configuration process includes: first, establishing a persistent connection with the government database system using a secure communication protocol with two-way authentication; then, initializing the message queue's transaction manager, setting the message persistent storage path and transaction log recording rules; and finally, configuring the message transmission confirmation mechanism and retry strategy. During command transmission, the system executes strict transaction management: when a message is ready to be sent, the system first records the message's sending status in the local transaction log; then, it writes the message to persistent storage, ensuring that messages are not lost even in the event of a system failure; next, it delivers the message to the sending queue, awaiting confirmation from the government database system. Upon receiving the message, the government database returns a receipt confirmation signal. Only upon receiving this confirmation signal will the system mark the message as delivered in the transaction log. If no confirmation signal is received within a certain time, the system resends the message according to a preset retry strategy, recording the number of retries and the timestamp of each retry. This mechanism ensures that each command is processed correctly in the order of transmission, and that no messages are lost or processed repeatedly.

[0050] During the status unlocking operation execution phase, the government database executes a strict operational procedure upon receiving the status unlocking command. First, command verification is performed, including verifying the validity of the digital signature, checking the standardization of the command format, and confirming the timeliness of the command. After successful verification, the government database locates the specific real estate record based on the task identifier in the command and executes the status unlocking operation. The specific steps of the unlocking operation include: releasing the temporary lock status of the real estate record, clearing the lock identifier and related lock parameters; updating the record's most recent operation timestamp, recording the specific time of the unlocking operation; and modifying the record's status field to restore it to a normally operable state. During the unlocking operation, the government database employs a database transaction mechanism to ensure the atomicity of the operation, meaning that all related data modifications either all execute successfully or all are rolled back. Simultaneously, the system records detailed operation logs, including key information such as the unlocking execution time, operator information, and the number of records affected. This log information will be used for subsequent auditing and problem tracking.

[0051] During the digital receipt generation phase, after successfully completing the status unlocking operation, the government database automatically generates a digital receipt containing verification information. The generation process employs a multi-step approach: first, key data from the unlocking operation is collected, including the unlock timestamp, operation status code, affected real estate record identifier, task identifier, and other core information; then, this data is encoded according to a standard format to generate a structured receipt document; next, a digital digest of the receipt document is calculated, generated using a cryptographic hash function to uniquely represent the receipt content; finally, the government database's private key is used to digitally sign the digital digest, forming a complete digital receipt. To ensure receipt security, the system also encrypts the receipt document using the smart contract's public key, ensuring that only a designated smart contract can decrypt and read the receipt content. After generating the digital receipt, the government database returns its encrypted digest to the smart contract through a secure channel, while simultaneously storing the complete receipt record in its local database and creating a corresponding index for subsequent queries.

[0052] During the receipt verification and state synchronization completion recording phase, the smart contract executes the verification process after receiving the encrypted digest of the digital receipt. The verification process begins with the decryption of the encrypted digest; the smart contract uses its private key to decrypt the digest, obtaining the plaintext receipt digest information. Then, the smart contract queries the receipt verification interface of the government database to obtain the complete digital receipt document and uses the government database's public key to verify the validity of the receipt signature. After successful signature verification, the smart contract recalculates the digital digest of the receipt document and compares it with the received digest information to ensure the integrity of the receipt content. Next, the smart contract verifies whether the business data in the receipt is consistent with expectations, including checking the matching of the task identifier, confirming the rationality of the unlock timestamp, and verifying the correctness of the operation status code. After all verifications pass, the smart contract creates a final state synchronization completion event record on the blockchain. This record contains complete verification information, the receipt digest, the completion timestamp, and the relevant blockchain transaction hash. Simultaneously, the smart contract updates the process state database, marking the land survey task as fully completed and releasing related system resources. The entire verification and recording process generates detailed operation logs, which are permanently stored on the blockchain, providing the system with complete audit and traceability capabilities.

[0053] The working principle of this invention is as follows: A task initialization module receives a land ownership investigation request and generates a unique task identifier, initiating a smart contract to execute the land ownership verification process. A network of oracles, composed of multiple independent nodes, queries the government database in parallel, and the query results are verified for consistency using a Byzantine fault-tolerant consensus mechanism. Upon reaching a consensus, a threshold signature is collaboratively generated. A state synchronization module atomically synchronizes the threshold signature to the smart contract and the government database, triggering on-chain state advancement and off-chain resource locking. Finally, upon completion of the process, a state unlocking command is automatically sent to the government database, achieving state synchronization between the blockchain and the government system. This system ensures cross-system data consistency and operational atomicity through a distributed consensus mechanism and cryptographic technology, solving the state inconsistency problem present in traditional land ownership investigations.

[0054] The foregoing has provided a detailed description of one embodiment of the present invention, but this description is merely a preferred embodiment and should not be construed as limiting the scope of the invention. All equivalent variations and modifications made within the scope of the claims of this invention should still fall within the patent coverage of this invention.

Claims

1. An automated system for land ownership investigation based on smart contracts, characterized in that, include: The task initialization module is used to receive ownership investigation requests and generate a unique task identifier, and initiate the ownership verification process associated with the task identifier through a smart contract deployed in the blockchain network. The distributed query module receives verification requests sent by the smart contract through an oracle alliance network composed of multiple independent nodes. Each node initiates a query operation in parallel with the government database based on the received request and obtains the query results. The consensus verification module, within the oracle alliance network, uses a Byzantine fault-tolerant consensus mechanism to verify the consistency of query results obtained by each node. When a consensus is reached, each node collaborates to generate a threshold signature. The state synchronization module is used to synchronously send threshold signatures to smart contracts and government databases, including: Once the threshold signature sent to the smart contract is verified, the ownership verification process is initiated. The threshold signature sent to the government database is used to perform state locking operations, enabling real-time synchronization between the government database resource status and the blockchain verification status; The process completion module is used to send a status unlocking command to the government database via a smart contract when the land ownership investigation process is completed on the blockchain network, thereby completing cross-system status synchronization.

2. The automated system for property rights investigation based on smart contracts according to claim 1, characterized in that, The initiated ownership verification process associated with the task identifier specifically includes: When receiving a property rights survey request, a task identifier with spatiotemporal uniqueness is generated. The request timestamp, digital digest of real estate geographic coordinates, blockchain, and latest block hash are superimposed in a three-layer calculation to form an unpredictable and non-repeatable identifier sequence. The generated task identifier is bidirectionally bound to real estate resource information. A mapping table between resource information feature vectors and identifiers is constructed, and the digital fingerprint of the mapping table is stored in the distributed ledger of the blockchain. The smart contract automatically activates the corresponding title verification workflow by parsing the feature parameters in the task identifier. The workflow intelligently matches the preset verification rule set according to the real estate type and initializes the verification state machine to the state to be verified. At the same time the verification process is initiated, the smart contract creates a dedicated state storage area on the blockchain. The storage area uses a Merkle tree structure to record all state change trajectories during the verification process.

3. The automated system for property rights investigation based on smart contracts according to claim 1, characterized in that, The specific steps for obtaining query results include: The Oracle Consortium Network adopts a hierarchical query strategy, parsing verification requests into core data items and auxiliary data items. The core data items are queried in parallel by all nodes, while the auxiliary data items are queried according to the characteristics of the nodes. When each query node initiates a query to the government database, it establishes a secure channel through two-way authentication based on blockchain digital certificates and embeds a digital signature of the task identifier in the query request. After each node obtains the query results, it first performs data format standardization processing locally, converting the heterogeneous data returned by different government databases into a unified structured data format; The node combines the standardized query results with its metadata into a data packet to be verified, which includes the query timestamp, data source identifier, and processing summary.

4. The automated system for property rights investigation based on smart contracts according to claim 1, characterized in that, The query results also include a query quality assessment mechanism: After a node completes a query operation, it automatically generates a query quality report, which includes evaluation indicators in three dimensions: response latency, data integrity, and format compliance. The node submits the query results and the quality report together to the consensus verification module of the Oracle Consortium Network, where the quality report serves as an auxiliary decision-making basis for consensus verification. During the consensus verification process, the system prioritizes selecting node data with higher query quality assessment scores as benchmark references, and marks and performs secondary verification on abnormal query results. The system dynamically adjusts node query permissions based on historical query quality assessment results, and downgrades nodes with low-quality queries.

5. The automated system for land ownership investigation based on smart contracts according to claim 1, characterized in that, The adoption of the Byzantine fault-tolerant consensus mechanism to verify the consistency of query results obtained by each node specifically includes: The query results submitted by each node are converted into standardized feature vectors, and a data consistency relationship graph between nodes is established by calculating the similarity distance between feature vectors. A multi-round voting mechanism is used for consensus verification. In each round of voting, nodes evaluate the credibility of the query results of neighboring nodes and vote based on the local data consistency graph. After each round of voting, the voting weights of each node are adjusted, with higher weights given to nodes that consistently provide consistent results and weight decay applied to nodes that output abnormal results. After a preset number of rounds of iterative voting, when more than a threshold of nodes reach a consensus on a query result, the system determines that a valid consensus has been reached and marks the query result as trustworthy data.

6. The automated system for property rights investigation based on smart contracts according to claim 1, characterized in that, When consensus is reached, the nodes collaborate to generate a threshold signature, specifically including: After confirming that a valid consensus has been reached, the system designates the node with the highest credibility weight as the signature coordinator, which is responsible for initializing the threshold signature generation process. Each participating node uses its own private key shard to digitally sign the consensus query result, generating a personal signature shard, and submits the signature shard to the signature coordinator; Once the signature coordinator has collected a sufficient number of valid signature fragments, these fragments are combined into a complete threshold signature. The system verifies the generated threshold signature to ensure that it can pass the verification of the corresponding public key, and outputs the verified threshold signature as a valid credential of the consensus result.

7. The automated system for land ownership investigation based on smart contracts according to claim 1, characterized in that, The step of synchronously sending the threshold signature to the smart contract and the government database specifically includes: The atomic broadcast protocol is used to simultaneously distribute threshold signatures to smart contracts and government database systems, ensuring that both systems receive valid threshold signatures at the same time, or neither receives them at all. After receiving the threshold signature, the smart contract verifies the integrity and validity of the signature. The verification process includes signature format check, issuer authentication, and timeliness verification. Once the signature verification is successful, the ownership verification status will be advanced from the current state to the next legal state, and the state transition transaction will be recorded on the blockchain. The smart contract generates a state transition proof, which includes the new state value, the state transition timestamp, and a threshold signature digest that has been verified.

8. The automated system for land ownership investigation based on smart contracts according to claim 1, characterized in that, The threshold signature sent to the government database is used to perform a state locking operation, specifically including: After receiving the threshold signature, the government database first verifies the validity of the signature and confirms that the signature comes from a legitimate oracle consortium network. After the signature verification is successful, the government database sets a temporary lock status on the target real estate record. The lock status includes a task identifier, a lock timestamp, and expected unlock conditions. The government database generates a lock status certificate and returns a digital summary of the lock status certificate to the status synchronization module, which then records the summary on the blockchain. The status synchronization module continuously monitors the status of the ownership verification process on the blockchain. When it detects that the process is completed or terminated, it automatically triggers the unlocking command of the government database.

9. The automated system for property rights investigation based on smart contracts according to claim 1, characterized in that, The step of sending a status unlock command to the government database via a smart contract specifically includes: When the smart contract detects that the ownership investigation process is completed, it automatically generates a structured status unlock instruction, which includes a task identifier, a process completion timestamp, and a blockchain transaction hash. A transactional message queue is used to transmit status unlocking commands to the government database, ensuring that commands are not lost or duplicated during transmission and that a strict order is maintained. After the government database performs the status unlocking operation, it generates a digital receipt containing the unlocking timestamp and operation status, and returns the encrypted digest of the digital receipt to the smart contract. The smart contract verifies the validity of the digital receipt, confirms that the government database status unlocking operation is completed, and records the final status synchronization completion event on the blockchain.

Images