A blockchain consensus method and system based on BFT

Abstract

The application relates to a BFT-based blockchain consensus method and system; a main node in the scheme detects a node change transaction, generates a view lock and broadcasts the view lock to all consensus nodes, each consensus node generates a new private key fragment and a new public key vector within 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; after the new private key fragment is verified by each consensus node according to the new view, the consensus node sends a threshold signature to the main node; the main node generates an aggregated signature according to a predetermined number of threshold signatures, generates a new block according to the aggregated signature and the new view, and updates a node list after the new block is confirmed and submitted through a consensus process, thereby completing the reconstruction of the node. It can be seen that when the main chain detects a node change transaction, the rotation of the key and the reconstruction of the node can be completed within the reconstruction window, so that the member reconstruction can be safely carried out without shutdown; and the method can update the public and private keys when the members change, thereby improving the security of the key.

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 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 an operation script, lacking an automated management process, which leaves a security risk 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:

[0007] 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;

[0008] 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;

[0009] 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, and updates the node list after confirming the submission through a consensus process, thereby completing the reconstruction of the node.

[0010] Optionally, the blockchain consensus method further comprises:

[0011] 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;

[0012] 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.

[0013] Optionally, before generating the view lock, the blockchain consensus method further comprises:

[0014] 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.

[0015] Optionally, after updating the node list, the blockchain consensus method further comprises:

[0016] 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.

[0017] Optionally, the consensus process executed by the main node comprises:

[0018] 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;

[0019] The main node calculates a digest value of each transaction, concatenates the digest values to generate an aggregated message authentication code, and generates a PPREQ message according to the aggregated message authentication code and sends the PPREQ message to each consensus node; 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 main node through a PREP message.

[0020] The main 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 main node through a COMM message.

[0021] The main 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.

[0022] Optionally, the process of generating the PPREQ message by the main node includes:

[0023] 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.

[0024] The output value, the verifiable proof, and the aggregated message authentication code are used to generate a PPREQ message; wherein each consensus node verifies the verifiable proof by using the public key of the verifiable random function after receiving the PPREQ message, and if the verification is passed, stores the output value to a local entropy pool.

[0025] Optionally, the blockchain consensus method further includes:

[0026] If the consensus node of the main chain detects that the change of the main 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 initial selection node is sent to other consensus nodes of the main chain through a new view request;

[0027] 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 main node when the initial selection node determined is consistent with the initial selection node of the new view request, the initial selection node is determined as the new main node, and a new view is entered.

[0028] In a second aspect, the application provides a BFT-based blockchain consensus system, which includes:

[0029] the main node and each consensus node of the main chain;

[0030] 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;

[0031] 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 new private key shard is verified;

[0032] 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 a node list after the new block is confirmed by a consensus process, to complete reconstruction of the nodes.

[0033] Optionally, the system further comprises:

[0034] a business sub-chain configured to send a registration request to the multi-chain gateway;

[0035] the multi-chain gateway is configured to receive the registration request, and verify a chain description block carried by the registration request; if the verification is successful, generate a new root hash of a Merkle-DAG, and generate a registration transaction structure based on the new root hash;

[0036] the main 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;

[0037] the multi-chain gateway is further configured to assign the business sub-chain to a corresponding target chain group after the registration transaction structure is confirmed, and update a routing table;

[0038] 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.

[0039] Optionally, the chain group orchestrator is specifically configured to:

[0040] Receiving a cross-chain call, judging 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, and the payload data of the cross-chain call is sent to the target sub-chain through the session tunnel; and performance index data corresponding to the cross-chain call is sent to Prometheus.

[0041] The above technical solution provided by the embodiments of the present application has the following advantages compared with the prior art: the present application provides a BFT-based blockchain consensus method and system; in the present solution, 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 shard and a new public key vector of each consensus node within the reconstruction window; the master node generates a new view according to the generated new public key vector and broadcasts it to each consensus node, and each consensus node sends a threshold signature to the master node after the new private key shard is verified according to the new public key vector of the new view, the master 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, and updates the node list after confirming the submission through the consensus process, completing the reconstruction of the node. It can be seen that in the present application, when the main chain detects a node change transaction, the key rotation and node reconstruction can be completed within the reconstruction window, so that the member reconstruction can be safely performed without stopping. Moreover, the public and private keys can be updated when the members change, improving the security of the keys. BRIEF DESCRIPTION OF DRAWINGS

[0042] 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.

[0043] 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, and obviously, other drawings can also be obtained by those skilled in the art without creative labor.

[0044] 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, and elements with the same reference numerals in the drawings represent similar elements, unless otherwise specified, and the drawings do not constitute a proportional limitation.

[0045] Figure 1 A BFT-based blockchain consensus method flowchart provided by the embodiments of the present application;

[0046] Figure 2 A specific consensus system architecture diagram is provided for the embodiments of the present application. DETAILED DESCRIPTION

[0047] To make the purposes, technical solutions, and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are 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 fall within the scope of protection of the present application.

[0048] The following disclosure provides many different embodiments, or examples, for implementing different structures of the application. For the purpose of simplicity, the elements and settings of the specific examples in the following are described. Of course, they are merely examples and are not intended to limit the application. Furthermore, the application can refer to the same or similar reference numerals in different examples. Such repetition is for the purpose of simplicity and clarity and does not indicate a relationship between the various embodiments and / or settings discussed.

[0049] 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 it is forced to submit an addition or deletion transaction on the chain, it also needs to open an additional round of 2f+1 voting and re-run the view to select the master, 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 the Cosmos-IBC (Inter-Blockchain Communication, Inter-Blockchain Communication Protocol), Polkadot-XCMP (Cross-Consensus Message Passing, Cross-Consensus Message Passing) and other protocols can do cross-chain transfer, but registering a new chain still needs to vote 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 the 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 verification, 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.

