Land second-level market transaction data verification storage processing method based on block chain

Abstract

The invention provides a land second-level market transaction data verification storage processing method based on a block chain, and relates to the crossing field of land resource management and computer technology, and the method comprises the steps: carrying out the data packaging of a transaction track hash sequence, a timestamp and an institution digital signature, and obtaining to-be-verified block data; performing consensus verification and distributed storage on the to-be-verified block data to obtain a corresponding chain hash value; and executing real-time data hash calculation based on the on-chain hash value to obtain a real-time calculation hash value, and comparing the consistency of the on-chain hash value and the real-time calculation hash value to obtain a verification report. Through a standardized transaction process and a block chain evidence storage technology, a land second-level market full-chain credible data management mechanism is established, and complete tracing, tampering prevention and efficient verification of transaction data are realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of land resource management and computer technology, in particular to a land secondary market transaction data verification storage processing method based on a block chain. BACKGROUND

[0002] With the rapid development of the land secondary market in China, the transfer, lease and mortgage of the construction land use right and other transaction activities are increasingly frequent. The existing land secondary market transaction system is usually deployed with a centralized architecture, and each business subsystem is built based on an independent database. At the data processing level, the following problems are faced: In the traditional centralized database storage mode, all transaction data are stored in the database environment controlled by the system operator. This architecture faces the dual threats of internal permission abuse and external network attacks. System administrators or internal personnel with high-level permissions may directly modify transaction records through the database. At the same time, once the centralized database is attacked, the core transaction data may be leaked or tampered with. Although some use database operation logs, audit tracking and other functions as security measures, these security data are still stored in the same trust domain and face the same security risks as the original data. This architectural defect may force the regulatory authorities and transaction participants to fully trust the system operator and cannot obtain independent technical verification means.

[0003] The data authenticity verification of the existing system completely depends on the internal mechanism of the system, and the verification process is within the same trust boundary as the data storage. When different participants dispute the transaction data, there is no independent technical verification means from the system operator. When performing the supervision duties, the regulatory authorities rely on the query results and log records provided by the system, and the authenticity of these data may not be verified by a third party. SUMMARY

[0004] The technical problem to be solved by the present application is to provide a land secondary market transaction data verification storage processing method based on a block chain. Through the standardized transaction process and the block chain storage technology, a land secondary market full-chain credible data management mechanism is established to realize the complete traceability, tamper-proofing and efficient verification of transaction data.

[0005] To solve the above technical problems, the technical solution of the present application is as follows: In a first aspect, the land secondary market transaction data verification storage processing method based on a block chain comprises: Generating subject matter information and transaction announcements based on a set of to-be-traded basic data, publishing the transaction announcements and collecting a set of bidding application data, and obtaining a set of bidding qualification data through multi-dimensional verification of the set of bidding application data; Based on the bidding qualification dataset, the initial bidding timing strategy is loaded and the transaction process is started, and the transaction event sequence is collected in real time; dynamic transaction features are extracted from the transaction event sequence; process control parameters are generated based on the dynamic transaction features; the initial bidding timing strategy is adjusted using the process control parameters, the optimized bidding process is executed and recorded, and the transaction result data is obtained. Based on the transaction result data, contract terms data is obtained; the ownership information in the contract terms data is verified to obtain the ownership verification result; the electronic signature process is triggered based on the ownership verification result to obtain the signed contract document; the signed contract document is registered and filed to obtain the contract filing dataset. The basic dataset to be traded, the bidding qualification dataset, the transaction result data, and the contract filing dataset are linked and integrated, and key data fields are extracted to generate a transaction trajectory hash sequence. The transaction trajectory hash sequence is encapsulated with timestamps and institutional digital signatures to obtain the block data to be verified; consensus verification and distributed storage are performed on the block data to be verified to obtain the corresponding on-chain hash value; Based on the on-chain hash value, real-time data hash calculation is performed to obtain the real-time calculated hash value. By comparing the consistency between the on-chain hash value and the real-time calculated hash value, a verification report is obtained.

[0006] Secondly, a blockchain-based land secondary market transaction data verification, storage, and processing system includes: The supply and demand service module is used to generate target information and transaction announcements based on the basic dataset to be traded, publish transaction announcements and collect bidding application datasets, and obtain bidding qualification datasets through multi-dimensional verification of the bidding application datasets; The transaction service module is used to load the initial bidding timing strategy and start the transaction process based on the bidding qualification dataset, and collect the transaction event sequence in real time; extract dynamic transaction features based on the transaction event sequence; generate process control parameters based on the dynamic transaction features; adjust the initial bidding timing strategy using the process control parameters; execute and record the optimized bidding process; and obtain transaction result data. The online contract signing and filing module is used to obtain contract terms data based on transaction result data; verify the ownership information in the contract terms data to obtain ownership verification results; trigger the electronic signature process based on the ownership verification results to obtain signed contract documents; and perform filing registration on the signed contract documents to obtain a contract filing dataset. The blockchain evidence storage module is used to link and integrate the basic dataset to be traded, the bidding qualification dataset, the transaction result data, and the contract filing dataset, extract key data fields to generate a transaction trajectory hash sequence; encapsulate the transaction trajectory hash sequence with timestamps and institutional digital signatures to obtain the block data to be verified; and perform consensus verification and distributed storage on the block data to be verified to obtain the corresponding on-chain hash value. The regulatory tracking module is used to perform real-time data hash calculations based on on-chain hash values ​​to obtain real-time calculated hash values. By comparing the consistency between the on-chain hash values ​​and the real-time calculated hash values, a verification report is obtained.

[0007] Thirdly, a computing device includes: One or more processors; A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method.

[0008] Fourthly, a computer-readable storage medium storing a program that, when executed by a processor, implements the method.

[0009] The above-described solution of the present invention has at least the following beneficial effects: Based on the underlying dataset to be traded, information on the target asset and transaction announcements are generated, standardizing the presentation of initial transaction data and ensuring the clarity and completeness of core information about the target asset. After the announcement is released, a dataset of bidding applications is collected, and compliant applications are screened through multi-dimensional verification (such as identity, qualifications, and deposit verification) to ensure the accuracy and compliance of the bidding qualification dataset. The initial bidding timing strategy is loaded and the transaction process is initiated, with real-time collection of transaction event sequences to ensure the timeliness of dynamic transaction data acquisition. Dynamic transaction features are extracted based on the event sequences, and process control parameters are generated based on these features to achieve targeted adjustments to the initial bidding timing strategy, making the strategy adaptable to the real-time transaction rhythm. The optimized bidding process is executed and recorded, allowing the transaction result data to fully reflect the optimized transaction details and improving the adaptability and completeness of transaction process data processing. Contract clause data is generated based on the transaction result data to ensure the consistency between the contract content and the transaction result. The ownership information in the contract clauses is verified to ensure the authenticity and lack of dispute of the ownership data. The electronic signature process is triggered based on the verification results, standardizing the data flow and legal effect of contract signing. The signed contracts are registered and filed. The contract filing dataset ensures the complete retention and traceability of contract-related data, strengthening the standardization and security of contract data processing. It integrates and links the underlying dataset for transactions, the bidding qualification dataset, the transaction result data, and the contract filing dataset, achieving seamless data flow across the entire transaction process. Key data fields are extracted to reduce redundant data and lower the processing load. A transaction trajectory hash sequence is generated, condensing key information from the entire transaction process and providing core identifiers for secure data storage and verification, improving the efficiency of data integration and refinement. The transaction trajectory hash sequence, along with timestamps and institutional digital signatures, is encapsulated to ensure the integrity and traceability of the block data to be verified. Consensus verification is performed on the block data to be verified, ensuring data credibility. Distributed storage enhances data storage security, improving the reliability and resilience of data storage. Real-time data hash calculations are performed based on on-chain hash values, enabling dynamic monitoring of the current transaction data status. By comparing the consistency between on-chain hash values ​​and real-time calculated hash values, the integrity and tamper-proof nature of transaction data can be quickly confirmed without verifying the entire dataset, improving data verification efficiency. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating the blockchain-based land secondary market transaction data verification, storage, and processing method provided in an embodiment of the present invention.

[0011] Figure 2 This is a schematic diagram of a blockchain-based land secondary market transaction data verification, storage, and processing system provided in an embodiment of the present invention. Detailed Implementation

[0012] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0013] like Figure 1 As shown, embodiments of the present invention propose a blockchain-based method for verifying, storing, and processing land secondary market transaction data. The method includes the following steps: Step 100: Generate target information and transaction announcement based on the basic dataset to be traded, publish the transaction announcement and collect the bidding application dataset, and obtain the bidding qualification dataset through multi-dimensional verification of the bidding application dataset; Step 200: Based on the bidding qualification dataset, load the initial bidding timing strategy and start the transaction process, and collect the transaction event sequence in real time; extract dynamic transaction features based on the transaction event sequence; generate process control parameters based on the dynamic transaction features; adjust the initial bidding timing strategy using the process control parameters, execute and record the optimized bidding process, and obtain transaction result data; Step 300: Based on the transaction result data, obtain the contract terms data; verify the ownership information in the contract terms data to obtain the ownership verification result; trigger the electronic signature process based on the ownership verification result to obtain the signed contract document; perform filing registration on the signed contract document to obtain the contract filing dataset. Step 400: The basic dataset to be traded, the bidding qualification dataset, the transaction result data, and the contract filing dataset are linked and integrated, and key data fields are extracted to generate a transaction trajectory hash sequence; Step 500: Encapsulate the transaction trajectory hash sequence with timestamps and institutional digital signatures to obtain the block data to be verified; Perform consensus verification and distributed storage on the block data to be verified to obtain the corresponding on-chain hash value. Step 600: Based on the on-chain hash value, perform real-time data hash calculation to obtain the real-time calculated hash value. By comparing the consistency between the on-chain hash value and the real-time calculated hash value, a verification report is obtained.

