BFT-based block chain consensus method and system

Abstract

The invention relates to a BFT-based block chain consensus method and system. In the scheme, a main node detects a node change transaction, generates a view lock and broadcasts the view lock to all consensus nodes, and each consensus node generates a new private key fragment and a new public key vector in a reconstruction window; the main node generates a new view according to the new public key vector and broadcasts the new view to each consensus node, each consensus node sends a threshold signature to the main node after verifying the new private key fragment according to the new view, and the main node generates an aggregation signature according to a predetermined number of threshold signatures and generates a new block according to the aggregation signature and the new view; and after submission is confirmed through a consensus process, a node list is updated, and node reconstruction is completed. Therefore, when the main chain detects the node change transaction, the rotation of the secret key and the reconstruction of the node can be completed in the reconstruction window, so that the member reconstruction can be safely carried out on the premise of not stopping the machine; moreover, the public and private keys can be updated when the members change, and the security of the keys is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchains, and in particular to a BFT-based blockchain consensus method and system. BACKGROUND

[0002] Byzantine Fault Tolerance (BFT) is a fault-tolerant technology in the field of distributed computing. Existing Byzantine fault-tolerant blockchains mostly assume that the "member set is static and unchangeable", and once a node needs to be added or deleted or a cross-chain ecosystem wants to access, the chain has to be stopped for upgrading or rely on off-chain governance voting, which cannot meet the flexible expansion and contraction of the production environment.

[0003] PBFT (Practical Byzantine Fault Tolerance), Tendermint, HotStuff and their commercial variants are mainstream solutions to solve Byzantine consensus, but their "epoch (time interval) = member set" assumption is too rigid. When the members change, such as when a new node joins or an existing node exits, off-chain governance or manual downtime upgrade is needed, which cannot meet the flexible expansion and contraction of the production environment; and the threshold public and private keys are usually manually issued by operation scripts, lacking automated management processes, which leaves security risks of key sharing / expiry.

[0004] Therefore, how to automatically implement member reconstruction and improve key security is a problem to be solved by those skilled in the art. SUMMARY

[0005] The present application provides a BFT-based blockchain consensus method and system to automatically implement member reconstruction and improve key security.

[0006] In a first aspect, the present application provides a BFT-based blockchain consensus method, comprising: If a master node of a main chain detects a node change transaction, it generates a view lock and broadcasts the view lock to all consensus nodes of the main chain; wherein each consensus node opens a reconstruction window according to the view lock, and in the reconstruction window, generates a new private key shard and a new public key vector for each node according to a distributed key generation protocol; The master node generates a new view according to the generated new public key vector and broadcasts the new view to each consensus node; wherein each consensus node verifies the new private key shard generated by the node according to the new public key vector of the new view, and sends a threshold signature to the master node after the new private key shard is verified; The main node receives a predetermined number of threshold signatures, generates an aggregated signature according to each threshold signature, generates a new block according to the aggregated signature and the new view, updates the node list after confirming the submission through a consensus process, and completes the reconstruction of the node.

[0007] Optionally, the blockchain consensus method further comprises: The main node receives a registration transaction structure sent by the multi-chain gateway; wherein, the generation process of the registration transaction structure comprises: the multi-chain gateway receives a registration request of a business sub-chain, verifies a chain description block carried by the registration request, generates a new root hash of a Merkle-DAG if the verification is successful, and generates a registration transaction structure based on the new root hash; The main node confirms the registration transaction structure through a consensus process; wherein, after the registration transaction structure is confirmed, the multi-chain gateway distributes the business sub-chain to a corresponding target chain group and updates a routing table; wherein, after the chain group arranger receives a legal cross-chain call, the cross-chain call is forwarded to a target sub-chain through the routing table.

[0008] Optionally, before generating the view lock, the blockchain consensus method further comprises: If the node change transaction is a node joining transaction, the main node determines a newly added target node according to the node change transaction and performs identity verification on the target node; if the verification is successful, the step of generating the view lock is executed.

[0009] Optionally, after updating the node list, the blockchain consensus method further comprises: If the node change transaction is a node joining transaction, the newly added target node obtains a snapshot file and a Merkle proof from any healthy node of the main chain, and restores the snapshot file to a local key-value database after the target node successfully verifies the Merkle proof.

[0010] Optionally, the consensus process executed by the main node comprises: The main node extracts at least one transaction from a memory pool; wherein, the transaction comprises a confirmation transaction of the new block and / or a registration transaction of the registration transaction structure; The main node calculates the digest value of each transaction, generates an aggregated message authentication code after splicing the digest values, generates a PPREQ message according to the aggregated message authentication code and sends it to each consensus node; wherein, each consensus node verifies the aggregated message authentication code of the PPREQ message after receiving the PPREQ message, generates a first local signature of the transaction batch hash if the verification is passed, and sends the first local signature to the main node through a PREP message; The master node aggregates the first partial signatures into an aggregated prepared signature after receiving a predetermined number of first partial signatures, and broadcasts the aggregated prepared signature to each consensus node; wherein each consensus node generates a second partial signature of a transaction batch hash after passing the verification of the received aggregated prepared signature, and sends the second partial signature to the master node through a COMM message; The master node aggregates the second partial signatures into an aggregated committed signature after receiving a predetermined number of second partial signatures, and generates a corresponding block; the block includes a block header and a block body, and each consensus node verifies the block header to determine that the block is a valid block.

[0011] Optionally, the process of generating the PPREQ message by the master node includes: The master node generates an output value and a verifiable proof according to the current view number, the current batch sequence number, the transaction batch hash, and a private key of a verifiable random function; The output value, the verifiable proof, and the aggregated message authentication code are used to generate a PPREQ message; wherein each consensus node receives the PPREQ message, verifies the verifiable proof through the public key of the verifiable random function, and stores the output value to a local entropy pool if the verification is passed.

[0012] Optionally, the blockchain consensus method further includes: If the consensus node of the main chain detects that the change master condition is met, the target output value of the last round of consensus process is obtained from the local entropy pool, the preliminary selected node is determined according to the target output value, and the new view request is sent to other consensus nodes of the main chain; If each consensus node receives the new view request, obtains the target output value from the local entropy pool, and determines that the preliminary selected node is the new master node when the preliminary selected node is consistent with the preliminary selected node of the new view request, and enters a new view.

[0013] In a second aspect, the present application provides a BFT-based blockchain consensus system, which includes: The master node and each consensus node of the main chain; The master node is configured to generate a view lock when detecting a node change transaction, and broadcast the view lock to all consensus nodes of the main chain; each consensus node is configured to open a reconstruction window according to the view lock, and generate a new private key shard and a new public key vector of each consensus node according to a distributed key generation protocol in the reconstruction window; The master node is further configured to generate a new view according to the generated new public key vector, and broadcast the new view to each consensus node; each consensus node is configured to verify a new private key slice generated by the node according to the new public key vector of the new view, and send a threshold signature to the master node after the new private key slice is verified. The master node is further configured to receive a predetermined number of threshold signatures, generate an aggregated signature according to each threshold signature, generate a new block according to the aggregated signature and the new view, and update a node list after the new block is confirmed by a consensus process, to complete reconstruction of the nodes.

[0014] Optionally, the system further comprises: The business sub-chain is configured to send a registration request to the multi-chain gateway. The multi-chain gateway is configured to receive the registration request, verify a chain description block carried by the registration request, generate a new root hash of a Merkle-DAG if the verification is successful, and generate a registration transaction structure based on the new root hash. The master node is configured to receive the registration transaction structure sent by the multi-chain gateway, and confirm the registration transaction structure by a consensus process. The multi-chain gateway is further configured to assign the business sub-chain to a corresponding target chain group and update a routing table after the registration transaction structure is confirmed. The chain group orchestrator is configured to forward the cross-chain call to a target sub-chain through the routing table after receiving a legal cross-chain call.

[0015] Optionally, the chain group orchestrator is specifically configured to: receive a cross-chain call, determine whether a target sub-chain of the cross-chain call is a legal registered sub-chain, establish a session tunnel with the target sub-chain if the target sub-chain is a legal registered sub-chain and the cross-chain call has the authority to call the target sub-chain, send payload data of the cross-chain call to the target sub-chain through the session tunnel, and send performance index data corresponding to the cross-chain call to Prometheus.