[0050] 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.

[0051] 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:

[0052] 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;

[0053] In the present application, when the node changes, a node change transaction is generated and submitted (Submit-Tx), which includes a JOIN transaction and a LEAVE transaction. The structure of the JOIN transaction is:

[0054] Tx_join = {type: “join”, pubKey: Pk_new, vrfSeed: Seed, meta: M, sig:Sig_new};

[0055] 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.

[0056] The structure of the LEAVE transaction is:

[0057] Tx_leave ={type:“leave”,nodeID:ID_old,reason:R,sig:Sig_old};

[0058] Wherein, Tx_leave is the structure of the LEAVE transaction, the transaction type type is leave, the unique identifier nodeID of the exit node is ID_old, the reason reason for exiting is R, and the signature sig of the exit node to the transaction content is Sig_old.

[0059] 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 exit node N_old.

[0060] The current master node P of the main chain polls the memPool_member every Δ_prepare (polling interval); when the first node change transaction is detected, a view lock ViewLock is generated immediately, specifically: ViewLock = {viewID:v, txHash:h_tx, window:Δ_rcfg, ts:t0, sig:SigP};

[0061] Wherein, the view number viewID is v, the hash value txHash of the member transaction changed this time 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 master node is SigP.

[0062] After the master node generates the view lock ViewLock, it is group broadcasted to all consensus nodes. After receiving the ViewLock, the consensus node suspends the local "normal transaction packing" thread for Δ_rcfg milliseconds, thereby providing a stable window for subsequent threshold key rotation, while ensuring that the main chain can still output blocks containing system transactions. Moreover, 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, the member change request is directly rejected.

[0063] 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 with each other 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, so as to facilitate subsequent auditing; the old private key share share_i is immediately subjected to a memory clearing process. Moreover, to prevent network partition from introducing inconsistencies, if a node does not receive sufficient (2f+1) response packets within Δ_dkg (the timeout time of DKG), the master node will roll back this DKG and record a failedReconfig event (reconstruction failure event) on the chain, and then the timer will retrigger the steps of the reconstruction window.

[0064] S102, 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 fragment 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 fragment is verified;

[0065] In the present application, after the rotation is completed, each node generates a new private key fragment 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}. Wherein the view number of the new view viewID is v+1, and the payload data payload is Tx_join / leave.

[0066] 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 fragment share_i'; if the check is passed, the corresponding threshold signature vote_i' is generated for the new view, and each consensus node sends the threshold signature to the master node.

[0067] S103, the master 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, and updates the node list after confirming the submission through the consensus process, completing the reconstruction of the node.

[0068] In the present application, after the master node receives a predetermined number of threshold signatures, it will generate an aggregated signature according to each threshold signature. Wherein 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 2f+1 threshold signatures are successfully aggregated, an aggregated signature AggSig is generated. The master node packs 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, confirms it through the BFT-X consensus process, and 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. Wherein, the member list NodeSet is the member list after the completion of node reconstruction, such as the member list after adding new nodes or deleting exiting nodes.

[0069] In summary, in the present application, the JOIN / LEAVE transaction is directly embedded into the consensus process. When the main chain detects the node change transaction, the key rotation is completed through the "reconstruction window + Pedersen-DKG + threshold signature" pipeline, the old and new keys are switched atomically, the main chain is normally block, the business is completely unaware, the member reconstruction is zero downtime, and the public and private keys are updated when the member changes, improving the security of the key.

[0070] 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 main node determines the 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 performed.

[0071] In the present application, if the node change transaction is a node joining transaction, it means that there is a newly added 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 the identity verification and state synchronization baseline. In the present application, when the target node is identity verified, the following steps can be included:

[0072] 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.

[0073] 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 added, providing trusted parameters for subsequent key rotation and snapshot synchronization. The specific input data and output data of this algorithm are as follows:

[0074] 1) Input: no data (read-only interface), establish a two-way authentication connection with any main chain node through mTLS (Mutual Transport Layer Security, Mutual Transport Layer Security).

[0075] 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.

[0076] The specific algorithm process of this algorithm is as follows:

[0077] function getHeaderTip(): (Algorithm function to get the latest block header and state snapshot root of the main chain)

[0078] Step 1: Connection Establishment: Establish a secure channel with the main chain node using mTLS (TLS 1.3 mutual authentication):

[0079] conn ← mTLS_connect(peer_address) (Connects to the specified peer address peer_address using the mTLS security protocol and establishes a secure channel conn).

[0080] Step 2: Request the latest block header: Send a request message `GetHeaderTipRequest` (a request message to retrieve the latest block header and state snapshot root of the main chain), requesting the node to return its latest height and block header information:

[0081] send(conn, GetHeaderTipRequest{})

[0082] response ← recv(conn) (receives the response from the connection conn and stores it in the response)

[0083] The response contains {height, header, AggSig};

[0084] h_tip ← response.height (extracts the block height from the response and assigns it to the h_tip variable);

[0085] Header ← response.header / / Header contains viewID, seq, hash(BatchTx), AggPrepare, AggCommit, VRF_out; (extracts the complete block header from the response and assigns it to the Header variable)

[0086] AggSig ← response.AggSig / / (Extracts the aggregate signature AggSig from the response and assigns it to the variable AggSig)

[0087] root_SS ← Header.stateRoot / / (Extract the state tree root hash stateRoot from the block header and assign it to the root_SS variable)

