Bitcoin smart contract construction and control block generation method based on multi-path script

Abstract

The application discloses a method for building and generating a control block of a Bitcoin smart contract based on a multi-path script, and particularly relates to the field of smart contracts, and is used for solving the conversion problem of a two-dimensional information to a three-dimensional concrete interactive reading interface. The method is characterized in that: the two-dimensional material is converted into a structure with coordinates and edges through the cooperation of semantic fragmentation and three-dimensional projection; the evidence anchor points, clauses and states are formed in one-to-one correspondence through path registration along the script tree; the interactive syntax presents the causal link in a single view field; the consistency self-check aligns the results and deposits the source index; the incremental remapping corrects the semantic boundary and path direction accordingly, so that the monitoring interface maintains clear semantic order and stable evidence alignment under complex branches, the abnormal positioning is more intuitive, the review has traceability and version management, and the three-dimensional concrete reading is thus landed as a repeatable execution judgment mechanism.

Description

Technical Field

[0001] This invention relates to the field of smart contracts, and more specifically, to a method for constructing Bitcoin smart contracts and generating control blocks based on multi-path scripts. Background Technology

[0002] Contract monitoring revolves around clause triggering, state transitions, and external evidence extraction. Common interfaces employ a flat design, dispersing information sources across flowcharts, checklists, and log panels. While multi-branch scripts generate structured evidence such as path proofs and control blocks during on-chain execution, these structures are largely confined to tool outputs and text records, making it difficult to present them in a unified view. Inspections and audit reviews often require switching repeatedly between clause descriptions, state records, script tree structures, and path evidence, lacking a common approach to stably transform flat information into a three-dimensional, interactive reading interface. The cost of understanding increases proportionally with contract complexity, and alarm interpretations and evidence alignment lack a unified interactive anchor.

[0003] However, a two-dimensional view struggles to align the causal relationships between clause levels, state transitions, and external evidence in a three-dimensional way. It lacks semantic anchors and spatial mapping rules for script trees, making it impossible to achieve bidirectional tracking of path evidence and control blocks within a single interface. This results in path-level anomaly localization relying on manual comparison, difficulty in revealing cross-branch dependencies, and time-consuming and misleading evidence chain verification. To align with the real-world workflow of contract monitoring, there is an urgent need to develop a design methodology for three-dimensional transformation of two-dimensional information and concrete interactive reading. This methodology should establish a one-to-one mapping and linked highlighting of clauses, states, and evidence within the same spatial coordinate system, supporting rapid location of trigger paths and corresponding evidence from any clause or state, and using reusable interactive syntax to support continuous monitoring and review tasks.

[0004] To address the aforementioned problems, a technical solution is provided. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a method for constructing Bitcoin smart contracts and generating control blocks based on multi-path scripts. Through the synergy of semantic fragmentation and 3D projection, planar materials are transformed into structures with coordinates and edges. Path registration along the script tree enables a one-to-one correspondence between evidence anchors, terms, and states. Interactive syntax presents causal links in a single viewpoint. Consistency self-checks align results and deposit source indexes. Incremental remapping corrects semantic boundaries and path directions accordingly, enabling the monitoring interface to maintain clear semantic order and stable evidence alignment under complex branches. Anomaly location is more intuitive, and the review has traceability and version management. 3D concrete reading is thus implemented as a repeatable judgment mechanism to solve the problems mentioned in the background art.

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

[0007] S1: Receive planar information and build an object index table and source index according to clause fragments, status fragments, and evidence fragments to generate a traceable semantic set;

[0008] S2: Read the object index table, map clause fragments to clause nodes, state fragments to state nodes, and evidence fragments to evidence anchors in the three-dimensional semantic coordinate system, and generate connecting edges according to the reference relationship and trigger relationship to form a three-dimensional semantic skeleton.

[0009] S3: Register evidence anchor points in the order from leaf to root along the script tree, establish a one-to-one mapping with the unique clause node and the unique state node, and mark the path direction and the entrance and exit to form a three-dimensional reading view;

[0010] S4: Enable concrete interactive syntax in the 3D reading view, trigger bidirectional tracking and linked highlighting of corresponding evidence anchor points and path directions from any clause node or status node, and generate omission list and conflict list according to consistency self-check rules and write them into the verification record.

[0011] S5: Generate a remapping task based on the verification record and inspection operation log, perform incremental remapping on the semantic segment boundary and path registration results, synchronously update the object index table, the 3D semantic skeleton and the 3D reading view, and complete the version archiving.

[0012] In a preferred embodiment, step S1 includes the following:

[0013] It receives planar information from Bitcoin smart contracts, parses and extracts clause fragments, state fragments, and evidence fragments, generates unique identifiers based on fragment content and metadata using a hash function, constructs an object index table to record the identifiers, content, and metadata of clause fragments, state fragments, and evidence fragments, generates a source index to record the original source and reference relationships of each fragment, and integrates the object index table and the source index into a traceable semantic set.

[0014] In a preferred embodiment, step S2 includes the following:

[0015] The object index table is read, and clause fragments are mapped to clause nodes, status fragments to status nodes, and evidence fragments to evidence anchors in a three-dimensional semantic coordinate system. The coordinates of clause nodes are determined according to clause level, definition time, and citation strength; the coordinates of status nodes are determined according to the level of associated clauses, timestamp, and citation strength; and the coordinates of evidence anchors are determined according to the level of associated clauses, generation time, and citation strength. Edges are generated based on the citation relationships in the source index and the trigger relationships in the clause and status index sub-tables, connecting clause nodes with evidence anchors, status nodes with evidence anchors, and clause nodes with status nodes. The set of clause nodes, status nodes, evidence anchors, and edges is integrated into a three-dimensional semantic skeleton.

