Relay cross-chain method and system applied to block chain cross-chain

Abstract

The invention discloses a relay cross-chain method and system applied to block chain cross-chain, and belongs to the technical field of block chain interoperation. The method comprises the following steps that: in an anonymous committee election stage, a candidate node performs anonymous drawing by using an anonymous verifiable random function combined with a weight and a temporary identity key; in the key generation stage, an asynchronous distributed key generation protocol is adopted, a reliable broadcast protocol is combined, and a threshold signature private key share is generated on the premise that a complete private key does not need to be reconstructed; in a cross-chain consensus stage, a committee member generates a threshold signature share containing an identity bit vector, an aggregation node encrypts the bit vector by using an accountability public key and generates a zero-knowledge proof, and a binding relationship between an identity ciphertext and an aggregation signature is constructed. According to the invention, identity privacy protection of a whole cross-chain verification process is realized, and the problem of key generation deadlock in an asynchronous network environment is solved.

Description

Technical Field

[0001] This invention belongs to the field of blockchain and cross-chain interoperability technology, specifically relating to a relay cross-chain method and system applied to blockchain cross-chain. Background Technology

[0002] With the development of blockchain technology, the "data silo" effect between different chains has become increasingly prominent, making cross-chain technology crucial for achieving interoperability. Among these, solutions based on relay chains are widely adopted due to their high degree of decentralization.

[0003] However, existing relay chain cross-chain solutions still face significant security and efficiency challenges in the cross-chain request verification process, particularly in ensuring anonymity and accountability throughout the process. Furthermore, as more blockchains join the relay chain, the number of transactions and state updates that need to be processed increases dramatically, potentially leading to system bottlenecks and decreased throughput.

[0004] In recent years, some research has attempted to address the security and efficiency issues of cross-chain communication at the consensus layer, particularly in innovation regarding validator committee election and transaction voting mechanisms. Most existing research employs consensus protocols based on verifiable random functions to elect validator committee members and utilizes threshold signatures for transaction voting. However, these schemes often struggle to achieve an effective balance between security and efficiency. For example, while some schemes achieve anonymity, their ring signature proof size increases rapidly with committee size, leading to high interactivity but low efficiency; other schemes, due to the public and fixed identities of committee members, are vulnerable to collusion attacks and distributed denial-of-service attacks. More importantly, existing schemes generally lack effective accountability mechanisms, making it difficult to promptly trace and punish negative or malicious behavior by committee participants, and they are insufficiently adaptable to asynchronous environments caused by network fluctuations. Summary of the Invention

[0005] Purpose of the invention: The purpose of this invention is to address the shortcomings of existing technologies by providing a relay cross-chain method and system for blockchain cross-chain applications, which can simultaneously achieve anonymity, asynchronous robustness, and behavioral accountability in complex network environments.

[0006] Technical solution: The relay cross-chain method applied to blockchain cross-chain as described in this invention includes the following steps:

[0007] S1: Anonymous Committee Election: Candidate nodes in the relay chain network generate temporary identity keys for the current period based on long-term identity keys, and calculate random numbers locally using anonymous verifiable random functions and weights, verifying whether they have been elected as members of the verification committee without revealing their long-term identity.

[0008] S2: Asynchronous Distributed Key Generation: Elected committee member nodes execute an asynchronous distributed key generation protocol, interact in an asynchronous network environment, and generate threshold signature private key shares and system aggregate public keys;

[0009] S3: Accountable Cross-Chain Consensus: Committee members use the threshold signature private key share to sign the received cross-chain request, generating a signature share and a bit vector indicating the participation status;

[0010] S4: Signature Aggregation and Identity Hiding: Aggregation nodes (which are one of the nodes elected by AVRF, and whose relationship with other nodes is the same as that of Follower and Leader nodes in a distributed system, and are selected through the Raft algorithm) collect signature shares that meet the threshold requirements to generate an aggregate signature. They use a preset accountability public key to encrypt the bit vector to generate identity ciphertext, and generate zero-knowledge proofs to build a binding relationship between the set of signers hidden by the identity ciphertext and the set of public keys used to generate the aggregate signature, forming a verifiable but identity-hidden cross-chain consensus message.

[0011] This invention also provides a relay cross-chain system for blockchain cross-chain applications, comprising:

[0012] Memory is used to store computer program instructions;

[0013] A processor, coupled to the memory, is configured to execute the computer program instructions to perform the functions of the following modules:

[0014] The anonymous election module is used to configure candidate nodes to generate temporary identity keys based on long-term identity keys, and to calculate random numbers locally by combining anonymous verifiable random functions and weights to verify whether they are elected as members of the verification committee.