[0088] Step 3: Verify the aggregate signature: Use the public threshold key PK generated in the previous round to verify the validity of the AggSig signature on the Header.

[0089] if not verifyThresholdSignature(PK, Header, AggSig):

[0090] Raise Exception("Invalid block signature") (If the verification of AggSig by the threshold signature verification function verifyThresholdSignature and the public threshold key PK fails, an "Invalid block signature" exception will be raised.)

[0091] / / Step 4: Return value

[0092] return (h_tip, root_SS, Header, AggSig)

[0093] It should be noted that the verification threshold signature ensures that h_tip and root_SS come from legitimate blocks, preventing malicious nodes from forging the state baseline; the block header contains VRF output and threshold signature fragments, which new nodes can use in subsequent view leader elections; the mTLS connection ensures two-way authentication, preventing man-in-the-middle attacks.

[0094] b) Zero Trust Access: The target node N_new uses the chain root certificate to connect to the main chain node and initiates a TLS-1.3 two-way handshake; the connection can only continue if the handshake is successful, otherwise the connection is immediately dropped.

[0095] c) Identity binding: To prevent Sybil attacks, JOIN requests must simultaneously submit on-chain identity credentials, which can be in the form of staked amount or an X.509 certificate issued by an authorized institution; if not provided, the request will be immediately discarded.

[0096] In another embodiment of this application, after updating the node list, the blockchain consensus method further includes: if the node change transaction is a node addition transaction, the newly added target node obtains a snapshot file and Merkle proof from any healthy node on the main chain. After the target node successfully verifies the Merkle proof, it restores the snapshot file to the local key-value database.

[0097] In this application, in the JOIN scenario, the newly joined target node sends a request GetSnapshot(h_tip, root_SS) to any healthy node. Among them, GetSnapshot(h_tip, root_SS) is a secure snapshot synchronization function, through which the latest system state compression snapshot can be provided for the newly joined node, so that it can quickly synchronize to the current state without replaying the complete transaction history. The input data of this function is: the latest height h_tip and state root root_SS (from getHeaderTip()), and the identity credentials of the requester (used to prevent unauthorized synchronization). The output data is: (SnapFile, ProofChunks): SnapFile is the compressed snapshot file Snap.tar.lz4, and ProofChunks is the Merkle proof array of each snapshot chunk.

[0098] After the node receives the request, it will search the local snapshot warehouse and return the compressed snapshot file Snap.tar.lz4 and its Merkle (Merkle tree) proof π. After the target node N_new verifies that π matches root_SS, the snapshot is restored to the local key-value database, which can be LevelDB (Log-Structured Merge Tree Database, embedded key-value storage), RocksDB (Rocks DataBase, storage engine), etc., and then the latest height h_tip is written to the local metadata state.json. At this point, N_new officially enters the consensus cycle. The entire addition and deletion process has no visible downtime to the outside world, and only suspends the packaging of new business transactions during the reconstruction window.

[0099] Here is a specific description of the secure snapshot synchronization function:

[0100] function GetSnapshot(h_tip, root_SS):

[0101] Step 1: Establish a secure connection through mTLS and verify the identity of the requester:

[0102] conn ← mTLS_connect(requester) (connect to the requester using mTLS two-way authentication)

[0103] verifyCredential(requester.cred) (verify the identity credentials cred of the requester)

[0104] Step 2: Find the snapshot file of height h_tip:

[0105] snapshot_meta ← lookupSnapshotMetadata(h_tip)(According to h_tip, find the corresponding snapshot metadata snapshot_meta)

[0106] if snapshot_meta is None:

[0107] raise Exception("Snapshot not found")(If snapshot metadata does not exist, throw an exception "Snapshot not found")

[0108] Step 3: Read the snapshot by block and calculate the block-level Merkle proof:

[0109] SnapFile ← []

[0110] ProofChunks ← [](Initialize an empty list to store the snapshot file SnapFile and the proof block ProofChunks, [] represents an empty list)

[0111] for each chunk c in snapshot_meta.chunks:

[0112] data ← readChunkFromStorage(c)(For each data block c in snapshot_meta.chunks, execute the following operations: read the data of data block c from the storage, and assign the read data to the data variable)

[0113] / / Calculate the Merkle proof π_i for each block, such that verifyProof(π_i, data.hash, root_SS) == true, where verifyProof is the verification proof function, data.hash is the hash value of the above data data.

[0114] π_i ← computeMerkleProof(c.index, snapshot_meta.merkleTree)(Calculate the Merkle proof MerkleProof of the i-th data block and assign it to the π_i variable, c.index is the index position of the current data block in the Merkle tree, snapshot_meta.merkleTree is the Merkle tree structure in the snapshot metadata)

[0115] append(SnapFile, data) (appends the data chunk data to the snapshot file list SnapFile)

[0116] append(ProofChunks, π_i) (appends the Merkle proof π_i to the proof chunk list ProofChunks)

[0117] Step 4: Returns the compressed snapshot and proof

[0118] return (compress(SnapFile), ProofChunks); where compress(SnapFile) denotes the compressed snapshot file.

[0119] Client processing flow:

[0120] function InstallSnapshot(SnapFile, ProofChunks, root_SS) (function InstallSnapshot is the snapshot installation function):

[0121] Step 1: Decompress the snapshot and iterate by block:

[0122] for i from 0 to len(SnapFile)-1: (loops through all data chunks in the snapshot file, len(SnapFile) is the length of the SnapFile list)

[0123] blockData ← decompressBlock(SnapFile[i]) (decompresses the i-th data chunk in the compressed snapshot file and assigns the decompressed data to blockData)

