Fuzzy test and symbolic execution-based Solana chain program transaction sequence dependence defect detection method
By combining fuzz testing and symbolic execution, the system automatically detects transaction order dependency defects in Solana on-chain programs, solving the problem of unpredictable order in Solana on-chain programs under high concurrency environments and achieving efficient and automated defect detection.
Patent Information
- Application Number
- CN202511026916.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-24
- Publication Date
- 2025-11-14
AI Technical Summary
Solana on-chain programs cannot predict the execution order of transactions in high-concurrency environments, which may lead to malicious attacks, and existing technologies are unable to effectively detect transaction order dependency defects.
The method employs fuzz testing and symbolic execution to generate initial states and seed transactions, perform random combinations and mutations, simulate transaction execution, detect read-write conflicts and state consistency, and output a defect report.
Without requiring program source code or test cases, it automatically detects transaction order dependency defects in Solana blockchain programs, improving detection efficiency and accuracy.
Smart Images
Figure CN120950386A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of program analysis, specifically relating to a method for detecting transaction sequence dependency defects in Solana chain programs based on fuzz testing and symbolic execution. Background Technology
[0002] With the promotion of blockchain technology and the gradual maturation of Web3 technology, blockchain technologies, represented by Solana, have been widely applied in many fields such as finance, healthcare, copyright protection, and supply chain management. In terms of concurrency, Solana utilizes its Sealevel concurrent runtime to fully leverage hardware resources and support the simultaneous processing of large numbers of transactions. This design allows Solana to maintain high efficiency even under heavy loads, making it suitable for applications requiring high-frequency transactions.
[0003] Solana on-chain programs are automated programs that run on the Solana blockchain and can automatically execute specific operations when preset conditions are met. They are written in code, deployed on the blockchain, and are decentralized, transparent, and immutable. The core idea of Solana on-chain programs is to eliminate intermediaries and directly implement agreements or transactions between parties through code.
[0004] However, a direct consequence of Solana's blockchain-based nature is that it can run on any node on the decentralized network, with a large number of transactions processed simultaneously, making the order and timing of transaction execution unpredictable. More importantly, not all network nodes are absolutely trustworthy; certain nodes can legally postpone the execution of specific transactions for their own benefit, without violating the cluster network consensus rules. This means that Solana's on-chain applications are also vulnerable to threats, such as transaction order dependency defects. Transactions in Solana's on-chain applications with such defects may be subject to manipulation by malicious attackers, leading to unexpected fund flows or program state data. Summary of the Invention
[0005] The purpose of this invention is to provide a method for detecting transaction sequence dependency defects in Solana on-chain programs based on fuzz testing and symbolic execution.
[0006] The technical solution to achieve the purpose of this invention is as follows: a method for detecting transaction sequence dependency defects in Solana on-chain programs based on fuzz testing and symbolic execution, taking the Solana on-chain program ELF executable file as input and a defect detection report as output, including the following steps:
[0007] Step 1: Use the Solana BPF program loader to verify that the tested Solana on-chain program has a valid program structure; then generate the initial state of the blockchain simulation state and the initial seed transaction of the program simulation transaction, and insert them into the state database and transaction database respectively.
[0008] Step 2: Randomly combine and mutate the states in the state database and the transactions in the transaction database to generate new transactions, but do not put them into the transaction database for the time being. Based on the selected states, simulate the execution of the combined and mutated transactions in a customized Solana virtual machine and collect execution process information.
[0009] Step 3: Collect the transaction execution results and make a judgment based on the process information in Step 2. If a new program area has been explored or is more conducive to exploring, then put the transaction into the transaction database.
[0010] Step 4: Check whether the execution can create a new state and whether there is a read / write conflict between the transaction and the previous transaction in the transaction chain. If so, try to swap the transaction and the previous transaction in the transaction chain and check whether the same state can be generated before and after changing the order. When it is found that the generated states are different, record that the program on the tested Solana chain has a transaction order dependency defect and save the transaction chain that reproduces the defect. At the same time, put the new state into the state database.
[0011] Step 5: Check if a new program region has not been explored for a long time; if so, use symbolic execution technology to invert the transaction execution in the transaction library to generate a new transaction, evaluate it and put it into the transaction library;
[0012] Step 6: Repeat steps 2 through 5 until the test is finished, and output a detection report of the defects found.
[0013] An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method described above.
[0014] A computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the steps of the above-described method.
[0015] A computer program product includes a computer program that, when executed by a processor, implements the steps of the above-described method.
[0016] Compared with the prior art, the significant advantages of this invention are: (1) It does not require providing program source code, only ELF executable file, and has good versatility. (2) It does not require a test code suite for the program under test, nor does it require manually inputting test cases, but is automatically generated and iterated. Attached Figure Description
[0017] Figure 1 This is a flowchart of a Solana on-chain program transaction sequence dependency defect detection method based on fuzzing and symbolic execution.
[0018] Figure 2 This is an SBPF assembly example corresponding to the main function of the input Solana chain program.
[0019] Figure 3 This is an example of a generated blockchain mock state.
[0020] Figure 4 This is a generated example of a program simulating a transaction.
[0021] Figure 5 This is an example of execution information collected during transaction simulation.
[0022] Figure 6 This is an example of transaction sequence dependency defect analysis.
[0023] Figure 7 This is an example of an output transaction order dependency defect detection report. Detailed Implementation
[0024] This invention proposes a method for detecting transaction order dependency defects in Solana on-chain programs based on fuzzing and symbolic execution. The method takes the ELF executable file of a Solana on-chain program as input and outputs a report of detected transaction order dependency defects. A Solana on-chain program refers to an executable program in the Solana blockchain, based on the Solana Runtime and SBPF instruction set, used to process blockchain transactions. When the Solana blockchain network receives a transaction, the validator on the Solana network node loads and executes the specified Solana on-chain program in the Solana virtual machine. A type of defect exists in Solana on-chain programs called transaction order dependency defects, which can cause the same transaction sequence to produce different execution results under different execution orders, thus making execution susceptible to control by malicious attackers. To detect transaction order dependency defects in Solana on-chain programs, this invention, based on the ideas of fuzzing and symbolic execution, tests and analyzes the input Solana on-chain program, generates an initial blockchain simulation state and seed transaction from the program executable file, and then performs cyclic testing. The iterative testing process comprises two parts: fuzzing and symbolic execution. Initially, fuzzing is performed. When fuzzing fails to explore the program state further, symbolic execution is used to solve the transaction database and generate new transactions that can further explore the program state. Fuzzing then continues. The fuzzing process mainly consists of three parts: extracting data from the state and transaction databases according to certain rules, executing transactions in a modified and customized Solana virtual machine, and adding the mutated transaction to the transaction database when the exploration is deemed valuable. Whenever a new blockchain state is explored, it checks whether the executed transaction has read / write conflicts with the previous transaction. It also detects transaction order dependency defects by reordering the two transactions and checking if the results are the same. When the test ends, a detailed report of all defects found in the process is output. The method proposed in this invention has the advantages of effectiveness and efficiency, and can effectively discover transaction order dependency defects in Solana on-chain programs.
[0025] like Figure 1 As shown, the method specifically includes the following steps:
[0026] Step 1: Use the Solana BPF program loader to verify that the tested Solana on-chain program has a valid program structure. Then, generate the initial state of the blockchain simulation state and the initial seed transaction of the program simulation transaction, and insert them into the state database and transaction database respectively. The specific steps are as follows:
[0027] Step 1-1: Use the Solana BPF program loader to verify whether the program structure of the program on the Solana chain is valid. If it is, continue; otherwise, report an error and end. Figure 2This is an assembly example corresponding to the input ELF file;
[0028] Steps 1-2: Create the initial state of the blockchain simulation state.
[0029] (1) Create a wallet account and mark the account owner as SystemProgram;
[0030] (2) Create a Solana on-chain program account and mark the account owner as BPF Loader Program;
[0031] (3) Create a system variable account and mark the account owner as Sysvar;
[0032] Then insert the initial state into the state library. Figure 3 The generated blockchain simulation state is displayed.
[0033] Steps 1-3: Create initial seed transactions for the program to simulate transactions. There are multiple initial seed transactions, the specific number of which is a predefined constant. Each initial seed transaction is generated according to the following steps:
[0034] (1) Generate an array of input accounts used in the transaction. The accounts are randomly selected from the initial state of the blockchain simulation state created in step 1-2, and the number ranges from 0 to 38 (the theoretical maximum number of accounts in a single transaction).
[0035] (2) Generate the instruction data used in the transaction. This data is randomly generated by the fuzz tester and is a byte array with a length ranging from 0 to 1232 bytes (the theoretical maximum length of instruction data in a single transaction).
[0036] Then insert the transaction into the transaction database. Figure 4 The generated transaction instance is shown.
[0037] Step 2 involves randomly combining and mutating the states in the state database and the transactions in the transaction database to generate new transactions, which are not yet added to the transaction database. Based on the selected states, the combined and mutated transactions are simulated and executed in a customized Solana virtual machine, and execution process information is collected. The specific steps are as follows:
[0038] Step 2-1: Select transaction t from the transaction database in sequence, calculate the cumulative number of branches explored but not fully explored during execution, and calculate the number of combined mutations by multiplying the cumulative number of branches by the mutation factor. The mutation factor is a predefined constant.
[0039] Step 2-2: Based on the number of mutations calculated in Step 2-1, perform combined mutations multiple times. Each mutation changes the state upon which the transaction t is based with a certain probability. The new state s_mut is randomly selected from the state database to form a new combination.<t,s_mut> .
[0040] Step 2-3: If the state on which the transaction is based was not changed in step 2-2, then the transaction itself is modified, including the account metadata array used when the transaction is executed and the instruction data used when the transaction is executed.
[0041] Specifically, the account metadata used during transaction execution is a triple.<PUBKEY,S,W> Here, PUBKEY represents the public key of the account to be used in the transaction, which is also the blockchain address of the account. S indicates whether the account needs to sign the transaction, and W indicates whether the account's content can be written in the transaction. The mutation process randomly selects one of the triples for mutation. If PUBKEY is selected, a new public key is randomly selected from the state on which the transaction is based. If S or W is selected, the boolean value is inverted.
[0042] Steps 2-4: Simulate the execution of the combined mutated transactions in a customized Solana virtual machine. Figure 5 It displays the information collected during execution. The customized content includes two parts: performance optimization and execution tracing. Specifically,
[0043] The purpose of performance optimization is to improve the efficiency of transaction execution for faster testing, specifically including:
[0044] (1) Remove the account signature verification mechanism during transaction execution because the accounts were created in step 1 rather than from outside during the test, so there is no need for extra verification.
[0045] (2) Remove the just-in-time compilation mechanism in the SBPF virtual machine because the interpreter mode is used in the test and compilation is not required;
[0046] (3) Reuse the program cache because the program under test is mainly executed in the test, which does not need to be loaded repeatedly.
[0047] The purpose of execution tracking is to evaluate the effectiveness of this execution and provide feedback for subsequent testing decisions, so as to better conduct testing. Specifically, it includes:
[0048] (1) Track whether any new instructions that have never been executed before were executed during this execution;
[0049] (2) Track whether the conditional distance of the conditional jump instruction executed in this execution has a smaller distance;
[0050] (3) Track the account data read in this execution, specifically the address of the account and the offset of the read account data in the account.
[0051] (4) Track the account data written in this execution, specifically the account address, the offset of the written account data in the account, and the written data.
[0052] Step 3: Based on the process information from Step 2, determine if a new program region has been explored or if exploring a new program region is more advantageous, then add the transaction to the transaction database. "More advantageous for exploring a new program region" includes executing a new instruction that has never been executed before or having a smaller distance; either of these conditions is considered more advantageous, as detailed below:
[0053] Step 3-1: Check whether the current transaction execution has executed any instructions that have never been executed before. If so, add the transaction to the transaction database.
[0054] Step 3-2: Check if the absolute value of the distance to the condition jump instruction in this transaction is smaller than before. If so, use this transaction to replace the large-distance transaction in the transaction database.
[0055] In this step, for each conditional jump instruction, the absolute value of the smallest distance encountered from the beginning to the present is recorded and maintained. This value is then compared with the recorded minimum value.
[0056] For the same program path, this step only retains the transaction with the smallest distance in the transaction database. Therefore, there is at most one transaction with the same path in the transaction database. Since the new one has been determined to be "smaller than before", the one with the same path that has already been saved is the large-distance transaction.
[0057] Step 3-3: Check whether the transaction execution was successful and whether a transaction order dependency defect was found. If so, add the transaction to the transaction database.
[0058] Step 4: Check if this execution can create a new state, and whether there is a read / write conflict between this transaction and the previous transaction in the transaction chain. If so, try swapping this transaction and the previous transaction in the transaction chain, and check if the same state can be generated before and after changing the order. If different states are found, record that the tested Solana chain program has a transaction order dependency defect, and save the transaction chain that reproduces the defect. At the same time, add the new state to the state database. The specific steps are as follows:
[0059] Step 4-1: Check if the result of this transaction execution contains errors. If it does not contain errors, the execution is successful. Use the execution result to construct a new state s.
[0060] Step 4-2: Take this transaction as tx1, and get the previous transaction in its transaction chain as tx2.
[0061] Step 4-3: Rearrange the order of the two transactions, that is, change ...->tx1->tx2 to ...->tx2->tx1, and re-execute to get the rearranged state s'.
[0062] Step 4-4: Check whether s in step 4-1 and s' in step 4-3 are the same. If they are different, record that the program on the tested Solana chain has a transaction order dependency defect and save the complete reproducible transaction chain of the defect. Figure 6 This analysis process is demonstrated.
[0063] Step 5: Check if no new program region has been explored for an extended period. If so, use symbolic execution techniques to solve the transaction execution process in the transaction database, generate a new transaction, evaluate it, and then add it to the transaction database. The extended period refers to a set time frame. The specific steps are as follows:
[0064] Step 5-1: Consult the transaction database and its marker data to obtain the list of transactions that have not yet been symbolically executed, tx_uneval.
[0065] Step 5-2: Enable the symbolic execution function of the Solana virtual machine and re-execute the transactions in the transaction list tx_uneval obtained in Step 5-1 one by one. During execution, the instruction data is symbolized, and symbolic constraints are tracked during transaction execution. Whenever a conditional jump instruction is encountered, its satisfied conditional constraints are logically inverted, and the z3 solver is called to solve it, generating a new set of instruction data for evaluation.
[0066] Step 5-3: Collect all instruction data generated in Step 5-2, and combine it with the original transaction in Step 5-1 to obtain a new transaction.
[0067] Step 5-4: Disable the symbolic execution function of the Solana virtual machine. Evaluate each new transaction obtained in Step 5-3 to see if it can explore or is more likely to explore a new state. If so, add it to the transaction library. "More likely to explore a new state" includes executing a new instruction that has never been executed before or having a smaller distance; either condition is considered more advantageous.
[0068] Step 6: Repeat steps 2 through 5 until the test time is up, and output a report of the defects found. The specific steps are as follows:
[0069] Step 6-1: Check whether the time elapsed since the start of the program is greater than or equal to the predetermined test time, which is a predefined value.
[0070] Step 6-2: If the condition is met, terminate the entire testing process and output a report of the transaction sequence dependency defect detected in step 4.
[0071] Figure 7 The output defect report is displayed.
[0072] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.
Claims
1. A method for detecting transaction sequence dependency defects in Solana on-chain programs based on fuzz testing and symbolic execution, characterized in that, Includes the following steps: Step 1: Use the SolanaBPF program loader to verify that the tested Solana on-chain program has a valid program structure; then generate the initial state of the blockchain simulation state and the initial seed transaction of the program simulation transaction, and insert them into the state database and transaction database respectively. Step 2: Randomly combine and mutate the states in the state database and the transactions in the transaction database to generate new transactions. These new transactions are not added to the transaction database yet. Based on the selected states, simulate the execution of the combined and mutated transactions in a customized Solana virtual machine and collect execution process information. Step 3: Collect the transaction execution results and make a judgment based on the process information in Step 2. If a new program area has been explored or is more conducive to exploring a new program area, then put the transaction into the transaction database. Step 4: Check whether the execution can create a new state, and check whether there is a read / write conflict between the transaction and the previous transaction in the transaction chain, and check whether the same state can be generated before and after the order is swapped. If they are different, report the transaction order dependency defect; at the same time, put the new state into the state database. Step 5: Check if no new program area has been explored within the set time; If so, symbolic execution techniques are used to solve the transaction execution process in the transaction database, and a new transaction is generated, evaluated, and then placed into the transaction database. Step 6: Repeat steps 2 through 5 until the test time is reached, and output a report of the discovered transaction sequence dependency defects.
2. The Solana on-chain program transaction sequence dependency defect detection method based on fuzz testing and symbolic execution according to claim 1, characterized in that, Step 1: Use the SolanaBPF program loader to verify that the tested Solana on-chain program has a valid program structure; then generate the initial state of the blockchain simulation state and the initial seed transaction of the program simulation transaction, and insert them into the state database and transaction database respectively; the specific steps are as follows: Step 1-1: Use the Solana BPF program loader to verify whether the program structure of the program on the Solana chain is valid. If it is, continue; otherwise, report an error and end. Steps 1-2: Create the initial state of the blockchain simulation state and insert the initial state into the state library; (1) Create a wallet account and mark the account owner as SystemProgram; (2) Create a Solana on-chain program account and mark the account owner as BPF Loader Program; (3) Create a system variable account and mark the account owner as Sysvar; Steps 1-3: Create initial seed transactions for the program to simulate transactions. There are multiple initial seed transactions, and each initial seed transaction is generated according to the following steps: (1) Generate an array of input accounts used for transactions. The accounts are randomly selected from the initial state of the blockchain simulation state created in steps 1-2, with a number ranging from 0 to 38. (2) Generate instruction data used by the transaction. This data is randomly generated by the fuzz tester and is a byte array with a length ranging from 0 to 1232 bytes. Then insert the transaction into the transaction database.
3. The Solana on-chain program transaction sequence dependency defect detection method based on fuzz testing and symbolic execution according to claim 1, characterized in that, Step 2: Randomly combine and mutate the states in the state database and the transactions in the transaction database to generate new transactions, but do not put them into the transaction database yet. Based on the selected states, simulate the execution of the combined and mutated transactions in a customized Solana virtual machine and collect execution process information. The specific steps are as follows: Step 2-1: Select transaction t from the transaction database in sequence, calculate the cumulative number of branches explored but not fully explored during execution, and calculate the number of combined mutations by multiplying the cumulative number of branches by the mutation factor. The mutation factor is a predefined constant. Step 2-2: Based on the number of mutations calculated in Step 2-1, perform combined mutations multiple times. Each mutation changes the state upon which the transaction t is based with a certain probability. The new state s_mut is randomly selected from the state database to form a new combination.<t,s_mut> ; Step 2-3: If the state on which the transaction is based was not changed in step 2-2, then the transaction itself is modified, including the account metadata array used when the transaction is executed and the instruction data used when the transaction is executed. Specifically, the account metadata used during transaction execution is a triple.<PUBKEY,S,W> PUBKEY represents the public key of the account to be used in the transaction, which is also the blockchain address of the account to be used in the transaction. S represents whether the account needs to sign the transaction, and W represents whether the content of the account can be written in the transaction. The mutation process randomly selects one of the triples for mutation. If PUBKEY is selected, a new public key is randomly selected from the state on which the transaction is based. If S or W is selected, the boolean value is inverted. Steps 2-4 involve simulating the execution of the combined mutated transactions in a customized Solana virtual machine. The customization includes two parts: performance optimization and execution tracing. Performance optimization specifically includes: (1) Remove the verification mechanism for account signatures during transaction execution; (2) Remove the just-in-time compilation mechanism from the SBPF virtual machine; (3) Reuse program cache; Execution tracing specifically includes: (1) Track whether any new instructions that have never been executed before were executed during this execution; (2) Track whether the conditional distance of the conditional jump instruction executed in this execution has a smaller distance; (3) Track the account data read in this execution, specifically the address of the account and the offset of the read account data in the account; (4) Track the account data written in this execution, specifically the account address, the offset of the written account data in the account, and the written data.
4. The Solana on-chain program transaction sequence dependency defect detection method based on fuzz testing and symbolic execution according to claim 1, characterized in that, Step 3: Based on the process information from Step 2, determine if a new program region has been discovered or if there is a greater opportunity to explore a new program region. Then, add the transaction to the transaction database. The specific steps are as follows: Step 3-1: Check whether the current transaction execution has executed any instructions that have never been executed before. If so, add the transaction to the transaction database. Step 3-2: Check if the absolute value of the distance to the condition jump instruction in this transaction is smaller than before. If so, use this transaction to replace the large-distance transaction in the transaction database. Step 3-3: Check whether the transaction was successfully executed and whether a defect was found. If so, add the transaction to the transaction database.
5. The Solana on-chain program transaction sequence dependency defect detection method based on fuzz testing and symbolic execution according to claim 1, characterized in that, Step 4, which involves detecting whether there are read / write conflicts between the transaction and the previous transaction in the transaction chain and checking whether the same state can be generated before and after changing the order, reports a transaction order dependency defect if they are different. This includes the following steps: Step 4-1: Check if the result of this transaction execution contains errors. If it does not contain errors, the execution is successful. Use the execution result to construct a new state s. Step 4-2: Take this transaction as tx1, and get the previous transaction in its transaction chain as tx2; Step 4-3: Rearrange the order of the two transactions, that is, change ...->tx1->tx2 to ...->tx2->tx1, and re-execute to get the rearranged state s'; Step 4-4: Check whether s in step 4-1 and s' in step 4-3 are the same. If they are different, record that the program on the tested Solana chain has a transaction order dependency defect and save the complete reproducible transaction chain of the defect.
6. The Solana on-chain program transaction sequence dependency defect detection method based on fuzz testing and symbolic execution according to claim 1, characterized in that, Step 5, which describes using symbolic execution techniques to solve the transaction execution process in the transaction database when no new program region is explored for an extended period, generates a new transaction, evaluates it, and then adds it to the transaction database, includes the following steps: Step 5-1: Consult the transaction database and its marker data to obtain the list of transactions that have not yet been symbolically executed, tx_uneval; Step 5-2: Enable the symbolic execution function of the Solana virtual machine and re-execute the transactions in the transaction list tx_uneval obtained in step 5-1 one by one; During execution, the instruction data is symbolized, and symbolic constraints are tracked during transaction execution. Whenever a conditional jump instruction is encountered, its satisfied conditional constraints are logically inverted, and the z3 solver is called to solve it, generating a new set of instruction data for evaluation. Step 5-3: Collect all instruction data generated in Step 5-2, and combine it with the original transaction data in Step 5-1 to obtain a new transaction; Step 5-4: Disable the symbolic execution function of the Solana virtual machine, and evaluate each new transaction obtained in Step 5-3 to see if it can explore or is more likely to explore the new state. If so, add it to the transaction library.
7. The Solana on-chain program transaction sequence dependency defect detection method based on fuzz testing and symbolic execution according to claim 1, characterized in that, Step 6: Repeat steps 2 through 5 until the test time is reached, and output a report of the discovered defects. The specific steps are as follows: Step 6-1: Check if the time elapsed since the start of the program is greater than or equal to the predetermined test time, which is a predefined value. Step 6-2: If the condition is met, terminate the entire testing process and output a report of the transaction sequence dependency defect detected in step 4.
8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method as described in any one of claims 1-7.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the method as described in any one of claims 1-7.
10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the method described in any one of claims 1-7.