Urban planning approval evidence storage system based on block chain

Abstract

The invention relates to the technical field of e-government affairs and block chain application, and particularly discloses a block chain-based urban planning approval evidence storage system. The system comprises a plurality of consensus nodes which are configured to execute the following steps: analyzing life cycles of approval items into sequential stage sequences according to a rule template; dynamically creating an independent stage evidence storage chain for each stage, wherein the independent stage evidence storage chain is used for packaging all events and data in the stage; the chain head block of the evidence storage chain of the next stage is embedded into the ending state value of the chain of the previous stage, so that all the stage chains are connected in series to form an approval main chain; meanwhile, a global evidence storage anchoring chain is maintained and used for responding to a state transition event of a stage chain, capturing a chain state snapshot and calculating a structured abstract, and anchoring proof is generated for global notarization. Through the structure of staged chain evidence storage and double-layer anchoring verification, data evidence storage which cannot be tampered in the whole life cycle and multi-dimensional operation process of urban planning approval, can be accurately traced and is strict in logic is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of e-government and blockchain application, more particularly, to a city planning approval evidence storage system based on blockchain. BACKGROUND

[0002] City planning approval is an administrative activity involving multi-department cooperation, long process and numerous files. Under the background of digital governance, ensuring the completeness, traceability and credibility of the whole approval process record is of great significance for improving administrative efficiency, protecting public right-to-know and preventing legal risks.

[0003] The existing electronic approval system usually uses centralized database or simple electronic file management system to store the approval record. This kind of technical solution has the following defects: first, the data is stored in the server of a specific department, which has the risk of single point failure, and the internal personnel have the potential ability to tamper with the data, which makes it difficult to independently and credibly verify the completeness and authenticity of the key records of the approval process (such as opinion modification, version replacement and time node) to the outside (such as other departments, the public or judicial organs). Second, the information systems of different approval departments are often independently constructed, forming a "data island", and the approval data of a project at different stages is stored in different systems, lacking a whole life cycle and inseparable correlation proof, which makes it necessary to manually piece together information from multiple heterogeneous systems when auditing or tracing the responsibility afterwards, which is inefficient and prone to errors. Finally, the existing solution cannot effectively support the parallel scheme exploration and backtracking demonstration scenarios that may occur in the approval process, and the related process records are either missing or lack rigorous version management and branch logic records, which cannot clearly reflect the complete track of decision-making.

[0004] Therefore, in view of the above problems, a city planning approval evidence storage system based on blockchain is proposed to solve the problems of insufficient transparency of transaction approval process, questionable data credibility and difficulty in whole-chain tracing. SUMMARY

[0005] In order to overcome the above-mentioned defects of the prior art, the embodiments of the present application provide a city planning approval evidence storage system based on blockchain to solve the problems raised in the background art.

[0006] To achieve the above-mentioned purpose, the present application provides the following technical scheme: The present application provides a city planning approval evidence storage system based on blockchain. The system aims to build a trusted and traceable approval data evidence storage framework, decouples the approval life cycle into discrete stages and stores them respectively, and then links and anchors them globally through cryptography to ensure the continuity, integrity and verifiability of the data.

[0007] Specifically, the system comprises a plurality of consensus nodes interconnected and configured to execute the following scheme: first, according to a preset project type rule template, the full life cycle of an approval project is parsed into a sequence of approval stages with a preset logical order. Subsequently, a separate stage storage chain is dynamically created for each approval stage in the sequence, which is only used to sequentially encapsulate all approval events and associated data within the corresponding stage. Then, by embedding the first block of the next stage storage chain into the final state consensus value of the previous stage storage chain, all stage storage chains are linked in the approval logical order to form an approval main chain representing the complete trajectory of the project.

[0008] Meanwhile, the system maintains a global storage anchor chain, which is used to capture the chain state snapshot in response to the preset state transition event of each stage storage chain and calculate the structured digest of the snapshot. The digest, together with the stage identifier, project identifier and timestamp, is packaged into an anchor proof, which is recorded after consensus, thereby constituting a global notarization of the key state of the stage storage chain.

