Validation method for blockchain network and related device

Abstract

The present application provides a validation method for a blockchain network, applied to a validation system of a blockchain network. The system validates transactions by pledging tokens, the system comprises multiple decentralized application nodes and a distributed validator technology (DVT) network, and the sum of tokens held by the multiple decentralized application nodes and used for pledging meets the pledging requirement. The method comprises: multiple decentralized application nodes aggregating their respective public keys by means of a key aggregation algorithm to generate a public address of a blockchain network, and respectively transferring tokens to the public address; the multiple decentralized application nodes transferring the tokens of the public address to a pledge account, and generating multiple pledge private keys; distributing the multiple pledge private keys to a DVT network; and the multiple decentralized application nodes using their respective pledge private keys to sign a transaction, obtaining an aggregated signature, and then providing the aggregated signature to a consensus node so as to participate in transaction validation. Thus, the trusted pledge range is expanded, avoiding the restriction of usage scenarios by pledge conditions.

Description

A blockchain network verification method and related equipment

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on June 29, 2023, with application number 202310786225.3, and with the invention name “A blockchain verification method and related system”, and claims priority to the Chinese patent application filed with the State Intellectual Property Office on August 31, 2023, with application number 2023111175704, and with the invention name “A blockchain network verification method and related equipment”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of blockchain technology, and in particular to a blockchain network verification method, system, computing device cluster, computer-readable storage medium, and computer program product. Background Art

[0003] A blockchain network is a network where multiple nodes jointly maintain a continuously growing, linked list ledger (also called a blockchain, or simply a blockchain) consisting of time-stamped and ordered blocks of recorded data, using a consensus mechanism based on cryptographic technology. Any number of nodes in a blockchain network can use cryptographic algorithms to calculate and record data exchanged over a period of time into a block. They then generate a fingerprint for this block, which is used to link and verify the next data block. All participating nodes in the blockchain network jointly determine whether the record is true.

[0004] Blockchain networks can be categorized as permissionless or permissioned, depending on the type of nodes involved. Permissionless networks, also known as trustless or public blockchains, are open networks where every user can participate in the consensus process used to verify transactions and data. To ensure secure and stable operation, permissionless blockchain networks employ a variety of consensus algorithms and economic incentives to attract large user participation.

[0005] Traditional permissionless blockchain networks typically consist of three components: a consensus client, an execution client, and a validation client. The validation client interacts with the consensus client of the consensus layer (CL) to complete block validation, thereby benefiting participating users. In many consensus algorithms, participants are typically required to possess a certain number of tokens and stake them to participate in the block validation process. This significantly limits the number of users who can participate in validation and restricts its application scenarios.

[0006] Summary of the Invention

[0007] This application provides a blockchain network verification method that expands the scope of trusted staking, supports multiple parties in building decentralized autonomous organizations to generate revenue, and avoids the limitations of staking conditions on usage scenarios. This application also provides a system, computing device cluster, computer-readable storage medium, and computer program product corresponding to the above method.

[0008] In a first aspect, the present application provides a blockchain network verification method. This method is applied to a blockchain network verification system, wherein the system verifies transactions by staking tokens. The system includes multiple decentralized application nodes and a distributed validator technology (DVT) network, and the sum of the tokens held by the multiple decentralized application nodes for staking meets the staking requirement. The staking requirement can be that the number of tokens pledged reaches a set number (the set number can be set based on empirical values, for example, 32).

[0009] Specifically, multiple decentralized application nodes aggregate the public keys held by multiple decentralized application nodes through a key aggregation algorithm to generate a public address of the blockchain network (for example, a public address in the blockchain network). Tokens are transferred to the public address respectively. Then, multiple decentralized application nodes transfer the tokens of the public address to the staking account, generate multiple staking private keys, and distribute multiple staking private keys to the DVT network. Multiple DVT nodes in the DVT network use their respective staking private keys to sign the transaction, obtain the aggregated signature, and then provide the aggregated signature to the consensus node to participate in the transaction verification.

[0010] This method transfers the pledged tokens held by multiple participants (decentralized application nodes) whose stakeable tokens do not meet the pledge requirements to a public address determined by the public keys of these participants. The tokens in the public address can then meet the pledge requirements and be transferred to the pledge account for staking, allowing participants to participate in transaction verification on the blockchain network. This method expands the scope of trusted staking, supports multiple participants in building decentralized autonomous organizations to generate revenue, and avoids the limitations of pledge conditions on usage scenarios.

[0011] Furthermore, each DVT node holds its own private staking key. An attacker would need to steal multiple private staking keys to obtain a complete transaction signature. Compared to single-point verification schemes, this significantly reduces transaction verification risk and improves reliability. Furthermore, the distributed DVT network can effectively mitigate the risks associated with concentrated interests and client-side centralization within blockchain networks.

[0012] In some possible implementations, the number of tokens held by each of the multiple decentralized application nodes for staking does not meet the staking requirements. For example, the number of tokens held by each decentralized node for staking is less than 32. This method broadens the application scenarios by organizing multiple participants to form a decentralized autonomous organization to participate in verification.

[0013] In some possible implementations, the DVT network includes DVT nodes corresponding to multiple decentralized application nodes, and the number of staked private keys is equal to the number of DVT nodes. Accordingly, each of the multiple staked private keys can be assigned to one of the multiple DVT nodes, and each staked private key can be assigned to a different DVT node. Each DVT node can use its own staked private key to participate in transaction verification.

[0014] This method solves the single point failure problem by building a DVT network, changing the single-point validator into a multi-point distributed verification cluster. Even if an individual DVT node fails, the remaining DVT nodes in the DVT network can sign the transaction based on their respective pledged private keys (or private key shards) and aggregate signatures for consensus verification, thereby improving reliability and security.

[0015] In some possible implementations, the DVT network includes a primary DVT node and a backup DVT node that correspond one-to-one to multiple decentralized application nodes, and the number of pledged private keys is equal to the sum of the number of primary DVT nodes and the number of backup DVT nodes. When allocating pledged private keys, each of the multiple pledged private keys can be assigned to one of the multiple DVT nodes. For example, each pledged private key can be assigned to a primary DVT node or a backup DVT node, and each pledged private key is assigned to a different DVT node. When at least one of the multiple primary DVT nodes fails, the backup DVT nodes corresponding to at least one primary DVT node use the pledged private keys they hold to sign transactions.

[0016] In this method, in order to ensure the security of the DVT network, the DVT network is further layered for each participant, and backup participants are added to each layer. Based on the two-layer network architecture, it is ensured that there is no single point of failure for different participants in the DVT network and the private keys are secure. In this way, the single point of failure problem of different participants is solved through the two-layer network architecture.

[0017] In some possible implementations, when the DVT network adopts a two-tier network architecture, multiple pledge keys can be generated at once. For example, when the number of decentralized application nodes is N (N is greater than 1), multiple decentralized application nodes can use a threshold key generation algorithm to generate 2N pledge keys at once. In some examples, multiple pledge keys can also be generated in multiple stages. For example, when the number of decentralized application nodes is N (N is greater than 1), multiple decentralized application nodes can use a threshold key generation algorithm to first generate N pledge keys. Each of the N pledge keys can be sharded to obtain 2N pledge keys. This ensures key security while achieving high key generation efficiency.

[0018] In some possible implementations, multiple decentralized application nodes can call the contract's public address generation interface, aggregate the public keys held by multiple decentralized application nodes using a key aggregation algorithm, and generate a public address for the blockchain network. Accordingly, when staking, multiple decentralized application nodes can call the contract's staking interface to transfer tokens from the public address to the staking account.

