A general method for constructing performance test datasets for blockchain systems

Abstract

This invention discloses a general method for constructing a performance test dataset for blockchain systems, relating to the field of system performance testing technology. The method includes the following steps: S1, determining the transaction type; S2, generating user accounts; S3, pre-setting account data; S4, generating random transaction relationships; S5, creating a transaction body; and S6, saving the transaction file. This general method for constructing a performance test dataset for blockchain systems, from the perspective of practical application scenarios, simulates applications with multiple users and different domains. The randomness of the test data ensures the fairness of the test results. It also specifies the dataset construction method for blockchain system performance testing, including six steps: determining the transaction type, generating user accounts, pre-setting account data, generating random transaction relationships, creating a transaction body, and saving the transaction file. By standardizing the construction of the performance test dataset, the performance testing process for different blockchain systems can be more standardized.

Description

Technical Field

[0001] This invention relates to the field of system performance testing technology, specifically a general method for constructing a blockchain system performance test dataset. Background Technology

[0002] As a novel information technology, blockchain is still in its early stages of development and has much room for improvement. Performance, as a crucial indicator of blockchain technology capabilities, has made performance testing one of the most important areas of focus in the industry. However, due to the different implementation methods of various blockchain systems, how to fairly, comprehensively, and objectively evaluate the performance of different blockchain systems remains a challenge.

[0003] Currently, the industry has proposed various blockchain system performance testing tools to support stress testing on different types of blockchains. However, a unified performance testing dataset has not yet been established, nor has a method for constructing such a dataset been proposed. A blockchain system performance testing dataset is crucial for ensuring the fairness of testing. By standardizing the types of transactions, transaction sizes, number of accounts, and transfer rules involved in stress testing, the fairness and universality of performance testing across different scenarios can be guaranteed.

[0004] Therefore, in order to fill the gap in the construction method of blockchain system performance test dataset, this invention provides a general method for constructing blockchain system performance test dataset, which aims to provide dataset support for blockchain system performance testing. Summary of the Invention

[0005] The purpose of this invention is to provide a general method for constructing a performance test dataset for blockchain systems, in order to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a general method for constructing a performance test dataset for a blockchain system, comprising the following steps:

[0007] S1. Determine the transaction type: Design different types of transactions for blockchain system performance testing for different blockchain application scenarios, so as to fully verify the performance limit of the blockchain system;

[0008] S2. Generate user accounts: Before starting the performance testing of the blockchain system, ensure that there are a certain number of accounts in the system. The accounts are the main body for executing transactions in the blockchain system, and the number of accounts should be set according to the actual application scenario of the blockchain system.

[0009] S3. Pre-configured account data: Based on different transaction types, pre-configure sufficient data for the account to support the smooth execution of transactions, and use it for transaction processing during performance testing;

[0010] S4. Generate random transaction relationships: For different transaction types, different methods are used to ensure the randomness of transactions, in order to simulate the situation in real environment where user behavior is difficult to predict and user transaction conditions are complex.

[0011] S5. Create a transaction body: Simulate the actual execution process of a transaction, create a transaction body for performance testing, and after the created transaction body completes the signing process, send it directly to the blockchain system for subsequent transaction execution;

[0012] S6. Save transaction files: Convert the constructed transaction body into a specific format such as JSON or XML, save it to a file to form a performance test dataset for subsequent performance testing.

[0013] Furthermore, in step S1, the blockchain system transaction types are divided into four categories: transfer transactions, evidence storage transactions, query transactions, and configuration transactions, as detailed below:

[0014] Transfer transactions: Transactions that transfer account balances from one account to another. The result of such transactions is an increase in the balance of the sending account and a decrease in the balance of the receiving account. Transfer transactions are a basic transaction type that blockchain systems should support and are also the most widely used transaction type.

[0015] Evidence storage transactions: These transactions store specific content in an account, and the stored content can be retrieved through that account. Evidence storage transactions establish a binding relationship between the stored content and the account (similar to storing data in a database, where the account name is the primary key and the stored content is the value corresponding to that key). They are widely used in consortium blockchain platforms, with application scenarios including traceability, judicial processes, and electronic invoices.

