Verification method of block chain network and related equipment

Abstract

The invention provides a verification method of a block chain network, the verification method is applied to a verification system of the block chain network, the system verifies a transaction through pledge token, the system comprises a plurality of decentralized application nodes and a distributed verifier technology (DVT) network, the sum of token held by the plurality of decentralized application nodes and used for pledge meets pledge requirements, and the DVT network is used for verifying the transaction. The method comprises the following steps: a plurality of decentralized application nodes aggregate respective public keys through a key aggregation algorithm, generate a public address of a block chain network, transfer a token to the public address, transfer the token of the public address to a pledge account by the plurality of decentralized application nodes, generate a plurality of pledge private keys, and transmit the pledge private keys to the block chain network; a plurality of pledge private keys are distributed to a DVT network, a plurality of DVT nodes use the pledge private keys held by the DVT nodes to sign a transaction to obtain an aggregated signature, and then the aggregated signature is provided for a consensus node to participate in verification of the transaction. Therefore, the credible pledge range is expanded, and the use scene is prevented from being limited by pledge conditions.

Description

[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 invention name “A blockchain verification method and related system”, the entire contents of which are incorporated by reference in 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] The blockchain network is a network that uses a consensus mechanism designed based on cryptography technology, with multiple nodes jointly maintaining a continuously growing chain list ledger (also called a blockchain ledger, or simply blockchain) constructed by timestamps and ordered record data blocks. Any number of nodes in the blockchain network can calculate and record the data exchanged by the blockchain network over a period of time into a block through cryptographic algorithms, and generate a fingerprint of the block for linking (chain) the next data block and verification. All participating nodes in the blockchain network jointly determine whether the record is true.

[0004] According to the different types of participating nodes in the blockchain network, the blockchain network can be divided into permissionless blockchain network and permissioned blockchain network. Among them, the permissionless blockchain network is also called trustless blockchain network or public blockchain network. It is an open network where every user can participate in the consensus process of the blockchain network to verify transactions and data. In order to ensure safe and stable operation, the permissionless blockchain network adopts a series of consensus algorithms and economic incentive mechanisms to attract a large number of users to participate.

[0005] Traditional permissionless blockchain networks usually include three components: consensus client, execution client and verification client. The verification client interacts with the consensus client of the consensus layer (CL) to complete the block verification work, so that users who participate in the verification can get benefits. In many consensus algorithms, participants usually need to have a certain number of tokens and pledge the tokens to enter the process of verifying blocks, which greatly limits the users who can participate in the verification and leads to limited application scenarios. Summary of the invention

[0006] The present application provides a verification method for a blockchain network, which expands the scope of trusted pledge, supports multiple participants to build decentralized autonomous organizations to obtain benefits, and avoids the use scenarios being restricted by pledge conditions. The present application also provides a system, a computing device cluster, a computer-readable storage medium, and a computer program product corresponding to the above method.

[0007] In the first aspect, the present application provides a verification method for a blockchain network. The method is applied to a verification system of a blockchain network, wherein the system verifies transactions by pledging tokens, wherein the system includes multiple decentralized application nodes and a distributed validator technology DVT network, wherein the sum of the tokens held by the multiple decentralized application nodes for pledging meets the pledge requirements. Among them, the pledge requirement may be that the number of pledged tokens reaches a set number (the set number can be set according to an empirical value, for example, it can be set to 32).

[0008] 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), transfer tokens to the public address respectively, and then multiple decentralized application nodes transfer the tokens of the public address to the pledge account, and generate multiple pledge private keys, and distribute multiple pledge private keys to the DVT network. Multiple DVT nodes in the DVT network use their respective pledge private keys to sign the transaction, obtain the aggregated signature, and then provide the aggregated signature to the consensus node to participate in the verification of the transaction.

[0009] This method transfers the tokens held by multiple participants (decentralized application nodes) who hold pledgeable tokens but do not meet the pledge requirements to a public address determined by the public keys of the above 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, and then can participate in the transaction verification of the blockchain network. This method expands the scope of trusted pledge, supports multiple participants to build decentralized autonomous organizations to obtain benefits, and avoids the use scenario being restricted by pledge conditions.