[0019] In this method, multiple parties can collaborate to complete the pledge through a contract without the need for a third-party agent. The pledge process is controllable and traceable, ensuring security.

[0020] In some possible implementations, a first decentralized application node among multiple decentralized application nodes can call the contract's stop staking interface to send a stop staking request to the remaining decentralized application nodes. Upon receiving the stop staking responses from the remaining decentralized application nodes, the first decentralized application node transfers the tokens in the pledged account to the public account and distributes the tokens transferred to the public account to the multiple decentralized application nodes through the contract.

[0021] This method supports any of multiple participants to initiate the process of exiting the pledge, and with the consent of other participants, the pledge can be stopped and the tokens in the pledge account can be returned to each participant through the contract to ensure security.

[0022] In some possible implementations, a first decentralized application node among multiple decentralized application nodes may also send cluster configuration information to a target node to establish a DVT network. The cluster configuration information includes a consensus algorithm. The consensus algorithm may be a fault-tolerant CFT algorithm. Accordingly, the multiple DVT nodes each use their respective staked private keys to sign the transaction. When the number of signatures received by the first DVT node among the multiple DVT nodes reaches the number set by the CFT algorithm, the received signatures are aggregated to obtain an aggregated signature.

[0023] In this method, the DVT nodes in the DVT network form a decentralized autonomous organization. The fault-tolerant CFT algorithm can be used in this decentralized organization, rather than being limited to the Byzantine fault-tolerant BFT algorithm. The CFT algorithm has better performance, faster processing speed, and can tolerate no more than half of the faulty nodes. Therefore, consensus verification using the CFT algorithm in the DVT network can improve verification efficiency.

[0024] In some possible implementations, the target nodes include one or more cloud nodes, edge nodes, or client-side nodes. This allows the existing proof-of-stake (POS) validator scheme in the public chain system to be cloud-native. Cloud services provide the ability to build a DVT network with on- and off-cloud connectivity, meeting the needs of different users and providing high availability. Furthermore, cloud-native DVT nodes support participation in validation on different POS chains, and the cloud-native staking architecture supports staking processes on multiple POS chains, with strong concurrency capabilities.

[0025] In some possible implementations, multiple DVT nodes can also obtain aggregated signatures without using a consensus algorithm. Specifically, at least one of the multiple DVT nodes aggregates the pledged private keys in the trusted execution hardware TEE to obtain an aggregated private key, which is then used to sign the transaction to obtain an aggregated signature. This can improve the efficiency of obtaining aggregated signatures and accelerate transaction verification.

[0026] In some possible implementations, the key aggregation algorithm includes a secure multi-party computation (MPC) algorithm. MPC algorithms may include, but are not limited to, threshold key generation algorithms. Keys generated using threshold key generation algorithms can be used for threshold signatures. An mn threshold signature scheme refers to a digital signature scheme in which any m or more signers from a group of n signers can represent the entire group and generate a valid signature. This signature can be verified using a group public key, which is an aggregation of the public keys of the participants. Generally speaking, threshold signatures do not reveal the actual members involved in generating the signature, thus ensuring security.

[0027] In a second aspect, the present application provides a blockchain network verification system. The system verifies transactions by staking tokens. The system includes multiple decentralized application nodes and a distributed validator technology (DVT) network. The sum of the tokens held by the multiple decentralized application nodes for staking meets the staking requirements.

[0028] The multiple decentralized application nodes are configured to aggregate the public keys held by the multiple decentralized application nodes through a key aggregation algorithm to generate a public address of the blockchain network, and transfer tokens to the public address respectively;

[0029] The multiple decentralized application nodes are further used to transfer the tokens of the public address to the pledge account, generate multiple pledge private keys, and distribute the multiple pledge private keys to the DVT network;

[0030] The multiple DVT nodes in the DVT network are used to sign the transaction using the pledged private keys they hold, obtain an aggregated signature, and then provide the aggregated signature to the consensus node to participate in the verification of the transaction.

[0031] In some possible implementations, the DVT network includes DVT nodes corresponding one-to-one to the multiple decentralized application nodes, and the number of the pledged private keys is equal to the number of the DVT nodes.

[0032] In some possible implementations, the DVT network includes a primary DVT node and a backup DVT node corresponding one-to-one to the plurality of decentralized application nodes, and the number of the pledged private keys is equal to the sum of the number of the primary DVT nodes and the number of the backup DVT nodes;

[0033] The multiple DVT nodes in the DVT network are specifically used for:

[0034] When at least one of the multiple master DVT nodes fails, the backup DVT nodes corresponding to the at least one master DVT node use the pledged private keys they hold to sign the transaction.

[0035] In some possible implementations, the multiple decentralized application nodes are specifically used to:

[0036] Calling the contract's public address generation interface, aggregating the public keys held by the multiple decentralized application nodes through a key aggregation algorithm, and generating a public address of the blockchain network;

[0037] Call the pledge interface of the contract to transfer the token of the public address to the pledge account.

[0038] In some possible implementations, the first decentralized application node among the multiple decentralized application nodes is further configured to:

[0039] Calling the stop staking interface of the contract to send a stop staking request to the remaining decentralized application nodes in the multiple decentralized application nodes;

[0040] When the first decentralized application node receives the stop staking response sent by the remaining decentralized application nodes, the tokens in the pledge account are transferred to the public account, and the tokens transferred to the public account are distributed to the multiple decentralized application nodes through the contract.

[0041] In some possible implementations, the first decentralized application node among the multiple decentralized application nodes is further configured to:

[0042] Sending cluster configuration information to the target node to establish the DVT network, the cluster configuration information including a consensus algorithm, and the consensus algorithm is a fault-tolerant CFT algorithm;

[0043] The first DVT node among the multiple DVT nodes is specifically configured to:

[0044] Receive signatures of transactions from the multiple DVT nodes in the DVT network using their respective pledged private keys. When the number of received signatures reaches the number set by the CFT algorithm, aggregate the received signatures to obtain an aggregated signature.

[0045] In some possible implementations, the target node includes one or more of a cloud node, an edge node, or an end-side node.

[0046] In some possible implementations, at least one DVT node among the multiple DVT nodes is specifically configured to:

[0047] Aggregate the pledged private key in the trusted execution hardware TEE to obtain an aggregated private key;

[0048] The aggregated private key is used to sign the transaction to obtain an aggregated signature.

[0049] In some possible implementations, the key aggregation algorithm includes a secure multi-party computing (MPC) algorithm.

[0050] In a third aspect, the present application provides a computing device cluster. The computing device cluster includes at least one computing device, each of which includes at least one processor and at least one memory. The at least one processor and the at least one memory communicate with each other. The at least one processor is configured to execute instructions stored in the at least one memory, so that the computing device or computing device cluster performs the blockchain network verification method described in the first aspect or any implementation of the first aspect.

[0051] In a fourth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores instructions, wherein the instructions instruct a computing device or a computing device cluster to execute the blockchain network verification method described in the above-mentioned first aspect or any one of the implementations of the first aspect.

[0052] In a fifth aspect, the present application provides a computer program product comprising instructions, which, when run on a computing device or a computing device cluster, enables the computing device or the computing device cluster to execute the blockchain network verification method described in the above-mentioned first aspect or any one of the implementations of the first aspect.

[0053] Based on the implementation methods provided in the above aspects, this application can also be further combined to provide more implementation methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] In order to more clearly illustrate the technical methods of the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments.

[0055] FIG1A is a schematic diagram of the architecture of a blockchain network verification system provided in an embodiment of the present application;

