A cross-chain method and system between blockchains

Abstract

The present invention relates to the field of cross-chain communication technology, specifically a cross-chain method and system between blockchains, comprising the following steps: obtaining the on-chain position range of a field, generating call boundary information, extracting transaction status and sequence to determine conflicts, arranging a list of field paths, checking the protocol structure to generate exclusion paths, screening recommended field structure sequences, generating a communication identifier and writing it into a configuration table, and forming a path identification number item. In the present invention, by constructing the position range of a field in the on-chain structure, accurate identification of lifecycle boundaries is achieved, field positioning and context association capabilities are enhanced, conflicting paths are determined based on transaction type and status data comparison, field consistency control is improved, structural continuity matching field combinations are screened, target chain field adaptability is enhanced, and a communication path identifier is generated in combination with a structure summary. This improves cross-chain path identification efficiency and configuration accuracy, and achieves stability and verification of inter-chain data collaboration.

Description

Technical Field

[0001] This invention relates to the field of cross-chain communication technology, and in particular to a cross-chain method and system between blockchains. Background Technology

[0002] Cross-chain communication technology encompasses mechanisms for data interaction and information sharing between multiple distributed ledgers or blockchain systems. The core of this technology is achieving interoperability between different blockchain networks, ensuring that multiple independent ledgers can transfer assets, verify information, and coordinate protocols without relying on a centralized institution. Cross-chain communication relies on cryptographic mechanisms to build trusted relay systems or verification mechanisms. Through the design of atomic swap protocols, relay chain schemes, sidechain mechanisms, and hash locking mechanisms, various on-chain systems can achieve data consistency and transaction validity while maintaining independence. This field also includes cross-chain identity verification, transaction order coordination, and consensus protocol mapping. The technical system covers communication structure design, cryptographic verification structures, inter-chain state synchronization mechanisms, transaction identification mechanisms, and cross-chain operation log management.

[0003] One cross-chain method refers to the operational process used to synchronize transaction information between two or more heterogeneous blockchain systems. This method primarily addresses the problem of direct communication during inter-chain data transfer, encompassing technical aspects such as inter-chain transaction identification based on preset verification rules, transmission of cross-chain request information via a relay chain, verification of the target chain state using a hash time-lock mechanism, authentication of inter-chain transaction validity using digital signatures, and data encapsulation and transmission using a unified transaction format. This method typically completes the inter-chain transaction initiation, verification, and response process through a predefined structured communication protocol, ensuring that each cross-chain request has a verifiable transaction source, legitimate recipient confirmation, and a complete execution record.

[0004] In the prior art, there is a problem of weak abstraction ability of on-chain field structures in the process of handling transaction synchronization in cross-chain communication. It is difficult to accurately identify the lifecycle boundary at the field call level, resulting in a lack of information support for context dependence in field conflict judgment, forming path redundancy and configuration misjudgment. Since most inter-chain field identifications rely on transaction format unification or hash lock verification mechanisms, lacking the联动 analysis of the relationship between field structure order and status data, it often causes consistency risks such as data overwrite and field loss in the cross-chain process. Most existing methods focus on transaction initiation and response, ignoring the structural distribution differences formed by field status changes in different chains, and it is difficult to achieve the adaptation and screening of field combinations on the target chain side, reducing the efficiency of cross-chain paths and the stability of transaction execution. For example, in the multi-field cross-verification process, it is impossible to identify the corresponding relationship between conflict field paths and protocol structures, which is extremely likely to cause repeated verification or misjudgment of channel construction, affecting the coherence and accuracy of cross-chain transaction transfer. The above problems limit the ability expansion of existing cross-chain communication mechanisms in complex structure synchronization, multi-field collaboration, and configuration path identification. Summary of the Invention

[0005] The purpose of the present invention is to solve the disadvantages existing in the prior art, and to propose a cross-chain method and system between blockchains.

[0006] To achieve the above purpose, the present invention adopts the following technical solutions: A cross-chain method between blockchains includes the following steps:

[0007] S1: Obtain the block height of field deployment on the current chain, the start and end heights of calls, and the contract name, and combine the call sequence numbers in the contract to determine the position range of the field in the on-chain structure, and generate field call boundary association information;

[0008] S2: Based on the field call boundary association information, extract the field transaction types, status data items, and write sequence numbers in the source chain and the target chain, judge the lifecycle overlap and sequence differences, and organize the conflict field paths into a field path conflict record list;

[0009] S3: According to the field path conflict record list, check whether the associated fields appear together in the configured cross-chain protocol structure. If so, mark the corresponding communication structure and generate a cross-chain protocol exclusion path set;

[0010] S4: Call the cross-chain protocol exclusion path set, extract the available field combinations on the target chain, and screen the field combinations with continuous and consistent distributions in the source chain structure according to the differences in the call sequence numbers and verification identifiers, and generate a recommended cross-chain field structure sequence;

[0011] S5: Call the recommended cross-chain field structure sequence, extract the main field name and sequence number, generate a structure summary and combine it with the field name to form a communication path identifier, write it into the protocol configuration table, and generate an inter-chain path identification number item.

[0012] As a further aspect of the present invention, the field call boundary association information includes deployment block height, earliest call height, call end height, contract name, and call sequence number; the field path conflict record list includes transaction type, binding status data item, write sequence number, lifecycle cross information, and sequence difference information; the cross-chain protocol exclusion path set includes communication structure marker, protocol path exclusion item, and cross-chain structure filtering rules; the recommended cross-chain field structure sequence includes verification identifier boolean value, structure continuity parameter, and distribution pattern characteristics; and the inter-chain path identification number item includes main field name, sequence number list, structure summary, communication path identifier, and protocol configuration table information.

[0013] As a further aspect of the present invention, the specific steps of S1 are as follows:

[0014] S101: Obtain the deployment block height of the contract to which the field belongs, the block height of the first and last calls of the field, and calculate the block offset values ​​of the first and last calls by combining the call sequence number, and generate the block offset range value of the field call.

