A Blockchain Smart Contract Notification and Risk Warning Method for Land Ownership Change

Abstract

This invention relates to the field of land ownership change management technology, and more particularly to a blockchain smart contract-based method for land ownership change notarization and risk warning. The invention acquires land ownership change request data packets and generates data fingerprints, then calls an ownership verification smart contract to complete ownership consistency verification. After successful verification, a spatiotemporal heterogeneous graph data integrating spatial topology and temporal information is constructed. A risk quantification proof is generated through a spatiotemporal graph convolutional risk quantification model, and after verification by zero-knowledge verifiable calculation, a risk warning level is output. Low-risk changes automatically complete on-chain notarization and network-wide status synchronization; high-risk changes automatically generate warning instructions, push them to regulatory nodes, and freeze the request. This invention achieves tamper-proof notarization and proactive risk warning throughout the entire land ownership change process, improving the efficiency and regulatory capabilities of ownership change processing, and effectively preventing ownership fraud and illegal transactions.

Description

Technical Field

[0001] This invention relates to the field of land ownership change management technology, specifically a blockchain smart contract notarization and risk warning method for land ownership change. Background Technology

[0002] Traditional land ownership management often uses centralized databases to store ownership data, with the security and integrity of this data entirely dependent on the protection capabilities of the central node. This central node is vulnerable to cyberattacks, leading to data tampering or leakage. Internal personnel may also abuse their privileges to illegally modify ownership records, causing confusion regarding ownership relationships. Paper archives are costly to preserve and easily damaged or lost due to natural environmental factors; digital archives also face single points of failure. If the central server malfunctions, ownership data becomes inaccessible. Furthermore, the lack of a unified, immutable traceability mechanism for ownership change records makes it difficult to provide credible original evidence in the event of ownership disputes, increasing the difficulty and cost of dispute resolution.

[0003] Traditional risk control models primarily rely on manual review. Reviewers can only conduct a formal examination of submitted written materials and cannot fully grasp the applicant's historical behavior, the historical changes to the land parcel, or the associated risk information of surrounding land parcels. Risk identification has a significant lag; most fraudulent transactions and illegal changes are only discovered after disputes arise, often resulting in irreparable economic losses. Furthermore, the standards for manual review are difficult to standardize; differences in the professional capabilities and judgment criteria of different reviewers can easily lead to missed or incorrect assessments.

[0004] Traditional regulatory models are reactive, meaning regulatory authorities cannot obtain real-time information on ownership changes, making it difficult to promptly detect and address illegal transactions. Cross-regional and cross-departmental regulatory coordination is challenging, as different regional ownership management systems cannot share data, resulting in numerous regulatory blind spots. Regulatory authorities lack effective technical means to comprehensively screen and analyze massive amounts of ownership change data, limiting them to random checks and resulting in limited coverage and efficiency.

[0005] In recent years, some regions have begun to explore the application of blockchain technology in land ownership registration. However, most existing solutions only provide simple on-chain data storage, failing to integrate artificial intelligence for proactive risk assessment. Many solutions lack a robust risk warning mechanism, hindering the proactive identification of potential risks during ownership changes. Furthermore, existing solutions lack a cross-chain collaborative regulatory system, preventing regulatory authorities from obtaining timely warnings of high-risk changes and hindering proactive oversight. Therefore, there is an urgent need to develop a land ownership change management method that enables fully automated registration and proactive risk warning throughout the entire process to address the numerous problems inherent in traditional models. Summary of the Invention

[0006] The purpose of this invention is to provide a blockchain smart contract notarization and risk warning method for land ownership changes, so as to solve the problems mentioned in the background art.

[0007] To achieve the above objectives, the present invention provides the following technical solution:

[0008] A blockchain smart contract-based method for evidence storage and risk warning in the context of land ownership changes includes the following steps:

[0009] S1. Obtain the land ownership change request data packet. The request data packet includes: the applicant's identity identifier, the ownership change type identifier, the spatial topology code of the land parcel to be changed, the ownership change basis document data, and the set of rights holders involved in the change; perform a cryptographic hash operation on the ownership change basis document data and the request data packet to generate a data fingerprint.

[0010] S2. Call the ownership verification smart contract deployed on the blockchain network, retrieve the current ownership status node stored in the Merkel state tree on the chain based on spatial topology encoding, perform permission mapping verification between the right holder identifier registered by the current ownership status node and the right holder set, verify the validity of the digital signature corresponding to the data fingerprint, and output the ownership consistency verification result.

[0011] S3. When the ownership consistency verification result is passed, the risk warning smart contract is invoked to perform a multi-dimensional risk quantification assessment: a spatiotemporal heterogeneous graph data is constructed using spatial topological encoding as graph nodes and historical ownership change events as temporal edges; the historical behavioral feature sequence corresponding to the applicant's identity identifier, the spatiotemporal heterogeneous graph data, and the change complexity parameter corresponding to the ownership change type identifier are input into the spatiotemporal graph convolutional risk quantification model for feature aggregation and risk propagation calculation, generating a risk quantification proof containing risk entropy value and multi-dimensional attribution vector; the risk quantification proof is cryptographically verified using a zero-knowledge verifiable computation protocol, and the risk warning level is output after successful verification.

[0012] S4. When the risk warning level is lower than the dynamic adaptive threshold, call the ownership change notarization smart contract to encapsulate the root hash of the ownership status before the change, the root hash of the ownership status after the change, the block timestamp, and the data fingerprint into the ownership change transaction payload.

[0013] S5. The ownership change transaction payload is verified through the blockchain network's preset consensus mechanism. After verification, it is packaged and written into the new block of the distributed ledger, and the root hash of the Merkel state tree is updated and synchronized with the state of all nodes in the network.

[0014] S6. When the risk warning level reaches or exceeds the dynamic adaptive threshold, the risk warning smart contract is invoked to generate risk warning instruction data containing multi-dimensional attribution vectors. The risk warning instruction data is pushed to the preset regulatory node through the cross-chain message routing protocol, and the on-chain status of the request data packet is marked as frozen and written into the on-chain priority pending queue.

[0015] As can be seen from the technical solution provided by the present invention above, the beneficial effects of the blockchain smart contract notarization and risk warning method for land ownership change provided by the present invention are:

[0016] This invention, through the deep integration of blockchain smart contracts and artificial intelligence technology, constructs a fully automated land ownership change certificate storage and risk warning system, which effectively solves the problems of easy tampering of certificate storage, lagging risk prevention and control, low efficiency of manual review, and difficulty in regulatory coordination in traditional land ownership management.

[0017] This invention employs a three-level progressive cryptographic hash operation to generate globally unique data fingerprints, combining a blockchain distributed ledger with a Merkle state tree to achieve immutable evidence preservation throughout the entire ownership change process; all ownership state updates are verified through a preset consensus mechanism before being written into the distributed ledger and triggering state synchronization across all network nodes, ensuring the consistency and traceability of ownership data; any tampering with ownership records will result in hash verification failure, technically eliminating the possibility of malicious tampering of ownership data;

[0018] This invention constructs a multi-dimensional risk quantification assessment model based on spatiotemporal graph convolution, enabling proactive identification and accurate early warning of land ownership change risks. By constructing spatiotemporal heterogeneous graph data that integrates spatial topology and temporal evolution information, and combining the historical behavioral characteristics of the applicant and the complexity parameters of ownership changes, it can comprehensively capture various risk factors in the ownership change process. At the same time, it introduces a zero-knowledge verifiable computation protocol to ensure the integrity and correctness of the risk quantification calculation process while protecting the privacy of sensitive business data, thereby improving the credibility of the risk assessment results.

