Universal block chain system performance test data set construction method

Abstract

The invention discloses a universal block chain system performance test data set construction method, and relates to the technical field of system performance test, and the method comprises the steps: S1, determining a transaction type; s2, generating a user account; s3, account data are preset; s4, generating a random transaction relationship; s5, creating a transaction body; and S6, storing the transaction file. According to the universal block chain system performance test data set construction method, from the perspective of an actual application scene, applications of multiple users and different fields are simulated, and the fairness of a test effect is ensured through the randomness of test data; a data set construction method during the performance test of the block chain system is stipulated, and the method comprises six steps of determining a transaction type, generating a user account, presetting account data, generating a random transaction relationship, creating a transaction body and storing a transaction file. And the performance test process of different block chain systems can be more standardized.

Description

Technical Field

[0001] The present invention relates to the technical field of system performance testing, and in particular to a method for constructing a universal blockchain system performance testing data set. Background Art

[0002] As a new type of information technology, blockchain is still in the early stages of development and has a lot of room for technical improvement. Performance is an important indicator for evaluating blockchain technology capabilities, making performance testing one of the most concerned topics in the industry. However, due to the different implementation methods of various blockchain systems, it is still a challenge to evaluate the performance of different blockchain systems in a fair, comprehensive and objective manner.

[0003] At present, the industry has proposed a variety of blockchain system performance testing tools to support stress testing of different types of blockchains, but there is no unified performance testing data set in the industry, nor has a method for constructing relevant data sets been proposed. The blockchain system performance testing data set is an important part of ensuring the fairness of the test. By standardizing the transaction type, transaction size, number of accounts, transfer rules, etc. during the performance test, the fairness and universality of performance testing in different scenarios can be guaranteed.

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

[0005] The purpose of the present invention is to provide a general method for constructing a blockchain system performance test data set to solve the problems raised in the above background technology.

[0006] To achieve the above purpose, the present invention provides the following technical solution: a general method for constructing a blockchain system performance test data set, 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 to fully verify the performance ceiling of the blockchain system;

[0008] S2. Generate user accounts: Before starting the blockchain system performance test, ensure that there are a certain number of accounts in the system. Accounts are the main body of blockchain system transaction execution, and the number of accounts is set according to the actual application scenario of the blockchain system;

[0009] S3. Preset account data: According to different transaction types, pre-set data sufficient to support the smooth execution of transactions for the account, which is used 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 to simulate the real environment where user behavior is difficult to predict and user transaction conditions are complex;

[0011] S5. Create a transaction body: simulate the actual transaction execution process, 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 file: Convert the constructed transaction body into a specific format such as JSON or XML, save it into a file, and form a performance test data set for subsequent performance testing processes.

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

[0014] Transfer transactions: transactions that transfer account balances from one account to another. The result of the transaction is that the balance of the outgoing account increases and the balance of the incoming account decreases. Transfer transactions are the basic transaction type that the blockchain system should support and are also the most widely used transaction type.

[0015] Evidence transactions: transactions that store a specific piece of content in an account, and the stored content can be queried through the account. Evidence transactions determine the binding relationship between the stored content and the account (similar to storing data in a database, the account name is the primary key, and the stored content is the value corresponding to the key). It is widely used in alliance chain platforms, and application scenarios include traceability, judicial, electronic bills, etc.

[0016] Query transactions: transactions that obtain content stored in the blockchain system through specific conditions;

[0017] Configuration transactions: transactions that directly modify the blockchain network configuration by sending transactions with configuration modification parameters to the blockchain system. They are applicable to blockchain systems that store blockchain network configuration parameters in blocks. Configuration transactions are usually part of operation and maintenance and are not the subject of performance testing.

[0018] Furthermore, the query type transactions are divided into two types: simple query and complex query according to different query conditions;

[0019] The simple query uses a single value as the query condition, and the query condition is the 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 querying according to a specific range. For numerical results, a result set within a certain range can also be queried by value range, such as greater than, less than, interval, etc.

[0021] Furthermore, the query transactions are divided into six types according to the query objects: account balance query, account evidence query, block information query, transaction information query, transaction history query, and system configuration query:

[0022] Account balance query: query the data of a specific account balance; the account model of the blockchain system includes two models: UTXO (Unspent Transaction Output) model and state model. Based on the difference in account models, the query method is different; for the UTXO account model, according to all the associated transactions of the account, the income and expenditure of each transaction are traced back one by one to calculate the balance of the account; for the account model, the current state of the account is directly obtained through query to obtain the current balance;

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

[0024] Block information query: Get detailed information of a specific block through the unique identifier of the block such as block hash or block height, including block generation time, previous blockchain hash, transaction list, etc.;

[0025] Transaction information query: Get detailed information of a specific blockchain through the unique identifier of the transaction such as the transaction hash, including the block where the transaction is located, the transaction initiator account and destination account, transaction content, etc.