[0124] proof ← ProofChunks[i] (gets the i-th Merkle proof from the proof chunk list and assigns it to the proof variable)

[0125] / / Step 2: Verify the existence of the block hash in the global state tree:

[0126] if not verifyProof(proof, hash(blockData), root_SS):

[0127] raise Exception("Snapshot block verification failed") (if the proof verification fails, throw an "Snapshot block verification failed" exception)

[0128] / / Step 3: Write to local key-value database

[0129] applyToLocalDB(blockData) (apply the verified data block to the local key-value database DB)

[0130] / / Step 4: Write to metadata state.json

[0131] updateLocalState(height=h_tip) (update the local state file to record the current height of synchronization)

[0132] As can be seen from the above, the embodiment can have the following beneficial effects by obtaining the snapshot file and the Merkle proof, and restoring the snapshot file to the local key-value database after the Merkle proof is verified successfully:

[0133] 1. Block-based Merkle proof: the state tree is divided into fixed-size blocks, each block contains a complete sub-tree and its sub-root hash, and there is no cross-dependence between blocks, and the proof chain can be verified independently.

[0134] 2. Fraud detection: attach a Merkle proof pi to each block, so that the receiver can verify that the block root is under the global state root during the download process. If a block is invalid, it can be discarded immediately and a request for another node is made, effectively avoiding delays by malicious nodes.

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

[0136] In another embodiment of the present application, the blockchain consensus method further comprises:

[0137] The main node receives the registration transaction structure sent by the multi-chain gateway; wherein the generation process of the registration transaction structure comprises: the multi-chain gateway receives the registration request of the business sub-chain, and verifies the 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;

[0138] The main node confirms the registration transaction structure through the consensus process; wherein after the registration transaction structure is confirmed, the multi-chain gateway assigns the business sub-chain to the corresponding target chain group, and updates the routing table; wherein after the chain group composer receives a legal cross-chain call, the cross-chain call is forwarded to the target sub-chain through the routing table.

[0139] In the present application, in order to realize the plug and play of the business subchain and the deterministic routing of cross-chain calling, the present application designs a chain description block (CDB) and a registration-verification-routing three-stage mechanism matched therewith.

[0140] 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:

[0141] 0. chainID, 16B, adopts UUID-128, unique identifier of the chain, unique in the system;

[0142] 1. createHeight, 8B, block height of the main chain when the CDB is generated;

[0143] 2. pk_chain, 33B, subchain management public key (compressed elliptic curve format);

[0144] 3. consType, 1B, consensus type enumeration (00=BFT, 01=PoS, 02=ZK-Rollup…);

[0145] 4. period_ms, 4B, subchain block generation period, unit: millisecond;

[0146] 5. ACL (Access Control List), TLV (Tag-length-value), multi-segment access control list, variable length; each segment label (1B) + length (2B) + content (nB);

[0147] 6. sigCDB, 64B, signature generated by the subchain management agency using Ed25519 on the first 0-5 fields.

[0148] Among them, field 5 uses TLV (Tag-Length-Value) format, which facilitates subsequent addition of permission types without damaging compatibility; field 6 covers only 0-5 fields, 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.

[0149] In the present application, when registering the business subchain, a registration request needs to be sent to the multi-chain gateway, and the registration request includes the chain description block submitted by the business subchain through POST / cdb / register. Specifically, the registration process of the business subchain includes the following steps:

[0150] 1) The service sub-chain submits a registration request as (CDB || σ_http), where σ_http is the mTLS session layer signature;

[0151] 2) Verify the session layer signature: verifySig(pk_chain, sigCDB, hash(CDB[0-5])), where verifySig is a function for verifying the signature, and hash(CDB[0-5]) is the hash value calculated for the first 5 fields of CDB; if the verification fails, return 4XX (client error status code) immediately.

[0152] 3) Perform a uniqueness check on the service sub-chain, and do GetIfExists(chainID) (a function for querying whether the 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, reject duplicate registration.

[0153] 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;

[0154] 5) Merkle-DAG insertion:

[0155] Calculate newLeafHash = H(CDB‖root_CDB‖ts_now); where newLeafHash is the new leaf node hash, H() represents the hash function, root_CDB represents the root hash value of the current Merkle-DAG structure, and ts_now is the 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:

[0156] RegisterTx = {type: reg, leaf: newLeafHash, root: root_CDB′};

[0157] 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 facilitate the chain cluster orchestrator to search.

[0158] 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.

[0159] 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:

[0160] 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;

[0161] 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;

[0162] 3) Permission check: matchACL (ACLdst, authZ); if not passed, return "Permission-Denied"; 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.

[0163] 4) Route resolution: obtain the target chain group entry (IP:Port) from the leaf node field clusterID→routeTable;

[0164] 5) Tunnel establishment: create a session tunnel tunnelID using gRPC-mutualTLS, and transmit the payload to the target sub-chain Biz-Chain;

[0165] 6) Telemetry feedback: call pushMetric() to send delay, throughput, and other indicators to Prometheus for subsequent elastic expansion decision-making.

[0166] Among them, 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. This scheme designs pushMetric() 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).

[0167] The algorithm steps of this function include:

[0168] function pushMetric(metricName, labels, value, timestamp):

[0169] Step 1: Compose Prometheus text format:

[0170] # metric_line: example 'chain_request_latency_ms{src="chainA",dst="chainB",result="success"} 42.7' (comment line, shows an example of Prometheus text format)