[0016] In a preferred embodiment, step S3 includes the following:

[0017] The system reads the 3D semantic skeleton, constructs a script tree structure based on the edge set and node metadata, uses the root node as the contract entry point and the leaf nodes as the execution endpoint, registers evidence anchors in the order from leaf to root, matches unique clause nodes and unique state nodes according to the reference relationships in the edge set, and establishes a one-to-one mapping; verifies the uniqueness of the mapping, marks the path direction, entry point and exit point along the script tree, records the sequence direction from the entry point to the exit point by traversing the edge set, and integrates the registered evidence anchors, mapping relationships and path direction annotations into the 3D semantic skeleton to form a 3D reading view.

[0018] In a preferred embodiment, step S4 includes the following:

[0019] In the 3D reading view, enable concrete interactive syntax, trigger bidirectional tracking and linked highlighting of corresponding evidence anchor points and path directions from any clause node or status node, start consistency self-check rules to calculate anchor coupling strength and enclosure tightness, form positive example triplets and control triplets, call mutual verification discriminator to output mutual verification credibility coefficient and discrete judgment label with anchor coupling strength and enclosure tightness as features.

[0020] In a preferred embodiment, step S4 further includes the following:

[0021] When a document is deemed credible, the evidence anchor point and path direction are highlighted, and the mutual verification credibility coefficient and source index are written into the verification record. When a document is deemed questionable, it is registered as a remapping candidate and the relevant clause nodes, status nodes, evidence anchor points and path segments are marked. An omission list is generated to record missing mappings or markings, and a conflict list is generated to record multiple matches or inconsistent paths.

[0022] In a preferred embodiment, step S5 includes the following:

[0023] Read the verification records and inspection operation logs, generate a remapping task list specifying semantic fragment boundary correction targets and path registration adjustment targets, sort the task priorities according to the mutual verification credibility coefficient, perform incremental remapping to correct semantic fragment boundaries and path registration results for each remapping task, and synchronously update the fragment identifiers, content and metadata in the object index table, node coordinates, edges and evidence anchor points in the 3D semantic skeleton, one-to-one mapping relationships, path direction annotations and highlighting mechanisms in the 3D reading view, ensure the atomicity of the update through the transaction mechanism, and archive the updated object index table, 3D semantic skeleton and 3D reading view as a new version, recording the version number, update timestamp and change log.

[0024] In a preferred embodiment, the anchor coupling strength acquisition logic is as follows: traverse the hash path sequentially from leaf to root, establish the binding relationship between evidence fragments and clause anchor points, and mark the hierarchical position and continuity; merge adjacent binding points within the same layer to form intra-layer binding clusters, and record the number of anchor points and continuous length of each cluster; track the continuation of anchor points of the same clause between layers to form cross-layer continuation segments, and mark the consistency of entry and exit; retain dense intra-layer and cross-layer continuation binding segments, calculate the ratio obtained by dividing their cumulative length by the path depth, and multiply it by the entry and exit consistency value, where the entry and exit consistency value is one if the entry and exit belong to the same clause range, otherwise it is zero.

[0025] In a preferred embodiment, the enclosure tightness acquisition logic is as follows: a forward fence is generated by a state window sequence triggered by the clause anchor point, and the adjacency relationship is merged to cover the path direction; a reverse fence is generated by sorting out the state fragments from the exit and recording the boundary landing point; the ratio obtained by dividing the area of ​​the overlapping area of ​​the forward fence and the reverse fence by the total area of ​​the reachable path is calculated and multiplied by the boundary landing point matching value, where the matching value is one if the boundary matches the key node, otherwise it is zero.

[0026] The technical effects and advantages of the Bitcoin smart contract construction and control block generation method based on multi-path scripts of this invention are as follows:

[0027] This invention transforms planar materials into structures with coordinates and connections through the synergy of semantic fragmentation and 3D projection. Path registration along the script tree ensures a one-to-one correspondence between evidence anchors, clauses, and states. Interactive syntax presents causal links within a single viewpoint, and consistency self-checks align results and accumulates source indexes. Incremental remapping corrects semantic boundaries and path directions, enabling the monitoring interface to maintain clear semantic order and stable evidence alignment even under complex branches. Anomaly location is more intuitive, and review has traceability and version management. Reading, presentation, verification, and correction form an integrated process, thus transforming 3D concrete reading into a repeatable judgment mechanism. Attached Figure Description

[0028] Figure 1 This is a flowchart illustrating the Bitcoin smart contract construction and control block generation method based on multi-path scripts according to the present invention. Detailed Implementation

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

[0030] Example 1: Figure 1This invention presents a method for constructing Bitcoin smart contracts and generating control blocks based on multi-path scripts, comprising:

[0031] S1: Receive planar information and build an object index table and source index according to clause fragments, status fragments, and evidence fragments, and generate a traceable semantic set.

[0032] S2: Read the object index table, map clause fragments to clause nodes, state fragments to state nodes, and evidence fragments to evidence anchors in the three-dimensional semantic coordinate system, and generate edges according to the reference relationship and trigger relationship to form a three-dimensional semantic skeleton.

[0033] S3: Register evidence anchor points in the order from leaf to root along the script tree, establish a one-to-one mapping with the unique clause node and the unique state node, and mark the path direction and the entrance and exit to form a three-dimensional reading view.

[0034] S4: Enable concrete interactive syntax in the 3D reading view, trigger bidirectional tracking and linked highlighting of corresponding evidence anchor points and path directions from any clause node or status node, and generate omission list and conflict list according to consistency self-check rules and write them into the verification record.