[0019] This invention achieves fully automated execution of the ownership verification process, significantly improving the efficiency of ownership change processing; through the ownership verification smart contract deployed on the blockchain network, it automatically completes operations such as on-chain ownership status retrieval, rights holder permission matching, and digital signature verification, replacing the traditional manual review process; the two-factor joint verification mechanism effectively ensures the objectivity and fairness of the verification results, reducing errors and corruption risks caused by human intervention.

[0020] This invention establishes a cross-chain collaborative regulatory early warning mechanism, realizing automatic interception and pre-regulation of high-risk ownership changes. When the risk warning level reaches or exceeds the dynamic adaptive threshold, the system automatically generates an early warning instruction containing multi-dimensional risk attribution and pushes it to the regulatory node through the cross-chain message routing protocol. At the same time, high-risk change requests are marked as frozen on the chain and written into the priority pending queue to ensure that regulatory authorities can intervene in a timely manner and effectively prevent ownership fraud and illegal transactions.

[0021] This invention adopts a distributed decentralized architecture, which has good system robustness and scalability; the consensus mechanism of the blockchain network ensures that the system can still operate normally when some nodes fail; the dynamically adaptive risk warning threshold can be flexibly adjusted according to the different types of land ownership change needs in different regions, adapting to diverse application scenarios; all operation logs and transaction vouchers generated by the system are permanently stored in the distributed ledger, providing a reliable technical basis for subsequent auditing and dispute resolution. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the steps of a blockchain smart contract notarization and risk warning method for land ownership changes according to the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0024] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific embodiments.

[0025] like Figure 1 As shown in the figure, this invention provides a blockchain smart contract notarization and risk warning method for land ownership changes, including the following steps:

[0026] S1. Obtain the land ownership change request data packet. The request data packet includes: the applicant's identity identifier, the ownership change type identifier, the spatial topology code of the land parcel to be changed, the ownership change basis document data, and the set of rights holders involved in the change; perform a cryptographic hash operation on the ownership change basis document data and the request data packet to generate a data fingerprint.

[0027] S2. Call the ownership verification smart contract deployed on the blockchain network, retrieve the current ownership status node stored in the Merkel state tree on the chain based on spatial topology encoding, perform permission mapping verification between the right holder identifier registered by the current ownership status node and the right holder set, verify the validity of the digital signature corresponding to the data fingerprint, and output the ownership consistency verification result.

[0028] S3. When the ownership consistency verification result is passed, the risk warning smart contract is invoked to perform a multi-dimensional risk quantification assessment: a spatiotemporal heterogeneous graph data is constructed using spatial topological encoding as graph nodes and historical ownership change events as temporal edges; the historical behavioral feature sequence corresponding to the applicant's identity identifier, the spatiotemporal heterogeneous graph data, and the change complexity parameter corresponding to the ownership change type identifier are input into the spatiotemporal graph convolutional risk quantification model for feature aggregation and risk propagation calculation, generating a risk quantification proof containing risk entropy value and multi-dimensional attribution vector; the risk quantification proof is cryptographically verified using a zero-knowledge verifiable computation protocol, and the risk warning level is output after successful verification.

[0029] S4. When the risk warning level is lower than the dynamic adaptive threshold, call the ownership change notarization smart contract to encapsulate the root hash of the ownership status before the change, the root hash of the ownership status after the change, the block timestamp, and the data fingerprint into the ownership change transaction payload.

[0030] S5. The ownership change transaction payload is verified through the blockchain network's preset consensus mechanism. After verification, it is packaged and written into the new block of the distributed ledger, and the root hash of the Merkel state tree is updated and synchronized with the state of all nodes in the network.

[0031] S6. When the risk warning level reaches or exceeds the dynamic adaptive threshold, the risk warning smart contract is invoked to generate risk warning instruction data containing multi-dimensional attribution vectors. The risk warning instruction data is pushed to the preset regulatory node through the cross-chain message routing protocol, and the on-chain status of the request data packet is marked as frozen and written into the on-chain priority pending queue.

[0032] In this embodiment, the core function of step S1 is to receive and standardize the land ownership change request data, complete the authentication of the applicant's identity and the security verification of the transmission channel, extract core business fields and construct a structured request data packet, and generate a globally unique and tamper-proof data fingerprint through a three-level progressive cryptographic hash operation to achieve integrity protection and unique identification of the request data, providing a reliable data foundation for subsequent on-chain ownership verification, risk quantification assessment and ownership change evidence storage operations; the detailed steps are as follows:

[0033] S1-1: Reception and Data Extraction of Land Ownership Change Request Messages:

[0034] The system receives land ownership change request messages submitted by applicants through a pre-defined ownership change pre-service gateway, performs identity verification and transmission channel encryption validity verification on the applicants. After successful verification, it extracts the applicant's identity identifier, ownership change type identifier, spatial topology code of the land parcel to be changed, ownership change basis document data, and the set of rights holders involved in the change from the request message. The extracted data is then packaged according to a pre-defined nested data structure to form an initial land ownership change request data packet.

[0035] S1-2: Compliance verification of ownership change documentation and first-level hash calculation:

[0036] The off-chain data compliance verification component is invoked to perform format compliance verification and data integrity verification on the ownership change basis file data in the initial land ownership change request data packet; after the verification is passed, the first cryptographic hash operation is performed on the ownership change basis file data to generate the basis file data hash value, and the basis file data hash value is temporarily stored in the trusted execution environment;

[0037] The first cryptographic hash operation formula is:

[0038] ,in, Based on the file data hash value, Documents and data serving as the basis for ownership changes;

[0039] S1-3: Request packet structure hash operation:

[0040] The applicant's identity identifier, ownership change type identifier, spatial topology code of the land parcel to be changed, set of rights holders involved in the change, and data hash value based on the file data are sequentially concatenated in a preset fixed order; a second cryptographic hash operation is performed on the concatenated data sequence to be hashed to generate the initial request data packet structure hash value.

[0041] The second cryptographic hash operation formula is:

[0042] ,in, The hash value of the initial request packet structure. As an identifier for the applicant, This is an identifier for the type of ownership change. Spatial topology coding for the land parcel to be changed. For the set of rights holders involved in the change, For data field concatenation operators;

[0043] S1-4: Composite data fingerprint generation and binding storage:

[0044] The data will be concatenated and ordered based on the hash value of the file data and the hash value of the initial request data packet structure. A third cryptographic hash operation will be performed on the composite data string obtained after concatenation to generate a data fingerprint that uniquely identifies this land ownership change request. The data fingerprint will be bound to the initial land ownership change request data packet and stored in the off-chain cache layer for subsequent on-chain smart contract calls for verification.

[0045] The third cryptographic hash operation formula is:

[0046] ,in, For data fingerprinting.

[0047] In this embodiment, the core function of step S2 is to invoke the ownership verification smart contract deployed on the blockchain network, complete the reliable retrieval and integrity verification of the on-chain ownership status based on the spatial topology code of the land parcel to be changed, construct a standardized on-chain ownership permission mapping table and execute the right holder permission matching and share verification, and simultaneously verify the validity of the digital signature of the applicant corresponding to the data fingerprint. Through a two-factor joint verification mechanism, an immutable ownership consistency verification result is output, providing a legal basis for subsequent risk quantification assessment and ownership change evidence storage operations. The detailed steps are as follows:

[0048] S2-1: On-chain Merkle state tree hierarchical addressing and ownership state node reconstruction:

[0049] Based on the spatial topology encoding of the land parcel to be changed, a top-down hierarchical path addressing is performed in the on-chain Merkel state tree. Starting from the root node of the Merkel state tree, each binary fragment of the spatial topology encoding is compared with the node branch index, and the process is traversed downwards along the matching branch until the target leaf node level is reached. The complete payload data of the target leaf node is extracted, and the hash value sequence of all sibling nodes on the path from the root node to the target leaf node is collected. Based on the extracted leaf node payload and sibling node hash sequence, the current ownership state node is reconstructed within the smart contract execution sandbox. The complete hash verification chain generated during the reconstruction process is combined with the target leaf node index to generate an ownership state retrieval path certificate. The ownership state retrieval path certificate can be used independently by subsequent audit nodes to verify the authenticity and tamper-proof nature of the ownership state retrieval process.

[0050] S2-2: Construction of the on-chain ownership and permission mapping table:

[0051] The payload data of the target leaf node in the ownership status retrieval path certificate is parsed, and all right holder identifiers registered in the current ownership status node are extracted sequentially according to the preset ownership status data structure. For each right holder identifier, its associated ownership share parameter and permission status label are further extracted. The ownership share parameter is a floating-point number between 0 and 1, representing the proportion of ownership the right holder enjoys over the land parcel. The permission status label is an enumeration type, including three states: valid, frozen, and cancelled. The extracted right holder identifiers, ownership share parameters, and permission status labels are structured and mapped to construct an on-chain ownership permission mapping table. The on-chain ownership permission mapping table uses the right holder identifier as the key and the tuple composed of the ownership share parameter and the permission status label as the value.

[0052] S2-3: Intersection of Rights Holder Sets and Filtering by Permission Status:

[0053] Perform a set intersection operation between the set of rights holders involved in the change and the set of rights holder identifiers in the on-chain ownership and permission mapping table to generate an intersection set of rights holders; traverse each element in the intersection set of rights holders and query the corresponding permission status label in the on-chain ownership and permission mapping table; filter out rights holders with permission status labels of frozen or cancelled, and retain rights holders with permission status labels of valid, to generate a valid intersection set of rights holders; calculate the sum of the ownership share parameters of all rights holders in the valid intersection set of rights holders to obtain the total valid ownership share;

[0054] S2-4: Calculation of Ownership Share Coverage Ratio and Authority Verification:

[0055] The ownership share coverage ratio is obtained by calculating the ratio of the total number of valid ownership shares to the total number of valid ownership shares registered on the chain; the ownership share coverage ratio is calculated using the following formula:

[0056] ,in, For ownership share coverage ratio, In order to effectively intersect the set of rights holders, For the effective intersection of the first The ownership share parameters corresponding to each right holder This refers to the set of all rights holders whose permissions are valid and registered on the blockchain. For the first on-chain Parameters of ownership share corresponding to each valid right holder;

[0057] The calculated ownership share coverage rate is compared with the preset ownership change access threshold. If the ownership share coverage rate is greater than or equal to the ownership change access threshold, the permission verification is deemed to have passed and intermediate data of permission verification is generated. If the ownership share coverage rate is less than the ownership change access threshold, the permission verification is deemed to have failed and a permission verification failure result is generated with an additional insufficient share abnormality mark.

[0058] S2-5: Verification of the applicant's digital signature:

[0059] The system invokes the built-in cryptographic signature verification component of the smart contract to perform a targeted search in the on-chain distributed identity registry based on the applicant's identity identifier, obtaining the public key certificate corresponding to the applicant; it extracts the data fingerprint bound to the land ownership change request and the digital signature submitted by the applicant; it performs an asymmetric decryption operation on the digital signature using the applicant's public key certificate to obtain the decrypted digest value; it compares the decrypted digest value with the data fingerprint byte by byte; if the two are completely consistent, the digital signature is determined to be valid, and a signature verification passed status flag is generated; if the two are different, the digital signature is determined to be invalid, a signature verification failed result is generated, and an invalid signature exception flag is attached.

[0060] S2-6: Output of Two-Factor Joint Decision and Validation Results:

[0061] The permission verification result and the signature verification result are imported into the ownership verification decision engine, and a two-factor logical AND operation is performed; the formula for the two-factor logical AND operation is:

[0062] ,in, For the ownership consistency verification result, For the permission verification result, For the signature verification result, For logical AND operator;

[0063] If the two-factor logical AND operation result is true, a property ownership consistency verification pass result is generated; the property ownership consistency verification pass result, the property ownership status retrieval path certificate, the current property ownership status root hash, and the data fingerprint are packaged into a verification transaction receipt; the verification transaction receipt is written to the temporary storage area of ​​the smart contract for subsequent smart contract calls and reading; if the two-factor logical AND operation result is false, a property ownership consistency verification interception result is generated; all abnormal markers are summarized and appended to the property ownership consistency verification interception result; the property ownership consistency verification interception result is written to the on-chain event log and broadcast to all network nodes, terminating this land ownership change process.

[0064] In this embodiment, the core function of step S3 is to invoke the risk warning smart contract deployed on the blockchain network to perform a multi-dimensional risk quantification assessment after the ownership consistency verification is passed. By constructing spatiotemporal heterogeneous graph data that integrates spatial topology and temporal evolution information, and combining the applicant's historical behavioral characteristics and ownership change complexity parameters, a spatiotemporal graph convolutional risk quantification model is used to complete feature aggregation and risk propagation calculation, generating a risk quantification proof that includes global risk measurement and local risk tracing. A zero-knowledge verifiable computation protocol is used to achieve cryptographic verification of the risk quantification process, ensuring the credibility and immutability of the risk assessment results. Finally, a standardized risk warning level is output, providing a decision-making basis for subsequent ownership change notarization or risk warning handling. The detailed steps are as follows:

[0065] S3-1: Initial Spatiotemporal Heterogeneous Graph Construction:

[0066] An undirected graph topology is initialized using the spatial topological codes of all land parcels with completed ownership changes as graph nodes. Each graph node carries a unique identifier for the land parcel and basic ownership attribute information. All historical ownership change events are extracted from the on-chain distributed ledger, sorted in ascending order by block timestamp, and transformed into weighted directed temporal edges. Each temporal edge connects the land parcel node corresponding to the ownership entity before the change with the land parcel node corresponding to the ownership entity after the change. The direction of the edge is consistent with the flow of ownership change, and the timestamp of the edge is the same as the block timestamp of the corresponding change event. The initial edge weights are dynamically assigned based on the correlation strength and change frequency of historical change events.

[0067] The formula for calculating the initial edge weight is:

[0068] ,in, For nodes With nodes Between in time The initial edge weights, For nodes With nodes Between in time The strength of the association between the change event and the event. For nodes With nodes Between in time Frequency of historical changes For the correlation strength weighting coefficient, To change the frequency weighting coefficient, and satisfy the following conditions: ;

[0069] Combine all graph nodes with weighted directed temporal edges to generate initial spatiotemporal heterogeneous graph data;

[0070] S3-2: Extraction of historical behavioral features of applicants and enhancement of node features:

[0071] From the on-chain distributed identity registry and historical change transaction logs, extract the full historical behavior data corresponding to the applicant's identity identifier; extract features from the historical behavior data according to preset dimensions to generate a historical behavior feature sequence; the historical behavior feature dimensions include the number of historical ownership changes, average change cycle, number of historical disputes, compliance record score, and number of abnormal change events; perform sliding time window slicing on the historical behavior feature sequence, with the time window length set to the most recent twelve months and the sliding step size set to one month; perform min-max normalization on the feature values ​​within each time window to eliminate the dimensional differences between different feature dimensions; concatenate the normalized multi-time window feature sequences into a node behavior feature tensor; perform dimension alignment mapping between the node behavior feature tensor and the land parcel nodes associated with the corresponding applicant in the initial spatiotemporal heterogeneous graph data, and attach the behavior feature tensor as a node attribute to the corresponding graph node to generate a node enhanced feature set;

[0072] S3-3: Decoupling of ownership change complexity parameters and dynamic adjustment of edge weights:

[0073] This paper analyzes the change complexity parameter corresponding to the type identifier of this ownership change; decouples the change complexity parameter into a policy sensitivity indicator, an ownership transfer level indicator, and a historical dispute frequency indicator; the policy sensitivity indicator measures the strictness of land policy control involved in this change, with a value range of 0 to 1; the ownership transfer level indicator measures the number of intermediate transfer links involved in this change, with a value range of 0 to 1; the historical dispute frequency indicator measures the proportion of ownership disputes that have occurred in the history of the land parcel to be changed to the total number of changes, with a value range of 0 to 1; constructs a dynamic edge weight adjustment matrix based on the preset weight coefficients of the three indicators; applies the dynamic edge weight adjustment matrix to all associated temporal edges of the corresponding land parcel node in the initial spatiotemporal heterogeneous graph data, and updates the edge weight values;

[0074] The updated weight calculation formula is as follows:

[0075] ,in, For the updated edge weights, As a policy sensitivity indicator, As an indicator of ownership transfer levels, This is an indicator of the frequency of historical disputes. The policy sensitivity weighting coefficient For the weighting coefficient of ownership transfer hierarchy, The frequency weighting coefficient for historical disputes, and satisfies the following conditions: ;

[0076] Replace all the initial edge weights with the updated edge weights to generate spatiotemporal heterogeneous graph data with fused change complexity;

[0077] S3-4: Spatiotemporal graph convolutional feature aggregation and risk quantification proof generation:

[0078] The model inputs node-enhanced feature sets and spatiotemporally heterogeneous graph data with fusion-modified complexity into a spatiotemporal graph convolutional risk quantification model. The model first performs graph convolution operations across time steps, aggregating neighborhood features for each graph node at each time step to extract spatial topological dependencies between land parcels. Then, the aggregated spatial features are input into multi-layer temporal convolutional units to capture the dynamic patterns of ownership status evolution over time. The spatial topological dependency features and temporal evolution features are concatenated and fused to generate a spatiotemporal joint latent state representation. Risk propagation calculations are performed based on this spatiotemporal joint latent state representation, simulating the diffusion path of risk factors in the graph structure through a graph message passing mechanism. The model calculates the risk accumulation probability of each graph node at different time steps, performs a global uncertainty measurement on the risk accumulation probability of all nodes, and generates a global risk entropy value. Simultaneously, the global risk entropy value is locally decomposed to obtain a multi-dimensional attribution vector corresponding to four dimensions: policy risk, credit risk, historical risk of land parcels, and transaction complexity risk. The global risk entropy value is combined with the multi-dimensional attribution vector to generate a risk quantification proof.

[0079] The formula for calculating the global risk entropy is:

[0080] ,in, This represents the global risk entropy value. This represents the total number of nodes in the spatiotemporal heterogeneity graph. For the first The cumulative risk probability of each node;

[0081] S3-5: Construction and Proof Generation of Zero-Knowledge Verifiable Computation Tasks:

[0082] The risk quantification proof is input into a zero-knowledge verifiable computation protocol; the global risk entropy value and multidimensional attribution vector are used as public verification input sources; the complete inference logic path of the spatiotemporal graph convolutional risk quantification model is extracted and transformed into an arithmetic circuit constraint containing addition and multiplication gates; zero-knowledge verification task parameters corresponding to this risk quantification proof are generated based on the arithmetic circuit constraints; the proof generation module of the zero-knowledge verifiable computation protocol is called to construct a zero-knowledge proof credential containing a computational integrity commitment and a data privacy mask based on the zero-knowledge verification task parameters; the computational integrity commitment is used to prove that the risk quantification calculation process strictly follows the preset model logic; the data privacy mask is used to protect sensitive business data involved in the calculation process from being leaked; the zero-knowledge proof credential and the de-identified hash digest of the multidimensional attribution vector are cryptographically bound to generate a verifiable computation response package;

[0083] S3-6: On-chain zero-knowledge verification and risk warning level output:

[0084] The verifiable computation response package is submitted to the on-chain verification node of the blockchain network; a non-interactive zero-knowledge verification procedure is triggered to verify the consistency between the computational integrity commitment and the preset model logic constraint baseline, and to verify that the generation process of the risk quantification proof has not been tampered with and that the deduction logic conforms to the operation rules of the spatiotemporal graph convolution risk quantification model; if the verification passes, a cryptographic verification pass status flag is generated; if the verification fails, a cryptographic verification failure result is generated and the current risk assessment process is terminated; when the cryptographic verification status flag is passed, the global risk entropy value and multi-dimensional attribution vector in the risk quantification proof are extracted; combined with the preset confidence weights of each risk attribution dimension, the comprehensive risk score is calculated;

[0085] The formula for calculating the comprehensive risk score is:

[0086] ,in, To calculate the overall risk score, The first in the multidimensional attribution vector Risk values ​​in each dimension For the first The confidence weight coefficients for each risk dimension, and satisfying ;

[0087] The comprehensive risk score is compared with the dynamic adaptive threshold within an interval; the risk warning level is divided into three levels: low risk, medium risk, and high risk; when the comprehensive risk score is lower than the dynamic adaptive threshold, it is judged as low risk; when the comprehensive risk score is greater than or equal to the dynamic adaptive threshold but less than twice the dynamic adaptive threshold, it is judged as medium risk; when the comprehensive risk score is greater than or equal to twice the dynamic adaptive threshold, it is judged as high risk; the final risk warning level is generated and output to the ownership change decision link.

[0088] In this embodiment, the core function of step S4 is to respond to the judgment signal that the risk warning level is lower than the dynamic adaptive threshold, call the ownership change notarization smart contract deployed on the blockchain network, complete the credible inference and hash calculation of the ownership status before and after the change, obtain the tamper-proof block timestamp maintained by the blockchain network consensus, and encapsulate and generate an ownership change transaction payload with atomicity and integrity according to the standardized transaction structure, providing a unified and reliable data carrier for subsequent blockchain consensus verification and distributed ledger writing; the detailed steps are as follows:

[0089] S4-1: Low-risk judgment signal response and root hash extraction of ownership status before change:

[0090] In response to a risk warning level falling below the dynamic adaptive threshold, the pre-defined notarization execution logic of the ownership change notarization smart contract is triggered. From the transaction context where ownership consistency verification has passed, the current ownership state root hash, retrieved and cached by the ownership verification smart contract, is extracted. This current ownership state root hash is determined as the ownership state root hash before the change. Simultaneously, the consistency of this root hash with the global Merkle state tree root hash stored in the latest block on the chain is verified to ensure that the ownership state has not changed during the period from verification completion to notarization triggering. If the consistency verification fails, the notarization process is terminated and a state anomaly alarm event is triggered.