[0056] FIG1B is a schematic diagram of the architecture of another blockchain network verification system provided in an embodiment of the present application;

[0057] FIG2 is a schematic diagram of a network configuration of a blockchain network verification system according to an embodiment of the present application;

[0058] FIG3 is a schematic diagram of another network configuration of a blockchain network verification system according to an embodiment of the present application;

[0059] FIG4 is a flow chart of a blockchain network verification method provided in an embodiment of the present application;

[0060] FIG5 is a flow chart of another blockchain network verification method provided in an embodiment of the present application;

[0061] FIG6 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0062] FIG7 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0063] FIG8 is a schematic diagram of the structure of another computing device cluster provided in an embodiment of the present application. DETAILED DESCRIPTION

[0064] The terms "first" and "second" in the embodiments of this application are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of technical features indicated. Therefore, features specified as "first" or "second" may explicitly or implicitly include one or more of the features.

[0065] First, some technical terms involved in the embodiments of this application are introduced.

[0066] A blockchain network is a decentralized network that provides ledger and smart contract (chaincode) services for applications. Applications built on this decentralized network are also called decentralized applications (dApps). Users of dApps can be end users of the application client or administrators of the blockchain network. DApp data can be stored on the blockchain network. Smart contracts are used to generate transactions (e.g., write and read data). Transactions are distributed to every node in the blockchain network and recorded in each node's copy of the ledger, making them immutable.

[0067] Nodes in a blockchain network achieve consensus through a consensus mechanism to record transactions. In a public blockchain network (also known as a trustless or permissionless blockchain network), any user can participate in the consensus process used to verify transactions. To ensure secure and stable operation, public blockchain networks employ a variety of consensus algorithms and incentive mechanisms to attract a large number of users.

[0068] Incentive mechanisms can include proof-of-stake (POS). Proof-of-stake forms the foundation of consensus mechanisms, and blockchain networks can use POS to achieve distributed consensus. In public blockchain networks that support POS, such as Ethereum, validators stake tokens, such as Ether, to the blockchain network's smart contracts. The staked tokens serve as collateral, which can be destroyed if the validator acts dishonestly or becomes inactive. Validators are then responsible for verifying the validity of new blocks propagated on the network. In some cases, validators can also create and propagate new blocks.

[0069] To participate in transaction validation as a validator, users typically stake tokens and run the execution client, consensus client, and validator on their nodes. When depositing tokens for staking, users enter an activation queue, which limits the rate at which new validators can join the network. Upon activation, validators receive new blocks from peer nodes on the public blockchain network. Transactions submitted within the blocks are re-executed, and the block signatures are checked to ensure the blocks are valid. Validators can then send a vote supporting the block across the entire network (a process also known as certification).

[0070] However, the staking requirements of POS-enabled blockchain networks significantly limit the number of users who can participate in verification. For example, in Ethereum, users are typically required to stake 32 ETH to enter the verification process, making it difficult for many users who hold less than 32 ETH to participate in the verification process.

[0071] In view of this, the present application provides a blockchain network verification method. The method can be performed by a blockchain network verification system. The system can include multiple decentralized application nodes and a distributed validator technology (DVT) network. The tokens held by each of the multiple decentralized application nodes for pledge do not meet the pledge requirements, while the sum of the tokens held by the multiple decentralized application nodes for pledge meet the pledge requirements.

[0072] Specifically, multiple decentralized application nodes aggregate the public keys held by multiple decentralized application nodes through a key aggregation algorithm to generate a public address on the blockchain network. Tokens are then transferred to the public addresses. Multiple decentralized application nodes then transfer the tokens from the public addresses to the staking accounts, generate multiple staking private keys, and distribute them to the DVT network. Multiple DVT nodes in the DVT network sign transactions using their respective staking private keys, obtaining an aggregated signature. They then provide this aggregated signature to the consensus node to participate in transaction verification.

[0073] This method transfers the pledged tokens held by multiple participants (decentralized application nodes) whose stakeable tokens do not meet the pledge requirements to a public address identified by the public keys of these participants. The tokens in the public address then meet the pledge requirements and are then transferred to a pledge account for staking, allowing participants to participate in transaction verification on the blockchain network. This method expands the scope of trusted staking, supports multiple participants in building decentralized autonomous organizations (DAOs) to generate revenue, and avoids the limitations of pledge conditions on usage scenarios.

[0074] In order to make the technical solution of the present application clearer and easier to understand, the system architecture of the verification system of the blockchain network of the present application is first introduced with reference to the accompanying drawings.

[0075] Referring to the architectural diagram of a verification system for a blockchain network shown in FIG1A , the system 10 includes a plurality of decentralized application nodes 100 and a DVT network 200. The DVT network 200 includes a plurality of DVT nodes. Each DVT node may include a distributed verification client (DV Client). Multiple DV Clients collaborate to complete transaction verification. Specifically, compared to the traditional verification nodes that use a single-point validator and consensus client (also known as a consensus node), the DVT node adds a DV Client to the traditional verification node. The DV Client is connected to the validator and consensus node (e.g., a beacon node) to verify the transaction. This allows for compatibility with existing nodes without requiring significant modifications to existing nodes or smart contracts.

[0076] The multiple decentralized application nodes 100 are used to aggregate the public keys held by the multiple decentralized application nodes through a key aggregation algorithm, generate a public address of the blockchain network, transfer tokens to the public addresses respectively, and then transfer the tokens of the public addresses to the pledge accounts, and generate multiple pledge private keys, and distribute multiple pledge private keys to the DVT network 200. The multiple DVT nodes in the DVT network 200 are used to sign the transaction using the pledge private keys they hold, aggregate the signatures of the transactions, and then provide the aggregated signatures to the consensus node to participate in the verification of the transaction. Furthermore, after the consensus node passes the verification, it can also send the transaction to the execution node (execution client), which will then upload the transaction to the chain and record the transaction in the blockchain ledger.