[0016] Compared with the prior art, the technical scheme provided by the embodiments of the present application has the following advantages: the present application provides a blockchain consensus method and system based on BFT; in the present scheme, if the master node of the main chain detects a node change transaction, a view lock is generated and broadcast to all consensus nodes of the main chain, each consensus node opens a reconstruction window according to the view lock, and generates a new private key fragment and a new public key vector of each consensus node in the reconstruction window; the master node generates a new view according to the generated new public key vector, and broadcasts the new view to each consensus node, each consensus node sends a threshold signature to the master node after the new private key fragment is verified according to the new public key vector of the new view, and the master node generates an aggregated signature according to the threshold signature after receiving a predetermined number of threshold signatures, and generates a new block according to the aggregated signature and the new view, and updates the node list after confirming the submission through the consensus process, and completes the reconstruction of the node. It can be seen that in the present application, the master chain can complete the rotation of the key and the reconstruction of the node in the reconstruction window when detecting a node change transaction, so as to safely perform member reconstruction under the premise of no shutdown; and the method can update the public and private keys when the members change, thereby improving the security of the key. BRIEF DESCRIPTION OF DRAWINGS

[0017] The accompanying drawings, which are incorporated into and form a part of the specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the application.

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced as follows: obviously, for those skilled in the art, other drawings can also be obtained without creative labor based on these drawings.

[0019] One or more embodiments are exemplarily illustrated by pictures in the drawings corresponding thereto, and these exemplary illustrations do not constitute a limitation on the embodiments, elements with the same reference numerals in the drawings represent similar elements, unless otherwise specified, and the drawings in the drawings do not constitute a proportional limitation.

[0020] Figure 1 A flowchart of a blockchain consensus method based on BFT provided by the embodiments of the present application is shown in the figure; Figure 2 A specific consensus system architecture provided by the embodiments of the present application is shown in the figure. DETAILED DESCRIPTION

[0021] To make the objects, technical solutions and advantages of the embodiments of the present application clearer, the following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work belong to the scope of protection of the present application.

[0022] The following disclosure provides many different embodiments or examples for implementing different structures of the present application. For simplicity of the present application, the components and settings of specific examples are described in the following. Of course, they are only examples, and the purpose is not to limit the present application. In addition, the present application can repeatedly refer to numbers and / or letters in different examples. Such repetition is for the purpose of simplification and clarity, and does not indicate the relationship between the various embodiments and / or settings discussed.

[0023] In the existing BFT blockchain, once a node needs to be added or deleted or a cross-chain ecology wants to access, it can only be upgraded or rely on off-chain governance voting; if forced to submit an addition or deletion transaction on the chain, an additional round of 2f+1 voting and view-based master selection need to be run, which is delayed and easy to be dragged by malicious nodes; where f is the maximum number of malicious nodes that the system can tolerate; at the same time, in the business scenario of multiple chains coexisting, although protocols such as Cosmos-IBC (Inter-Blockchain Communication, Inter-Blockchain Communication Protocol), Polkadot-XCMP (Cross-Consensus Message Passing, Cross-Consensus Message Passing) can make cross-chain transfers, registering a new chain still requires governance voting or Slot (Slot) auction, and is not a real "plug and play"; at the same time, the metadata of the chain directory is scattered in DNS (Domain Name System, Domain Name System), Github (code hosting platform) or sub-chain smart contract, and lacks a unified and verifiable view, which brings additional complexity to routing and permission checking, so the existing solution lacks a unified entrance provided to the outside, and internally ensures that the chain directory is consistent, verifiable and has cross-chain permission control infrastructure.

[0024] Therefore, in the present application, a BFT-based blockchain consensus method and system are disclosed, which can safely reconstruct the BFT consensus member set without downtime and improve key security, allowing a large number of business sub-chains to be plug-and-play like USB devices.

[0025] Referring to Figure 1 A BFT-based blockchain consensus method flowchart is provided for the embodiments of the present application, which specifically includes the following steps: S101, if the main node of the main chain detects a node change transaction, a view lock is generated and broadcast to all consensus nodes of the main chain; wherein each consensus node opens a reconstruction window according to the view lock, and in the reconstruction window, a new private key fragment and a new public key vector of each node are generated according to a distributed key generation protocol; In the present application, when the node changes, a node change transaction is generated and submitted (Submit-Tx), which includes a node joining (JOIN) transaction and a node leaving (LEAVE) transaction. The structure of the JOIN transaction is: Tx_join = {type: “join”, pubKey: Pk_new, vrfSeed: Seed, meta: M, sig:Sig_new}; Wherein, Tx_join is the structure of the JOIN transaction, the transaction type type is join, the public key pubKey of the new node is Pk_new, the verifiable random function (VRF) seed vrfSeed is Seed, the metadata field meta is M, and the digital signature sig of the new node to the transaction content is Sig_new.

[0026] The structure of the LEAVE transaction is: Tx_leave ={type:“leave”,nodeID:ID_old,reason:R,sig:Sig_old}; Wherein, Tx_leave is the structure of the LEAVE transaction, the transaction type type is leave, the unique identifier nodeID of the exiting node is ID_old, the reason reason for exiting is R, and the signature sig of the exiting node to the transaction content is Sig_old.

[0027] Both types of transactions are digitally signed by the initiator using its private key (the algorithm is not limited to Ed25519), and then broadcast to the memPool_member. The initiator of the JOIN transaction is the new node N_new, and the initiator of the LEAVE transaction is the exiting node N_old.

[0028] The current master node P of the main chain polls memPool_member every Δ_prepare (polling interval); when the first node change transaction is detected, a view lock ViewLock is immediately generated, which is: ViewLock = {viewID:v,txHash:h_tx, window:Δ_rcfg, ts:t0, sig:SigP}; Wherein, the view number viewID is v, the hash value txHash of the member transaction of this change is h tx, the duration of the reconstruction window window is Δ rcfg, the timestamp ts of the window opening is t0, and the signature sig of the main node is SigP.

[0029] The main node generates a view lock ViewLock and broadcasts it to all consensus nodes. After receiving the ViewLock, all consensus nodes pause the local "normal transaction packaging" thread for Δ rcfg milliseconds, thereby providing a stable window for subsequent threshold key rotation, while ensuring that the main chain can still produce blocks containing system transactions. In addition, to avoid malicious frequent triggering, the application can set a minimum reconstruction interval minReconfigInterval on the chain. If the formula node detects that the time interval between two ViewLocks is less than minReconfigInterval, it directly rejects the member change request.

[0030] In the present application, after each node receives the ViewLock, it will perform a distributed key generation-rotation process: all online nodes exchange Commit / response messages according to the Pedersen-DKG (Pedersen Distributed Key Generation) process, calculate new private key shares share_i' and new public key vectors PK', and then each node writes the hash value hash(share_i') of the new private key share into the local state tree / dkg / shares branch for subsequent auditing; the old private key share share_i is immediately subjected to a memory clearing process. In addition, to prevent network partition from introducing inconsistencies, if a node does not receive enough (2f+1) response packets within Δ dkg (the timeout time of DKG), the main node will roll back this DKG and record a failedReconfig event (reconstruction failure event) on the chain, and then a timer will retrigger the reconstruction window step.

[0031] S102, the main node generates a new view according to the generated new public key vector, and broadcasts the new view to each consensus node; wherein each consensus node verifies the new private key share generated by the node according to the new public key vector of the new view, and sends a threshold signature to the main node after the new private key share is verified. In the present application, after the rotation is completed, each node generates a new private key share_i' and a new public key vector PK', the master node generates a new view NewView according to the new public key vector PK', specifically: NewView ={viewID:v+1,payload:Tx_join / leave,PK', sig:SigP}. Among them, the view number of the new view viewID is v+1, and the payload data payload is Tx_join / leave.

[0032] After the present application generates a new view, it needs to broadcast the new view to each consensus node. After each consensus node receives the new view, it needs to check whether the new public key vector in the new view is consistent with the local new private key share_i'; if the check passes, the corresponding threshold signature vote_i' is generated for the new view, and each consensus node sends the threshold signature to the master node.

[0033] S103, the master node receives a predetermined number of threshold signatures, generates an aggregated signature according to each threshold signature, and generates a new block according to the aggregated signature and the new view, and updates the node list after confirming the submission through the consensus process, completing the reconstruction of the node.

[0034] In the present application, the master node receives a predetermined number of threshold signatures, and generates an aggregated signature according to each threshold signature. Among them, the predetermined number is 2f+1, that is, the master node receives 2f+1 threshold signatures before it aggregates the signatures. In the present application, after successfully aggregating 2f+1 threshold signatures, an aggregated signature AggSig is generated. The master node packages the aggregated signature AggSig together with the new view NewView into a new block B_new, broadcasts it into the standard BFT-X block confirmation process, and confirms it through the BFT-X consensus process. After the new block is confirmed and submitted, the member list NodeSet and the view number viewID need to be updated in the state tree, and the old public key PK is written into the history branch / history / keys for audit backtracking. Among them, the member list NodeSet is the member list after the completion of the node reconstruction, such as the member list after adding new nodes or deleting exiting nodes.

