Data cross-chain transmission method based on multi-signature proof

Abstract

The application provides a data cross-chain transmission method based on multi-signature proof, relates to the technical field of blockchain interoperability and cross-chain trusted transmission, and performs data update on a sending log list based on a cross-chain set of a message source chain, obtains broadcast log data and performs broadcast sending; a signer set is determined according to a heterogeneous chain type of the message source chain, a checkpoint of the broadcast log data is constructed based on the signer set; the checkpoint is subjected to hash calculation to obtain a checkpoint hash, the checkpoint hash is subjected to threshold signature according to the signer set to obtain a final certification; transmission data is obtained according to the checkpoint and the final certification, message verification is performed based on the transmission data on a target chain to obtain a verification result, the checkpoint containing the sending message can be subjected to threshold signature according to the blockchain, and the verification efficiency of cross-chain data verification is improved.

Description

Technical Field

[0001] This invention relates to data processing technology, and more particularly to a method for cross-chain data transmission based on multiple signatures. Background Technology

[0002] With the widespread application of blockchain technology in multi-chain collaborative distributed business interoperability, the demand for reliable and efficient data interaction between heterogeneous chains is increasing.

[0003] Currently, due to the existence of multiple different types of blockchains in enterprise management, and the differences between different blockchains, each chain becomes an independent technology, making it impossible to configure and maintain them uniformly, which increases management costs. Existing cross-chain transmission solutions usually adopt fixed verification nodes or full signature verification modes, which leads to a relatively redundant cross-chain verification process, high computational overhead, and an inability to simultaneously ensure data transmission security and verification efficiency.

[0004] Therefore, how to perform threshold signing on checkpoints containing sent messages based on the blockchain to improve the verification efficiency of cross-chain data verification has become an urgent problem to be solved. Summary of the Invention

[0005] This invention provides a cross-chain data transmission method based on multi-signature authentication, which can perform threshold signatures on checkpoints containing sent messages according to the blockchain, thereby improving the verification efficiency of cross-chain data verification.

[0006] A first aspect of this invention provides a method for cross-chain data transmission based on multiple signatures, comprising: The cross-chain collection based on the message source chain updates the data of the sending log list, obtains the broadcast log data, and broadcasts it. The signer set is determined based on the heterogeneous chain type of the message source chain, and checkpoints for the broadcast log data are constructed based on the signer set. The checkpoint is hashed to obtain the checkpoint hash, and the checkpoint hash is threshold-signed according to the set of signers to obtain the finality certificate; Based on the checkpoints and the finality certificate, the transmitted data is obtained, and message verification is performed on the target chain based on the transmitted data to obtain the verification result.

[0007] Optionally, in one possible implementation of the first aspect, the cross-chain set based on the message source chain updates the sending log list to obtain broadcast log data, including: Extract the key fields of each cross-chain message in the cross-chain set, perform a hash operation on the key fields, and obtain the message leaf; The number of message leaves is counted to obtain the number of new counts. The historical counts are updated based on the number of new counts to obtain the current count. The message leaf is filled into the sending log list to obtain the broadcast log list. Based on the current count and the broadcast log list, the broadcast log data is obtained.

[0008] Optionally, in one possible implementation of the first aspect, determining the signer set based on the heterogeneous chain type of the message source chain includes: when the heterogeneous chain type of the message source chain is determined to be a first definite type, the consensus audit node of the message source chain is used as a verifiable signature node. When the heterogeneous chain type is determined to be the second joint type, the organization audit nodes of each organization in the message source chain are selected based on the preset number of witnesses to obtain verifiable signature nodes; The set of signers for the corresponding message source chain is obtained by statistically analyzing the verifiable signature nodes.

[0009] Optionally, in one possible implementation of the first aspect, constructing checkpoints for the broadcast log data based on the set of signers includes: Obtain the broadcast time corresponding to the broadcast log data, and calculate the interval duration based on the time difference between the current time and the broadcast time; When the interval duration is determined to be equal to the preset construction duration, a checkpoint is generated based on the current count of broadcast log data, the broadcast log list, the source chain address of the message source chain, the signer set, and the current time.

[0010] Optionally, in one possible implementation of the first aspect, the step of hashing the checkpoint to obtain a checkpoint hash, and then performing a threshold signature on the checkpoint hash based on the set of signers to obtain a finality certificate, includes: The check fields in the checkpoints are normalized and sorted to obtain a check sequence, and the check sequence is hashed to obtain the checkpoint hash; Based on the heterogeneous chain type of the message source chain, the signer set is controlled to perform threshold signing on the checkpoint hash to obtain a finality certificate.

[0011] Optionally, in one possible implementation of the first aspect, controlling the signer set to perform threshold signing on the checkpoint hash based on the heterogeneous chain type of the message source chain to obtain a finality certificate includes: The number of verifiable signature nodes in the signer set is counted to obtain the number of verification nodes. Based on the number of verification nodes, a preset threshold form is compared to obtain the signature threshold. An initial signature bitmap is generated based on the signer set. The signer set generates node signatures based on the signature threshold and checkpoint hash. The initial signature bitmap is updated based on the node signatures to obtain the sending signature bitmap. The already signed verifiable signature nodes are taken as signed nodes, and the node signatures of the signed nodes are counted sequentially according to the signature position in the sent signature bitmap to obtain a signature list. A finality certificate is obtained based on the set address of the signer set, the signature threshold, the sent signature bitmap, and the signature list.