[0009] Preferably, the process of dynamically creating a stage storage chain is specifically as follows: when the system determines that all preset state transition conditions of the current active approval stage are met, a stage transition is triggered; the system generates a new stage storage chain according to the configuration parameters predefined for the next stage in the rule template, which includes the chain data structure specification and the event record format standard; and in the genesis block of the new stage storage chain, a link proof field pointing to a specific final block of the previous stage storage chain is compulsorily included.

[0010] Preferably, the determination of the state transition condition is achieved by executing a preset on-chain verification rule. When verification is required, the relevant consensus nodes verify the state proof data of the current stage storage chain according to the rule and generate a result certificate that can be verified by the consensus network, which is stored as a key approval event record in the current stage storage chain or the global storage anchor chain.

[0011] Preferably, the linking mechanism between the stage storage chains adopts a binding method containing time constraints. The method includes: when the previous stage storage chain is terminated, calculating its final state consensus value S1 and selecting a future time point parameter T; binding S1 and T according to a preset rule to generate a binding commitment value C, and writing C in advance into the global storage anchor chain; after the condition indicated by the time point parameter T is met, creating the next stage storage chain, disclosing the verification information of S1 and T in the genesis block thereof, and the system re-calculates C and compares it with the commitment value stored on the chain, and only when the comparison is successful and the constraint condition is met, the genesis block is accepted by consensus.

[0012] Preferably, the structured summary calculation process is: for the data blocks contained in the captured chain state snapshot, a hierarchical data relationship structure is constructed according to the system predetermined structure organization rule, and the root node information of the structure is summarized.

[0013] Preferably, the system constructs a composite space-time identifier for each approval project, which is formed by fusing the standardized location code of the project core geographic area and the project establishment time code according to a specific rule. The identifier is recorded in the genesis block of the starting stage of the approval main chain and the related anchor proof. The system provides an association query mechanism based on the identifier, which can quickly retrieve and aggregate the anchor proofs of related approval projects on the global evidence anchor chain according to a given geographic location range or time interval, and then locate the approval main chain data.

[0014] Preferably, the system supports nonlinear extension processing of the approval track. Specifically, when multiple alternative solutions need to be explored in parallel in a certain approval stage, the system allows multiple parallel exploratory branch chains to be forked based on the consensus block state point of the current stage evidence chain; all exploratory branch chains share the same history, and their fork starting blocks point to the same parent state point; the global evidence anchor chain generates state anchor proofs for each active exploratory branch chain independently; when a solution is selected through an approval decision, the system publishes a convergence decision proof on the global evidence anchor chain, and formally connects the selected branch chain after its fork point to the approval main chain as the main continuation, and marks the other branch chains as historical archive chains.

[0015] Preferably, the system implements a role-bound permission control mechanism. The mechanism predefines role-operation mapping rules for each approval stage, which specifies which role of the node has the right to initiate a specific type of event record on the stage evidence chain; when a node submits an event record to the stage evidence chain, it must attach its verified role identification information; before packaging the event record, the consensus node of the stage evidence chain verifies whether the role identification of the submitting node conforms to the corresponding operation permission specified in the mapping rule, and records the role identification in the event record.

[0016] Preferably, the system connects with an external administrative approval business system through a trusted data synchronization gateway. The gateway is configured to: listen to the predefined approval state change signals in the external business system, collect event data and trusted evidence; after verifying the validity of the event data inside the gateway, construct a standard evidence request and attach the on-chain verification information, and submit it to the corresponding stage evidence chain for consensus evidence; at the same time, the gateway converts the key state changes confirmed on the stage evidence chain or the global evidence anchor chain into a format recognizable by the external system and synchronously pushes it.

[0017] Preferably, the global evidence anchoring chain is deployed with automatic verification rules for performing cross-chain consistency automatic verification. The rules are configured to listen to newly generated anchoring proofs and automatically trigger the execution of at least one of the following verification logics: Verify the structured summary of the state of the phase evidence chain in the new anchoring proof, whether it is consistent with the summary value calculated independently from the latest state of the chain; For the phase evidence chain claiming to link to the previous phase, verify whether the prequel chain link proof declared in its genesis block matches the state summary in the latest final state anchoring proof of the prequel chain recorded by the global evidence anchoring chain; According to the composite space-time identifier carried by the anchoring proof, trigger the comparison of specific planning parameters of other anchored items within the preset associated range, and generate a conflict warning record on the anchoring chain when the parameter conflict exceeds the preset threshold.