[0035] As can be seen from the above, in the present application, the JOIN / LEAVE transaction is directly embedded into the consensus process. When the master chain detects the node change transaction, it completes the key rotation through the "reconstruction window + Pedersen-DKG + threshold signature" pipeline, and the old and new keys are switched atomically. The master chain continues to generate blocks, and the business is completely unaware, realizing zero-downtime member reconstruction. Moreover, this method can update the public and private keys when the members change, improving the security of the keys.

[0036] In another embodiment of the present application, before generating the view lock, the blockchain consensus method further comprises: if the node change transaction is a node joining transaction, the master node determines the newly joined target node according to the node change transaction, and performs identity verification on the target node; if the verification is successful, the step of generating the view lock is executed.

[0037] In the present application, if the node change transaction is a node joining transaction, it means that there is a newly joined target node. Before the target node is included in the consensus, in order to avoid the subsequent high-overhead steps (DKG, view switching) being dragged in by malicious or unqualified nodes, identity verification needs to be performed on the target node in order to quickly and lowly complete an identity verification and state synchronization baseline. In the present application, when identity verification is performed on the target node, the following steps can be included: a) Read-only synchronization: the target node N_new calls getHeaderTip() through read-only gRPC (Remote Procedure Call, Remote Procedure Call) to obtain the latest height h_tip of the main chain and the state snapshot root hash root_SS.

[0038] getHeaderTip() is an algorithm for obtaining the latest block header and state snapshot root of the main chain. The purpose of this algorithm is to quickly confirm the height and state baseline of the current chain when a new consensus node (target node) is joined, and to provide trusted parameters for subsequent key rotation and snapshot synchronization. The specific input data and output data of this algorithm are as follows: 1) Input: no data (read-only interface), establish a two-way authentication connection with any master node through mTLS (Mutual Transport Layer Security, Mutual Transport Layer Security).

[0039] 2) Output: (h_tip, root_SS, Header, AggSig): the latest block height h_tip, the state root hash root_SS corresponding to the block, the block header Header (including VRF output value, threshold signature, etc. Metadata), and the aggregation signature AggSig of the block header.

[0040] The specific algorithm process of this algorithm is as follows: function getHeaderTip(): (algorithm function for obtaining the latest block header and state snapshot root of the main chain) Step 1: Connection establishment: use mTLS (TLS 1.3 two-way authentication) to establish a secure channel with the master node: conn ← mTLS_connect(peer_address) (connect to the specified peer address peer_address using the mTLS security protocol, and establish a secure channel conn).

[0041] Step 2: Request the latest block header: Send the request message `GetHeaderTipRequest` (request message to get the latest block header and state snapshot root of the main chain), and request the node to return its latest height and block header information: send(conn, GetHeaderTipRequest{}) response ← recv(conn) (receive the response from the connection conn and store it in the response response) Where response contains {height, header, AggSig}; h_tip ← response.height (extract the block height height from the response response and assign it to the h_tip variable); Header ← response.header / / Header contains viewID, seq, hash(BatchTx), AggPrepare, AggCommit, VRF_out; (extract the complete block header header from the response response and assign it to the Header variable) AggSig ← response.AggSig / / (extract the aggregated signature AggSig from the response and assign it to the AggSig variable) root_SS ← Header.stateRoot / / (extract the state tree root hash stateRoot from the block header Header and assign it to the root_SS variable) Step 3: Verify the aggregated signature: Use the public threshold key PK generated in the last round to verify the validity of the signature AggSig on Header.

[0042] if not verifyThresholdSignature(PK, Header, AggSig): raise Exception("Invalid block signature") (if the verification fails through the threshold signature verification function verifyThresholdSignature and the public threshold key PK, AggSig, throw an "invalid block signature" exception) / / Step 4: Return value return (h_tip, root_SS, Header, AggSig) Note that the check threshold signature can ensure that h_tip and root_SS come from a legitimate block, preventing malicious nodes from forging state baselines; the block header Header contains the VRF output and threshold signature fragments, which can be used by new nodes when selecting a master in subsequent views; mTLS connection ensures mutual authentication, preventing man-in-the-middle attacks.

[0043] b) Zero trust access: the target node N_new initiates a TLS-1.3 handshake with the master chain node using the chain root certificate; the successful party can continue, otherwise the connection is immediately discarded.

[0044] c) Identity binding: to prevent Sybil attacks, the JOIN request must also submit an on-chain identity credential cred, which can be in the form of a staking amount or an X.509 certificate issued by an authorized agency; if not provided, it is immediately discarded.

[0045] In another embodiment of the present application, after updating the node list, the blockchain consensus method further comprises: if the node change transaction is a node joining transaction, the newly joined target node obtains a snapshot file and a Merkle proof from any healthy node of the master chain, and the target node restores the snapshot file to the local key-value database after successfully verifying the Merkle proof.

[0046] In the present application, in the JOIN scenario, the newly joined target node sends a request GetSnapshot(h_tip, root_SS) to any healthy node. Wherein, GetSnapshot(h_tip, root_SS) is a secure snapshot synchronization function, through which a compressed snapshot of the latest system state can be provided to the new node, allowing it to quickly synchronize to the current state without having to replay the complete transaction history. The input data of this function is: the latest height h_tip and state root root_SS (from getHeaderTip()), as well as the identity credentials of the requester (to prevent unauthorized synchronization). The output data is: (SnapFile, ProofChunks): SnapFile is a compressed snapshot file Snap.tar.lz4, and ProofChunks is an array of Merkle proofs for each snapshot chunk.

[0047] Upon receiving the request, the node looks up the local snapshot repository and returns the compressed snapshot file Snap.tar.lz4 and its Merkle proof π. The target node N_new verifies that π matches root_SS and restores the snapshot to a local key-value database, which can be LevelDB (Log-Structured Merge Tree Database), RocksDB (Rocks DataBase), etc., and then writes the latest height h_tip to the local metadata state.json. At this point, N_new officially enters the consensus cycle. The entire add-delete process has no visible downtime to the outside world, only suspending the packaging of new business transactions during the reconstruction window.

[0048] Here is a detailed description of the secure snapshot synchronization function: function GetSnapshot(h_tip, root_SS): Step 1: Establish a secure connection through mTLS and verify the identity of the requester: conn ← mTLS_connect(requester) (connect to the requester using mTLS two-way authentication) verifyCredential(requester.cred) (verify the identity of the requester's credential cred) Step 2: Find the snapshot file of height h_tip: snapshot_meta ← lookupSnapshotMetadata(h_tip) (find the snapshot metadata snapshot_meta corresponding to h_tip) if snapshot_meta is None: raise Exception("Snapshot not found") (if the snapshot metadata does not exist, throw an exception "Snapshot not found") Step 3: Read the snapshot by block and calculate the block-level Merkle proof: SnapFile ← [] ProofChunks ← [] (initialize an empty list to store the snapshot file SnapFile and the proof block ProofChunks, [] represents an empty list) for each chunk c in snapshot_meta.chunks: data ← readChunkFromStorage(c) (For each data block c in the snapshot metadata snapshot_meta, perform the following operations: read the data of data block c from storage and assign the read data to the data variable) / / Calculate the Merkle proof π_i for each block such that verifyProof(π_i, data.hash, root_SS) == true, where verifyProof is the verification proof function and data.hash is the hash value of the data mentioned above; π_i ← computeMerkleProof(c.index, snapshot_meta.merkleTree) (computes the Merkle proof MerkleProof for the i-th data block and assigns it to the variable π_i. c.index is the index position of the current data block in the Merkle tree, and snapshot_meta.merkleTree is the Merkle tree structure in the snapshot metadata.) append(SnapFile, data) (Appends the data block data to the list of snapshot files SnapFile) append(ProofChunks, π_i) (Appends Merkle's proof π_i to the list of proof chunks ProofChunks) Step 4: Return to compressed snapshot and proof return (compress(SnapFile), ProofChunks); where compress(SnapFile) represents a compressed snapshot file.

[0049] Client processing flow: function InstallSnapshot(SnapFile, ProofChunks, root_SS) (functionInstallSnapshot is the function for installing snapshots): Step 1: Decompress the snapshot and iterate by block: for i from 0 to len(SnapFile)-1: (Iterate through all data blocks in the snapshot file, where len(SnapFile) is the length of the SnapFile list) blockData ← decompressBlock(SnapFile[i]) (Compresses the i-th data block in the snapshot file and assigns the decompressed data to blockData) proof ← ProofChunks[i] (Retrieves the i-th Merkle proof from the list of proof chunks and assigns it to the proof variable) / / Step 2: Verify the existence of the block hash in the global state tree: if not verifyProof(proof, hash(blockData), root_SS): Raise an exception ("Snapshot block verification failed") if the verification fails. / / Step 3: Write to the local key-value database applyToLocalDB(blockData) (Applies the validated data block to the local key-value database DB) / / Step 4: Write metadata to state.json updateLocalState(height=h_tip) (Updates the local state file, recording the current synchronized height) In summary, this embodiment, by acquiring a snapshot file and a Merkle proof, and restoring the snapshot file to the local key-value database after successful verification of the Merkle proof, can achieve the following beneficial effects: 1. Block-based Merkle proof: The state tree is divided into fixed-size blocks, each containing a complete subtree and its root hash. There are no cross dependencies between blocks, and the proof chain can be verified independently.

