Block chain unstable factor detection method and related equipment

Abstract

The invention discloses a block chain unstable factor detection method and related equipment. The method comprises the following steps: constructing a state model; the state model comprises a state set, an event input set, a state transition function and an output function, designing a basic input mode according to the state model, introducing a state transition coverage rate in a block chain operation environment, and constructing a plurality of different transaction sequences based on the basic input mode and a fuzzy test; executing a fuzzy test according to all transaction sequences, and recording actual state transition and actual output results; and comparing the actual state transition with the expected state transition of the state model, comparing the actual output result with the expected output result of the state model, and detecting an abnormal behavior to determine the block chain instability factor. According to the embodiment of the invention, unstable factors caused by competition conditions caused by cross-transaction concurrency can be captured, and the practical applicability of the test is improved. The method can be widely applied to the technical field of software testing.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software testing, in particular to a blockchain unstable factor detection method and related equipment. BACKGROUND

[0002] Solana adopts PoH+PoS consensus and Sealevel parallel execution mechanism to achieve extremely high throughput performance of the blockchain system. Its design requires nodes to process transactions with extremely high parallelism, but parallel processing also brings complex state consistency and resource competition problems. The early version of Solana lacks perfect congestion control (such as priority rate, local fee market), and has been congested and failed in stability due to transaction flooding several times. For example, in September 2021, the Solana network suffered a malicious robot attack during the initial liquidity (IDO) of the Grape protocol, with a network load of 400,000 TPS, a Forwarder queue explosion, and a 17-hour downtime of the validator node due to memory exhaustion; in May 2022, NFT casting robots generated a transaction peak of about 4 million TPS on the Metaplex application, causing validator consensus failure and network downtime for about 7 hours. As of 2022, Solana has had more than seven similar interruption events, fully demonstrating the challenges of its stability in the context of ultra-high concurrency.

[0003] Existing smart contract testing and security verification technologies mainly target single-threaded environments or focus on static analysis and formal verification, and are difficult to adapt to the high concurrency and cross-contract interaction scenarios of Solana. For example, research shows that due to the persistent state of blockchain transactions, traditional fuzz testing faces input explosion and state space explosion problems. Solana smart contracts are mostly developed in Rust / eBPF, and the source code is usually not available, so tools such as FuzzDelSol proposed by Sven Smolka et al. use binary coverage-guided methods to explore vulnerabilities. Although there have been works on Solana vulnerability detection, there is still a lack of effective means for transaction execution anomalies and system instability. Existing testing methods often ignore state competition and anomalies caused by concurrent execution, and cannot fully discover potential faults in a black-box environment. SUMMARY

[0004] The main purpose of the embodiments of the present application is to propose a blockchain unstable factor detection method and related equipment, aiming to capture unstable factors caused by race conditions triggered by cross-transaction concurrency, and improve the practical applicability of testing.

[0005] To achieve the above purpose, one aspect of the embodiments of the present application proposes a blockchain unstable factor detection method, which comprises the following steps: constructing a state model; the state model comprises a state set, an event input set, a state transition function and an output function, the state transition function characterizes a mapping from a current state and an input event to a next state, and the output function characterizes an output result defined according to the current state and the input event; designing a basic input mode according to the state model, introducing state transition coverage in a blockchain running environment, and constructing a plurality of different transaction sequences based on the basic input mode and fuzzy testing; performing fuzzy testing according to all transaction sequences, recording actual state transitions and actual output results, comparing the actual state transitions with expected state transitions of the state model, comparing the actual output results with expected output results of the state model, detecting abnormal behaviors, and determining unstable factors of the blockchain.

[0006] In some embodiments, the state model is constructed by: identifying key state variables, determining a state set according to the key state variables, and defining an event input set; generating a state transition function and an output function according to the state set and the event input set.

[0007] In some embodiments, the basic input mode is designed according to the state transition function in the state model, fuzzy testing is performed based on the basic input mode in a blockchain running environment, new transaction sequences are continuously generated until the state transition coverage of the current fuzzy testing meets a preset threshold, and a plurality of different transaction sequences are constructed. designing a basic input mode according to a state transition function in a state model; In some embodiments, the basic input mode is designed according to the state transition function in the state model, fuzzy testing is performed based on the basic input mode in a blockchain running environment, new transaction sequences are continuously generated until the state transition coverage of the current fuzzy testing meets a preset threshold, and a plurality of different transaction sequences are constructed.