[0015] S102: Based on the field, call the block offset interval value, filter the data fields within the corresponding block range whose number is not less than the field number, count the number of fields and the difference between their numbers, and generate the field number interval span value;

[0016] S103: Based on the field call block offset interval value and the field number interval span value, extract the field number and block height, calculate the average of the differences between adjacent field numbers and heights, and obtain the field call boundary correlation value.

[0017] As a further aspect of the present invention, the specific steps of S2 are as follows:

[0018] S201: Based on the field call boundary correlation value, extract the transaction type, binding status data item and write order number of the field in the source chain and target chain, mark the field path and number accordingly, and generate the field transaction order label quantity;

[0019] S202: Call the field transaction sequence label, perform path cross-comparison of the write sequence numbers in the source chain and the target chain, extract the field paths with inconsistent write order and their number difference values, and generate a set of field path sequence difference values;

[0020] S203: Based on the set of field path order difference values, identify combinations of lifecycle overlap and order difference that exist simultaneously in the field path, and obtain a list of field path conflict records.

[0021] As a further aspect of the present invention, the specific calculation formula for extracting the field paths with inconsistent writing order and their number differences is as follows:

[0022] ;

[0023] in, The first in the path combination of the representative field The source chain path and the first The order difference weighted offset value of each target chain path. Represents the first in the target chain The writing order number of each field path, For the first in the source chain The sum of the boundary call weights of all fields corresponding to each field path in the target chain. Representing the The source chain field and the first Call weight values ​​between target chain fields Representing the The total number of bound state data items for each field path in the source chain. Represents the first in the source chain The writing order number of each field path, This represents the number of field paths in the target chain.

[0024] As a further aspect of the present invention, the specific steps of S3 are as follows:

[0025] S301: Obtain the list of field path conflict records and the cross-chain protocol structure. Based on the field paths in the conflict records, detect whether the field paths co-occur with the conflicting fields in the cross-chain protocol structure. If they co-occur, mark the corresponding communication field combination position and generate a field co-occurrence communication position information set.

[0026] S302: Call the communication field combination location in the field co-occurrence communication location information set, compare the intersection with the configured field set in the protocol structure, filter the communication structure in which at least two fields exist at the same time in the conflicting fields, calculate the field intersection ratio, and obtain the high co-occurrence field path structure set;

[0027] S303: Based on the field path distribution in the high coexistence field path structure set, extract the field combinations that overlap with the field paths in the conflict record list, determine whether they co-occur repeatedly in all protocol structures, construct an exclusion field path index set, and generate a cross-chain protocol exclusion path set.

[0028] As a further aspect of the present invention, the specific steps of S4 are as follows:

[0029] S401: Call the cross-chain protocol to exclude the field paths in the path set and the target chain path, extract logically continuous field combinations in the target chain, record the field distribution position and calling order, and generate a field sequence difference value by comparing the order difference and displacement direction of the field combinations.

[0030] S402: Based on the field sequence difference value and the field call order number, extract the field including the verification identifier boolean value, compare the position difference of the field in the target chain and the source chain, filter the field combination with the order offset less than the position difference threshold, and generate a boolean field offset matching value.

[0031] S403: Based on the Boolean field offset matching degree value and the source chain structure continuity rule, compare the order and distribution trend of field combinations, filter combinations that meet the requirements of field offset direction and structural hierarchy, calculate the stability of field arrangement, and generate a recommended cross-chain field structure sequence.

[0032] As a further aspect of the present invention, the specific formula for selecting combinations that meet the requirements of field offset direction and structural hierarchy is as follows:

[0033] ;

[0034] Where S represents the stability of the field arrangement. Representing the The offset of the combination of fields, This represents the target offset of the field combination. Representing the The structural complexity of combining multiple fields, Representing the The length of the combination of fields, This represents the source chain structure hierarchy of the field combination. Representing the The target chain structure hierarchy of the combination of fields, Representing the The weighted index of a combination of fields, Represents the total number of field combinations.

[0035] As a further aspect of the present invention, the specific steps of S5 are as follows:

[0036] S501: Obtain the recommended cross-chain field structure sequence, extract the field name and sequence number, select each field from the structure sequence in turn, extract the corresponding name and number, form a corresponding list of main field names and sequence numbers, generate a string of concatenated numbers, and obtain a list of field numbers;

[0037] S502: Based on the field number list, combine the field names and numbers to generate a structural summary of the field names and numbers. Then, concatenate the number and name of each field into a set of data, and summarize all fields to generate a complete structural summary, thus obtaining a structural summary list.

[0038] S503: Based on the structure summary list, combine the structure summary list with the main field name to generate a communication path identifier, and write the generated communication path identifier into the protocol configuration table to obtain the inter-chain path identification number item.

[0039] A cross-chain system between blockchains, comprising:

[0040] The on-chain field information collection module obtains the deployment block height, earliest call height, call end height, and contract name of the field in the blockchain. Combined with the call sequence number of the field in the contract structure, it constructs the position range of the field in the on-chain structure and generates field call boundary association information.

[0041] Based on the field call boundary association information, the field conflict detection module extracts the transaction type, binding status data item and write order number of the fields in the source chain and the target chain, compares the consistency between the life cycle intersection and the write order, determines the field path combination that has conflict, and organizes and generates a list of field path conflict records.

[0042] The cross-chain protocol matching module checks whether related fields appear together in the configured cross-chain protocol structure based on the field path conflict record list. If they do, the corresponding communication structure is marked and a cross-chain protocol exclusion path set is generated.

[0043] The field matching and filtering module calls the cross-chain protocol exclusion path set, extracts the available field combinations in the target chain, judges the position difference and matching degree based on the field calling order number and verification identifier boolean value, filters the field combinations that match the continuity and distribution pattern of the source chain structure, and generates a recommended cross-chain field structure sequence.

[0044] The cross-chain path identification module calls the recommended cross-chain field structure sequence, extracts the main field name and sequence number list, concatenates the numbers and generates a structure summary, combines the structure summary with the field name, writes it into the protocol configuration table, and generates the inter-chain path identification number item.

