阅读说明：本技术 对用于区块链系统的签名验证进行测试的方法和设备 (Method and apparatus for testing signature verification for blockchain systems ) 是由 马玉 于 2019-03-04 设计创作，主要内容包括：本文公开了用于对用于区块链系统的签名验证进行测试的方法、设备和装置,包括存储在计算机可读介质上的计算机程序。所述方法之一包括：从配置文件获得测试配置,其中所述测试配置指定所述区块链系统中使用的加密算法、对应于加密算法的包括一个或多个私钥的私钥组、以及基于所述加密算法和所述私钥组的预定执行结果；通过基于所述加密算法和所述私钥组对表示交易的数据进行加密来对所述交易签名,以生成一个或多个签名交易；将所述一个或多个签名交易发送到所述区块链系统并从所述区块链系统接收执行结果；以及基于所述执行结果确定所述预定执行结果是否被满足。(Methods, apparatus, and devices, including computer programs stored on computer-readable media, for testing signature verification for blockchain systems are disclosed herein. One of the methods comprises: obtaining a test configuration from a configuration file, wherein the test configuration specifies an encryption algorithm used in the blockchain system, a private key set corresponding to the encryption algorithm that includes one or more private keys, and a predetermined execution result based on the encryption algorithm and the private key set; signing the transaction by encrypting data representing the transaction based on the encryption algorithm and the private key set to generate one or more signed transactions; sending the one or more signature transactions to the blockchain system and receiving execution results from the blockchain system; and determining whether the predetermined execution result is satisfied based on the execution result.)

1. A computer-implemented method for testing signature verification for blockchain systems, comprising:

obtaining a test configuration from a configuration file, wherein the test configuration specifies an encryption algorithm used in the blockchain system, a private key set corresponding to the encryption algorithm that includes one or more private keys, and a predetermined execution result based on the encryption algorithm and the private key set;

signing a transaction by encrypting data representing the transaction based on the encryption algorithm and the private key set to generate one or more signed transactions;

sending the one or more signature transactions to the blockchain system and receiving an execution result from the blockchain system, the execution result indicating whether the one or more signature transactions correspond to valid transactions or invalid transactions; and

determining whether the predetermined execution result is satisfied based on the execution result received from the blockchain system.

2. The method of claim 1, wherein the set of private keys comprises duplicate private keys.

3. The method of any preceding claim, wherein the encryption algorithm used in the blockchain system comprises at least one of an RSA algorithm, an ECDSA algorithm, or an SM2 algorithm.

4. The method of any preceding claim, wherein the test configuration comprises a representation of each private key in the set of private keys, the method further comprising:

mapping a representation of each private key in the set of private keys to a corresponding private key; and

and obtaining the corresponding private key.

5. The method of any preceding claim, further comprising:

generating a transaction; and

determining a hash value of the generated transaction as data representing the transaction.

6. The method of any preceding claim, wherein determining whether the predetermined execution result is satisfied comprises:

comparing the execution results received from the blockchain system with the predetermined execution results to make the determination.

7. The method of any preceding claim, further comprising:

receiving the execution results based on the weights corresponding to each private key in the set of private keys.

8. The method of any preceding claim, further comprising:

in response to determining that the predetermined execution result is satisfied, displaying a test result indicating that signature verification operations in the blockchain system are normal.

9. The method of any preceding claim, further comprising:

obtaining a plurality of test configurations from the configuration file, wherein the plurality of test configurations specify a plurality of cryptographic algorithms used in the blockchain system, a plurality of private key sets including one or more private keys, and a plurality of predetermined execution results; and

performing testing in parallel based on the plurality of test configurations.

10. An apparatus for testing signature verification for blockchain systems, comprising:

one or more processors; and

one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to perform the method of any of claims 1-9.

11. An apparatus for testing signature verification for a blockchain system, the apparatus comprising a plurality of modules for performing the method of any of claims 1 to 9.

12. A non-transitory computer readable medium having stored therein instructions that, when executed by a processor of a device, cause the device to perform the method of any of claims 1-9.

Technical Field

This document relates generally to computer technology and, more particularly, to methods and apparatus for testing signature verification for blockchain systems.

Background

