WO2025010033A1

WO2025010033A1 - Smart contract specification mining

Info

Publication number: WO2025010033A1
Application number: PCT/SG2024/050440
Authority: WO
Inventors: Yi Li; Ye Liu
Original assignee: Nanyang Technological University
Current assignee: Nanyang Technological University
Priority date: 2023-07-06
Filing date: 2024-07-05
Publication date: 2025-01-09
Anticipated expiration: 2026-01-06

Abstract

Systems and methods for smart contract specification mining receive a smart contract transaction history, slice the history to produce invocation traces, and determine predicates from the history. Each predicate belongs to a condition of a function of the smart contract. A finite state machine is then constructed over states in the invocation traces and predicates, and counterexample-guided abstraction refinement is performed to extend the finite state machine satisfying a minimal existential abstraction property.

Description

SMART CONTRACT SPECIFICATION MINING

Technical Field

The present invention relates, in general terms, to mining smart contract specifications. More particularly, the present invention relates to, but is not limited to, inferring smart contract specifications from past transactions histories.

Background

Blockchain technology has been developed rapidly in recent years, since the introduction of Bitcoin. Blockchain itself is a distributed ledger maintained and shared by a peer-to-peer (P2P) network. Blockchain has evolved into a platform supporting the deployment and execution of smart contracts.

Smart contracts are self-executing computer programs used to implement Decentralized Applications (DApps). Users interact with smart contracts by executing transactions on the blockchain, where the transaction data specifies inputs, such as the address of the sender, the smart contract function called, and parameter values.

Despite the high stakes involved in transacting using smart contracts, smart contracts are often developed in an undisciplined way. The existence of bugs and vulnerabilities compromises the reliability and security of smart contracts and endangers the trust of users. For example, many smart contracts restrict user access to functionalities by implementing certain access control policies. Many smart contracts do not comply with standard specifications and contain bugs. As a result, economic behaviour models can be exploited to attack the decentralized finance (DeFi) ecosystem with flash loans.

A major difficulty in validating the conformance of smart contracts, i.e., whether

the contract implementation adheres to the expected behaviours, is the lack of documented formal specifications. Formal specifications capture the expected contract behaviours, in terms of formal languages, based on a formal model with precise semantics. Specifications of a smart contract play a central role in describing, understanding, reasoning about contract behaviours, and detecting, through testing and verification, non-conformance issues such as functional bugs and security vulnerabilities.

Similar to traditional formal specifications, there are two general forms of smart contract specifications: (1) function-level program invariants used in testing, verification and runtime validation of smart contracts; and (2) contract-level behavioural specifications in the form of automata, which can be used to support contract synthesis model-based testing, design verification, and workflow verification.

Mining high-level automata-based specifications automatically for smart contracts, is a difficult problem. However, the way smart contracts behave poses new challenges for mining automata-based behavioural models. As they are usually deployed on public blockchain networks, smart contracts handle multiple user interactions simultaneously. Therefore, the execution traces recorded in contract transaction histories consist of interleaving events triggered by different user interactions and may belong to different sessions. Since there does not exist a standard approach for managing user sessions, the execution traces cannot be easily separated for independent interactions. Moreover, predicate abstraction is crucial in deriving compact but accurate automata. Yet, the choice of predicates remains challenging and is often tightly tied with the specific analysis tasks. The predicate abstraction techniques used in computing state abstractions must be tailored to take into account the specific data structures and runtime environments of smart contracts.

It would be desirable to provide a more reliable mechanism for mining smart contracts to develop specifications, or at least to provide a useful alternative to

pre-existing solutions.

Summary

As described herein, to mine more accurate automata specification efficiently for smart contracts, specification mining algorithms are powered by trace slicing and predicate abstraction. The contract specification mining process is preceded by a slicing of the transaction histories - e.g., via a parametric binding learned from the existing test suites. Relatedly, a slice of history is a sequence of interrelated transactions, e.g., all transactions related to one specific trade session. Smart contract transaction histories, being stored persistently on blockchain, record all past function executions since the contract deployment. To find suitable predicate candidates for state abstraction, a statistical inference technique generates a set of dynamic invariants, based on the transaction histories. A counterexample-guided abstraction refinement approach is used to perform a lazy state abstraction, and introduce minimal existential abstraction to ensure the automata specification is accurate and simple. Finally, the present automata specification subsumes all observed invocation sequences and at the same time preserves its generality.

The present invention derives high-level behavioural automata with program invariants from smart contracts and their transaction histories.

Disclosed herein is a method for smart contract specification mining, comprising : receiving a transaction history for a smart contract; slicing the transaction history to produce one or more invocation traces; determining one or more predicates, each predicate belonging to a condition of a function of the smart contract; constructing a finite state machine over states in the one or more invocation traces and the one or more predicates; and