[0026] Transaction history query: Based on a specific account address or stored evidence data, obtain all transaction records related to the address or data. Through these records, all transaction records of the account or all flow records of the data can be traced back, which is the core operation of the traceability application;

[0027] System configuration query: Obtain the configuration information of the blockchain system, including consensus type, block generation 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 capability 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, account data of different transaction types are preset as follows:

[0030] Transfer transactions: preset a balance as large as possible for the account to ensure that the transaction will not fail due to insufficient account balance during the transaction, which will affect the results of the performance test;

[0031] Evidence storage transactions: according to 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, and the data is set as a random string. In this embodiment, for applications that only store hashes on the chain, the data preset in the account should be at least a 64-bit string. For scenarios where more content needs to be stored on the chain, a 200-byte or 2048-byte random string can be set.

[0032] Query transactions: After a large number of transfer transactions or evidence storage transactions, the system will be tested after accumulating a large amount of transaction data;

[0033] Configuration transactions: When performance testing of configuration transactions is required, you can test configuration parameters that support dynamic modification, such as consensus participating nodes, consensus algorithm switching, block conditions, cryptographic algorithm switching, etc.

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

[0035] Transfer transactions: The accounts for transfer out and transfer in are randomly selected from the preset accounts, and the transfer amount is also randomly set; in this embodiment, an account is randomly selected from the preset accounts as the transfer out account, and then an account is randomly selected as the transfer in account, and the transfer in and transfer out accounts can be the same, and the transfer amount is a positive number ≥ 0, and can be a decimal; during the transfer process, it is necessary to ensure that the transfer in and transfer out amounts of each transaction are strictly consistent, and the sum of the transfer in and transfer out account balances after the transfer cannot be different from that before the transfer;

[0036] Evidence transactions: The two accounts for sending and receiving data are randomly selected from the preset accounts, and the content of the evidence data cannot change before and after the transfer;

[0037] Query transactions: For different types of query transactions, a random query should be performed on a certain condition, 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 transactions: Considering the stability of system operation, it is not recommended to conduct tests that involve a large number of random configuration changes.

[0039] Furthermore, in step S5, the actual execution process of the transaction 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 is as follows: according to the preset transaction account and transaction logic, a transaction proposal including transaction parameters is constructed through the client of the tested blockchain system, and the transaction signature is completed. The transaction body can be directly sent to the blockchain system and can be successfully executed.

[0041] The present invention provides a general method for constructing a blockchain system performance test data set, which has the following beneficial effects:

[0042] The present invention simulates multi-user and different field applications from the perspective of actual application scenarios, and ensures the fairness of the test results through the randomness of the test data. The present invention specifies a data set construction method for blockchain system performance testing, including six steps: determining transaction type, generating user accounts, presetting account data, generating random transaction relationships, creating transaction bodies, and saving transaction files. By standardizing the construction of performance test data sets, the performance test process of different blockchain systems can be more standardized, ensuring the fairness of performance testing, and because it is a universal construction method, it can be applied to different blockchain systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 This is a schematic diagram of the operation flow of a general blockchain system performance test data set construction method of the present invention. DETAILED DESCRIPTION

[0044] The following embodiments of the present invention are described in further detail in conjunction with the accompanying drawings and examples. The following examples are used to illustrate the present invention, but are not intended to limit the scope of the present invention.

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

[0046] S1. Determine the transaction type: According to different blockchain application scenarios, different types of transactions are designed for blockchain system performance testing to fully verify the performance upper limit of the blockchain system; blockchain system transaction types are divided into four categories: transfer transactions, evidence transactions, query transactions, and configuration transactions, as follows:

[0047] 1) Transfer transactions: transactions that transfer account balances from one account to another. The result of the transaction is that the balance of the outgoing account increases and the balance of the incoming account decreases. Transfer transactions are the basic transaction type that the blockchain system should support and are also the most widely used transaction type.

[0048] 2) Evidence transactions: transactions that store a specific piece of content in an account, and the stored content can be queried through the account. Evidence transactions determine the binding relationship between the stored content and the account (similar to storing data in a database, the account name is the primary key, and the stored content is the value corresponding to the key). It is widely used in alliance chain platforms, and application scenarios include traceability, judicial, electronic bills, etc.

[0049] 3) Query transactions: transactions that obtain content stored in the blockchain system through specific conditions;

[0050] A. According to different query conditions, it is divided into:

[0051] Simple query: query with a single value as the query condition, and the query condition is account address, transaction ID, block height, or a specific key value set when storing data on the chain;

[0052] Complex query: Combine multiple query conditions or query according to a specific range. For numeric results, you can also query a certain range of result sets by value range, such as greater than, less than, or interval.

[0053] B. According to the different query objects, it is divided into:

[0054] Account balance query: query the data of a specific account balance; the blockchain system account model includes UTXO (Unspent Transaction Output) model and state model. Based on the difference in account models, the query method is different; for the UTXO account model, according to all the associated transactions of the account, the income and expenditure of each transaction are traced back one by one to calculate the account balance; for the account model, the current state of the account is directly obtained through query to obtain the current balance;

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

[0056] Block information query: Get detailed information of a specific block through the unique identifier of the block such as block hash or block height, including block generation time, previous blockchain hash, transaction list, etc.;

[0057] Transaction information query: Get detailed information of a specific blockchain through the unique identifier of the transaction such as the transaction hash, including the block where the transaction is located, the transaction initiator account and destination account, transaction content, etc.

[0058] Transaction history query: Based on a specific account address or stored evidence data, obtain all transaction records related to the address or data. Through these records, all transaction records of the account or all flow records of the data can be traced back, which is the core operation of the traceability application;

[0059] System configuration query: Get the configuration information of the blockchain system, including consensus type, block 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.

[0060] 4) Configuration transactions: transactions that directly modify the blockchain network configuration by sending transactions with configuration modification parameters to the blockchain system. They are applicable to blockchain systems that store blockchain network configuration parameters in blocks. Configuration transactions are usually part of operation and maintenance and are not the subject of performance testing.

[0061] S2. Generate user accounts: Before starting the blockchain system performance test, ensure that there are a certain number of accounts in the system. Accounts are the main body of blockchain system transaction execution, and 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, the number of users of different scales is 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;

[0062] S3. Preset account data: According to different transaction types, pre-set data sufficient to support the smooth execution of transactions for the account, which is used for transaction processing during performance testing;

[0063] In this embodiment, account data of different transaction types are preset as follows:

[0064] Transfer transactions: preset a balance as large as possible for the account to ensure that the transaction will not fail due to insufficient account balance during the transaction, which will affect the results of the performance test;

[0065] Evidence storage transactions: according to 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, and the data is set as a random string. In this embodiment, for applications that only store hashes on the chain, the data preset in the account should be at least a 64-bit string. For scenarios where more content needs to be stored on the chain, a 200-byte or 2048-byte random string can be set.

[0066] Query transactions: After a large number of transfer transactions or evidence storage transactions, the system will be tested after accumulating a large amount of transaction data;

[0067] Configuration transactions: When performance testing of configuration transactions is required, you can test configuration parameters that support dynamic modification, such as consensus participating nodes, consensus algorithm switching, block 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 to simulate the 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 in the following ways:

[0070] Transfer transactions: The accounts for transfer out and transfer in are randomly selected from the preset accounts, and the transfer amount is also randomly set; in this embodiment, an account is randomly selected from the preset accounts as the transfer out account, and then an account is randomly selected as the transfer in account, and the transfer in and transfer out accounts can be the same, and the transfer amount is a positive number ≥ 0, and can be a decimal; during the transfer process, it is necessary to ensure that the transfer in and transfer out amounts of each transaction are strictly consistent, and the sum of the transfer in and transfer out account balances after the transfer cannot be different from that before the transfer;

[0071] Evidence transactions: The two accounts for sending and receiving data are randomly selected from the preset accounts, and the content of the evidence data cannot change before and after the transfer;

[0072] Query transactions: For different types of query transactions, a random query should be performed on a certain condition, 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 transactions: Considering the stability of system operation, it is not recommended to conduct tests that randomly modify configurations in large quantities;

[0074] S5. Create a transaction body: simulate the actual transaction execution process (i.e., users complete the construction, signing and packaging of transactions on their respective clients, and then send transaction requests to blockchain nodes respectively), 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;

[0075] In this embodiment, the process of creating a transaction body: according to the preset transaction account and transaction logic, through the client of the tested blockchain system, a transaction proposal containing transaction parameters is constructed, 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 file: Convert the constructed transaction body into a specific format such as JSON or XML, save it into a file, and form a performance test data set for subsequent performance testing processes.

[0077] The above-mentioned embodiments have been used in the special test of "Trusted Blockchain Performance" of China Academy of Information and Communications Technology, and have completed performance tests of more than 40 blockchain products. Currently, they have been verified in blockchain systems such as Changan Chain, FISCO BCOS, Super Chain, and Hyperledger, and have successfully passed the "Trusted Blockchain Performance" test of China Academy of Information and Communications Technology.

[0078] The embodiments of the present invention are given for the purpose of illustration and description, and are not intended to be exhaustive or to limit the invention to the disclosed forms. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiments are selected and described in order to better illustrate the principles and practical applications of the present invention and to enable those of ordinary skill in the art to understand the present invention and thereby design various embodiments with various modifications suitable for specific uses.

Claims