[0050] 2. Fraud Detection: A Merkle proof π_i is attached to each block, allowing the receiver to verify that the block root is below the global state root during the download process. If a block is invalid, it can be immediately discarded and a new request can be made to other nodes, effectively preventing malicious nodes from delaying the process.

[0051] 3. Incremental recovery: The local database can be restored in parallel after downloading a block, without waiting for the entire snapshot to complete; thus reducing recovery time.

[0052] In another embodiment of this application, the blockchain consensus method further includes: The main node receives a registration transaction structure sent by the multi-chain gateway; wherein, the generation process of the registration transaction structure comprises: the multi-chain gateway receives a registration request of a business sub-chain, and verifies a chain description block carried by the registration request, if the verification is successful, a new root hash of the Merkle-DAG is generated, and the registration transaction structure is generated based on the new root hash; The main node confirms the registration transaction structure through a consensus process; wherein, after the registration transaction structure is confirmed, the multi-chain gateway distributes the business sub-chain to a corresponding target chain group, and updates a routing table; wherein, after the chain group arranger receives a legal cross-chain call, the cross-chain call is forwarded to a target sub-chain through the routing table.

[0053] In the present application, in order to realize the plug-and-play of the business sub-chain and the deterministic routing of the cross-chain call, the present application designs a chain description block (Chain-Description-Block, CDB for short) and a registration-verification-routing three-stage mechanism matched therewith.

[0054] Specifically, the structure of the chain description block adopts a binary coding mode of fixed-length header and variable-length tail, and the field and byte length are as follows: 0. chainID, 16B, adopts UUID-128, a unique identifier of the chain, which is unique in the system; 1. createHeight, 8B, block height of the main chain when the CDB is generated; 2. pk_chain, 33B, sub-chain management public key (compressed elliptic curve format); 3. consType, 1B, consensus type enumeration (00=BFT, 01=PoS, 02=ZK-Rollup…); 4. period_ms, 4B, sub-chain block generation period, unit: millisecond; 5. ACL (Access Control List), TLV (Tag-length-value), multi-segment access control list, variable length; each segment label (1B) + length (2B) + content (nB); 6. sigCDB, 64B, signature generated by the sub-chain management institution using Ed25519 on the fields 0-5.

[0055] Among them, field 5 uses TLV (Tag-Length-Value) format, which facilitates subsequent addition of permission types without breaking compatibility; field 6 covers only fields 0-5, ensuring that any field tampering will result in signature verification failure; when consType=ZK-Rollup, the verification key vk and data availability endpoint can be embedded in ACL.

[0056] In the present application, the service sub-chain needs to send a registration request to the multi-chain gateway at the time of registration, and the registration request includes the chain description block submitted by the service sub-chain through POST / cdb / register. Specifically, the registration process of the service sub-chain includes the following steps: 1) The service sub-chain submits a registration request as (CDB||σ_http), where σ_http is an mTLS session layer signature; 2) Verify the session layer signature: verifySig(pk_chain, sigCDB, hash(CDB[0-5])), where verifySig is a function for verifying a signature, and hash(CDB[0-5]) is a hash value calculated for the first 5 fields of CDB; if the verification fails, return 4XX (client error status code) immediately.

[0057] 3) Perform a uniqueness check on the service sub-chain by doing GetIfExists(chainID) (a function for querying whether a value exists according to chainID) in the local RocksDB (key-value storage database) - ColumnFamily (namespace) cdb_idx (column family, used to store the index of chainID to its metadata); if it already exists, refuse duplicate registration; 4) Perform ACL semantic audit, call policy engine policyCheck(ACL), and if consType (consensus type) == ZK-Rollup (zero-knowledge rollup), also check the connectivity of the data availability endpoint; 5) Merkle-DAG insertion: Calculate newLeafHash = H(CDB‖root_CDB‖ts_now); where newLeafHash is a new leaf node hash, H() represents a hash function, root_CDB represents the root hash value of the current Merkle-DAG structure, and ts_now is a timestamp; then use the CAS (Compare-And-Swap, atomic operation protocol) method to write newLeafHash into RocksDB; generate a new root hash root_CDB′, and construct a registration transaction structure, which is: RegisterTx={type:reg, leaf:newLeafHash, root:root_CDB′}; Wherein, the identifier transaction type type is reg (registration operation), the leaf node hash to be registered is newLeafHash, and the new root hash root is root_CDB'. Then, the main chain node sends RegisterTx into consensus, executes the BFT-X consensus process, and guarantees that the DAG root is confirmed by the whole network. After success, the multi-chain gateway Gateway writes the (chainID→clusterID (chain cluster number)) mapping relationship into the routing table routeTable, so as to be retrieved by the chain cluster orchestrator.

[0058] In the present application, after the chain cluster orchestrator receives a legal cross-chain call, it needs to judge whether the target sub-chain of the cross-chain call is a legal registered sub-chain; if the target sub-chain is a legal registered sub-chain and the cross-chain call has the authority to call the target sub-chain, a session tunnel is established with the target sub-chain, the payload data of the cross-chain call is sent to the target sub-chain through the session tunnel, and the performance index data corresponding to the cross-chain call is sent to Prometheus.

[0059] Specifically, in the routing stage of the business sub-chain, the chain cluster orchestrator (Cluster-Orchestrator) receives a cross-chain call, which is request = {dstID, payload, authZ}, wherein, dstID is the number of the target sub-chain, payload is the payload data of the cross-chain call, and authZ is the authorization credential. After receiving the cross-chain call, the chain cluster orchestrator performs the following steps: 1) Root hash alignment: if local_root_CDB_local≠root_CDB_onChain (the local root hash is inconsistent with the on-chain root hash), call syncRoot() (root hash synchronization function) to pull the latest root hash from the main chain and incrementally synchronize the missing leaf nodes; 2) Existence verification: MerkleProof π←findRoute(dstID) (find the routing information in the database according to dstID, and generate a Merkle proof π that can prove the existence of the target sub-chain), verify VerifyProof(π, root_CDB_local)==true, if the verification is successful, it means that the target sub-chain is a legal registered sub-chain, otherwise, return "No-Such-Chain", wherein, VerifyProof is a verification function; 3) Permission check: matchACL (ACLdst, authZ); return "Permission-Denied" if not passed; wherein matchACL is used to match the access control list, and the ACL of the target sub-chain is matched with the authorization credentials. If the permission verification is passed, it means that the cross-chain call has the permission to call the target sub-chain.

[0060] 4) Route resolution: Obtain the target chain group entry (IP:Port) from the leaf node field clusterID→routeTable; 5) Tunnel establishment: Create a session tunnel tunnelID using gRPC-mutualTLS, and transmit the payload to the target sub-chain Biz-Chain; 6) Telemetry feedback: Call pushMetric() to send delay, throughput, and other indicators to Prometheus for subsequent elastic expansion decision-making.

[0061] Wherein, pushMetric() is a function for implementing performance indicator pushing. The purpose of this function is to push performance indicators such as delay and throughput to the monitoring system after cross-chain calls or key events, supporting subsequent elastic expansion and fault diagnosis. The reason for setting the push function is that Prometheus uses a pull mode to collect data, which is not suitable for one-time short tasks, so the official provides Pushgateway for pushing indicators. The pushMetric() function in this scheme is designed to encapsulate the call to Pushgateway and combine it with the gRPC framework to achieve unified indicator reporting. The input data of this function is: metricName (indicator name) (such as chain_request_latency_ms), labels (key-value pairs, including source chain, target chain, result, etc.), value (floating point number), and timestamp (timestamp).