A blockchain system, also known as a Distributed Ledger System (DLS) or consensus system, can make the participating entities store data securely and tamperproof. Without reference to any particular use case, the blockchain system may include any DLS and may be used for public, private, and federated blockchain networks. The public blockchain network opens all entities to use the system and participate in consensus processing. A private blockchain network is provided for a particular entity that centrally controls read and write permissions. A federated blockchain network is provided for a selected group of entities that controls the consensus process, and the federated blockchain network includes an access control layer.

The blockchain system maintains one or more blockchains. Blockchains are data structures used to store data, such as transactions, that may prevent malicious parties from tampering with and manipulating the data.

The data in the tiles of the blockchain may represent transactions. Data representing the transaction is typically encrypted for authentication purposes so that the blockchain system can verify the validity of the transaction. Different encryption algorithms or different private keys of the same encryption algorithm may be used to encrypt the transaction. Accordingly, there may be a need for methods and apparatus for testing encryption algorithms and corresponding private keys used to encrypt transactions.

Disclosure of Invention

In one embodiment, a computer-implemented method for testing signature verification for blockchain systems includes: obtaining a test configuration from a configuration file, wherein the test configuration specifies an encryption algorithm used in the blockchain system, a private key set corresponding to the encryption algorithm that includes one or more private keys, and a predetermined execution result based on the encryption algorithm and the private key set; signing the transaction by encrypting data representing the transaction based on the encryption algorithm and the private key set to generate one or more signed transactions; sending the one or more signature transactions to the blockchain system and receiving an execution result from the blockchain system, the execution result indicating whether one or more signature transactions correspond to valid transactions or invalid transactions; and determining whether the predetermined execution result is satisfied based on the execution result received from the blockchain system.

In another embodiment, an apparatus for testing signature verification for a blockchain system includes: one or more processors; and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon, wherein the instructions are executable by the one or more processors to: obtaining a test configuration from a configuration file, wherein the test configuration specifies an encryption algorithm used in the blockchain system, a private key set corresponding to the encryption algorithm that includes one or more private keys, and a predetermined execution result based on the encryption algorithm and the private key set; signing the transaction by encrypting data representing the transaction based on the encryption algorithm and the private key set to generate one or more signed transactions; sending the one or more signature transactions to the blockchain system and receiving an execution result from the blockchain system, the execution result indicating whether one or more signature transactions correspond to valid transactions or invalid transactions; and determining whether the predetermined execution result is satisfied based on the execution result received from the blockchain system.

In yet another embodiment, a non-transitory computer readable medium has instructions stored therein, which when executed by a processor of a device, cause the device to perform a method for testing signature verification for a blockchain system. The method comprises the following steps: obtaining a test configuration from a configuration file, wherein the test configuration specifies an encryption algorithm used in the blockchain system, a set of private keys corresponding to the encryption algorithm that includes one or more private keys, and a predetermined execution result based on the encryption algorithm and the set of private keys; signing the transaction by encrypting data representing the transaction based on the encryption algorithm and the private key set to generate one or more signed transactions; sending the one or more signature transactions to the blockchain system and receiving an execution result from the blockchain system, the execution result indicating whether one or more signature transactions correspond to valid transactions or invalid transactions; and determining whether the predetermined execution result is satisfied based on the execution result received from the blockchain system.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments. In the following description with reference to the drawings, the same numbers in different drawings represent the same or similar elements, unless otherwise specified.

Fig. 1 shows a schematic diagram of a blockchain system according to one embodiment.

Fig. 2 is a flow diagram of a signature method according to an embodiment.

Fig. 3 is a flow diagram of a signature verification method according to an embodiment.

Fig. 4 is a flow diagram of a method for testing signature verification for a blockchain system, according to an embodiment.

Fig. 5 is a block diagram of an apparatus for testing signature verification for a blockchain system, according to an embodiment.

Fig. 6 is a flow diagram of a method for testing signature verification for a blockchain system, according to an embodiment.

Fig. 7 is a block diagram of an apparatus for testing signature verification for a blockchain system, according to an embodiment.

Detailed Description

Embodiments herein provide methods and apparatus for testing signature verification for blockchain systems. The method and apparatus may obtain a test configuration from a configuration file. The test configuration may specify a cryptographic algorithm used in the blockchain system, a set of private keys corresponding to the cryptographic algorithm that includes one or more private keys, and a predetermined execution result based on the cryptographic algorithm and the set of private keys. The method and apparatus may also generate one or more signed transactions by encrypting data representing the transaction based on an encryption algorithm and a set of private keys to sign the transaction. The method and apparatus may also send one or more signature transactions to the blockchain system and receive execution results from the blockchain system. The execution result may indicate whether one or more of the signed transactions correspond to valid transactions or invalid transactions. The method and apparatus may also determine whether a predetermined execution result is satisfied based on the execution result received from the blockchain system.