[0008] In some embodiments, the fuzzy testing based on the basic input mode continuously generates new transaction sequences until the state transition coverage of the current fuzzy testing meets a preset threshold, which includes: taking the basic input mode as a current input of fuzzy testing, mutating the current input to generate a current transaction sequence, and calculating the state transition coverage of the current fuzzy testing; If the state transition coverage of the current fuzzy testing does not reach the preset threshold, updating the current input to the current transaction sequence, and returning to mutate the current input to generate a current transaction sequence and calculate the state transition coverage of the current fuzzy testing until the state transition coverage of the current fuzzy testing meets the preset threshold.

[0009] In some embodiments, the state transition coverage of the current fuzzy testing is calculated by the following method: counting a number of state transitions covered by all transaction sequences generated by the current fuzz testing; taking a ratio of the number of state transitions covered to a total number of state transitions reachable according to the state model as a state transition coverage ratio of the current fuzz testing.

[0010] In some embodiments, the detecting the abnormal behavior according to the comparison between the actual state transition and the expected state transition of the state model, and the comparison between the actual output result and the expected output result of the state model, comprises: comparing the actual state transition with the expected state transition of the state model, and identifying a behavior inconsistent with the expected state transition of the state model as the abnormal behavior; comparing the actual output result with the expected output result of the state model, and identifying a behavior inconsistent with the expected output result of the state model as the abnormal behavior.

[0011] To achieve the above object, another aspect of the embodiments of the present application provides a device for detecting unstable factors of a blockchain, the device comprising: a construction module configured to construct a state model; the state model comprising a state set, an event input set, a state transition function and an output function, the state transition function representing a mapping from a current state and an input event to a next state, and the output function representing an output result defined according to the current state and the input event; a sequence construction module configured to design a basic input mode according to the state model, introduce a state transition coverage ratio in a blockchain running environment, and construct a plurality of different transaction sequences based on the basic input mode and the fuzz testing; an abnormality detection module configured to execute the fuzz testing according to all the transaction sequences, record an actual state transition and an actual output result, detect an abnormal behavior according to the comparison between the actual state transition and the expected state transition of the state model, and the comparison between the actual output result and the expected output result of the state model, and determine a blockchain unstable factor.

[0012] To achieve the above object, another aspect of the embodiments of the present application provides an electronic device, comprising a memory and a processor, the memory storing a computer program, and the processor implementing the above method when executing the computer program.

[0013] To achieve the above object, another aspect of the embodiments of the present application provides a computer readable storage medium storing a computer program, the computer program being executed by a processor to implement the above method.

[0014] To achieve the above object, another aspect of the embodiment of the present application provides a computer program product comprising a computer program which, when executed by a processor, implements the above method.

[0015] The embodiment of the present application at least has the following beneficial effects: the present application provides a blockchain unstable factor detection method, device, electronic equipment, storage medium and program product, which effectively discovers abnormal state transition and concurrent competition problems in the transaction sequence by constructing a finite state machine model and combining a fuzzy test strategy, detects defects that cause inconsistent on-chain states or transaction failures in a timely manner, quantitatively describes system behavior by using a state model, introduces a state transition coverage rate index to guide fuzzy testing, makes testing more systematic and efficient, can capture hidden errors missed by traditional methods when facing the execution environment specific to Solana, and forms a plug-and-play solution in combination with a chain combination mode to cope with the complexity of business requirements, thereby reducing research and development costs and simplifying application complexity. BRIEF DESCRIPTION OF DRAWINGS

[0016] Figure 1 is a flowchart of a blockchain unstable factor detection method provided by the embodiment of the present application; Figure 2 is a flowchart of another blockchain unstable factor detection provided by the embodiment of the present application; Figure 3 is a flowchart of constructing a state model provided by the embodiment of the present application; Figure 4 is a structural schematic diagram of a state model provided by the embodiment of the present application; Figure 5 is a flowchart of constructing a plurality of different transaction sequences provided by the embodiment of the present application; Figure 6 is a flowchart of fuzzy test execution provided by the embodiment of the present application; Figure 7 is a flowchart of constructing a transaction sequence provided by the embodiment of the present application; Figure 8 is a flowchart of calculating a state transition coverage rate provided by the embodiment of the present application; Figure 9 is a flowchart of identifying abnormal behavior provided by the embodiment of the present application; Figure 10 is a hardware structural schematic diagram of an electronic equipment provided by the embodiment of the present application. DETAILED DESCRIPTION