[0062] The algorithm steps of this function include: function pushMetric(metricName, labels, value, timestamp): Step 1: Form the Prometheus text format: # metric_line: example 'chain_request_latency_ms{src="chainA",dst="chainB",result="success"} 42.7' (Comment line, showing an example of Prometheus text format) `label_str ← join([key + "="" + val + """ for (key,val) in labels],',')` (This converts a dictionary of labels into a comma-separated string, where `label_str` stores the generated label string, `join()` is the join function, and `[key + "="" + val + """ for (key,val) in labels]` is a list comma that generates a string in the format `key="value"` for each label key-value pair. `metric_line` ← `f"{metricName}{{{label_str}}} {value}"` (combines the metric name, label string, and value into a complete metric line). if timestamp is not None: metric_line ← metric_line + f" {timestamp}" (If the timestamp is not empty, add it to the end of the metric line) body ← metric_line + "" Adds a newline character at the end of the metric_line to form the complete HTTP request body. " Step 2: Send an HTTP POST (Hypertext Transfer Protocol) request to Pushgateway: URL ← "http: / / pushgateway.example.com / metrics / job / chain_orchestrator" / / Send using gRPC or an HTTP client; HTTP is used as an example here: http_post(url, body) / / Step 3: Optional error handling and retries if response.status_code != 200: retry or log error (If the HTTP response status code is not equal to 200 (success), perform a retry or log the error message).

[0063] Further, in another embodiment of the application, the on-chain multi-chain directory can also be integrated with pre-authorization access control, enabling secure and verifiable cross-chain data circulation.

[0064] The main process is as follows: 1. CDB registration and chain directory maintenance: when a sub-chain is registered, the gateway verifies the CDB signature, checks uniqueness and audits the ACL, then calculates the new leaf hash H(CDB || root_CDB || ts), and writes the new root hash to the chain through the main chain consensus. The root hash serves as the chain directory reference shared by the entire network.

[0065] 2. Token generation and registration: the data provider registers the access policy on the chain and generates a permission token for the requester. The token includes metadata such as authorization scope, validity period, and remaining available times, and after signing, the association with the policy ID is recorded on the chain.

[0066] 3. Cross-chain request processing: when the cross-chain request request={dstID, payload, authZ} reaches the chain group orchestrator: Align the local chain directory root by calling syncRoot(); Verify the existence of dstID in the chain directory by VerifyProof(π, root_CDB_local); Perform token verification and basic policy evaluation, and reject unauthorized or exceeding permission requests; Call the target sub-chain according to the access result output by the policy engine, and record the access event and report the performance metrics through pushMetric().

[0067] 4. Dynamic policy switching: monitor runtime signals, switch policies when conditions are met through atomic updates, record the new and old policy IDs and timestamps on the chain to ensure audit and rollback.

[0068] 5. Permission token adjustment: after switching policies, adjust the tokens for unfinished or subsequent requests to ensure that the token's permission scope is consistent with the target policy.

[0069] As can be seen from the above, in the application, multi-chain plug-and-play is achieved through chain description blocks (CDB) and Merkle-DAG chain directories. After the business sub-chain is registered once, it can be automatically indexed and assigned to the corresponding chain group. The directory root hash is written to the main chain regularly, and the entire network shares a unified and verifiable chain view, enabling deterministic routing and ACL permission control.

[0070] In another embodiment of the application, the consensus process performed by the master node includes: The master node extracts at least one transaction from the memory pool; wherein the transaction includes a confirmation transaction of a new block, and / or a registration transaction of a registration transaction structure; The master node calculates the digest value of each transaction, splices the digest values to generate an aggregated message authentication code, and sends a PPREQ message to each consensus node according to the aggregated message authentication code; wherein each consensus node verifies the aggregated message authentication code of the PPREQ message after receiving the PPREQ message, and if the verification is passed, generates a first local signature of the transaction batch hash, and sends the first local signature to the master node through a PREP message; The master node receives a predetermined number of first local signatures, aggregates the first local signatures into an aggregated prepared signature, and broadcasts the aggregated prepared signature to each consensus node; wherein each consensus node generates a second local signature of the transaction batch hash after verifying the received aggregated prepared signature, and sends the second local signature to the master node through a COMM message; The master node receives a predetermined number of second local signatures, aggregates the second local signatures into an aggregated commit signature, and generates a corresponding block; the block includes a block header and a block body, and each consensus node verifies the block header to determine that the block is a valid block.

[0071] In the present application, in order to reduce network load, compress confirmation delay, and improve anti-audit manipulation ability, the present application introduces three key technologies of batch MAC (Message Authentication Code) aggregation, VRF randomness and threshold signature on the basis of classical BFT protocol, and provides an improved BFT-X consensus process. In the BFT-X protocol, the message type is not only a communication format, but also a semantic beacon, which is used to tell all consensus nodes the current stage and the state transition that should be performed.

[0072] In the present application, the BFT-X consensus process includes three core messages, and each message type is described as follows: 1) PPREQ (Pre-Prepare-Request, pre-preparation request): {view, seq, BatchTx, VRF_out, π_VRF, MAC_agg} Wherein, view is the view number; seq is the sequence number; BatchTx is the transaction batch, which is a batch of transactions collected and packaged by the master node from the transaction pool; VRF_out is the output value of the verifiable random function; π_VRF is the VRF proof; and MAC_agg is the aggregated message authentication code.

[0073] The function of the PPREQ message is that the master node proposes a transaction batch and attaches randomness and batch MAC.

[0074] Wherein, VRF is used to generate unpredictable and verifiable random numbers in each round of consensus, in this scheme, ECVRF (Elliptic-Curve VRF) is adopted, and VRF output (VRF_out) and proof π are attached in each PPREQ message.

[0075] 2) PREP (Prepare-Vote, prepare voting) {view, seq, hBatch, σ_i} Wherein, hBatch is the transaction batch hash, hBatch = H (BatchTx) ; σ_i is the threshold signature fragment of node i on hBatch in different stages, that is, local signature. Effect: Each consensus node gives a threshold signature fragment of hBatch = H (BatchTx), indicating "ready".

[0076] 3) COMM (Commit-Vote, commit voting) {view, seq, hBatch, σ_i} Effect: After collecting enough PREP, each consensus node signs again to confirm "commit".

[0077] In this application, when the master node executes the consensus process, it first takes m transactions tx1…tx_m from the memory pool mempool, and this application calls the m transactions as transaction batch BatchTx; Wherein, the transactions in the memory pool include the confirmed transactions of the new block, the registration transactions of the registration transaction structure, etc. in the above embodiment, which are not specifically limited here. After obtaining the transaction batch, for each transaction in the transaction batch, an 8-byte digest value d1…d_m of each transaction is obtained by SIPHASH-16 (hash function). Then, the m digest values (d1…d_m) are spliced in order, and a 16-byte aggregated message authentication code MAC_agg is generated by executing POLY1305 (cryptographic algorithm).

[0078] It should be noted that since all nodes can replay the same calculation process, only one MAC_agg needs to be carried in the PPREQ message of this batch, and all copies can verify the MAC_agg of the PPREQ message by replaying the above process, and the network bandwidth saving rate ≈1-(16+8) / m, when m≥64, the packet body overhead can be reduced by about 70%. The application can verify a batch of transactions with one aggregated MAC by batch packaging and MAC aggregation, reducing bandwidth and CPU (Central Processing Unit, Central Processing Unit) consumption.

[0079] In another embodiment of the present application, the process of generating the PPREQ message by the primary node includes: The primary node generates an output value and a verifiable proof according to the current view number, the current batch sequence number, the transaction batch hash, and the private key of the verifiable random function; generates the PPREQ message by the output value, the verifiable proof, and the aggregated message authentication code; wherein each consensus node, after receiving the PPREQ message, verifies the verifiable proof by the public key of the verifiable random function, and if the verification is passed, stores the output value to the local entropy pool.

[0080] In the present application, a verifiable random number needs to be added in the PPREQ message to ensure that the subsequent leader election is unpredictable and uncontrollable. Specifically, at the beginning of each round of consensus, the primary node first calls the private key (VRF private key) of its own verifiable random function on the uniquely determined context (view || seq || hBatch) to obtain the output value VRF_out and its verifiable proof π_VRF, and puts VRF_out, π_VRF, and MAC_agg into the PPREQ message. After receiving the PPREQ message, the consensus node uses the previously published public key (VRF public key) of the verifiable random function to verify the correctness of π_VRF, and after the verification is passed, appends VRF_out to the local entropy pool randPool.

[0081] It should be noted that, since the VRF has two characteristics of uniqueness and unpredictability, its output is random and uncontrollable to anyone (including the primary node itself) before the primary node signs. The protocol then uses VRF_out as the fair leader election seed for the next view: all consensus nodes independently calculate the new primary node newLeader = H(VRF_out) mod n, where mod n represents taking the modulus of the total number of nodes n; through this way, the present application can ensure that the result is consistent and the old primary node cannot affect in advance; at the same time, the on-chain governance or sharding scheduling module can also directly read the high-bit bits of randPool to obtain a trusted and verifiable public random source.