[0035] S5: Generate a remapping task based on the verification record and inspection operation log, perform incremental remapping on the semantic segment boundary and path registration results, synchronously update the object index table, the 3D semantic skeleton and the 3D reading view, and complete the version archiving.

[0036] Monitoring and auditing Bitcoin smart contracts involves complex interactions of clause triggering, state transitions, and external evidence. Traditional flat interfaces present clause descriptions, state records, script tree structures, and path evidence in a fragmented manner, leading to information disjointedness. Users must repeatedly switch between multiple information sources during inspections or audit reviews, and the understanding cost increases significantly with contract complexity. Flat views fail to intuitively demonstrate the causal relationships between clause hierarchy, state transitions, and evidence, lack unified semantic anchors and spatial mapping rules, and result in inefficient bidirectional tracking of path evidence and control blocks. Anomaly location relies on manual comparison, cross-branch dependencies are difficult to reveal, and evidence chain verification is time-consuming and prone to misunderstanding. This invention proposes a method for constructing Bitcoin smart contracts and generating control blocks based on multi-path scripts. Through semantic fragmentation, 3D projection, and concrete interactive syntax, flat information is transformed into a 3D concrete interactive reading interface, supporting unified mapping and linked presentation of clauses, states, and evidence. Step S1, as the starting point of the process, is responsible for receiving flat information and performing structured processing to generate a traceable semantic set, providing structured data for the subsequent construction of a 3D semantic skeleton.

[0037] The goal of step S1 is to extract clause fragments, state fragments, and evidence fragments from the planar information input of the Bitcoin smart contract, generate an object index table and a source index, and integrate them into a traceable semantic set to provide structured data for subsequent three-dimensional semantic coordinate system mapping. The specific processing logic is as follows:

[0038] 1-1. Input Reception and Formatting:

[0039] The input data includes contract terms descriptions, state transition records, external evidence data, and script execution logs, typically provided in text, JSON, or log file formats, and may contain unstructured or semi-structured data. First, the input data is parsed to extract triggering conditions and rules from the terms descriptions, timestamps and status identifiers from the state transition records, hash values ​​or reference addresses from the external evidence, and path identifiers from the script execution logs. To ensure data consistency, a unified cleaning rule is used to remove duplicate fields, standardize the timestamp format to Coordinated Universal Time (UTC), and segment unstructured text into the smallest semantic units, such as a single term, a single state transition, or a single evidence record. The cleaned data is stored in three initial sets: a term fragment set, a state fragment set, and an evidence fragment set, each containing all term fragments, state fragments, and evidence fragments, providing a clearly categorized data foundation for index construction.

[0040] 1-2. Construction of the object index table:

[0041] The object index table assigns a unique identifier to each clause fragment, state fragment, and evidence fragment, recording its semantic content and metadata for easy referencing and mapping in subsequent steps. A unique identifier is generated for each fragment, calculated using a hash function based on the fragment content and metadata, ensuring the uniqueness and verifiability of the identifier. The object index table consists of three parts: a clause index sub-table, a state index sub-table, and an evidence index sub-table. The clause index sub-table records the identifier, content (such as triggering conditions), and metadata (such as clause level, reference script) of each clause fragment; the state index sub-table records the identifier, content (such as state value), and metadata (such as timestamp, associated transaction identifier) ​​of each state fragment; the evidence index sub-table records the identifier, content (such as hash value), and metadata (such as evidence source, on-chain address) of each evidence fragment. The object index table is stored in key-value pair format, where the key is the fragment identifier and the value is a structured record of content and metadata, supporting fast retrieval.

[0042] 1-3. Generation of the source index:

[0043] The source index records the original data source and reference relationships for each fragment, facilitating subsequent traceability and consistency verification. Source information is extracted for each fragment: clause fragments originate from the contract description file, state fragments from the state transition log, and evidence fragments from external evidence or script execution logs. The source index comprises three parts: a clause source sub-index, a state source sub-index, and an evidence source sub-index. The clause source sub-index records the source file path and pointer to the referenced script for the clause fragment; the state source sub-index records the log file path and references to related transactions for the state fragment; and the evidence source sub-index records the external data source and on-chain reference address for the evidence fragment. The source index is implemented through a database table or key-value store, ensuring that the source of each fragment is traceable and the reference relationships are verifiable.

[0044] 1-4. Integration of semantic sets:

[0045] The object index table and source index are integrated into a traceable semantic set, containing the semantic content, metadata, source, and reference relationships of all fragments. An integrity check is performed on the traceable semantic set to ensure that each fragment has a corresponding identifier, content, metadata, and source record. Missing or conflicting records are marked as exceptions and written to the initial verification log. The traceable semantic set is stored in a structured format, such as JSON or a database table, facilitating subsequent steps to read and map it to a three-dimensional semantic coordinate system. The integration process ensures data integrity and consistency, providing a unified data interface.

[0046] Step S1 parses and cleans the planar information of the Bitcoin smart contract, generating a set of clause fragments, a set of state fragments, and a set of evidence fragments. It then constructs an object index table and a source index, integrating them into a traceable semantic set. This traceable semantic set is stored in a structured format, containing unique identifiers, semantic content, metadata, and source information, supporting subsequent 3D semantic coordinate system mapping and path registration. The processing generates unique identifiers using hash functions and employs standardized metadata formats and integrity checks to ensure data consistency and traceability, providing structured data support for the 3D interactive reading interface in Bitcoin smart contract monitoring.