[0012] Optionally, in one possible implementation of the first aspect, the set of signers generates node signatures based on the signature threshold and checkpoint hash, including: When the heterogeneous chain type is determined to be the first definite type, each verifiable signature node verifies the checkpoint hash and generates a node signature based on the monitoring results of the message source chain; When the heterogeneous chain type is determined to be the second joint type, each verifiable signature node generates a node signature based on the cross-organization verification strategy when the number of monitoring counts is equal to the current number of counts.

[0013] Optionally, in one possible implementation of the first aspect, generating node signatures based on a cross-organizational verification strategy includes: The broadcast log lists received by each organization are used as the verification lists of the corresponding organizations. When the verification lists of each organization are consistent, the checkpoint hash is verified and a node signature is generated.

[0014] Optionally, in one possible implementation of the first aspect, obtaining the transmission data based on the checkpoint and the finality certificate, performing message verification on the target chain based on the transmission data, and obtaining the verification result includes: The relay layer receives the broadcast log data, extracts message leaves, and generates message proofs based on the message leaves; Based on the checkpoints, the finality certificate, and the message proof, the transmitted data is submitted to the target chain; The target chain performs data parsing on the finality certificate to obtain the set address, and retrieves the preset public key list based on the set address; The transmitted data is subjected to bitmap verification based on the preset public key list to obtain the verification result.

[0015] Optionally, in one possible implementation of the first aspect, the step of performing bitmap verification on the transmitted data according to the preset public key list to obtain a verification result includes: Identify the bitmap symbol of the verifiable signature node that sends the signature bitmap in the transmitted data. When the bitmap symbol is determined to be a signature symbol, compare the node signature with the verification signature at the corresponding position in the preset public key list to obtain the first verification result. When the first verification result is determined to be a match, the number of valid signatures is incremented to obtain the current number of valid signatures. When the number of currently valid signatures is greater than or equal to the signature threshold, a verification pass result is obtained; when the number of currently valid signatures is less than the signature threshold, a verification failure result is obtained. The verification result includes the verification pass result and the verification failure result.

[0016] A third aspect of the present invention provides an electronic device, comprising: a memory, a processor, and a computer program, wherein the computer program is stored in the memory, and the processor executes the computer program to perform the methods described in the first aspect of the present invention and various possible methods related to the first aspect.

[0017] A fourth aspect of the present invention provides a storage medium storing a computer program, which, when executed by a processor, is used to implement the first aspect of the present invention and various methods possibly involved in the first aspect.

[0018] The beneficial effects of this invention are as follows: 1. This invention can adaptively construct a corresponding signer set based on heterogeneous chain types to improve the security of cross-chain information transmission. Specifically, this invention can dynamically determine the signer set based on the heterogeneous chain type of the message source chain. For the first clearly defined type of message source chain, the consensus audit node of the message source chain can be directly used as a verifiable signature node to ensure the legitimacy and credibility of the signing entity and improve signing efficiency. For the second joint type of message source chain, organizational audit nodes can be selected from various organizations as verifiable signature nodes based on a preset number of witnesses. This multi-organization witnessing method avoids a single organization or node controlling the signing process and improves the credibility of cross-chain information.

[0019] 2. This invention can generate a final certificate, improving the verification efficiency of transmitted data on the target chain. Specifically, this invention can normalize and sort the check fields in the checkpoint to obtain a check sequence, and then perform hash calculations to obtain the checkpoint hash. This avoids hash inconsistencies caused by differences in the field reading order among different nodes, ensuring the accuracy of the signing and verification process. Simultaneously, the hash operation transforms complex checkpoints into short hash values, facilitating improved signing efficiency. Furthermore, this invention can generate an initial signature bitmap based on the signer set. Each verifiable signing node executes corresponding verification logic according to the heterogeneous chain type to generate a node signature, updating the signature bitmap in real time to obtain the sent signature bitmap. The set address, signature threshold, sent signature bitmap, and signature list are integrated and encapsulated to obtain a final certificate, enabling the target chain to quickly verify based on the final certificate without relying on the underlying structure of the source chain, thus improving signing efficiency.

[0020] 3. This invention enables the target chain to perform threshold verification on the sent signature bitmap, reducing resource consumption and improving verification efficiency. Specifically, the target chain can parse the finality certificate to obtain the set address of each signing node and retrieve a preset public key list. Based on the public key list and the sent signature bitmap, it verifies the legitimacy of each node's signature one by one, counts the current number of valid signatures, and compares the current number of valid signatures with a signature threshold to obtain the verification result. This verification process does not require parsing the entire cross-chain message; trustworthiness verification can be completed solely through threshold verification using the finality certificate, thus improving verification efficiency. Attached Figure Description

[0021] Figure 1 A flowchart of a data cross-chain transmission method based on multiple signatures provided by the present invention; Figure 2 A flowchart for obtaining a set of signers provided by the present invention; Figure 3 A flowchart for obtaining the current number of valid signatures provided by the present invention; Figure 4 This invention provides a flowchart for determining verification results. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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.