[0014] In this embodiment of the invention, the initial transaction data is standardized by generating subject matter information and transaction announcements; the bidding application dataset is verified from multiple dimensions to ensure the accuracy and compliance of the bidding qualification dataset, providing a reliable data starting point for subsequent transaction processes; real-time collection of transaction event sequences ensures the timeliness of dynamic data acquisition; dynamic transaction features are extracted and process control parameters are generated to achieve targeted adjustments to the initial bidding timing strategy; the optimized bidding process is recorded so that the transaction result data can truly reflect the optimized transaction situation, improving the adaptability of transaction process data processing; ownership information in contract terms is verified to ensure the authenticity of ownership data; the electronic signature process is triggered to standardize the contract signing data process; and the filing and registration are performed to form a contract filing. The dataset ensures the complete retention and traceability of contract-related data, strengthening the standardization of contract data processing; it integrates datasets from multiple stages to achieve seamless data flow throughout the entire process; it extracts key data fields to reduce redundant data, generates transaction trajectory hash sequences to condense key transaction information, and improves the efficiency of data integration and refinement; it encapsulates data including timestamps and institutional digital signatures to ensure the integrity and traceability of the source of the block data to be verified; it performs consensus verification to ensure data credibility; distributed storage enhances data security and strengthens the reliability of data storage; it calculates data hash values ​​in real time to achieve dynamic monitoring of data status; and it compares on-chain and real-time calculated hash values ​​to quickly confirm whether the data is complete and tamper-proof, ensuring the reliability of the data in subsequent use.

[0015] In a preferred embodiment of the present invention, before step 100, the method further includes: The system receives raw land supply information, performs structured processing on it, and extracts and generates structured supply data containing plot numbers, owner information, plot location, and area. Specifically, this includes: First, receiving raw land supply information submitted by suppliers through the supply and demand service subsystem of the secondary land market transaction service system. This raw land supply information may include unstructured text descriptions, scanned copies of plot-related documents, and fragmented field information. The scanned copies of plot-related documents include, for example, scanned copies of property ownership certificates and land survey and demarcation reports. Next, according to preset structured data field rules, the system performs structured processing on the received raw land supply information. Specifically, for plot numbers, based on preset coding rules such as administrative division codes, year, and 6-digit serial numbers, existing plot numbers are identified from the raw information. If the raw information does not contain plot numbers, the system automatically generates plot numbers that conform to the aforementioned coding rules. Regarding the land ownership information, the system extracts the land ownership name, type of identification document, and corresponding document number from the original information. The identification document type includes documents such as business licenses and resident ID cards, ensuring the integrity of the land ownership information. For the land parcel location, the system extracts the administrative region and detailed address of the land parcel from the original information, forming a standardized description of the land parcel location. For the land parcel area, the system extracts the land parcel area value from the original information and converts it into a unified unit of measurement, such as square meters. If the area unit in the original information is not uniform, a conversion operation is performed according to preset unit conversion rules (e.g., converting mu (a Chinese unit of area) to square meters). Finally, the extracted and standardized land parcel number, land ownership information, land parcel location, and land parcel area are integrated into a structured data format to generate structured supply data. This achieves the transformation of original land supply information into standardized data, providing a standardized data foundation for subsequent review and verification processes.

[0016] The structured supply data is audited and verified to obtain a supply dataset with an audited status. Based on the audited supply dataset, the verified supply data is encapsulated into a basic dataset for transaction, containing land parcel numbers and owner information. Specifically, this includes: First, based on the structured supply data, an audit and verification operation is initiated through the supply and demand service subsystem of the land secondary market transaction service system. During the audit and verification process, each field of the structured supply data is verified one by one according to the system's preset audit standards. Specifically, the system verifies whether the land parcel number conforms to the system's preset coding rules and is not duplicated; whether the owner information is consistent with the supporting documents submitted by the supplier, such as scanned copies of business licenses and resident ID cards; whether the land parcel location accurately corresponds to the actual geographical area and is unambiguous; and whether the land parcel area is consistent with the area data in the land survey and demarcation report. Simultaneously, it can... The system calls the interface of the real estate registration system to automatically verify the land ownership information in the structured supply data to be reviewed, further confirming the legality and lack of dispute over land ownership. After the review and verification are completed, the system marks the corresponding review status for each piece of structured supply data. The review status includes three types: approved, unapproved, and under review. Structured supply data that is unapproved must be marked with the reason for the failure, such as the ownership information not matching the real estate registration system or missing land area data. Subsequently, the structured supply data with the review status of approved are filtered out, and this part of the data is encapsulated. The land parcel number is used as the core identifier field to associate the corresponding owner information, including the owner's name, document type, and document number, and integrated to form a basic dataset to be traded. This basic dataset to be traded will serve as the initial data basis for the subsequent transaction process, ensuring that the data entering the transaction stage is compliant and accurate.

[0017] In a preferred embodiment of the present invention, step 100 includes: Step 101: Generate target asset metadata based on the target asset metadata, and construct a structured transaction announcement based on the target asset metadata. Specifically, this includes: based on the core data fields contained in the target asset dataset, first extracting key information from the dataset such as land parcel number, owner's name and document type and number, land parcel location, land area, land nature, land use right type, land use, transfer term, and termination date. The land area needs to be uniformly converted to square meters; the land nature is state-owned construction land or collective construction land; the land use right type includes: allocation, transfer, or other; and the land use is divided into primary use and secondary use. The aforementioned information is organized into target asset metadata according to the preset metadata specifications. Among them, the transaction supplementary information in the target asset metadata needs to be combined with the transaction service subsystem function of the land secondary market transaction service system to determine the starting price of the target asset based on the land valuation and similar market transaction conditions. The deposit amount is calculated according to the preset percentage of the starting price (such as 20%). The transaction method of online bidding or offline matching is selected according to the characteristics of the transaction target. Among them, online bidding includes online listing and online auction, and a transaction time period including announcement period, bidding application period and bidding period is set. At the same time, the description of the defects of the target asset is supplemented, such as whether there are any attachments or restrictions on rights on the land, to improve the target asset metadata.

[0018] To ensure the standardization and completeness of structured transaction announcements, a pre-set transaction announcement template is used in the land secondary market transaction service system. This template includes rules for generating announcement numbers, a fixed clause area, and a dynamic information filling area. The target asset's metadata is filled into the dynamic information area of ​​the template, and supplemented with bidding qualification requirements, transaction rules, contact information of the transaction service agency, and relevant legal basis. Among them, bidding qualification requirements include that bidders must have real estate development qualifications and no record of dishonesty related to land transactions; transaction rules include the increment, timed bidding trigger conditions, and rules for handling bidding overdue; contact information of the transaction service agency includes: contact number, address, and email address; and relevant legal basis includes "Pilot Program on Improving the Secondary Market for the Transfer, Lease, and Mortgage of Construction Land Use Rights". This forms a structured transaction announcement, and the land parcel number in the underlying dataset to be traded is linked in the structured transaction announcement as a core identifier to ensure a unique correspondence between the announcement and the transaction target.

[0019] Step 102: Publish the structured transaction announcement through the announcement release interface, triggering and collecting application data submitted by bidders to form a bidding application dataset. Specifically, this includes: relying on the announcement release interface provided by the transaction service subsystem of the land secondary market transaction service system, first configuring the interface's connection and release channels, including a prominent position on the portal homepage of the land secondary market transaction service system, electronic display screens in offline transaction halls, and the government information disclosure platform of the local natural resources department, to achieve multi-channel coverage of the structured transaction announcement; during the release process, automatically generate a unique announcement number for the structured transaction announcement, such as using administrative division code, announcement year, and serial number rules, and record the announcement release timestamp. Simultaneously, associate and store the announcement number with the land parcel number and target object metadata in the basic dataset to be traded, facilitating subsequent data traceability.

[0020] Following the announcement, the bidding application collection mechanism is triggered. During the bidding application period specified in the structured transaction announcement, the bidding application portal of the transaction service subsystem receives application data submitted by bidders. Bidders are required to fill in basic personal or corporate information, upload qualification certificates, and submit a declaration of bidding intention through this portal. The basic personal or corporate information includes name, document type and number, contact number, and contact address. Qualification certificates include scanned copies of real estate development qualification certificates and proof of no credit record. The declaration of bidding intention clearly states the bidding target and intention, and a deposit payment voucher must be uploaded. The submitted application data is collected in real time according to the application time sequence, and a unique application number is assigned to each bidding application, which is associated with the corresponding announcement number and land parcel number to ensure that each application data can be traced back to the specific transaction target, ultimately forming a complete bidding application dataset.

[0021] Step 103 involves performing multi-dimensional verification, including identity verification, qualification review, and deposit verification, on the bidding application dataset to obtain a bidding qualification dataset containing verification results. Specifically, to ensure the accuracy and compliance of bidding qualification determination, multi-dimensional verification is performed on the aforementioned collected bidding application dataset, as follows: Relying on the connection function between the land secondary market transaction service system and external authoritative systems, the identity information in the bidding application data is connected to the corresponding verification interface. Among them, corporate bidders need to verify the consistency and validity of their business license information with the information registered with the industrial and commercial department, such as whether the business license is valid. Individual bidders need to verify the matching of their ID card information with the data in the public security identity verification system. At the same time, the system connects to the credit information sharing platform to query whether the bidder has any serious dishonesty records or land transaction-related violations, and marks applications with dishonesty or violations.

[0022] Compare the bidding eligibility requirements specified in the structured transaction announcement with the qualification materials in the bidding application data one by one. For example, if the announcement requires bidders to have a first-class real estate development qualification, verify whether the level and validity period of their qualification certificate meet the requirements. If joint bidding is involved, verify the legality of the joint bidding agreement and whether the qualifications of each joint party meet the requirements. For applications that do not meet the qualification requirements, mark in detail the specific clauses and reasons for the qualification non-compliance.

[0023] By using the financial management subsystem of the land secondary market transaction service system, the deposit receipt inquiry function is invoked to verify whether the amount corresponding to the deposit payment voucher submitted by the bidder is equal to the deposit amount stipulated in the announcement, such as 20% of the starting price, whether the payment time is before the deposit deadline stated in the announcement, and whether the funds are in a valid receipt status, excluding cases of non-payment, underpayment, or overdue payment.

[0024] Finally, the results of each of the above identity verification, qualification review, and deposit verification (pass or fail and the specific reasons) are associated with the corresponding bidding application data. According to the judgment rule that passing all verifications means being qualified to bid, and failing any verification means being disqualified, the qualification conclusion of each bidder is determined. This results in the formation of a bidding qualification dataset containing the bidder's identifier, application number, verification results of each dimension, and qualification judgment conclusion. This dataset is then associated with the land parcel number and the announcement number of the structured transaction announcement in the basic dataset to be traded, providing compliant bidding entity data support for subsequent transaction processes.