[0047] Step S1 has completed the parsing and structuring of planar information, generating an object index table and source index containing clause fragments, state fragments, and evidence fragments, which are then integrated into a traceable semantic set. Step S2 needs to construct a semantic skeleton in a three-dimensional semantic coordinate system based on the traceable semantic set, mapping fragments to nodes and generating edges to provide structured support for subsequent path registration and interactive view generation.

[0048] The goal of step S2 is to read the object index table generated in step S1, map clause fragments to clause nodes, state fragments to state nodes, and evidence fragments to evidence anchors in a three-dimensional semantic coordinate system, and generate edges based on reference and trigger relationships to form a three-dimensional semantic skeleton, providing structured support for path registration in the subsequent step S3. The specific technical logic is as follows:

[0049] 2-1. Read the object index table:

[0050] An object index table is extracted from the traceable semantic set generated in step S1, comprising a clause index sub-table, a status index sub-table, and an evidence index sub-table. The clause index sub-table records the identifier, content (such as triggering conditions), and metadata (such as clause level and reference script) of clause fragments; the status index sub-table records the identifier, content (such as status value), and metadata (such as timestamp and associated transaction identifier) ​​of status fragments; and the evidence index sub-table records the identifier, content (such as hash value), and metadata (such as evidence source and on-chain address) of evidence fragments. The key-value structure of the object index table allows for the retrieval of the identifier and content of each fragment, ensuring efficient and consistent data access.

[0051] 2-2. Construction of a three-dimensional semantic coordinate system:

[0052] A three-dimensional semantic coordinate system is constructed to map clause fragments, state fragments, and evidence fragments into spatial nodes. The coordinate system defines three dimensions: the first dimension represents the clause hierarchy, reflecting the hierarchical relationship of clause fragments within the contract structure, determined by metadata in the clause index sub-table; the second dimension represents the time series, reflecting the timestamps or triggering order of state and evidence fragments, determined by timestamps or triggering order in the metadata; and the third dimension represents the evidence relevance, reflecting the strength of the reference between the evidence fragment and the clause or state, calculated through the number and depth of reference relationships. The coordinate system unifies the value range of each dimension through normalization processing, ensuring that mapping accuracy is not affected by scale differences.

[0053] 2-3. Mapping fragments to nodes:

[0054] Fragments in the object index table are mapped to nodes in a three-dimensional semantic coordinate system. Clause fragments are mapped to clause nodes, with their position in the three-dimensional coordinate system determined by their hierarchy, definition time, and citation strength to evidence. The hierarchy is obtained from the metadata of the clause index sub-table, the definition time is obtained through a timestamp, and the citation strength is calculated as the ratio of the number of citations to the maximum number of citations. Status fragments are mapped to status nodes, with their coordinate position determined by the hierarchy of associated clauses, timestamp, and citation strength to evidence. The hierarchy of associated clauses is obtained from the metadata of the status index sub-table, the timestamp is used directly, and the citation strength is calculated as the ratio of the number of citations to the maximum number of citations. Evidence fragments are mapped to evidence anchors, with their coordinate position determined by the hierarchy of associated clauses, generation time, and citation strength to clauses or states. The hierarchy of associated clauses is obtained from the metadata of the evidence index sub-table, the generation time is obtained through a timestamp, and the citation strength is calculated as the ratio of the number of citations to the maximum number of citations. The mapping process ensures that the node positions reflect semantic relationships.

[0055] 2-4. Edge generation:

[0056] Based on the reference and trigger relationships in the object index table and source index, edges are generated for the three-dimensional semantic skeleton. Reference relationship edges connect clause nodes and evidence anchors, and state nodes and evidence anchors, based on the reference pointers in the source index, representing data source or verification relationships. Trigger relationship edges connect clause nodes and state nodes, based on the trigger conditions and state transition records in the clause index sub-table and state index sub-table, representing trigger logic. Edge records are node pairs and their types (reference or trigger), forming an edge set that stores all edge information, ensuring the structural integrity of the semantic skeleton.

[0057] 2-5. Integration and storage of the three-dimensional semantic skeleton:

[0058] The clause nodes, status nodes, evidence anchors, and edge sets are integrated into a 3D semantic skeleton, containing the coordinate information and edge relationships of all nodes. The integrity of the 3D semantic skeleton is checked to ensure that each node is associated with at least one edge; missing or conflicting edges are recorded as anomalies and written to the skeleton verification log. The 3D semantic skeleton is stored in a graph structure, such as JSON or a graph database, for step S3 to read and perform path registration.

[0059] Step S2 reads the object index table generated in step S1 and maps the clause fragments, state fragments, and evidence fragments to clause nodes, state nodes, and evidence anchors respectively in the three-dimensional semantic coordinate system. It then generates edges based on reference and trigger relationships, integrating them into a three-dimensional semantic skeleton. The three-dimensional semantic skeleton is stored in a graph structure, containing node coordinates and edge information. Integrity verification ensures consistency between nodes and edges, providing structured support for path registration and a three-dimensional, interactive reading interface in Bitcoin smart contract monitoring.

[0060] Step S2 has constructed a three-dimensional semantic coordinate system based on the object index table, mapping fragments to clause nodes, status nodes, and evidence anchors, and generating edges to form a three-dimensional semantic skeleton. Step S3 requires path registration along the tree-to-root order of the script, establishing a one-to-one mapping between evidence anchors and clause nodes and status nodes, and marking the path direction to provide a three-dimensional reading view for subsequent interactive syntax activation.

[0061] The goal of step S3 is to register evidence anchor points sequentially from leaf to root along the script tree, establish a one-to-one mapping with unique clause nodes and unique state nodes, and mark the path direction, entry point, and exit point to form a three-dimensional reading view. This provides visual support for the consistency self-check and interactive syntax in the subsequent step S4. The specific technical logic is as follows:

[0062] 3-1. Reading the 3D semantic skeleton

[0063] The three-dimensional semantic skeleton is extracted from the output generated in step S2, comprising a set of clause nodes, a set of state nodes, a set of evidence anchors, and a set of edges. The set of clause nodes records the coordinates, identifier, and associated metadata of each clause node; the set of state nodes records the coordinates, identifier, and associated metadata of each state node; the set of evidence anchors records the coordinates, identifier, and associated metadata of each evidence anchor; and the set of edges records the reference relationships and trigger relationships between nodes. The nodes and edges are traversed using the graph structure of the three-dimensional semantic skeleton.

[0064] 3-2. Construction of the script tree structure:

[0065] Based on the edge set and node metadata in the 3D semantic skeleton, a script tree structure is constructed. The script tree uses the root node as the contract entry point, branch nodes as path branches, and leaf nodes as execution endpoints. Trigger relationship edges from the edge set connect clause nodes and status nodes to form branches; reference relationship edges associate evidence anchor points to corresponding tree nodes. The script tree structure is defined as a hierarchical graph, where each node inherits coordinates from the 3D semantic coordinate system, ensuring that tree traversal is consistent with spatial location.

[0066] 3-3. Evidence Anchor Point Registration:

[0067] The evidence anchors are registered following the leaf-to-root order in the script. First, starting from the leaf nodes, each evidence anchor is traversed, and based on the reference relationships in the edge set, a unique clause node and a unique state node are matched to establish a one-to-one mapping. The mapping record shows the correspondence between the evidence anchor and the matched clause node and state node. The registration process verifies the uniqueness of the mapping; if multiple matches exist, they are marked as conflicts and written to the registration log.

[0068] 3-4. Path direction marking:

[0069] After registration, the path direction, entry point, and exit point are labeled along the script tree. The entry point is labeled as the initial edge connecting the root node, and the exit point is labeled as the final edge connecting the leaf node. The path direction is recorded by traversing the set of edges, recording the sequential direction from the entry point to the exit point, including branch points and convergence points. The labeled information is attached to the nodes and edges of the 3D semantic skeleton to form an enhanced graph structure, ensuring that the path is traceable.

[0070] 3-5. Generation and storage of 3D reading views:

[0071] The registered evidence anchors, mapping relationships, and path annotations are integrated into a 3D semantic skeleton to form a 3D reading view. The 3D reading view is stored in a visual graph format, containing all nodes, edges, mappings, and annotation information. The view integrity is checked to ensure that each evidence anchor has a unique mapping and path annotation; any anomalies are recorded in the view verification log. The 3D reading view is read by step S4 to enable concrete interactive syntax.

[0072] Step S3 reads the 3D semantic skeleton generated in step S2, constructs a script tree structure, registers evidence anchors sequentially from leaf to root, establishes a unique one-to-one mapping with clause nodes and state nodes, and annotates the path direction, entry point, and exit point to generate a 3D reading view. The 3D reading view is stored in a visual graph format, containing mapping and annotation information. Integrity verification ensures accurate registration, providing visual support for interaction syntax and consistency self-checking in Bitcoin smart contract monitoring.

[0073] Step S3 has registered evidence anchor points in the order from leaf to root of the script, established a one-to-one mapping with clause nodes and status nodes, and marked the path direction to form a three-dimensional reading view. Step S4 needs to enable concrete interactive syntax in the three-dimensional reading view, trigger bidirectional tracking and linked highlighting, and generate omission and conflict lists according to consistency self-check rules to provide verification records for subsequent remapping.

[0074] The goal of step S4 is to enable concrete interactive syntax in the 3D reading view, triggering bidirectional tracking and linked highlighting of corresponding evidence anchor points and path directions from any clause node or status node, and generating omission and conflict lists according to consistency self-check rules, writing them into the verification record to provide a basis for the remapping task in the subsequent step S5. The specific technical logic is as follows:

[0075] 4-1. Reading the 3D reading view:

[0076] Extract the 3D reading view from the output generated in step S3, which includes a set of clause nodes, a set of status nodes, a set of evidence anchors, a set of edges, one-to-one mapping relationships, and path direction annotations. The set of clause nodes records the coordinates, identifier, and associated metadata of each clause node; the set of status nodes records the coordinates, identifier, and associated metadata of each status node; the set of evidence anchors records the coordinates, identifier, and associated metadata of each evidence anchor; the set of edges records the reference relationships and trigger relationships between nodes; the one-to-one mapping relationship records the correspondence between the evidence anchor and the unique clause node and the unique status node; and the path direction annotation records the sequence direction from the entrance to the exit.

[0077] 4-2. Enable concrete interactive syntax:

[0078] A concrete interactive syntax is defined in the 3D reading view to trigger actions from any clause node or status node. The concrete interactive syntax includes bidirectional tracing rules: tracing forward from the trigger node along the path to the corresponding evidence anchor point, and tracing backward from the evidence anchor point back to the trigger node. A linked highlighting mechanism is based on a one-to-one mapping relationship and a set of connecting edges, highlighting the corresponding evidence anchor point, path direction, and related connecting edges. The interactive syntax is implemented in an event-driven manner; when the user selects a clause node or status node, tracing and highlighting are automatically activated, ensuring the presentation of causal links within a single view.

[0079] 4-3. Consistency self-check rules activated:

[0080] The consistency self-checking rules use the anchor coupling strength and enclosure tightness as core features to ensure accurate quantitative evaluation of the fit between evidence and clause structure, as well as the temporal enclosure of clause triggering and state transition. The former establishes binding relationships layer by layer along the hash path and aggregates and compares the cumulative length and path depth to capture the stable attachment of evidence at the contract clause level, avoiding structural deviations caused by branch complexity in planar information transformation; the latter generates forward and reverse fences to calculate the overlap coverage ratio, verifying the continuous enclosure of the state window on the path, preventing evidence chain breaks or abnormal positioning delays caused by temporal inconsistencies. The parallel application of these two dimensionless parameters not only reflects the inherent logical consistency of the actual execution process, but also provides reliable input for the mutual verification discriminator, supporting the rapid identification and correction of potential conflicts from the three-dimensional reading view, and realizing the semantic order stability and evidence alignment optimization of the monitoring interface.

[0081] After completing the one-to-one mapping and generating the 3D reading view, initiate the consistency self-check rule. First, calculate the two parameters: anchor coupling strength and enclosure tightness.

[0082] Anchorage coupling strength is determined by traversing the hash path sequentially from leaf to root, establishing the binding relationship between evidence fragments and clause anchor points, and recording hierarchical position and continuity. Within the same layer, adjacent binding points are merged to form intra-layer binding clusters, recording the number of anchor points spanned and the continuous length of each cluster. Between layers, the continuation of anchor points of the same clause is tracked to form cross-layer continuation segments, marking entry and exit consistency. Dense intra-layer binding segments that continue across layers are retained, and their cumulative length is calculated as the ratio of path depth to anchorage coupling strength. For example, the calculation formula could be:

[0083]

[0084] in:

[0085] ACS represents the anchorage coupling strength, a dimensionless value; K represents the number of retained restraint segments; L seg Depth represents the cumulative length of each bound segment, calculated by combining the continuous length within the layer and the spanning segments; path Indicates the total path depth, representing the total number of levels from the tree leaves to the root; C ee This indicates consistency between the entry and exit points. A value of 1 indicates that the entry and exit points fall within the same clause range, and 0 indicates otherwise. This is used as a priority criterion.

[0086] Enclosure tightness is determined by generating a forward fence from a state window sequence triggered by clause anchors, merging adjacent relationships to cover the path direction; conversely, a reverse fence is generated by sorting state fragments from the exit, recording the boundary landing point; the overlap ratio of the forward and reverse fences is calculated as the enclosure tightness, and the boundary conformity is confirmed. For example, the calculation formula can be:

[0087]

[0088] in:

[0089] CT indicates the tightness of the fit, a dimensionless value; A overlap The area representing the overlap between the forward and reverse fences is calculated by merging the window sequences; A reachable M represents the total area of ​​reachable paths, calculated from path coverage; bound This indicates the degree of boundary point matching. A value of 1 indicates that the boundary matches the critical node, and 0 indicates otherwise. This is used as a priority judgment condition.

[0090] Subsequently, a positive example triad is formed by the clause anchor point, the corresponding status window, and the corresponding evidence fragment, while a contrasting triad is formed by the disruptive clause or disruptive evidence.

[0091] 4-4. Mutual Verification Assessment and Judgment:

[0092] The mutual verification discriminator is invoked, receiving a positive example triplet and a control triplet. Anchor bundle coupling strength and encirclement tightness are extracted from the pre-calculation as feature pairs. The input is formatted as a feature vector, ensuring consistent pairing between positive and control examples. The anchor bundle coupling strength and encirclement tightness are normalized to map them to a unified interval, and feature integrity is checked; missing features are marked as invalid input and written to the discrimination log. Based on the pre-processed features, the logistic function is used to calculate the sum of the negative anchor bundle coupling strength and encirclement tightness, calculated by dividing by an exponential function. The system determines and forms a probability interval with a continuous value range of zero to one. It then compares the coefficients of the positive example triplet with those of the control triplet. If the coefficient of the positive example triplet is higher than that of the control triplet, the credibility is increased; otherwise, the credibility is decreased. Based on the mutual verification credibility coefficient and a preset threshold, a discrete judgment label is generated. If the coefficient is greater than the threshold, the label is considered credible; otherwise, it is considered questionable. When the coefficient equals the threshold, it is marked as needing to be reviewed. The mutual verification credibility coefficient and the discrete judgment label are integrated into the output result, associated with the source index, and written into the mutual verification log. This log is then directly used by the consistency self-checking rules for highlighting or remapping candidate registrations.

[0093] If the positive example coefficient is higher than the control coefficient, the credibility is increased; otherwise, the credibility is decreased. The specific adjustment process is illustrated below: First, calculate the mutual credibility coefficient of the positive example trio (denoted as MCC). pos The mutual credibility coefficient (MCC) of the control triad and the control triad ctrl Then, if MCC pos Greater than MCC ctrl Then MCC pos Multiply by the enhancement factor of 1.2 to obtain the final mutual verification credibility coefficient; if MCC pos Less than or equal to MCC ctrl Then MCC pos Multiplying by a reduction factor of 0.8 yields the final mutual verification credibility coefficient. This adjustment ensures that the quantification of the difference in comparisons affects the credibility assessment, and then the final mutual verification credibility coefficient is used to generate discrete judgment labels.

[0094] An example of obtaining the threshold is as follows: The threshold is fixed at 0.6 as a preset configuration parameter, determined through empirical verification based on Bitcoin smart contract monitoring scenarios during the invention design phase, ensuring the distinction between the trustworthy and questionable boundaries in the consistency self-check rules. Specifically, the threshold is calibrated using a test dataset simulating multi-path script execution, selecting a value that maximizes accuracy, and remains unchanged during implementation unless updated via the version archive in step S5.