[0018] All the execution and results of the verification are generated corresponding verification traces and associated stored in the global evidence anchoring chain.

[0019] The technical effects and advantages of the present application are: Compared with the prior art, the present application decouples the approval full life cycle by logical stages, dynamically creates independent phase evidence chains for each stage, and constructs a "staged chain evidence" structure. The system automatically divides the approval stages according to the preset rule templates, and initializes a new blockchain at the stage transition. The operation and data of each stage are recorded in sequence in its exclusive chain, and the starting block of the next stage chain needs to be cryptographically linked to the final state of the previous stage chain. This way of working makes the natural evolution of the approval process and the growth of the data structure of the blockchain synchronous, realizing the native digital mapping of the approval track. It decomposes the complex approval long process into multiple chain modules that can be independently managed, verified and audited, avoiding the performance and data mixing problems of a single long chain, and at the same time, through the inter-chain linking, it forcibly guarantees the continuity and unbreakability of the full-process record. It can accurately locate and isolate any link in the approval process for verification, improving the organization of the evidence data and the pertinence of the ex post facto review.

[0020] Compared with the prior art, the application establishes a double-layer verification system by introducing a cross-chain linking binding mechanism containing time constraints and a global evidence anchoring chain. When linking between phase evidence chains, the system binds the terminal state of the previous chain with a future time parameter to generate a commitment and anchor in advance. The creation of the subsequent chain must disclose matching information and pass the time verification, and then be recognized. At the same time, an independent global anchoring chain continuously captures the state snapshots of each phase chain at key nodes and notarizes them. Its working mode is to provide unified timestamp sequence notarization and state integrity anchor points for decentralized phase chains. It strengthens the non-repudiation of the transition between phases, prevents post-linking attacks on the "terminated" historical phases, and also provides a lightweight, quickly searchable project state index through the global anchoring chain. The security and reliability of the entire evidence system in the time dimension are enhanced, and an efficient global state verification portal is provided.

[0021] Compared with the prior art, the application improves the adaptability of the system to complex approval scenarios by assigning a composite space-time identifier to the approved project and designing an associated query mechanism, as well as supporting a non-linear exploration branch chain evidence model. The system fuses the project geographic location and time information to generate a unique identifier, and based on this, implements cross-project association retrieval on the global chain. When multiple schemes are running in parallel during the approval, the system allows the creation of exploratory branch chains from the main chain to record independently, and finally merges the selected branch into the main chain through the convergent resolution. The system works in this way, so that the evidence system not only records linear processes, but also structurally accommodates decision tree-like argumentation processes. It realizes the association analysis of approval data in the spatial dimension and the complete record in the decision logic dimension. It enhances the reviewability of urban planning in spatial coordination and ensures that the argumentation traces of different schemes in the decision-making process are completely preserved. BRIEF DESCRIPTION OF DRAWINGS

[0022] Fig. 1 The overall flowchart of the urban planning approval evidence system of the application.

[0023] Fig. 2 The phase evidence chain creation and linking mechanism flowchart of the application.

[0024] Fig. 3 The non-linear processing and permission control branch diagram of the application's approval track. DETAILED DESCRIPTION

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

[0026] Example 1 As attached Figs. 1 to 3 The implementation details of the blockchain-based urban planning approval and evidence storage system are as follows: S1. Project Initialization and Approval Phase Sequence Generation The system received a project approval instruction for an urban planning project. This instruction includes a unique project identifier (PID) and the project type. Core geographical coordinates of the project and project initiation timestamp .

[0027] The system is based on project type Query the pre-set project type rule template database to obtain the corresponding rule template. Rule Template The system defines the standard approval stage sequence and its logical order for this type of project using a structured data format. For the current project Generate an approval stage sequence , For an ordered list, such as ,in This indicates the "draft planning stage". This indicates the "joint departmental review stage". This indicates the "public opinion solicitation phase". This indicates the "approval stage of the planning results".