[0023] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0024] like Figure 1 As shown, the present invention provides a flowchart of a data cross-chain transmission method based on multiple signatures. This data cross-chain transmission method based on multiple signatures includes: S1 updates the sending log list based on the cross-chain set of the message source chain, obtains the broadcast log data, and broadcasts it.

[0025] It should be noted that since the message source chain generates multiple messages that need to be sent at the same time, and these messages may be sent to different target chains, when the message source chain needs to send the generated messages to the target chain, it usually aggregates the messages within the same time period and sends them outward. This allows the monitoring nodes on the message source chain side to promptly monitor the broadcast log data, verify the signature, listen to the relay layer information, and package and submit the messages. This improves the efficiency of message sending from the message source chain side and the accuracy of the messages when they are sent.

[0026] Among them, the message source chain is the blockchain that generates messages and sends them outwards; it is the party that generates the data. The cross-chain set is the set of all business messages that need to be sent in the current batch. The sending log list is an ordered list within the source chain used to record cross-chain messages. The broadcast log data is the information data sent outwards.

[0027] In some embodiments, a specific implementation of step S1 includes: S11, extract the key fields of each cross-chain message in the cross-chain set, perform a hash operation on the key fields, and obtain the message leaf.

[0028] Understandably, the source chain, i.e. the message source chain, performs hash operations on each cross-chain message that needs to be sent in the cross-chain set to obtain the message leaf corresponding to each cross-chain message. This allows for rapid verification of cross-chain messages through the message leaf, improving verification efficiency.

[0029] Among them, the cross-chain message is the message data that needs to be sent across chains, the key fields are the field information in the cross-chain message, such as the source of the cross-chain message, the information field to be sent to the target chain, the message content hash field, the message sequence number and other related field information, and the message leaf is the information data obtained after hashing the key fields.

[0030] S12, count the number of message leaves to obtain the number of new counts, update the historical counts based on the number of new counts to obtain the current count.

[0031] Understandably, as the message source chain continuously generates new cross-chain messages at different times, the number of message leaves obtained by hashing the cross-chain messages also increases continuously. Therefore, it is necessary to update the count of message leaves in a timely manner so that each verifiable signature node can verify the broadcast log data based on the count, thereby improving the efficiency and accuracy of data verification.

[0032] Among them, the newly added count is the number of message leaves corresponding to newly generated cross-chain messages counted by the message source chain at the current moment, the historical count is the number of message leaves corresponding to the historical period before the current moment, and the current count is the total number of message leaves at the current moment.

[0033] S13, fill the message leaf into the sending log list to obtain the broadcast log list, and obtain the broadcast log data based on the current count and the broadcast log list.

[0034] It is understandable that the broadcast log list is the sending log list with newly added message leaves, and the broadcast log data includes the current count and the broadcast log list.

[0035] S2, determine the signer set according to the heterogeneous chain type of the message source chain, and construct the checkpoint of the broadcast log data based on the signer set.

[0036] Understandably, different blockchains have different architectures, meaning their trust models also differ. Some rely on strong consensus nodes for information commitment, while others involve joint monitoring and governance by multiple organizations. Therefore, not all types of blockchains can adhere to the same set of signature rules. Figure 2 As shown, the set of signers can be determined based on the heterogeneous chain type of the message source chain, so as to construct a checkpoint corresponding to the current broadcast log data.

[0037] Among them, heterogeneous chain type refers to the type of blockchain, including first explicit type and second joint type. For example, ChainMaker and BCOS have strong finality and clear node governance, so the corresponding blockchain type can be classified as first explicit type. In the Fabric blockchain scenario, consensus audit nodes do not have strong finality or clear functions, so the Fabric blockchain type is classified as second joint type. Signer set is the set of nodes that can make commitments to verify message reliability. Checkpoint is the information set that quickly checks the broadcast log data at a certain moment, including broadcast log list, current count, source chain information, signer information, etc.

[0038] Through the above implementation methods, the present invention can dynamically determine a suitable set of signers based on the type of message source chain, without relying on a single centralized node, so as to improve the security of subsequent information dissemination.

[0039] In some embodiments, a specific implementation of step S2 includes: S21, when the heterogeneous chain type of the message source chain is determined to be the first definite type, the consensus audit node of the message source chain is used as a verifiable signature node.

[0040] Understandably, when the source chain is determined to belong to the first clearly defined type of blockchain, the source chain itself has already completed the verification process of node information through the consensus mechanism. Its consensus audit node has the recognized credibility and verification authority on the blockchain. There is no need to find other nodes to assist in verifying the correctness of cross-chain information. The consensus audit node can be directly used as a verifiable signature node, which helps to ensure the legitimacy and credibility of the signing subject and improves the signing efficiency.

[0041] Among them, heterogeneous chain type refers to the type of blockchain with different structures. The first explicit type is a blockchain type with strong finality and clear and explicit node governance rules. Consensus audit node is a node in the source chain that participates in consensus verification and has legal auditing authority on the chain. Verifiable signature node is a node that is authorized to sign and promise to ensure the credibility of the data for checkpoint information.

[0042] S22, when the heterogeneous chain type is determined to be the second joint type, the organization audit nodes of each organization in the message source chain are selected based on the preset number of witnesses to obtain verifiable signature nodes.