[0010] In addition, each DVT node holds its own pledge private key. An attacker needs to steal multiple pledge private keys to obtain a complete transaction signature. Compared with the single-point verification solution, the transaction verification risk is greatly reduced and reliability is improved. In addition, the distributed DVT network can effectively reduce the associated risks in the blockchain network caused by interest concentration and client concentration.

[0011] In some possible implementations, the notifications held by each decentralized application node in multiple decentralized application nodes for staking do 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 build a decentralized autonomous organization to participate in verification.

[0012] In some possible implementations, the DVT network includes DVT nodes corresponding to multiple decentralized application nodes, and 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. Each DVT node can use its own pledged private key to participate in the verification of the transaction.

[0013] This method solves the single point failure problem by building a DVT network to change 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 and aggregate the transaction based on their respective pledged private keys (or private key shards) for consensus verification, thereby improving reliability and security.

[0014] In some possible implementations, the DVT network includes a master DVT node and a backup DVT node corresponding to a plurality of decentralized application nodes, and 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 plurality of pledged private keys can be allocated to a DVT node among the plurality of DVT nodes, for example, each pledged private key can be allocated to a master DVT node or a backup DVT node, and the DVT nodes to which each pledged private key is allocated are different. When at least one of the plurality of master DVT nodes fails, the backup DVT nodes corresponding to at least one master DVT node use the pledged private keys they hold to sign the transaction.

[0015] 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 that 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.

[0016] In some possible implementations, when the DVT network adopts a two-layer network architecture, multiple pledge keys can be generated at one time. For example, when the number of decentralized application nodes is N (N is greater than 1), multiple decentralized application nodes can generate 2N pledge keys at one time through 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 is N (N is greater than 1), multiple decentralized application nodes can generate N pledge keys through a threshold key generation algorithm. For each of the N pledge keys, sharding can be performed to obtain 2N pledge keys. In this way, key security can be guaranteed while having a high key generation efficiency.

[0017] In some possible implementations, multiple decentralized application nodes can call the public address generation interface of the contract, aggregate the public keys held by multiple decentralized application nodes through the key aggregation algorithm, and generate the public address of the blockchain network. Accordingly, when staking, multiple decentralized application nodes can call the staking interface of the contract to transfer the tokens of the public address to the staking account.

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

[0019] In some possible implementations, the first decentralized application node among the multiple decentralized application nodes can call the stop pledge interface of the contract to send a stop pledge request to the remaining decentralized application nodes among the multiple decentralized application nodes. When the first decentralized application node receives the stop pledge response sent by the remaining decentralized application nodes, it transfers the tokens in the pledge account to the public account, and distributes the tokens transferred to the public account to multiple decentralized application nodes through the contract.

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

[0021] In some possible implementations, the first decentralized application node among the multiple decentralized application nodes may also send cluster configuration information to the target node to form 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 respectively use their respective pledged private keys to sign the transaction, and 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 the aggregated signatures.

[0022] In this method, the DVT nodes in the DVT network form a decentralized autonomous organization. The fault-tolerant CFT algorithm can be used in the decentralized organization, without 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 through the CFT algorithm in the DVT network can improve verification efficiency.

[0023] In some possible implementations, the target node includes one or more of a cloud node, an edge node, or an end-side node. In this way, the original public chain system's proof-of-stake (POS) strategy can be cloud-native, and the ability to build a DVT network through cloud services to provide on-cloud and off-cloud intercommunication can meet the needs of different types of users and have high availability. In addition, cloud-native DVT nodes support participation in different POS chain verifications, and the cloud-native staking system architecture supports multi-POS chain staking processes with strong concurrency capabilities.

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

[0025] In some possible implementations, the key aggregation algorithm includes a secure multi-party computing MPC algorithm. The MPC algorithm may include, but is not limited to, a threshold key generation algorithm. The key generated based on the threshold key generation algorithm can be used for threshold signatures. An mn threshold signature scheme refers to a digital signature scheme in which any m or more signers in a group of n signers can represent the entire group and generate a valid signature. The 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 expose the actual members involved in generating the signature. This ensures security.

[0026] In the second aspect, the present application provides a verification system for a blockchain network. The system verifies transactions by staking tokens, and 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 requirements;

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

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

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

[0030] In some possible implementations, 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.