[0045] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0046] In this invention, by constructing the position range of fields in the on-chain structure, the lifecycle boundary can be accurately identified, enhancing the field positioning and context association capabilities. Conflict paths can be determined based on the comparison of transaction type and state data, improving field consistency control. Field combinations that match structural continuity can be selected, enhancing the adaptability of target chain fields. Communication path identifiers can be generated by combining structural summaries, improving the efficiency and accuracy of cross-chain path identification and configuration, and achieving the stability and verifiability of inter-chain data collaboration. Attached Figure Description

[0047] Figure 1 This is a schematic diagram of the steps of the present invention.

[0048] Figure 2 This is a system module diagram of the present invention. Detailed Implementation

[0049] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0050] In the description of this invention, it should be understood that the terms "length," "width," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, in the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0051] Please see Figure 1 A cross-chain method between blockchains includes the following steps:

[0052] S1: Obtain the deployment block height, earliest call height, call end height, and contract name of the field currently on the chain. Combine this with the field's call sequence number in the contract structure to construct the field's position range in the on-chain structure and generate field call boundary association information.

[0053] S2: Based on the field call boundary association information, extract the transaction type, binding status data item and its write order number of the fields in the source chain and the target chain, determine the situation where the life cycle crosses and the write order is inconsistent, and organize the conflicting field paths into a list of field path conflict records.

[0054] S3: Based on the list of field path conflict records, check whether the related fields appear together in the configured cross-chain protocol structure. If they do, mark the corresponding communication structure and generate a cross-chain protocol exclusion path set.

[0055] S4: Call the cross-chain protocol to exclude the path set, extract the available field combinations in the target chain, perform position difference and matching degree judgment on the field call order number and verification identifier boolean value, filter the field combinations that match the continuity and distribution pattern of the source chain structure, and generate a recommended cross-chain field structure sequence;

[0056] S5: Call the recommended cross-chain field structure sequence, extract the main field name and sequence number list, concatenate the numbers and generate a structure summary, combine the structure summary and field name into a communication path identifier, write it into the protocol configuration table, and generate an inter-chain path identification number item.

[0057] The field call boundary association information includes the deployment block height, earliest call height, call end height, contract name, and call sequence number. The field path conflict record list includes the transaction type, binding status data item, write sequence number, lifecycle cross information, and sequence difference information. The cross-chain protocol exclusion path set includes communication structure markers, protocol path exclusion items, and cross-chain structure filtering rules. The recommended cross-chain field structure sequence includes the verification identifier boolean value, structure continuity parameter, and distribution pattern characteristics. The inter-chain path identification number item includes the main field name, sequence number list, structure summary, communication path identifier, and protocol configuration table information.

[0058] The specific steps of S1 are as follows:

[0059] S101: Obtain the deployment block height of the contract to which the field belongs, the block height of the first and last calls of the field, and calculate the block offset values ​​of the first and last calls by combining the call sequence number, and generate the block offset range value of the field call.

[0060] When obtaining the deployment block height, earliest call height, call end height, and contract name of an on-chain field, the deployment transaction record is first extracted based on the target contract's contract name, and the block number where the deployment occurred is obtained as the field's deployment height. Then, the transaction information where the field first participated in the call is extracted one by one, and the block number where it first appeared in the call log is confirmed as the earliest call height. The subsequent call transactions of the field on the blockchain are traced back to the last transaction block number where it no longer appears, which is used as the field's call end height. This is combined with the field's appearance in the smart contract source code structure. The sequential numbering of fields is used to construct the numbering information of fields in the structure definition. For example, in contract X, field A is deployed in block 12000, the first call is at 12500, and the last call is at 13200. Its sequential number in the contract structure is 5. Then, field A can be associated with the block height sequence 12500 to 13200, indicating that the field is the 5th position in the on-chain contract structure, and its active call range is blocks 12500 to 13200. By performing the same operation on all fields, the correspondence between the field structure sequential number and the deployment and call height is established, and finally, the call height range data is generated.

[0061] S102: Based on the field, call the block offset interval value, filter the data fields whose number is not less than the field number within the corresponding block range, count the number of fields and the difference between their numbers, and generate the field number interval span value;

[0062] Based on the call height range data, the deployment block height, earliest call height, and call end height of a field are extracted to identify the field's call time span. For example, if field B is deployed at block 14000, the earliest call is at 14400, and the call end is at 15000, it can be determined that the field started calling 400 blocks after deployment and continued to call 600 blocks thereafter. During this process, the structural sequence number of the field is mapped to the call time range. Taking number 8 corresponding to the range 14400 to 15000 as an example, this field is the 8th position in the structure, and its call cycle spans 600 blocks. By establishing such a set of correspondences between numbers and ranges for all fields, a call time range table indexed by the sequence number is constructed. At the same time, fields are classified according to the length of the time interval between the start and end of the call. Fields that start calling within 100 blocks after deployment are classified as short-latency fields, and fields whose calls continue for more than 1000 blocks are classified as long-lifecycle fields. After integration, the position range information of the field in the contract is finally generated.

[0063] S103: Based on the field call block offset interval value and the field number interval span value, extract the field number and block height, calculate the average value of the difference between adjacent field numbers and heights, and obtain the field call boundary correlation value.

[0064] Based on the position range information of the fields in the contract, the blockchain node data interface is called to extract the node number information involved in each field during the call. Within the call range of the field, the transaction data associated with the field is queried block by block. The relevant node number is identified by the execution node information in the transaction record, and the participation frequency and corresponding block range of each node are counted. For example, the call range of field C is from block 16000 to 17000. Within this range, the transactions processed by nodes 03, 07 and 11 all contain the call content of field C. Among them, node 03 processed 20 transactions from 16000 to 16200, node 07 processed 15 transactions from 16300 to 16500, and node 11 processed 30 transactions from 16600 to 17000. In this way, the field structure number, call range and corresponding node information are combined into a multi-dimensional mapping table. After repeating this process for all fields, a set of boundary relationships between field numbers and calling nodes is formed, and finally, the field call boundary association information is generated.

[0065] The specific steps of S2 are as follows:

[0066] S201: Based on the field call boundary correlation value, extract the transaction type, binding status data item and write sequence number of the field in the source chain and target chain, mark the field path and number accordingly, and generate the field transaction sequence label quantity;

[0067] Based on the field call boundary correlation value, the call status of each field path is first collected from the source chain and the target chain. The call frequency of each field in the target chain is compared with its total number of calls in the entire chain to measure the concentration of the field in cross-chain calls. For example, if a field is called 3 times in the target chain and its total number of calls is 10, its call boundary correlation is 0.3, indicating that the field has a moderate call dependency in the target chain. Then, the transaction type and binding status data items are extracted for each field path. The transaction type is directly read from the operation type marked in the operation log. For example, if the field is marked as "write" in the on-chain data record, it is marked as T2, and "read" is marked as T1. The binding status is determined by the field... The unique binding identifier is determined in the business binding mapping table. If a binding relationship exists, it is set to 1; otherwise, it is set to 0. The write sequence number is sorted according to the system timestamp of the first time the field is written to the chain. The numbers are numbered sequentially from earliest to latest, and the number values ​​are sequentially increased in the form of natural numbers. For example, if the first write time of field A is earlier than that of field B, then A is numbered 1 and B is numbered 2. Finally, the field path, transaction type, binding status, and write sequence number are combined to form a combined identifier, which constitutes the complete structural information of the field path. For example, if the field " / account / create / user information" has a write transaction type, a binding status of 1, and a sequence number of 5, then this information is encapsulated and recorded according to the structure. Finally, all field path structural information is summarized to generate the field transaction sequence label.

[0068] S202: Call the field transaction order label, perform path cross-comparison of the write order numbers in the source chain and the target chain, extract the field paths with inconsistent write order and their number difference values, and generate a set of field path order difference values.

[0069] The specific formula for calculating the difference in field paths and their numbers due to inconsistent write order is as follows:

[0070] ;

[0071] in, The first in the path combination of the representative field The source chain path and the first The order difference weighted offset value of each target chain path. Represents the first in the target chain The writing order number of each field path, For the first in the source chain The sum of the boundary call weights of all fields corresponding to each field path in the target chain. Representing the The source chain field and the first Call weight values ​​between target chain fields Representing the The total number of bound state data items for each field path in the source chain. Represents the first in the source chain The writing order number of each field path, The number of field paths in the target chain;

[0072] This formula is used to calculate the order difference weighted offset value between the source chain field path and the target chain field path. The formula takes into account the write order number of the target chain field, the call weight between the source and target chain fields, and the number of bound state data items in the source chain field.

[0073] First, define the following parameters:

[0074] The first in the target chain The writing order number of each field path. For example, if the field path " / finance / approval / submit" in the target chain is written to the system in the 4th position, then... .

[0075] : indicates the first in the source chain The sum of call weights between the source chain field " / business / data" and all field paths in the target chain. If the call weights of the source chain field " / business / data" corresponding to " / finance / approval / submit" and " / finance / approval / record" in the target chain are 0.3 and 0.7 respectively, then the sum is 1.0.

[0076] : indicates the first in the source chain The number of bound state data items for each field path. For example, if the " / business / data" field is bound to 5 different states during the business process, then... .

[0077] The first in the source chain The writing order number of each field path. For example, if the source chain field path " / business / data" is written to the system in the second position, then... .

[0078] The total number of field paths in the target chain. For example, if there are 10 field paths in the target chain, then... .

[0079] In practice, these parameters can be obtained through methods such as system log analysis (writing sequence number), API call statistics (call weight), and system configuration files (number of binding status data items).

[0080] The derivation is carried out using specific numerical examples, with the following settings:

[0081] ;

[0082] ,but ;

[0083] ;

[0084] ;

[0085] Substitute into the formula to calculate:

[0086] ;

[0087] The calculation process shows that the source chain and the target chain are the first Hedi The weighted offset of the order difference for each field path is 1.33. This result shows that, after considering the weighting of call frequency and binding state complexity, there is a significant deviation in the data write order between the two field paths, indicating that the target chain path is written earlier than the source chain. Calculating this deviation can help analyze potential synchronization problems in the data stream or optimize the data processing flow.

[0088] The results indicate that there is a significant difference in the order of the two field paths, which may affect the consistency and efficiency of data processing. Further analysis is needed to determine the actual impact of this deviation on the business process and adjust the data management strategy accordingly.

[0089] S203: Based on the set of field path order difference values, identify the combination of lifecycle overlap and order difference in the field path and obtain a list of field path conflict records;

[0090] Based on the set of field path sequence difference values, further analysis is conducted to determine whether the field paths simultaneously satisfy the conditions of lifecycle intersection and sequence number difference. The lifecycle intersection judgment is based on the existence of different transaction type records for the same field path or similar fields in the source chain and the target chain, i.e., one is a write type and the other is a read type. For example, if the path " / report / generate / project information" is marked as write (T2) in the source chain and as read (T1) in the target chain, then the lifecycle is considered to have intersection. Then, combined with its corresponding write sequence number difference value, it is determined whether it exceeds a preset threshold. The threshold is set with reference to 95% of the write time intervals in the business chain. For the range of number changes, if the number difference of 95% of the fields in the business process does not exceed 3 during continuous writing, then the path pairs with a number difference value greater than 3 can be judged as order conflicts. For example, if a field has a number of 3 in the source chain and a number of 8 in the target chain, the difference is 5, which exceeds the judgment threshold. In addition, the field type has a life cycle intersection. Therefore, the path combination is judged to have a conflict. Similarly, the entire set of path difference values ​​is traversed, and field path combinations that meet the above two conditions are selected, sorted and merged, and their path identifier, transaction type distribution, number difference value and life cycle intersection status are recorded. Finally, a list of field path conflict records is formed.

[0091] The specific steps for S3 are as follows:

[0092] S301: Obtain the list of field path conflict records and the cross-chain protocol structure. Based on the field paths in the conflict records, detect whether the field paths co-occur with the conflicting fields in the cross-chain protocol structure. If they co-occur, mark the corresponding communication field combination position and generate a field co-occurrence communication position information set.