[0025] In a preferred embodiment of the present invention, step 200 includes: Step 201: Initialize the transaction process instance based on the bidding qualification dataset. During the initialization process, configure an initial bidding timing strategy including bidding intervals and bidding rounds. Based on the operation of the initial bidding timing strategy, obtain a transaction event sequence containing complete timestamps. Specifically, this includes: First, relying on the transaction service subsystem of the land secondary market transaction service system, initialize the transaction process instance based on the bidding qualification dataset; during the initialization phase, extract core fields such as bidder identifier and qualification verification pass result from the bidding qualification dataset. The bidder identifier, such as the bidding number, associates and binds the information of each qualified bidder with the transaction process instance. Only compliant bidders can participate in the subsequent bidding process. Meanwhile, in the strategy configuration module of the transaction service subsystem, an initial bidding sequence strategy is configured. This strategy must specify two core parameters: the bidding interval and the number of bidding rounds. The bidding interval can be preset to a fixed duration based on the type of transaction. For example, for commercial land or industrial land, the preset fixed duration is 3 minutes per bid for regular listing transactions and 1 minute per bid for auction transactions. The number of bidding rounds is determined based on the bidding period duration specified in the transaction announcement. For example, if the bidding period is 10 calendar days with 8 valid bidding periods per day, the initial number of bidding rounds is set to 80 rounds.

[0026] After the initial bidding timing strategy is configured, the strategy is started and the transaction process is run. During the bidding process, the transaction events corresponding to each bidder's bidding operation are collected in real time, including the bidder's identifier, bidding amount, bidding operation time (accurate to the second), and the current bidding round. A unique event number is automatically generated for each transaction event, and associated with the corresponding transaction process instance identifier and the land parcel number in the basic dataset to be traded. Finally, a transaction event sequence containing a complete timestamp is formed. This sequence needs to be stored in the event recording module of the transaction service subsystem to provide structured and traceable raw data support for subsequent time series analysis.

[0027] Step 202 involves performing time-series analysis on the transaction event sequence to extract dynamic transaction features, including bidding frequency and price fluctuations. Specifically, this includes: based on the transaction event sequence with complete timestamps generated in step 201, time-series analysis is performed on the sequence through the transaction data analysis module of the land secondary market transaction service system. First, the transaction event sequence is divided according to preset time segmentation rules, such as by hour or by calendar day, to ensure the analysis dimensions align with the actual transaction rhythm. During the time-series analysis, two key dynamic transaction features are extracted: one is bidding frequency, which involves counting the total number of bidding operations within each time segment and combining this with the number of bidders still participating in the bidding within that segment to form the average bidding frequency per unit time, such as an average of 3 bids per hour. The first aspect is the bidding process, which reflects the level of activity in the transaction. The second aspect is price fluctuation, which involves extracting the amount data of each bidding operation and calculating the difference between two adjacent bids. For example, the difference between a bid of 10 million yuan and a previous bid of 9.8 million yuan is 200,000 yuan. The maximum, minimum, and average price difference within each time segment are also calculated to reflect the magnitude of changes in transaction prices. When extracting dynamic transaction features, it is necessary to ensure that each feature data is associated with the corresponding time segment identifier, transaction process instance identifier, and land parcel number to avoid the disconnect between feature data and the transaction target. At the same time, the extracted dynamic transaction features are stored in real time in the feature database of the transaction service subsystem to form a structured feature dataset, providing accurate and dynamic data basis for the calculation of subsequent process control parameters.

[0028] Step 203: Calculate the bidding activity index and price volatility based on the dynamic transaction characteristics, and weight and fuse them to obtain process control parameters. Specifically, this includes: First, using dynamic transaction characteristics as input, which include bidding frequency and price volatility, and relying on the parameters of the land secondary market transaction service system, quantitatively calculate the bidding activity index and price volatility respectively. The bidding activity index is calculated by dividing the average bidding frequency per unit time (e.g., 3 times per hour) by the number of valid bidders in that time period (e.g., 5 people) to obtain the number of bids per bidder per unit time, such as 0.6 times / person / hour, thus achieving a preliminary quantitative assessment of activity. The price volatility is calculated by taking the average price difference per unit time, such as an average price difference of 150,000 yuan per hour, and then dividing it by the initial bidding amount in that time period, such as a starting price of 10 million yuan, to obtain the relative proportion of price volatility, such as 1.5%, thus reflecting the preliminary quantitative result of the relative magnitude of price changes.

[0029] After completing the preliminary quantitative calculations of the above two indicators, to eliminate the evaluation bias caused by differences in different indicator dimensions (bidding activity is measured in times / person / hour, and price volatility is a percentage), and to ensure the comparability and accuracy of the indicators under a unified dimension, a two-dimensional vector projection algorithm is introduced to correct the indicators. Specifically, for each dynamic feature calculation period, such as hourly or daily, the preliminary quantified bidding activity indicator and price volatility are used as the two dimensions of a two-dimensional feature vector. For example, the two-dimensional feature vector for a certain 1-hour period is [0.6 times / person / hour, 1.5%]. At the same time, relying on the historical transaction database of the land secondary market transaction service system, historical dynamic feature data of land transactions in the same region and for the same purpose in the past year are extracted to calculate the average bidding activity and average price volatility of such transactions, and to construct a standard feature space. This space includes an activity-volatility standard axis determined based on historical best trading cases. Historical best trading cases are those with high execution efficiency and price volatility that aligns with market expectations. The activity-volatility standard axis, for example, is a coordinate axis with a historical average activity of 0.5 times / person / hour and an average volatility of 1.2% as its origin. Using a two-dimensional vector projection algorithm, the two-dimensional feature vector of the current period is projected onto this standard axis to obtain a projection coefficient. For example, if the projection coefficient is 0.92, this coefficient is multiplied by the initial bidding activity index and price volatility to obtain the corrected bidding activity index (e.g., 0.6 × 0.92 = 0.55 times / person / hour) and the corrected price volatility (e.g., 1.5% × 0.92 = 1.38%). This maps both indicators to a unified dimension of the standard feature space, improving the rationality of subsequent weight fusion.

[0030] Subsequently, to further align the process control parameters with the current trading dynamics and historical best-case scenarios, a weighted Euclidean distance algorithm is introduced to calculate feature differences and dynamically adjust weights. First, based on the dynamic characteristics of historical best-case trading examples, an optimal two-dimensional feature vector is determined, such as [0.7 times / person / hour, 2.0%]. This vector corresponds to historically reasonable trading cycles and positive market responses. The weights of each dimension of the optimal vector are preset according to the trading method of the target asset (online auction or online listing). For example, in online auction trading, the activity dimension weight is set to 0.6, and the volatility dimension weight is set to 0.4; in online listing trading, the activity dimension weight is set to 0.4, and the volatility dimension weight is set to 0.6. Using the weighted Euclidean distance algorithm, the corrected two-dimensional feature vector for the current period is compared with the optimal two-dimensional feature vector. Substituting the feature vectors into the calculation yields the weighted Euclidean distance between the two. This distance value directly reflects the degree of difference between the current trading dynamics and the historical best trading dynamics. For example, a distance value of 0.15 indicates a small difference, while a distance value of 0.5 indicates a large difference. If the distance value is less than a preset difference threshold, such as 0.2, it indicates that the current trading dynamics are close to the historical best state, and the original preset weight allocation rule is maintained. If the distance value is greater than or equal to the preset difference threshold, it indicates that the current trading dynamics deviate significantly from the historical best, and the weights are fine-tuned according to the distance. For example, for every 0.1 increase in distance, the activity weight and volatility weight are each adjusted by 0.05. For instance, in online auction trading, when the distance is 0.3, the activity weight is adjusted to 0.55, and the volatility weight is adjusted to 0.45, in order to achieve dynamic correction of the initial weight rules.

[0031] After completing the above indicator correction and weight adjustment, the corrected bidding activity indicator is multiplied by its corresponding weight, and the corrected price volatility is multiplied by its corresponding weight. The results of these two multiplications are summed to obtain a single numerical form of the process control parameter. The price volatility is converted to a decimal form, e.g., 1.38% is converted to 0.0138. In online auction transactions, for example, 0.55×0.55+0.0138×0.45=0.3025+0.00621=0.3087. Throughout the process, it is necessary to ensure that the weight rules (including the initial preset weights and the weights adjusted based on weighted Euclidean distance) can be manually adjusted through the strategy management module of the transaction service subsystem of the land secondary market transaction service system to adapt to the differentiated needs of different regions and types of land transactions. This includes different regions such as first-tier cities and third- and fourth-tier cities, and different types of land transactions such as commercial land and industrial land. Simultaneously, the generated process control parameter needs to be associated and stored with the corresponding transaction process instance identifier and dynamic feature calculation period to ensure a strong correlation between the parameter and the real-time transaction status.

[0032] Step 204: Dynamically adjust the bidding interval and bidding round parameters in the initial bidding timing strategy using the process control parameters to obtain an optimized bidding timing strategy; execute the bidding process based on the optimized bidding timing strategy to obtain a bidding event record containing complete bidding records, specifically including: First, relying on the land secondary market transaction service system, associate the process control parameters generated in step 203 with the initial bidding timing strategy configured in step 201, and dynamically adjust the bidding interval and bidding round parameters in the initial strategy according to the parameter values: If If the process control parameter value is higher than the preset threshold, such as 0.8, it indicates high trading activity and large price fluctuations. In this case, the bidding interval should be shortened, such as adjusting the initial 3 minutes / bid to 2 minutes / bid, and the number of bidding rounds should be appropriately increased, such as adjusting the initial 80 rounds to 90 rounds, to adapt to the needs of high-frequency trading. If the process control parameter value is lower than the preset threshold, such as 0.5, it indicates low trading activity and small price fluctuations. In this case, the bidding interval should be extended, such as adjusting the initial 3 minutes / bid to 5 minutes / bid, and the number of bidding rounds should be maintained or reduced, such as adjusting the initial 80 rounds to 70 rounds, to avoid unnecessary waiting.

[0033] After parameter adjustments are completed, an optimized bidding timing strategy is formed. This optimized strategy is then bound to the corresponding transaction process instance, and the optimized bidding process is initiated through the bidding execution module of the transaction service subsystem. During the process execution, each bidder's bidding operation is collected in real time. The recorded content includes the bidder's identifier, bid amount, bid time, current bidding round, and corresponding strategy adjustment parameters, such as the adjusted bidding interval, ensuring that each bid record fully reflects the transaction details under the optimized strategy. After the bidding process is executed according to the optimized strategy until the termination condition is met (such as no new bids in the timed bidding or reaching the maximum bidding round), all collected bid records are integrated to form a bidding event record containing the complete bidding trajectory.