[0095] Based on the anchor coupling strength and enclosure tightness, the system outputs a mutual verification credibility coefficient and discrete judgment labels. When the judgment is credible, the corresponding evidence anchor point and path direction are highlighted in the 3D reading view in conjunction with the trigger node, and the mutual verification credibility coefficient and source index are written into the verification record. When the judgment is questionable, the involved one-to-one mappings are registered as remapping candidates, and the relevant clause nodes, status nodes, evidence anchor points, and path segments are labeled. An omission list is generated to record missing mappings or labels, and a conflict list is generated to record multiple matches or inconsistent paths.

[0096] 4-5. List Writing and Storage:

[0097] The omission list and conflict list are written into the verification record. The verification record includes the mutual verification credibility coefficient, source index, remapping candidates, and annotation information. The verification record is stored in a structured format for step S5 to read and generate the remapping task.

[0098] Step S4 reads the 3D reading view generated in step S3, enables concrete interactive syntax to trigger bidirectional tracking and linked highlighting, calculates the anchor coupling strength and enclosure tightness according to the consistency self-check rules, performs mutual verification evaluation, generates an omission list and a conflict list, and writes them into the verification record. The verification record is stored in a structured format, containing the judgment results and annotation information, providing a basis for remapping correction in Bitcoin smart contract monitoring.

[0099] S4 has enabled concrete interactive syntax in the 3D reading view, triggering bidirectional tracking and linked highlighting, and generating omission and conflict lists based on consistency self-check rules, which are then written to the verification record. Step S5 requires generating a remapping task based on the verification record and inspection operation log, performing incremental remapping, synchronously updating relevant structures, and completing version archiving, providing a closed-loop mechanism for continuous optimization of contract monitoring.

[0100] Step S5 aims to generate a remapping task based on the verification records and inspection operation logs, perform incremental remapping on the semantic segment boundary and path registration results, synchronously update the object index table, the 3D semantic skeleton, and the 3D reading view, and complete version archiving, thus providing support for anomaly correction and version management in Bitcoin smart contract monitoring. The specific technical logic is as follows:

[0101] 5-1. Read the verification records and inspection operation logs:

[0102] The verification records are extracted from the output generated in step S4, including an omission list, a conflict list, mutual verification credibility coefficients, remapping candidates, and annotation information, including relevant clause nodes, status nodes, evidence anchors, and path segments. Simultaneously, the inspection operation log is read, recording user interaction history, abnormal triggering events, and audit operation sequences. The data is parsed using a structured format, and the remapping candidates are associated with the log events to form the input dataset.

[0103] 5-2. Generate remapping task:

[0104] Based on the remapping candidates in the verification records and the abnormal events in the inspection operation logs, a remapping task list is generated. Each task specifies a semantic segment boundary correction target and a path registration adjustment target. Task priorities are sorted according to the mutual verification trust coefficient, with candidates of lower coefficients being processed first. The task list is stored in a key-value structure, where the key is the candidate identifier and the value is the correction type and associated path segment.

[0105] 5-3. Perform incremental remapping:

[0106] For each remapping task, incremental corrections are performed: for semantic fragment boundaries, the boundaries of clause fragments, state fragments, or evidence fragments are adjusted using annotation information, and the consistency of the original data is verified based on the source index; for path registration, the one-to-one mapping between evidence anchor points and clause nodes and state nodes is re-registered along the annotated path segments, and the reference relationships in the connection set are updated. The incremental approach only modifies the affected parts, avoiding full reconstruction and ensuring efficiency.

[0107] 5-4. Synchronous update structure:

[0108] After remapping, the object index table, 3D semantic skeleton, and 3D reading view are updated synchronously: the object index table refreshes the identifiers, content, and metadata of the affected fragments; the 3D semantic skeleton adjusts node coordinates, edges, and evidence anchor point positions; and the 3D reading view updates the one-to-one mapping relationships, path direction annotations, and highlighting mechanisms. The update process ensures atomicity through a transaction mechanism to prevent inconsistencies in intermediate states.

[0109] Version 5-5:

[0110] The updated object index table, 3D semantic skeleton, and 3D reading view are archived as new versions, recording the version number, update timestamp, and change log, including remapping task details. Archiving is implemented using a database or file system, supporting rollback to the previous version to ensure traceability.

[0111] Step S5 generates a remapping task by reading the verification record and inspection operation log generated in step S4. It then performs incremental remapping to correct semantic fragment boundaries and path registration, synchronously updates the object index table, the 3D semantic skeleton, and the 3D reading view, and completes version archiving. The version archive records change details, ensuring continuous optimization of the semantic order and evidence alignment in Bitcoin smart contract monitoring.

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

[0113] It should be noted that the system of the present invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting a variety of hardware environments and usage requirements.

[0114] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