performing counterexample-guided abstraction refinement to extend the finite state machine satisfying a minimal existential abstraction property.

Also disclosed is a system for smart contract specification mining, comprising: memory; and at least one processor (processor(s)), the memory storing instructions that, when executed by the processor(s), cause the processor(s) to: receive a transaction history for a smart contract; slice, using a history slicing module, the transaction history to produce one or more invocation traces; determine, using a predicate extractor, one or more predicates, each predicate belonging to a condition of a function of the smart contract; construct, at a finite state machine module, a finite state machine over states in the one or more invocation traces and the one or more predicates; and perform, using a refinement module, counterexample-guided abstraction refinement to extend the finite state machine satisfying a minimal existential abstraction property

Brief description of the drawings

Embodiments of the present invention will now be described, by way of nonlimiting example, with reference to the drawings in which:

Figure 1 illustrates how interleaving interactions are separated from past transaction histories.

Figure 2, comprising images 2a and 2b, shows a data structure used in a smart contract implementation (image 2a) and a mined automation in accordance with present teachings (image 2b).

Figure 3 shows a two-state automaton containing potential spurious paths.

Figure 4 shows an automaton containing spurious paths.

Figure 5 shows a final automaton containing no spurious paths.

Figure 6 is a schematic of a system for implementing the present methodology.

Detailed description

Described is a specification mining approach to infer contract specifications from past transaction histories. The present approach derives high-level behavioural automata of function invocations, accompanied by program invariants statistically inferred from the transaction histories.

To that end, disclosed is a method for smart contract specification mining. This approach of the method is illustrated, though not limited to, with the GameChannel contract from a DApp called Dicether. Dicether is a decentralized casino application on Ethereum, relying on a smart contract to provide an open, secure, and fair gaming experience. From a user perspective, a smart contract is a set of interface functions. The functions can be invoked to execute contract code. If these interface functions be represented as base events: is the set of interface function names and e e l; corresponds to a contract function. The execution of e accepts parameters (denoted as X), including the user-provided function inputs (XI) and the contract state variables (X2) stored on the blockchain.

A new game is created by calling the contract function createGame - i.e., a transaction over the smart contract is initiated. When approaching the end of a game, an admin user may invoke the serverEndGame function to close the game. With reference to Figure 1, the method, embodied by schematic 100, includes receiving a transaction history 102 for a smart contract. The transaction

histories 102 are each a sequence of transactions. Each transaction can be decoded as a contract function invocation. The functions are labelled in Figure 1 as A to G. Each transaction history is then sliced (at Trace slicer 104) to produce one or more invocation traces 106. The slicing function performed by the trace slicer 104 performs is determined by interaction patterns observed in test suites, on the transaction history, to produce a set of independent invocation sequences. For GameChannel, there are six game interaction (invocation) sequences shown in Figure 1, corresponding to six user sessions. For instance, useri : A(gameld : l) indicates the invocation sequence for createGame by useri for creating a game with index 1. For simplicity, some values and variables are omitted from Figure 1. A function invocation may change the values of state variables, thus updating contract states.

There are two types of trace considered in the present disclosure, namely NonParametric and Parametric traces. For Non-Parametric Events and Traces, let be a set of (nonparametric) events, called base events or simply events. An E,- trace, or simply a (non-parametric) trace is any finite sequence of events

that is, an element

If event e e <; appears in trace w e

then e e w. For Parametric Events and Traces, let X be a set of parameters and let V be a set of corresponding parameter values X in parametric traces. Let DX , DX1, and DX2 be the corresponding domains. If £ is a set of base events as for Non-Para metric traces, then ^(X) is the set of corresponding parametric events e(0), where e is a base event in <; and 0 is a partial function in [X V ]. A parametric trace is a trace with events in ^(X), that is, a word in 5(X)~. Given a smart contract, let ^(X) be the set of all function executions, and any function invocation sequence can be represented as a parametric trace (word) in ^(X)\

After slicing, one or more predicates are determined, wherein each predicate belongs to a condition of a function of the smart contract. In the present example, 11 predicates have been identified, namely:

Pi: status = 0

P2 : status = 1

P3 : status = 2

P4 : status = 3

Ps : status > 3

Pe : roundld = 0

P7 : roundld > 0

Ps : endlnitiatedTime = 0

P9 : endlnitiatedTime > 0

Pio : stake = 0

PH : stake > 0

Table 1 shows the pre/post-conditions of GameChannel.

Table 1 : pre/post conditions of GameChannel

Predicates partition the domain of the state. In Figure 1, the first game is created by useri and after a while ended by users. Three game states, sO, si, and s2, are involved. The second game is created by user?, and later cancelled by user2 and users via serverCancelActiveGame and userCancelActiveGame,