[0034] Step 205 involves cleaning and formatting the bidding event records to form a standardized bidding dataset. Based on the final bid records in the bidding dataset, the transaction price and winning bidder are determined, generating transaction result data containing the transaction price, transaction time, and the winning bidder's identity information. Specifically, this includes: First, using the land secondary market transaction service system, performing data cleaning on the bidding event records generated in Step 204: removing duplicate data, invalid data, and data with format errors. Duplicate data includes duplicate bids submitted by the same bidder at the same timestamp; invalid data includes records with bids lower than the starting price; and data with format errors includes records with missing timestamps. This ensures the accuracy and validity of the remaining data. Then, formatting is performed to uniformly convert the bidding amount into a pre-set price. Let the unit be ten thousand yuan. The bidding time is uniformly formatted as the standard time format YYYY-MM-DDHH:MM:SS. The bidder's identifier is then linked with the identification number and name in the bidding qualification dataset to complete the data, ultimately forming a standardized bidding dataset with unified fields and a standardized format. After standardizing the dataset, the amount field of all bidding records is extracted, and the bidding record with the largest value is selected as the final bidding record. Based on this final bidding record, the corresponding transaction price, i.e., the final bidding amount, is determined. By linking it to the bidding qualification dataset, the bidder's identity information corresponding to this bidding record is obtained, such as company name, unified social credit code, or individual name and ID number, thus identifying the winning bidder. Simultaneously, the timestamp of the final bidding record is extracted as the transaction time.

[0035] Finally, the transaction price, transaction time, and successful bidder's identity information are linked and integrated with the land parcel number and owner information in the basic dataset to be traded to generate structured transaction result data. This transaction result data must contain a unique transaction result number, which is generated using the rules of land parcel number, transaction date, and serial number.

[0036] In this embodiment of the invention, a transaction process instance is initialized using a bidding qualification dataset to ensure accurate association between the process instance and compliant bidding entities; an initial bidding timing strategy, including bidding intervals and bidding rounds, is configured to provide a standardized execution framework for the bidding process; a sequence of transaction events with complete timestamps is obtained based on the initial strategy, realizing the time-series recording of transaction events and laying a data foundation for subsequent time-series analysis, while ensuring the traceability of transaction event data; time-series analysis is performed on the transaction event sequence to extract dynamic transaction features such as bidding frequency and price fluctuations from continuous event data, transforming disordered event data into ordered feature data, and achieving accurate extraction of dynamic transaction information; bidding activity indicators and price volatility are quantitatively calculated based on dynamic transaction features to achieve quantifiable evaluation of transaction dynamics; and process control parameters are obtained by weighted fusion of the two indicators, enabling the control parameters to comprehensively reflect transaction activity. The system monitors the degree of volatility and price change trends to improve the adaptability of parameters to subsequent strategy adjustments. It dynamically adjusts the bidding interval and bidding rounds of the initial bidding sequence strategy using process control parameters, ensuring the bidding strategy aligns with real-time trading dynamics and avoids a disconnect between fixed strategies and actual trading needs. Based on the optimized strategy, the system executes the bidding process and records complete bidding records, ensuring the integrity of bidding process data and enabling data linkage between strategy adjustments and process execution. It performs data cleaning and formatting on bidding event records to eliminate data redundancy and errors, forming a standardized bidding dataset to guarantee data quality and standardization. Based on the final bidding records in the standardized dataset, it determines the transaction price and winning bidder, ensuring the accuracy of transaction result determination. Finally, it generates transaction result data containing the transaction price, transaction time, and winning bidder identity information, providing standardized and complete data for subsequent contract generation, filing, and other stages.

[0037] In a preferred embodiment of the present invention, step 300 includes: Step 301: Based on the land parcel number and owner information in the basic dataset to be traded, and the transaction price and successful bidder identity information in the transaction result data, construct a transaction feature vector containing price and identity dimensions. Specifically, this includes: First, relying on the contract online signing and filing subsystem of the land secondary market transaction service system, retrieve the basic dataset to be traded and the transaction result data, and establish a mapping relationship between the two types of data with the land parcel number in the basic dataset to be traded as the core associated field; extract the land parcel number and owner information from the basic dataset to be traded, where the land parcel number is, for example, Ji DZR

[2019] 002, and the owner information includes the owner's name, document type and number; extract the transaction price and successful bidder identity information from the transaction result data, where the transaction price is, for example, 10 million yuan, and the successful bidder identity information includes the successful bidder's name, document type and number, ensuring that each extracted data item has a unique correspondence with the land parcel number.

[0038] Secondly, according to the preset feature vector construction rules, the extracted information is divided into price dimension and identity dimension. The price dimension includes the transaction price and the starting price of the target in the basic dataset to be traded, which serves as a price reference benchmark. The identity dimension includes the owner information and the identity information of the successful bidder. The information of each dimension is transformed into structured data form, such as the owner name in text format and the transaction price in numerical format. These are combined to form a transaction feature vector containing price dimension and identity dimension. The land parcel number is clearly marked in the vector as a unique identifier to ensure that the vector can be accurately traced to the specific transaction target, providing integrated core data support for the subsequent generation of contract terms parameters.

[0039] Step 302: Normalize the transaction feature vector to obtain a standardized feature vector; perform a linear transformation on the standardized feature vector to obtain a contract clause parameter vector. Specifically, this includes: based on the transaction feature vector, firstly, normalize the vector through the contract online signing and filing subsystem of the land secondary market transaction service system; since there is a scale difference between the price dimension data (unit: RMB 10,000) and the identity dimension data (encoded values) in the transaction feature vector, the difference needs to be eliminated according to the preset normalization rules: for the price dimension, take the average transaction price of land transactions in the same area and for the same purpose in the past year as the benchmark, divide the current transaction price and the starting price by the benchmark price respectively to obtain the normalized value of the price dimension. For example, if the benchmark price is RMB 8 million, the normalized value of the current transaction price of RMB 10 million is 1.25; for the identity dimension, encode the ownership and winning bidder's identification numbers by character position, such as directly retaining numbers and converting letters according to ASCII codes, and then divide by the preset maximum value of the encoding to obtain the normalized value of the identity dimension, thereby forming a standardized feature vector.

[0040] After normalization, a linear transformation operation is performed on the standardized feature vector. Based on the format requirements of the contract terms parameters, preset linear transformation coefficients are used, such as setting the price dimension transformation coefficient to 0.8 and the identity dimension transformation coefficient to 0.2. The values ​​of each dimension in the standardized feature vector are multiplied by the corresponding coefficients, and then the calculation results are integrated in a preset order to obtain the contract terms parameter vector. The preset order is, for example, land parcel number, owner, successful bidder, and transaction price. The format and value range of each parameter in this vector are adapted to the field requirements of the subsequent contract template. For example, the transaction price parameter format is adjusted to the text form of RMB XX (in words: XX), ensuring that the parameter can be directly used to fill in the contract terms.

[0041] Step 303: Map the contract clause parameter vector to a preset contract clause template space to generate contract clause data containing complete transaction clauses. Specifically, this includes: First, in the contract online signing and filing subsystem of the land secondary market transaction service system, the construction of a preset contract clause template space is completed. This preset process is specifically executed by the template management function module of the subsystem to ensure that the template space adapts to the needs of different transaction scenarios in the land secondary market. The specific preset operation is as follows: Log in to the backend of the contract online signing and filing subsystem, enter the template management function interface, and create corresponding template classification directories according to the core types of construction land use right transactions, including transfer, lease, and mortgage. For each type of transaction, import standard contract model texts that comply with national and local land transaction norms. For example, for transfer transactions, import the "State-owned Construction Land Use Right Transfer Contract (Model Text)", for lease transactions, import the "State-owned Construction Land Use Right Lease Contract (Model Text)", and for mortgage transactions, import the "State-owned Construction Land Use Right Mortgage Contract (Model Text)". At the same time, it supports the import of supplementary template texts formulated by local natural resources departments to ensure the compliance and regional adaptability of the templates.

[0042] For each imported standard contract template, the template content is divided into a fixed clause area and a dynamic field area using the field editing function in the template management interface. The fixed clause area contains common content in the contract that does not require dynamic adjustment, including legal basis clauses, general clauses on liability for breach of contract, and general clauses on dispute resolution. If the legal basis clauses cite relevant regulations, the content in this area is locked to prevent subsequent accidental modifications. The dynamic field area contains personalized content filled in based on specific transaction data, including subject information fields, transaction entity information fields, transaction price fields, and transaction term fields. The subject information fields include the land parcel number, land parcel location, and land area; the transaction entity information fields include the owner's name, document type and number, and the successful bidder's name, document type and number; the transaction price field includes the transaction price and payment method; and the transaction term fields include the transfer period, lease period, and mortgage period. Each dynamic field is marked with a unique field identifier, which must correspond one-to-one with the parameter identifiers in the subsequent contract clause parameter vector. For example, the land parcel number field is marked as {land parcel number}, the transaction amount field is marked as {transaction amount}, and the owner's name field is marked as {owner's name}.

[0043] In the template management interface, association rules are configured for each template with defined field areas. This involves establishing a mapping relationship between templates and transaction types based on the land transfer method field (transfer / lease / mortgage) in the underlying dataset to be traded. For example, templates marked with the transfer attribute are associated with transaction data where the land transfer method is transfer, and templates marked with the lease attribute are associated with transaction data where the land transfer method is lease. This ensures that the system can automatically match the corresponding template based on the specific transaction's transfer method. Simultaneously, a version management function is configured for the templates to record the time, content, and operator of each template update, forming a template version log for easy traceability and rollback.

[0044] After completing the above configuration, use the test and verification function of the template management interface to simulate parameter data of different transaction types, such as the land parcel number and transaction price of a simulated transfer transaction, to verify whether the dynamic field area of ​​the template can be correctly identified and matched with the parameter identifier, and whether the content of the fixed clause area is complete and correct. After the test is passed, the template will be officially activated and included in the preset contract clause template space. This template space is stored in the template database of the online contract signing and filing subsystem in real time. The template can be updated, added or deactivated according to policy adjustments or business needs.

[0045] After completing the construction of the preset contract terms template space, the contract terms parameter vector is matched with the target template in the contract terms template space. The matching rule is based on the land transfer method in the basic dataset to be traded, including: transfer, lease, and mortgage, and calls the corresponding type templates that are pre-associated in the template space. After the matching is completed, according to the identifier of each parameter in the parameter vector, such as the land parcel number parameter, the owner parameter, and the transaction price parameter, the parameters are mapped one by one to the dynamic field area of ​​the template. For example, the parameter vector "Ji DZR