[0015] The asynchronous key generation module is used to configure elected members to execute the asynchronous distributed key generation protocol in an asynchronous network environment, generating threshold signature private key shares and system aggregate public keys;

[0016] The accountable consensus module is used to configure committee members to sign cross-chain requests using threshold signature private key shares and generate bit vectors indicating participation status.

[0017] The aggregation and binding module is used to collect signature shares to generate an aggregated signature, use the accountability public key to encrypt the bit vector to generate identity ciphertext, and generate a zero-knowledge proof to build a binding relationship between the identity ciphertext and the aggregated signature.

[0018] Beneficial effects: Compared with the prior art, the advantages of the present invention are as follows:

[0019] This invention introduces temporary identity keys and anonymous verifiable random functions (AVRF) during the committee election phase, allowing candidate nodes to participate in the interaction directly without using long-term public keys. By associating temporary identities with long-term weights through zero-knowledge proofs, external observers cannot associate the current consensus node with the physical node or the long-term identity, thereby blocking DDoS attacks and targeted interference against the verification node at the source.

[0020] This invention employs an asynchronous distributed key generation (ADKG) scheme that combines Reliable Broadcast (RBC) and the Asynchronous Binary Byzantine Fault Tolerance (ABA) protocol. This scheme eliminates the reliance on network-wide clock synchronization, tolerates network latency fluctuations and message out-of-order delivery, and avoids the deadlock problem inherent in traditional DKG in asynchronous environments. Furthermore, by incorporating a pipelined parallel processing mechanism, the time-consuming key generation is moved to the background for asynchronous execution, significantly improving the throughput of cross-chain request processing.

[0021] By introducing an accountable threshold signature mechanism, this invention cleverly embeds encrypted bit vectors into aggregate signatures. During normal transaction processes, the specific participation of verifiers remains private; however, in the event of a malicious signature, the accountable node can use its accountability private key to decrypt the bit vector, accurately pinpoint the ID of the malicious node, and execute on-chain penalties. This mechanism protects privacy under normal circumstances while ensuring regulatory oversight in abnormal situations, solving the problem of non-attribution in traditional threshold signatures. Attached Figure Description

[0022] Figure 1 This is a diagram illustrating the overall logical architecture of a cross-chain system provided in an embodiment of the present invention.

[0023] Figure 2 This is a flowchart of the cross-chain request execution process provided in an embodiment of the present invention;

[0024] Figure 3 A schematic diagram of the pipeline parallel processing mechanism provided in an embodiment of the present invention;

[0025] Figure 4 This is a schematic diagram illustrating the specific interactions of the Anonymous Committee Election (ACE) in an embodiment of the present invention;

[0026] Figure 5 This is a schematic diagram illustrating the specific principles of accountable threshold signature and tracking in an embodiment of the present invention;

[0027] Figure 6 This is a comparison chart showing the delay of this invention's embodiment with other mainstream cross-chain solutions during the Anonymous Committee Election (ACE) phase;

[0028] Figure 7 This is a comparison chart showing the delay of this invention's embodiment with other mainstream cross-chain solutions during the Committee Consensus Voting (ACV) phase;

[0029] Figure 8 This is a comparison chart of the total latency of the entire cross-chain request process between the embodiments of the present invention and other mainstream cross-chain solutions. Detailed Implementation

[0030] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings, but the scope of protection of the present invention is not limited to the embodiments described.

[0031] Example 1: The overall logical architecture of this example includes four main parts: SourceChain, TargetChain, CrossChainGateway, and Relay-Chain, which serves as the core trust intermediary.

[0032] (1) SourceChain: The source chain is the initiator of cross-chain requests, and is usually a blockchain network with an independent consensus mechanism. Specific smart contracts or scripts are deployed on the source chain to lock the user's state.

[0033] (2) TargetChain: The target chain is the receiving end of cross-chain requests and is also an independent blockchain network. Release contracts are deployed on the target chain.

[0034] (3) CrossChainGateway: A cross-chain gateway is a communication bridge connecting heterogeneous blockchains and relay chains, responsible for listening, format conversion, and message routing. In this embodiment, the cross-chain gateway can be composed of a group of decentralized nodes or relayers.

[0035] (4) Relay Chain: The relay chain is a core component of this invention. It is an independent blockchain network that supports smart contracts and maintains the security of cross-chain requests through a special consensus mechanism. For example... Figure 1 As shown in the middle section, the roles of participants in the relay chain include:

[0036] Candidate: A regular node in the relay chain network that gains the qualification to participate in the election of the validation committee by locking weight (Staking). The candidate pool constitutes the underlying security foundation of the system.