[0171] label_str ← join([key + "="" + val + """ for (key,val) in labels],',') (converts the labels dictionary to a comma-separated string, where label_str is the generated label string, join() is the join function, and [key + "="" + val + """ for (key,val) in labels] is a list comprehension that generates a key="value" formatted string for each label key-value pair;

[0172] metric_line ← f"{metricName}{{{label_str}}} {value}" (combines the metric name, label string, and value to form a complete metric line)

[0173] if timestamp is not None:

[0174] metric_line ← metric_line + f" {timestamp}" (if the timestamp is not empty, add it to the end of the metric line)

[0175] body ← metric_line + "“ adds a newline character at the end of the metric line to form the complete HTTP request body”

[0176] "

[0177] Step 2: Send an HTTP POST to the Pushgateway:

[0178] url ← "http: / / pushgateway.example.com / metrics / job / chain_orchestrator" / / Use a gRPC or HTTP client to send; here we use HTTP as an example: http_post(url, body)

[0179] / / Step 3: Optional error handling and retries

[0180] if response.status_code!= 200:

[0181] retry or log error(If the HTTP response status code is not equal to 200 (success), perform a retry or log an error message.)

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

[0183] The main process is as follows:

[0184] 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 benchmark shared by the entire network.

[0185] 2. Token generation and registration: Data providers register access policies on the chain and generate permission tokens for requesters. The token includes authorization scope, validity period, and remaining available times, etc. After signing, the association with the policy ID is recorded on the chain.

[0186] 3. Cross-chain request processing: When a cross-chain request {dstID, payload, authZ} arrives at the chain group orchestrator:

[0187] Call syncRoot() to align the local chain directory root;

[0188] Verify the existence of dstID in the chain directory through VerifyProof(π, root_CDB_local);

[0189] Perform token verification and basic policy evaluation, and reject unauthorized or exceed permission requests;

[0190] Call the target sub-chain according to the access result output by the policy engine, and record the access event and report the performance indicators through pushMetric().

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

[0192] 5. Permission token adjustment: After switching policies, adjust the tokens of unfinished or subsequent requests to ensure that the permission scope of the token is consistent with the target policy.

[0193] As can be seen from the above, in the present application, plug-and-play of multiple chains is achieved. Through the chain description block (CDB) and the Merkle-DAG chain directory, a business sub-chain can be automatically indexed and assigned to the corresponding chain group after being registered once. The directory root hash is written to the main chain regularly, and a unified and verifiable chain view is shared across the network, realizing deterministic routing and ACL permission control.

[0194] In another embodiment of the present application, the consensus process performed by the master node includes:

[0195] 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;

[0196] The master node calculates the digest value of each transaction, concatenates the digest values to generate an aggregated message authentication code, and generates a PPREQ message according to the aggregated message authentication code and sends it to each consensus node; wherein each consensus node receives the PPREQ message, verifies the aggregated message authentication code of 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;

[0197] The master node receives a predetermined number of first local signatures, aggregates the first local signatures into an aggregated preparation signature, and broadcasts the aggregated preparation signature to each consensus node; wherein each consensus node verifies the received aggregated preparation signature, generates a second local signature of the transaction batch hash, and sends the second local signature to the master node through a COMM message;

[0198] The master node receives a predetermined number of second local signatures, aggregates the second local signatures into an aggregated submission 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.

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

[0200] In this application, the BFT-X consensus process includes three core messages, and each message type is described as follows:

[0201] 1) PPREQ (Pre-Prepare-Request):

[0202] {view, seq, BatchTx, VRF_out, π_VRF, MAC_agg}

[0203] 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.

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

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

[0206] 2) PREP (Prepare-Vote)

[0207] {view, seq, hBatch, σ_i}

[0208] Wherein, hBatch is the transaction batch hash, hBatch=H(BatchTx); and σ_i is the threshold signature fragment of node i on hBatch in different stages, that is, the local signature.

[0209] Function: Each consensus node gives a threshold signature fragment of hBatch=H(BatchTx), which means "ready".

[0210] 3) COMM (Commit-Vote, commit vote)

[0211] {view, seq, hBatch, σ_i}

[0212] Action: After collecting enough PREP, each consensus node signs again to confirm that it is "commitable".

[0213] In the present application, when the master node performs the consensus process, it first takes m transactions tx1…tx_m from the memory pool mempool in batches, and the present application refers to the m transactions as a transaction batch BatchTx; wherein the transactions in the memory pool include the confirmation transactions of the new block, the registration transactions of the registration transaction structure, etc. in the above embodiments, 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 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) once.

[0214] 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 the present batch, and all copies can replay the above process to verify the MAC agg of the PPREQ message, and the network bandwidth saving rate is approximately 1-(16+8) / m, which can reduce the packet body overhead by about 70% when m≥64. By batch packaging and MAC aggregation, one aggregated MAC can be used to verify a batch of transactions, reducing bandwidth and CPU (Central Processing Unit, Central Processing Unit) consumption.

[0215] In another embodiment of the present application, the process of generating a PPREQ message by the master node includes:

[0216] 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 the private key of the verifiable random function; generates a PPREQ message from the output value, the verifiable proof, and the aggregated message authentication code; wherein each consensus node receives the PPREQ message, verifies the verifiable proof by the public key of the verifiable random function, and stores the output value to the local entropy pool if the verification is passed.

[0217] In the present application, a verifiable random number needs to be added in the PPREQ message to ensure that the subsequent master selection is unpredictable and non-manipulable. Specifically, at the beginning of each round of consensus, the master 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 verifies the correctness of π_VRF using the pre-announced public key (VRF public key) of the verifiable random function, and after verification, appends VRF_out to the local entropy pool randPool.

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

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