[0028] Simultaneously, the system executes the process of generating composite spatiotemporal identifiers. First, it generates geographic coordinates. Input the Geohash encoding algorithm to obtain a string encoding representing a geographical region. Then, With project initiation timestamp The strings are concatenated, and a SHA-256 hash operation is performed on the concatenated strings to generate a composite spatiotemporal identifier for the project. ,Right now . It possesses both spatial and temporal attributes.

[0029] S2. Initial Stage: Creation and Data Recording of the Evidence Storage Chain The system has entered the approval phase sequence. The first stage According to the rule template China Preset configuration parameters The system initializes the first stage of the evidence storage chain. . The consensus mechanism type, block data structure definition, and event data format specification allowed to be recorded in this phase.

[0030] Genesis block of Generated by the system and reached network consensus. The data structure of contains the following fields: (value is PID), (value is the identity of ), and chain configuration parameters determined by . After that, enter the state of receiving transactions.

[0031] In the duration of , all approval operations related to this phase are constructed as transactions Tx. Each transaction Tx contains fields such as operation type, operation content hash, operator digital signature, timestamp, etc. For example, when submitting the initial planning draft file , the system calculates its file hash , and constructs a transaction of type "file submission". The operator signs using their private key to generate a signature . Subsequently, is broadcast to the network of .

[0032] The consensus nodes in the network verify the validity of and whether the transaction format conforms to the provisions of . After verification, multiple transactions are packaged into a new block , The block header of contains the hash value of the previous block , the Merkle root of the block transaction, and the block generation timestamp. In this way, the entire events of are recorded in chronological order.

[0033] S3. Phase state transition determination and verification When the business activities of proceed according to the preset logic to the point where it needs to be determined whether it can end, the system triggers the state transition determination process. The rule template defines a set of state transition conditions for . These conditions are coded as executable logic statements.

[0034] To verify whether the conditions are met, the system calls a verification smart contract deployed on the blockchain . The relevant nodes (e.g., regulatory nodes or phase advancement trigger nodes) submit a verification request to the contract , which contains a set of ProofData pointing to specific transactions (e.g., a list of transaction IDs proving that the final draft has been signed, a hash proving that the internal review meeting has been held, etc.). The contract automatically executes on-chain, reads the ProofData, and performs calculations and judgments based on the pre-set logic, finally outputs a boolean result (TRUE or FALSE) and a cryptographic proof of the calculation process .

[0035] Regardless of the value, the result and are structured into a result certificate transaction . is submitted to the blockchain network and recorded after consensus, forming a public and tamper-proof judgment record. If is TRUE, it means that the state transition conditions have been fully met.

[0036] S4. Creation of the next phase certificate chain and cross-chain time constraint linkage When the judgment result of S3 is TRUE and the system is ready to enter , the creation and linkage process of the phase certificate chain is executed. This process includes a time constraint binding mechanism.

[0037] First, when is confirmed as final, the system calculates the final state consensus value of . It is usually the block hash of the latest valid block , i.e. .

[0038] At the same time, the system selects a future time point parameter according to the pre-set strategy , the value of which is the current system time plus a fixed delay interval , i.e. , which can be 86400 seconds.

[0039] Secondly, the system executes the binding operation function Commit. This function binds and ​As input, output a binding commitment value. .

[0040] In this implementation, the Commit function is defined as follows: , where || represents string concatenation. The calculation yields... Then, the system immediately constructs a commitment transaction. Its core content is and will Submit to the global evidence storage and anchoring chain. The global evidence storage and anchoring chain, after consensus, will contain... The block is denoted as Thus, the commitment value Permanently public and locked.

[0041] When system time Reaching or exceeding the time point parameter (Right now After that, the system will allow it to... Creation Phase Evidence Chain .

[0042] create At that time, its genesis block The generation must include the following steps: In a specific data field, the final state value of the previous stage is explicitly written. (Field names can be) ) and the time parameters used .also, Further writing is required. Configuration parameters .