[0077] In some possible implementations, when generating pledge private keys, multiple decentralized application nodes 100 can also generate them through distributed key generation (DKG) services or management services. A typical application of DKG is threshold key generation (Thresh-Key-Gen). A DKG protocol is constructed based on security parameters. Running the DKG protocol can output a common public key pk and private keys ski (i.e., pledge private keys) owned by different participants. Aggregating the private key shares that meet the threshold number can construct the real private key sk. During the transaction verification process, based on the distributed communication network, each participant (e.g., the participant's DV Client) completes the distributed collaborative signing of the message m (e.g., the transaction message) using its own private key share ski and outputs the final verifiable signature Sig(sk,m). Among them, each DV T node can sign the transaction. When a DVT node receives a number of signatures that meets the requirements of the consensus algorithm, it can aggregate the signatures and provide the aggregated signature as a verifiable signature to the consensus node to participate in the transaction verification.

[0078] Figure 1A illustrates an example of multiple DVT nodes obtaining aggregated signatures through a consensus algorithm. In some possible implementations, DVT nodes can also obtain aggregated signatures without using a consensus algorithm and then participate in transaction verification based on the aggregated signatures. Referring to Figure 1B , an architectural diagram of another blockchain network verification system is shown. In this system, DVT nodes (e.g., DV Clients within a DVT node) can aggregate the pledged private keys within a trusted execution environment (TEE) to obtain an aggregated private key, which they then use to sign transactions and obtain an aggregated signature. The TEE is a secure area built using hardware and software methods on a computing platform (e.g., a DVT node) that ensures the confidentiality and integrity of code and data loaded within the secure area. Unlike the system architecture shown in Figure 1A , the system architecture in Figure 1B can include two DVT nodes. These two DVT nodes can obtain the aggregated signature more quickly without having to reach agreement through a consensus algorithm, thereby improving the efficiency of transaction verification.

[0079] It should be noted that a DVT node can be a cloud node, such as a public cloud node or a private cloud node. Such a cloud node can also be a third-party cloud node, such as a public cloud node or a private cloud node provided by a third-party cloud service provider. In some possible implementations, a DVT node can also be a self-deployed node, such as a self-deployed private cloud node. Such a cloud node can be a cloud server.

[0080] In the multi-tenant scenario of the cloud platform, by building multiple tenants to join the DVT network 200, the business needs of tenants can be met while supporting the following features: supporting cloud tenants to dynamically join the DVT network 200, supporting the construction of the DVT network 200 to change the single-point validator to a multi-point validator, thereby improving reliability and security.

[0081] DVT nodes can also be edge nodes or end-side nodes. Edge nodes can be edge servers or edge computing boxes (referred to as boxes for short). Edge computing boxes are devices used for edge computing, typically including computing, storage, networking, and security functions. Edge computing boxes can be small computers that can be placed near IoT devices, sensors, or other edge devices to process and calculate data generated by edge devices and transmit the processing results to the cloud or elsewhere. End-side nodes can be terminal devices, including but not limited to desktops, laptops, and smartphones.

[0082] This application supports the interconnection of cloud nodes between different virtual private clouds (VPCs) in a public cloud to form a DVT network 200, supports the interconnection of public cloud nodes and private cloud nodes to form a DVT network 200, or the interconnection of cloud nodes in a private cloud and a third-party cloud to form a DVT network 200, or the interconnection of cloud nodes in a public cloud and a third-party cloud to form a DVT network 200, supports the interconnection of private clouds and edge nodes to form a DVT network 200, and supports the interconnection of cloud nodes and edge nodes in a third-party cloud to form a DVT network.

[0083] When cloud nodes are used to form the DVT network 200, it can support the construction of clusters with different service providers (pledge service providers) to participate in verification as reliable DVT nodes. As shown in Figure 2, the cloud nodes in the cloud platform can build cluster A with the nodes in service provider 1, the nodes in service provider 2, and the box to form the DVT network 200. The cloud nodes in the cloud platform can also build cluster B with the nodes in service provider 3, service provider 4, and service provider 5 to form the DVT network 200. It should be noted that the cloud nodes in the cloud platform can also build clusters with different nodes of the same service provider to form the DVT network 200. Considering security, the DV Client in the DVT node can be implemented using offline nodes, such as end-side nodes or edge nodes, and the consensus client and execution client in the DVT node can be deployed in a cloud environment, such as a cloud node.

[0084] In some possible implementations, all DVT nodes can be offline. As shown in Figure 3, a node from Service Provider 2 and three nodes from Service Provider 3 can form a cluster. Each node in the cluster can deploy a validator, a DV Client, and a Beacon Node to form a DVT network. These DV Clients can use the DVT protocol to aggregate transaction signatures and then provide the aggregated signatures to the consensus node to participate in transaction verification. This also allows offline users to join the DVT network 200, performing multi-point verification through the DVT network 200 to improve reliability and security.

[0085] Regardless of whether cloud-native or offline networking is used, this application can support multiple users who do not meet the staking requirements (for example, staking 32 ETH) to jointly build a DVT network, achieve trusted verification capabilities, and ensure that the profits of participating verification users are not lost.

[0086] Based on the aforementioned blockchain network verification system 10, the present application also provides a blockchain network verification method. The blockchain network verification method of the present application is described below with reference to the accompanying drawings.

[0087] Referring to the flowchart of a blockchain network verification method shown in FIG4 , the method includes:

[0088] S402. Multiple decentralized application nodes 100 aggregate the public keys held by multiple decentralized application nodes through a key aggregation algorithm to generate a public address of the blockchain network, and transfer tokens to the public address respectively.

[0089] Specifically, each decentralized application node 100 holds a public-private key pair, such as one generated by a key generation algorithm. During blockchain network verification, multiple decentralized application nodes 100 can aggregate the public keys held by multiple decentralized application nodes using a key aggregation algorithm. The aggregated public key can be considered a public address of the blockchain network, and multiple decentralized application nodes 100 can transfer tokens to this public address.

[0090] In this case, the tokens transferred into each decentralized application node 100 do not meet the pledge requirement, but the sum of the tokens transferred into multiple decentralized application nodes 100 does meet the pledge requirement. For example, if the pledge requirement is that the number of pledged tokens reaches a preset number, and the number of tokens transferred into a single decentralized application node 100 is less than the preset number, the sum of the tokens transferred into multiple decentralized application nodes 100 equals the preset number.

[0091] For security reasons, the key aggregation algorithm can be a secure multi-party computation (MPC) algorithm. MPC algorithms may include, but are not limited to, threshold key generation algorithms. Keys generated using threshold key generation algorithms can be used for threshold signatures. An mn threshold signature scheme refers to a digital signature scheme in which any m or more signers from a group of n signers can represent the entire group and generate a valid signature. This signature can be verified using a group public key, which is an aggregation of the public keys of the participants. Generally speaking, threshold signatures do not reveal the actual members who generated the signature.

[0092] To ensure reliability and security, multiple decentralized application nodes 100 can call the contract's public address generation interface, aggregate the public keys held by multiple decentralized application nodes 100 through a key aggregation algorithm, and generate a public address of the blockchain network.

[0093] S404. Multiple decentralized application nodes 100 transfer the tokens of the public address to the pledge account and generate multiple pledge private keys.

[0094] In specific implementations, multiple decentralized application nodes 100 can call the contract's pledge interface to transfer tokens from the public address to the pledge account. It should be noted that one decentralized application node 100 can be determined among the multiple decentralized application nodes 100 to trigger the pledge process. For example, the first decentralized application node among the multiple decentralized application nodes 100 can call the contract's pledge interface to transfer tokens from the public address to the pledge account.

[0095] When generating a public address (e.g., a group public key), multiple decentralized application nodes 100 can also generate multiple pledged private keys. When multiple decentralized application nodes 100 aggregate the public keys held by multiple decentralized application nodes 100 using a threshold key generation algorithm, they can also generate private key shares belonging to different participants based on the DKG protocol. These private key shares can also be called private key shards and can serve as the pledged private keys of each participant. Each participant obtains a private key share but does not construct a complete key, which ensures the security of the key in the distributed verification process.

[0096] S406. Multiple decentralized application nodes 100 distribute multiple pledge private keys to the DVT network 200.

[0097] In a specific implementation, a user may configure node information for forming a DVT network 200. The node information may include a node identifier or an Internet Protocol (IP) address of the node. Based on the node information for forming the DVT network 200, multiple decentralized application nodes 200 may allocate multiple staking private keys to the nodes forming the DVT network 200.

[0098] In some possible implementations, the DVT network 200 includes DVT nodes that correspond one-to-one with multiple decentralized application nodes 100. The number of pledged private keys is equal to the number of DVT nodes. Accordingly, each of the multiple pledged private keys can be assigned to one of the multiple DVT nodes, and each pledged private key is assigned to a different DVT node. In other words, there can be a one-to-one correspondence between pledged private keys and DVT nodes. Each DVT node can use its own pledged private key to participate in transaction verification.

[0099] In other possible implementations, the DVT network 200 can also adopt a two-layer network architecture to solve the single point failure problem of different participants. Specifically, the DVT network 200 includes a master DVT node and a backup DVT node corresponding to multiple decentralized application nodes 100. The number of pledged private keys is equal to the sum of the number of master DVT nodes and the number of backup DVT nodes. When allocating pledged private keys, each of the multiple pledged private keys can be assigned to a DVT node among the multiple DVT nodes. For example, each pledged private key can be assigned to a master DVT node or a backup DVT node, and the DVT node to which each pledged private key is assigned is different. Furthermore, the backup DVT node can deploy a complete validator, DV Client, and beacon node to ensure that when the master DVT node fails or the validator, DV Client, or beacon node in the master DVT node fails, the backup DVT node corresponding to the failed master DVT node can replace the master DVT node to participate in the verification of the transaction.

[0100] In the two-tier network architecture, multiple pledge keys can be generated at once. For example, when the number of decentralized application nodes 100 is N (N is greater than 1), multiple decentralized application nodes 100 can generate 2N pledge keys at once using a threshold key generation algorithm. In some examples, multiple pledge keys can also be generated in multiple stages. For example, when the number of decentralized application nodes 100 is N (N is greater than 1), multiple decentralized application nodes 100 can generate N pledge keys using a threshold key generation algorithm. Each of the N pledge keys can be sharded to obtain 2N pledge keys.

[0101] S408. Multiple DVT nodes in the DVT network 200 use their respective pledged private keys to sign the transaction, aggregate the signatures of the transaction, and then provide the aggregated signatures to the consensus node to participate in the verification of the transaction.

[0102] Specifically, multiple DVT nodes can sign transactions using a threshold signature algorithm to participate in transaction verification. An mn threshold signature scheme refers to a digital signature scheme in which any m or more signers out of a group of n signers can represent the entire group and generate a valid signature. Among the n signers, any subset of m signers can generate a valid signature. When creating a signature, each member contributes a signature fragment to a specific combiner, who can derive the expected threshold signature from these signature fragments. Based on this, multiple DVT nodes use their respective pledged private keys to sign the transaction and obtain signature fragments. Among them, a DVT node (for example, a DVT node determined by election or voting) can aggregate the received partial signature fragments to obtain a complete and valid signature.

[0103] In this embodiment, a first decentralized application node among the multiple decentralized application nodes 100 sends cluster configuration information to a target node to establish a DVT network. The target node may be the node corresponding to the DVT network. The cluster configuration information may include a consensus algorithm. Traditional POS-supported blockchain networks typically use a Byzantine Fault Tolerance (BFT) algorithm. This application supports configuring the consensus algorithm not only as a BFT algorithm, but also as a Crash Fault Tolerance (CFT) algorithm.

[0104] Consensus algorithms are categorized by their tolerance for Byzantine faults: CFT algorithms and BFT algorithms. CFT algorithms are non-trivial fault-tolerant algorithms. They can still reach consensus on a proposal even when faced with common faults such as network or disk failures, or server downtime. CFT algorithms include, but are not limited to, Paxos and Raft. CFT algorithms offer superior performance, faster processing speed, and can tolerate no more than half of the nodes failing. BFT algorithms, in addition to tolerating common faults during the consensus process, can also tolerate Byzantine faults such as intentional deception by some nodes (e.g., falsifying transaction results). BFT algorithms include hotstaff, Practical Byzantine Fault Tolerance (PBFT), Federated Byzantine Agreement (FBA), and Delegated Byzantine Fault Tolerance (dBFT). BFT algorithms offer lower performance than CFT algorithms and can tolerate no more than one-third of the nodes failing.

[0105] Based on this, in the process of signature aggregation, when the number of signatures received by the first DVT node among multiple DVT nodes reaches the number set by the CFT algorithm, the first DVT node can aggregate according to the received signatures. Among them, the first DVT node can use the BLS (i.e. Boneh-Lynn-Shacham) signature algorithm to aggregate the received signatures. BLS is an algorithm that can realize signature aggregation and key aggregation. The BLS algorithm can merge the signatures and public keys in a transaction into a single signature and public key, and the merging process is invisible. In this way, there is no way to trace whether this signature or public key was obtained through merging, nor can it be traced which signatures or public keys were merged, thereby ensuring security.

[0106] Furthermore, when the DVT network 200 adopts a two-layer network architecture, when at least one of the multiple main DVT nodes fails, the backup DVT nodes corresponding to at least one main DVT node use the pledged private keys they hold to sign the transaction, thereby solving the problem of verification failure caused by a single point failure of any of the different participants.

[0107] It should be noted that S408 is only one implementation method for multiple DVT nodes in the DVT network 200 to obtain an aggregated signature. In other possible implementations of the embodiments of the present application, the DVT nodes may also obtain the aggregated signature through other methods. For example, the DVT nodes may also aggregate the pledged private keys in the TEE to obtain the aggregated private key, and use the aggregated private key to sign the transaction to obtain the aggregated signature.

[0108] S410: A first decentralized application node among the multiple decentralized application nodes 100 calls a stop staking interface of the contract and sends a stop staking request to the remaining decentralized application nodes among the multiple decentralized application nodes 100.

[0109] When a participant wants to stop staking (stop trading), the staking stop process can be triggered through the contract. In order to ensure security, the participant who initiates the staking stop can stop staking after the consent of other participants. Specifically, the first decentralized application node among the multiple decentralized application nodes 100 calls the contract's staking stop interface and sends a staking stop request to the remaining decentralized application nodes in the multiple decentralized application nodes 100. Among them, the first decentralized application node can trigger the staking stop based on the pledge private key corresponding to the first decentralized application node. For example, the first decentralized application node can call the contract's staking stop interface to generate a staking stop request, and the staking stop request can carry a signature of the message using the pledge private key.

[0110] S412. When the first decentralized application node receives a stop staking response from the remaining decentralized application nodes, the first decentralized application node transfers the tokens in the pledged account to the public account, and distributes the tokens transferred to the public account to multiple decentralized application nodes 100 through the contract.

[0111] The stop-staking response can be a response indicating agreement to stop staking. When the first decentralized application node receives the stop-staking response sent by the remaining decentralized application nodes, it indicates that all participants in the staking process agree to stop staking. Based on this, the first decentralized application node can transfer the tokens in the pledge account to the public account and distribute the tokens transferred to the public account to multiple decentralized application nodes 100 through the contract.

[0112] It should be noted that when the first decentralized application node distributes the tokens transferred from the public account to multiple decentralized application nodes 100 through the contract, the distribution can be based on the number of tokens transferred in by each decentralized application node 100. For example, when staking is initiated, each decentralized application node 100 transfers in 11 Ether. Then, when staking is stopped, 11 Ether can be distributed to each decentralized application node 100.

[0113] The above S410 and S412 are optional steps of the present application, and the verification method of the blockchain network of the embodiment of the present application may not execute the above S410 and S412.

[0114] Based on the above description, it can be seen that the blockchain network verification method of this application transfers the tokens held by multiple participants (decentralized application nodes) whose holdings of pledgeable tokens do not meet the pledge requirements to a public address determined by the public keys of these multiple participants. The tokens in the public address can meet the pledge requirements, and the tokens in the public address are transferred to the pledge account for pledge, thereby participating in the transaction verification of the blockchain network. This method expands the scope of trusted pledge, supports multiple participants in building DAOs to obtain benefits, and avoids the limitation of use cases by pledge conditions.

[0115] Multiple decentralized application nodes 100 can jointly stake tokens that meet the stake requirements, or a single decentralized application node 100 can stake tokens that meet the stake requirements. The following details the validation process with reference to the accompanying figures.

[0116] Referring to FIG5 , a flowchart of a blockchain network verification method is shown. This method can be applied to a blockchain network verification system 10, which includes a decentralized application node 100 and a DVT network 200. The DVT network 200 includes a decentralized application node 100 sending a pledged private key (also known as a key shard) to a target node, which is then networked based on the pledged private key. Specifically, this method may include the following steps:

[0117] S502: The decentralized application node 100 receives the user's cluster configuration information.

[0118] S504. The decentralized application node 100 generates multiple pledge private keys according to the cluster configuration information.

[0119] S506. The decentralized application node 100 sends cluster configuration information and pledge private key to the target node.

[0120] Cluster configuration information may include a user-selected consensus algorithm. When there are multiple decentralized application nodes 100, each decentralized application node 100 may select a consensus algorithm. For example, a decentralized application node 100 may select Raft as the consensus algorithm, which is a CFT algorithm with high performance. In some examples, a decentralized application node 100 may also select Hot Staff as the consensus algorithm, which can achieve Byzantine fault tolerance.

[0121] The cluster configuration information may also include the number of nodes in the cluster. In other words, the number of nodes in the cluster corresponds to the number of participants. The decentralized application node 100 may generate multiple pledge private keys based on the number of nodes in the cluster. The number of pledge private keys may be equal to the number of nodes in the cluster.

[0122] The pledge private key can be generated by the decentralized application node 100. In specific implementations, the decentralized application node 100 can generate the pledge private key using tools such as the DKG service. For details on how to generate the pledge private key, please refer to the description of the embodiment shown in FIG4 . Furthermore, the decentralized application node 100 can also distribute the pledge private key to the target node through the DKG service.

[0123] The cluster configuration information may also include node information used to form a cluster, specifically node information used to form the DVT network 200. The node information may be a node identifier or an IP address of a target node.

[0124] S508. The target node establishes the DVT network 200 according to the cluster configuration information.

[0125] The target node can be initialized according to the above cluster configuration information to build a DVT cluster. The DVT cluster includes multiple DV Clients. Staking boxes can also be registered on the target node, such as staking-box C1 registered on node C1 and staking-box Y registered on node Y. The staking-box includes a validator, a beacon node (consensus client), and an execution client. The consensus layer (CL) and execution layer (EL) information in the staking-box can be configured in the DVT cluster. The DV Client in the DVT cluster can monitor the node status in the staking-box. When the node status indicates that the node has a survival issue, it can switch to other DV Client nodes for supervision.

[0126] The DV Clients in the DVT cluster and the staking-boxes they oversee can form the DVT network 200. The nodes that deploy the validators, beacon nodes, and execution clients in the DV Clients and staking-boxes can be DVT nodes in the DVT network 200. Each DVT node in the DVT network 200 holds a staking private key (specifically, a private key shard). Only an aggregate signature of m of n staking private keys is valid. Therefore, participants do not need to worry about losing their private keys, ensuring the security of their private keys.

[0127] It should be noted that the DVT network 200 can be organized as a consortium chain. A consortium chain is a blockchain deployment model that is restricted to a specific group of clients, allowing only authorized nodes to access it. Accessed nodes can participate in reading and writing data according to rules. Networking target nodes in a consortium chain format can improve networking efficiency, consensus efficiency, and the performance of the DVT network 200.

[0128] S510. The DV Client in the DVT node queries the consensus node to obtain the verification task.

[0129] A verification task refers to a transaction that requires verification. Specifically, a DV Client can call the contract's task query interface to query verification tasks from a consensus node, such as in beacon mode. This verification task can be a transaction that the validator needs to verify, for example, an operation that the validator needs to perform in a time slot in the next epoch.

[0130] S512: The DV Client in the DVT node distributes the verification task to other DV Clients in the DVT cluster.

[0131] As shown in Figure 5, DV Client C1 can send the verification task to DV Client X, which can then send the verification task to DV Client Y, which in turn sends the verification task to DV Client Z. DV Client Z can be a DV Client deployed on a cloud node in the cloud platform. In this way, each DV Client in the DVT node obtains the verification task. It should be noted that Figure 5 is merely an exemplary implementation of distributing verification tasks to a DVT cluster. In other possible implementations of the present application, verification tasks can also be distributed in other ways.

[0132] S514. The DV Client in the DVT node signs the transaction based on the queried verification task.

[0133] Among them, the DV Client can dispatch the VC interface of the validator client to sign the transactions in the verification task.

[0134] S516. The DV Client aggregates the signatures based on the consensus algorithm to obtain an aggregated signature.

[0135] S518. DV Client sends the aggregated signature to the consensus node of the consensus layer to participate in the verification of the transaction.

[0136] Among the multiple DV Clients in the DVT cluster, one DV Client can be determined for signature aggregation. For example, multiple DV Clients can select one DV Client for signature aggregation through voting. In this embodiment, it is assumed that DV Client C1 is the DV Client C1 used for signature aggregation.

[0137] DV Client C1 can aggregate signatures based on the consensus algorithm after receiving signatures that meet the consensus algorithm requirements. The following examples illustrate this using the BFT or CFT consensus algorithms as examples.

[0138] When the consensus algorithm is a BFT algorithm, it can generally tolerate 1 / 3 of the node failures. This means that signatures can be aggregated if signatures from 2 / 3 or more nodes are received. In this example, the DVT cluster has 4 nodes, and 2 / 3 or more nodes can be 3 nodes. In other words, DV Client C1 can aggregate signatures if it obtains signatures from 3 nodes (including its own).

[0139] When the consensus algorithm is the CFT algorithm, it can generally tolerate 1 / 2 of the node failures. This means that signatures can be aggregated if signatures from at least 1 / 2 of the nodes (including 1 / 2) are received. In this example, the DVT cluster has 4 nodes, and at least 1 / 2 of the nodes can be 2 nodes. In other words, DV Client C1 can aggregate signatures if it obtains signatures from 2 nodes (including its own).

[0140] When using the CFT algorithm, the DV Client can quickly collect the required signatures and aggregate them to obtain the aggregated signature, which it then provides to the consensus node for transaction verification. Compared to the BFT algorithm, the CFT algorithm can obtain aggregated signatures more quickly for transaction verification and has higher performance.

[0141] It should be noted that the DV Client can also obtain an aggregated signature without going through the consensus algorithm. For example, if the DVT network includes two DVT nodes, the DV Client in the DVT node can call the TEE component to aggregate the pledged private key. The aggregated private key can be regarded as a complete private key. The DV Client uses the aggregated private key to sign the transaction, thereby obtaining a complete transaction signature, also known as an aggregated signature.

[0142] This application also provides a blockchain network verification system 10 that verifies transactions by staking tokens. As shown in Figure 1A or Figure 1B, the verification system 10 includes multiple decentralized application nodes 100 and a DVT network 200, wherein the sum of the tokens held by the multiple decentralized application nodes for staking meets the staking requirements.

[0143] Multiple decentralized application nodes 100, configured to aggregate the public keys held by the multiple decentralized application nodes 100 through a key aggregation algorithm to generate a public address of the blockchain network, and transfer tokens to the public address respectively;

[0144] The plurality of decentralized application nodes 100 are further configured to transfer the tokens at the public address to the pledge account, generate a plurality of pledge private keys, and distribute the plurality of pledge private keys to the DVT network 200;

[0145] The multiple DVT nodes in the DVT network 200 are used to sign the transaction using the pledged private keys they hold, obtain an aggregated signature, and then provide the aggregated signature to the consensus node to participate in the verification of the transaction.

[0146] Illustratively, the decentralized application node 100 and the DVT node in the DVT network 200 may be implemented by hardware or software.

[0147] When implemented by software, the decentralized application node 100 and the DVT node in the DVT network 200 can be applications running on computer devices, such as computing engines, clients (dAPP, DV Client), etc. The application can be provided to users in the form of virtualized services. Virtualization services can include virtual machine (VM) services, bare metal server (BMS) services, and container services. Among them, VM services can be services that use virtualization technology to virtualize virtual machine (VM) resource pools on multiple physical hosts (such as computing devices) to provide VMs for users to use on demand. BMS services are services that virtualize BMS resource pools on multiple physical hosts to provide BMS for users to use on demand. Container services are services that virtualize container resource pools on multiple physical hosts to provide containers for users to use on demand. VM is a simulated virtual computer, that is, a logical computer. BMS is a high-performance computing service that is elastically scalable and has computing performance that is no different from that of traditional physical machines and has the characteristics of secure physical isolation. Containers are a kernel virtualization technology that provides lightweight virtualization to isolate user spaces, processes, and resources. It should be understood that the VM service, BMS service, and container service mentioned above are merely examples. In actual applications, virtualization services can also be other lightweight or heavyweight virtualization services, which are not specifically limited here.

[0148] When implemented through hardware, the decentralized application node 100 and the DVT node in the DVT network 200 may include at least one computing device, such as a server. Alternatively, the decentralized application node 100 and the DVT node in the DVT network 200 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0149] In some possible implementations, the DVT network 200 includes DVT nodes corresponding one-to-one to the multiple decentralized application nodes, and the number of the pledged private keys is equal to the number of the DVT nodes.