[0115] It should be noted that, in this document, the use of relational terms such as "first" and "second" is merely to distinguish one entity or operation from another, and does not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0116] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for constructing and controlling blocks of a Bitcoin smart contract based on a multi-path script, characterized in that, The method comprises the steps of: S1: receiving planar information and establishing object index table and source index according to clause fragments, state fragments and evidence fragments, and generating traceable semantic set; S2: reading the object index table, mapping the clause fragments into clause nodes, the state fragments into state nodes, and the evidence fragments into evidence anchor points in a three-dimensional semantic coordinate system, and generating edges according to reference relationships and trigger relationships to form a three-dimensional semantic skeleton; wherein the coordinates of the clause nodes are determined according to clause levels, definition times and reference strengths, the coordinates of the state nodes are determined according to associated clause levels, timestamps and reference strengths, and the coordinates of the evidence anchor points are determined according to associated clause levels, generation times and reference strengths; the edges are generated according to the reference relationships in the source index and the trigger relationships in the clause and state index sub-tables, and the clause nodes and the evidence anchor points, the state nodes and the evidence anchor points, and the clause nodes and the state nodes are connected; S3: registering the evidence anchor points in the order of leaf to root along the script tree, matching the unique clause nodes and the unique state nodes according to the reference relationships in the edge set to establish one-to-one mapping, verifying the mapping uniqueness, and marking the path direction, the entrance and the exit to form a three-dimensional reading view; S4: enabling the concrete interaction grammar in the three-dimensional reading view, triggering bidirectional tracking and linkage highlighting of the corresponding evidence anchor points and path direction from any clause node or state node, and generating a missing list and a conflict list according to the consistency self-checking rules and writing them into a verification record; S5: generating a remapping task according to the verification record and the inspection operation log, performing incremental remapping on the semantic fragment boundaries and the path registration results, synchronously updating the object index table, the three-dimensional semantic skeleton and the three-dimensional reading view, and completing version archiving.

2. The multi-path script based Bitcoin smart contract construction and control block generation method of claim 1, wherein, Step S1 includes the following contents: The planar information of the Bitcoin smart contract is received, and clause fragments, state fragments and evidence fragments are parsed and extracted. A unique identifier is generated based on the fragment content and metadata through a hash function. The object index table records the identifiers, contents and metadata of the clause fragments, state fragments and evidence fragments. The source index records the original sources and reference relationships of each fragment. The object index table and the source index are integrated into a traceable semantic set.

3. The multi-path script based Bitcoin smart contract construction and control block generation method of claim 1, wherein, Step S3 includes the following contents: The three-dimensional semantic skeleton is read, the script tree structure is constructed based on the edge set and node metadata, the root node is taken as the contract entrance and the leaf node is taken as the execution end point, the evidence anchor points are registered in the order of leaf to root along the script tree, the unique clause nodes and the unique state nodes are matched according to the reference relationships in the edge set, and one-to-one mapping is established; the mapping uniqueness is verified, the path direction, the entrance and the exit are marked along the script tree, the sequence direction from the entrance to the exit is recorded by traversing the edge set, the registered evidence anchor points, the mapping relationship and the path direction marking are integrated into the three-dimensional semantic skeleton, and a three-dimensional reading view is formed.

4. The multi-path script based Bitcoin smart contract construction and control block generation method of claim 3, wherein, Step S4 includes the following contents: Enable the concrete interaction syntax in the three-dimensional reading view, trigger the bidirectional tracking and linkage highlight corresponding evidence anchor points and path direction from any clause node or state node, start the consistency self-check rule to calculate the anchor bundle coupling strength and the surrounding tightness, form the positive example triad and the control triad, call the mutual evidence discriminator to output the mutual evidence confidence coefficient and the discrete judgment label with the anchor bundle coupling strength and the surrounding tightness as the features.

5. The multi-path script based Bitcoin smart contract construction and control block generation method of claim 4, wherein, Step S4 further includes the following contents: When judged as reliable, the evidence anchor points and path direction are highlighted in linkage, and the mutual evidence confidence coefficient and the source index are written into the verification record. When judged as suspicious, the one-to-one mapping is registered as a remapping candidate and the relevant clause node, state node, evidence anchor point and path section are marked. The missing mapping or the missing mark is generated. The conflict list record is generated or the multiple matching or inconsistent path.

6. The multi-path script based Bitcoin smart contract construction and control block generation method of claim 5, wherein, Step S5 includes the following contents: Read the verification record and the inspection operation log, generate the remapping task list, specify the semantic segment boundary correction target and the path registration adjustment target, sort the task priority according to the mutual evidence confidence coefficient, execute the incremental remapping to correct the semantic segment boundary and the path registration result for each remapping task, synchronize the update of the segment identifier, content and metadata in the object index table, the node coordinate, edge and evidence anchor point position in the three-dimensional semantic skeleton, the one-to-one mapping relationship, path direction mark and highlight mechanism in the three-dimensional reading view, ensure the atomicity of the update through the transaction mechanism, archive the updated object index table, three-dimensional semantic skeleton and three-dimensional reading view as a new version, record the version number, update timestamp and change log.

7. The multi-path script-based Bitcoin smart contract construction and control block generation method of claim 4, characterized in that: Anchor bundle coupling strength acquisition logic: traverse the hash path in leaf-to-root order, establish the binding relationship between evidence segments and clause anchor points, and mark the hierarchical position and continuity; merge adjacent binding points within the same layer to form intra-layer binding clusters, and record the number of anchor points and the continuous length of each cluster; track the continuation of the same clause anchor point between layers to form a cross-layer continuation segment, and mark the entry and exit consistency; retain the binding segments that are dense within the layer and continue across layers, calculate the proportion obtained by dividing the cumulative length of the binding segments by the path depth, and multiply it by the entry and exit consistency value, where the entry and exit consistency value is one if the entry and exit belong to the same clause range, otherwise it is zero.

8. The multi-path script-based Bitcoin smart contract construction and control block generation method of claim 4, characterized in that: Surrounding tightness acquisition logic: generate a forward fence with the state window sequence triggered by the clause anchor point, merge the adjacency relationship to cover the path direction; generate a reverse fence by reverse combing the state segments from the exit, and record the boundary landing point; calculate the proportion obtained by dividing the overlapping area of the forward fence and the reverse fence by the total area of the reachable path, and multiply it by the boundary landing point fit value, where the fit value is one if the boundary and the key node fit, otherwise it is zero.

Images