[0043] Understandably, since the second type of blockchain operates through multi-organizational joint governance, there is no unified strong finality consensus functional node. Its trust foundation is jointly formed by the participating organizations. It is impossible to rely on a single audit node to make a reliability commitment signature for cross-chain information. Furthermore, since there are many nodes on each organization, it is not possible to have them all verify before signing. Therefore, a fixed number of nodes can be selected on each organization to aggregate the nodes selected by multiple organizations to obtain a set of signers. Thus, a corresponding number of nodes can be selected from each participating organization on the chain as verifiable signing nodes according to a preset number. The fairness and security of the verification nodes are ensured through multi-organizational distributed witnessing, avoiding the control of the signing process by a single organization or node, and facilitating the improvement of the credibility of cross-chain information.

[0044] The second joint type is a blockchain type that requires the joint participation of multiple organizations in governance and collaborative verification. That is, a blockchain type in which multiple organizations participate in governance and rely on inter-organizational collaborative verification. The preset witness number is the number of organizational nodes required for participation in signing, that is, the number of nodes selected on each organization of the blockchain. The organizational audit node is the node responsible for data review and verification within each participating organization.

[0045] S23, count the verifiable signature nodes to obtain the set of signers for the corresponding message source chain.

[0046] Understandably, all verifiable signature nodes selected based on heterogeneous chain types will be aggregated and statistically analyzed to obtain the signer set corresponding to the current message source chain. This will provide a clear range of verifiable signature nodes for subsequent checkpoint signing, enabling the target chain to determine the legitimate signer based on the signer set during verification, avoiding other nodes from participating in the signing process, and allowing for reliability verification of the signing process.

[0047] S24, obtain the broadcast time corresponding to the broadcast log data, and obtain the interval duration based on the time difference between the current time and the broadcast time.

[0048] Understandably, since cross-chain messages are generated irregularly, checkpoints can be built according to fixed time periods to avoid resource waste caused by frequent checkpoint generation and to improve the overall efficiency of cross-chain processing. Therefore, the time of broadcast log data can be recorded and the time interval between the current time and the broadcast time can be calculated in real time for subsequent checkpoint construction.

[0049] Among them, the broadcast time is the time when the message source chain sends the broadcast log data outward, the current time is the real-time time for building the checkpoint, and the interval duration is the time difference between the current time and the broadcast time.

[0050] S25, when it is determined that the interval duration is equal to the preset construction duration, a checkpoint is generated based on the current count of broadcast log data, the broadcast log list, the source chain address of the message source chain, the signer set, and the current time.

[0051] Understandably, when the time interval reaches the preset checkpoint construction period, the currently aggregated broadcast log data, the source chain address of the message source chain, the set of signers, and the time information are integrated to construct the corresponding checkpoint. This checkpoint, as an information set of a certain batch of cross-chain messages, contains complete key information that can be verified, facilitating subsequent verification by the target chain.

[0052] The preset construction duration is the pre-set checkpoint generation time interval, and the source chain address is the unique identifier of the message source chain in the blockchain network.

[0053] S3, perform hash calculation on the checkpoint to obtain the checkpoint hash, and perform threshold signature on the checkpoint hash according to the signer set to obtain the finality certificate.

[0054] Understandably, checkpoints contain a lot of information, and signing them directly is inefficient and easily tampered with. Therefore, it is better to first perform a hash operation on the checkpoint to obtain a short hash value before signing, which improves signing efficiency. At the same time, when signing the checkpoint hash, a final certificate that meets the verification conditions will only be obtained after the number of signed nodes meets the threshold condition. This allows the target chain to directly verify the number of signatures and bitmap symbols in the final certificate, reducing data processing volume and improving the verification efficiency of message verification.

[0055] Among them, the checkpoint hash is the unique data information obtained after normalizing the checkpoint hash, representing the digital identity of the checkpoint; the threshold signature is the signature that is valid only when a preset minimum number of signatures is reached; and the finality certificate is a complete proof file containing signer information, signature threshold, bitmap, and signature list.

[0056] In some embodiments, a specific implementation of step S3 includes: S31, the check fields in the checkpoint are normalized and sorted to obtain a check sequence, and the check sequence is hashed to obtain the checkpoint hash.

[0057] It is understandable that checkpoints contain multiple different types of check fields, and different nodes may read the fields in different orders. In order to ensure that the hash results calculated by all subsequent verifiable signature nodes are consistent with those calculated by the target chain, the check fields can be first sorted according to preset rules to obtain a check sequence, and then a hash operation can be performed on the check sequence to obtain a unique checkpoint hash. By using a unified sorting method, the hash inconsistency caused by different field orders can be avoided, which facilitates the accuracy and consistency of the signing and verification process.

[0058] Among them, the check fields are the various data fields contained in the checkpoint, such as the current count, broadcast log list, source chain address, signer set, timestamp, etc. The normalized sorting can be the arrangement of the check fields according to the preset field order or the byte length of the check fields. The check sequence is the byte sequence obtained after the fields are arranged in order. The checkpoint hash is the structured data obtained by performing a hash operation on the check sequence.

[0059] It is worth mentioning that when performing hash calculations on checkpoints, the domain separation and version tag corresponding to the checkpoint are added to obtain the checkpoint hash, so as to avoid hash collisions between different objects or different version encodings.