[2019] 002" is filled into the land parcel number field of the template target, corresponding to the identifier {land parcel number}, and RMB 10 million (in words: ten million yuan) is filled into the transaction amount field, corresponding to the target. The system identifies the transaction amount and enters "xxx Real Estate Co., Ltd." into the owner's name field, corresponding to the identifier "owner's name". Simultaneously, it automatically loads pre-configured fixed clauses from the template, such as citing Article 55 of the "Land Administration Law of the People's Republic of China" regarding the transfer of land use rights, generating contract clause data containing complete transaction terms. During generation, based on preset contract number generation rules, the system assigns a unique contract number to the contract clause data using the administrative division code, land parcel number, and serial number (e.g., Jin 140105ZR20190001), and stores the contract number in association with the land parcel number in the underlying dataset to be traded, ensuring a unique correspondence between the contract clause data and the specific transaction target.

[0046] Step 304 involves cross-verifying the land parcel number and owner information in the contract terms data to obtain an ownership verification result including verification time and result. Specifically, this includes: First, sending a data query request to the real estate registration system based on the land parcel number in the contract terms data to retrieve the official registration information corresponding to that land parcel number, including the registered owner's name, document number, ownership certificate number, and any restrictions on the land parcel's rights, such as whether there are any mortgages or seizures; Second, cross-comparing the retrieved official registration information with the owner information in the contract terms data, where the owner information includes the owner's name and document number: if the registered owner's name is completely identical to the contract owner's name... If the document numbers are identical and there are no rights restrictions on the land parcel, the ownership verification is initially deemed successful. If there are differences in name description or misalignment of individual characters in the document numbers, such as differences in name description (e.g., between "Limited Liability Company" and "Limited Company"), the difference fields are automatically marked and a review process is triggered to verify the reasons for the differences, such as failure to update registration due to a change in company name. Finally, detailed information about the entire verification process is recorded, including the verification initiation time, verification completion time, timestamp of the data returned by the real estate registration system, comparison results, and explanations of differences. This information is then integrated to form an ownership verification result that includes the verification time and verification result. The verification initiation time is accurate to the second, and the comparison result includes: pass or fail, with an explanation of the difference if it fails.

[0047] Step 305: Based on the verification pass identifier in the ownership verification result, trigger the multi-party electronic signature process to generate a legally valid signed contract document. Specifically, this includes: First, the contract online signing and filing subsystem of the land secondary market transaction service system monitors the ownership verification result in real time. When the result contains a verification pass identifier, it automatically triggers the multi-party electronic signature process. Then, an electronic signature notification is sent to both parties to the contract via a combination of in-system messaging and SMS. The two parties are the original owner in the transaction dataset and the successful bidder in the transaction result data. The notification includes a signature entry link, an operation time limit, and a list of required materials, such as an operation time limit of 24 hours and a list of materials including an electronic business license and a personal digital certificate. After logging into the system through the signature entry, both parties upload the electronic signature authorization document. Enterprise users upload their electronic business licenses, and individual users upload their personal digital certificates. The system connects to an authoritative CA (Certificate Authority) interface to verify the validity of the authorization documents, such as whether the digital certificate is valid and whether the certificate holder and the signatory are identical. After successful verification, the system displays the contract terms to be signed. Both parties, guided by instructions, complete the electronic signature operation in the preset signature positions on the contract template. For example, the preset signature positions are for the transferor (Party A) and the transferee (Party B). Upon completion, a legally valid signed contract document is automatically generated. This document includes the electronic signature timestamp, CA certification information, and an anti-tampering watermark. Simultaneously, the signed contract document is stored in association with the contract number and land parcel number, and a signature completion notification is sent to both parties, ensuring the compliance of the contract signing process and the legal validity of the document.

[0048] Step 306 involves calculating a completeness digest of the signed contract document to generate a unique digital digest. This process includes: First, reading the entire content of the signed contract document, including text terms, electronic signature images, and CA authentication information, and converting the document content into a binary data stream. Then, a preset hash algorithm, such as SHA-256, is invoked to calculate the digest of the binary data stream. During the calculation, the data stream is processed byte-by-byte, generating a fixed-length (e.g., 256-bit) hash value according to the hash algorithm's rules. This hash value is the digital digest of the contract document. Due to the one-way and unique nature of hash algorithms, if any modification is made to the content of the signed contract document, such as changes to the text of the terms or replacement of the signature image, the recalculated digital digest will be completely different from the original digest. Therefore, this digital digest uniquely identifies the current state of the signed contract document. Finally, the generated digital digest of the contract document is associated with the contract number and land parcel number and stored in the digest database of the data security module. Simultaneously, this digest information is added to the end of the signed contract document to provide a completeness basis for subsequent filing and verification.

[0049] Step 307: Associate the digital digest with the contract number, signatory information, and signing timestamp to form a complete filing record. This includes: First, retrieving the digital digest of the contract document and extracting the core associated information of the signed contract document: including the contract number, signatory information, and signing timestamp. The contract number uniquely identifies the contract; the signatory information includes the name, document type, and number of the original owner and the successful bidder; and the signing timestamp is the precise time the electronic signature was completed, in the format YYYY-MM-DDHH:MM:SS. Second, according to the preset filing record structure, integrate the above information by associating it with the contract number as the core field, sequentially associating the contract... The file includes a digital digest, original owner information, successful bidder information, and signing timestamp. It also includes the corresponding land parcel number (linked to the underlying dataset) and transaction type (transfer / lease / mortgage) to form a structured filing record. Each piece of information in the filing record undergoes format verification; for example, the signing timestamp must conform to the standard time format, and the signatory's identification number must conform to the corresponding document coding rules, such as an 18-digit ID card number or an 18-digit unified social credit code, ensuring the standardization of the recorded information. After integration, the filing record undergoes a uniqueness verification to check for the existence of filing records with the same contract number. If no record exists, the filing record is confirmed to be complete and valid, preparing for subsequent persistent storage.

[0050] Step 308 involves persistently storing the filing records in a distributed filing database to generate a contract filing dataset containing the filing number, entry timestamp, and digital digest of the contract documents. Specifically, to address the security risks of traditional centralized storage, the distributed data storage module of the land secondary market transaction service system is used to perform persistent storage operations on the complete filing records. This distributed filing database consists of multiple independent nodes, such as transaction center nodes, regulatory agency nodes, and third-party notary agency nodes. Each node has data storage and read / write permissions, and the nodes synchronize data through an encrypted communication protocol.

[0051] First, generate a unique filing number for the filing record. The filing number follows the rule of administrative division code, filing year, and 6-digit serial number, such as Jin 140105 ZR (Bei) 20190001. At the same time, record the timestamp of the filing record's entry into the database, accurate to the second. Subsequently, associate the filing record with the filing number and the entry timestamp. Among them, the filing record includes contract number, digital digest, signatory information, etc., and synchronize it to all nodes of the database according to the distributed storage protocol. Each node performs an integrity check on the received filing record before local storage, and confirms that the record has not been tampered with by comparing the digital digest. After passing the check, complete local storage. After storage, integrate the core information of all filing records, including filing number, contract number, land parcel number, entry timestamp, and digital digest of the contract file, to generate a contract filing dataset. This dataset is stored in a standardized format, supporting fast query by fields such as filing number, contract number, and land parcel number. At the same time, due to the characteristics of distributed storage, when data on any node is damaged or lost, the complete filing record can be restored through other nodes, ensuring the security, integrity, and traceability of contract filing data.

[0052] In the embodiment of the present invention, associate the land parcel number and the owner information in the basic dataset to be traded with the transaction price and the identity information of the winning bidder in the transaction result data, construct a transaction feature vector containing price and identity dimensions, and achieve the structured integration of core transaction data from different sources, providing a unified data basis for the subsequent generation of contract terms. Ensure the accuracy of data association. Perform normalization processing on the transaction feature vector to eliminate the scale differences of different data dimensions, and obtain a standardized feature vector; convert the standardized vector into a contract term parameter vector through linear transformation to make the parameter format adapt to the requirements of contract term generation, improve the adaptability of subsequent parameter and template mapping, and ensure the standardization of parameter data; map the contract term parameter vector to a preset contract term template space, automatically fill the template to generate contract term data for a complete transaction term, realize the automatic generation of contract terms, and at the same time ensure the consistency between the term data and the core transaction parameters, reducing manual input errors; perform cross-verification on the land parcel number and the owner information in the contract term data, check the information consistency and record the verification time and result, strengthen the verification rigor of the ownership information, ensure the authenticity and accuracy of the ownership data, and provide a reliable precondition guarantee for subsequent electronic signature.

[0053] The system triggers a multi-party electronic signature process solely based on the verification pass identifier in the ownership verification results, ensuring the compliance of the signature process initiation. It generates legally valid signed contract documents, guaranteeing the standardization of the contract signing process and the legal validity of the contract documents. A completeness digest is calculated for each signed contract document, generating a unique digital digest. The uniqueness of the digest identifies the contract document's status, quickly identifying whether the document has been tampered with, ensuring the integrity and security of the contract documents. The digital digest is linked and integrated with the contract number, signatory information, and signing timestamp to form a complete filing record, achieving centralized collection of core filing data. This ensures that the filing record contains the key information needed for traceability and provides structured data units for subsequent filing storage. The filing record is persistently stored in a distributed filing database, avoiding the risks associated with a single storage node. A contract filing dataset containing the filing number, database entry timestamp, and digital digest of the contract document is generated, ensuring secure storage and traceability of filing data, while forming a standardized and unified filing data set for easy subsequent querying and management.

[0054] In a preferred embodiment of the present invention, step 400 includes: Step 401 involves linking and integrating the land parcel number from the basic dataset to be traded, the qualification verification results from the bidding qualification dataset, the transaction price and successful bidder information from the transaction result data, and the filing number from the contract filing dataset to form complete transaction trajectory data. Specifically, this includes: first, retrieving the four core datasets generated in the preceding processes. The basic dataset to be traded originates from the system's supply and demand service subsystem; the bidding qualification dataset originates from the qualification verification module of the transaction service subsystem; the transaction result data originates from the bidding result management module of the transaction service subsystem; and the contract filing dataset originates from the contract website. The filing management module of the filing subsystem uses the land parcel number in the basic dataset to be traded as the core associated field to establish a mapping relationship between four types of datasets. It associates the qualification verification results (such as approval, disapproval, and reasons) corresponding to the land parcel number in the bidding qualification dataset with the land parcel number. It also associates the transaction price and the information of the successful bidder (including both uppercase and lowercase amounts) corresponding to the land parcel number in the transaction result data with the land parcel number. The information of the successful bidder includes the bidder's name, document type, and number. Finally, it associates the filing number corresponding to the land parcel number in the contract filing dataset with the land parcel number.