[0093] First, field paths need to be extracted from the cross-chain protocol structure. These paths represent the relationships between each data field and other fields in the protocol. For example, in data exchange between blockchains, each block contains multiple fields such as "transaction ID," "sender address," "recipient address," and "amount," and each field may conflict with other fields. Then, based on the field paths in the conflict records, the field paths in the protocol structure need to be compared to see if conflicting fields appear simultaneously in the same location. For example, if a conflict record contains the field path "transaction ID-sender address," and the protocol structure also contains "transaction ID-sender address," then this field path is considered conflicting and marked as a communication field combination location. This location marking helps with subsequent intersection comparisons and conflict detection. Next, a field co-occurrence communication location information set is generated. This set records the combination locations of all conflicting fields and their co-occurrence relationships, allowing subsequent steps to further filter out highly coexisting conflicting field paths based on this information set. For example, if certain field paths appear multiple times in a protocol structure, and these field paths co-occur in multiple protocol structures, then they need to be specially marked and their specific locations recorded in the information set.

[0094] S302: Call the communication field combination location in the field co-occurrence communication location information set, compare the intersection with the configured field set in the protocol structure, filter the communication structure in which at least two fields exist at the same time in the conflicting fields, calculate the field intersection ratio, and obtain the high co-occurrence field path structure set;

[0095] First, it's necessary to extract the locations of communication field combinations from the co-occurrence communication location information set. These locations include those that appear together with conflicting fields. Next, these locations are compared with the set of fields configured in the protocol structure, checking whether these field combinations appear simultaneously in the protocol structure. For example, the protocol might have a field path "Transaction ID - Recipient Address," while the conflict record might have a field path "Transaction ID - Sender Address." If the "Transaction ID" field co-occurs in multiple paths, it indicates an intersection, requiring further analysis. During the comparison, the intersection method is used to ensure that only fields appearing simultaneously in multiple field paths are included in the filtering scope. Then, based on the intersection results, the field intersection ratio is calculated. This ratio represents the degree of coexistence of conflicting fields in the protocol structure. The formula is: Intersection Ratio = Number of Intersecting Fields / Total Number of Fields. For example, if in a protocol structure, the fields "Transaction ID" and "Sender Address" appear simultaneously in 3 different field paths, and the total number of these field paths is 5, then the intersection ratio is 3 / 5 = 0.6. Ultimately, the resulting set of highly co-occurring field path structures contains field paths with a high degree of field co-occurrence, providing a basis for subsequent analysis.

[0096] S303: Based on the field path distribution in the high coexistence field path structure set, extract the field combinations that overlap with the field paths in the conflict record list, determine whether they are repeatedly co-occurring in all protocol structures, construct an exclusion field path index set, and generate a cross-chain protocol exclusion path set;

[0097] First, it's necessary to analyze the distribution of field paths in the high-coexistence field path structure set and extract field combinations that overlap with those in the conflict record list. For example, if the conflict record list contains the field path "Transaction ID - Recipient Address," and the high-coexistence field path structure set also contains the "Transaction ID - Recipient Address" field path, then this field combination needs to be extracted and further analyzed. Next, it's necessary to determine whether these field combinations are repeatedly co-occurring in all protocol structures, i.e., whether they frequently appear in multiple protocols. If a field combination appears multiple times in different protocol structures, it indicates a strong co-occurrence relationship among these protocols. This can be determined by statistically analyzing the frequency of these field combinations in different protocols. For example, if the field path "Transaction ID - Recipient Address" exists in 10 protocol structures, it can be considered a repeatedly co-occurring field combination. Based on this analysis, an exclusion field path index set is constructed, recording these frequently occurring field paths in multiple protocols. This ultimately generates a cross-chain protocol exclusion path set, which contains information on all paths that need to be excluded, allowing for avoidance of these paths in subsequent operations or protocol configurations.

[0098] The specific steps of S4 are as follows:

[0099] S401: Call the cross-chain protocol to exclude field paths in the path set from the target chain path, extract logically continuous field combinations in the target chain, record the field distribution position and calling order, and generate field sequence difference value by comparing the order difference and displacement direction of field combinations.

[0100] First, logically consecutive field combinations in the target chain are obtained. Based on the target chain's design structure, these fields are extracted and their distribution positions and calling order within the target chain are recorded. For example, assuming the target chain's field combination is field A, field B, and field C, and their positions in the chain are 1, 2, and 3 respectively, then the combination order of these three fields in the target chain is 1, 2, 3. Next, a field combination order difference analysis is performed. This process requires calculating the difference in field combination order between the target chain and the source chain, i.e., comparing the order of fields in the target chain with the order of fields in the source chain. Based on the difference in the positions of fields in the source chain and the target chain, the order difference and displacement direction of the field combinations are calculated. If the source chain's field combination is field X, field Y, and field Z, with an order of 1, 3, 2, the field order difference is 1 - 2 = -1 (the order difference between field X and field Y). The order difference between field Z and other fields is -1, thus generating a field sequence difference value, i.e., -1, -1. Finally, this difference value is an important indicator of the field combination difference, used for subsequent filtering and optimization of field combinations. The generated field sequence difference values ​​can help assess the degree of matching of cross-chain protocol paths.

[0101] S402: Based on the field sequence difference value and the field call order number, extract the field including the verification identifier boolean value, compare the position difference of the field in the target chain and the source chain, filter the field combination with the order offset less than the position difference threshold, and generate a boolean field offset matching value.

[0102] First, extract all fields containing Boolean values ​​for verification identifiers from the target chain. Verification identifier fields are typically control flags used for inter-chain communication, and their values ​​are Boolean (true / false). These fields are included in the field combinations of the target and source chains. Next, compare the positional differences of these fields in the target and source chains. Positional differences can be numerically compared by comparing the positions of the fields in the two chains. For example, if fields A and B in the target chain are at positions 2 and 4, respectively, and at positions 3 and 5 in the source chain, the positional difference is 1 and 1. If this difference is less than a set positional difference threshold (e.g., a threshold of 2), it can be determined that the positional matching requirement is met, and field combinations that meet the condition are filtered out. Further, for each field combination, calculate the field combinations whose sequential offset is less than the positional difference threshold, and generate a Boolean field offset matching degree value based on this result. For example, if the threshold is 2 and the sequential offset of the field combination is 1, then the combination passes the filtering, and the Boolean field offset matching degree value is 1. In this way, field combinations that match sequentially between the source and target chains can be accurately filtered out.