[0031] In some possible implementations, the DVT network includes a primary DVT node and a backup DVT node corresponding one-to-one to the multiple 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;

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

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

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

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

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

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

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

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

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

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

[0042] The first DVT node among the multiple DVT nodes is specifically used for:

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

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

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

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

[0047] Use the aggregated private key to sign the transaction and obtain the aggregated signature

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

[0049] In a third aspect, the present application provides a computing device cluster. 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. The at least one processor and the at least one memory communicate with each other. The at least one processor is used to execute instructions stored in the at least one memory, so that the computing device or the computing device cluster performs the verification method of the blockchain network as described in the first aspect or any one of the implementations of the first aspect.

[0050] In a fourth aspect, the present application provides a computer-readable storage medium, wherein instructions are stored in the computer-readable storage medium, and 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.

[0051] In a fifth aspect, the present application provides a computer program product comprising instructions, which, when executed 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 first aspect or any one of the implementations of the first aspect.

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

[0053] In order to more clearly illustrate the technical method of the embodiments of the present application, the drawings required for use in the embodiments are briefly introduced below.

[0054] Figure 1A A schematic diagram of the architecture of a blockchain network verification system provided in an embodiment of the present application;

[0055] Figure 1B Schematic diagram of another blockchain network verification system provided in an embodiment of the present application

[0056] Figure 2 A network diagram of a blockchain network verification system provided in an embodiment of the present application;

[0057] Figure 3 A network diagram of another blockchain network verification system provided in an embodiment of the present application;

[0058] Figure 4 A flowchart of a blockchain network verification method provided in an embodiment of the present application;

[0059] Figure 5 A flowchart of another blockchain network verification method provided in an embodiment of the present application;

[0060] Figure 6 A schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0061] Figure 7 A schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0062] Figure 8 A schematic diagram of the structure of another computing device cluster provided in an embodiment of the present application. DETAILED DESCRIPTION

[0063] The terms "first" and "second" in the embodiments of the present application are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features.

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

[0065] The blockchain network is a decentralized network that provides ledger and smart contract (chaincode) services for applications. Among them, the applications built on the above decentralized network are also called decentralized applications (dAPP). Users who use decentralized applications can be end users of application clients or administrators of blockchain networks. The data of decentralized applications can be stored in the above blockchain network. Smart contracts are used to generate transactions (such as transactions for writing and reading data). Transactions can be distributed to each node in the blockchain network. Transactions will be recorded on the ledger copy of each node and cannot be tampered with.

[0066] The nodes in the blockchain network achieve accounting after reaching a consensus through a consensus mechanism. In a public blockchain network (also known as a trustless blockchain network or a permissionless blockchain network), any user can participate in the consensus process of the blockchain network to verify transactions. In order to ensure safe and stable operation, the public blockchain network adopts a series of consensus algorithms and incentive mechanisms to attract a large number of users to participate.

[0067] Incentive mechanisms can include proof-of-stake (POS). Proof-of-stake is the basis 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 smart contracts on the blockchain network. The staked tokens can serve as collateral, and if the validator is dishonest or passive, the collateral can be destroyed. Afterwards, the validator is responsible for checking whether the new blocks propagated on the network are valid. In some cases, validators can also create and propagate new blocks.

[0068] To participate in transaction verification as a validator, users usually need to stake tokens and run the execution client, consensus client, and validator in their nodes. When depositing tokens for staking, users can enter an activation queue, which limits the speed at which new validators can join the network. After activation, the validator will receive new blocks from peer nodes on the public blockchain network. The transactions delivered in the block are re-executed, and the block signatures are checked to ensure that the block is valid. The validator can then send a vote in support of the block across the entire network (a process also called certification).

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

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

[0071] 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, transfer tokens to the public addresses respectively, and then multiple decentralized application nodes transfer the tokens of the public addresses to the pledge accounts, generate multiple pledge private keys, and distribute multiple pledge private keys to the DVT network. Multiple DVT nodes in the DVT network use their respective pledge private keys to sign the transaction, obtain the aggregated signature, and then provide the aggregated signature to the consensus node to participate in the verification of the transaction.