1. A general method for constructing a blockchain system performance test data set, characterized in that: The following steps are involved: S1. Determine the transaction type: Design different types of transactions for blockchain system performance testing for different blockchain application scenarios to fully verify the performance ceiling of the blockchain system; S2. Generate user accounts: Before starting the blockchain system performance test, 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. Preset account data: According to different transaction types, pre-set data sufficient to support the smooth execution of transactions for the account, which is used 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 to simulate the real environment where user behavior is difficult to predict and user transaction conditions are complex; S5. Create a transaction body: simulate the actual transaction execution process, 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 in a file to form a performance test data set.

2. A general blockchain system performance test data set construction method according to claim 1, characterized in that: In step S1, the transaction types of the blockchain system are divided into four categories: transfer transactions, evidence storage transactions, query transactions, and configuration transactions, as follows: Transfer transactions: transactions that transfer account balances from one account to another. The result of the transaction is that the balance of the outgoing account increases and the balance of the incoming account decreases. Evidence transactions: transactions that store a specific piece of content in an account, and the stored content can be queried through the account. Evidence transactions determine the binding relationship between the stored content and the account. Application scenarios include traceability, judicial, and electronic bills. Query transactions: transactions that obtain content stored in the blockchain system through specific conditions; Configuration transactions: Transactions that directly modify the blockchain network configuration by sending transactions with configuration modification parameters to the blockchain system. They are suitable for blockchain systems that store blockchain network configuration parameters in blocks.

3. A general blockchain system performance test data set construction method according to claim 2, characterized in that: The query transactions are divided into two types: simple query and complex query according to different query conditions; The simple query uses a single value as the query condition, and the query condition is the 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 querying according to a specific range.

4. A general blockchain system performance test data set construction method according to claim 2, characterized in that: The query transactions are divided into six types according to the query objects: account balance query, account evidence query, block information query, transaction information query, transaction history query, and system configuration query: Account balance query: query the data of a specific account balance; the account model of the blockchain system includes two models: UTXO model and state model. Based on the difference in account models, the query method is different; for the UTXO account model, according to all the associated transactions of the account, the income and expenditure of each transaction are traced back one by one to calculate the balance of the account; for the account model, the current state of the account is directly obtained through query to obtain the current balance; Account evidence query: query the data stored in a specific account or account address; due to differences in the architectural design of the blockchain system, the length of data stored in the account address varies; Block information query: Get detailed information of a specific block through the unique identifier of the block hash or block height; Transaction information query: Get detailed information of a specific blockchain through the unique identifier of the transaction hash transaction; Transaction history query: Based on a specific account address or stored evidence data, obtain all transaction records related to the address or data. Through these records, all transaction records of the account or all circulation records of the data can be traced back; System configuration query: obtain the configuration information of the blockchain system, including consensus type, block rules, and encryption method; and system configuration query is only applicable to blockchain systems that record configuration information in blocks.

5. A general blockchain system performance test data set construction method according to claim 1, characterized in that: In step S2, different scales of user amounts are set in a gradient manner to simulate different user scales, and the gradient is designed according to scales of thousands, tens of thousands, hundreds of thousands, and millions.

6. A general blockchain system performance test data set construction method according to claim 1, characterized in that: In step S3, account data of different transaction types are preset as follows: Transfer transactions: Preset a large balance for the account to ensure that the transaction will not fail due to insufficient account balance; Evidence storage transactions: store a certain amount of data in the account according to the actual scenario. 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 transactions: After a large number of transfer transactions or evidence storage transactions, the system will be tested after accumulating a large amount of transaction data; Configuration transactions: Test configuration parameters that support dynamic modification, such as consensus participating nodes, consensus algorithm switching, block conditions, and cryptographic algorithm switching.

7. A general blockchain system performance test data set construction method according to claim 1, characterized in that: In step S4, the randomness of different transaction types is specifically achieved in the following manner: Transfer transactions: The accounts for transfer out and transfer in are randomly selected from the preset accounts, and the transfer amount is also randomly set; during the transfer process, the transfer in and transfer out amounts of each transaction must be strictly consistent, and the sum of the balances of the transfer in and transfer out accounts after the transfer cannot be different from that before the transfer; Evidence transactions: The two accounts for sending and receiving data are randomly selected from the preset accounts, and the content of the evidence data cannot change before and after the transfer; Query transactions: For different types of query transactions, a random query should be performed on a certain condition, that is, the query parameters are random. For complex queries with combined conditions, each query condition is random. Configuration transactions: Considering the stability of system operation, it is not recommended to conduct tests that involve a large number of random configuration changes.

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

9. A general blockchain system performance test data set construction method according to claim 1, characterized in that: In step S5, the process of creating a transaction body is as follows: according to the preset transaction account and transaction logic, a transaction proposal containing transaction parameters is constructed through the client of the tested blockchain system, and the transaction signature is completed. The transaction body can be directly sent to the blockchain system and can be successfully executed.

Images