[0150] In some possible implementations, the DVT network 200 includes a primary DVT node and a backup DVT node corresponding one-to-one to the plurality of decentralized application nodes, and the number of the pledged private keys is equal to the sum of the number of the primary DVT nodes and the number of the backup DVT nodes;

[0151] The multiple DVT nodes in the DVT network 200 are specifically used for:

[0152] When at least one of the multiple master DVT nodes fails, the backup DVT nodes corresponding to the at least one master DVT node use the pledged private keys they hold to sign the transaction.

[0153] In some possible implementations, the multiple decentralized application nodes 100 are specifically used to:

[0154] Calling the contract's public address generation interface, aggregating the public keys held by the multiple decentralized application nodes through a key aggregation algorithm, and generating a public address of the blockchain network;

[0155] Call the pledge interface of the contract to transfer the token of the public address to the pledge account.

[0156] In some possible implementations, the first decentralized application node among the plurality of decentralized application nodes 100 is further configured to:

[0157] Calling the stop staking interface of the contract to send a stop staking request to the remaining decentralized application nodes in the multiple decentralized application nodes;

[0158] When the first decentralized application node receives the stop staking response sent by the remaining decentralized application nodes, the tokens in the pledge account are transferred to the public account, and the tokens transferred to the public account are distributed to the multiple decentralized application nodes through the contract.