[0060] S32, control the set of signers to perform threshold signing on the checkpoint hash according to the heterogeneous chain type of the message source chain, and obtain the finality certificate.

[0061] It is understandable that, since the verification logic and signing conditions of different heterogeneous chain types are different, the signature strategy can be adopted according to the type of the message source chain to control the set of signers to sign the checkpoint hash. That is, after the threshold condition for the number of signatures is met, the relevant signature information is summarized to obtain a final certificate that can be directly verified by the target chain, so as to perform adaptive threshold signing according to different heterogeneous chain types and obtain a final certificate.

[0062] In some embodiments, a specific implementation of step S32 includes: S321, count the number of verifiable signature nodes in the signer set to obtain the number of verification nodes, and compare the preset threshold form based on the number of verification nodes to obtain the signature threshold.

[0063] Understandably, since the number of verifiable signing nodes in the signer set corresponding to different types of message source chains is different, and the number of signatures when the signer set performs threshold signing on the checkpoint hash cannot be less than the threshold number, the subsequent target chain will compare the number of signed nodes with the threshold to obtain the verification result. Therefore, the number of verification nodes can be obtained by counting the number of verifiable signing nodes in the signer set corresponding to the message source chain, and then compared with the preset threshold form to obtain the signing threshold. This facilitates the subsequent signing of the checkpoint hash by the signer set based on the signing threshold, which not only monitors the source chain of the information to ensure information security, but also avoids excessive resource waste during the signing process.

[0064] Among them, the number of verification nodes is the total number of nodes in the signer set that can participate in signing, the preset threshold form is a pre-configured table with thresholds, which contains the mapping relationship between the number of verification nodes and the corresponding signing threshold. For example, when the number of verification nodes is 5, the corresponding signing threshold is 3. The signing threshold is the minimum number of currently valid signatures required for the signature to take effect.

[0065] S322, an initial signature bitmap is generated based on the signer set. The signer set generates node signatures based on the signature threshold and checkpoint hash. The initial signature bitmap is updated according to the node signatures to obtain the sending signature bitmap.

[0066] Understandably, in order to enable the target chain to quickly verify the credibility of the transmitted data, an initial signature bitmap with all-zero identifiers can be generated based on the set of signers. Each identifier corresponds to a verifiable signature node. Each verifiable signature node verifies the checkpoint hash and generates a node signature according to the verification rules of the corresponding heterogeneous chain type. After each node signature is completed, the identifier of the corresponding node position in the initial signature bitmap is updated to obtain a sending signature bitmap that marks all signed nodes, so as to enable rapid verification of the sending signature bitmap in the future.

[0067] The initial signature bitmap is a sequence containing the signature positions and initial signature identifiers of all verifiable signature nodes in the signer set. For example, if there are 5 verifiable signature nodes in the signer set, these 5 verifiable signature nodes can be sorted and associated with the corresponding initial signature identifier 0 to obtain the initial signature bitmap 00000. The sending signature bitmap is a bitmap that records the bitmap after a node has completed signing. For example, when a verifiable node located at the second position in the initial signature bitmap completes signing, the initial signature bitmap is updated to obtain the sending signature bitmap 01000. The node signature is the signature data obtained by each verifiable signature node signing the checkpoint hash using its own private key.

[0068] In some embodiments, a specific implementation of step S322 includes: S3221, when the heterogeneous chain type is determined to be the first definite type, each verifiable signature node verifies the checkpoint hash and generates a node signature based on the monitoring results of the message source chain.

[0069] Understandably, for first-definition blockchains with strong finality and a clear governance structure, their consensus audit nodes can directly monitor the message source chain in real time, confirm whether the checkpoint information is true and valid, and whether the broadcast log data is legal and correct. After the verification is passed, the checkpoint hash is directly signed to generate the corresponding node signature.

[0070] The monitoring result is the result of the verifiable signature node monitoring and verifying the received broadcast log data.

[0071] S3222, when the heterogeneous chain type is determined to be the second joint type, when each verifiable signature node determines that the number of monitoring counts is equal to the current number of counts, a node signature is generated based on the cross-organization verification strategy.

[0072] Understandably, for the second type of joint governance blockchain, there is no unified strong consensus node. Each organization's signing node can first confirm whether the current count in the currently monitored broadcast log data is the same as the target count in the broadcast log data generated by the source chain at the corresponding time. By quickly verifying the count, it can be determined whether a trustworthy signature can be made. Only when it is determined that the current count is equal to the target count can the subsequent verifiable signing node generate a node signature according to the cross-organization verification strategy, so as to improve the data processing efficiency of the signing process.

[0073] The number of monitoring counts refers to the number of counts in the broadcast log data monitored by verifiable signature nodes.

[0074] In some embodiments, a specific implementation of step S3222 includes: S32221, The broadcast log list received by each organization is used as the verification list of the corresponding organization. When it is determined that the verification lists of each organization are consistent, the checkpoint hash is verified and a node signature is generated.