[0037] Committee: A group of validator nodes elected from candidates using an anonymous random algorithm. Committee members are responsible for performing the specific tasks of cross-chain request verification and signing. To ensure security, committee members remain anonymous during the election and voting process.

[0038] Consensus Layer: Responsible for achieving consensus on cross-chain messages. This embodiment uses a consensus mechanism based on threshold signatures.

[0039] Table 1: Symbols used in this invention and their corresponding meanings

[0040]

[0041] like Figure 2 As shown, this embodiment details the complete nine-step process (Steps 1-9) of a cross-chain transfer transaction from initiation to completion.

[0042] Step 1 (Transaction Initiation): Source Chain User ( The user initiates a cross-chain request. The user invokes the locking smart contract on the source chain through the client. The target chain identifier (TargetChainID), target receiving address (ReceiveAddress), and transfer data are passed in.

[0043] Step 2 (StateLocking): Lock the smart contract Upon receiving the request, verify whether the user's data quota / credit score is sufficient. Once verification is successful, the contract will transfer the user's data. v units of numerical / data objects are transferred to a lock address controlled by the contract (LockAddress).

[0044] Step 3 (EventCapture): The cross-chain gateway on the source chain listens for the CrossChainLock event through a full node interface (such as RPC / WebSocket). The gateway extracts the transaction credential and requests the source chain to generate a proof of the transaction's existence (such as MerkleProof or SPVProof).

[0045] Step 4 (Request Relaying): The cross-chain gateway encapsulates the collected transaction information and existence proofs into a "Cross-Chain Proposal" and submits it to the relay chain's receiving interface. / GatewayInterface).

[0046] Step 5 (Committee Verification): The current session of the relay chain's verification committee receives the cross-chain proposal. Committee member nodes execute the verification logic: verifying the validity of the source chain proof (e.g., verifying whether MerkleRoot is in the known block header).

[0047] Step 6 (Instruction Delivery): The cross-chain gateway on the target chain listens for the cross-chain instruction confirmed by the relay chain and forwards it to the generation contract on the target chain. ).

[0048] Step 7 (StateMapping): Contract execution on-chain verification: Verifies whether the aggregate signature was generated by the currently valid relay chain committee public key (CommitteePublicKey). This public key is typically pre-set or updated in the target chain contract via a light client synchronization mechanism. Upon successful verification, the contract triggers the generation function, sending the signature to user B (…). The receiving address (ReceiveAddress) generates mapping data / state credentials corresponding to the locked data from the source. At this point, the cross-chain request is logically completed, and user B successfully receives the target data.

[0049] Step 8 (Committee Voting & Consensus): Note: Figure 2 The steps are numbered in logical order, with step 8 occurring in the data processing phase following step 5. After successful verification, committee members proceed to the Accountable Committee (ACV) voting phase.

[0050] Step 9 (StateUpdate): The relay chain packages the consensus-reached cross-chain instructions (including aggregate signatures) into a new block, updates the global state of the relay chain, and prepares to send them to the target chain through the relay chain gateway.

[0051] like Figure 3 As shown, in order to solve the problem of time-consuming key generation in asynchronous network environments and improve system throughput, this embodiment adopts a pipeline mechanism.

[0052] Block B1 (Epoch0): System startup, execution of initial ACE and ADKG.

[0053] Block B2 (Epochi): ACV Layer: 1 The committee is currently processing the current cross-chain request (green module). ACE / ADKG layer: Meanwhile, the system is undergoing its first... The election of the committee (yellow module) and key generation (blue module).

[0054] Block B3 (Epochi+1): ACV layer: 1st Upon taking office, the committee will use the keys generated in phase B2 to process transactions. ACE / ADKG layer: Preparations for the next phase begin in the background. The committee.

[0055] Through this staggered execution, the first The committee at the Key construction was completed by the end of the cycle, enabling seamless switching and significantly reducing cross-chain latency.

[0056] Example 2: To prevent malicious attackers from launching targeted attacks (such as DDoS or interference) on the verification node, this example introduces an election mechanism based on Anonymous Verifiable Random Function (AnonymousVRF).

[0057] System initialization: The system first defines security parameters. (For example, λ=128), the generation algorithm is executed according to the security parameter λ. Output the following public parameters (PP): , It should be a large prime number with at least 256 digits; : These are the elliptic curve groups defined on the domain; There is a root domain Multiplicative subgroups; : are groups and The canonical generators; It is a bilinear mapping group system.

[0058] S1: Cross-chain system initialization and anonymous committee election (ACE) phase