respectively. From these invocation sequences 106 and predicates, we are able to capture the behaviours of a smart contract using a labelled transition system (LTS) that accepts all its function invocation sequences. A smart contract is a labelled transition system (S, sO, Z, 6) where S is a set of possibly-infinite states, S c DX1, sO e S is an initial state, Z is a possibly-infinite alphabet, Z c 5(X)*, and 6 £ s x Z x S is a set of transitions. An LTS can be represented more compactly by abstracting it into an extended finite state machine (EFSM). The finite state machine (or EFSM) is annotated with function pre/post-conditions, as a specification of the observed contract behaviours, and is constructed over states in the one or more invocation traces and the one or more predicates. Specifically, in GameChannel, each function pre/post-condition consists of a set of predicates either relevant to game state variables or function input parameters.

An EFSM in the present disclosure is defined as a tuple - presently, a 6-tuple (Q, qo, Z', G, U, T ) where, Q is a finite set of symbolic states under a predicate abstraction a : S -> Q, qo e Q is the initial symbolic state, Z' is a finite alphabet defined as Z' c

G is a set of guarding functions gi such that gi : Dx > {True, False}, - U is a set of update function Ui such that ui: DX Dx, T is a transition relation, T : Q x G x Z ^ U x Q.

Counterexample-guided abstraction refinement can then be performed to extend the finite state machine satisfying a minimal existential abstraction property. Abstraction refinement can be looped to iteratively produce the extended finite state machine. Counterexample-guided extraction involves computing state abstractions for states of the finite state machine. To compute state abstractions, predicate abstraction is typically used. Predicate abstraction is a function to create a partition of the domains of data types. A widely used predicate abstraction for integer domain is {neg, zero, pos} which represent negative, zero and positive numbers respectively. However, there could be many EFSM candidates that an LTS can be abstracted into. For this reason, the present methodologies employ a minimal existential abstraction to obtain a compact EFSM.

As mentioned above, the finite state machine is defined as a tuple, presently s the minimal existential abstraction of LTS = (S,

Under the minimal existential abstraction, (1) the initial concrete state can be mapped to the initial symbolic state in the EFSM, and vice versa, and (2) every concrete path is preserved in the ESFM, and every symbolic path in the ESFM has at least a corresponding concrete path.

Image 2a shows an example data structure - e.g. that used in GameChannel. In this example, server, gameldCntr, and gameldGame maintain information about the game manager, the number of created games, and all game state information, respectively. The game state variables include status, roundld, endlnitiatedTime, and stake. The variable status being ENDED (0) indicates that a game either has not been created or has already been terminated; roundld refers to the number of current gambling rounds; endlnitiatedTime records when a game is required to terminate itself as per users' requests; and stake keeps the funds that a player deposits as the bid when creating a game. All parameter values, including contract state variables and user-provided function inputs, can be decoded from blockchain transactions. Accordingly, dynamic invariants can be inferred as candidates for predicates on function pre/post- conditions. Table 1 shows the predicates identified in this example, those predicates partitioning the domain of each game state variable.

By default, all contract state variables are initialized zero, so so can be represented by Pi A Pg A PS A PIO. These predicates also form the pre- and postconditions in Table 1 where some other parameter predicates in the pre- and post-conditions are over function input parameters, i.e., " roundld", and caller of the function, i.e., "caller". For the createGame function, its precondition is that all the values of variables, namely, status, stake, roundld, and endlnitiatedTime, are zero; and its postcondition is that when createGame finishes, the variable status is set to ACTIVE (1) and the deposited stake is greater than zero and equals to the transferred fund, i. e., msg. value.

Image 2b shows the mined automaton of the smart contract underpinning GameChannel. The correctness of the automaton has been verified using the ground truth specification of GameChannel. The mined automaton has seven symbolic states, represented by circles in image 2b. Only createGame can be called in the initial state, hence the single path from the initial symbolic state to the next state under function A. Furthermore, when the caller is server, he/she is allowed to call serverEndGame to terminate the game and move the current state to the final state.

Such an automaton captures the common usages of GameChannel and its permission policies, thus being a likely contract specification. As for automata construction, the tool SmCon uses a CEGAR-like approach, as discussed below. This involves a lazy abstraction - i.e., no refinement of the predicate abstraction unless necessary. To obtain an ESFM, SmCon takes the sliced independent invocation sequences and inferred function pre/post-conditions as input. An initial automaton is constructed containing only two states, which is then revisited to recognize spurious symbolic paths that have no support - i.e., those paths without a corresponding concrete invocation sequence in the past observations (historical transactions).

The automaton is then refined to eliminate the spurious paths. This can be done via splitting larger states into smaller states or sub-states, or by removing

unreachable transitions. This process is repeated until no spurious paths remain in the automaton. Thus constructing the finite state machine involves assuming an automaton comprising a set of states and a set of transitions between states in the set of states, then iteratively refining paths between states to excise spurious paths.

Smart contracts simultaneously accept inputs from multiple users. Contract executions in such a setting result in a linear transaction history consisting of interleaving execution traces triggered through multiple user interactions/sessions. To record data owned by different users, many smart contracts maintain a collection of custom data objects, indexed by user(session)-specific parameters. For example, the GameChannel contract maintains many concurrent game instances as state variables. To interact with a particular game instance, a user needs to specify the value of its gameld, through input parameters of the transaction - refer to "gameld" in Figure 1.

To determine the contract specifications from transaction histories with mixed interactions, the transactions histories need to be sliced into independent traces for each game instance. Functionally, for trace slicing a parametric trace, given a parametric trace T e ^(X)* and a parametric binding 9 in [X V ], let the 9- trace slice T t0e

be the nonparametric trace defined as:

where e is the empty trace/word, and :

where 6' is assumed to be less informative than 0, written iff for any x e

X, if 0'(x) is defined then 0(x) is also defined and 0'(x) = 6(x).

In accordance with present teachings, a transaction history of smart contract is a parametric trace. Trace slicing slices the history into a set or plurality of independent invocation sequences via certain parametric bindings (e.g., 0). Moreover, slicing the transaction history can involve performing a plurality of slices, the method comprising, for each slice, filtering out all events that are irrelevant to a parameter instance of a parameter in the parametric bindings. A trace slice T I'd first filters out all the parametric events that are irrelevant to the parameter instance 9. An event is irrelevant to a parameter instance if the event does not take the parameter instance as input, manipulate the parameter instance nor output the parameter instance. A trace slice also forgets the parameter bindings of parametric events. Thus, slicing the transaction history comprises performing a plurality of slices, and the method then involves, for each slice, forgetting parameter bindings for parametric events.

As a result, a trace slice is non-parametric and merely a list of base events. To find parametric bindings, the relation between different events should be ascertained, or function invocations in smart contracts. Such parametric bindings can be inferred - e.g., from existing test suites that demonstrate typical usage scenarios and user interaction patterns. In some embodiments, a group of related functions and the parameter values they share can be observed in a unit test. For example, the test suites for GameChannel contain many test cases where game objects are explicitly specified by the "gameld" variable in each contract function. Therefore, the transaction history can be sliced according to the corresponding values of "gameld" to generate a set of independent game invocation sequences.

The choice of predicates is crucial for computing good state abstractions. To this end, statistically likely pre- and post-conditions of contract functions as considered candidate predicates. The method of smart contract specification mining can therefore involve decoding, from the transaction history and before and after each function invocation, one or both of contract state variables values and user-provided inputs (function inputs). Dynamic invariants can then be

statistically inferred for each function, each predicate comprising a dynamic invariant. The inferred dynamic invariants hold for all observed invocations in the past transaction histories. More specifically, a predicate template is defined as "x XI y", where x eX is a parameter, and y eX uK is either a parameter or constant, and X is an operator from the set {=, ! =, >, <, <=, > = }. The template is instantiated on all successful transactions, which are not reverted during executions, and the instances which always hold are kept as predicate candidates for either function pre- or post-conditions. The predicates defined over state variables are used in constructing the symbolic states Q in the EFSM.

Smart contracts employ large integer type systems and some unique data structures when compared with traditional programs, such as "mapping", which defines a key-value collection. Therefore, the existing integer invariant templates must be extended, and new invariant templates must be added. In some smart contracts, a transaction reversion will be raised if contract execution fails to satisfy any execution condition. In other words, the target function's pre- and post-conditions are satisfied in all successful past transactions. But since the transaction history may be limited, the inferred pre- and post-conditions are likely to hold, which is good enough to serve as predicate candidates.

The over-generalization of the inferred function pre/post-conditions is the main difficulty for their direct use in mining high-level automata specifications. To address this problem, a counterexample guided abstraction refinement (CEGAR)-like approach is used to mine automata specifications with predicate abstraction.

To mine a precise specification, a precise state abstraction a is computed. This creates partitions on the contract state variables. The abstraction function a is implicitly computed following the paradigm of counterexample-guided abstraction refinement. In some embodiments, the specification mining algorithm is defined using the following rules:

The algorithm takes as input past observations of concrete invocation sequences and inferred function pre/post-conditions. When the algorithm terminates, it produces an EFSM containing no spurious states and transitions.

The Init rule initializes a preliminary extended finite state machine containing two states: qo, referring to ^ x = 0 that all state variables are valued zero, and — >qo for the remaining cases. The guard function G and update function U are directly instantiated by the inferred function pre- and postconditions, respectively. The transition relation set T is initialized to be empty. The Construct rule is the applied to add theoretically feasible state transitions to the automaton. A state transition is theoretically feasible if and only if it satisfies the logical conjunction of symbolic states and function preconditions or post- conditions.

The resulting automaton could be over-generalized such that it includes spurious state transition paths. The RmPath rule is thus applied, following Algorithm 1 to eliminate those spurious state transition paths that are not supported in the concrete observations. Algorithm 1 performs one of two actions to exclude spurious paths - state splitting or transition removal. Thus, counterexample-guided abstraction refinement comprises identifying a number of spurious paths resulting from applying the invocation traces to the finite state machine, and extending the finite state machine, removing spurious paths, by either splitting at least one state in the set of states, into two or more states, or by removing at least one transition from the set of transitions, to reduce the number of spurious paths. This abstraction process can be repeatedly performed until the number of spurious paths is zero. These above rules would thus be applied many times according to a fair scheduling. Thus, when the algorithm terminates, it produces an extended finite state machine, containing no spurious states or transitions.

The resulting automaton does not allow loop transitions according to the RmPath rule. However, this kind of automaton may not be able to produce precise and useful contract specifications. Because many smart contracts have behaviour cycles, it is preferred to have loop transitions in the resulting automaton.

To improve the precision and usability of contract specification mined using the present teachings, the range of path selection may be limited when applying RmPath - e.g., a loop transition may only be covered once in any selected path. For example, a state transition path

- <7 is excluded given the path loops twice. With this minor modification to the RmPath rule, the resulting automaton allows loop transitions so that it may express cycles.

Use GameChannel as an example - initially, rule Init is applied. As shown in Figure 3. The resulting automaton has two states: qo and qi. For the initial state qo, all state variables are valued zero, namely Pi A Pe A PS A PIO, while qi covers all the remaining values of the state variables, namely . For

each function m, its precondition g_m is added as the guard function set G, and the post-condition u_m is added to the update function set U, which we omit from these diagrams for simplicity.

The Construct rule adds all possible transitions to the automaton. It is easy to see in Figure 3 that the resulting automaton contains all the observed concrete function invocation sequences. However, spurious behaviours may have been allowed in the automaton. For example, the symbolic path -

qi - C - qi is spurious, as it has no supported concrete invocation sequence within the observations. Therefore, the RmPath rules is applied to eliminate such spurious paths. In rule RmPath, the concretize function is used on a symbolic path to represent one of its possible concrete invocation sequences. For the spurious path the automaton needs to refine

itself by either splitting the state qi (q_n in Line 6 of Algorithm 1) or removing the transition qi - C - qi (tn+i in Line 10 of Algorithm 1).

Algorithm 1 shows the present approach to removing a spurious path via state splitting or transition removal. For the state qi and the transition qi - C - qi in Figure 3, first an attempt is made to split the state qi with the precondition of function C, namely Pz v (Pa A PG) of serverCancelActiveGame. The decision procedure SAT (Line 5 of Algorithm 1) decides if a symbolic state is feasible. Due to the fact that the two newly created states (Lines 3-4 of Algorithm 1) for qi are feasible, qi is replaced with the new states (Line 6 of Algorithm 1) and the outdated transitions starting or ending with qi are removed (Line 7 of Algorithm 1). The modified automata structure will be returned (Line 15 of Algorithm 1) and when applying the Construct rule again. A new automaton is then obtained per Figure 4, which now has three states.

In Algorithm 1, it is possible that q_n is not splittable with the function precondition (Lines 8-14 of Algorithm 1). When tn+i has never been visited by replaying all the concrete invocation sequences on the automaton (Line 9 of Algorithm 1), tn+i can be safely removed to eliminate the spurious path. Otherwise, state q_n will be split with an equivalent predicate representing a partial set of the visited concrete states (such as so to S17 of Figure 1) along a symbolic path n' (Lines 12-13 of Algorithm 1). Outdated transitions relevant to q_n will also be removed (Line 14 of Algorithm 1).

Figure 4 also contains spurious paths, such as qo - A - qn - E - qn - E - qi2, which have to be eliminated. By applying the aforementioned rules many times, an automaton can be mined as shown in Figure 5, which has the exact automata structure as image 2b, except for the guard condition that has been excluded for simplicity. Apart from the common usage scenarios, root semantics of each state in the automaton can be understood. Each symbolic state is represented by a set of predicates. As described before, qo is represented by Pi A Pe A PS A PIO. In the automaton, q'n is represented by Pz that says status is ACTIVE, q'n is represented by P4 A Pe that says status is SERVER INITIATED END and roundld is zero, qs is represented by P3 A Pe that says status is USER INITIATED END

and roundld is zero, q4 is represented by P4 A P7 that says status is SERVER INITIATED END but roundld is larger than zero, qs is represented by P3 A P7 that says status is USER INITIATED END but roundld is larger than zero, and qe having no outcoming transitions suggests it the final state whose predicates cover all the remaining cases. Such automata specifications precisely model smart contract semantics, which is helpful for understanding contract behaviours.

To ensure the termination of the present methodology, applications of the rules have to follow a fair scheduling. A fair scheduling is an infinite sequence of actions: ai, a2, . . . , an, where ai e {Construct, RmPath} and the following conditions apply:

(1) Construct is the initial action - this enables the initial construction of the automaton.

(2) if new states are added, Construct keeps applying until it is inapplicable - this ensures the integrity of any subsequent automata construction.

(3) RmPath appears infinitely often - ensures that every spurious path of the automaton will eventually be removed.

Under the above conditions, the assumption is that the algorithm terminates when RmPath and Construct are both no longer applicable.

The present specification mining algorithm terminates after a finite number of actions in any fair scheduling. For LTSh which is equivalent to the observed concrete invocation sequences, let N_s be the number of concrete states and N_p be the number of all concrete invocation sequences. For each application of rule RmPath, it will take no more than N_P+i times to traverse the resulting automaton to find such a spurious path n if it exists. Therefore, RmPath itself is terminated. As discussed in Algorithm 1, a transition may be removed from the resulting automaton. According to the fairness conditions, RmPath will keep applying until it splits a state to generate two new fine-grained states. Suppose the current automaton has n symbolic states and k symbolic state transitions, then k < n x

\M\ x n, where \M\ is the number of contract functions. Therefore, the times for RmPath to find one more reachable states is no more than n x |M| x n. So it takes no more than N_s x max(n) x |M| x max(n) times to find all reachable states, where max(n) < N_s.

The number of RmPath actions in any scheduling cannot exceed (N_s+i)xmax(n)x \M\ xmax(n). Finding all reachable states does not exceed N_s xmax(n)x \M\ xmax(n) . RmPath will then be applied to remove any unreachable transition if applicable. This will apply no more than max(n)x \M\ xmax(n) times. Finally, RmPath will be inapplicable and the algorithm will terminate with no more than (N_s+i)xmax(n)x\M\ xmax(n) actions of RmPath.

The automaton resulting from the above process (ignoring loop transitions) is a minimal existential abstraction of LTSh. To show this is the case, the automaton must satisfy Condition (1) and Condition (2). Condition (1) holds because by default, all uninitialized state variables of smart contracts are valued zero, and so is the initial concrete state where all state variables are valued zero. The automaton takes the zero-valued predicates of all state variables as the initial symbolic state qo. In this setting, {so} = a^-1(qo). Thus, Condition (1) is satisfied. Condition (2) can be verified by proving: (i) every observed concrete invocation sequence (i.e., a concrete path in LTSh) is preserved in the resulting automaton; (ii) every symbolic path of the resulting automaton has a corresponding concrete path in LTSh, - i.e., no symbolic path is spurious. According to rule Construct, (i) holds in the resulting automaton. Regarding (ii), suppose the resulting automaton contains a spurious path n : qotitz ■ ■ ■ q_n e EFSM where 3 concretize(n) e LTSh. The RmPath rule will be applied to remove n either via state splitting or transition removal at finite actions. Thus, there is no such spurious path n, which is in contradiction with the assumption. Therefore, (b) is proved. Hence, Condition (2) is satisfied by the resulting automaton.

The abovementioned processes are executed in a computer system such as system 600 of Figure 6. The system 600 may be any suitable computer, including that set out below in relation to the experiments.

While modules and components of the system 600 are shown, and labelled, separately, it will be appreciated that they can be combined in any suitable combination, and broken down into smaller components as needed, provided the functionality set out herein is preserved. Moreover, each module may be located on a common server, or distributed across multiple servers. In addition, each component may be implemented in software, hardware or a combination of the two.

The system 600 comprises memory 602 that stores computer executable instructions (program code 604) that is executable by processor(s) 606 to implement the above methodology. The system 600 also includes an interface (I/O module 608) for receiving data (e.g., transaction histories) and outputting mined specifications. The system 600 further comprises a history slicing module 610, predicate extractor 612, finite state machine (FSM) module 614 and refinement module 616. The history slicing module 610 slices the transaction histories to produce invocation traces. The predicate extractor determines predicates belonging to a condition of a function of the smart contract received by I/O module 608. The FSM module 614 constructs a FSM over states in the invocation traces and the predicates, and the refinement module 616 performs counterexample-guided abstraction refinement to extend the finite state machine satisfying a minimal existential abstraction property.

Thus, the methodology schematically reflected in Figure 1, and the system 600 that implements that methodology, enable specification mining for smart contracts. The approach uses a CEGAR-like mechanism to mine automata specifications based on past transaction histories. The mined specifications capture not only the allowed function invocation sequences, but also the inferred program invariants describing contract semantics precisely. Such contract

specifications are useful in contract understanding, testing, verification, and validation.

Experiments

Algorithm 1, named SmCon, was written in Python code. Through experiments,

SmCon was evaluated to answer the following questions:

1. How accurately and efficiently does SmCon mine smart contract specifications?

2. How useful are the mined specifications for smart contract test case

To evaluate SmCon, the selected accuracy metric measures the similarity between the mined automata specification and the ground truth, considering both precision and recall. Precision is defined as the percentage of sequences generated by the mined automata that are accepted by the ground truth, while recall is the percentage of sequences generated by the ground truth that are accepted by the mined automata. The Fl-score was used to measure the overall accuracy, which is defined as: u j_S impractical to generate all possible sequences for aut

omata with loops. Therefore, the length of the generated sequences was limited for accuracy calculation.

SmCon was evaluated against popular Ethereum DApp smart contracts as shown in Table 2. Ground truth specifications were obtained as well as the transaction data (historical transactions) from Etherscan since contract deployment and raw results are available at:

Regarding accuracy and efficiency, SmCon was evaluated on eight real-world smart contract instances running on Ethereum, shown in Table 3. SmCon was compared with a baseline approach, RPNI-MDL, implemented based on LearnLib, which is a passive learning algorithm to learn automata from positive trace examples. The recognition of negative examples for smart contracts is difficult since the invocation to a function may fail in some cases but succeed in others. With only positive training data, RPNIMDL was used as the baseline for our automata mining.

Table 3 shows the comparison result. The first column shows the names of the subject contract instances. The next two columns show the number of states and the number of transitions of the ideal automata, namely the corresponding ground truth. The five columns under RPNI-MDL list its results, including the number of states and transitions, precision, recall and Fl-score of the mined automata. Similarly, the next five columns show the results of SmCon. Table 3 shows that SmCon outperforms RPNI-MDL for all cases in precision when the trace length limit for automata comparison is set to be 3 or 6. The precision of the mined automata by SmCon is 100 % except for MoonCatRescue since spurious loop transitions were allowed in the present automata construction process - note: the method may include identifying a smart contract type and selectively permitting (or disabling) loop transitions. The precision of RPNI-MDL on the subject contracts is mostly lower than 85% when the trace length limit

is 3 and lower than 50% when the trace length limit is 6. The recall of SmCon is comparable with RPNI-MDL.

When the trace length limit is set to 6, the recall on some contracts is low for both techniques. The main reason is that, for some contracts, many designed behaviours have never been exercised, thus could not be mined from the transaction histories. For example, the contracts CryptoPunksMarket, SaleClockAuction, SupeRare, and MoonCatRescue, have the lowest recall when the trace length limit is set to 6. Specifically, in SaleClockAuction, we did not observe any invocation to its function createAuction taking four parameters in the transaction histories.

The Fl-score indicates that SmCon outperforms RPNI-MDL for nearly all cases. Notice that GameChannel has three deployed instances 0x7e, 0x99, and Oxae, which share the same ground truth specification, but have different transaction histories. The precision, recall, and Fl-score for their mined automata by SmCon are reasonably similar to each other. This shows that variations in transaction histories do not have a significant impact on SmCon's performance. In terms of computation time, SmCon on average took about 3 minutes while RPNI-MDL took around one second per contract. In summary, SmCon achieves relatively high precision, comparable recall, and good Fl-score in the automata mining from past transaction histories of smart contracts.

Regarding how useful the methodology is, SmCon was used to help generate test cases to complement the existing test suites. Various test sequences were derived from the mined extended finite state machine by SmCon. Each test sequence walks through a symbolic path of the automaton.

Table 4 shows the comparison results of the state and transition coverage on the ground truth by the existing test suites and the test sequences generated from the mined automata. The columns "Test suites", "SmCon", and "Test suites + SmCon", show the number of covered states and transitions by the existing test suites, SmCon, and their combination, respectively. The existing test suites have better coverage than SmCon in some cases, but SmCon is better for others.

Table 4 shows that the test suite of MoonCatRescue has insufficient test cases covering only 6 out of 10 states and 13 out of 58 transitions. Interestingly, SmCon covered 9 states and 34 transitions. Meanwhile, when test suites are missing, SmCon can be used to generate new test cases for RpsGame from the scratch. Moreover, the combination of SmCon and the existing test suites contributes to higher state and transition coverage. These results indicate SmCon can generate test cases as good as those written by developers, achieving higher test coverage.

It will be appreciated that many further modifications and permutations of various aspects of the described embodiments are possible. Accordingly, the described aspects are intended to embrace all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims.

Throughout this specification and the claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" and "comprising", will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that that prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.

Claims

1. A method for smart contract specification mining, comprising: receiving a transaction history for a smart contract; slicing the transaction history to produce one or more invocation traces; determining one or more predicates, each predicate belonging to a condition of a function of the smart contract; constructing a finite state machine over states in the one or more invocation traces and the one or more predicates; and performing counterexample-guided abstraction refinement to extend the finite state machine satisfying a minimal existential abstraction property.

2. The method of claim 1, wherein constructing the finite state machine comprises assuming an automaton comprising a set of states and a set of transitions between states in the set of states.

3. The method of claim 2, wherein performing counterexample-guided abstraction refinement comprises: identifying a number of spurious paths resulting from applying the one or more invocation traces to the finite state machine; and extending the finite state machine by splitting at least one state in the set of states, into two or more states, to reduce the number of spurious paths.

4. The method of claim 2 or 3, wherein performing counterexample-guided abstraction refinement comprises: identifying a number of spurious paths resulting from applying the one or more invocation traces to the finite state machine; and extending the finite state machine by removing at least one transition from the set of transitions, to reduce the number of spurious paths.

5. The method of claim 3 or 4, comprising repeatedly performing counterexample-guided abstraction refinement until the number of spurious paths is zero.

6. The method of any one of claims 1 to 5, wherein slicing the transaction history into one or more invocation traces comprises slicing the transaction history into a plurality of independent invocation sequences via parametric bindings.

7. The method of claim 6, wherein slicing the transaction history comprises performing a plurality of slices, the method comprising, for each slice, filtering out all events that are irrelevant to a parameter instance of a parameter in the parametric bindings.

8. The method of claim 7, wherein an event is irrelevant to a parameter instance if the event does not take the parameter instance as input, manipulate the parameter instance nor output the parameter instance.

9. The method of any one of claims 6 to 8, wherein slicing the transaction history comprises performing a plurality of slices, the method comprising, for each slice, forgetting parameter bindings for parametric events.

10.The method of any one of claims 1 to 9, wherein determining one or more predicates comprises: decoding, from the transaction history and before and after each function invocation, one or both of contract state variables values and user- provided inputs; and statistically inferring dynamic invariants for each function, each predicate comprising a said dynamic invariant.

11. A system for smart contract specification mining, comprising : memory; and

at least one processor (processor(s)), the memory storing instructions that, when executed by the processor(s), cause the processor(s) to: receive a transaction history for a smart contract; slice, using a history slicing module, the transaction history to produce one or more invocation traces; determine, using a predicate extractor, one or more predicates, each predicate belonging to a condition of a function of the smart contract; construct, at a finite state machine module, a finite state machine over states in the one or more invocation traces and the one or more predicates; and perform, using a refinement module, counterexample-guided abstraction refinement to extend the finite state machine satisfying a minimal existential abstraction property. The system of claim 11, wherein the finite state machine module constructs the finite state machine by assuming an automaton comprising a set of states and a set of transitions between states in the set of states. The system of claim 12, wherein the refinement module performs counterexample-guided abstraction refinement by: identifying a number of spurious paths resulting from applying the one or more invocation traces to the finite state machine; and extending the finite state machine by splitting at least one state in the set of states, into two or more states, to reduce the number of spurious paths. The system of claim 12 or 13, wherein the refinement module performs counterexample-guided abstraction refinement by: identifying a number of spurious paths resulting from applying the one or more invocation traces to the finite state machine; and

extending the finite state machine by removing at least one transition from the set of transitions, to reduce the number of spurious paths. The system of claim 13 or 14, wherein the refinement module is configured to repeatedly perform counterexample-guided abstraction refinement until the number of spurious paths is zero. The system of any one of claims 11 to 15, wherein the history slicing module slices the transaction history into one or more invocation traces via parametric bindings. The system of claim 16, wherein the history slicing module slices the transaction history by performing a plurality of slices and, for each slice, filters out all events that are irrelevant to a parameter instance of a parameter in the parametric bindings. The system of claim 17, wherein an event is irrelevant to a parameter instance if the event does not take the parameter instance as input, manipulate the parameter instance nor output the parameter instance. The system of any one of claims 16 to 18, wherein the history slicing module slices the transaction history by performing a plurality of slices and, for each slice, forgets parameter bindings for parametric events. The system of any one of claims 11 to 19, wherein the predicate extractor determines one or more predicates by: decoding, from the transaction history and before and after each function invocation, one or both of contract state variables values and user- provided inputs; and statistically inferring dynamic invariants for each function, each predicate comprising a said dynamic invariant.