[0082] In the present application, the primary node sends the PPREQ message to each consensus node, and each consensus node, after receiving the PPREQ message, needs to verify the aggregated message authentication code of the PPREQ message, and if the verification is passed, each consensus node generates a local signature σ_i by calling TSIG_sign (threshold signature algorithm) on the transaction batch hash hash(BatchTx) in the Prepare phase, and then each node sends the local signature σ_i to the primary node through the PREP message.

[0083] If the master node collects 2f+1 local signatures σ_i, it will aggregate the 2f+1 local signatures σ_i into an aggregated prepared signature AggPrepare, and broadcast the aggregated prepared signature and the transaction batch hash hash(BatchTx) to each consensus node. Each consensus node receives the aggregated prepared signature AggPrepare, and if the verification of AggPrepare is passed, the node enters the Commit phase, signs the same transaction batch hash hash(BatchTx) again to generate a local signature σ_i, and sends it to the master node through the COMM message. In order to distinguish, the local signature generated in the Prepare phase is called the first local signature, and the local signature generated in the Commit phase is called the second local signature.

[0084] If the master node receives 2f+1 second local signatures, it will aggregate the 2f+1 second local signatures to generate an aggregated commit signature AggCommit, and generate a block; the block includes a block header Header and a block body, and the block body stores the real transaction batch, and the block header Header is specifically: Header = {view, seq, hash(BatchTx), AggPrepare, AggCommit, VRF_out}.

[0085] All verifiers only need to do sha2-256 on Header to confirm the validity of the block. As can be seen, the application can aggregate the 2f+1 signatures of the two-stage into a threshold signature, compress the block header and speed up the signature verification.

[0086] In the improved BFT-X consensus protocol, the threshold signature algorithm is used to aggregate the local signatures of 2f+1 nodes into an aggregated signature, compress the block header and speed up the verification. The threshold signature implementation needs a two-stage process of distributed key generation and signature. The application adopts the current leading FROST Schnorr threshold signature protocol as a specific implementation example, which provides two rounds of signature and supports Ed25519 / BLS curves, is safe and efficient. Because the threshold signature generation process is completely completed off-chain (only the public key and key update need to be recorded on-chain), it will not block block generation, and can meet the "zero downtime member reconstruction", mainly including the following two parts: 1. Distributed key generation (Pedersen-DKG) The key generation phase generates a group public key PK and n private key shares sk_i. The Pedersen DKG is used: each node selects a random polynomial p_i(x) and broadcasts a commitment A_{i,k}=g^{a_{i,k}}. A_{i,k} is the kth coefficient commitment of the ith node, and a_{i,k} is the kth random coefficient of the ith node. Shares s_{i,j}=p_i(j) are exchanged, where s_{i,j} is the private key share of node i to node j, and p_i(j) is the value of the polynomial at x=j. Each node sums the received shares to obtain its own private key share s_j, and the public key is g^{s}. This scheme can generate a shared private key without a trusted third party and allows threshold recovery.

[0087] 2. FROST-TSIG signature process FROST signature is divided into two rounds: commitment generation and signature sharing, and the signature is aggregated after the second round. The FROST protocol shortens the threshold signature to two rounds of interaction, saves communication rounds compared to the traditional Feldman threshold Schnorr signature, supports offline commitment, and reduces the attack surface.

[0088] / / Round One: Nonce commitment function Round1_GenerateCommitment(i, sk_i):(Node i function to generate random number commitment in the first round) / / Participant i randomly selects a hidden / binding random number hiding_nonce_i ← RandomScalar()(Generate a hidden random number and assign it to the hiding_nonce_i variable, RandomScalar() is a function that generates a random scalar value) binding_nonce_i ← RandomScalar()(Generate a binding random number and assign it to the binding_nonce_i variable) / / Calculate commitment hiding_commitment ← g^hiding_nonce_i(Calculate the hidden commitment hiding_nonce and assign it to the hiding_commitment variable) binding_commitment ← g^binding_nonce_i(Calculate the binding commitment and assign it to the binding_commitment variable) / / Send the commitment to the coordinator (main node) and store the random number locally broadcastCommitment(i, hiding_commitment, binding_commitment) (broadcast the hiding commitment hiding_commitment and the binding commitment binding_commitment of node i) return (hiding_nonce_i, binding_nonce_i) (return the hiding nonce hiding_nonce_i and the binding nonce binding_nonce_i) / / Round Two: Signature Share Generation function Round2_SignShare(i, sk_i, nonce_i, msg, commitment_list): (define the second round signature share generation function, msg is the message to be signed, commitment_list is the commitment list of all nodes) / / Calculate auxiliary variables such as binding factor binding_factor_list ← compute_binding_factors(group_public_key,commitment_list, msg) (where binding_factor_list is the binding factor list variable, compute_binding_factors is the function to calculate the binding factor, group_public_key is the group public key) binding_factor ← binding_factor_for_participant(binding_factor_list,i) (get the binding factor of the current node i from the binding factor list) group_commitment ← compute_group_commitment(commitment_list,binding_factor_list) (calculate the group commitment value, group_commitment is the group commitment variable, compute_group_commitment is the function to calculate the group commitment) lambda_i ← derive_interpolating_value(participant_list, i) (calculate the interpolating coefficient of node i) challenge ← compute_challenge(group_commitment, group_public_key, msg) (compute signature challenge value) (hiding_nonce, binding_nonce) ← nonce_i (unpack hiding nonce and binding nonce from nonce_i) / / Compute signature share z_i sig_share ← hiding_nonce + binding_nonce * binding_factor + lambda_i * sk_i * challenge (compute signature share z_i) / / Send signature share to coordinator sendSignatureShare(i, sig_share) return sig_share (send signature share to coordinator, return signature share) / / Aggregation: Coordinator aggregates shares into final signature function AggregateSignatures(commitment_list, msg, group_public_key, sig_shares) (function for coordinator to aggregate collected signature shares into final signature, AggregateSignatures for aggregate signature): / / Compute binding factors and group commitment binding_factor_list ← compute_binding_factors(group_public_key, commitment_list, msg), where binding_factor_list is the list of binding factors, and compute_binding_factors is the function to compute binding factors; group_commitment ← compute_group_commitment(commitment_list, binding_factor_list), where group_commitment is the group commitment; / / Aggregate signature z = Σ z_i z ← 0 for each z_i in sig_shares: z ← z + z_i return (group_commitment, z) / / Schnorr signature (R, z) (initializes the aggregate signature z to 0, iterates through each signature share and adds it to the aggregate signature z, and returns a (R, z) pair in Schnorr signature format, where R represents the group commitment group_commitment).

[0089] In another embodiment provided in this application, the blockchain consensus method further includes: If a consensus node on the main chain detects that the conditions for switching leaders are met, it retrieves the target output value of the previous consensus process from its local entropy pool, determines the initial node based on the target output value, and then sends a new view request to other consensus nodes on the main chain. If each consensus node receives the new view request, retrieves the target output value from its local entropy pool, and if the determined initial node matches the initial node in the new view request, it determines that the initial node is the new leader node and enters the new view.

[0090] In this application, if the master node fails or times out, when each consensus node detects that the conditions for switching masters are met, a new master can be unanimously selected using the publicly available VRF output value.

[0091] Specifically, if any consensus node in the main chain detects that the master node has not broadcast PREP within `timeout_prepare` milliseconds (the time threshold for the preparation phase), it can be determined that the conditions for a change of leader are met, and a new view request (`NewViewReq`) can be initiated to trigger the change of leader. When generating the new view request, the initiator uses the target output value `VRF_out` from the previous round as a random seed to calculate the initial candidate node for the new master node, `newLeader = H(VRF_out) mod n`, and declares it in `NewViewReq`.

[0092] After receiving the NewViewReq, all other nodes independently reproduce the newLeader calculation. If the calculated newLeader matches the newLeader in the NewViewReq, they jointly recognize the newLeader as the new master node and enter the new view. In this way, each node does not need to perform 2f+1 voting, because VRF_out has been confirmed by the entire network and is unpredictable. The old master cannot manipulate or favor this master election in advance, ensuring that the view switch is both fair and efficient. This VRF_out is a functional module that enables a no-vote master change when the master node goes offline.

[0093] In the present application, formal security proof is also provided, and the specific proving process is: through TLA+ (a language for formal modeling), the entire consensus protocol and its member change process are accurately modeled to obtain an executable state machine specification. On this basis, the state machine is imported into Isabelle / HOL (an interactive theorem prover), and the "eventual commitment" (as long as the network is eventually stable, the transaction will be settled) and "safety" (all non-Byzantine nodes always maintain the same order of settled transactions) are formally written as two theorems to be proved, and the mechanical proof is completed in the interactive theorem prover. For member changes, the JOIN / LEAVE window is abstracted as an atomic switch, and the "before change" and "after change" network models are seamlessly spliced through state mapping, and it is proved that as long as the number of Byzantine nodes satisfies f < n / 3 at any time, the system still satisfies Eventual-Commit and All-Agree. Therefore, it can be asserted that no matter whether node hot plugging or multiple registrations across chains occur, the consistency and final commitability of the ledger will not be destroyed.