[0072] This method transfers the tokens held by multiple participants (decentralized application nodes) who hold pledgeable tokens but do not meet the pledge requirements to a public address determined by the public keys of the above 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, and then can participate in the transaction verification of the blockchain network. This method expands the scope of trusted pledge, supports multiple participants to build a decentralized autonomous organization (DAO) to obtain benefits, and avoids the use scenario being restricted by pledge conditions.

[0073] 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 introduced below in conjunction with the accompanying drawings.

[0074] See also Figure 1AThe schematic diagram of the architecture of a verification system of a blockchain network shown in the figure, the system 10 includes multiple decentralized application nodes 100 and a DVT network 200. Among them, the DVT network 200 includes multiple DVT nodes. Among them, each DVT node may include a distributed verification client (DV Client). Multiple DV Clients collaborate to complete transaction verification. In specific implementation, compared with the single-point validator and consensus client (also called consensus node) in the traditional verification node, the DVT node adds a DV Client on the basis of the traditional verification node. The DV Client is connected to the validator and consensus node (such as a beacon node) respectively for verifying transactions. In this way, compatibility with existing nodes can be achieved without significantly modifying existing nodes or smart contracts.

[0075] Multiple decentralized application nodes 100 are used to aggregate the public keys held by 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. Multiple DVT nodes in the DVT network 200 are used to sign transactions using their respective pledge private keys, 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 upload the transaction to the chain and record the transaction in the blockchain ledger.

[0076] 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 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) belonging to different participants. Aggregating private key shares that meet the threshold number can construct the real private key sk. In the process of transaction verification, based on a distributed communication network, each participant (e.g., the DV Client of the participant) completes the distributed collaborative signing of the message m (such as the transaction message) through 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 meet the requirements of the consensus algorithm, it can aggregate the signatures and provide the aggregated signatures as verifiable signatures to the consensus node to participate in transaction verification.

[0077] Figure 1A Taking the example of multiple DVT nodes obtaining aggregated signatures through the consensus algorithm, in some possible implementations, DVT nodes can also obtain aggregated signatures without using the consensus algorithm, and then participate in transaction verification based on the aggregated signatures. Figure 1B The schematic diagram of the architecture of another blockchain network verification system is shown in the figure. In this system, the DVT node (for example, the DV Client in the DVT node) can aggregate the pledged private key in the trusted execution environment (TEE) to obtain the aggregated private key, and use the aggregated private key to sign the transaction to obtain the aggregated signature. Among them, TEE is a secure area built by software and hardware methods on a computing platform (such as a DVT node), which can ensure that the code and data loaded in the secure area are protected in terms of confidentiality and integrity. Different from Figure 1A The system architecture shown, Figure 1B In the system architecture, the DVT network can include 2 DVT nodes. The 2 DVT nodes can obtain the aggregated signature quickly without reaching a consensus through a consensus algorithm, thereby improving the efficiency of transaction verification.

[0078] It should be noted that the DVT node may be a cloud node, such as a public cloud node or a private cloud node. The cloud node may 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, the DVT node may also be an autonomously deployed node, such as an autonomously deployed private cloud node. The cloud node may be a cloud server.

[0079] 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 and the following features can be supported: 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.

[0080] 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, usually 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.

[0081] The present application supports the interconnection of cloud nodes between different virtual private clouds (VPC) 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.

[0082] When cloud nodes are used to form the DVT network 200, it is possible to support building clusters with different service providers (pledge service providers) and participate in verification as reliable DVT nodes. Figure 2 As shown, 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 boxes to form a 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 a 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 a 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.

[0083] In some possible implementations, all DVT nodes may be offline nodes. Figure 3 As shown, the node in service provider 2 and the three nodes in service provider 3 can form a cluster, and each node in the cluster can deploy a validator, a DV Client, and a Beacon Node to form a DVT network. The above-mentioned DV Client can use the DVT protocol to aggregate the signature of the transaction, and then provide the aggregated signature to the consensus node to participate in the verification of the transaction. In this way, it is also possible to support offline users to join the DVT network 200, and perform multi-point verification through the DVT network 200 to improve reliability and security.

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

[0085] 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 introduced below in conjunction with the accompanying drawings.

[0086] See also Figure 4 A flowchart of a blockchain network verification method is shown, the method comprising:

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