[0075] Understandably, in a multi-organizational joint governance scenario, each organization's signing node can use its own monitored broadcast log list as a local verification list. By comparing the contents of each organization's local verification list, and confirming that the log data of all organizations is completely consistent and there is no tampering or inconsistency, each verifiable node reconstructs the checkpoint according to the verification list and performs a hash operation to obtain the verification hash. Then, it compares the detected checkpoint hash with the verification hash and confirms that the verification hash and checkpoint hash are consistent before signing, in order to improve the credibility of cross-organizational data and prevent a single organization from tampering with the data.

[0076] The verification list is a list of broadcast logs received by each organization for monitoring.

[0077] S323, the signed verifiable signature nodes are taken as signed nodes, and the node signatures of the signed nodes are counted sequentially according to the signature position in the sent signature bitmap to obtain a signature list.

[0078] Understandably, due to the different response times of different verifiable signing nodes—for example, all verifiable signing nodes can complete signing at the same time, but verifiable signing nodes may also experience delays due to a large amount of data processing—it is impossible to obtain node signatures from all verifiable signing nodes at the same time. Therefore, in order to improve the efficiency of cross-chain proof generation, a final certificate can be generated once it is determined that the number of completed signatures in the signature bitmap is greater than or equal to the signature threshold. For example, as long as any three nodes in the network reach a consensus and exchange information, the certificate is generated, without waiting for all five nodes to complete signing before generating the final certificate. This is to improve the efficiency of cross-chain proof generation while meeting the security requirement of reaching the signature threshold.

[0079] Among them, the signed node is the verifiable signed node that has completed the signing, the signature position is the arrangement position of the signed node in the sent signature bitmap, such as signed node A corresponding to the first position and signed node C corresponding to the third position, and the signature list is the sequence obtained by sorting all valid node signatures according to the bitmap order.

[0080] S324, obtains a finality certificate based on the set address of the signer set, the signature threshold, the sent signature bitmap, and the signature list.

[0081] Understandably, by encapsulating and combining the signer set identifier, signature threshold, sent signature bitmap, and signature list, a finality certificate can be obtained. Subsequent target chains can independently complete a rapid verification process using this finality certificate without relying on the underlying structure of the source chain, thus achieving lightweight, standardized, and trustworthy cross-chain proof.

[0082] The set address is the unique identifier of the set of signers in the blockchain network, and the finality certificate is a standardized and trusted proof document containing the set address, signature threshold, sent signature bitmap, and signature list.

[0083] S4. Obtain the transmission data based on the checkpoint and the finality certificate, perform message verification on the target chain based on the transmission data, and obtain the verification result.

[0084] Understandably, the relay layer packages the checkpoint, finality certificate, and message proof and sends them to the target chain. The target chain does not need to verify all the data from the source chain, but only needs to verify whether the finality certificate is valid, i.e., whether the signature is valid, whether the number of signatures meets the threshold requirement, and whether the message truly belongs to the checkpoint. If the verification passes, the cross-chain message is considered trustworthy and the business message content is executed; otherwise, it is rejected.

[0085] The transmitted data refers to all information data transmitted to the target chain, and the verification result is the result of the target chain verifying the received cross-chain message.

[0086] Through the above implementation method, the target chain can achieve fast verification without parsing and verifying all message content corresponding to cross-chain messages.

[0087] In some embodiments, a specific implementation of step S4 includes: S41, the relay layer receives the broadcast log data, extracts the message leaf, and generates a message proof based on the message leaf.

[0088] Understandably, after the relay layer listens to the broadcast log data of the message source chain, it extracts the message leaf of the corresponding cross-chain message and generates a message proof based on the association between the message leaf and the broadcast log list. This message proof allows the target chain to quickly verify the authenticity and ownership of the message without synchronizing the full log data, thus achieving lightweight message verification.

[0089] The relay layer is a transit service layer that listens to the source chain broadcast, collects data, and forwards it to the target chain. The message proof is the verification data that proves the message leaf belongs to the corresponding broadcast log list.

[0090] It's easy to understand that the source chain constructs a hash tree based on the broadcast log list, using multiple message leaves as leaf nodes of the hash tree, and calculates the cross-chain message root hash layer by layer. The relay layer obtains the message proof by collecting the hash values ​​of adjacent sibling nodes on the path from the leaf node to the root node based on the index position of the message leaf to be proven in the hash tree. The message proof includes at least the message leaf, the leaf index, the set of sibling node hashes, and the size of the hash tree. The target chain recalculates the hash path based on the message leaf to be proven and the message proof to obtain the reconstructed root hash. The reconstructed root hash is compared with the cross-chain message root hash in the checkpoint. If they match, it is determined that the message leaf belongs to the broadcast log list corresponding to the current checkpoint, thus obtaining the result that the message inclusion relationship verification is successful.

[0091] S42, based on the checkpoint, the finality certificate, and the message proof, the transmitted data is submitted to the target chain.

[0092] Understandably, the relay layer encapsulates checkpoints, finality certificates, and message proofs into complete transmission data, and submits this transmission data to the target chain. The target chain can verify the transmission data without directly interacting with the message source chain, which improves the stability of cross-chain transmission.

[0093] The transmitted data is the data transmitted to the target chain, which can include a complete cross-chain data packet containing checkpoints, finality certificates, and message proofs.

[0094] S43, the target chain performs data parsing processing on the finality certificate to obtain the set address, and retrieves the preset public key list based on the set address.