[0055] During the association process, the matching consistency between each dataset and the land parcel number is automatically verified. If a land parcel number does not have a corresponding record in a certain type of dataset, such as if no filing is completed, there will be no filing number. In this case, it will be marked as needing to be supplemented and a data completion reminder will be triggered. After the association is completed, it will be integrated to form a complete transaction trajectory data containing the land parcel number, qualification verification results, transaction price, information of the successful bidder, and filing number.

[0056] Step 402: Extract key data fields from the complete transaction trajectory data, including land parcel number, transaction price, successful bidder identification, and contract filing number. Specifically, this includes: performing a key data field filtering operation based on the complete transaction trajectory data; the filtering criteria are the core identifiers and key result information of the entire transaction process. The specific extraction content includes: the land parcel number as the unique identifier of the transaction target, running through the entire process from the basic data to the contract filing, ensuring that the field value is completely consistent with the original land parcel number in the basic dataset to be traded, such as Ji DZR

[2019] 002; the transaction price is the final transaction amount confirmed in the extracted transaction result data, including both Arabic numerals and Chinese capital letters, such as 10 million yuan / ten million yuan, ensuring that the price The accuracy and compliance of the information are ensured. The successful bidder's identity is a core field integrated into the information; for corporate bidders, the unified social credit code is extracted, and for individual bidders, their ID card number is extracted, serving as the sole identifier of the winning entity. The contract filing number is a unique filing number extracted from the contract filing dataset. This number is associated with core information in the filing and registration process, ensuring the traceability of the transaction loop. During the extraction process, redundant information in the complete transaction trajectory data is automatically removed, such as temporary modification records during the bidding application process and non-core operation logs in the filing process, retaining only the aforementioned key fields to reduce the load on subsequent data processing. Simultaneously, format validation is performed on the extracted key fields to ensure standardized field formats, laying the foundation for subsequent serialization processing.

[0057] Step 403 involves serializing the key data fields according to the transaction time sequence to obtain the transaction trajectory data sequence. Specifically, this includes: serializing the key data fields extracted in step 402 according to the actual time sequence of the transactions; firstly, retrieving the timestamps corresponding to each key field's corresponding stage: the land parcel number corresponds to the timestamp of the generation of the basic dataset to be traded, originating from the supply information review completion time of the supply and demand service subsystem; the successful bidder's identity identifier corresponds to the timestamp of passing the bidding qualification verification, originating from the qualification review completion time of the transaction service subsystem; the transaction price corresponds to the transaction completion timestamp, originating from the bidding termination time of the transaction service subsystem; and the contract filing number corresponds to the timestamp of contract filing completion, originating from the contract website. The registration completion time of the filing and filing subsystem is recorded. Key data fields are arranged sequentially from earliest to latest timestamp to form a transaction trajectory data sequence. For example, the sequence of a transaction might be: land parcel number at 10:00 on 2024-05-01, followed by the successful bidder's identity at 15:30 on 2024-05-05, then the transaction price at 09:15 on 2024-05-10, and finally the contract filing number at 11:20 on 2024-05-15. During the serialization process, each field is labeled with its corresponding timestamp and associated with the land parcel number, ensuring that the sequence not only reflects the field order but also traces the time nodes of the transaction process corresponding to each field, making the temporal logic of the transaction trajectory clearly discernible.

[0058] Step 404 involves character encoding conversion of the transaction trajectory data sequence to generate a binary data sequence; then, data block processing is performed on the binary data sequence to form an ordered set of data blocks. Specifically, this includes: first, performing character encoding conversion on the transaction trajectory data sequence; and adopting a unified encoding rule for different types of key fields: text fields such as land parcel number, successful bidder identification, and contract filing number are converted to binary data using UTF-8 encoding format; numeric fields, such as the Arabic numeral part of the transaction price, are first converted to text format, such as 10000000, and then converted to binary data using UTF-8 encoding, ensuring that all key fields are uniformly in binary format to meet the requirements of subsequent hash calculations for the data source format.

[0059] After encoding and conversion, the data is divided into blocks. Based on preset block rules, such as each block not exceeding 1024 bytes, the binary data sequence is divided in an ordered manner. During this division, the field order of the original transaction trajectory data sequence is maintained; that is, binary data corresponding to the previous field is divided into blocks first, and binary data of the same field is not divided across blocks. If the binary data of a certain field exceeds the maximum size of a single block, the block rules are adjusted to ensure field integrity. After block division, an ordered set of data blocks is formed. Each data block is labeled with a block number according to the division order, such as block 1, block 2, ..., block N, and associated with the corresponding land parcel number and transaction trajectory data sequence identifier. This ensures that the data block set does not lose its correspondence with the original transaction trajectory. Simultaneously, block division reduces the data load of a single hash calculation, improving the efficiency of subsequent iterative processing.

[0060] Step 405: Generate an initial hash value based on the first data block of the data block set, and iteratively process subsequent data blocks based on the initial hash value. The hash output of each data block serves as the input for processing the next data block. After processing all data blocks, a transaction trajectory hash sequence is obtained. Specifically, this includes: First, calling a preset hash algorithm. The preset process for the preset hash algorithm (such as the SHA-256 algorithm) is as follows: During the system deployment phase, based on the security level requirements of land transaction data, a hash algorithm is selected from the list of cryptographic algorithms recommended by the State Cryptography Administration. After selection, the algorithm identifier (such as SHA-256) is written into the configuration file of the hash calculation module through the system configuration interface, and the algorithm parameters are fixed, such as the hash value output length being 256 bits. At the same time, the algorithm information is synchronized to the system's distributed storage module and each node of the blockchain network to ensure that the entire system adopts a unified algorithm standard and avoids hash value mismatch problems caused by algorithm differences.

[0061] Based on the aforementioned preset hash algorithm, a hash calculation is performed on the first data block (block 1) in the data block set formed in step 404 to generate an initial hash value. During the calculation, the complete binary data of the first data block is read, and the data is processed according to the operation rules of the preset hash algorithm, such as data padding, grouping, and compression function iteration. A fixed-length initial hash value is output, such as 256 characters. This initial hash value serves as the basic input for processing subsequent data blocks. Starting from the initial hash value, iterative hash processing is performed on the subsequent data blocks (blocks 2 to N) in the data block set: the hash output result of the previous data block is taken, such as the initial hash value of block 1. The initial hash value is concatenated with the binary data of the current data block to be processed (e.g., block 2) to form a new mixed data. The mixed data is then hashed again using the same preset hash algorithm to obtain the hash output result of the current data block. This output result is then used as the input for processing the next data block (e.g., block 3), and this process is repeated until the hash processing of all data blocks is completed. After all data blocks are processed, the hash output result of the last data block is determined as the transaction trajectory hash sequence. The system associates and stores this hash sequence with the corresponding land parcel number, data block set number, and hash calculation timestamp, and simultaneously synchronizes it to the system's distributed storage module.

[0062] Because iterative hashing is based on a preset and unified hash algorithm, any modification to the binary data of any data block, such as a change in the transaction price or a change in the registration number, will cause changes in the hash results of that data block and all subsequent data blocks, ultimately altering the transaction trajectory hash sequence. This iterative hashing scheme based on a unified hash algorithm can effectively avoid the risk of data being easily tampered with under traditional centralized architectures, ensuring the integrity and authenticity of transaction trajectory data, and providing a technical identifier independent of the system operator for subsequent data verification.

[0063] In a preferred embodiment of the present invention, step 500 includes: Step 501 involves encapsulating the transaction trajectory hash sequence with the current timestamp and the digital signature of the transaction institution to generate block data to be verified. Specifically, this includes: First, retrieving the transaction trajectory hash sequence, which serves as the core identifier of the block data and must be uniquely associated with the land parcel number in the underlying dataset to ensure the block data can be accurately traced to the specific transaction target; Second, automatically obtaining the current timestamp, which must be accurate to the second and in the format YYYY-MM-DDHH:MM:SS, to record the specific time of block data encapsulation and avoid temporal inconsistencies; Simultaneously, calling the institution digital signature module of the transaction service subsystem, whereby the transaction institution generates a digital signature using its preset institution digital certificate. This institution digital certificate is issued by an authoritative CA institution. Specifically, after logging into the system, the system confirms the data to be signed in the signature module, namely the transaction trajectory hash sequence and the current timestamp. After verifying the validity of the institution digital certificate, a digital signature of the transaction institution is generated. The validity of the digital certificate includes aspects such as the certificate's validity period and the consistency between the certificate holder and the transaction institution.

[0064] Finally, according to the preset block data structure, the transaction trajectory hash sequence, current timestamp, and transaction institution digital signature are integrated and encapsulated. At the same time, a unique block identifier is assigned to this encapsulated data, which is generated using the rules of land parcel number, encapsulation timestamp, and 3-digit serial number to form the block data to be verified. This block data to be verified needs to be temporarily stored in the system's block preprocessing module and associated with the corresponding land parcel number and transaction process instance identifier to ensure that it forms a data closed loop with the previous steps (such as steps 400 to 405), providing a complete and compliant basic data unit for subsequent consensus verification.

[0065] Step 502 involves broadcasting the block data to be verified to blockchain network nodes for consensus verification to obtain a consensus verification result. Specifically, this includes: activating a block broadcasting mechanism based on the block data to be verified. These blockchain network nodes consist of multiple pre-defined entity nodes, including the transaction center node corresponding to the transaction service subsystem, the regulatory agency node corresponding to the regulatory tracking subsystem, and third-party notary office nodes. Each node possesses independent data verification and voting permissions to mitigate the risk of single-node decision-making under traditional centralized architectures. After the block data to be verified is broadcast to each node, each node automatically calls its local... The block verification module performs consensus verification operations: First, it verifies the legality of the transaction trace hash sequence. The node retrieves the original record of the transaction trace hash sequence generated in step 405 and compares it with the consistency of the sequence in the block to be verified to ensure that the hash sequence has not been tampered with. Second, it verifies the rationality of the current timestamp. The node determines whether the timestamp is within the reasonable error range of the current system time, such as ±30 seconds, and excludes invalid time-series data. Third, it verifies the validity of the digital signature of the transaction institution. The node connects to the authoritative CA certification interface to verify whether the signature is generated by the digital certificate of the preset transaction institution and whether the certificate is within its validity period.