[0088] Specifically, each decentralized application node 100 holds a public-private key pair, for example, a public-private key pair generated by a key generation algorithm. During the verification process of the blockchain network, multiple decentralized application nodes 100 can aggregate the public keys held by multiple decentralized application nodes through a key aggregation algorithm. The aggregated public key can be regarded as a public address of the blockchain network, and multiple decentralized application nodes 100 transfer tokens to the above public address respectively.

[0089] Among them, the tokens transferred by each decentralized application node 100 do not meet the pledge requirements, and the sum of the tokens transferred by multiple decentralized application nodes 100 meets the pledge requirements. For example, when the pledge requirement is that the number of pledged tokens reaches a preset number, the number of tokens transferred by a single decentralized application node 100 is less than the preset number, and the sum of the tokens transferred by multiple decentralized application nodes 100 is equal to the preset number.

[0090] Considering security, the key aggregation algorithm can be a secure multi-party computing (MPC) algorithm. Among them, the MPC algorithm may include but is not limited to the threshold key generation algorithm. The key generated based on the threshold key generation algorithm can be used for threshold signature. An mn threshold signature scheme refers to a digital signature scheme in which any m or more signers in a group of n signers can represent the entire group and generate a valid signature. The signature can be verified using a group public key, which is aggregated from the public keys of the participants. Generally speaking, threshold signatures do not expose the actual members involved in generating signatures.

[0091] In order to ensure reliability and security, multiple decentralized application nodes 100 can call the public address generation interface of the contract, aggregate the public keys held by multiple decentralized application nodes 100 through the key aggregation algorithm, and generate the public address of the blockchain network.

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

[0093] In specific implementation, multiple decentralized application nodes 100 can call the pledge interface of the contract to transfer the token of the public address to the pledge account. It should be noted that one decentralized application node 100 can be determined to trigger the pledge process among the multiple decentralized application nodes 100. For example, the first decentralized application node among the multiple decentralized application nodes 100 can call the pledge interface of the contract to transfer the token of the public address to the pledge account.

[0094] When generating a public address (such as a group public key), multiple decentralized application nodes 100 can also generate multiple pledged private keys. Among them, when multiple decentralized application nodes 100 use the threshold key generation algorithm to aggregate the public keys held by multiple decentralized application nodes 100, they can also generate private key shares belonging to different participants based on the DKG protocol. The private key share can also be called a private key shard, which can be used as the pledged private key 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.

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

[0096] In specific implementation, the user can configure the node information of the DVT network 200, and the node information may include the node identifier or the Internet Protocol (IP) address of the node. Multiple decentralized application nodes 200 allocate multiple pledge private keys to the nodes of the DVT network 200 according to the node information of the DVT network 200.

[0097] In some possible implementations, the DVT network 200 includes DVT nodes that correspond one-to-one to 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 a DVT node among the multiple DVT nodes, and the DVT nodes to which each pledged private key is assigned are different. In other words, the pledged private keys and DVT nodes can correspond one-to-one. Each DVT node can use its own pledged private key to participate in the verification of the transaction.

[0098] In some other possible implementations, the DVT network 200 can also use 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 nodes to which each pledged private key is assigned are different. Furthermore, the backup DVT node can deploy a complete validator, DV Client, and beacon node to ensure that when the main DVT node fails or the validator, DV Client, and beaconnode in the main DVT node fail, the backup DVT node corresponding to the failed main DVT node can replace the main DVT node to participate in the verification of the transaction.

[0099] Among them, in the scheme of the two-layer network architecture, multiple pledge keys can be generated at one time. 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 one time through 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 through a threshold key generation algorithm. For each of the N pledge keys, sharding can be performed to obtain 2N pledge keys.

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

[0101] Specifically, multiple DVT nodes can sign transactions through the threshold signature algorithm to participate in the verification of transactions. 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 valid signatures. 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 which 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.

[0102] In this embodiment, the first decentralized application node among the multiple decentralized application nodes 100 sends cluster configuration information to the target node to form a DVT network. Among them, the target node may be a node corresponding to the formation of the DVT network. The cluster configuration information may include a consensus algorithm. Traditional blockchain networks that support POS usually use the Byzantine Fault Tolerance (BFT) algorithm. This application not only supports configuring the consensus algorithm as the BFT algorithm, but also supports configuring the consensus algorithm as a Crash Fault Tolerance (CFT) algorithm.