[0220] If the master node collects 2f+1 local signatures σ_i, it will aggregate the 2f+1 local signatures σ_i into an aggregated prepare signature AggPrepare, and broadcast the aggregated prepare signature together with the transaction batch hash hash(BatchTx) to each consensus node. Each consensus node receives the aggregated prepare signature AggPrepare and verifies AggPrepare, and then 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.

[0221] If the master node receives 2f+1 second partial signatures, it aggregates the 2f+1 second partial signatures to generate an aggregated commitment signature AggCommit, and generates a block; the block includes a block header Header and a block body, the block body stores a real transaction batch, and the block header Header is specifically:

[0222] Header = {view, seq, hash(BatchTx), AggPrepare, AggCommit, VRF_out}.

[0223] All verifiers only need to do sha2-256 on Header to confirm that the block is valid. As can be seen, the two-stage 2f+1 signature aggregation into a threshold signature can compress the block header and speed up the signature verification.

[0224] 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 present application adopts the current leading FROST Schnorr threshold signature protocol as a specific implementation example, which provides two-round 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:

[0225] 1. Distributed key generation (Pedersen-DKG)

[0226] The key generation stage generates a group public key PK and n private key fragments sk_i. Pedersen DKG is adopted: each node selects a random polynomial p_i(x) and broadcasts the 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; send shares s_{i,j}=p_i(j) to each other, 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 fragment 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.

[0227] 2. FROST-TSIG signature process

[0228] FROST signatures consist of two rounds: commitment generation and signature sharing, with the signatures aggregated after the second round. The FROST protocol shortens threshold signing to two rounds of interaction, saving communication rounds compared to traditional Feldman threshold Schnorr signatures, while also supporting offline commitments and reducing the attack surface.

[0229] / / Round One: Nonce commitment

[0230] function Round1_GenerateCommitment(i, sk_i): (Function for node i to generate random numbers and commit during the first round)

[0231] / / Participant i randomly selects a hidden / bound random number

[0232] hiding_nonce_i ← RandomScalar() (Generates a hidden random number and assigns it to the variable hiding_nonce_i. RandomScalar() is a function that generates a random scalar value.)

[0233] binding_nonce_i ← RandomScalar() (Generates a binding random number and assigns it to the binding_nonce_i variable)

[0234] / / Calculate commitment

[0235] hiding_commitment ← g^hiding_nonce_i (Calculates the hidden commitment hiding_nonce and assigns it to the hiding_commitment variable)

[0236] binding_commitment ← g^binding_nonce_i (Calculates the binding commitment and assigns it to the binding_commitment variable)

[0237] / / Send the commitment to the coordinator (master node) and store the random number locally.

[0238] broadcastCommitment(i, hiding_commitment, binding_commitment) (broadcast node i's hidden commitment and binding commitment)

[0239] return (hiding_nonce_i, binding_nonce_i)

[0240] / / Round Two: Signature Share Generation

[0241] function Round2_SignShare(i, sk_i, nonce_i, msg, commitment_list): (defines the second round signature share generation function, msg is the message to be signed, commitment_list is the list of commitments of all nodes)

[0242] / / Compute auxiliary variables like binding factors

[0243] 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 compute binding factors, group_public_key is the group public key)

[0244] binding_factor ← binding_factor_for_participant(binding_factor_list, i) (gets the binding factor for the current node i from the binding factor list)

[0245] group_commitment ← compute_group_commitment(commitment_list, binding_factor_list) (computes the group commitment value, group_commitment is the group commitment variable, compute_group_commitment is the function to compute the group commitment)

[0246] lambda_i ← derive_interpolating_value(participant_list, i) (computes the interpolating coefficient for node i)

[0247] challenge ← compute_challenge(group_commitment, group_public_key, msg) (computes the signature challenge value)

[0248] (hiding_nonce, binding_nonce) ← nonce_i (Unpack the hidden and bound random numbers from nonce_i)

[0249] / / Calculate signature sharing z_i

[0250] sig_share ← hiding_nonce + binding_nonce * binding_factor + lambda_i * sk_i * challenge (calculate signature share z_i)

[0251] / / Send signature sharing to coordinator

[0252] sendSignatureShare(i, sig_share)

[0253] return sig_share (sends the signature share to the coordinator and returns the signature share).

[0254] / / Aggregation: Coordinator aggregates shares into final signature

[0255] The function `AggregateSignatures(commitment_list, msg, group_public_key, sig_shares)` (a function that aggregates the collected signature shares into a final signature; `AggregateSignatures` is the aggregated signature) is used to achieve this.

[0256] / / Calculate binding factor and group commitment