[0017] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and not intended to limit the present application. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with embodiments of the present application. They are only examples of apparatuses and methods consistent with some aspects of the embodiments of the present application as detailed in the appended claims.

[0018] It can be understood that the terms "first", "second" and the like used in the present application can be used herein to describe various concepts, but unless specifically stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of the present application, the first information can also be referred to as the second information, and similarly, the second information can also be referred to as the first information. Depending on the context, the word "if" as used herein can be interpreted as "when" or "upon" or "in response to determining".

[0019] The terms "at least one", "multiple", "each", "any" and the like used in the present application include one, two or more than two, multiple includes two or more than two, each refers to each of the corresponding multiple, and any refers to any one of the multiple.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs. The terms used herein are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.

[0021] Before the embodiments of the present application are described in detail, first, some nouns and terms involved in the embodiments of the present application are described, and the nouns and terms involved in the embodiments of the present application are applicable to the following explanations.

[0022] State modeling: the state modeling method adopted by the embodiments of the present application is finite state machine (FSM) modeling. The FSM model is a mathematical model composed of a state set, an (event) input set, a state transition function and an output function, which is used to describe the state transition logic of a system under different inputs. In FSM, the state transition function defines the mapping of the current state and the input event to the next state, and the output function defines the output result.

[0023] Fuzzing: an automated testing technique that generates random perturbations of legal inputs or boundary input sequences, executes the program multiple times, and detects abnormal behavior.

[0024] In related technologies, testing methods often ignore state competition and exceptions caused by concurrent execution, and cannot comprehensively discover potential faults in a black box environment.

[0025] Therefore, in the embodiments of the present application, a blockchain unstable factor detection method, device, electronic equipment, storage medium and program product are provided. The scheme effectively discovers abnormal state transitions and concurrent competition problems in the transaction sequence by constructing a finite state machine model and combining a fuzzing strategy, detects defects that cause inconsistent on-chain states or transaction failures in a timely manner, quantitatively describes system behavior using a state model, introduces a state transition coverage rate index to guide fuzzing, makes testing more systematic and efficient, can capture hidden errors missed by traditional methods when facing the execution environment specific to Solana, and forms a plug-and-play solution in combination with chain combination to cope with the complexity of business requirements, thereby reducing research and development costs and simplifying application complexity.

[0026] The blockchain unstable factor detection method provided in the embodiments of the present application relates to the field of information technology. The blockchain unstable factor detection method provided in the embodiments of the present application can be applied to a terminal, can also be applied to a server, and can be software running in a terminal or a server. In some embodiments, the terminal can be a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, a vehicle-mounted terminal, and the like, but is not limited thereto; the server end can be configured as a standalone physical server, can also be configured as a server cluster or a distributed system composed of multiple physical servers, can also be configured as a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, and big data and artificial intelligence platforms, and the server can also be a node server in a blockchain network; the software can be an application that implements the blockchain unstable factor detection method, and the like, but is not limited to the above forms.

[0027] The application is operable in a multitude of generic or specific computer system environments or configurations. Examples include personal computers, server computers, handheld or laptop devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. The application can be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and the like, that perform particular tasks or implement particular abstract data types. The application can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in local and remote computer storage media including memory storage devices.

[0028] Figure 1 is an optional flowchart of a blockchain instability factor detection method provided by an embodiment of the application, Figure 1 The method in the above embodiment can include, but is not limited to, steps S101 to S103.

[0029] Step S101, constructing a state model; the state model includes a state set, an event input set, a state transition function and an output function, the state transition function represents the mapping from the current state and the input event to the next state, and the output function represents the output result defined according to the current state and the input event; Step S102, designing a basic input mode according to the state model, introducing state transition coverage under the blockchain running environment, and constructing a plurality of different transaction sequences based on the basic input mode and fuzzy testing; Step S103, performing fuzzy testing according to all the transaction sequences, recording actual state transitions and actual output results, comparing the actual state transitions with expected state transitions of the state model, comparing the actual output results with expected output results of the state model, detecting abnormal behaviors, and determining the blockchain instability factors.