[0016] Query transactions: Transactions that retrieve content stored in the blockchain system based on specific conditions;

[0017] Configuration transactions: Transactions that directly modify the blockchain network configuration by sending a transaction with configuration modification parameters to the blockchain system. These transactions are suitable for blockchain systems that store blockchain network configuration parameters in blocks. Configuration transactions are usually part of operations and maintenance and are not used as performance testing objects.

[0018] Furthermore, the query transactions are divided into two types based on the different query conditions: simple queries and complex queries.

[0019] The simple query uses a single value as the query condition, which can be an account address, transaction ID, block height, or a specific key value set when storing data on the chain.

[0020] The complex query is performed by combining multiple query conditions or by querying according to a specific range. For numerical results, the query can also be performed by a range of values, such as greater than, less than, or interval.

[0021] Furthermore, the query transactions are categorized into six types based on the query object: account balance query, account evidence storage query, block information query, transaction information query, transaction history query, and system configuration query.

[0022] Account Balance Inquiry: Query the balance data of a specific account; the blockchain system account model includes two types: UTXO (Unspent Transaction Output) model and state model. Based on the difference in account models, the query methods are different; for the UTXO account model, the account balance is calculated by tracing back the income and expenditure of each transaction according to all related transactions of the account; for the state model, the current balance is obtained directly by querying the current state of the account.

[0023] Account storage query: Query the data stored in a specific account or account address; due to differences in the architectural design of blockchain systems, the length of data stored in account addresses varies, including text data, encrypted characters, data hashes, etc.

[0024] Block information query: Obtain detailed information about a specific block by its unique identifier, such as block hash or block height, including block generation time, previous blockchain hash, transaction list, etc.

[0025] Transaction information query: By using the unique identifier of a transaction, such as the transaction hash, you can obtain detailed information about a specific blockchain, including the block on which the transaction is located, the initiating account and the destination account, and the transaction content.

[0026] Transaction history query: Based on a specific account address or evidence data, retrieve all transaction records related to that address or data. Through these records, all transaction records of that account or all flow records of that data can be traced. This is the core operation of traceability applications.

[0027] System configuration query: retrieves the configuration information of a blockchain system, including consensus type, block production rules, encryption method, etc.; and system configuration query is only applicable to blockchain systems that record configuration information in blocks. Other blockchain systems can be queried by querying configuration files or other methods.

[0028] Furthermore, in step S2, in order to verify the performance of the blockchain under different user scales, different user scales are set in a gradient manner to simulate different user scales, and the gradient is designed according to the scales of thousands, tens of thousands, hundreds of thousands, and millions.

[0029] Furthermore, in step S3, the account data for different transaction types is preset as follows:

[0030] For transfer transactions: Reserve the account with the largest possible balance to ensure that the transaction will not fail due to insufficient account balance, thus affecting the performance test results;

[0031] Evidence storage transactions: Based on the actual scenario, a certain amount of data is stored in the account. The data size and data type can be set according to the data in the actual application. The data is set as a random string. In this embodiment, for applications that only save hashes on the chain, the data preset in the account should be at least a 64-bit string. For scenarios that need to save more content on the chain, a random string of 200 bytes or 2048 bytes can be set.

[0032] Query-type transactions: Testing will be conducted after a large number of transfer or evidence storage transactions have been completed and the system has accumulated a large amount of transaction data.

[0033] Configuration-related transactions: When performance testing of configuration-related transactions is required, tests can be conducted on configuration parameters that support dynamic modification, such as consensus participating nodes, consensus algorithm switching, block production conditions, and cryptographic algorithm switching.

[0034] Furthermore, in step S4, the randomness of different transaction types is specifically achieved through the following methods:

[0035] For transfer transactions: both the sending and receiving accounts are randomly selected from preset accounts, and the transfer amount is also randomly set. In this embodiment, an account is randomly selected from the preset accounts as the sending account, and then an account is randomly selected as the receiving account. The sending and receiving accounts can be the same. The transfer amount is a positive number ≥ 0 and can be a decimal. During the transfer process, it must be ensured that the amount transferred in and out of each transaction is strictly consistent, and the sum of the balances of the sending and receiving accounts after the transfer cannot be different from that before the transfer.

[0036] For evidence-based transactions: the two accounts for sending and receiving data are randomly selected from preset accounts, and the content of the evidence-based data cannot be changed before and after the transfer.

[0037] Query-type transactions: For different types of query transactions, a certain condition should be randomly queried, that is, the query parameters are random. For example, for account balance query, an existing account in the blockchain system should be randomly selected for query. For complex queries with combined conditions, each query condition is random.

[0038] Configuration-related transactions: Considering the stability of system operation, it is not recommended to conduct tests involving a large number of random configuration modifications.

[0039] Furthermore, in step S5, the actual transaction execution process is as follows: users complete the construction, signing, and packaging of the transaction on their respective clients, and then send transaction requests to the blockchain nodes respectively.

[0040] Furthermore, in step S5, the process of creating a transaction body involves: constructing a transaction proposal containing transaction parameters through the client of the tested blockchain system based on the preset transaction account and transaction logic, and completing the transaction signature. The transaction body can be directly sent to the blockchain system and can be successfully executed.

[0041] This invention provides a general method for constructing a performance test dataset for blockchain systems, which has the following advantages:

[0042] This invention, from the perspective of practical application scenarios, simulates multi-user applications across different fields, ensuring fairness in test results through the randomness of test data. This invention specifies a method for constructing datasets for blockchain system performance testing, including six steps: determining transaction types, generating user accounts, pre-setting account data, generating random transaction relationships, creating transaction bodies, and saving transaction files. By standardizing the construction of performance test datasets, the performance testing process for different blockchain systems can be more standardized, ensuring fairness in performance testing. Furthermore, as a universal construction method, it can be applied to various blockchain systems. Attached Figure Description

[0043] Figure 1 This is a schematic diagram illustrating the operational flow of a general blockchain system performance test dataset construction method according to the present invention. Detailed Implementation

[0044] The embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and should not be construed as limiting the scope of the invention.

[0045] like Figure 1 As shown, a general method for constructing a performance test dataset for a blockchain system includes the following steps:

[0046] S1. Determine Transaction Types: For different blockchain application scenarios, design different types of transactions for blockchain system performance testing to fully verify the performance limits of the blockchain system. Blockchain system transaction types are divided into four categories: transfer transactions, evidence storage transactions, query transactions, and configuration transactions, as detailed below:

[0047] 1) Transfer transactions: Transactions that transfer account balances from one account to another. The result of such transactions is an increase in the balance of the sending account and a decrease in the balance of the receiving account. Transfer transactions are a basic transaction type that blockchain systems should support and are also the most widely used transaction type.

[0048] 2) Evidence storage transactions: These transactions store specific content in an account, and the stored content can be retrieved through that account. Evidence storage transactions establish a binding relationship between the stored content and the account (similar to storing data in a database, where the account name is the primary key and the stored content is the value corresponding to that key). They are widely used in consortium blockchain platforms, with application scenarios including traceability, judicial processes, and electronic invoices.

[0049] 3) Query transactions: Transactions that retrieve content stored in the blockchain system based on specific conditions;

[0050] A. Based on different query conditions, it is divided into:

[0051] Simple query: Query using a single value as the query condition, where the query condition is an account address, transaction ID, block height, or a specific key-value pair set when storing data on the chain;

[0052] Complex queries: queries can be performed by combining multiple query conditions or by querying within a specific range. For numerical results, queries can also be performed by specifying the range of values, such as greater than, less than, or interval.

[0053] B. Based on the different objects being queried, they are divided into:

[0054] Account Balance Inquiry: Query the balance data of a specific account; the blockchain system account model includes two types: UTXO (Unspent Transaction Output) model and state model. Based on the difference in account models, the query methods are different; for the UTXO account model, the account balance is calculated by tracing back the income and expenditure of each transaction according to all related transactions of the account; for the state model, the current balance is obtained directly by querying the current state of the account.

[0055] Account storage query: Query the data stored in a specific account or account address; due to differences in the architectural design of blockchain systems, the length of data stored in account addresses varies, including text data, encrypted characters, data hashes, etc.

[0056] Block information query: Obtain detailed information about a specific block by its unique identifier, such as block hash or block height, including block generation time, previous blockchain hash, transaction list, etc.

[0057] Transaction information query: By using the unique identifier of a transaction, such as the transaction hash, you can obtain detailed information about a specific blockchain, including the block on which the transaction is located, the initiating account and the destination account, and the transaction content.

[0058] Transaction history query: Based on a specific account address or evidence data, retrieve all transaction records related to that address or data. Through these records, all transaction records of that account or all flow records of that data can be traced. This is the core operation of traceability applications.

[0059] System configuration query: Retrieves the configuration information of a blockchain system, including consensus type, block production rules, encryption method, etc.; and system configuration query is only applicable to blockchain systems that record configuration information in blocks. Other blockchain systems can query configuration files or other methods.

[0060] 4) Configuration transactions: Transactions that directly modify the blockchain network configuration by sending a transaction with configuration modification parameters to the blockchain system. These transactions are suitable for blockchain systems that store blockchain network configuration parameters in blocks. Configuration transactions are usually part of operations and maintenance and are not used as performance testing objects.

[0061] S2. Generate user accounts: Before starting the performance test of the blockchain system, ensure that there are a certain number of accounts in the system. The accounts are the main body for the execution of blockchain system transactions. The number of accounts is set according to the actual application scenario of the blockchain system. In order to verify the performance of the blockchain under different user scales, different scales of users are set in a gradient manner to simulate different user scales. The gradient is designed according to the scale of thousands, tens of thousands, hundreds of thousands, and millions.

[0062] S3. Pre-configured account data: Based on different transaction types, pre-configure sufficient data for the account to support the smooth execution of transactions, and use it for transaction processing during performance testing;

[0063] In this embodiment, the account data for different transaction types is preset as follows:

[0064] For transfer transactions: Reserve the account with the largest possible balance to ensure that the transaction will not fail due to insufficient account balance, thus affecting the performance test results;

[0065] Evidence storage transactions: Based on the actual scenario, a certain amount of data is stored in the account. The data size and data type can be set according to the data in the actual application. The data is set as a random string. In this embodiment, for applications that only save hashes on the chain, the data preset in the account should be at least a 64-bit string. For scenarios that need to save more content on the chain, a random string of 200 bytes or 2048 bytes can be set.

[0066] Query-type transactions: Testing will be conducted after a large number of transfer or evidence storage transactions have been completed and the system has accumulated a large amount of transaction data.

[0067] Configuration-related transactions: When it is necessary to perform performance testing on configuration-related transactions, tests can be conducted on configuration parameters that support dynamic modification, such as consensus participating nodes, consensus algorithm switching, block production conditions, cryptographic algorithm switching, etc.

[0068] S4. Generate random transaction relationships: For different transaction types, different methods are used to ensure the randomness of transactions, in order to simulate the situation in real environment where user behavior is difficult to predict and user transaction conditions are complex.

[0069] In this embodiment, the randomness of different transaction types is specifically achieved through the following methods:

[0070] For transfer transactions: both the sending and receiving accounts are randomly selected from preset accounts, and the transfer amount is also randomly set. In this embodiment, an account is randomly selected from the preset accounts as the sending account, and then an account is randomly selected as the receiving account. The sending and receiving accounts can be the same. The transfer amount is a positive number ≥ 0 and can be a decimal. During the transfer process, it must be ensured that the amount transferred in and out of each transaction is strictly consistent, and the sum of the balances of the sending and receiving accounts after the transfer cannot be different from that before the transfer.