The embodiments disclosed herein have one or more technical effects. In some embodiments, the method and apparatus obtain test configurations from a configuration file and set a private key set including one or more private keys for each test configuration in the configuration file. This allows test configurations to be automatically generated to verify signature transactions in a blockchain system under various scenarios. Furthermore, when a new combination based on the private key is required to test the signature verification, this allows the configuration file to be easily updated by simply adding the new combination. In other embodiments, the methods and apparatus encrypt transactions based on an encryption algorithm and one or more private keys to generate one or more signed transactions. This allows multiple combinations of private keys to be tested. In other embodiments, the methods and apparatus include a representation of each private key in the profile, rather than the private key itself, e.g., by mapping the representation of the private key to the private key itself based on the correspondence. This saves the file size of the configuration file, thereby facilitating the user to generate and view the configuration file. In other embodiments, the methods and apparatus perform testing for multiple encryption algorithms and multiple sets of private keys in parallel. This allows multiple encryption algorithms and multiple private keys to be tested substantially simultaneously.

The following description provides details of embodiments. In an embodiment, the blockchain is a data structure that stores, for example, data for a transaction in a manner that the transaction may be non-tamperable and subsequently verified. A block chain includes one or more blocks. Each block is linked to the immediately preceding block by a cryptographic hash value (cryptographical hash) that includes the immediately preceding block. Each tile may also include a timestamp, its own cryptographic hash value, and one or more transactions. Transactions that have been generally verified by nodes of a blockchain system may be hashed and encoded into a data structure such as a merkel (Merkle) tree. In a Merkle tree, data at leaf nodes is hashed, and all hash values in each branch of the tree may be joined at the root of the branch. This process continues down the tree up to the root of the entire tree where hash values representing all of the data in the tree are stored. The hash value of a transaction purportedly stored in the tree can be quickly verified by determining whether it is consistent with the structure of the tree.

The blockchain system includes a network of computing nodes that manage, update, and maintain one or more blockchains. The network may be a public blockchain network, a private blockchain network, or a federated blockchain network. For example, many entities, such as hundreds, thousands, or even millions of entities, may operate in a public blockchain network, and each entity operates at least one node in the public blockchain network. Thus, a public blockchain network may be considered a public network with respect to participating entities. Sometimes, most entities (nodes) must sign each chunk in order to verify and add the chunk to the blockchain of the blockchain network. Exemplary public blockchain networks include peer-to-peer (peer-to-peer) payment networks that utilize distributed ledgers referred to as blockchains.

Typically, public blockchain networks may support open transactions. The open transaction is shared by all nodes within the public blockchain network and stored in the global blockchain. A global blockchain is a blockchain that is replicated across nodes (e.g., complete blockchain nodes), and the nodes are in consensus with respect to the global blockchain. To achieve consensus (e.g., agree to add blocks to a blockchain), a consensus protocol is implemented within the public blockchain network. Examples of consensus protocols include proof of work (POW) (e.g., implemented in some cryptocurrency networks), proof of rights (POS), and proof of authority (POA).

Typically, a private blockchain network is provided for a particular entity that centrally controls read and write permissions. The entity controls which nodes can participate in the blockchain network. Thus, private blockchain networks are often referred to as authority networks, which limit who is allowed to participate in the network, as well as their level of participation (e.g., only in certain transactions). Various types of access control mechanisms may be used (e.g., existing participants vote to add a new entity, and regulatory authorities may control permissions).

Typically, a federated blockchain network is private between the participating entities. In a federated blockchain network, the consensus process is controlled by a set of authorized nodes, one or more of which are operated by corresponding entities (e.g., financial institutions, insurance companies). For example, a federation of ten (10) entities (e.g., financial institutions, insurance companies) may operate a federated blockchain network, and each entity may operate at least one node in the federated blockchain network. Thus, a federated blockchain network can be considered a private network associated with the participating entities. In some examples, each entity (node) must sign each chunk to validate the chunk and add it to the chain of chunks. In some examples, at least a subset of the entities (nodes) (e.g., at least 7 entities) must sign each chunk to validate the chunk and add it to the chain of chunks.