[0094] As can be seen from the above, the present application proposes a non-voting master replacement method, which uses the VRF output value of the last round of chain as a random seed, each node independently derives a new master, and the view switching can be completed without collecting 2f+1 prepared votes, the delay only needs one network round trip and the old master cannot predict or manipulate the result; and the present application can perform MAC aggregation and batch block output, so that only one Poly1305 verification is performed on a batch of transactions, and the 2f+1 prepared signatures of Prepare / Commit are compressed into a single aggregated signature by threshold signature, which greatly reduces the bandwidth and CPU overhead. Further, the present application can realize formal proof security, model the whole process by TLA+, and mechanically prove the activity and consistency in Isabelle / HOL. Even if the nodes are dynamically added or deleted or multiple links are connected, the ledger security is not destroyed under the premise of f < n / 3, so that the performance, robustness and mathematical level security are all superior to the existing BFT blockchain scheme.

[0095] In another embodiment of the present application, a BFT-based blockchain consensus system structure diagram is provided, which comprises: a master node and each consensus node of a master chain; The master node is configured to generate a view lock when detecting a node change transaction, and broadcast the view lock to all consensus nodes of the master chain; each consensus node is configured to open a reconstruction window according to the view lock, and generate a new private key fragment and a new public key vector of each consensus node according to a distributed key generation protocol in the reconstruction window; The master node is further configured to generate a new view according to the generated new public key vector and broadcast the new view to each consensus node; each consensus node is configured to check a new private key fragment generated by the node according to the new public key vector of the new view, and send a threshold signature to the master node after the new private key fragment is checked. The master node is further configured to generate an aggregated signature according to each threshold signature after receiving a predetermined number of threshold signatures, generate a new block according to the aggregated signature and the new view, and update a node list after the new block is confirmed by a consensus process, to complete reconstruction of the nodes.

[0096] In another embodiment of the present application, the system further comprises: A business sub-chain configured to send a registration request to the multi-chain gateway; The multi-chain gateway is configured to receive the registration request and verify a chain description block carried by the registration request, generate a new root hash of a Merkle-DAG if the verification is successful, and generate a registration transaction structure based on the new root hash; A master node configured to receive the registration transaction structure sent by the multi-chain gateway and confirm the registration transaction structure by a consensus process; The multi-chain gateway is further configured to assign the business sub-chain to a corresponding target chain group and update a routing table after the registration transaction structure is confirmed; A chain group orchestrator configured to forward a cross-chain call to a target sub-chain through the routing table after receiving a legal cross-chain call.

[0097] In another embodiment of the present application, the chain group orchestrator is specifically configured to: receive a cross-chain call, determine whether a target sub-chain of the cross-chain call is a legal registered sub-chain, if the target sub-chain is a legal registered sub-chain and the cross-chain call has the authority to call the target sub-chain, establish a session tunnel with the target sub-chain, send payload data of the cross-chain call to the target sub-chain through the session tunnel, and send performance index data corresponding to the cross-chain call to Prometheus.

[0098] Referring to Figure 2 To clearly illustrate the present scheme, a specific consensus system architecture diagram is provided, as shown in the figure. The system comprises four types of core components: Master-Peers: Master-Peers include master nodes and other consensus nodes, responsible for persistently storing the global ledger, executing the improved BFT-X consensus algorithm, maintaining the VRF random master election service and threshold key rotation service in each view round. Threshold key rotation is triggered when member changes are detected. To ensure security, the number of master chain consensus nodes n always satisfies n³ 3f + 1, and f < n / 3, where f is the number of tolerable Byzantine nodes.

[0099] Cluster-Orchestrator: responsible for virtualizing several business sub-chains into a logical "cluster", the orchestrator resides in the internal nodes of the cluster, and uses chain-level ACL for cross-chain permission verification; after receiving a legal cross-chain call, it forwards the call to the target sub-chain through the internal gRPC routing table, and pushes performance indicators to the Prometheus monitoring endpoint.

[0100] Gateway: located at the edge of the system and exposing a unified REST (Representational State Transfer) / GRPC (Google Remote Procedure Call) entry. The multi-chain gateway receives the chain description block CDB submitted by the business sub-chain and performs legality verification; organizes the legal CDB into a Merkle-DAG index structure, generates an index root hash, and then periodically writes the index root hash as a special transaction into the master chain, so that all nodes share the same "chain directory".

[0101] Biz-Chains: can use any permissioned chain or zero-knowledge rollup (ZK-Rollup) technology, and evolve and upgrade independently. After the sub-chain completes the one-time handshake in the initialization phase and registers the CDB with the gateway, it can be included in the cluster by the orchestrator.

[0102] As shown in Figure 2 , the overall system startup process is as follows: 1. Deploy and start the master chain, and the consensus nodes enter the improved BFT-X working state; 2. Each business sub-chain submits CDB to the multi-chain gateway to complete registration, and the gateway assigns the sub-chain to different clusters according to the strategy; and writes the hash into the master chain; 3. When an external node needs to join or exit the master chain, the node initiates a JOIN / LEAVE member change transaction; 4. After the member change transaction is agreed, the master chain automatically updates the member view and completes the threshold key rotation; 5. When cross-chain calls are generated at random, the chain group arranger consults the Merkle-DAG chain directory, checks the permissions, establishes a communication link, and forwards the call.

[0103] Based on the above embodiments, the overall process, dynamic node addition and deletion process, and multi-chain dynamic access process designed in this application are summarized and described as follows: I. Overall process: The improved BFT-X consensus protocol introduces batch MAC aggregation, VRF randomness, and threshold signature based on the classic PBFT / Tendermint. The main message types include: PPREQ: Proposed by the master node, the transaction batch is accompanied by VRF output and aggregated MAC; PREP: Copies of transaction batch hash do threshold signature fragments, indicating "ready"; COMM: After collecting enough Prepare tickets, the copy signs again to confirm that it can be submitted.

[0104] To reduce bandwidth consumption, the master node concatenates the 8-byte SIPHASH digest of m transactions tx_1⋯tx_m and executes Poly1305 once to generate an aggregated MAC. All copies replay this process to verify the MAC. The VRF output is used as the seed for the next view fair master selection, preventing the master node from manipulating the master selection. Threshold signature aggregates 2f+1 local signatures into a single signature, significantly compressing the block header. View switching uses VRF output to "replace master without voting".

[0105] II. Dynamic node addition and deletion process: Dynamic node addition and deletion includes pre-check, transaction submission, window reconstruction, distributed key generation (DKG), view update, and new node snapshot synchronization: 1. Pre-check stage: New node N_new obtains the latest height h_tip and state snapshot root_SS (algorithm given below) by read-only gRPC call getHeaderTip(); complete two-way TLS handshake and submit chain identity credentials to prevent Sybil attacks.

[0106] 2. Submit JOIN / LEAVE transaction: New nodes broadcast Tx_join={type:"join",pubKey:Pk_new,vrfSeed:Seed,meta:M,sig:Sig_new} to the memory pool; exit nodes submit Tx_leave.

[0107] 3. Reconfiguration Window: The primary node periodically polls memPool_member, detects the first member transaction change, and generates ViewLock={viewID, txHash, window, ts, sig} broadcast to notify all nodes to enter the key rotation window.

[0108] 4. Distributed Key Generation (DKG): All online nodes interact according to Pedersen-DKG to generate new threshold key PK', each node calculates new private key share_i' and writes the hash to the chain. If not enough responses are collected within the timeout, rollback and retry.