[0159] In some possible implementations, the first decentralized application node among the plurality of decentralized application nodes 100 is further configured to:

[0160] Sending cluster configuration information to the target node to establish the DVT network, the cluster configuration information including a consensus algorithm, and the consensus algorithm is a fault-tolerant CFT algorithm;

[0161] The first DVT node among the multiple DVT nodes is specifically configured to:

[0162] Receive signatures of transactions from the multiple DVT nodes in the DVT network using their respective pledged private keys, and when the number of received signatures reaches the number set by the CFT algorithm, aggregate the received signatures.

[0163] The received signatures may include the first DVT node's own signature on the transaction using the pledged private key. For example, if the first DVT node receives a signature on a transaction sent by another DVT node, as well as its own signature on the transaction, the number of signatures received may be 2.

[0164] In some possible implementations, the target node includes one or more of a cloud node, an edge node, or an end-side node.

[0165] In some possible implementations, at least one DVT node among the multiple DVT nodes is specifically configured to:

[0166] Aggregate the pledged private key in the trusted execution hardware TEE to obtain an aggregated private key;

[0167] The aggregated private key is used to sign the transaction to obtain an aggregated signature.

[0168] In some possible implementations, the key aggregation algorithm includes a secure multi-party computing (MPC) algorithm.

[0169] This application also provides a computing device 600. As shown in Figure 6, computing device 600 includes a bus 602, a processor 604, a memory 606, and a communication interface 608. Processor 604, memory 606, and communication interface 608 communicate with each other via bus 602. Computing device 600 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in computing device 600.