[0030] The application proposes a Solana blockchain instability factor detection method based on state modeling and fuzzy testing, aiming to systematically find potential instability abnormal behaviors in Solana smart contract transactions through FSM formal modeling, sequence construction and abnormal detection.

[0031] Reference is made to Figure 2In one specific embodiment, the FSM modeling module defines various possible states for the input set of smart contracts, generates state transition functions and corresponding results as basic items for the sequence construction module; the sequence construction module designs basic input patterns as seeds for Fuzzing based on the FSM model, constructs different transaction sequences based on Fuzzing by introducing a state transition coverage index; the anomaly detection module performs Fuzzing according to all transaction sequences, records actual state transitions and result information, detects abnormal behaviors by comparing each actual state transition with the expected transition of the FSM model and comparing each actual output result with the expected result of the FSM model.

[0032] In some embodiments, referring to Figure 3 , a state model is constructed, including: Step S201, identifying a key state variable, determining a state set according to the key state variable, and defining an event input set; Step S202, generating a state transition function and an output function according to the state set and the event input set.

[0033] In the FSM modeling module, first, the key state variable in the transaction sequence contract is identified, and it is abstracted as a state set of the state machine . An event or input set (such as contract call, transaction instruction, etc.) is defined, and a corresponding state transition function and an output function are generated. For example, in a decentralized exchange (DEX) contract, the state can be defined as various Token balances, order book states, etc., and the event can be defined as price ordering, asset exchange, clearing, etc. The state transition function indicates that after executing the event in the state , it is transferred to a new state , and the output function indicates the output result of the operation (such as whether the transaction is successful, return value, etc.). At the same time, a receiving state and an error state set are defined, which are used to mark illegal or abnormal states. The FSM modeling analyzes the contract logic and the blockchain execution rules, lists possible states and transitions, and visualizes them as a state transition graph. Referring to Figure 4 , Figure 4 is an example of a finite state machine (FSM) model graph, which is an example of a contract state transition. The circle represents the state, such as S1 / S2, and the arrow with a labeled number represents the state transition under a specific input event.

[0034] In some embodiments, referring to Figure 5According to the state model, a basic input mode is designed, and in a blockchain running environment, state transition coverage is introduced. Based on the basic input mode and fuzzy testing, a plurality of different transaction sequences are constructed, including: In step S301, a basic input mode is designed according to a state transition function in the state model. In step S302, in a blockchain running environment, fuzzy testing is performed based on the basic input mode, and new transaction sequences are continuously generated until the state transition coverage of the current fuzzy testing meets a preset threshold, so as to construct a plurality of different transaction sequences.

[0035] In the sequence construction module, the transaction interaction of the smart contract is regarded as an event input sequence, and a basic input mode is designed as a Fuzzing seed, such as a single transaction (calling a function of the contract), batch transactions (a plurality of transactions are executed in a specific order), and the like. In addition, a new transaction sequence is generated using a feedback-based mutation strategy: according to the state transition coverage of the current test, the existing input is mutated to generate diversified transaction sequences. For example: modifying the transaction order, changing the parameter value, and inserting concurrent transactions. Until the state transition coverage of the current fuzzy testing meets the preset threshold, a plurality of different transaction sequences are constructed.

[0036] In some embodiments, based on the basic input mode, fuzzy testing is performed, and new transaction sequences are continuously generated until the state transition coverage of the current fuzzy testing meets a preset threshold, including: In step S401, the basic input mode is taken as the current input of the fuzzy testing, the current input is mutated to generate a current transaction sequence, and the state transition coverage of the current fuzzy testing is calculated. In step S402, if the state transition coverage of the current fuzzy testing does not reach the preset threshold, the current input is updated to the current transaction sequence, and the current input is mutated to generate a current transaction sequence, and the state transition coverage of the current fuzzy testing is calculated, until the state transition coverage of the current fuzzy testing meets the preset threshold.