[0095] Understandably, after receiving the transmitted data, the target chain can first parse the finality certificate, extract the set address corresponding to the set of signers, and then obtain the list of public keys corresponding to the set of signers from the local pre-configured information based on the set address, so as to verify the accuracy of the node signatures and prevent illegal node signatures from passing the verification.

[0096] The set address is the network identifier of each verifiable signing node in the signer set, such as an IP address. The preset public key list is the set of public key data corresponding to each node in the signer set that is pre-stored in the target chain.

[0097] S44, perform bitmap verification on the transmitted data according to the preset public key list to obtain the verification result.

[0098] Understandably, the target chain can verify the legitimacy of node signatures one by one by using the obtained pre-set public key list and the sending signature bitmap and signature list in the finality certificate of the transmitted data, and count the current number of valid signatures. By determining whether the current number of valid signatures meets the signature threshold, the final verification result can be obtained, which facilitates the automated verification of the trustworthiness of cross-chain data and improves verification efficiency.

[0099] Bitmap verification is a verification method that verifies each signature by combining the signature position marked on the signature bitmap with the public key list. The verification result is the result of whether the transmitted data passes the trustworthiness verification.

[0100] It is worth mentioning that the process of automating the verification of the trustworthiness of cross-chain data includes verifying whether the finality certificate is trustworthy based on the public key and signature threshold, and reconstructing the root hash to determine whether the message leaf belongs to the current broadcast log list. Only when both are verified successfully will a verification result be obtained.

[0101] In some embodiments, a specific implementation of step S44 includes: S441, Identify the bitmap symbol of the verifiable signature node that sends the signature bitmap in the transmitted data. When the bitmap symbol is determined to be a signature symbol, compare the node signature with the verification signature at the corresponding position in the preset public key list to obtain the first verification result.

[0102] Understandably, the target chain identifies the bitmap symbols in the sent signature bitmap bitmap bit by bit. When a bitmap symbol of a certain bit is a signature symbol indicating that it has been signed, such as the second bitmap symbol being 1, it means that the node corresponding to that position has participated in the signing. At this time, the signature of the corresponding node is retrieved from the signature list, and the signature is verified using the public key corresponding to the verifiable signature node in the preset public key list to determine whether the signatures are consistent and obtain the first verification result.

[0103] Among them, the bitmap symbol is a binary bit identifier used in the signature bitmap to mark whether a node has signed, the signature symbol is an identifier indicating that the corresponding node has completed the signing, such as 1, and the first verification result is the comparison result of whether the signatures of a single node are consistent.

[0104] S442, when it is determined that the first verification result is consistent, the number of valid signatures is calculated by incrementing the number of valid signatures to obtain the current number of valid signatures.

[0105] Understandably, when a node's signature verification passes (i.e., the first verification result is a match), it indicates that the node's signature is valid. The number of valid signatures is then incremented by one. Figure 3As shown, after traversing the bitmap symbols corresponding to all signature nodes in sequence, the total number of valid signatures is finally obtained, which is the current number of valid signatures. This allows the current number of valid signatures to be compared with the signature threshold to obtain the verification result.

[0106] The number of valid signatures is the initial count of valid signatures before the verification begins, which is usually 0. The current number of valid signatures is the total number of node signatures that have passed the verification.

[0107] S443, when it is determined that the number of currently valid signatures is greater than or equal to the signature threshold, a verification pass result is obtained; when it is determined that the number of currently valid signatures is less than the signature threshold, a verification failure result is obtained. The verification result includes the verification pass result and the verification failure result.

[0108] It is understandable that, such as Figure 4 As shown, the target chain compares the current number of valid signatures with the signature threshold. If the current number of valid signatures reaches or exceeds the signature threshold, it indicates that the current signature meets the requirements for the credibility of the transmitted data, that is, the checkpoint and the cross-chain message are credible. The result can be combined with the message inclusion relationship to obtain the verification result. If the current number of valid signatures does not reach the signature threshold, it indicates that the signature does not meet the credibility condition, and thus the verification fails, resulting in the verification failure result.

[0109] The verification pass result means that the transmitted data is trustworthy, that is, the transmitted data is trustworthy and the target chain can execute business logic. The verification failure result means that the trustworthiness verification of the transmitted data failed, that is, the transmitted data is untrustworthy and subsequent operations are refused.

[0110] Through the above implementation methods, the present invention can quickly verify finality certificates by using a threshold judgment method, thereby improving the verification efficiency of cross-chain data.

[0111] The present invention also provides a readable storage medium storing a computer program, which, when executed by a processor, is used to implement the methods provided in the various embodiments described above.

[0112] The readable storage medium can be a computer storage medium or a communication medium. A communication medium includes any medium that facilitates the transfer of computer programs from one location to another. A computer storage medium can be any available medium accessible to a general-purpose or special-purpose computer. For example, a readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application-Specific Integrated Circuit (ASIC). Alternatively, the ASIC can be located in a user equipment. Of course, the processor and the readable storage medium can also exist as discrete components in a communication device. The readable storage medium can be a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0113] The present invention also provides a program product including executable instructions stored in a readable storage medium. At least one processor of the device can read the executable instructions from the readable storage medium, and the at least one processor executes the executable instructions to cause the device to implement the methods provided in the various embodiments described above.