[0043] The network's consensus nodes receive Then, perform link verification: node reading. In and Verify the current time satisfy Recalculate the commitment value Query the global evidence storage anchor chain to retrieve the previously stored commitment value. Finally, a comparison is performed if and only if C' equals The verification passed. Accepted Officially activated.

[0044] This mechanism ensures that from arrive The links are tamper-resistant and have explicit time delay properties. and subsequent stages , The data recording method is the same as in S2 The recording method is the same, and the evidence storage chain at each stage is recorded through its genesis block. The fields are linked sequentially to form the project. The main approval chain.

[0045] Furthermore, the notarization process for each stage state of the global evidence storage anchor chain operates independently of the individual stage evidence storage chains. Nodes of the global evidence storage anchor chain continuously monitor the evidence storage chains at each stage (e.g., ...). , (For stage number). A state transition event of a preset type occurs. At times (for example, Creation complete The cumulative number of blocks has reached 1000. (Marked as terminated), the listener is triggered.

[0046] The node then directed to Network request to retrieve events Chain state snapshot at the moment of occurrence . Includes up to the trigger time The block header information of all consensus blocks.

[0047] Get Then, the nodes calculate their structured summaries. The calculation process uses the Merkle tree algorithm: ... The hash value of each block header is used as a leaf node. Group these leaf nodes in pairs and calculate the hash of the parent node. If the number of leaf nodes is odd, the last leaf node is paired with a null node; this process is repeated recursively until a unique root hash value is generated. . That is Structured summary.

[0048] Next, the node constructs an anchor proof transaction. . The data load includes: (PID) ( (logo) (value is) ), ( (type) and (Current time). Submitted to the global evidence storage anchor chain network, and after consensus is reached, packaged into a new block. In the middle. This block is... In the event A notarized record of the state at the time of the incident.

[0049] Furthermore, the execution process of the composite spatiotemporal identifier association query is initiated when cross-project planning analysis is required. Assume that a geographic area range needs to be queried. (corresponding to a set of Geohash prefixes) Within a time interval All projects approved internally.

[0050] The system query service first scans the global notarized anchor chain and reads all anchored proof transactions. For each transaction Extract its The field value is the STID of a specific project. Since the STID is geocoded... and timestamp Hash generation is necessary for geographic matching; the system needs to reconstruct or associate its original geocode G'. In one implementation, G' and... The STID is additionally stored in a queryable index during STID generation. The system looks up the index using the STID to obtain the corresponding G' and .

[0051] Then, the system performs a filtering judgment: checking whether the prefix of G' is contained in the target prefix set. In the middle; check at the same time Does it meet the requirements? If both conditions are met, then item P' is included in the result set.

[0052] The system ultimately outputs a list of PIDs for all eligible projects and their corresponding anchor proofs on the global evidence storage anchor chain. Users can then use this information to further locate and retrieve detailed approval main chain data for these projects.

[0053] Furthermore, the processing flow of the nonlinear branch of the approval trajectory during the approval stage... It will be activated if a scenario arises where multiple alternative solutions need to be evaluated in parallel.

[0054] Assuming in of Above, block height Block at the location This is a decision fork point. At this point, it is necessary to... The system simulates several scenarios. It executes a chain fork operation based on... create An exploratory branch chain, denoted as , ,..., .

[0055] Each branch chain ( From 1 to The genesis block of ) of All fields point to the same parent block hash Subsequently, regarding the first... All data, including discussions, modifications, and simulation results, for each scheme were recorded independently. In subsequent blocks, the branch chains do not interfere with each other.

[0056] The global evidence storage anchor chain is for each active [chain]. Each entity independently executes the notarization process to generate its own state anchoring proof.

[0057] After deliberation, the approving body made a decision and selected the [number]. One option. At this point, the system publishes a convergence resolution proof transaction on the global evidence storage anchor chain. , declare project In the stage The branch exploration has been completed, and the branch chain has been officially selected. As a basis for subsequent procedures.

[0058] When entering the next approval stage At that time, its stage of evidence storage chain The creation and linking (refer to S4) will be based on The final state is then reached. That is, In the genesis block The field points to The final block hash, not At height The subsequent block hash. The remaining unselected branch chains ( , These will be marked as part of a historical archive chain, where the data remains complete and searchable.

[0059] Furthermore, the role-based access control mechanism applies at any approval stage. Its stage of evidence storage chain This is implemented during the data writing operation.

[0060] The system is A role-operation permission mapping table is predefined. . It is a two-dimensional matrix or equivalent data structure that clearly defines which role is identified at this stage. What type of operation (Op) can be initiated? For example, Possible stipulation: Nodes with the role of "Planning and Design Unit" are executable. Submit design documents; the node with the role of "Planning Approval Section" is executable. Fill in the preliminary review comments.

[0061] When a participant node in the network Trying to Submit a transaction hour, Two key pieces of information must be attached to the submission request: one is... Digital signature of content Secondly, it can be proven that its role is credentials (Usually a certified digital certificate).

[0062] Upon receiving this request, the consensus node first performs an authorization check before executing regular transaction verification (such as signature verification): the node uses... verify Role Authentic and valid; subsequently, from The type of operation it intends to perform is parsed from the data. Finally, query ,examine Is this combination authorized?

[0063] like If the permission identifier for this combination is "Allowed," the permission verification passes, and the transaction can proceed to the subsequent consensus packaging process; otherwise, the request will be directly rejected. Additionally, role identifiers... This will be recorded in the final packaged block transaction metadata.

[0064] Furthermore, the data synchronization gateway workflow with external systems achieves data interoperability with external administrative approval business systems through a trusted data synchronization gateway.

[0065] When an approval event requiring evidence storage occurs in an external business system (for example, an official document is electronically stamped in the OA system), the data synchronization gateway is triggered. The gateway captures the event through predefined interfaces (such as database log listening and message queue subscription) and obtains the event data EventData and the trusted supporting evidence ExternalProof generated by the external system (such as the digital signature of the event log in the OA system).

[0066] The gateway internally verifies EventData and ExternalProof to ensure the event source is authentic and the data is complete. Once verification is successful, the gateway proceeds to the target approval stage. to a standardized evidence request StdRequest. The structure of StdRequest conforms to the transaction format of the corresponding phase evidence chain . The gateway signs StdRequest using its own private key to generate .

[0067] Subsequently, the gateway broadcasts StdRequest and to the network as a transaction. The consensus nodes of the phase evidence chain verify the validity of (the transaction is from a trusted gateway) and the format compliance of StdRequest, and record it on the chain after verification.

[0068] The reverse synchronization process is as follows: the gateway continuously listens to the phase evidence chain and the global evidence anchoring chain. When it listens to the key state change on the chain that needs to be fed back to the external business system (for example, a new anchoring proof on the global evidence anchoring chain indicates that “planning achievement approval” has taken effect), the gateway analyzes the record on the chain and extracts the key state information ChainStateInfo. Then, the gateway encapsulates ChainStateInfo into a specific data packet ExternalMsg according to the API specification provided by the external business system, and pushes ExternalMsg to the external system through a secure channel to complete state synchronization.

[0069] Further, the execution of the global automatic verification rule is realized by deploying a smart contract VContract on the global evidence anchoring chain, which is configured to listen to newly generated anchoring proof transactions .

[0070] When is recorded by consensus, the verification smart contract VContract is automatically triggered to execute. VContract encodes the following verification logic, at least one of which is selected each time: Verification logic a (state summary consistency verification): VContract reads the phase evidence chain identifier and the state summary declared in . Subsequently, VContract requests the latest block header information of the phase evidence chain network corresponding to the through a cross-chain query interface, and independently calculates the structured summary of the current state (the calculation method is the same as described above). VContract compares and to generate a boolean verification result​ .

[0071] Verification logic b (cross-chain link validity verification): VContract analyzes the declaration of the newly generated stage-based evidence storage chain. When a new blockchain is detected (e.g.) ) claims its The field value is and pointing At that time, VContract queries the global evidence storage anchor chain and finds information about... The latest anchored proof with event type "phase termination" is used to extract its notarized state summary. VContract comparison and To check if they are equal, generate a Boolean check result. .

[0072] Validation logic c (planning parameter conflict early warning validation): VContract read Composite spatiotemporal identifier carried in And from it, the geocode can be parsed or correlated to obtain the geocode. VContract with Based on this, retrieve all other anchored proofs on the global notarization anchor chain to identify those geocoded and... Items within the preset spatial distance threshold.

[0073] For each found neighboring item VContract reads specific planning parameters from the most recent anchoring proofs from both parties (e.g., Representative projects Floor area ratio, Representative projects (Floor area ratio). VContract calculation parameter differences. .like Greater than the system's preset conflict threshold (e.g.) If a conflict is detected, an early warning result will be generated. This includes conflicting project pairs and parameter information.

[0074] Regardless of the validation logic executed, VContract will package the validation logic type, input parameters, output result CheckResult, and execution timestamp to generate a validation trace transaction. The transaction is then submitted to the global notarization anchor chain for notarization, thereby forming an audit log of the system operation.

[0075] Finally, the following points should be noted: First, in the description of this application, it should be noted that, unless otherwise specified and limited, the terms "installation", "connection", and "linkage" should be interpreted broadly, and can be mechanical or electrical connections, or internal connections between two components, or direct connections. "Up", "down", "left", "right", etc. are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may change. Secondly: The accompanying drawings of the embodiments disclosed in this invention only involve the structures involved in the embodiments disclosed in this invention. Other structures can refer to the general design. In the absence of conflict, the same embodiment and different embodiments of this invention can be combined with each other. In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A blockchain-based urban planning approval and evidence storage system, characterized in that, The system, comprising multiple interconnected consensus nodes, is configured to execute: S1. In response to the establishment of urban planning approval projects, the entire life cycle of the project is analyzed into a sequence of approval stages with a preset logical order according to the preset project type rule template; S2. For each approval stage in the sequence, dynamically create an independent stage evidence storage chain. Each stage evidence storage chain is only used to sequentially encapsulate all approval events and related data generated in its corresponding stage. S3. Link the first block of the stage evidence storage chain corresponding to the next approval stage by embedding the consensus value of the final state of the stage evidence storage chain corresponding to the previous approval stage, so that all stage evidence storage chains are linked together in the order of approval logic to form an approval main chain that represents the complete life trajectory of the project. S4. Maintain a global evidence anchor chain to respond to preset state transition events of each stage evidence chain, capture its chain state snapshot and calculate the structured digest of the snapshot, package the digest with the stage identifier, project identifier and timestamp into an anchor proof, and record it in the global evidence anchor chain after consensus, thus constituting global notarization of the key states of the stage evidence chain.

2. The blockchain-based urban planning approval and evidence storage system according to claim 1, characterized in that, The process of dynamically creating the evidence storage chain specifically includes: S21. When the system determines that all preset state transition conditions of the current active approval stage are met, a stage transition is triggered. S22. Generate a new stage evidence storage chain based on the configuration parameters predefined for the next stage in the rule template. The configuration parameters include the chain data structure specification and event record format standard. S23. In the genesis block of the new stage of the evidence storage chain, a link proof field pointing to a specific final block of the previous stage of the evidence storage chain shall be mandatory as a technical credential for the continuity of approval.

3. The blockchain-based urban planning approval and evidence storage system according to claim 2, characterized in that, The determination of the state transition conditions is achieved by executing preset on-chain verification rules; When verification is required, the relevant consensus nodes verify the state proof data of the current stage of the evidence storage chain according to the rules, and generate a result certificate that can be verified by the consensus network. This certificate is stored as a key approval event record in the current stage evidence storage chain or the global evidence storage anchor chain.

4. The blockchain-based urban planning approval and evidence storage system according to claim 1, characterized in that, The linking mechanism in step S3 employs a binding method that includes time constraints, specifically including: S31. When the evidence storage chain terminates in the previous stage, calculate its termination state consensus value S1 and select a future time point parameter T; S32. Bind S1 and T according to preset rules to generate a binding commitment value C, and write C into the global evidence storage anchor chain in advance; S33. When the conditions indicated by the time parameter T are met, the verification information of S1 and T are disclosed in the genesis block when the next stage of the evidence storage chain is created. The system recalculates C and compares it with the commitment value stored on the chain. When the comparison is successful and the constraint conditions are met, the genesis block is accepted by consensus.

5. The blockchain-based urban planning approval and evidence storage system according to claim 1, characterized in that, The calculation process of the structured summary is as follows: for the data blocks contained in the captured chain state snapshot, a hierarchical data relationship structure is constructed according to the system's predetermined structural organization rules, and a summary operation is performed on the root node information of the structure.

6. The blockchain-based urban planning approval and evidence storage system according to claim 1, characterized in that, The system constructs a composite spatiotemporal identifier for each approved project. This identifier is formed by fusing the standardized location code of the core geographical area of ​​the project with the project establishment time code according to specific rules. This identifier is recorded in the genesis block of the evidence storage chain and related anchor proofs during the initial stage of the approval main chain; The system provides a correlation query mechanism based on this identifier, which can quickly retrieve and aggregate anchor certificates of relevant approval projects on the global evidence storage anchor chain according to a given geographical location range or time interval, and then locate its approval main chain data.

7. The blockchain-based urban planning approval and evidence storage system according to claim 1, characterized in that, The system supports non-linear extension processing of the approval trajectory, specifically: When multiple alternative solutions that need to be explored in parallel are generated during a certain approval stage, the system allows multiple parallel exploratory branch chains to be forked based on the consensus block state point of the current stage's evidence storage chain. All exploratory branch chains share the same history, and their fork start blocks point to the same parent state point; The global proof anchor chain independently generates state anchor proofs for each active exploratory branch chain; When a scheme is selected through an approval resolution, the system publishes a convergence resolution proof on the global evidence anchor chain, and formally connects the selected branch chain from its fork point onwards to the approval main chain as the main trunk continuation, while other branch chains are marked as historical archive chains.

8. The blockchain-based urban planning approval and evidence storage system according to claim 2, characterized in that, The system implements a role-based access control mechanism: Predefine role-operation mapping rules for each approval stage, specifying which roles of nodes are authorized to initiate specific types of event recordings on the stage's evidence storage chain; When a node submits an event record to the staged evidence storage chain, it must include its verified role identification information. Before packaging the event record, the consensus node of the staged evidence storage chain verifies whether the role identifier of the submitting node conforms to the corresponding operation permissions specified in the mapping rules, and records the role identifier in the event record.

9. The blockchain-based urban planning approval and evidence storage system according to claim 1, characterized in that, The system connects to external administrative approval business systems through a trusted data synchronization gateway; The gateway is configured to: listen for predefined approval status change signals in external business systems, and collect event data and credible evidence; After verifying the validity of the event data within the gateway, a standard evidence storage request is constructed and on-chain verification information is attached. The request is then submitted to the corresponding stage evidence storage chain for consensus evidence storage. At the same time, the gateway converts the confirmed key state changes on the stage evidence storage chain or the global evidence storage anchor chain into a format that can be recognized by external systems and pushes them synchronously.

10. The blockchain-based urban planning approval and evidence storage system according to claim 1, characterized in that, The global evidence storage anchor chain is equipped with automatic verification rules for performing cross-chain consistency automatic verification. The rule is configured to monitor newly generated anchored proofs and automatically trigger the execution of at least one of the following verification logics: Verify whether the structured digest of the stage-based evidence chain state in the new anchored proof is consistent with the digest value calculated independently from the latest state of the chain; For a stage evidence chain that claims to link to the previous stage, verify whether the proof of linking the preceding chain declared in its genesis block matches the state digest in the latest final state anchor proof of the preceding chain recorded in the global evidence anchor chain. Based on the composite spatiotemporal identifier carried by the anchoring certificate, a comparison of specific planning parameters of other anchored projects within the preset association range is triggered. When a parameter conflict is found to exceed a preset threshold, a conflict warning is generated and recorded on the anchoring chain.

Images