[0059] S1.1 Node Identity Initialization

[0060] Define a way to map messages of arbitrary length to a group Hash function on: Selecting group generators and collision-resistant hash functions Each relay chain candidate node Generate long-term identity public / private key pairs .

[0061] S1.2 Temporary Anonymous Identity Generation

[0062] Before each round of elections begins, each candidate node Random selection of randomization factor Calculate the temporary public key used in this round of elections. : , ,in It is the public key component corresponding to the node's long-term private key. It is a randomly selected random factor. Temporary public key Used for subsequent communication and verification, making it impossible for external observers to... With long-term public keys To establish associations and thus hide nodes His true identity.

[0063] S1.3 Random Number Certificate Generation and Broadcasting

[0064] Candidate Nodes Based on the Anonymous Verifiable Random Function (AVRF), it utilizes a long-term private key and a temporary public key. Calculate pseudo-random numbers from the common input of the current epoch (including the hash or height of the previous block). :

[0065]

[0066]

[0067] in The hash function is mapped onto the group; simultaneously, nodes generate non-interactive zero-knowledge proofs using the Chaum-Pedersen protocol. Prove that it satisfies the discrete logarithm equality relation without revealing the long-term private key:

[0068]

[0069] Nodes broadcast tuples to the entire network .

[0070] S1.4 Weighted Local Election Decision

[0071] Candidate nodes are selected based on the total locked weight W of the entire network and their own locked weight. and the calculated random number The local node runs a probabilistic verification algorithm to determine whether it has been elected as a member of the verification committee and the weight of the votes it received (j). Only elected nodes need to broadcast their election proof to the network. Specific steps:

[0072] Candidate nodes retrieve the weight stake information of all candidate nodes from the distributed database and calculate the total weight value of the entire network. and its own weight value Set the target committee size n, and calculate the base probability of election per unit weight. ;

[0073] To ensure that the probability of a candidate being selected is proportional to its weight, the Algorand encryption sorting algorithm is used. Probability verification is performed locally to determine if the following inequality is satisfied:

[0074] The weight of candidate i is The total weight of all candidates is Probability of being selected per unit weight Then candidate i The probability of selecting k units of a component weight follows a binomial distribution.

[0075]