[0091] S4-2: On-chain ownership state machine transition and new ownership allocation deduction:

[0092] Based on the successful ownership consistency verification and the preset change rule pointed to by the ownership change type identifier, the on-chain state machine transition function is called; all rights holder identifiers and corresponding ownership share parameters registered in the current ownership status node are mapped and matched one by one with the set of rights holders involved in the change and the agreed ownership allocation scheme; a deterministic ownership redistribution deduction is performed to generate a new ownership allocation tree structure; the new ownership allocation tree structure takes the spatial topology code of the land parcel to be changed as the root node and each rights holder identifier as the leaf node, and the payload data of each leaf node contains the corresponding rights holder's ownership share parameter and permission status label;

[0093] S4-3: Calculation of root hash of ownership status after change:

[0094] A bottom-up Merkle root hash calculation is performed on the newly generated ownership allocation tree structure. First, cryptographic hash operations are performed on the complete payload data of all leaf nodes to generate leaf node hash values. Then, the hash values ​​of two adjacent leaf nodes are concatenated and hashed to generate the corresponding parent node hash value. The above hierarchical hash aggregation process is repeated until a unique root node hash value is generated. If the number of nodes in a certain layer is odd, the hash value of the last node is concatenated with itself to calculate the parent node hash value. The final generated root node hash value is the root hash of the changed ownership status.

[0095] The formula for calculating the Merkle root hash hierarchy is:

[0096] ,in, The hash value of the parent node. The hash value of the left child node. The hash value of the right child node;

[0097] S4-4: Tamper-proof timestamp acquisition and data fingerprint retrieval:

[0098] Within the local execution sandbox of the smart contract for ownership change notarization, the timestamp of the unconfirmed block in the current distributed ledger is obtained through the tamper-proof timestamp interface provided by the trusted execution environment. This timestamp is jointly maintained by the consensus nodes of the blockchain network and has global consistency and immutability. At the same time, the data fingerprint bound to this land ownership change request is retrieved from the off-chain cache layer to verify the integrity of the data fingerprint and the validity of the binding relationship. If the data fingerprint verification fails, the notarization process is terminated and a data anomaly alarm event is triggered.

[0099] S4-5: Construction of the Initial Ownership Change Transaction Payload:

[0100] The root hash of the ownership status before the change, the root hash of the ownership status after the change, the timestamp of the block to be confirmed, and the data fingerprint are ordered and filled with data fields according to a preset transaction payload structure sequence. The preset transaction payload structure includes, in sequence, a transaction type identifier field, a root hash field of the ownership status before the change, a root hash field of the ownership status after the change, a block timestamp field, a data fingerprint field, and a reserved extension field. The length and encoding format of each data field are predefined uniformly to ensure the consistency of the parsing results of all nodes in the blockchain network. After all data fields are filled, the initial ownership change transaction payload is generated.

[0101] S4-6: Atomicity Packaging and Transaction Payload Submission:

[0102] The atomic encapsulation primitive built into the ownership change evidence storage smart contract is invoked to apply a structural integrity check code and a payload type identifier to the initial ownership change transaction payload. The structural integrity check code is generated by performing a cyclic redundancy check on all bytes of the initial transaction payload and is used to verify the integrity of the transaction payload during transmission and storage.

[0103] The formula for calculating the structural integrity check code is:

[0104] ,in, For structural integrity check codes, The byte sequence of the initial ownership change transaction payload;

[0105] The structural integrity check code and payload type identifier are appended to the end of the initial transaction payload to generate a self-describing and tamper-proof ownership change transaction payload. The ownership change transaction payload is then submitted to the pending transaction cache pool of the blockchain network node, awaiting subsequent verification and packaging processing by the preset consensus mechanism.

[0106] In this embodiment, the core function of step S5 is to complete the global legality verification and consensus of the transaction through a preset consensus mechanism after the ownership change transaction payload is submitted to the pending transaction cache pool. The legal and valid transaction is then packaged and written into a new block of the distributed ledger, driving the incremental update of the on-chain Merkel state tree and synchronizing the state of all network nodes. Ultimately, this achieves an immutable notarization of land ownership changes and a closed loop of consistency between the entire network state. The detailed steps are as follows:

[0107] S5-1: Detection of conflicts between pending transaction extraction and global transaction:

[0108] The ownership change transaction payload is extracted from the pending transaction cache pool of the blockchain network nodes. The block proposal node with the pre-defined consensus mechanism performs structural integrity parsing on it. The structural integrity check code is extracted from the transaction payload. A cyclic redundancy check (CRC) operation is re-executed on the initial ownership change transaction payload. The calculation result is compared with the extracted structural integrity check code. If the comparison is inconsistent, the transaction payload structure is determined to have been tampered with, and it is marked as an invalid transaction and removed from the pending transaction pool. If the comparison is consistent, a global transaction conflict detection is performed. All transactions in the pending transaction cache pool and unconfirmed blocks are traversed to check for any incomplete ownership change transactions with the same spatial topology encoding as this transaction. If a conflict exists, this transaction is marked as a conflicting transaction and returned to the end of the pending transaction pool, awaiting the next round of consensus scheduling. If no conflict exists, this transaction is added to the pending consensus transaction sequence.

[0109] S5-2: Verifying Node State Machine Replay and Consensus Verification Receipt Generation:

[0110] The consensus transaction sequence is broadcast to the group of verification nodes with the preset consensus mechanism. Each verification node first loads its latest local state snapshot based on the root hash of the ownership state before the change in the transaction payload. It then performs a deterministic state machine replay calculation on the ownership change transaction payload in the local sandbox. The replay process strictly reproduces the ownership redistribution deduction logic in step S4, generates a new ownership allocation tree structure, and calculates the root hash of the ownership state after replay. The root hash calculated by replay is compared byte by byte with the root hash of the ownership state after the change carried in the transaction payload. If the two are completely consistent, a consensus verification receipt carrying the digital signature of the verification node is generated. If the two are different, a verification failure receipt is generated and a root hash mismatch exception flag is attached.

[0111] S5-3: Consensus Legal Threshold Determination and Target New Block Generation:

[0112] The master validator collects consensus verification receipts returned by all valid validators, filters out receipts with invalid digital signatures, and counts the number of valid consensus verification receipts. When the number of valid receipts reaches a preset consensus threshold, it is determined that the ownership change transaction has reached global consensus. The master validator concatenates the ownership change transaction payload with the hash value of the block preceding the current block's timestamp in an ordered manner. A Merkle tree is constructed for the hash values ​​of all transaction payloads to be packaged, and the Merkle root hash of the transaction set is calculated. The Merkle root hash of the transaction set is combined with the hash value of the block preceding the current block's timestamp and encapsulated into block header metadata. The block header metadata and the ownership change transaction payload are combined and packaged to generate the target new block.

[0113] The formula for calculating the Merkle root hash of a transaction set is:

[0114] ,in, For the Merklegen hash of the transaction set, to The hash values ​​of each transaction payload to be packaged;

[0115] S5-4: Distributed Ledger Chained Appendage and Merkel State Tree Incremental Update:

[0116] The target new block is written to a local copy of the distributed ledger in a chain-append manner, ensuring that the blocks are unidirectionally linked in chronological order and cannot be tampered with; the root hash of the changed ownership state carried in the target new block is parsed, and an incremental path update strategy is used to drive the on-chain Merkle state tree to perform the update; first, the target leaf node in the Merkle state tree is located based on the spatial topology code of the land to be changed, and its payload is replaced with the new ownership state data; then, the hash values ​​of all parent nodes on the path from the leaf node to the root node are updated sequentially from bottom to top, completing the root hash update of the Merkle state tree;