[0257] `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 that calculates the binding factors.

[0258] group_commitment ← compute_group_commitment(commitment_list, binding_factor_list), where group_commitment is the group commitment;

[0259] / / Aggregate signature z = Σ z_i

[0260] z ← 0

[0261] for each z_i in sig_shares:

[0262] z ← z + z_i

[0263] return (group_commitment, z) / / Schnorr signature (R, z) (initialize the aggregate signature z to 0, iterate over each signature share and accumulate it to the aggregate signature z, and return the (R, z) pair in the Schnorr signature format, where R represents the group commitment group_commitment).

[0264] In another embodiment provided in the application, the blockchain consensus method further comprises:

[0265] 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 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; wherein, if each consensus node receives the new view request, the target output value is obtained from the local entropy pool, and when the determined preliminary selected node is consistent with the preliminary selected node of the new view request, the preliminary selected node is determined as the new master node, and the new view is entered.

[0266] In the application, if the master node is invalid or times out, each consensus node can uniformly select a new master by means of the disclosed VRF output value when detecting that the exchange master condition is met.

[0267] Specifically, any consensus node in the main chain can determine that the exchange master condition is met when the master node does not broadcast PREP within timeout_prepare (the time threshold of the preparation stage) milliseconds, and can initiate a new view request NewViewReq to trigger the exchange master. When generating the new view request, the initiator takes the target output value VRF_out of the last round as a random seed, calculates the preliminary selected node newLeader=H(VRF_out) mod n of the new master node, and declares it in NewViewReq.

[0268] All other nodes receive NewViewReq, independently reproduce newLeader calculation; if the newLeader calculated is consistent with the newLeader in NewViewReq, it is jointly determined that the newLeader is the new master node, and enters the new view, in this way, each node does not need to do 2f+1 voting again, because VRF_out has been confirmed by the whole network and has unpredictability, the old master cannot manipulate or bias this master selection in advance, ensuring that the view switching is fair and efficient, and this VRF_out is a function module for realizing non-voting master replacement when the master node is offline.

[0269] In the present application, formal safety proof is also provided, and the specific proof 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 "eventual-commit" (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 into 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 eventual commitability of the ledger will not be destroyed.

[0270] 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 can complete view switching 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, can perform Poly1305 verification only once for a batch of transactions, and can compress 2f+1 signatures of Prepare / Commit into a single aggregated signature by threshold signature, greatly reducing the bandwidth and CPU overhead. Further, the present application can realize formal proof safety, model the whole process by TLA+, and mechanically prove the activity and consistency in Isabelle / HOL, and even if the nodes are dynamically added or deleted or multiple links are connected, the ledger safety will not be destroyed under the premise of f<n / 3, so that the performance, robustness and mathematical level safety are all superior to the existing BFT blockchain scheme.

[0271] In another embodiment of the present application, a BFT-based blockchain consensus system structure diagram is provided, which comprises:

[0272] a master node and each consensus node of the main chain;

[0273] 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 within the reconstruction window;

[0274] 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 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 master node after the verification of the new private key shard is passed;

[0275] 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 the node list after the new block is confirmed and submitted through a consensus process, thereby completing the reconstruction of the node.

[0276] In another embodiment of the present application, the system further comprises:

[0277] a business sub-chain configured to send a registration request to a multi-chain gateway;

[0278] the multi-chain gateway is configured to receive the registration request, and verify a 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;

[0279] a master node configured to receive the registration transaction structure sent by the multi-chain gateway, and confirm the registration transaction structure through a consensus process;

[0280] the multi-chain gateway is further configured to assign the business sub-chain to a corresponding target chain group after the registration transaction structure is confirmed, and update a routing table;

[0281] 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.

[0282] In another embodiment of the present application, the chain group orchestrator is specifically configured to:

[0283] Receiving a cross-chain call, judging 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 permission to call the target sub-chain, a session tunnel with the target sub-chain is established, and the payload data of the cross-chain call is sent to the target sub-chain through the session tunnel; the performance index data corresponding to the cross-chain call is sent to Prometheus.

[0284] Referring to Figure 2 , in order to clearly illustrate the present scheme, a specific consensus system architecture diagram is provided, as shown in the figure, the system includes four types of core components:

[0285] Master-Peers: Master-Peers includes master nodes and other consensus nodes, responsible for persistently saving global ledger, executing improved BFT-X consensus algorithm, maintaining VRF random master selection service and threshold key rotation service in each view round. Trigger threshold key rotation when detecting member changes. 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.

[0286] 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 to do cross-chain permission verification; after receiving a legal cross-chain call, the call is forwarded to the target sub-chain through the internal gRPC routing table, and the performance index is pushed to the Prometheus monitoring endpoint.

[0287] Gateway: located at the edge of the system and exposing a unified REST (Representational State Transfer) / GRPC (Google Remote Procedure Call) entrance. The multi-chain gateway receives the chain description block CDB submitted by the business sub-chain and does 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".

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

[0289] As Figure 2 shown, the overall system startup process is as follows:

[0290] 1. Deploy and start the main chain, and the consensus node enters the improved BFT-X working state;

[0291] 2. Each business sub-chain submits CDB to the multi-chain gateway in turn to complete registration, and the gateway distributes the sub-chain to different chain groups according to the strategy; and the hash is written into the main chain;

[0292] 3. When an external node needs to join or exit the main chain, the node initiates a JOIN / LEAVE member change transaction;

[0293] 4. After the member change transaction reaches consensus, the main chain automatically updates the member view and completes the threshold key rotation;

[0294] 5. When cross-chain calls occur between any chains, the chain group arranger checks the Merkle-DAG chain directory, establishes a communication link after verifying the authority, and forwards the call.

[0295] Based on the above embodiment, the overall process, dynamic node addition and deletion process, and multi-chain dynamic access process designed by the application are summarized and described as follows:

[0296] I. Overall process:

[0297] The improved BFT-X consensus protocol introduces batch MAC aggregation, VRF randomness, and threshold signature on the basis of the classic PBFT / Tendermint. Its main message types include:

[0298] PPREQ: Proposed by the main node, the transaction batch is accompanied by VRF output and aggregated MAC;

[0299] PREP: The replica does threshold signature fragments on the transaction batch hash, indicating "ready";

[0300] COMM: The replica signs again after collecting enough Prepare votes, confirming that it can be submitted.

[0301] To reduce bandwidth consumption, the main node concatenates the 8-byte SIPHASH digest of m transactions tx_1⋯tx_m and executes Poly1305 once to generate an aggregated MAC, and all replicas replay this process to verify the MAC. The VRF output is used as the seed for the fair selection of the next view, preventing the main node from manipulating the 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".

[0302] II. Dynamic node addition and deletion process:

[0303] Dynamic node addition and deletion includes pre-inspection, transaction submission, window reconstruction, distributed key generation (DKG), view update, and new node snapshot synchronization.

[0304] 1. Pre-check phase: The new node N_new obtains the latest height h_tip and state snapshot root_root_SS of the main chain by a read-only gRPC call getHeaderTip(), and completes a two-way TLS handshake and submits on-chain identity credentials to prevent Sybil attacks.

[0305] 2. Submit JOIN / LEAVE transactions: The new node broadcasts Tx_join={type: "join", pubKey: Pk_new, vrfSeed: Seed, meta: M, sig: Sig_new} to the mempool; the exiting node submits Tx_leave.

[0306] 3. Reconstruct the window: The main node periodically polls memPool_member, detects the first member change transaction, generates ViewLock={viewID, txHash, window, ts, sig} broadcast, and notifies all nodes to enter the key rotation window.

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

[0308] 5. View update and block submission: The main node constructs NewView={viewID+1, payload: Tx_join / leave, PK'}, aggregates the threshold signature AggSig, and packs it into a new block.

[0309] 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 it to restore the local database.

[0310] Three, multi-chain dynamic access process

[0311] In order to make the business sub-chain like a USB device that can be used as soon as it is plugged in, the platform designs a chain description block (CDB) and a Merkle-DAG chain directory. The specific steps of sub-chain registration, verification and routing are as follows:

[0312] 1. CDB structure: CDB adopts 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.

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

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

[0315] 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;

[0316] The memory is used to store a computer program.

[0317] The processor is used to execute the program stored on the memory, and implement the blockchain consensus method described in any of the above method embodiments, which will not be described here.

[0318] The communication bus mentioned in the above terminal 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.

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

[0320] 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.

[0321] The processor described above can be a general processor, including a central processing unit (CPU), a network processor (NP), etc.; can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component.

[0322] In another exemplary embodiment, a computer storage medium is also provided, and the program instructions are executed by the processor to 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.

[0323] Optionally, specific examples in the embodiments can refer to the examples described in the above embodiments, and the embodiments will not be described here again.

[0324] It should be understood that the terms used herein are for the purpose of describing specific 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.

[0325] The above description is merely one specific example embodiment of the application, which enables those skilled in the art to understand or implement the application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the application. Therefore, the application will not be limited to these embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A BFT-based blockchain consensus method, characterized in that, The method comprises the following steps: 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; 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 through a consensus process, thereby completing the reconstruction of the node; The consensus process executed by the main node comprises: The main node extracts at least one transaction from the memory pool; the transaction includes a confirmation transaction of the new block and / or a registration transaction structure; The main node calculates the digest value of each transaction, generates an aggregated message authentication code by splicing the digest values, and sends a PPREQ message to each consensus node according to the aggregated message authentication code; each consensus node verifies the aggregated message authentication code of the PPREQ message after receiving the PPREQ message, and 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; After receiving a predetermined number of first local signatures, the main node aggregates the first local signatures into an aggregated preparation signature, and broadcasts the aggregated preparation signature to each consensus node; each consensus node generates a second local signature of the transaction batch hash after verifying the received aggregated preparation signature, and sends the second local signature to the main node through a COMM message; After receiving a predetermined number of second local signatures, the main node aggregates the second local signatures into an aggregated submission 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. 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 a 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 a chain group orchestrator, the cross-chain call is forwarded to a 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 master 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 executed.

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, and restores the snapshot file to a local key-value database after the target node successfully verifies the Merkle proof. 5.The blockchain consensus method of claim 1, wherein, The process of generating the PPREQ message by the master node comprises: 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 the private key of the verifiable random function; The output value, the verifiable proof, and the aggregate 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 a local entropy pool if the verification is successful. 6.The blockchain consensus method of claim 5, wherein, The blockchain consensus method further comprises: 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, the preliminary selected node is determined to be the new master node, and a new view is entered. 7.A BFT-based blockchain consensus system, characterized in that, Comprise: The master node and each consensus node of the main chain; The master node is configured to generate a view lock when a node change transaction is detected, 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 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 master node after the new private key shard is verified successfully; The master node is further configured to receive a predetermined number of threshold signatures, generate an aggregate signature according to each threshold signature, generate a new block according to the aggregate signature and the new view, and update the node list after the new block is confirmed by the consensus process, complete the reconstruction of the node; The consensus process executed by the master node comprises: The master node extracts at least one transaction from the memory pool; wherein the transaction comprises a confirmation transaction of the new block, and / or a registration transaction of a registration transaction structure; The main node calculates a digest value of each transaction, concatenates the digest values to generate an aggregated message authentication code, and generates a PPREQ message according to the aggregated message authentication code and sends the PPREQ message to each consensus node; wherein each consensus node receives the PPREQ message, verifies the aggregated message authentication code of 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 main node through a PREP message; The main 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 main node through a COMM message; The main node receives a predetermined number of second local signatures, aggregates the second local signatures into an aggregated commitment 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. 8.The blockchain consensus system of claim 7, wherein, Further comprising: 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, and if the verification is successful, generate a new root hash of a Merkle-DAG and generate a registration transaction structure based on the new root hash; The main node is configured to receive the registration transaction structure sent by the multi-chain gateway and confirm the registration transaction structure through 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 is configured to forward a cross-chain call to a target sub-chain through the routing table after receiving a legal cross-chain call. 9.The blockchain consensus system of claim 8, wherein, The chain group orchestrator is specifically configured to: receive a cross-chain call, determine 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, establish a session tunnel with the target sub-chain, send the 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.

Images