[0170] Bus 602 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG6 shows a single bus line, but this does not imply a single bus or type of bus. Bus 602 may include a path for transmitting information between various components of computing device 600 (e.g., memory 606, processor 604, and communication interface 608).

[0171] The processor 604 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0172] The memory 606 may include volatile memory, such as random access memory (RAM). The memory 606 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD) or solid state drive (SSD). The memory 606 stores executable program code, and the processor 604 executes the executable program code to implement the aforementioned blockchain network verification method. Specifically, the memory 606 stores instructions for the blockchain network verification system 10 to execute the blockchain network verification method. It should be noted that the processor 604 can execute the program code to implement the steps in the blockchain network verification method performed by the decentralized application node 100, or the steps performed by the DVT node in the DVT network 200. For example, the memory 606 stores instructions for executing steps of the decentralized application node 100 in the verification system 10 of the blockchain network, and the processor 604 executes the instructions, thereby executing the steps executed by the decentralized application node 100. For another example, the memory 606 stores instructions for executing steps of the DVT node in the verification system 10 of the blockchain network, and the processor 604 executes the instructions, thereby executing the steps executed by the DVT node.

[0173] The communication interface 608 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 600 and other devices or a communication network.

[0174] Embodiments of the present application also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0175] As shown in Figure 7, the computing device cluster includes at least one computing device 600. The memory 606 of one or more computing devices 600 in the computing device cluster may store instructions for executing the verification method of the blockchain network by the verification system 10 of the same blockchain network.

[0176] In some possible implementations, one or more computing devices 600 in the computing device cluster may also be used to execute some of the instructions of the blockchain network verification system 10 for executing the blockchain network verification method. In other words, the combination of one or more computing devices 600 can jointly execute the instructions of the blockchain network verification system 10 for executing the blockchain network verification method.

[0177] It should be noted that the memory 606 in different computing devices 600 in the computing device cluster can store different instructions for executing part of the functions of the verification system of the blockchain network.

[0178] FIG8 shows a possible implementation. One or more computing devices in a computing device cluster can be connected via a network. The network can be a wide area network or a local area network, etc. As shown in FIG8 , computing devices 600A, 600B, 600C and computing devices 600D, 600E, 600F are connected via a network. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, the memory 606 in the computing devices 600A, 600B, 600C stores instructions for executing the functions of the decentralized application node 100. At the same time, the memory 606 in the computing devices 600D, 600E, 600F stores instructions for executing the functions of the DVT node.

[0179] The connection method between the computing device clusters shown in Figure 8 can be considered to be that the verification method of the blockchain network provided in this application requires a large amount of computing power for consensus and verification, so it is considered to entrust the functions implemented by the DVT node to the computing devices 600D, 600E, and 600F.

[0180] 8 may also be implemented by multiple computing devices 600. Similarly, the functions of computing devices 600D, 600E, and 600F may also be implemented by multiple computing devices 600.

[0181] The present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device, or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the verification system 10 applied to the blockchain network to perform the verification method for the blockchain network.