Fig. 1 shows a schematic diagram of a blockchain system 100 according to one embodiment. Referring to fig. 1, a blockchain system 100 may include a plurality of nodes, such as node 102 and 110, configured to operate on a blockchain 120. The nodes 102 and 110 may form a network 112, such as a peer-to-peer (P2P) network. Each of nodes 102 and 110 may be a computing device, such as a computer or computer system, configured to store a copy of block chain 120, or may be software, such as a process or application, running on the computing device. Each of the nodes 102 and 110 may have a unique identifier.

In some embodiments, blockchain 120 may include a growing list of records in the form of data chunks, such as chunks B1-B5 in FIG. 1. Each of tiles B1-B5 may include a timestamp, a cryptographic hash value of a previous tile, and data of the current tile, which may be a transaction such as a monetary transaction. For example, as shown in fig. 1, chunk B5 may include a timestamp, a cryptographic hash value for chunk B4, and transaction data for chunk B5. Further, for example, a hash operation may be performed on a previous chunk to generate a cryptographic hash value for the previous chunk. The hash operation may convert inputs of various lengths into fixed-length encrypted outputs by a hash algorithm such as SHA-256.

In some embodiments, node 102 and 110 are configured to perform operations on blockchain 120. For example, when a node (e.g., node 102) wants to store new data onto blockchain 120, the node generates a new block to be added to blockchain 120 and broadcasts the new block to other nodes in network 112, such as node 104 and 110. Based on the validity of the new tile, e.g., its signature and transaction validity, other nodes may determine to accept the new tile so that node 102 and other nodes may add the new tile to their respective copies of the blockchain 120. As this process repeats, more and more data chunks may be added to blockchain 120.

In some embodiments, the transaction is verified in the blockchain system 100 based on a cryptographic algorithm. The cryptographic algorithm may provide a key pair comprising a private key and a public key. The private key is associated with a particular user and may encrypt data representing, for example, a transaction initiated by the user. Encrypting data representing a transaction may also be referred to as signing the transaction. The public key is provided to another user in the blockchain system 100 to decrypt the encrypted data to verify whether the transaction is indeed authorized by the particular user. The decryption may also be referred to as signature verification. In one embodiment, the blockchain system 100 may support a variety of encryption algorithms, such as the RSA (Rivest-Shamir-Adleman) algorithm, the Elliptic Curve Digital Signature Algorithm (ECDSA), the SM2 algorithm, and the like.

In some embodiments, multiple signatures may be performed on transactions in the blockchain system 100. The multi-signature is a technique that allows a group of users and the generated private key set to sign the same transaction.

Fig. 2 is a flow diagram of a signature method 200 for use in a blockchain system, such as blockchain system 100 (fig. 1), according to an embodiment. Referring to fig. 2, in step 202, a hash value of data representing a transaction is generated by applying a hash algorithm to the data. In some embodiments, the hash value may also be referred to as a hash digest. In step 204, a signature for the transaction is further generated by encrypting the hash value using a private key of the first user (e.g., the user initiating the transaction) and an encryption algorithm. In step 206, the data representing the transaction and the generated signature are combined into a signed transaction.

Fig. 3 is a flow diagram of a signature verification method 300 for use in a blockchain system, such as blockchain system 100 (fig. 1), according to an embodiment. Referring to fig. 3, in step 302, the signed transaction is received and processed by the second user to obtain data representing the transaction and a signature for the transaction. In step 304, the signature of the transaction is decrypted using a public key corresponding to a private key of the encryption algorithm to obtain a first hash value. In step 306, a second hash value is generated by encrypting the obtained data representing the transaction using the same hash algorithm as the one used to sign the transaction. In step 308, the first hash value and the second hash value are compared to determine whether the signature and the signed transaction are valid. For example, if the first value matches the second value, it indicates that the private key used for encryption and the public key used for decryption are a pair, and therefore, the signature of the transaction is valid. Thus, the transaction may be verified as a valid transaction.

In some embodiments, the blockchain system may verify transactions signed by one or more users related to the transactions. For example, each user may be associated with one or more private keys. Accordingly, multiple signatures for transactions may be generated, and thus multiple signed transactions may be generated. In some embodiments, the plurality of signatures may correspond to different weights, respectively. The blockchain system may verify the transaction based on the validity and corresponding weight of each signature. In one embodiment, a "1" indicates that the blockchain system determines that the signature (and thus the signature transaction) is valid, and a "0" indicates that the blockchain system determines that the signature is invalid. The blockchain system may verify the transaction based on a weighted sum of the validity of each signature. For example, if the weighted sum is greater than a predetermined threshold, e.g., 70%, the blockchain system verifies the transaction as a valid transaction.