[0114] In the embodiments of the above-described device, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0115] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A data cross-chain transmission method based on multiple signature authentication, characterized in that, include: The cross-chain collection based on the message source chain updates the sending log list, obtains broadcast log data, and broadcasts it, including: Extract the key fields of each cross-chain message in the cross-chain set, perform a hash operation on the key fields, and obtain the message leaf; The number of message leaves is counted to obtain the number of new counts. The historical counts are updated based on the number of new counts to obtain the current count. The message leaf is filled into the sending log list to obtain the broadcast log list. Based on the current count and the broadcast log list, the broadcast log data is obtained. The signer set is determined based on the heterogeneous chain type of the message source chain, and checkpoints for the broadcast log data are constructed based on the signer set, including: Obtain the broadcast time corresponding to the broadcast log data, and calculate the interval duration based on the time difference between the current time and the broadcast time; When the interval duration is determined to be equal to the preset construction duration, a checkpoint is generated based on the current count of broadcast log data, the broadcast log list, the source chain address of the message source chain, the signer set, and the current time. The checkpoint is hashed to obtain the checkpoint hash, and the checkpoint hash is threshold-signed according to the set of signers to obtain the finality certificate; Based on the checkpoints and the finality certificate, the transmitted data is obtained, and message verification is performed on the target chain based on the transmitted data to obtain the verification result.

2. The method according to claim 1, characterized in that, The step of determining the signer set based on the heterogeneous chain type of the message source chain includes: When the heterogeneous chain type of the message source chain is determined to be the first definite type, the consensus audit node of the message source chain is used as a verifiable signature node; When the heterogeneous chain type is determined to be the second joint type, the organization audit nodes of each organization in the message source chain are selected based on the preset number of witnesses to obtain verifiable signature nodes; The set of signers for the corresponding message source chain is obtained by statistically analyzing the verifiable signature nodes.

3. The method according to claim 1, characterized in that, The process of hashing the checkpoint to obtain a checkpoint hash, and then performing a threshold signature on the checkpoint hash based on the set of signers to obtain a finality certificate includes: The check fields in the checkpoints are normalized and sorted to obtain a check sequence, and the check sequence is hashed to obtain the checkpoint hash; Based on the heterogeneous chain type of the message source chain, the signer set is controlled to perform threshold signing on the checkpoint hash to obtain a finality certificate.

4. The method according to claim 3, characterized in that, The step of controlling the signer set to perform threshold signing on the checkpoint hash based on the heterogeneous chain type of the message source chain to obtain a finality certificate includes: The number of verifiable signature nodes in the signer set is counted to obtain the number of verification nodes. Based on the number of verification nodes, a preset threshold form is compared to obtain the signature threshold. An initial signature bitmap is generated based on the signer set. The signer set generates node signatures based on the signature threshold and checkpoint hash. The initial signature bitmap is updated based on the node signatures to obtain the sending signature bitmap. The already signed verifiable signature nodes are taken as signed nodes, and the node signatures of the signed nodes are counted sequentially according to the signature position in the sent signature bitmap to obtain a signature list. A finality certificate is obtained based on the set address of the signer set, the signature threshold, the sent signature bitmap, and the signature list.

5. The method according to claim 4, characterized in that, The set of signers generates node signatures based on the signature threshold and checkpoint hash, including: When the heterogeneous chain type is determined to be the first definite type, each verifiable signature node verifies the checkpoint hash and generates a node signature based on the monitoring results of the message source chain; When the heterogeneous chain type is determined to be the second joint type, each verifiable signature node generates a node signature based on the cross-organization verification strategy when the number of monitoring counts is equal to the current number of counts.

6. The method according to claim 5, characterized in that, The generation of node signatures based on the cross-organizational verification strategy includes: The broadcast log lists received by each organization are used as the verification lists of the corresponding organizations. When the verification lists of each organization are consistent, the checkpoint hash is verified and a node signature is generated.

7. The method according to claim 5, characterized in that, The process of obtaining transmission data based on checkpoints and the finality certificate, performing message verification on the target chain based on the transmission data, and obtaining verification results includes: The relay layer receives the broadcast log data, extracts message leaves, and generates message proofs based on the message leaves; Based on the checkpoints, the finality certificate, and the message proof, the transmitted data is submitted to the target chain; The target chain performs data parsing on the finality certificate to obtain the set address, and retrieves the preset public key list based on the set address; The transmitted data is subjected to bitmap verification based on the preset public key list to obtain the verification result.

8. The method according to claim 7, characterized in that, The step of performing bitmap verification on the transmitted data according to the preset public key list to obtain the verification result includes: Identify the bitmap symbol of the verifiable signature node that sends the signature bitmap in the transmitted data. When the bitmap symbol is determined to be a signature symbol, compare the node signature with the verification signature at the corresponding position in the preset public key list to obtain the first verification result. When the first verification result is determined to be a match, the number of valid signatures is incremented to obtain the current number of valid signatures. When the number of currently valid signatures is greater than or equal to the signature threshold, a verification pass result is obtained; when the number of currently valid signatures is less than the signature threshold, a verification failure result is obtained. The verification result includes the verification pass result and the verification failure result.

Images