[0037] If the coverage does not reach the preset threshold, new transaction sequences are continuously generated as the input of the next time to explore more state transitions, as shown in Figure 6 The figure shows a test cycle diagram based on coverage feedback. The Fuzzer generates a new transaction sequence based on system coverage information, as the input of the next time and updates the coverage index, and stops when the threshold is reached.

[0038] In a specific embodiment, refer to Figure 7, according to the smart contract and rules thereof, an FSM model is constructed, and based on the FSM model, the FSM model comprises an input event set, a state set, a state transition function, and a transition result function; a basic input mode is designed according to the FSM model, the basic input mode is designed as a Fuzzing seed, a transaction sequence is generated, and a state transition coverage rate of current testing is calculated to determine whether the state transition coverage rate of current testing reaches a threshold; if the state transition coverage rate of current testing does not reach the preset threshold, the generated transaction sequence is taken as a Fuzzing seed to continue the next round of Fuzzing test; if the state transition coverage rate of current testing reaches the preset threshold, the Fuzzing test is ended.

[0039] In some embodiments, referring to Figure 8 , the state transition coverage rate of current Fuzzing test is calculated by the following method: Step S501, the number of state transitions covered by all transaction sequences generated by current Fuzzing test is counted; Step S502, the ratio of the number of state transitions covered to the number of all reachable state transitions is taken as the state transition coverage rate of current Fuzzing test; the number of all reachable state transitions is determined according to the state model.

[0040] The definition of state transition coverage rate COV index (calculated coverage rate) is calculated according to the following formula:

[0041] The number of state transitions covered by all transaction sequences generated by current Fuzzing test refers to the number of state transitions determined by the states corresponding to the transaction sequences according to the state transition function in the state model, and the number of all reachable state transitions refers to the number of all state transitions determined according to the state set and the state transition function in the state model.

[0042] In some embodiments, referring to Figure 9 , according to the comparison between actual state transition and expected state transition of the state model, and the comparison between actual output result and expected output result of the state model, abnormal behaviors are detected, including: Step S601, the actual state transition is compared with the expected state transition of the state model, and behaviors inconsistent between the actual state transition and the expected state transition of the state model are identified as abnormal behaviors; Step S602, the actual output result is compared with the expected output result of the state model, and behaviors inconsistent between the actual output result and the expected output result of the state model are identified as abnormal behaviors.

[0043] According to the generated all transaction sequence, the fuzzy test is performed, the actual state transition under each input is recorded, and the actual transition is compared with the expected transition of the FSM model, the inconsistent behavior is identified as abnormal behavior, and the actual output result is compared with the expected output result of the state model, the inconsistent behavior of the actual output result and the expected output result of the state model is identified as abnormal behavior; That is, the detected factors causing unstable transaction sequence. Specifically, for each transaction sequence , the system records its state sequence , wherein If the actual state transition does not conform to the FSM model definition in a certain step (for example, an undefined state transition or an error state is entered), the system marks the transaction sequence as abnormal. For the detected abnormality, record its information: abnormal transaction sequence, previous and next state, input that triggers the abnormality, difference between expected output and actual output. When the fuzzy test coverage reaches the threshold, output all abnormal information in the log, that is, all possible abnormal behaviors that may cause unstable transactions detected.

[0044] Next, taking a decentralized exchange (DEX) smart contract on the Solana platform as an example, the implementation process of the present application is described in detail.

[0045] Step 1, FSM modeling For the DEX contract, define the state set as:

[0046] Among them, Idle, order placed, matching, settlement completed and error represent five different states.

[0047] Define the input event set as:

[0048] Among them, Place order, cancel order, match order and settlement represent four different input events.

[0049] State transition function and output function are defined as follows:

[0050] Output result set is:

[0051] Among them, Respectively represent five different output results of order creation success, matching start, settlement completion, order cancellation success, illegal operation (enter error state).

[0052] Through the above FSM modeling, the legal input of the DEX contract in different states and the corresponding state transition and result are defined, and subsequent anomaly detection is carried out on this basis.

[0053] Step 2, sequence construction The embodiment of the application mainly constructs and tests the input sequence by means of the Trident tool (an open source fuzzing framework of the Solana platform).

[0054] Step 2.1, initialize the Trident test environment: in the working directory of the Anchor framework, initialize the fuzzing test environment, build the project, read the generated IDL, and create a fuzzing test template.