[0071] For evidence-based transactions: the two accounts for sending and receiving data are randomly selected from preset accounts, and the content of the evidence-based data cannot be changed before and after the transfer.

[0072] Query-type transactions: For different types of query transactions, a certain condition should be randomly queried, that is, the query parameters are random. For example, for account balance query, an existing account in the blockchain system should be randomly selected for query. For complex queries with combined conditions, each query condition is random.

[0073] Configuration-related transactions: Considering the stability of system operation, it is not recommended to conduct tests involving a large number of random configuration modifications;

[0074] S5. Create a transaction body: Simulate the actual execution process of a transaction (i.e., users complete the construction, signing and packaging of the transaction on their respective clients, and then send transaction requests to the blockchain node respectively), create a transaction body for performance testing, and after the created transaction body completes the signing process, it is directly sent to the blockchain system for subsequent transaction execution.

[0075] In this embodiment, the process of creating a transaction body is as follows: based on the preset transaction account and transaction logic, a transaction proposal containing transaction parameters is constructed through the client of the blockchain system under test, and the transaction signature is completed. The transaction body can be directly sent to the blockchain system and can be successfully executed.

[0076] S6. Save transaction files: Convert the constructed transaction body into a specific format such as JSON or XML, save it to a file to form a performance test dataset for subsequent performance testing.

[0077] The above embodiments have been used in the "Trusted Blockchain Performance" special test of the China Academy of Information and Communications Technology (CAICT), and have completed performance tests on more than 40 blockchain products. Currently, they have been verified in blockchain systems such as Chang'an Chain, FISCO BCOS, SuperChain, and Hyperledger, and have successfully passed the "Trusted Blockchain Performance" test of CAICT.

[0078] The embodiments of the present invention are given for illustrative and descriptive purposes only, and are not intended to be exhaustive or to limit the invention to the forms disclosed. Many modifications and variations will be apparent to those skilled in the art. The embodiments were chosen and described in order to better illustrate the principles and practical application of the invention, and to enable those skilled in the art to understand the invention and to design various embodiments with various modifications suitable for a particular purpose.

Claims

1. A general method for constructing a performance test dataset for blockchain systems, characterized in that, Includes the following steps: S1. Determine the transaction type: Design different types of transactions for blockchain system performance testing for different blockchain application scenarios, so as to fully verify the performance limit of the blockchain system; S2. Generate user accounts: Before starting the performance test of the blockchain system, ensure that there are a certain number of accounts in the system, and set the number of accounts according to the actual application scenario of the blockchain system. S3. Pre-configured account data: Based on different transaction types, pre-configure sufficient data for the account to support the smooth execution of transactions, and use it for transaction processing during performance testing; S4. Generate random transaction relationships: For different transaction types, different methods are used to ensure the randomness of transactions, in order to simulate the situation in real environment where user behavior is difficult to predict and user transaction conditions are complex. S5. Create a transaction body: Simulate the actual execution process of a transaction, create a transaction body for performance testing, and after the created transaction body completes the signing process, send it directly to the blockchain system for subsequent transaction execution; S6. Save transaction file: Convert the constructed transaction body into a specific format and save it to a file to form a performance test dataset; In step S1, the blockchain system transactions are categorized into four types: transfer transactions, evidence storage transactions, query transactions, and configuration transactions, as detailed below: Transfer transactions: Transactions that transfer account balances from one account to another, resulting in an increase in the balance of the sending account and a decrease in the balance of the receiving account; Evidence storage transactions: These are transactions that store specific content in an account and allow the stored content to be retrieved through that account. Evidence storage transactions establish a binding relationship between the stored content and the account. Application scenarios include traceability, judicial processes, and electronic invoices. Query transactions: Transactions that retrieve content stored in the blockchain system based on specific conditions; Configuration transactions: Transactions that directly modify the blockchain network configuration by sending a transaction with configuration modification parameters to the blockchain system. These are suitable for blockchain systems that store blockchain network configuration parameters in blocks.