In some embodiments, the blockchain system may support one or more cryptographic algorithms for signature verification. Signature verification by a blockchain system may be tested using the methods and apparatus described below.

Fig. 4 is a flow diagram of a method 400 for testing signature verification for a blockchain system, such as blockchain system 100 (fig. 1), according to one embodiment. For example, the method 400 may be performed by a computer system. Referring to fig. 4, the method 400 may include the following steps.

In step 402, one or more test configurations are obtained from a configuration file. For example, the configuration file may be generated by a user or automatically by a computer system, and the configuration file may be loaded into the computer system. Further, for example, each test configuration in the configuration file may specify a cryptographic algorithm used in the blockchain system to test signature verification, a set of private keys corresponding to the cryptographic algorithm that includes one or more private keys, and a predetermined execution result based on the cryptographic algorithm and the set of private keys. In some embodiments, each test configuration may also be referred to as a use case or a test use case.

In some embodiments, each private key in the test configuration may be a valid private key or an invalid private key. For example, the test configuration may contain duplicate private keys, one private key being valid and the other private key being invalid, to test for the case where a transaction is signed twice using the same private key. By setting a private key for each test configuration in the configuration file, the method 400 can automatically test signature verification under different combinations of private keys used in the actual situation.

In some embodiments, a representation of each of the one or more private keys may be included in the configuration file. For example, a private key is typically a series of numbers, such as 256-bit numbers for the SM2 algorithm. To save the file size of the configuration file and facilitate the user's generation and viewing of the configuration file, the configuration file may include a representation of the private key, rather than the 256-bit private key itself. For example, the representation of the private key may include an address where the private key is stored. Further, for example, the representation of the private key may include an alias of the private key, such as "private 1," so that the corresponding private key may be identified and retrieved.

In some embodiments, the predetermined execution result of the test configuration may indicate an expected result when the corresponding encryption algorithm and private key set in the test configuration are used to sign the transaction. For example, if the same private key is not allowed to sign a transaction twice in a blockchain system, the predetermined execution result of the test configuration specifying the duplicate private key may be set to "invalid".

In one embodiment, the configuration file may be in the form of a table, such as table 1 below.

TABLE 1

In one embodiment, test configuration 1 is arranged for testing signature verification requiring transactions signed with private keys private 1, private 2 and private 3 by the ECDSA algorithm; test configuration 2 is provided for testing signature verification that does not allow transactions signed with duplicate private keys private 2 and private key2 by the SM2 algorithm; the test configuration 3 is provided for test signature verification that requires transactions signed with private keys private 1, private 2 and private 4 by the SM2 algorithm.

In some embodiments, a threshold for signature verification for transactions that require signatures by multiple users may be predetermined. For example, the threshold may be set to 70% to validate the signature verification for the transaction. Thus, if, for example, the weighted sum of the validity of each signature generated based on the test configuration is assumed to be greater than 70%, the predetermined execution result of the test configuration may be set to "valid".

In some embodiments, the testing of signature verification may be performed in parallel or sequentially based on the test configuration in the configuration file. For example, multiple computer processes or threads may be generated for the test configuration in the configuration file in step 404 and may be executed in parallel to improve test efficiency.

In step 406, a transaction is generated for each test configuration in the configuration file. In some embodiments, different types of transactions may be generated to perform tests based on the test configuration. For example, a transaction for registering an account and a transaction for transferring cryptocurrency may be generated. By generating different types of transactions, the cryptographic algorithms and private keys in the test configuration may be tested in a variety of scenarios.

In step 408, if the test configuration includes a representation of the private key, the private key may be obtained based on the representation. For example, if the test configuration includes an address where the private key is stored, the private key may be retrieved from the address. Further, for example, the test configuration includes an alias of the private key (e.g., "private 1"), and the private key may be obtained, for example, by checking a lookup table that includes a correspondence between the alias and the private key.

In step 410, the generated transaction is signed using the private key set in the test configuration. For example, a hash value of the generated transaction may be generated according to a predetermined hash algorithm. The generated transaction hash value may further be used to generate one or more signed transactions by encrypting the generated transaction hash value with one or more private keys of the set, for example, using method 200 (fig. 2).