[0055] Step 2.2, define the test account: in the fuzz_accounts.rs file, define the account structure used for testing , containing three elements: , respectively representing the user account, order book account and Token minting account.

[0056] Step 2.3, define the fuzzing instruction: in the fuzz_instructions.rs file, define the test instruction , containing 4 different instruction structures: 、 、 . Each instruction structure contains necessary account information accounts and input data , according to the IDL generated in step 2.1, to construct the corresponding transaction data and account meta information.

[0057] Step 2.4, calculate the current test coverage according to the number of state transitions and generate the corresponding transaction sequence. The following two examples illustrate the calculation process. For example, given a preset threshold of 80%, the input set is , for the input sequence , from , there are 2 states in total, and the number of all reachable state transitions is 5, and the coverage is: , which does not reach the preset threshold, at which time the transaction sequence needs to be regenerated. For the input sequence , from , there are 4 states in total, and the number of all reachable state transitions is 5, and the coverage is , which reaches the preset threshold, at which time the input sequence does not need to be regenerated.

[0058] Step 3, anomaly detection Step 3.1, performing test: based on the Trident tool framework, according to the fuzzy test instructions and test accounts defined in steps 2.2 and 2.3, all transaction sequences generated in step 2.4 are executed, the contract behavior is monitored, and the actual state transition of each input is recorded.

[0059] Step 3.2, state comparison: compare the actual state transition with the expected state transition of the FSM, and identify the behavior inconsistent with the two as abnormal behavior; output result comparison: compare the actual output result with the expected output result of the FSM, for example, for a set , For the discovered abnormal behavior, it means that after placing an order, a settlement operation is directly performed, which violates the provision in the FSM model that matching must be performed first. When transactions are executed concurrently, this operation may occur due to concurrent competition, which is an unstable factor that causes transaction failure.

[0060] To achieve the above purpose, another aspect of the embodiment of the present application proposes a blockchain unstable factor detection device, which can implement the above method. The device comprises: A state model is constructed, which includes a state set, an event input set, a state transition function, and an output function. The state transition function represents the mapping of the current state and the input event to the next state, and the output function represents the output result defined according to the current state and the input event. A sequence construction module is used to design a basic input mode according to the state model, introduce state transition coverage in a blockchain running environment, and construct a plurality of different transaction sequences based on the basic input mode and fuzzy testing. An anomaly detection module is used to execute fuzzy testing according to all transaction sequences, record actual state transitions and actual output results, compare actual state transitions with expected state transitions of the state model, compare actual output results with expected output results of the state model, detect abnormal behavior, and determine a blockchain unstable factor.

[0061] It can be understood that the contents in the above method embodiment are applicable to the device embodiment. The device embodiment specifically implements the same functions as the above method embodiment, and achieves the same beneficial effects as the above method embodiment.

[0062] The embodiment of the present application also provides an electronic device, which comprises a memory and a processor. The memory stores a computer program, and the processor implements the above method when executing the computer program. The electronic device can be any intelligent terminal, such as a tablet computer or a vehicle-mounted computer.

[0063] It can be understood that the contents in the above method embodiments are all applicable to the present device embodiments, the present device embodiments specifically implement the functions same as those of the above method embodiments, and achieve the same beneficial effects as those of the above method embodiments.

[0064] Please refer to Figure 10 , Figure 10 The hardware structure of the electronic device of another embodiment is illustrated, and the electronic device comprises: The processor 1001 can be implemented in a general-purpose CPU (Central Processing Unit), a microprocessor, an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits, etc., and is used to execute related programs to implement the technical solutions provided by the present application; The memory 1002 can be implemented in the form of a ROM (Read Only Memory), a static storage device, a dynamic storage device, or a RAM (Random Access Memory), etc. The memory 1002 can store an operating system and other application programs, and when the technical solutions provided by the present application are implemented by software or firmware, the related program codes are stored in the memory 1002 and are called and executed by the processor 1001 to implement the above-mentioned method of the present application; The input / output interface 1003 is used to realize information input and output; The communication interface 1004 is used to realize the communication interaction between the present device and other devices, and can realize communication through a wired manner (such as USB, network cable, etc.) or a wireless manner (such as mobile network, WIFI, Bluetooth, etc.); The bus 1005 transmits information between various components (such as the processor 1001, the memory 1002, the input / output interface 1003, and the communication interface 1004) of the device. Among them, the processor 1001, the memory 1002, the input / output interface 1003, and the communication interface 1004 realize the communication connection between each other in the device through the bus 1005.