[0117] The formula for recalculating the hash of the parent node of the path is:

[0118] ,in, For the updated parent node hash value, The updated hash value of the left child node. The updated hash value of the right child node;

[0119] S5-5: Network-wide status synchronization broadcast and transaction final status confirmation:

[0120] The updated Merkle state tree root hash and the block identifier of the target new block are encapsulated into a state synchronization signal, which is then broadcast to all nodes in the decentralized peer-to-peer network. Each receiving node first performs a cryptographic validity check on the state synchronization signal, verifying the integrity of the digital signature of the block identifier and the root hash. After the check passes, the local distributed ledger copy is synchronously overwritten, and the snapshot of the local Merkle state tree is updated. When more than two-thirds of the nodes in the network have completed state synchronization and the root hash comparison is consistent, the on-chain state of the ownership change transaction payload is marked as the final state confirmed. A transaction completion event log is generated and broadcast to all audit nodes in the network, completing the consensus notarization and state synchronization closed loop for ownership change.

[0121] In this embodiment, the core function of step S6 is to invoke the risk warning smart contract to generate a standardized warning instruction containing multi-dimensional risk attribution when the risk warning level reaches or exceeds the dynamic adaptive threshold. This instruction is then used to securely push the warning information to regulatory nodes via a cross-chain message routing protocol. Simultaneously, high-risk change requests are marked as frozen on the chain and written into a priority waiting queue, enabling automatic interception of high-risk transactions and proactive regulatory intervention to prevent fraud and violations during ownership transfers. The detailed steps are as follows:

[0122] S6-1: High-risk assessment signal response and risk warning instruction data generation:

[0123] In response to the judgment condition that the risk warning level reaches or exceeds the dynamic adaptive threshold, the warning execution logic of the risk warning smart contract is invoked. The smart contract first extracts the global risk entropy value and multi-dimensional attribution vector from the risk quantification proof generated in step S3. The multi-dimensional attribution vector contains the risk values ​​and confidence levels of four dimensions: policy risk, subject credit risk, land historical risk, and transaction complexity risk. Combining the spatial topology code of this change request with the applicant's identity identifier and data fingerprint, the data is serialized and metadata is filled according to the preset instruction encapsulation template. A globally unique transaction traceability identifier is attached, which is generated by the concatenated hash of the block timestamp and the data fingerprint. All fields are combined according to the preset structure to generate risk warning instruction data.

[0124] The formula for calculating the transaction origination identifier is:

[0125] ,in, For transaction traceability identifiers, This is the timestamp of the current block. For data fingerprinting;

[0126] S6-2: Cross-chain message encryption and standard cross-chain message construction:

[0127] Based on the generated risk warning instruction data, the encrypted routing module of the cross-chain message routing protocol is invoked. First, the public key credential corresponding to the preset regulatory node is retrieved from the on-chain cross-chain identity registry. Then, the public key credential of the regulatory node is used to perform asymmetric encryption on the risk warning instruction data, generating a cross-chain encrypted payload. The asymmetric encryption algorithm uses elliptic curve cryptography to ensure that only the regulatory node holding the corresponding private key can decrypt and read the warning content. A standard cross-chain message is constructed, with the message structure sequentially including the source chain identifier, target access address, routing sequence number, and cross-chain encrypted payload. The source chain identifier identifies the source blockchain network of the warning information; the target access address is the unique address of the regulatory node in the cross-chain network; and the routing sequence number ensures the orderliness of the cross-chain message and prevents replay attacks.

[0128] S6-3: Cross-chain message routing and delivery receipt reception:

[0129] The completed standard cross-chain message is submitted to the cross-chain relay network; the relay network performs smart routing based on the target access address in the message, forwarding the cross-chain message to the corresponding regulatory node; after receiving the cross-chain message, the regulatory node uses its own private key to decrypt the cross-chain encrypted payload and obtain the complete risk warning instruction data; the regulatory node generates a routing delivery receipt containing a routing sequence number and a receiving timestamp, and sends the receipt back to the cross-chain message routing protocol module of the source chain through the relay network; after the source chain module verifies that the routing sequence number in the delivery receipt is consistent with the sequence number sent, it confirms that the warning instruction has been successfully delivered;

[0130] S6-4: On-chain request state freeze and snapshot locking:

[0131] Upon receiving the routing delivery receipt, the on-chain state machine transition logic is triggered. Using the data fingerprint of this land ownership change request as an index, the corresponding storage node is located in the on-chain Merkle state tree. A state field overwrite operation is performed to update the on-chain state of the request data packet to a frozen state identifier. The frozen state identifier is a preset fixed binary value, indicating that the change request has been intercepted by the system, prohibiting any subsequent automatic execution operations. A state freeze transaction certificate is generated, which contains the freeze timestamp data fingerprint and the smart contract address that performed the freeze operation. A hash chain recalculation is performed on all parent nodes on the state update path to lock the on-chain snapshot of the request data packet, ensuring that the frozen state cannot be tampered with.

[0132] S6-5: Priority scheduling parameter calculation and writing to the pending queue:

[0133] Analyze the risk confidence of each attribution dimension in the multidimensional attribution vector and extract the weight value of the highest risk dimension; perform a weighted operation on the weight value of the highest risk dimension and the global risk entropy value to generate priority scheduling parameters; the larger the value of the priority scheduling parameter, the higher the risk level of the request, and the more likely it is to be manually reviewed.

[0134] The formula for calculating priority scheduling parameters is:

[0135] ,in, For priority scheduling parameters, This represents the confidence weight of the highest-risk dimension in the multidimensional attribution vector. Global risk entropy value;

[0136] The request data packet, carrying the priority scheduling parameters, frozen state identifier spatial topology encoding, and data fingerprint, is structured and encoded; the encoded data packet is inserted into the contract storage mapping slot of the on-chain priority pending queue; all nodes in the queue are sorted in descending order based on the priority scheduling parameters to ensure that high-risk requests are placed at the front of the queue; a queue mounting event log is generated and broadcast to all audit nodes in the network to complete the cross-chain issuance of risk warning instructions and the on-chain suspension and evidence storage of high-risk change requests.

[0137] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A blockchain smart contract-based method for evidence storage and risk warning in the context of land ownership transfer, characterized in that: Includes the following steps: S1. Obtain a land parcel ownership change request data packet, the request data packet including: applicant identity identifier, ownership change type identifier, spatial topology code of the land parcel to be changed, ownership change basis document data, and the set of rights holders involved in the change; perform cryptographic hash operation on the ownership change basis document data and the request data packet to generate a data fingerprint; S2. Call the ownership verification smart contract deployed on the blockchain network, retrieve the current ownership status node stored in the Merkel state tree on the chain based on spatial topology encoding, perform permission mapping verification between the right holder identifier registered by the current ownership status node and the right holder set, verify the validity of the digital signature corresponding to the data fingerprint, and output the ownership consistency verification result. S3. When the ownership consistency verification result is passed, the risk warning smart contract is invoked to perform a multi-dimensional risk quantification assessment: a spatiotemporal heterogeneous graph data is constructed using spatial topological encoding as graph nodes and historical ownership change events as temporal edges; the historical behavioral feature sequence corresponding to the applicant's identity identifier, the spatiotemporal heterogeneous graph data, and the change complexity parameter corresponding to the ownership change type identifier are input into the spatiotemporal graph convolutional risk quantification model for feature aggregation and risk propagation calculation, generating a risk quantification proof containing risk entropy value and multi-dimensional attribution vector; the risk quantification proof is cryptographically verified using a zero-knowledge verifiable computation protocol, and the risk warning level is output after successful verification. S4. When the risk warning level is lower than the dynamic adaptive threshold, call the ownership change notarization smart contract to encapsulate the root hash of the ownership status before the change, the root hash of the ownership status after the change, the block timestamp, and the data fingerprint into the ownership change transaction payload. S5. The ownership change transaction payload is verified through the blockchain network's preset consensus mechanism. After verification, it is packaged and written into the new block of the distributed ledger, and the root hash of the Merkel state tree is updated and synchronized with the state of all nodes in the network. S6. When the risk warning level reaches or exceeds the dynamic adaptive threshold, the risk warning smart contract is invoked to generate risk warning instruction data containing multi-dimensional attribution vectors. The risk warning instruction data is pushed to the preset regulatory node through the cross-chain message routing protocol, and the on-chain status of the request data packet is marked as frozen and written into the on-chain priority pending queue.