[0103] Among them, consensus algorithms are divided into the following categories according to whether they tolerate Byzantine faults: CFT algorithm and BFT algorithm. CFT algorithm is a non-ordinary fault-tolerant algorithm. When the system encounters common faults such as network failure, disk failure, server downtime, etc., it can still reach a consensus on a certain proposal. CFT algorithms can include but are not limited to Paxos, Raft, etc. CFT algorithms have good performance, fast processing speed, and can tolerate no more than half of the faulty nodes. In addition to tolerating common faults that occur during the system consensus process, BFT algorithms can also tolerate Byzantine faults such as deliberate deception by some nodes (such as forging transaction execution results). BFT algorithms include hotstaff, Practical Byzantine Fault Tolerance (PBFT), Federated Byzantine Agreement (FBA), Delegated Byzantine Fault Tolerance (dBFT), etc. The performance of BFT algorithms is lower than that of CFT algorithms, and can tolerate no more than one-third of faulty nodes.

[0104] 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 is obtained through merging, nor can it be traced which signatures or public keys are merged, thereby ensuring security.

[0105] 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 their respective pledged private keys to sign the transaction, thereby solving the problem of verification failure caused by a single point failure of any of the different participants.

[0106] It should be noted that S408 is only one implementation method for multiple DVT nodes in the DVT network 200 to obtain the aggregated signature. In other possible implementation methods of the embodiment of the present application, the DVT node can also obtain the aggregated signature in other ways. For example, the DVT node can also aggregate the pledged private key in the TEE to obtain the aggregated private key, use the aggregated private key to sign the transaction, and obtain the aggregated signature.

[0107] S410. The first decentralized application node among the multiple decentralized application nodes 100 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 100.

[0108] When a participant wants to stop staking (stop trading), the process of stopping staking can be triggered through the contract. In order to ensure security, the participant who initiates the stop staking can stop staking after the consent of other participants. Specifically, the first decentralized application node among the multiple decentralized application nodes 100 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 100. Among them, the first decentralized application node can trigger the stop staking based on the pledge private key corresponding to the first decentralized application node. For example, the first decentralized application node can call the stop staking interface of the contract to generate a stop staking request, and the stop staking request can carry a signature of the message using the pledge private key.

[0109] S412: When the first decentralized application node receives a stop staking response sent by 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.

[0110] The stop pledge response may be a response indicating agreement to stop pledging. When the first decentralized application node receives the stop pledge response sent by the remaining decentralized application nodes, it indicates that all parties involved in the pledge agree to stop pledging. Based on this, the first decentralized application node may 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.

[0111] It should be noted that when the first decentralized application node distributes the tokens transferred to the public account to multiple decentralized application nodes 100 through the contract, the tokens can be distributed according to the number of tokens transferred in by each decentralized application node 100. For example, when staking is started, each decentralized application node 100 transfers in 11 ethers respectively, and when staking is stopped, 11 ethers can be distributed to each decentralized application node 100 respectively.

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

[0113] Based on the above description, it can be known that the verification method of the blockchain network of this application transfers the tokens held by multiple participants (decentralized application nodes) who hold pledgeable tokens but do not meet the pledge requirements to a public address determined by the public keys of the above 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, and then can participate in the transaction verification of the blockchain network. This method expands the scope of trusted pledge, supports multiple participants to build DAOs to obtain benefits, and avoids the use scenario being restricted by pledge conditions.

[0114] Multiple decentralized application nodes 100 jointly pledge tokens that meet the pledge requirements, or a single decentralized application node 100 pledges tokens that meet the requirements, and can all participate in the verification of the transaction. The verification process is described in detail below with reference to the accompanying drawings.

[0115] See also Figure 5The flowchart of a verification method of a blockchain network shown in FIG. 1 is applicable to a verification system 10 of a blockchain network, and the verification system 10 of a blockchain network includes a decentralized application node 100 and a DVT network 200. The DVT network 200 sends a pledged private key (also called a key shard) to a target node by the decentralized application node 100, and the target node is obtained by networking based on the pledged private key. The method may specifically include the following steps:

[0116] S502: The decentralized application node 100 receives cluster configuration information of the user.

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

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