[0066] After each node completes its independent verification, it provides feedback on the verification results through the blockchain network's voting mechanism, including: pass or fail. The node feedback results are tallied according to the consensus rules. Consensus is reached if more than 2 / 3 of the nodes vote in favor. If the statistical results meet the consensus rules, a consensus verification pass result is generated, and the verification timestamp and voting opinions of each node are recorded. If the consensus rules are not met, a consensus verification fail result is generated, and the reasons for the objections of the failing nodes are marked, such as inconsistent transaction trace hash sequences or invalid digital signatures, providing a basis for subsequent data correction.

[0067] Step 503: Based on the consensus verification result, the verified block data is distributed and stored to obtain the stored block data. Specifically, this includes: after obtaining the consensus verification result, initiating the persistent storage operation of the verified block data; first, extracting the block identifier and land parcel number from the block data to be verified, using these two as core association fields to ensure that the stored block data can be quickly located via the land parcel number; subsequently, according to the distributed storage protocol, synchronizing the block data to all nodes in the blockchain network, including: transaction center nodes, regulatory agency nodes, and third-party notary agency nodes. After receiving the block data, each node calls its local node storage module to write the block data into its respective encrypted local database. The database uses a symmetric encryption algorithm to ensure storage security. Storage security is ensured. During storage, each node records the timestamp of the block data's entry and the node identifier, forming a record linking the node, block, and entry time. This facilitates subsequent data traceability and data recovery in case of node failure. Simultaneously, the system's distributed storage monitoring module monitors the storage status of each node in real time. If a node fails to store data, such as due to a network interruption preventing data from being written, a data retransmission mechanism is automatically triggered. This mechanism resynchronizes the block data from other successfully stored nodes to the failed node until all nodes have completed storage. This process ensures that block data is retained across multiple nodes, effectively mitigating the risk of data loss caused by a single node failure in traditional centralized storage. It also enables multi-subject supervision and backup of block data, providing a foundation for subsequent data security verification.

[0068] Step 504: Based on the stored block data, obtain the corresponding on-chain hash value. Specifically, this includes: generating the on-chain hash value based on the block data already stored on each node; first, retrieving the complete stored block data from any node that has completed storage, such as a regulatory agency node, due to its regulatory authority. This data must contain all information including the transaction trace hash sequence, current timestamp, transaction institution digital signature, block identifier, and storage timestamp; then, calling a preset hash algorithm, such as the SHA-256 algorithm, to perform hash calculation on the retrieved complete stored block data. During the calculation process, it is necessary to ensure that every field of the block data (including hidden fields such as the storage timestamp) is processed. To avoid hash value deviations due to missing fields, a fixed-length hash value (e.g., 256 characters) is generated after calculation, which becomes the on-chain hash value of the corresponding block data. Finally, the on-chain hash value is associated with and integrated with the corresponding block identifier, plot number, storage node identifier, and calculation timestamp, and stored in the system's on-chain hash value management library. Simultaneously, the on-chain hash value is synchronized to all nodes in the blockchain network, ensuring that each node holds this hash value. This provides unified on-chain benchmark data for subsequent comparisons between the on-chain hash value and the real-time calculated hash value. Furthermore, due to the unidirectional nature of the hash algorithm, any modification to stored block data will result in a change in the on-chain hash value, thus achieving tamper-proof protection for on-chain data.

[0069] In a preferred embodiment of the present invention, step 600 includes: Step 601 involves generating a data verification instruction based on the on-chain hash value. Specifically, this includes: First, retrieving the on-chain hash value using the verification management module of the regulatory tracking subsystem within the land secondary market transaction service system. This on-chain hash value must be uniquely associated with the land parcel number in the underlying dataset to be traded, ensuring accurate data verification targeting of the specific transaction and avoiding confusion with other transaction data. Second, following a preset verification instruction format, the on-chain hash value is used as the core instruction parameter, supplemented with the corresponding block identifier (derived from the block identifier in step 501) and the transaction process instance number to verify the target object of the operation. Simultaneously, the instruction must embed verification triggering entity information to distinguish verification requests initiated by different entities. Finally, the content containing the on-chain hash value, block identifier, transaction process instance number, and verification entity information is formatted and encapsulated to generate a structured data verification instruction. This instruction must be temporarily stored in the instruction queue of the regulatory tracking subsystem, marked as pending execution, and associated with the corresponding land parcel number, ensuring a data loop with the preceding steps (steps 501 to 504), providing a clear and targeted operational basis for subsequent real-time data processing.

[0070] Step 602: In response to the data verification command, the underlying dataset to be traded, the bidding qualification dataset, the transaction result data, and the contract filing dataset are linked and integrated. Key data fields are extracted and a real-time transaction trajectory data sequence is generated. Specifically, this includes: based on the data verification command, automatically responding to and triggering a data integration operation, and retrieving four types of core datasets respectively: First, the underlying dataset to be traded originates from the supply and demand service subsystem and includes land parcel number and owner information; second, the bidding qualification dataset originates from the transaction service subsystem and includes qualification verification results and bidder identity identifiers; third, the transaction result data originates from the transaction service subsystem and includes transaction price and successful bidder information. Fourth, the contract filing dataset originates from the online contract signing and filing subsystem and includes the filing number and filing timestamp. Using the land parcel number in the data verification instruction as the core associated field, the above four types of datasets are associated and integrated. Redundant information in the datasets, such as temporary modification records during the bidding application process and non-core operation logs in the filing process, is removed. Key data fields are extracted, including the land parcel number, transaction price, successful bidder's identity identifier, contract filing number, and qualification verification result. Among them, the transaction price includes uppercase and lowercase formats, the successful bidder's identity identifier is the unified social credit code for enterprises and the ID card number for individuals, and the qualification verification result includes pass or fail.

[0071] Following the chronological logic of the transaction process, the process begins with supply and demand review, followed by qualification verification, then auction and transaction, and finally contract filing. The extracted key data fields are arranged in chronological order to generate a real-time transaction trajectory data sequence. The real-time transaction trajectory data sequence needs to be labeled with the timestamp of each transaction stage corresponding to each field, such as the completion time of supply and demand review and the time of qualification verification, to ensure consistency with the transaction trajectory data sequence generated in step 403 in terms of field logic and time sequence, thus providing a standardized and unified data source for subsequent hash calculations.

[0072] Step 603 involves performing cryptographic hash calculations on the real-time transaction trajectory data sequence to generate real-time hash values. Specifically, this includes: first, calling a preset cryptographic hash algorithm; the preset process for the preset cryptographic hash algorithm (such as the SHA-256 algorithm) is as follows: During the system initialization and deployment phase, based on data security-related configuration specifications and considering the sensitivity level and anti-tampering requirements of land transaction data, suitable algorithms are selected from the cryptographic algorithm library recognized by the national cryptographic management department; after selection, the algorithm type and parameters are written into the module configuration file and fixed through the configuration interface of the data security module. The algorithm type is, for example, SHA-256, and the parameters include hash value output length and data processing block size. Simultaneously, the algorithm information is synchronized to the system's hash calculation module, the monitoring and tracking subsystem, and each node of the blockchain network to ensure that the entire hash calculation process adopts a unified standard and avoids verification deviations caused by algorithm differences.

[0073] Based on the aforementioned preset cryptographic hash algorithm, hash calculations are performed on the real-time transaction trajectory data sequence. During the calculation process, the field formats of the real-time transaction trajectory data sequence are first standardized and verified to ensure that text fields are UTF-8 encoded and numeric fields are in the preset numeric format, avoiding calculation deviations due to format differences. Text fields include land parcel numbers and registration numbers, while numeric fields include transaction prices. Subsequently, following the processing flow of the preset cryptographic hash algorithm, such as data filling, grouping iteration, and compression function operations, each key data field in the sequence is processed sequentially. The processing results of each field are integrated to generate a fixed-length (e.g., 256 bits) real-time hash value. After generating the real-time hash value, the system associates and stores this hash value with the corresponding real-time transaction trajectory data sequence and land parcel number, temporarily storing it in the hash cache area of ​​the data security module. Simultaneously, the timestamp of the hash calculation is recorded, accurate to the second, ensuring that the real-time hash value can be traced back to the specific calculation process, providing verifiable numerical evidence for subsequent comparison operations.

[0074] Step 604 involves performing a consistency comparison between the real-time calculated hash value and the on-chain hash value to obtain the hash comparison result. Specifically, this includes: First, retrieving the real-time calculated hash value generated in step 603 and the on-chain hash value generated in step 504, and initiating a consistency comparison operation. During the comparison, the consistency of the basic attributes of the two hash values ​​is first verified, including whether the character length is the preset length and whether the character encoding is consistent (e.g., the preset length is 256 bits, and the character encoding is consistent, such as ASCII encoding). If the basic attributes are inconsistent, the comparison is directly marked as failing and the difference type is recorded, such as length mismatch. If the basic attributes are consistent, the two hash values ​​are compared character by character. The system analyzes the character content of each hash value and determines whether each character is identical. After comparison, a hash comparison result is generated, which must clearly indicate whether the comparison is consistent or inconsistent. If the comparison is consistent, the complete character content of the two hash values ​​and the comparison completion time must be recorded. If the comparison is inconsistent, the position of the first character difference must be located, and the real-time transaction trajectory data sequence must be associated with the transaction trajectory data sequence stored on the chain. Key data fields that may have differences, such as the transaction price field and the filing number field, must be marked. At the same time, the comparison result must be associated with the corresponding land parcel number and data verification instruction number to ensure that a data traceability chain is formed with the previous steps and to avoid the comparison result being isolated.

[0075] Step 605: Based on the hash comparison result, complete the integrity verification and anti-tampering verification of the transaction process, and generate a verification report containing a verification timestamp. Specifically, this includes: based on the hash comparison result of step 604, performing integrity and anti-tampering verification of the transaction process: if the hash comparison is consistent, it indicates that the real-time transaction data and the transaction data stored on the chain are identical, and it can be determined that the entire transaction process data is complete and has not been tampered with; if the hash comparison is inconsistent, further verify the transaction process data corresponding to the marked difference field, such as when verifying the transaction price field, by retrieving the transaction service. The subsystem records the bidding logs to pinpoint the specific reasons for data discrepancies, such as data entry errors or malicious tampering. After verification, a verification report is generated according to a preset verification report template. The report content must include: verification report number, verification timestamp, plot number, on-chain hash value, real-time calculated hash value, hash comparison result, integrity and tamper-proof verification conclusion, and participating entities. The verification report number is generated using the plot number, verification timestamp, and 3-digit serial number rule. The verification timestamp is accurate to the second. Participating entities include regulatory agencies and trading centers.