[0065] The present application also provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the above-mentioned method.

[0066] It can be understood that the contents in the above method embodiments are all applicable to the present storage medium embodiments, the present storage medium embodiments specifically implement the functions same as those of the above method embodiments, and achieve the beneficial effects same as those of the above method embodiments.

[0067] The present application also provides a computer program product comprising a computer program which, when executed by a processor, implements the above method.

[0068] It can be understood that the contents in the above method embodiments are all applicable to the present program product embodiments, the present program product embodiments specifically implement the functions same as those of the above method embodiments, and achieve the beneficial effects same as those of the above method embodiments.

[0069] The memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. In addition, the memory can include a high-speed random access memory and can also include a non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state memory device. In some embodiments, the memory can optionally include a memory disposed remotely relative to the processor, and these remote memories can be connected to the processor through a network. Examples of the above network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0070] The blockchain instability factor detection method and device, the electronic device, the storage medium and the program product provided by the present application have the following beneficial effects: (1) The FSM modeling is used for transaction sequences in the Solana blockchain to detect instability. The FSM considers the Sealevel parallelism of Solana, so that the test can handle multiple transaction interactions at the same time. Compared with traditional serial execution tests, the method can capture instability factors caused by race conditions triggered across transaction concurrency, improving the real-world applicability of the test.

[0071] (2) The state transition coverage rate index is used to guide the fuzzy test. Compared with existing technologies, the present application combines the state coverage rate index COV to guide the fuzzy test, which can systematically explore the input space and automatically generate new mutation inputs when the value is not saturated, improving the test efficiency. Compared with random blind test or fixed case test, the coverage rate guided strategy is more likely to trigger abnormalities under deep state and complex sequence, greatly enhancing the defect discovery ability and having strong applicability.

[0072] The embodiments described in the specification are for more clearly illustrating the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. Those skilled in the art can know that, with the evolution of technology and the appearance of new application scenarios, the technical solutions provided by the embodiments of the present application are also applicable to similar technical problems.

[0073] Those skilled in the art can understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and can include more or fewer steps than shown in the figures, or combine certain steps, or different steps.

[0074] The device embodiments described above are only schematic, and the units described as separate components can or can not be physically separate, i.e., can be located in one place, or can be distributed on multiple network units. Part or all of the modules can be selected according to actual needs to achieve the purpose of the embodiments of the present application.

[0075] Those skilled in the art can understand that all or some of the steps in the above disclosed method, the functional modules / units in the system and the device can be implemented as software, firmware, hardware and their appropriate combinations.

[0076] The terms "first", "second", "third", "fourth" and the like (if any) in the specification of the present application and the above-described drawings are used to distinguish similar objects, and do not necessarily have to be used to describe a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units does not have to be limited to those steps or units clearly listed, but can include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0077] It should be understood that, in the application, "at least one" refers to one or more, and "multiple" refers to two or more. "And / or" is used to describe the association relationship of the associated objects, which means that there can be three relationships, for example, "A and / or B" can represent three cases of only A, only B and A and B existing at the same time, wherein A and B can be singular or plural. The character " / " generally represents an "or" relationship between the front and rear associated objects. "At least one of the following" or the like means any combination of these items, including any combination of single or multiple items. For example, at least one of a, b or c can represent a, b, c, "a and b", "a and c", "b and c", or "a and b and c", wherein a, b and c can be single or multiple.

[0078] In several embodiments provided in the application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of the above units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed mutual ones can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0079] The units described above as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, they can be located in one place, or can be distributed on multiple network units. According to actual needs, part or all of the units can be selected to achieve the purpose of the embodiment scheme.

[0080] In addition, each functional unit in each embodiment of the application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0081] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application, essentially or in other words, the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes multiple instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various program storage media.