[0119] The cluster configuration information may include a consensus algorithm selected by the user. When there are multiple decentralized application nodes 100, each of the multiple decentralized application nodes 100 may select a consensus algorithm. For example, the decentralized application node 100 may select a consensus algorithm as raft, which belongs to a CFT algorithm and has higher performance. In some examples, the decentralized application node 100 may also select a consensus algorithm as hot staff, so that Byzantine fault tolerance can be achieved.

[0120] 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, and the decentralized application node 100 may generate multiple pledged private keys according to the number of nodes in the cluster. The number of pledged private keys may be equal to the number of nodes in the cluster.

[0121] The pledge private key can be generated by the decentralized application node 100. In specific implementation, the decentralized application node 100 can generate the pledge private key through tools such as DKG service. The specific implementation of generating the pledge private key can be found in Figure 4 The relevant content of the illustrated embodiment is described. Further, the decentralized application node 100 can also distribute the pledge private key to the target node through the DKG service.

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

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

[0124] 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. Staking-box includes validator, beacon node (consensus client), and execution client (execution client). The information of the consensus layer (CL) and execution layer (EL) 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 problem, it can switch to other DV Client nodes for supervision.

[0125] Among them, each DV Client in the DVT cluster and the staking-box supervised by each DV Client can form a DVT network 200. The nodes that deploy the validator, beacon node, and executionclient in the DV Client and staking-box can be DVT nodes in the DVT network 200. Each DVT node in the DVT network 200 holds a pledge private key (specifically a private key shard), and only the pledge private key aggregate signature of m of n can be valid, so the participants do not need to worry about the loss of private keys, which ensures the security of private keys.

[0126] It should be noted that the DVT network 200 can be networked in the form of a consortium chain. The consortium chain is a type of blockchain deployment model that is limited to a specific group of customers, only authorized nodes can access it, and the access nodes can participate in reading and writing data according to the rules. Each target node is networked in the form of a consortium chain, which can improve the networking efficiency, consensus efficiency, and performance of the DVT network 200.

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

[0128] A verification task refers to a transaction that needs to be verified. Specifically, the DV Client can call the task query interface of the contract to query the verification task from the consensus node such as beacon mode. The verification task can be a transaction that the validator needs to verify, for example, it can be an operation that the validator needs to perform in a time slot in the next epoch.

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

[0130] like Figure 5 As shown, DV Client C1 can send the verification task to DV Client X, DV Client X can send the verification task to DV Client Y, and DV Client Y can send the verification task to DV Client Z. Among them, DVclient Z can be a DV Client deployed in 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 This is only an exemplary implementation of distributing verification tasks to a DVT cluster. In other possible implementations of the embodiment of the present application, verification tasks may also be distributed in other ways.

[0131] S514. The DV Client in the DVT node signs the transaction according to the queried verification task.

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

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

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

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

[0136] DV Client C1 can aggregate the signatures according to the consensus algorithm after receiving the signatures that meet the requirements of the consensus algorithm. The following examples are given with the consensus algorithm being the BFT algorithm or the CFT algorithm.

[0137] When the consensus algorithm is a BFT algorithm, 1 / 3 of the node failures can usually be tolerated, that is, the signatures can be aggregated by receiving signatures from more than 2 / 3 (including 2 / 3) of the nodes. In this example, the number of DVT cluster nodes is 4, and more than 2 / 3 of the nodes can be 3 nodes. In other words, DV Client C1 can aggregate the signatures by obtaining signatures from 3 nodes (including itself).

[0138] When the consensus algorithm is the CFT algorithm, 1 / 2 of the node failures can usually be tolerated, that is, the signatures can be aggregated by receiving signatures from more than 1 / 2 (including 1 / 2) of the nodes. In this example, the number of DVT cluster nodes is 4, and more than 1 / 2 of the nodes can be 2 nodes. In other words, DV Client C1 can aggregate the signatures by obtaining signatures from 2 nodes (including itself).

[0139] When the CFT algorithm is used, the DV Client can quickly collect the required signatures, aggregate them based on the collected signatures, and then provide the aggregated signatures to the consensus node to participate in the verification of the transaction. Compared with the BFT algorithm, the CFT algorithm can obtain the aggregated signatures faster to participate in the verification of the transaction, and has higher performance.