[0103] S403: Based on the Boolean field offset matching degree value and the source chain structure continuity rule, compare the order and distribution trend of field combinations, filter combinations that meet the requirements of field offset direction and structural hierarchy, calculate the stability of field arrangement, and generate a recommended cross-chain field structure sequence.

[0104] The specific formula for filtering combinations that meet the requirements of field offset direction and structural hierarchy is as follows:

[0105] ;

[0106] Where S represents the stability of the field arrangement. Representing the The offset of the combination of fields, This represents the target offset of the field combination. Representing the The structural complexity of combining multiple fields, Representing the The length of the combination of fields, This represents the source chain structure hierarchy of the field combination. Representing the The target chain structure hierarchy of the combination of fields, Representing the The weighted index of a combination of fields, The total number of combinations of fields;

[0107] Parameter analysis:

[0108] : No. The offset of a combination of fields represents the offset of that field within the source chain structure. It is obtained by comparing the differences between the source chain fields and the target chain fields at corresponding positions. The offset value is typically obtained through monitoring and calculating the field positions, assuming this value is the actual measured offset, such as the difference recorded at the field position on the chain.

[0109] This field combination represents the target offset, indicating the correct position of the field within the target chain. It is determined through data acquisition, monitoring, or target field position planning, based on the target chain design. It assumes that the field positions within the target chain have been pre-defined and obtained through analysis, and that their values ​​represent the standard positions the target fields should occupy.

[0110] : No. The structural complexity of a field combination represents the degree of complexity of that field within the chain structure. Structural complexity can be quantified by factors such as the degree of association between fields in the chain and the number of nested levels. For example, if a field involves more in-chain data transformations or has multiple related fields, its complexity will be correspondingly higher. Assume its value is 3 obtained through a chain structure analysis tool.

[0111] : No. The length of a combination of fields indicates the length of the data involved in that field or the length of the field sequence. The length is calculated based on the number of characters in the data field, the amount of data represented by the field, etc. Assume the length of this field is 50 (unit: characters).

[0112] The source chain structure level of this field combination indicates its structural position within the source chain. It is obtained through the source chain structure diagram and field classification criteria. Fields at lower levels represent basic data, while fields at higher levels represent more complex data structures. For example, a value of 2 indicates that the field is at the second level.

[0113] The target chain structure level of this field combination indicates the structural position level of this field within the target chain. Similar to the source chain, it is derived through analysis of the target chain structure diagram. Assume this field is at level 3 in the target chain.

[0114] : No. The weighted index of a combination of fields is used to adjust the weight of that field in the calculation. The weighting is set based on factors such as historical data and the frequency of field usage; for example, the weighted index is assumed to be 1.2.

[0115] : Total number of field combinations, representing the number of field combinations involved in the analysis. Assume there are 5 field combinations involved in the calculation.

[0116] Detailed calculation derivation process:

[0117] Based on the above analysis, calculations can be performed by substituting actual numbers into the formula. Let's assume we combine the first field (i.e....) The calculation is performed, assuming the relevant parameters are as follows:

[0118] ; ; ; ; ; ; ;

[0119] Substitute these values ​​into the formula to calculate the contribution of the first field combination:

[0120] ;

[0121] ;

[0122] ;

[0123] ;

[0124] ;

[0125] ;

[0126] ;

[0127] Explanation of final results:

[0128] Calculated The value 23.48 indicates that the stability contribution of the first field combination is 23.48. This value reflects the stability of this field combination; a higher value indicates that the field has higher stability in the chain. Factors such as offset, structural complexity, length, and level all affect the stability of this field. This result will be used to calculate the overall stability of all field combinations.

[0129] Instructions for setting parameter weights in the formula calculation process:

[0130] Difference in offset ( This directly affects the matching degree of the field's position in the chain. Field combinations with large offsets require more adjustments to adapt to the target chain structure.

[0131] Structural complexity ( This reflects the complexity of the field itself. Fields with higher complexity require greater weight in the calculation to reflect their influence.

[0132] Field length ( ) and structural hierarchy ( The position and depth of a field in the chain are influenced by its length; longer and deeper fields usually have more connections and influence.

[0133] Weighted index ( The settings are based on the performance and frequency of use of field combinations in historical data. Field combinations with higher weights usually require higher indices to adjust their calculation results.

[0134] Further derivation:

[0135] If we continue with other field combinations (such as...) The calculation of ) will also substitute the parameters of each field combination to finally calculate the stability value of all field combinations, and then sum these values ​​to obtain the total field arrangement stability value.

[0136] The specific steps of S5 are as follows:

[0137] S501: Obtain the recommended cross-chain field structure sequence, extract the field name and sequence number, select each field from the structure sequence in turn, extract the corresponding name and number, form a list of the correspondence between the main field name and the sequence number, generate a string of concatenated numbers, and obtain the field number list;

[0138] When obtaining the recommended cross-chain field structure sequence, the first step is to retrieve the defined cross-chain field structures from the cross-chain system. These structures may include multiple fields and their associated sequence numbers. Each field represents a data item in the cross-chain transaction process, and the sequence number is used to identify the order of the fields. During execution, all field data is first extracted from the cross-chain field structure sequence. Each field typically contains a unique field name and a corresponding sequence number. The field name may include identifying information such as "Chain ID" and "Transaction Type". Next, the name and sequence number of each field are extracted sequentially to generate a list of field numbers. This list pairs field names with sequence numbers to form a set of field data. For example, assuming the cross-chain field sequence contains the field names "Transaction Type" and "Chain ID" with sequence numbers 1 and 2, the generated list of field numbers might be [1: Transaction Type, 2: Chain ID]. The key to this step is to extract the sequence number and name of the fields sequentially from this list and concatenate them into a single number string to form a complete list of field numbers, facilitating subsequent processing and application. The final result is a list of field numbers for use in the next step.

[0139] S502: Based on the list of field numbers, combine the field names and numbers to generate a structure summary of the field names and numbers. Then, concatenate the number and name of each field into a set of data and summarize all fields to generate a complete structure summary, thus obtaining a list of structure summaries.

[0140] Based on the field number list generated above, the next step is to combine the number and name of each field to generate a structure summary. The core of this process lies in generating structured data corresponding to a field by combining the field number and name in a specific order. Each data item is formed by concatenating the field number and field name to create a structure summary. For example, based on the field number list [1: Transaction Type, 2: Chain ID] extracted in the previous step, the structure summary can be created as "1_Transaction Type_2_Chain ID", where "1" represents the transaction type number. Subsequent field names and numbers are combined sequentially and connected with underscores, resulting in the final structure summary "1_Transaction Type_2_Chain ID". By performing this concatenation process sequentially, the numbers and names of all fields are integrated into a structure summary list containing complete data. This process not only helps manage cross-chain field information but also provides a clear and orderly combination of fields for subsequent communication path identifier generation. In this step, the data of each field is precisely concatenated and arranged in order, ultimately generating a comprehensive structure summary list to provide data support for subsequent path identifier generation.

[0141] S503: Based on the structure summary list, combine the structure summary list with the main field name to generate a communication path identifier, and write the generated communication path identifier into the protocol configuration table to obtain the inter-chain path identification number item;

[0142] Next, based on the generated list of structure digests, each structure digest is combined with its corresponding main field name to generate the final communication path identifier. At this point, the communication path identifier is not only composed of field names, but also takes into account the field's sequential numbering, ensuring that the order and name of each field clearly indicate its specific location and function. For example, assuming the previously obtained structure digest is "1_Transaction Type_2_Chain ID", the main field name might be "Transaction Information" or "Cross-Chain Transaction". The communication path identifier will combine these elements, such as "Transaction Information_1_Transaction Type_2_Chain ID", to form a unique communication identifier. The generated communication path identifier is written into the protocol configuration table, ensuring that each field in the cross-chain system can be accurately identified and mapped to the corresponding inter-chain communication path through a specific identifier. Finally, the generated inter-chain path identification number provides clear path identification information for the cross-chain protocol, used to identify the specific data flow path in cross-chain transactions. This process involves the accurate mapping and configuration of field names, numbers, and their combinations, thereby ensuring that data can flow efficiently between different chains.

[0143] Please see Figure 2 A cross-chain system between blockchains, comprising:

[0144] The on-chain field information collection module obtains the deployment block height, earliest call height, call end height, and contract name of the field in the blockchain. Combined with the call sequence number of the field in the contract structure, it constructs the position range of the field in the on-chain structure and generates field call boundary association information.

[0145] The field conflict detection module extracts the transaction type, binding status data item and write order number of the fields in the source chain and the target chain based on the field call boundary association information, compares the consistency between the life cycle crossover and the write order, determines the field path combination that has conflict, and organizes and generates a list of field path conflict records.

[0146] The cross-chain protocol matching module checks whether related fields appear together in the configured cross-chain protocol structure based on the field path conflict record list. If they do, the corresponding communication structure is marked and a cross-chain protocol exclusion path set is generated.

[0147] The field matching and filtering module calls the cross-chain protocol exclusion path set, extracts the available field combinations in the target chain, judges the position difference and matching degree based on the field calling order number and verification identifier boolean value, filters the field combinations that match the continuity and distribution pattern of the source chain structure, and generates a recommended cross-chain field structure sequence.

[0148] The cross-chain path identification module calls the recommended cross-chain field structure sequence, extracts the main field name and sequence number list, concatenates the numbers and generates a structure summary, combines the structure summary with the field name, writes it into the protocol configuration table, and generates the inter-chain path identification number item.

[0149] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A cross-chain method between blockchains, characterized in that, Includes the following steps: S1: Obtain the current on-chain field deployment block height, call start and end height, and contract name. Combine this with the call sequence number within the contract to determine the field's position range in the on-chain structure and generate field call boundary association information. S2: Based on the field call boundary association information, extract the field transaction type, status data item and write sequence number in the source chain and target chain, determine the life cycle overlap and sequence difference, and organize the conflicting field paths into a field path conflict record list; S3: Based on the field path conflict record list, check whether the associated fields appear together in the configured cross-chain protocol structure. If they do, mark the corresponding communication structure and generate a cross-chain protocol exclusion path set. S4: Invoke the cross-chain protocol to exclude the path set, extract the available field combinations of the target chain, and filter the field combinations with continuous and consistent distribution of the source chain structure according to the difference between the invocation order number and the verification identifier, and generate a recommended cross-chain field structure sequence; S5: Call the recommended cross-chain field structure sequence, extract the main field name and sequence number, generate a structure summary and combine it with the field name to form a communication path identifier, write it into the protocol configuration table, and generate an inter-chain path identification number item; The specific steps of S1 are as follows: S101: Obtain the deployment block height of the contract to which the field belongs, the block height of the first and last calls of the field, and calculate the block offset values ​​of the first and last calls by combining the call sequence number, and generate the block offset range value of the field call. S102: Based on the field, call the block offset interval value, filter the data fields within the corresponding block range whose number is not less than the field number, count the number of fields and the difference between their numbers, and generate the field number interval span value; S103: Based on the field call block offset interval value and the field number interval span value, extract the field number and block height, calculate the average of the differences between adjacent field numbers and heights, and obtain the field call boundary correlation value.

2. The cross-chain method between blockchains according to claim 1, characterized in that, The field call boundary association information includes deployment block height, earliest call height, call end height, contract name, and call sequence number. The field path conflict record list includes transaction type, binding status data item, write sequence number, lifecycle cross information, and sequence difference information. The cross-chain protocol exclusion path set includes communication structure marker, protocol path exclusion item, and cross-chain structure filtering rules. The recommended cross-chain field structure sequence includes verification identifier boolean value, structure continuity parameter, and distribution pattern characteristics. The inter-chain path identification number item includes main field name, sequence number list, structure summary, communication path identifier, and protocol configuration table information.

3. The cross-chain method between blockchains according to claim 1, characterized in that, The specific steps of S2 are as follows: S201: Based on the field call boundary correlation value, extract the transaction type, binding status data item and write order number of the field in the source chain and target chain, mark the field path and number accordingly, and generate the field transaction order label quantity; S202: Call the field transaction sequence label, perform path cross-comparison of the write sequence numbers in the source chain and the target chain, extract the field paths with inconsistent write order and their number difference values, and generate a set of field path sequence difference values; S203: Based on the set of field path order difference values, identify combinations of lifecycle overlap and order difference that exist simultaneously in the field path, and obtain a list of field path conflict records.

4. The cross-chain method between blockchains according to claim 3, characterized in that, The specific calculation formula for extracting the field paths and their number differences due to inconsistent writing orders is as follows: ； in, The first in the path combination of the representative field The source chain path and the first The order difference weighted offset value of each target chain path. Represents the first in the target chain The writing order number of each field path For the first in the source chain The sum of the boundary call weights of all fields corresponding to each field path in the target chain. Representing the The source chain field and the first Call weight values ​​between target chain fields Representing the The total number of bound state data items for each field path in the source chain. Represents the first in the source chain The writing order number of each field path, This represents the number of field paths in the target chain.

5. The cross-chain method between blockchains according to claim 3, characterized in that, The specific steps for S3 are as follows: S301: Obtain the list of field path conflict records and the cross-chain protocol structure. Based on the field paths in the conflict records, detect whether the field paths co-occur with the conflicting fields in the cross-chain protocol structure. If they co-occur, mark the corresponding communication field combination position and generate a field co-occurrence communication position information set. S302: Call the communication field combination location in the field co-occurrence communication location information set, compare the intersection with the configured field set in the protocol structure, filter the communication structure in which at least two fields exist at the same time in the conflicting fields, calculate the field intersection ratio, and obtain the high co-occurrence field path structure set; S303: Based on the field path distribution in the high coexistence field path structure set, extract the field combinations that overlap with the field paths in the conflict record list, determine whether they co-occur repeatedly in all protocol structures, construct an exclusion field path index set, and generate a cross-chain protocol exclusion path set.

6. The cross-chain method between blockchains according to claim 5, characterized in that, The specific steps of S4 are as follows: S401: Call the cross-chain protocol to exclude the field paths in the path set and the target chain path, extract logically continuous field combinations in the target chain, record the field distribution position and calling order, and generate a field sequence difference value by comparing the order difference and displacement direction of the field combinations. S402: Based on the field sequence difference value and the field call order number, extract the field including the verification identifier boolean value, compare the position difference of the field in the target chain and the source chain, filter the field combination with the order offset less than the position difference threshold, and generate a boolean field offset matching value. S403: Based on the Boolean field offset matching degree value and the source chain structure continuity rule, compare the order and distribution trend of field combinations, filter combinations that meet the requirements of field offset direction and structural hierarchy, calculate the stability of field arrangement, and generate a recommended cross-chain field structure sequence.

7. The cross-chain method between blockchains according to claim 6, characterized in that, The specific formula used to filter combinations that meet the requirements of field offset direction and structural hierarchy is as follows: ； Where S represents the stability of the field arrangement. Representing the Source offset of a combination of fields, This represents the target offset of the field combination. Representing the The structural complexity of combining multiple fields, Representing the The length of the combination of fields, This represents the source chain structure hierarchy of the field combination. Representing the The target chain structure hierarchy of the combination of fields, Representing the The weighted index of a combination of fields, Represents the total number of field combinations.

8. The cross-chain method between blockchains according to claim 6, characterized in that, The specific steps of S5 are as follows: S501: Obtain the recommended cross-chain field structure sequence, extract the field name and sequence number, select each field from the structure sequence in turn, extract the corresponding name and number, form a corresponding list of main field names and sequence numbers, generate a string of concatenated numbers, and obtain a list of field numbers; S502: Based on the field number list, combine the field names and numbers to generate a structural summary of the field names and numbers. Then, concatenate the number and name of each field into a set of data, and summarize all fields to generate a complete structural summary, thus obtaining a structural summary list. S503: Based on the structure summary list, combine the structure summary list with the main field name to generate a communication path identifier, and write the generated communication path identifier into the protocol configuration table to obtain the inter-chain path identification number item.

9. A cross-chain system between blockchains, characterized in that, The system is used to perform a cross-chain method between blockchains as described in any one of claims 1-8, the system comprising: The on-chain field information collection module obtains the deployment block height, earliest call height, call end height, and contract name of the field in the blockchain. Combined with the call sequence number of the field in the contract structure, it constructs the position range of the field in the on-chain structure and generates field call boundary association information. Based on the field call boundary association information, the field conflict detection module extracts the transaction type, binding status data item and write order number of the fields in the source chain and the target chain, compares the consistency between the life cycle intersection and the write order, determines the field path combination that has conflict, and organizes and generates a list of field path conflict records. The cross-chain protocol matching module checks whether related fields appear together in the configured cross-chain protocol structure based on the field path conflict record list. If they do, the corresponding communication structure is marked and a cross-chain protocol exclusion path set is generated. The field matching and filtering module calls the cross-chain protocol exclusion path set, extracts the available field combinations in the target chain, judges the position difference and matching degree based on the field calling order number and verification identifier boolean value, filters the field combinations that match the continuity and distribution pattern of the source chain structure, and generates a recommended cross-chain field structure sequence. The cross-chain path identification module calls the recommended cross-chain field structure sequence, extracts the main field name and sequence number list, concatenates the numbers and generates a structure summary, combines the structure summary with the field name, writes it into the protocol configuration table, and generates the inter-chain path identification number item.

Images