[0182] The present application also provides a computer program product containing instructions. The computer program product may be software or a program product containing instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute the aforementioned blockchain network verification method.

[0183] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the protection scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A verification method for a blockchain network, characterized in that: A verification system applied to a blockchain network, wherein the system verifies transactions by staking tokens, the system comprises a plurality of decentralized application nodes and a distributed validator technology DVT network, the sum of the tokens held by the plurality of decentralized application nodes and used for staking meets the staking requirements, and the method comprises: The multiple decentralized application nodes aggregate the public keys held by the multiple decentralized application nodes through a key aggregation algorithm to generate a public address of the blockchain network, and transfer tokens to the public address respectively; The multiple decentralized application nodes transfer the tokens of the public address to the pledge account, generate multiple pledge private keys, and distribute the multiple pledge private keys to the DVT network; Multiple DVT nodes in the DVT network use their respective pledged private keys to sign the transaction, obtain an aggregated signature, and then provide the aggregated signature to the consensus node to participate in the verification of the transaction.

2. The method according to claim 1, characterized in that The DVT network includes DVT nodes corresponding one-to-one to the multiple decentralized application nodes, and the number of pledged private keys is equal to the number of the DVT nodes.

3. The method according to claim 1, characterized in that The DVT network includes a primary DVT node and a backup DVT node corresponding to the multiple decentralized application nodes one by one, and the number of the pledged private keys is equal to the sum of the number of the primary DVT nodes and the number of the backup DVT nodes; Multiple DVT nodes in the DVT network use their respective pledged private keys to sign transactions, including: When at least one of the multiple main DVT nodes fails, the backup DVT nodes corresponding to the at least one main DVT node use the pledged private keys they hold to sign the transaction.

4. The method according to any one of claims 1 to 3, characterized in that: The multiple decentralized application nodes aggregate the public keys held by the multiple decentralized application nodes through a key aggregation algorithm to generate a public address of the blockchain network, including: The multiple decentralized application nodes call the public address generation interface of the contract, aggregate the public keys held by the multiple decentralized application nodes through a key aggregation algorithm, and generate a public address of the blockchain network; The multiple decentralized application nodes transfer the tokens of the public address to the pledge account, including: The multiple decentralized application nodes call the pledge interface of the contract to transfer the tokens of the public address to the pledge account.

5. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: The first decentralized application node among the multiple decentralized application nodes calls the stop staking interface of the contract and sends a stop staking request to the remaining decentralized application nodes among the multiple decentralized application nodes; When the first decentralized application node receives the stop staking response sent by the remaining decentralized application nodes, the tokens in the staking account are transferred to the public account, and the tokens transferred to the public account are distributed to the multiple decentralized application nodes through the contract.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: The first decentralized application node among the multiple decentralized application nodes sends cluster configuration information to the target node to form the DVT network, wherein the cluster configuration information includes a consensus algorithm, and the consensus algorithm is a fault-tolerant CFT algorithm; Multiple DVT nodes in the DVT network use their respective pledged private keys to sign the transaction and obtain an aggregated signature, including: The multiple DVT nodes respectively use their respective pledged private keys to sign the transaction. When the number of signatures received by the first DVT node among the multiple DVT nodes reaches the number set by the CFT algorithm, the received signatures are aggregated to obtain an aggregated signature.

7. The method according to claim 6, characterized in that The target node includes one or more of a cloud node, an edge node or an end-side node.

8. The method according to any one of claims 1 to 5, characterized in that: Multiple DVT nodes in the DVT network use their respective pledged private keys to sign the transaction and obtain an aggregated signature, including: At least one DVT node among the multiple DVT nodes aggregates the pledged private key in the trusted execution hardware TEE to obtain an aggregated private key; The at least one DVT node signs the transaction using the aggregated private key to obtain an aggregated signature.

9. A verification system for a blockchain network, characterized in that: The system verifies transactions by staking tokens. The system includes multiple decentralized application nodes and a distributed validator technology DVT network. The sum of the tokens held by the multiple decentralized application nodes for staking meets the staking requirements. The multiple decentralized application nodes are used to aggregate the public keys held by the multiple decentralized application nodes through a key aggregation algorithm to generate a public address of the blockchain network, and transfer tokens to the public addresses respectively; The multiple decentralized application nodes are also used to transfer the tokens of the public address to the pledge account, generate multiple pledge private keys, and distribute the multiple pledge private keys to the DVT network; The multiple DVT nodes in the DVT network are used to sign the transaction using the pledged private keys they hold, obtain an aggregated signature, and then provide the aggregated signature to the consensus node to participate in the verification of the transaction.

10. The system according to claim 9, characterized in that The DVT network includes DVT nodes corresponding one-to-one to the multiple decentralized application nodes, and the number of pledged private keys is equal to the number of the DVT nodes.

11. The system according to claim 8, characterized in that The DVT network includes a primary DVT node and a backup DVT node corresponding to the multiple decentralized application nodes one by one, and the number of the pledged private keys is equal to the sum of the number of the primary DVT nodes and the number of the backup DVT nodes; The multiple DVT nodes in the DVT network are specifically used for: When at least one of the multiple main DVT nodes fails, the backup DVT nodes corresponding to the at least one main DVT node use the pledged private keys they hold to sign the transaction.

12. The system according to any one of claims 9 to 11, characterized in that The multiple decentralized application nodes are specifically used for: Calling the public address generation interface of the contract, aggregating the public keys held by the multiple decentralized application nodes through a key aggregation algorithm, and generating a public address of the blockchain network; Call the pledge interface of the contract to transfer the token of the public address to the pledge account.

13. The system according to any one of claims 9 to 12, characterized in that: The first decentralized application node among the plurality of decentralized application nodes is further configured to: Calling the stop staking interface of the contract to send a stop staking request to the remaining decentralized application nodes among the multiple decentralized application nodes; When the first decentralized application node receives the stop staking response sent by the remaining decentralized application nodes, the tokens in the staking account are transferred to the public account, and the tokens transferred to the public account are distributed to the multiple decentralized application nodes through the contract.

14. The system according to any one of claims 9 to 13, characterized in that The first decentralized application node among the plurality of decentralized application nodes is further configured to: Sending cluster configuration information to the target node to form the DVT network, the cluster configuration information including a consensus algorithm, and the consensus algorithm is a fault-tolerant CFT algorithm; The first DVT node among the multiple DVT nodes is specifically used for: Receive signatures of transactions from the multiple DVT nodes in the DVT network using their respective pledged private keys, and when the number of signatures received reaches the number set by the CFT algorithm, aggregate the received signatures to obtain aggregated signatures.

15. The system according to claim 14, characterized in that The target node includes one or more of a cloud node, an edge node or an end-side node.

16. The system according to any one of claims 9 to 15, characterized in that At least one of the plurality of DVT nodes is specifically configured to: Aggregate the pledged private key in the trusted execution hardware TEE to obtain an aggregated private key; The transaction is signed using the aggregated private key to obtain an aggregated signature.

17. A computing device cluster, characterized in that: The computing device cluster includes at least one computing device, and the at least one computing device includes at least one processor and at least one memory, wherein the at least one memory stores computer-readable instructions; the at least one processor executes the computer-readable instructions so that the computing device cluster executes the method as described in any one of claims 1 to 8.

18. A computer-readable storage medium, characterized in that: The method comprises computer-readable instructions; the computer-readable instructions are used to implement the method according to any one of claims 1 to 8.

19. A computer program product, characterized in that The method comprises computer-readable instructions; the computer-readable instructions are used to implement the method according to any one of claims 1 to 8.

Images