[0140] It should be noted that the DV Client can also obtain the aggregated signature without using the consensus algorithm. For example, when 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.

[0141] The present application also provides a verification system 10 for a blockchain network, which verifies transactions by staking tokens. Figure 1A or Figure 1B As shown, 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.

[0142] A plurality of decentralized application nodes 100, used to aggregate the public keys held by the plurality of decentralized application nodes 100 through a key aggregation algorithm, generate a public address of the blockchain network, and transfer tokens to the public addresses respectively;

[0143] The plurality of decentralized application nodes 100 are further used to transfer the tokens of 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;

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

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

[0146] Among them, when implemented by software, the decentralized application node 100 and the DVT node in the DVT network 200 can be an application running on a computer device, such as a computing engine, a client (dAPP, DV Client), etc. The application can be provided to users in the form of a virtualized service. Virtualization services may include virtual machine (VM) services, bare metal server (BMS) services, and container services. Among them, the VM service can be a service that virtualizes a virtual machine (VM) resource pool on multiple physical hosts (such as computing devices) through virtualization technology to provide users with VMs on demand for use. The BMS service is a service that virtualizes a BMS resource pool on multiple physical hosts to provide users with BMS on demand for use. The container service is a service that virtualizes a container resource pool on multiple physical hosts to provide users with containers on demand for use. VM is a simulated virtual computer, that is, a logical computer. BMS is a high-performance computing service that can be elastically scalable, and its computing performance is no different from that of a traditional physical machine, and it has the characteristics of secure physical isolation. Container is a kernel virtualization technology that can provide lightweight virtualization to achieve the purpose of isolating user space, processes and resources. It should be understood that the VM service, BMS service and container service in the above virtualization services are only used as specific examples. In actual applications, the virtualization service can also be other lightweight or heavyweight virtualization services, which are not specifically limited here.

[0147] When implemented by 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, etc. Alternatively, the decentralized application node 100 and the DVT node in the DVT network 200 may also be a device implemented by 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.

[0148] 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 pledged private keys is equal to the number of the DVT nodes.

[0149] In some possible implementations, the DVT network 200 includes a primary DVT node and a backup DVT node corresponding one-to-one to the multiple 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;

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

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

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

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

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

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

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

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

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

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

[0160] The first DVT node among the multiple DVT nodes is specifically used for:

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

[0162] The received signature may include the signature of the first DVT node itself on the transaction using the pledged private key. For example, if the first DVT node receives a signature on the transaction sent by other DVT nodes and the signature of the first DVT node itself on the transaction, the number of signatures received may be 2.

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

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

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

[0166] The transaction is signed using the aggregated private key to obtain an aggregated signature.

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

[0168] The present application also provides a computing device 600. Figure 6As shown, computing device 600 includes: bus 602, processor 604, memory 606 and communication interface 608. Processor 604, memory 606 and communication interface 608 communicate through bus 602. Computing device 600 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in computing device 600.

[0169] The bus 602 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 The bus 602 may include a path for transmitting information between various components of the computing device 600 (eg, the memory 606, the processor 604, and the communication interface 608).

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

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

[0172] 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 communication networks.

[0173] The embodiment of the present application also provides 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 smart phone.

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

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

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

[0177] Figure 8 One possible implementation is shown. One or more computing devices in the computing device cluster may be connected via a network. The network may be a wide area network or a local area network, etc. Figure 8 As shown, 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 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 computing devices 600D, 600E, 600F stores instructions for executing the functions of the DVT node.

[0178] Figure 8 The connection method between the computing device clusters shown can be considered to be that the verification method of the blockchain network provided in this application requires a lot 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.

[0179] It should be understood that Figure 8 The functions of the computing devices 600A, 600B, and 600C shown in FIG. 6 may also be completed by multiple computing devices 600. Similarly, the functions of the computing devices 600D, 600E, and 600F may also be completed by multiple computing devices 600.

[0180] The embodiment of 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 containing one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk). The computer-readable storage medium includes instructions that instruct the computing device to execute the verification system 10 applied to the blockchain network for executing the verification method of the blockchain network.

[0181] The embodiment of the present application also provides a computer program product including instructions. The computer program product may be a software or program product including 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, the at least one computing device executes the verification method of the blockchain network.

[0182] 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 cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the 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