2. The blockchain smart contract notarization and risk warning method for land ownership change as described in claim 1, characterized in that: Obtain the land ownership change request data packet, perform a cryptographic hash operation on the ownership change basis document data and the request data packet to generate a data fingerprint, specifically including: The system receives land ownership change request messages submitted by the applicant through a pre-set ownership change pre-service gateway. It performs identity authentication and transmission channel encryption verification on the applicant. After successful verification, it extracts the applicant's identity identifier, ownership change type identifier, spatial topology code of the land parcel to be changed, ownership change basis document data, and the set of rights holders involved in the change from the request message. The extracted data is then packaged according to a pre-set nested data structure to form an initial land ownership change request data packet. The off-chain data compliance verification component is invoked to perform format compliance and integrity verification on the ownership change basis file data in the initial land ownership change request data packet. After the verification is passed, the first cryptographic hash operation is performed on the ownership change basis file data to generate the basis file data hash value, and the basis file data hash value is temporarily stored in the trusted execution environment. The applicant's identity identifier, ownership change type identifier, spatial topology code of the land parcel to be changed, set of rights holders involved in the change, and data hash value based on the file data are concatenated in a preset order. The second cryptographic hash operation is performed on the concatenated data sequence to be hashed to generate the initial request data packet structure hash value. The hash value of the file data and the hash value of the initial request data packet structure will be concatenated for a second time. A third cryptographic hash operation will be performed on the composite data string obtained after concatenation to generate a data fingerprint that uniquely identifies this land ownership change request. The data fingerprint will be bound to the initial land ownership change request data packet and stored in the off-chain cache layer for subsequent on-chain smart contract calls for verification.

3. The blockchain smart contract notarization and risk warning method for land ownership change as described in claim 1, characterized in that: The system invokes a smart contract deployed on the blockchain network to verify ownership. Based on spatial topology encoding, it retrieves the current ownership state node stored in the Merkle state tree on the chain. It then performs permission mapping verification by matching the registered rights holder identifier of the current ownership state node with the set of rights holders, verifies the validity of the digital signature corresponding to the data fingerprint, and outputs the ownership consistency verification result, specifically including: Based on spatial topology coding, hierarchical path addressing is performed in the on-chain Merkle state tree to extract the target leaf node payload and the hash sequence of the associated sibling node, reconstruct the current ownership state node, and generate ownership state retrieval path credentials. The node payload in the ownership status retrieval path certificate is parsed, and the right holder identifier registered in the current ownership status node and the ownership share parameters and permission status tags associated with each identifier are extracted to construct an on-chain ownership permission mapping table. The set intersection and share coverage calculation are performed between the set of right holders involved in the change and the on-chain ownership permission mapping table to generate permission intersection matching results. When the permission intersection matching results meet the preset ownership change admission threshold, the permission verification passed intermediate state data is output. The built-in cryptographic signature verification component of the smart contract is invoked to retrieve the corresponding public key certificate in the on-chain distributed identity registry based on the applicant's identity identifier. The data fingerprint and public key certificate are combined to perform asymmetric decryption and digest comparison operations to verify the cryptographic validity of the digital signature corresponding to the data fingerprint and generate a signature verification status identifier. The intermediate data that passes the permission verification and the signature verification status are imported into the ownership verification decision engine, and a two-factor logical AND operation is performed. If both factors pass the verification, an ownership consistency verification result is generated and packaged as a verification transaction receipt. If either factor fails the verification, an ownership consistency verification interception result is generated and an anomaly tracing mark is attached. The ownership consistency verification result is then passed as an output parameter to the next processing node.

4. The blockchain smart contract notarization and risk warning method for land ownership change as described in claim 1, characterized in that: A spatiotemporal heterogeneous graph data is constructed using spatial topological encoding as graph nodes and historical ownership change events as temporal edges. The historical behavioral feature sequence corresponding to the applicant's identity identifier, the spatiotemporal heterogeneous graph data, and the change complexity parameter corresponding to the ownership change type identifier are input into a spatiotemporal graph convolutional risk quantification model for feature aggregation and risk propagation calculation. This generates a risk quantification proof containing risk entropy values ​​and multidimensional attribution vectors, specifically including: The graph topology is initialized using spatial topological encoding as the graph node. Historical ownership change events are sorted by occurrence timestamp and transformed into weighted directed temporal edges. The edge weights are dynamically assigned according to the event association strength and change frequency to generate initial spatiotemporal heterogeneous graph data. Extract the historical behavioral feature sequence corresponding to the applicant's identity identifier, perform time window slicing and feature normalization on the historical behavioral feature sequence, generate a node behavioral feature tensor, align and map the node behavioral feature tensor with the node dimension of the initial spatiotemporal heterogeneous graph data, and generate a node enhanced feature set. The change complexity parameter corresponding to the ownership change type identifier is analyzed, and the change complexity parameter is decoupled into policy sensitivity index, ownership transfer level index and historical dispute frequency index. A dynamic weight adjustment matrix is ​​constructed, and the dynamic weight adjustment matrix is ​​applied to the temporal edge weights of the initial spatiotemporal heterogeneous graph data to generate spatiotemporal heterogeneous graph data that integrates change complexity. The node-enhanced feature set and spatiotemporal heterogeneous graph data with fusion change complexity are input into the spatiotemporal graph convolutional risk quantification model. The neighborhood feature aggregation operation across time steps is performed to extract spatial topological dependency features. Combined with temporal convolutional units, the ownership evolution law is captured to generate a spatiotemporal joint hidden state representation. Risk propagation calculation is performed based on spatiotemporal joint hidden state representation. The diffusion path of risk factors in the graph structure is simulated through graph message passing mechanism. The risk accumulation probability of each graph node is calculated, global uncertainty measurement and local risk source decomposition are performed, and risk quantification proof containing risk entropy value and multidimensional attribution vector is generated.