[0076] To determine the number of specific sub-weights selected from the weights of candidate i, the Algorand algorithm divides the interval... Divided into a series of forms (in If the following formula is satisfied:

[0077]

[0078] This allows us to determine how many sub-weights candidate i was selected, thus ensuring that the larger the weight, the greater the probability of being selected.

[0079] in, random numbers The binary length, It is the binomial probability mass function.

[0080] If the calculation yields If so, the node is determined to be elected as a committee member and possesses [certain rights / status]. Voting weights; nodes publicly disclose their calculation results. Other validators perform repeated verifications, thus completing decentralized elections without exposing the node's true identity or long-term identity binding.

[0081] S2. Consensus Key Construction (ADKG) Phase Based on Asynchronous Distributed Key Generation

[0082] The elected n anonymous committee members collaboratively generate threshold signature private keys through an asynchronous network, without reconstructing the complete private key during the process.

[0083] S2.1 Asynchronous Secret Sharing

[0084] The elected committee members, acting as sharers, randomly select a t-th degree secret polynomial using the Asynchronous Verifiable Secret Sharing (ACSS) scheme. Calculations for other members secret share Encrypt and send to other members Simultaneously, the Pedersen commitment of the broadcast polynomial coefficients.

[0085] Each member As the distributor (Dealer), randomly select a secret value. And construct a random polynomial of degree t: ;

[0086] Calculate the corresponding Pedersen commitment vector: And broadcast the commitment.

[0087] Share distribution: Nodes distribute shares to each of the other members. Calculate the secret share: and through an encrypted channel Send to .

[0088] S2.2 Asynchronous Acknowledgment Based on Reliable Broadcast

[0089] Members use the Reliable Broadcast (RBC) protocol to interact and confirm the validity of the received secret shares, ensuring that all honest nodes receive consistent messages in an asynchronous network environment. Then, the Asynchronous Binary Byzantine Fault Tolerance (ABA) protocol is used to reach a consensus on the set of valid shares, and the final set of nodes T participating in key construction is determined, where |T| ≥ t + 1.

[0090] Reliable Broadcast (RBC): A node initiates a reliable broadcast protocol to transmit commitments and encrypted shares. In an asynchronous network environment, when a node... Received from About different nodes When the ECHO message of the proposal is received, the READY message is broadcast. Upon receiving a READY message, confirm that a valid secret sharing instance has been received, and... Add to the local "set of valid suggestions".

[0091] Asynchronous Binary Byzantine Protocol (ABA): Nodes run the asynchronous binary Byzantine protocol (ABA) to reach a consensus on "which members contributed valid secret shares" and finally output a public set T containing at least t+1 member indices.

[0092] S2.3 Threshold Private Key Share Derivation

[0093] Once the set is determined, each member, based on the information in set T, locally aggregates and calculates the private key share required for the gate signature. And the corresponding aggregated public key TPK, to complete the distributed key generation, without reconstructing the complete private key during the process.

[0094] Each node Calculate its final private key share : ;

[0095] Global aggregate public key of computing system : .

[0096] S3. Cross-Chain Request Consensus and Accountable Signature (ACV) Phase

[0097] S3.1 Cross-chain event listening and encapsulation

[0098] Relay chain nodes listen for data locking or cross-chain information events on the source chain through the cross-chain gateway, obtain source chain transaction credentials, and encapsulate them into a standard cross-chain request m.

[0099] S3.2 Threshold Signature Share Generation

[0100] For cross-chain request messages Committee members Utilizing its unique threshold private key share Calculate BLS signature shares : Members will Send to the aggregator.

[0101] S3.3 Signature Aggregation, Blinding, and Bit Vector Encryption

[0102] like Figure 5 As shown, signer Regarding the message Perform BLS signing and generate Simultaneously, the signer generates a "bitvector" indicating their participation in the signing and uses the accountability public key. The information is encrypted using ElGamal. The aggregator verifies and aggregates at least t+1 valid signature shares to generate an aggregated signature σ.

[0103] Signature Share Verification and Aggregation: The aggregator verifies the collected signature shares and filters out the valid signature set. (satisfy ); Calculate aggregate signature : At this point, verification can be performed. To determine aggregate signature The effectiveness.

[0104] Bit vector construction: Construct a bit vector of length... Participant bit vector If node ,but ,otherwise .

[0105] Bit-vector encryption: using the public key of the signatory accountant. For vectors Perform El-Gamal encryption, which involves selecting a random value. Then perform the following calculations: , where vector It is a vector The encrypted ciphertext.

[0106] A random blinding factor is introduced to hide the aggregate signature σ and the corresponding signature verification public key;

[0107] Select a random value Calculate the blinded aggregated public key: ;

[0108] Compute blinded aggregate signature: .

[0109] At this point, it becomes verified. To determine aggregate signature The effectiveness.

[0110] Simultaneously generate zero-knowledge proofs Proof of ciphertext The corresponding plaintext vector With generating aggregate signatures The subset of public keys used is consistent.

[0111]

[0112] in, This is a mapping that encodes bit vectors onto group elements.

[0113] Final signature data: Generates complete and accountable aggregate signature data. .

[0114] The verifier receives the data packet ( The verifier first verifies... Is it a valid threshold signature? Next, verify... Is it correct? If both pass, then the cross-chain message is accepted. At this point, the validator does not know the specific list of signers (who are...). hide).

[0115] When a verified cross-chain message is discovered If the act is actually malicious, initiate an accountability process: the victim will include... The evidence is submitted to the tracker or a public arbitration tribunal. The tracker uses its private key. Decryption The decryption result will reconstruct a bit vector (e.g., ... The node corresponding to the position marked 1 is the signer who participated in malicious activity. Based on the decryption result, the smart contract automatically forfeits the locked deposit of these malicious nodes.

[0116] The validator calculates the temporary aggregate public key. : Verify aggregate signature The validity of the equation is determined by checking whether the bilinear equality holds.

[0117] Simultaneously verify zero-knowledge proofs The effectiveness of ensuring It is ciphertext The hidden identity vector was correctly constructed.

[0118] S3.4 Transaction Verification and On-Chain Execution

[0119] The verification nodes of the relay chain use the aggregated public key and blinding parameters to verify the validity of the signature σ. If the verification passes, they perform data generation or release operations.

[0120] Verify aggregate signature The validity of the equation is determined by checking whether the bilinear equality holds. ;

[0121] Simultaneously verify zero-knowledge proofs The effectiveness of ensuring It is ciphertext The hidden identity vector is correctly constructed if the equation holds and it is proven. If valid, the cross-chain request is confirmed as legitimate, and data transfer or release is executed.

[0122] S4. Malicious Behavior Tracking and Accountability Phase

[0123] S4.1 Anomaly Detection and Evidence Submission

[0124] When a double signature, invalid transaction signature, or consensus conflict occurs at the same height in the network, the challenger node constructs a fraud proof and submits it to the accountability contract.

[0125] Specific scenarios: malicious signature behavior; receiving fraudulent evidence against a certain aggregated signature.

[0126] S4.2 Identity Tracking and Penalties

[0127] The accountability node reconstructs the accountability private key through multi-party computation (MPC) and uses the accountability private key. The generated ciphertext Decrypt; for each component in the ciphertext ,calculate: This allows us to recover the participant's bit vector. Identify the set of all nodes involved in generating the malicious aggregate signature. ;

[0128] Smart contracts based on the reconstructed set Automatic penalty is applied: if a signature is determined to be malicious (e.g., signing a conflicting transaction), no valid signature is collected. All weights locked by all nodes in step S1; if a liveness fault is determined, then the weights of nodes that did not participate in the signing ( A minor economic penalty will be imposed; at the same time, the long-term public key of the malicious node will be... They will be blacklisted by the system and permanently disqualified from participating in subsequent cycle committee elections.

[0129] Example 2: To verify the performance and scalability of the relay cross-chain system proposed in this invention in a real network environment, this example constructs a complete test environment and performs a full-process simulation of the core protocol components of this invention—Anonymous Committee Election (ACE), Asynchronous Distributed Key Generation (ADKG), and Accountable Committee Voting (ACV). It is also compared with current mainstream cross-chain solutions (including the Bool Network solution based on ring signatures and the Sidechains-OSP solution based on fixed dual committees).

[0130] 1. Experimental Environment and Parameter Settings The simulation program in this embodiment is written in Java 11 and relies on the Apache Milagro cryptography library (AMCL) to implement the underlying bilinear pairing and elliptic curve operations. The elliptic curve used in the experiment is BLS12-381, which provides a 128-bit security level and conforms to the current general security standards for blockchain systems.

[0131] Hardware configuration: The test host machine runs the Windows 11 operating system and is equipped with an Intel® Core™ i7-12700 processor (2.10GHz) and 16.0GB of physical memory.

[0132] Network Environment Simulation: To closely simulate real-world wide area network (WAN) cross-chain scenarios, this experiment utilizes Java's JUC (Java Util Concurrent) concurrency framework to simulate a multi-node environment. The experiment introduces a uniformly distributed random network latency, with a latency range set between [5ms, 40ms], to simulate communication jitter and transmission time between distributed nodes.

[0133] Transaction parameters: The standard cross-chain request size is set to 256 bytes, and SHA-256 is used as the hash function in the test.

[0134] Testing method: For the case where the size of the verification committee is gradually expanded from 3 nodes to 20 nodes, 100 independent repeated experiments were conducted for each scheme, and the average running time was taken as the final evaluation index.

[0135] 2. To verify the performance, scalability, and advantages of the proposed "3A Relay" cross-chain relay system in a real-world network environment, this embodiment constructs a complete simulation test environment. The test selects two mainstream cross-chain schemes as comparative examples: the Bool Network scheme based on ring signature technology, and the Sidechains-OSP scheme based on a fixed committee mechanism.

[0136] The experiment focused on examining how latency varied across different processing stages and the overall workflow as network size (number of candidate nodes and committee members) increased. Experimental results are as follows: Figures 6 to 8 As shown.

[0137] Performance in small-scale networks: In the initial stage with a small number of verification nodes (e.g., 3 nodes), the cross-chain system of this invention demonstrates performance advantages. Experimental data shows that the total latency of this invention is reduced by approximately 28 milliseconds compared to the Sidechains-OSP solution (performance improvement of approximately 11.07%), and by approximately 12 milliseconds compared to the Bool Network solution (performance improvement of approximately 5.06%). This indicates that even in lightweight networks, the anonymity and asynchronous mechanisms of this invention do not incur additional performance overhead.

[0138] Scalability advantages in large-scale networks: As the size of the verification committee increases (from 3 nodes to 20 nodes), the latency of existing technical solutions exhibits a steep linear growth trend.

[0139] The Sidechains-OSP scheme, due to its reliance on synchronous communication and the large number of dot product operations involved in the signature aggregation phase, experiences a significant increase in execution time with the number of nodes. From 3 nodes to 20 nodes, the execution time increases by 533 milliseconds.

[0140] The Bool Network scheme is limited by the computational complexity of ring signature verification (which is usually linear or higher order with the number of nodes), increasing its processing time by 488 milliseconds.

[0141] Thanks to the pipeline parallel processing mechanism, this invention moves the time-consuming Committee Election (ACE) and Distributed Key Generation (ADKG) stages to the background for asynchronous execution, freeing the current transaction verification (ACV) from the cumbersome key switching process. Experimental results show that, at the same scaling scale, the total execution time of this invention only increases by 416 milliseconds, and the total execution time with 20 nodes is 145 milliseconds faster than the Sidechains-OSP scheme (the relative performance advantage expands to 18.5%).

[0142] Reduced algorithm complexity: Existing technologies (such as Bool Network) typically rely on computationally expensive ring signature verification, where the number of bilinear pairing operations required for verification increases linearly with the number of nodes. In contrast, the threshold signature scheme used in this invention requires a constant number of pairing operations for verification, which does not significantly increase with the size of the committee.

[0143] Communication mechanism optimization: The asynchronous distributed key generation (ADKG) introduced in this invention eliminates the dependence on network-wide clock synchronization. Combined with pipelined design, it effectively masks the latency costs caused by network interaction.

[0144] Therefore, the decryption and verification time of this invention is insensitive to the expansion of node scale, proving that this solution has better practicality, robustness and scalability in supporting large-scale, high-concurrency cross-chain applications.

[0145] Privacy Protection Notice of this Invention: Considering the identity security of validator nodes and the attack resistance of consensus in the cross-chain relay network, data interaction flows from candidate nodes in the relay chain to the entire consensus network. On the Anonymous Committee Election (ACE) side, candidate nodes cannot directly use their long-term identity public keys to participate in the election. Instead, they generate one-time temporary public keys and combine them with an Anonymous Verifiable Random Function (AVRF) to generate random credentials. This prevents external attackers from associating the current consensus node with the real physical node IP or long-term identity, blocking distributed denial-of-service (DDoS) attacks and targeted interference against specific validators at the source.

[0146] For the verification committee, because the messages transmitted during the Asynchronous Distributed Key Generation (ADKG) phase contain sensitive private key shares, and the network environment may have asynchronous delays, this invention employs a non-interactive secret sharing and encrypted channel for transmission. Committee members only calculate and hold private key shares locally and do not have the ability to decrypt the complete system private key. Only the multinomial commitment and encrypted shares are transmitted over the network; therefore, the privacy of the system master key is protected, and even if some nodes are compromised, the complete signing private key cannot be recovered.

[0147] For the supervision and accountability of cross-chain requests, this invention employs Accountable Threshold Signature (ACV) technology to ensure "conditional privacy" during the voting process. In normal transaction flows, by introducing a blinding factor and aggregate signature technology, the identity vectors of participating nodes are hidden within the ciphertext. External parties cannot directly determine which nodes voted in favor from the aggregate signature. Only when malicious transactions are detected (such as duplicate execution or state conflicts) can the accountable node decrypt the identity vector using its accountability private key, accurately locating the malicious node. This achieves both identity privacy protection under normal circumstances and precise accountability control under abnormal conditions.

[0148] As described above, although the invention has been shown and described with reference to specific preferred embodiments, it should not be construed as limiting the invention itself. Various changes in form and detail may be made without departing from the spirit and scope of the invention as defined in the appended claims.

Claims

1. A relay cross-chain method applied to blockchain cross-chain, characterized in that, Includes the following steps: S1: Anonymous Committee Election: Candidate nodes in the relay chain network generate temporary identity keys for the current period based on long-term identity keys, and calculate random numbers locally using anonymous verifiable random functions and weights, verifying whether they have been elected as members of the verification committee without revealing their long-term identity. S2: Asynchronous Distributed Key Generation: Elected committee member nodes execute an asynchronous distributed key generation protocol, interact in an asynchronous network environment, and generate threshold signature private key shares and system aggregate public keys; S3: Accountable Cross-Chain Consensus: Committee members use the threshold signature private key share to sign the received cross-chain request, generating a signature share and a bit vector indicating the participation status; S4: Signature Aggregation and Identity Hiding: Aggregation nodes are elected through a distributed consensus algorithm, and signature shares that meet the threshold requirements are collected to generate an aggregate signature. The bit vector is encrypted using a preset accountability public key to generate identity ciphertext, and zero-knowledge proofs are generated to establish a binding relationship between the set of signers hidden by the identity ciphertext and the set of public keys used to generate the aggregate signature, forming a verifiable but identity-hidden cross-chain consensus message.

2. The relay cross-chain method applied to blockchain cross-chain as described in claim 1, characterized in that, In the anonymous committee election, candidate nodes generate temporary identity keys including: Constructing a bilinear mapping group system Selecting group generators ; Define a way to map messages of arbitrary length to a group Hash function on: ; Candidate Nodes Holding a long-term private key and long-term public keys , ; Candidate Nodes Selecting randomization factors Calculate the temporary public key ,in , Generating non-interactive zero-knowledge proofs using the Chaum-Pedersen protocol .

3. The relay cross-chain method applied to blockchain cross-chain as described in claim 2, characterized in that, In the anonymous committee election, the verification of whether a candidate node has been elected includes: Get the common input for the current period And mapped to group elements ; Calculating pseudo-random numbers using anonymous verifiable random functions and generate proof Zero-knowledge proof; Obtain the total weight of the entire network Self-weight and the size of the target committee Calculate the probability of being elected per unit weight ; Using the random number binary length and binomial distribution probability mass function Determine if an integer exists. The following inequalities must be satisfied: ， If the calculated number of sub-weights for a candidate is... If so, the node is determined to be elected and obtains [the necessary benefits]. Voting weight.

4. The relay cross-chain method applied to blockchain cross-chain as described in claim 1, characterized in that, The asynchronous distributed key generation step specifically includes: S2.1 Asynchronous Secret Sharing: Elected Committee Members As a distributor, I randomly select a secret value using an asynchronous verifiable secret sharing scheme. And build polynomial of degree For each of the other members Calculate the secret share It is transmitted in encrypted form, and simultaneously broadcasts the Pedersen commitments for the polynomial coefficients. ; S2.2 Consensus Confirmation: Members interact via a reliable broadcast protocol to confirm the validity of received secret shares, and run an asynchronous binary Byzantine protocol to determine the set of members with valid contribution shares. ,in ; S2.3 Share Derivation: Each member is based on a set Local aggregation computes its own threshold private key share and system aggregated public key : , ,in For members The commitment constant of broadcasting.

5. The relay cross-chain method applied to blockchain cross-chain as described in claim 1, characterized in that, In the accountable cross-chain consensus, the specific formula for generating signature shares is as follows: for cross-chain request messages... Committee members Use private key share Calculate BLS signature shares : ,in To map messages to the group The hash function.

6. The relay cross-chain method applied to blockchain cross-chain as described in claim 1, characterized in that, The construction of the binding relationship in the signature aggregation and identity concealment steps specifically includes: Aggregate nodes construct bit vectors For nodes participating in the signing ,make ,otherwise ; Using system accountability public keys and random numbers ElGamal encryption is applied to the bit vector components to generate the identity ciphertext. For each component in the ciphertext ; Verification nodes calculate temporary aggregate public keys And verify whether the bilinear equivalence holds to confirm the aggregate signature. Validity: Simultaneously verify zero-knowledge proofs Ensure It is ciphertext The hidden identity vector was correctly constructed.

7. The relay cross-chain method applied to blockchain cross-chain as described in claim 6, characterized in that, It also includes steps for tracking and holding accountable malicious behavior: When double signatures or invalid transaction signatures for the same block height are detected, the accountable node submits evidence of fraud including the aggregate signature, identity ciphertext, and the zero-knowledge proof. The identity ciphertext is decrypted using the accountability private key corresponding to the accountability public key, and the bit vector of the node participating in the signature is restored, thereby locating the long-term identity ID of the malicious node. Based on the location results, the smart contract automatically executes penalty operations such as confiscating the weight of malicious nodes and removing their committee qualifications.

8. The relay cross-chain method applied to blockchain cross-chain as described in claim 1, characterized in that, The method employs a pipelined parallel processing mechanism: While the relay chain processes the cross-chain request consensus step in the i-th cycle, when the block height of the i-th cycle reaches the preset election trigger threshold, the anonymous committee election step and asynchronous distributed key generation step for the i+1-th cycle are started in parallel in the background, so that the consensus key of the i+1-th committee is completed before the end of the i-th cycle.

9. A relay cross-chain system applied to blockchain cross-chain, characterized in that, include: Memory is used to store computer program instructions; A processor, coupled to the memory, is configured to execute the computer program instructions to perform the functions of the following modules: The anonymous election module is used to configure candidate nodes to generate temporary identity keys based on long-term identity keys, and to calculate random numbers locally by combining anonymous verifiable random functions and weights to verify whether they are elected as members of the verification committee. The asynchronous key generation module is used to configure elected members to execute the asynchronous distributed key generation protocol in an asynchronous network environment, generating threshold signature private key shares and system aggregate public keys; The accountable consensus module is used to configure committee members to sign cross-chain requests using threshold signature private key shares and generate bit vectors indicating participation status. The aggregation and binding module is used to collect signature shares to generate an aggregated signature, use the accountability public key to encrypt the bit vector to generate identity ciphertext, and generate a zero-knowledge proof to build a binding relationship between the identity ciphertext and the aggregated signature.

Images