In step 412, one or more signature transactions are sent to the blockchain system where test signature verification is performed. The blockchain system may receive one or more signature transactions for verification, for example, using method 300 (fig. 3), and return execution results corresponding to the test configuration. The execution result may indicate whether the transaction is valid or invalid.

In step 414, execution results are received from the blockchain system in which test signature verification is performed.

In step 416, it is determined whether a predetermined execution result in the test configuration is satisfied based on the execution result received from the blockchain system. For example, the received execution result is compared with a predetermined execution result in the corresponding configuration to determine whether the received execution result matches the predetermined execution result. A comparison result may be generated for the test configuration. For example, when the received execution result indicates that the transaction is valid and the predetermined execution result in the test configuration is also valid, the comparison result may indicate that the blockchain system is operating properly for signature verification of the test configuration. In another example, when the received execution result indicates that the transaction is invalid but the predetermined execution result in the test configuration is valid, the comparison result may indicate that the blockchain system is not operating properly for signature verification of the test configuration.

In step 418, the comparison results for each test configuration in the configuration file are obtained. For example, if the execution result of each test configuration received matches the corresponding predetermined execution result, it may be determined that the signature verification operation of the blockchain system is normal.

Fig. 5 shows a block diagram of an apparatus 500 for testing signature verification for a blockchain system according to an embodiment. For example, device 500 may perform method 400 (fig. 4). Referring to fig. 5, device 500 may include an obtaining module 502, a transaction signature module 504, a transceiver module 506, and a determining module 508.

The obtaining module 502 may obtain one or more test configurations from the configuration file. For example, the obtaining module 502 may include a configuration file loading unit 512 for loading a configuration file into the device 500. Further, for example, each test configuration in the configuration file may specify a cryptographic algorithm used in the blockchain system to test signature verification, a set of private keys corresponding to the cryptographic algorithm that includes one or more private keys, and a predetermined execution result based on the cryptographic algorithm and the set of private keys. Each test configuration may also be referred to as a use case or a test case.

In some embodiments, each private key specified in the test configuration may be a valid private key or an invalid private key. For example, a test configuration may contain duplicate private keys, one private key being valid and the other private key being invalid, to test for the case where a transaction is signed twice using the same private key. By setting a private key for each test configuration in the configuration file, the device 500 can automatically test signature verification under different combinations of private keys that can be used for practical situations.

In some embodiments, the predetermined execution result of the test configuration may indicate an expected result when the corresponding encryption algorithm and private key set in the test configuration are used to sign the transaction. For example, if the same private key is not allowed to sign a transaction twice, the predetermined execution result of the test configuration specifying the duplicate private key may be set to "invalid".

Transaction signing module 504 may sign the transaction by encrypting data representing the transaction based on a cryptographic algorithm and a private key set in each test configuration that includes one or more private keys to generate one or more signed transactions. The transaction signature module 504 may include a transaction generation unit 514, a private key mapping unit 516, and a signature unit 518.

Transaction generation unit 514 may generate a transaction for each test configuration in the configuration file. If the test configuration includes a representation of the private key, e.g., an alias of the private key, private key mapping unit 516 may map the representation of the private key to the private key itself by examining a lookup table that includes a correspondence between the alias and the private key. Signature unit 518 may sign the generated transaction using the private key set in the test configuration to generate one or more signed transactions.

The transceiver module 506 may send one or more signature transactions to the blockchain system for which test signature verification is performed. The blockchain system may receive and verify one or more signature transactions using method 300 (fig. 3). The transceiver module 506 may also receive execution results from the blockchain system indicating whether the transaction is valid or invalid.

The determination module 508 can determine whether a predetermined execution result is satisfied based on the execution results received from the blockchain system. For example, the determining module 508 may comprise a comparing unit 520 for comparing the received execution result with a predetermined execution result in the test configuration to determine whether the received execution result matches the predetermined execution result.

The device 500 may generate a determination result for each of the test configurations. In one embodiment, the apparatus 500 may determine that the signature verification of the blockchain system passes the test if the received execution result of each test configuration matches the corresponding predetermined execution result.

In some embodiments, each of the above modules and units may be implemented as software or hardware, or a combination of software and hardware. For example, each of the modules and units described above may be implemented using a processor executing instructions stored in a memory. Also, for example, each of the above modules and units may be implemented with one or more dedicated integrated circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), controllers, micro-controllers, microprocessors, or other electronic components for performing the below-described methods.