[0109] 5. View Update and Block Submission: The primary node constructs NewView={viewID+1, payload: Tx_join / leave, PK'} and aggregates threshold signature AggSig, then packs it into a new block.

[0110] 6. Snapshot Synchronization: Only performed when a new node joins. The new node requests a snapshot GetSnapshot(h_tip, root_SS) from any healthy node, receives the compressed snapshot Snap.tar.lz4 and Merkle proof π, and verifies to restore the local database.

[0111] III. Multi-chain Dynamic Access Process To allow business sub-chains to be used as soon as they are plugged in, the platform designs a chain description block (CDB) and a Merkle-DAG chain directory. The specific steps for sub-chain registration, verification, and routing are as follows: 1. CDB structure: CDB uses fixed-length header plus variable-length tail encoding, fields include chainID, createHeight, pk_chain, consensus type consType, block period period_ms, ACL access control list, and CDB signature sigCDB.

[0112] 2. Registration phase: The sub-chain submits (CDB || σ_http) through POST / cdb / register, the gateway verifies the signature, checks uniqueness and ACL semantics, then inserts newLeafHash into the Merkle-DAG and writes root_CDB' to the main chain, completes chain group routing table update.

[0113] 3. Routing phase: The orchestrator receives cross-chain calls {dstID, payload, authZ}, compares local chain directory root hash, verifies Merkle proof, matches ACL, parses routing, and establishes gRPC-mTLS tunnel.

[0114] In another embodiment of the present application, an electronic device structure is provided, which includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete communication with each other through the communication bus; a memory for storing a computer program; a processor for executing the program stored on the memory to implement the block chain consensus method of any method embodiment described above, which will not be described here.

[0115] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc.

[0116] The communication interface is used for communication between the terminal and other devices.

[0117] The memory can include a Random Access Memory (RAM) and can also include a non-volatile memory, such as at least one disk memory. Optionally, the memory can also be at least one storage device located away from the aforementioned processor.

[0118] The processor mentioned above can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; can also be a Digital Signal Processing (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components.

[0119] In another exemplary embodiment, a computer storage medium is also provided, and the program instructions, when executed by a processor, implement the steps of the blockchain consensus method described in any of the method embodiments. The storage medium can include a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.

[0120] Optionally, specific examples in the present embodiment can refer to the examples described in the above embodiments, and the present embodiment will not be repeated here.

[0121] It should be understood that the terms used herein are for the purpose of describing particular example embodiments only and are not intended to be limiting. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms "comprises", "comprising", "includes", "including" and "has" are inclusive and therefore specify the presence of stated features, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order in which they are described unless specifically indicated as such. It is also to be understood that additional or alternative steps can be employed.

[0122] The above description is merely exemplary of the application and is not intended to limit the application to the specific embodiments described. As such, modifications and variations are possible in light of the above teachings or can be acquired from practice of the application. For example, other combinations of the disclosed elements can be used and other elements can be utilized or operations can be modified without departing from the spirit of the application. It is therefore to be understood that, within the scope of the claims and their equivalents, the application can be practiced otherwise than as specifically described.

Claims

1. A BFT-based blockchain consensus method, characterized in that, The method comprises the following steps: If a main node of the main chain detects a node change transaction, a view lock is generated and broadcast to all consensus nodes of the main chain; each consensus node opens a reconstruction window according to the view lock, and a new private key shard and a new public key vector of each node are generated according to a distributed key generation protocol within the reconstruction window; The main node generates a new view according to the generated new public key vector, and broadcasts the new view to each consensus node; each consensus node verifies the new private key shard generated by the node according to the new public key vector of the new view, and sends a threshold signature to the main node after the verification of the new private key shard is passed; After receiving a predetermined number of threshold signatures, the main node generates an aggregated signature according to each threshold signature, generates a new block according to the aggregated signature and the new view, and updates the node list after the new block is confirmed by the consensus process, thereby completing the reconstruction of the node. 2.The blockchain consensus method of claim 1, wherein, The blockchain consensus method further comprises: The main node receives a registration transaction structure sent by the multi-chain gateway; the generation process of the registration transaction structure comprises: the multi-chain gateway receives a registration request of a business sub-chain, verifies a chain description block carried by the registration request, generates a new root hash of a Merkle-DAG if the verification is successful, and generates a registration transaction structure based on the new root hash; The main node confirms the registration transaction structure through a consensus process; after the registration transaction structure is confirmed, the multi-chain gateway distributes the business sub-chain to a corresponding target chain group and updates a routing table; after a legal cross-chain call is received by the chain group arranger, the cross-chain call is forwarded to the target sub-chain through the routing table. 3.The blockchain consensus method of claim 1, wherein, Before generating the view lock, the blockchain consensus method further comprises: If the node change transaction is a node joining transaction, the main node determines a target node newly added according to the node change transaction, and performs identity verification on the target node; if the verification is successful, the step of generating the view lock is performed.

4. The blockchain consensus method of claim 3, wherein, After updating the node list, the blockchain consensus method further comprises: If the node change transaction is a node joining transaction, the target node newly added obtains a snapshot file and a Merkle proof from any healthy node of the main chain; after the Merkle proof is verified successfully by the target node, the snapshot file is restored to a local key-value database. 5.The blockchain consensus method according to any one of claims 1 to 4, characterized in that, The consensus process performed by the main node comprises: The main node extracts at least one transaction from a memory pool; the transaction comprises a confirmation transaction of the new block and / or a registration transaction of the registration transaction structure; The main node calculates the digest value of each transaction, splices the digest values to generate an aggregated message authentication code, generates a PPREQ message according to the aggregated message authentication code, and sends the PPREQ message to each consensus node; each consensus node receives the PPREQ message, verifies the aggregated message authentication code of the PPREQ message, generates a first local signature of a transaction batch hash if the verification is passed, and sends the first local signature to the main node through a PREP message; The main node aggregates the first partial signatures into an aggregated prepared signature after receiving a predetermined number of first partial signatures, and broadcasts the aggregated prepared signature to each consensus node; wherein each consensus node generates a second partial signature of a transaction batch hash after passing the verification of the received aggregated prepared signature, and sends the second partial signature to the main node through a COMM message; The main node aggregates the second partial signatures into an aggregated submitted signature after receiving a predetermined number of second partial signatures, and generates a corresponding block; the block includes a block header and a block body, and each consensus node verifies the block header to determine that the block is a valid block. 6.The blockchain consensus method of claim 5, wherein, The process of generating the PPREQ message by the main node includes: The main node generates an output value and a verifiable proof according to the current view number, the current batch sequence number, the transaction batch hash, and the private key of the verifiable random function; The output value, the verifiable proof, and the aggregated message authentication code are used to generate a PPREQ message; wherein each consensus node receives the PPREQ message, verifies the verifiable proof through the public key of the verifiable random function, and stores the output value in the local entropy pool if the verification is passed.

7. The blockchain consensus method of claim 6, wherein, The blockchain consensus method further includes: If the consensus node of the main chain detects that the exchange master condition is met, the target output value of the last round of consensus process is obtained from the local entropy pool, the initial selection node is determined according to the target output value, and the new view request is sent to other consensus nodes of the main chain; Wherein, if each consensus node receives the new view request, obtains the target output value from the local entropy pool, and determines that the initial selection node is the new master node when the initial selection node determined is consistent with the initial selection node of the new view request, and enters a new view. 8.A BFT-based blockchain consensus system, characterized in that, It includes: The main node and each consensus node of the main chain; The main node is configured to generate a view lock when detecting a node change transaction, and broadcast the view lock to all consensus nodes of the main chain; Each consensus node is configured to open a reconstruction window according to the view lock, and generate a new private key shard and a new public key vector of each consensus node according to a distributed key generation protocol within the reconstruction window; The main node is further configured to generate a new view according to the generated new public key vector, and broadcast the new view to each consensus node; each consensus node is configured to verify the new private key shard generated by the node according to the new public key vector of the new view, and send a threshold signature to the main node after the verification of the new private key shard is passed; The main node is further configured to generate an aggregated signature according to each threshold signature after receiving a predetermined number of threshold signatures, generate a new block according to the aggregated signature and the new view, and update the node list after the new block is confirmed and submitted through the consensus process, to complete the reconstruction of the node. 9.The blockchain consensus system of claim 8, wherein, It further includes: A business sub-chain configured to send a registration request to a multi-chain gateway; The multi-chain gateway is configured to receive the registration request, and verify the chain description block carried by the registration request; if the verification is successful, a new root hash of a Merkle-DAG is generated, and a registration transaction structure is generated based on the new root hash; The main node is configured to receive a registration transaction structure transmitted by the multi-chain gateway, and confirm the registration transaction structure through a consensus process. The multi-chain gateway is further configured to, after the registration transaction structure is confirmed, distribute the business sub-chain to a corresponding target chain group, and update a routing table. A chain group orchestrator is configured to, after receiving a legal cross-chain call, forward the cross-chain call to a target sub-chain through the routing table. 10.The blockchain consensus system of claim 9, wherein, The chain group orchestrator is specifically configured to: receive a cross-chain call, and determine whether a target sub-chain of the cross-chain call is a legal registered sub-chain; if the target sub-chain is a legal registered sub-chain, and the cross-chain call has the permission to call the target sub-chain, a session tunnel with the target sub-chain is established, the payload data of the cross-chain call is transmitted to the target sub-chain through the session tunnel, and performance index data corresponding to the cross-chain call is transmitted to Prometheus.

Images