[0082] The preferred embodiments of the embodiments of the present application are described above with reference to the accompanying drawings, and are not limited to the scope of the embodiments of the present application. Any modifications, equivalent replacements and improvements made by those skilled in the art without departing from the scope and essence of the embodiments of the present application shall be within the scope of the embodiments of the present application.

Claims

1. A method for detecting instability factors in blockchain, characterized in that, The method comprises the following steps: constructing a state model; the state model comprises a state set, an event input set, a state transition function and an output function, the state transition function characterizing a mapping from a current state and an input event to a next state, and the output function characterizing an output result defined according to the current state and the input event; designing a basic input mode according to the state model, introducing state transition coverage in a blockchain running environment, and constructing a plurality of different transaction sequences based on the basic input mode and fuzzy testing; performing fuzzy testing according to all the transaction sequences, recording actual state transitions and actual output results, comparing the actual state transitions with expected state transitions of the state model, comparing the actual output results with expected output results of the state model, and detecting abnormal behaviors to determine unstable factors of the blockchain.

2. The method of claim 1, wherein, The state model is constructed by: identifying key state variables, determining a state set according to the key state variables, and defining an event input set; generating a state transition function and an output function according to the state set and the event input set.

3. The method of claim 1, wherein, The basic input mode is designed according to the state transition function in the state model, fuzzy testing is performed based on the basic input mode in the blockchain running environment, and a plurality of different transaction sequences are constructed by continuously generating new transaction sequences until the state transition coverage of the current fuzzy testing meets a preset threshold. The basic input mode is designed according to the state transition function in the state model, fuzzy testing is performed based on the basic input mode in the blockchain running environment, and a plurality of different transaction sequences are constructed by continuously generating new transaction sequences until the state transition coverage of the current fuzzy testing meets a preset threshold. The fuzzy testing based on the basic input mode continuously generates new transaction sequences until the state transition coverage of the current fuzzy testing meets a preset threshold, which comprises:

4. The method of claim 3, wherein, taking the basic input mode as a current input of the fuzzy testing, mutating the current input to generate a current transaction sequence, and calculating the state transition coverage of the current fuzzy testing; if the state transition coverage of the current fuzzy testing does not reach the preset threshold, updating the current input to the current transaction sequence and returning to mutate the current input to generate a current transaction sequence and calculate the state transition coverage of the current fuzzy testing until the state transition coverage of the current fuzzy testing meets the preset threshold. The state transition coverage of the current fuzzy testing is calculated by:

5. The method of claim 3, wherein, counting the number of state transitions covered by all the transaction sequences generated by the current fuzzy testing; taking the ratio of the number of covered state transitions to the number of all reachable state transitions as the state transition coverage of the current fuzzy testing; The number of all reachable state transitions is determined according to the state model. The comparison of the actual state transitions with the expected state transitions of the state model and the comparison of the actual output results with the expected output results of the state model for detecting abnormal behaviors comprise:

6. The method of claim 1, wherein, ​ comparing the actual state transition with the expected state transition of the state model, and identifying behavior that is inconsistent between the actual state transition and the expected state transition of the state model as abnormal behavior; comparing the actual output result with the expected output result of the state model, and identifying behavior that is inconsistent between the actual output result and the expected output result of the state model as abnormal behavior. 7.A blockchain instability factor detection apparatus, characterized by, The apparatus comprises: a construction module configured to construct a state model, wherein the state model comprises a state set, an event input set, a state transition function, and an output function, the state transition function representing a mapping from a current state and an input event to a next state, and the output function representing an output result defined according to the current state and the input event; a sequence construction module configured to design a basic input mode according to the state model, introduce state transition coverage in a blockchain running environment, and construct a plurality of different transaction sequences based on the basic input mode and fuzzy testing; an abnormality detection module configured to perform fuzzy testing according to all the transaction sequences, record an actual state transition and an actual output result, compare the actual state transition with the expected state transition of the state model, compare the actual output result with the expected output result of the state model, detect abnormal behavior, and determine a blockchain instability factor.

8. An electronic device, comprising: comprise: at least one processor; at least one memory for storing at least one program; when the at least one program is executed by the at least one processor, the at least one processor implements the method of any one of claims 1-6.

9. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 8. The computer program is executed by the processor to implement the method of any one of claims 1 to 6.

10. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the method of any one of claims 1 to 6.

Images