Fig. 6 is a flow diagram of a method 600 for testing signature verification for a blockchain system, according to another embodiment. The method 600 may be performed by a computer system. The computer system may include a memory storing a set of instructions and at least one processor configured to execute the set of instructions to cause the computer system to perform method 600. Referring to fig. 6, the method 600 may include the following steps.

In step 602, the computer system may obtain a profile comprising a plurality of test configurations, each test configuration specifying a private key set comprising one or more private keys, a corresponding encryption algorithm, and predetermined execution results based on the encryption algorithm and the private key set. The encryption algorithm may be the RSA algorithm, the ECDSA algorithm, or the SM2 algorithm.

In step 604, the computer system may generate a transaction to be signed based on each test configuration in the configuration file.

In step 606, the computer system may generate a plurality of test cases based on the configuration file. Each of the plurality of test cases corresponds to one of the test configurations in the configuration file. For example, each test case corresponds to a private key set including one or more private keys, a corresponding cryptographic algorithm, and a predetermined execution result based on the cryptographic algorithm and the private key set.

In step 608, the computer system may execute a plurality of test cases by signing the transaction using the private key set and the corresponding cryptographic algorithm and sending one or more signed transactions to the blockchain system. In some embodiments, the computer system may generate a hash value for the transaction, obtain one or more private keys according to the test configuration, and sign the transaction by encrypting the hash value with each obtained private key.

The computer system may receive execution results from the blockchain system and compare the execution results to predetermined execution results. The execution result may indicate whether the transaction is valid or invalid.

In step 610, the computer system may determine whether the received execution results match predetermined results in each test configuration and generate comparison results. The computer system may also determine that the signature verification is operating correctly in the blockchain system if the received execution results match predetermined results in each test configuration in the configuration file.

Fig. 7 is a block diagram of an apparatus 700 for testing signature verification for a blockchain system according to one embodiment. For example, device 700 may be implemented using a computer system. Referring to fig. 7, device 700 may include a processor 702, a memory 704, a communication interface 706, and a display 708.

In some embodiments, the processor 702 may execute instructions to perform the above-described methods. The processor 702 may include one or more modules that facilitate testing. For example, processor 702 may include an obtaining module 502, a transaction signature module 504, a transceiver module 506, and a determining module 508 (fig. 5).

In some embodiments, the memory 704 may store instructions for performing the above-described methods. The memory 704 may be implemented as any type or combination of volatile or non-volatile memory devices, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, or magnetic or optical disks.

In some embodiments, communication interface 706 may facilitate communication between device 700 and other devices. Communication interface 706 may support one or more communication standards such as the internet standard or protocol, the Integrated Services Digital Network (ISDN) standard, and so on.

In some embodiments, the display 708 may display the test results when performing the above-described method. For example, display 708 may be a Liquid Crystal Display (LCD). Also, for example, display 708 may include a touch screen for receiving user input.

In some embodiments, a computer program product is also provided. The computer program product may include a non-transitory computer readable storage medium having computer readable program instructions thereon for causing a processor to perform the above-described method.

The computer readable storage medium may be a tangible device that may store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a Static Random Access Memory (SRAM), a portable compact disc read-only memory (CD-ROM), a Digital Versatile Disc (DVD), a memory stick, a floppy disk, a mechanical coding device such as a punch card or a raised pattern in a recess having instructions recorded thereon, and any suitable combination of the foregoing.

The computer-readable program instructions for performing the above-described methods may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including an object oriented programming language and a conventional procedural programming language. The computer-readable program instructions may be executed entirely on a computer system as a stand-alone software package, or partially on a first computer and partially on a second computer remote from the first computer. In the latter scenario, the second remote computer may be connected to the first computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN).

The computer-readable program instructions may be provided to a processor of a general purpose or special purpose computer or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the methods described above.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments herein. In this regard, the blocks in the flowchart or block diagrams may represent software programs, segments, or portions of code, which comprise one or more executable instructions for implementing the specified functions. It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

It is appreciated that certain features of the specification, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the disclosure that are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination, or as suitable in any other described embodiment herein. Unless otherwise indicated, certain features described in the context of various embodiments should not be considered essential features of those embodiments.

While the present invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, the following claims are intended to embrace all such alternatives, modifications and variances which fall within the scope of the appended claims.