2. The method for constructing a general blockchain system performance test dataset according to claim 1, characterized in that, The query transactions are divided into two types based on the different query conditions: simple queries and complex queries. The simple query uses a single value as the query condition, which can be an account address, transaction ID, block height, or a specific key value set when storing data on the chain. The complex query is performed by combining multiple query conditions or by querying according to a specific range.

3. The method for constructing a general blockchain system performance test dataset according to claim 2, characterized in that, The query transactions are divided into six types based on the different query objects: account balance query, account evidence storage query, block information query, transaction information query, transaction history query, and system configuration query. Account Balance Inquiry: Inquire about the balance of a specific account; the blockchain system account model includes two types: UTXO model and state model. Based on the difference in account models, the query methods are different; for the UTXO account model, the account balance is calculated by tracing back the income and expenditure of each transaction according to all related transactions of the account; for the state model, the current balance is obtained by directly querying the current state of the account. Account storage query: Query the data stored in a specific account or account address; due to differences in the architectural design of blockchain systems, the length of data stored in an account address may vary. Block information query: Obtain detailed information about a specific block by using the block hash or the block height, which are unique identifiers of the block. Transaction information query: Obtain detailed information about a specific blockchain by using the transaction hash, the unique identifier of the transaction; Transaction history query: Based on a specific account address or evidence data, retrieve all transaction records related to that address or data. Through these records, you can trace all transaction records of that account or all flow records of that data. System configuration query: retrieves the configuration information of the blockchain system, including consensus type, block production rules, and encryption method; and the system configuration query is only applicable to blockchain systems that record configuration information in blocks.

4. The method for constructing a general blockchain system performance test dataset according to claim 1, characterized in that, In step S2, different user numbers are set in a gradient manner to simulate different user scales, and the gradient is designed according to the scale of thousands, tens of thousands, hundreds of thousands, and millions.

5. The method for constructing a general blockchain system performance test dataset according to claim 1, characterized in that, In step S3, the account data for different transaction types is preset as follows: For transfer transactions: Reserve the largest possible balance in the account to ensure that the transaction will not fail due to insufficient account balance; Evidence storage transactions: Based on the actual scenario, a certain amount of data is stored in the account. The data size and data type can be set according to the data in the actual application. The data is set as a random string. Query-type transactions: Testing will be conducted after a large number of transfer or evidence storage transactions have been completed and the system has accumulated a large amount of transaction data. Configuration-related transactions: Test configuration parameters that support dynamic modification, such as consensus participating nodes, consensus algorithm switching, block production conditions, and cryptographic algorithm switching.

6. The method for constructing a general blockchain system performance test dataset according to claim 1, characterized in that, In step S4, the randomness of different transaction types is specifically achieved through the following methods: For transfer transactions: Both the sending and receiving accounts are randomly selected from preset accounts, and the transfer amount is also randomly set; during the transfer process, it must be ensured that the amount transferred in and out of each transaction is strictly consistent, and the sum of the balances of the sending and receiving accounts after the transfer must not be different from that before the transfer. For evidence-based transactions: the two accounts for sending and receiving data are randomly selected from preset accounts, and the content of the evidence-based data cannot be changed before and after the transfer. Query-type transactions: For different types of query transactions, a certain condition should be randomly queried, that is, the query parameters are random. For complex queries with combined conditions, each query condition is random. Configuration-related transactions: Considering the stability of system operation, it is not recommended to conduct tests involving a large number of random configuration modifications.

7. The method for constructing a general blockchain system performance test dataset according to claim 1, characterized in that, In step S5, the actual transaction execution process is as follows: users complete the construction, signing, and packaging of the transaction on their respective clients, and then send transaction requests to the blockchain nodes respectively.

8. The method for constructing a general blockchain system performance test dataset according to claim 1, characterized in that, In step S5, the process of creating a transaction body is as follows: based on the preset transaction account and transaction logic, a transaction proposal containing transaction parameters is constructed through the client of the blockchain system under test, and the transaction signature is completed. The transaction body can be directly sent to the blockchain system and can be successfully executed.

Images