5. The blockchain smart contract notarization and risk warning method for land ownership change as described in claim 4, characterized in that: The zero-knowledge verifiable computation protocol is used to cryptographically verify risk quantification proofs. Upon successful verification, a risk warning level is output, including: The risk quantification proof is input into the zero-knowledge verifiable computation protocol, with the risk entropy value and multidimensional attribution vector as the public verification input source. The reasoning logic path of the spatiotemporal graph convolutional risk quantification model is extracted and transformed into arithmetic circuit constraints to generate zero-knowledge verification task parameters corresponding to the risk quantification proof. The proof generation module of the zero-knowledge verifiable computation protocol is invoked to construct a zero-knowledge proof credential containing a computational integrity commitment and a data privacy mask based on the zero-knowledge verification task parameters. The zero-knowledge proof credential is cryptographically bound to the de-identified hash digest of the multi-dimensional attribution vector to generate a verifiable computation response package. The verifiable computation response package is submitted to the on-chain verification node, triggering a non-interactive verification procedure. By verifying the consistency between the computational integrity commitment and the preset model logic constraint baseline, the process of generating the risk quantification proof is verified to be tampered with and the deduction logic conforms to the operation rules of the spatiotemporal graph convolution risk quantification model, and a cryptographic verification status identifier is output. When the cryptographic verification status indicates that the verification is successful, the risk entropy value in the risk quantification proof is extracted. The risk level mapping operation is then performed in combination with the confidence weights of each risk attribution dimension in the multidimensional attribution vector. The mapping operation result is compared with the dynamic adaptive threshold for interval comparison and classification, generating a risk warning level that represents the risk level. The risk warning level is then output to the ownership change decision link.

6. The blockchain smart contract notarization and risk warning method for land ownership change as described in claim 1, characterized in that: When the risk warning level is lower than the dynamic adaptive threshold, the ownership change notarization smart contract is invoked to encapsulate the root hash of the ownership state before the change, the root hash of the ownership state after the change, the block timestamp, and the data fingerprint into the ownership change transaction payload, which specifically includes: In response to the judgment signal that the risk warning level is lower than the dynamic adaptive threshold, the pre-set evidence storage execution logic of the ownership change evidence storage smart contract is triggered. The current ownership state root hash, which is retrieved and cached by the ownership verification smart contract, is extracted from the transaction context where the ownership consistency verification result has passed, and the current ownership state root hash is determined as the ownership state root hash before the change. Based on the ownership consistency verification result being passed and the change rule pointed to by the ownership change type identifier, the on-chain state machine transition function is called to perform ownership redistribution deduction on the right holder identifier registered in the current ownership state node and the set of right holders involved in the change, generating a new ownership allocation tree structure, and performing Merkle root hash calculation on the new ownership allocation tree structure to generate the root hash of the changed ownership state. Within the local execution sandbox of the smart contract for ownership change notarization, the timestamp of the unconfirmed block of the current distributed ledger is obtained through the tamper-proof timestamp interface provided by the trusted execution environment, and the data fingerprint bound to the request data packet is retrieved. The root hash of the ownership status before the change, the root hash of the ownership status after the change, the timestamp of the block to be confirmed, and the data fingerprint are ordered and filled with data fields according to the preset transaction payload structure sequence to construct the initial ownership change transaction payload body. The atomic encapsulation primitive built into the ownership change notarization smart contract is invoked to apply a structural integrity check code and a payload type identifier to the initial ownership change transaction payload, generating an ownership change transaction payload that is self-describing and tamper-proof. This ownership change transaction payload is then submitted to the pending transaction cache pool of the blockchain network node, awaiting subsequent verification and packaging processing by the preset consensus mechanism.

7. The blockchain smart contract notarization and risk warning method for land ownership change as described in claim 1, characterized in that: The ownership change transaction payload is verified through the blockchain network's pre-defined consensus mechanism. Once verified, it is packaged and written into a new block of the distributed ledger, triggering an update of the Merkel state tree's root hash and synchronization with the state of all network nodes. Specifically, this includes: The ownership change transaction payload is extracted from the pending transaction cache pool. The block proposal node with the preset consensus mechanism performs structural integrity analysis and global transaction conflict detection on the ownership change transaction payload to generate a transaction sequence to be consensused. The sequence of transactions awaiting consensus is broadcast to the group of verification nodes with the preset consensus mechanism. Each verification node loads a local state snapshot based on the root hash of the ownership state before the change, performs a deterministic state machine replay calculation on the ownership change transaction payload, verifies the consistency between the root hash of the ownership state after the change and the calculation result, and generates a consensus verification receipt carrying the node's digital signature. When the number of valid consensus verification receipts received reaches the preset consensus legal threshold, the main verification node will concatenate the ownership change transaction payload with the block timestamp and the hash value of the previous block in an ordered manner, calculate the Merkle root hash of the payload set and encapsulate it as block header metadata, and combine the block header metadata with the ownership change transaction payload to generate the target new block. The target new block is written to the distributed ledger in a chain append manner. The root hash of the changed ownership state carried in the target new block is parsed. The Merkle state tree is driven by the incremental path update strategy to perform target leaf node state replacement and parent node hash chain recalculation, and the root hash update of the Merkle state tree is completed. The updated root hash and the block identifier of the target new block are encapsulated into a state synchronization signal. This signal is then broadcast to all nodes in the decentralized peer-to-peer network to synchronize the state synchronization signal. Each responding node performs cryptographic validity verification on the state synchronization signal, then synchronously overwrites its local ledger copy and updates the Merkle state tree snapshot. When the state synchronization of all nodes in the network is completed and the root hash comparison is consistent, the on-chain state of the ownership change transaction payload is marked as the final state confirmed, thus completing the consensus notarization and state synchronization closed loop.

8. The blockchain smart contract notarization and risk warning method for land ownership change as described in claim 1, characterized in that: When the risk warning level reaches or exceeds the dynamic adaptive threshold, the risk warning smart contract is invoked to generate risk warning instruction data containing multi-dimensional attribution vectors. This data is then pushed to a pre-defined regulatory node via a cross-chain message routing protocol. The on-chain status of the request data packet is marked as frozen and written to an on-chain priority queue, specifically including: In response to the judgment condition that the risk warning level reaches or exceeds the dynamic adaptive threshold, the risk warning smart contract is invoked to extract the risk entropy value and multi-dimensional attribution vector from the risk quantification proof. Combined with the spatial topology code and applicant identity identifier in the request data packet, the data is serialized and metadata is filled according to the preset instruction encapsulation template. Transaction traceability identifier is attached to generate risk warning instruction data. Based on the risk warning instruction data, the encrypted routing module of the cross-chain message routing protocol is invoked. The risk warning instruction data is asymmetrically encrypted using the pre-set regulatory node public key credentials to generate a cross-chain encrypted payload. A standard cross-chain message containing the source chain identifier, target access address, routing sequence number and cross-chain encrypted payload is constructed. The standard cross-chain message is then routed and pushed to the preset regulatory node through the relay network. After receiving the routing delivery receipt of the standard cross-chain message, the on-chain state machine transition logic is triggered. The current storage node is located in the Merkle state tree using the request data packet as an index. The state field overwrite operation is performed to update the on-chain state of the request data packet to the frozen state identifier. A state frozen transaction certificate is generated and a hash chain recalculation is performed on the parent node of the update path to lock the on-chain snapshot of the request data packet. The risk confidence of each attribution dimension in the multidimensional attribution vector is analyzed. The weight of the highest risk dimension is extracted and weighted with the risk entropy value to generate priority scheduling parameters. The request data packet carrying the priority scheduling parameters, frozen state identifier and spatial topology code is structured and encoded, and inserted into the contract storage mapping slot of the on-chain priority waiting queue. The nodes in the queue are rearranged in descending order according to the priority scheduling parameters. The queue mounting event log is generated and broadcast to the audit nodes of the entire network, thus completing the cross-chain issuance of risk warning instructions and the on-chain suspension and evidence storage of high-risk change requests.

Images