[0076] After the report is generated, the verification report will be stored in the report management library of the regulatory tracking subsystem and simultaneously pushed to the regulatory agency node for querying and access. In addition, the report needs to be associated with the corresponding transaction process instance identifier to ensure that the regulatory agency can trace the complete transaction data through the report, thus meeting the functional requirements of the regulatory tracking subsystem for independent verification of transaction data.

[0077] like Figure 2 As shown, embodiments of the present invention also provide a blockchain-based land secondary market transaction data verification, storage, and processing system, including: The supply and demand service module is used to generate target information and transaction announcements based on the basic dataset to be traded, publish transaction announcements and collect bidding application datasets, and obtain bidding qualification datasets through multi-dimensional verification of the bidding application datasets; The transaction service module is used to load the initial bidding timing strategy and start the transaction process based on the bidding qualification dataset, and collect the transaction event sequence in real time; extract dynamic transaction features based on the transaction event sequence; generate process control parameters based on the dynamic transaction features; adjust the initial bidding timing strategy using the process control parameters; execute and record the optimized bidding process; and obtain transaction result data. The online contract signing and filing module is used to obtain contract terms data based on transaction result data; verify the ownership information in the contract terms data to obtain ownership verification results; trigger the electronic signature process based on the ownership verification results to obtain signed contract documents; and perform filing registration on the signed contract documents to obtain a contract filing dataset. The blockchain evidence storage module is used to link and integrate the basic dataset to be traded, the bidding qualification dataset, the transaction result data, and the contract filing dataset, extract key data fields to generate a transaction trajectory hash sequence; encapsulate the transaction trajectory hash sequence with timestamps and institutional digital signatures to obtain the block data to be verified; and perform consensus verification and distributed storage on the block data to be verified to obtain the corresponding on-chain hash value. The regulatory tracking module is used to perform real-time data hash calculations based on on-chain hash values ​​to obtain real-time calculated hash values. By comparing the consistency between the on-chain hash values ​​and the real-time calculated hash values, a verification report is obtained.

[0078] It should be noted that this system is a system corresponding to the above method. All implementation methods in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.

[0079] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A blockchain-based method for verifying, storing, and processing land secondary market transaction data, characterized in that: The method includes: Step 100: Generate target information and transaction announcement based on the basic dataset to be traded, publish the transaction announcement and collect the bidding application dataset, and obtain the bidding qualification dataset through multi-dimensional verification of the bidding application dataset; Step 200: Based on the bidding qualification dataset, load the initial bidding timing strategy and start the transaction process, and collect the transaction event sequence in real time; extract dynamic transaction features based on the transaction event sequence; generate process control parameters based on the dynamic transaction features; adjust the initial bidding timing strategy using the process control parameters, execute and record the optimized bidding process, and obtain transaction result data; Step 300: Based on the transaction result data, obtain the contract terms data; verify the ownership information in the contract terms data to obtain the ownership verification result; trigger the electronic signature process based on the ownership verification result to obtain the signed contract document; perform filing registration on the signed contract document to obtain the contract filing dataset. Step 400: The basic dataset to be traded, the bidding qualification dataset, the transaction result data, and the contract filing dataset are linked and integrated, and key data fields are extracted to generate a transaction trajectory hash sequence; Step 500: Encapsulate the transaction trajectory hash sequence with timestamps and institutional digital signatures to obtain the block data to be verified; Perform consensus verification and distributed storage on the block data to be verified to obtain the corresponding on-chain hash value. Step 600: Based on the on-chain hash value, perform real-time data hash calculation to obtain the real-time calculated hash value. By comparing the consistency between the on-chain hash value and the real-time calculated hash value, a verification report is obtained.

2. The method for verifying, storing, and processing land secondary market transaction data based on blockchain according to claim 1, characterized in that, Before step 100, the method further includes: Receive raw land supply information, perform structured processing on the raw land supply information, and extract and generate structured supply data containing plot number, owner information, plot location and area; The structured supply data is audited and verified to obtain a supply dataset with an audit status. Based on the supply dataset with an audit status, the verified supply data is encapsulated into a basic dataset to be traded, which includes land parcel numbers and owner information.

3. The method for verifying, storing, and processing land secondary market transaction data based on blockchain according to claim 2, characterized in that, Step 100 includes: Based on the underlying dataset to be traded, generate the target asset metadata, and construct a structured transaction announcement based on the target asset metadata; The structured transaction announcement is published to the public through the announcement publishing interface, triggering and collecting the application data submitted by bidders to form a bidding application dataset; Perform multi-dimensional verification, including identity verification, qualification review, and deposit verification, on the bidding application dataset to obtain a bidding qualification dataset containing the verification results.

4. The blockchain-based land secondary market transaction data verification, storage, and processing method according to claim 3, characterized in that, Step 200 includes: The transaction process instance is initialized based on the bidding qualification dataset. During the initialization process, an initial bidding timing strategy including bidding interval and bidding round is configured. Based on the operation of the initial bidding timing strategy, a transaction event sequence containing complete timestamps is obtained. Time-series analysis is performed on the transaction event sequence to extract dynamic transaction features, including bidding frequency and price fluctuations; Based on the dynamic trading characteristics, the bidding activity index and price volatility are calculated, and the two are weighted and fused to obtain the process control parameters; The bidding interval and bidding round parameters in the initial bidding timing strategy are dynamically adjusted using the process control parameters to obtain an optimized bidding timing strategy; the bidding process is executed based on the optimized bidding timing strategy to obtain a bidding event record containing complete bidding records; The bidding event records are cleaned and formatted to form a standardized bidding dataset; the transaction price and the winning bidder are determined based on the final bid records in the bidding dataset, and transaction result data containing the transaction price, transaction time and the identity information of the winning bidder is generated.

5. The blockchain-based land secondary market transaction data verification, storage, and processing method according to claim 4, characterized in that, Step 300 includes: Based on the land parcel number and owner information in the basic dataset to be traded, and the transaction price and winner's identity information in the transaction result data, a transaction feature vector containing price and identity dimensions is constructed. The transaction feature vector is normalized to obtain a standardized feature vector; the standardized feature vector is then linearly transformed to obtain a contract clause parameter vector. The contract terms parameter vector is mapped to a preset contract terms template space to generate contract terms data containing complete transaction terms; Cross-validate the land parcel number and owner information in the contract terms data to obtain ownership verification results including verification time and verification results.

6. The blockchain-based land secondary market transaction data verification, storage, and processing method according to claim 5, characterized in that, Step 300 also includes: Based on the verification pass mark in the ownership verification result, a multi-party electronic signature process is triggered to generate a legally valid signed contract document; Perform an integrity digest calculation on the signed contract documents to generate a unique digital digest of the contract documents; The digital digest is linked with the contract number, signatory information, and signing timestamp to form a complete filing record; The filing records are persistently stored in a distributed filing database to generate a contract filing dataset containing the filing number, the entry timestamp, and a digital digest of the contract documents.

7. The blockchain-based land secondary market transaction data verification, storage, and processing method according to claim 6, characterized in that, Step 400 includes: The land parcel numbers in the basic dataset to be traded, the qualification verification results in the bidding qualification dataset, the transaction prices and winning bidder information in the transaction results dataset, and the filing numbers in the contract filing dataset are linked and integrated to form complete transaction trajectory data; Extract key data fields, including land parcel number, transaction price, successful bidder identification, and contract filing number, from complete transaction trajectory data; The key data fields are serialized according to the transaction time sequence to obtain the transaction trajectory data sequence; The transaction trajectory data sequence is converted into a binary data sequence by character encoding; the binary data sequence is then divided into data blocks to form an ordered set of data blocks. An initial hash value is generated based on the first data block in the data block set, and subsequent data blocks are iteratively processed based on the initial hash value. The hash output of each data block serves as the input for the next data block. After processing all data blocks, a transaction trajectory hash sequence is obtained.

8. The blockchain-based land secondary market transaction data verification, storage, and processing method according to claim 7, characterized in that, Step 500 includes: The transaction trajectory hash sequence is encapsulated with the current timestamp and the digital signature of the transaction institution to generate block data to be verified. The block data to be verified is broadcast to blockchain network nodes for consensus verification, and a consensus verification result is obtained. Based on the consensus verification results, the verified block data is distributed and stored to obtain the stored block data; Based on the stored block data, the corresponding on-chain hash value is obtained.

9. The blockchain-based land secondary market transaction data verification, storage, and processing method according to claim 8, characterized in that, Step 600 includes: Generate data verification instructions based on the on-chain hash value; In response to the data verification instruction, the basic dataset to be traded, the bidding qualification dataset, the transaction result data and the contract filing dataset are linked and integrated, key data fields are extracted and a real-time transaction trajectory data sequence is generated; Cryptographic hash calculations are performed on the real-time transaction trajectory data sequence to generate real-time hash values; The real-time calculated hash value is compared with the on-chain hash value to obtain the hash comparison result. Based on the hash comparison results, the integrity verification and anti-tampering verification of the transaction process are completed, and a verification report containing a verification timestamp is generated.

10. A blockchain-based land secondary market transaction data verification, storage, and processing system, wherein the system implements the method as described in any one of claims 1 to 9, characterized in that, include: The supply and demand service module is used to generate target information and transaction announcements based on the basic dataset to be traded, publish transaction announcements and collect bidding application datasets, and obtain bidding qualification datasets through multi-dimensional verification of the bidding application datasets; The transaction service module is used to load the initial bidding time series strategy and start the transaction process based on the bidding qualification dataset, and to collect the transaction event sequence in real time; and to extract dynamic transaction features based on the transaction event sequence. Process control parameters are generated based on dynamic transaction characteristics; the initial bidding timing strategy is adjusted using the process control parameters, the optimized bidding process is executed and recorded, and transaction result data is obtained. The online contract signing and filing module is used to obtain contract terms data based on transaction result data; Verify the ownership information in the contract terms data to obtain the ownership verification results; The electronic signature process is triggered based on the ownership verification results, resulting in a signed contract document; The signed contract documents are registered and filed to obtain a contract filing dataset; The blockchain evidence storage module is used to link and integrate the basic dataset to be traded, the bidding qualification dataset, the transaction result data, and the contract filing dataset, extract key data fields to generate a transaction trajectory hash sequence, and encapsulate the transaction trajectory hash sequence with timestamps and institutional digital signatures to obtain the block data to be verified. Consensus verification and distributed storage are performed on the block data to be verified to obtain the corresponding on-chain hash value; The regulatory tracking module is used to perform real-time data hash calculations based on on-chain hash values ​​to obtain real-time calculated hash values. By comparing the consistency between the on-chain hash values ​​and the real-time calculated hash values, a verification report is obtained.

Images