CheckMate: Automated Game-Theoretic Security Reasoning

We present the CheckMate framework for full automation of game-theoretic security analysis, with particular focus on blockchain technologies. CheckMate analyzes protocols modeled as games for their game-theoretic security - that is, for incentive compatibility and Byzantine fault-tolerance. The framework either proves the protocols secure by providing defense strategies or yields all possible attack vectors. For protocols that are not secure, CheckMate can also provide weakest preconditions under which the protocol becomes secure, if they exist. CheckMate implements a sound and complete encoding of game-theoretic security in first-order linear real arithmetic, thereby reducing security analysis to satisfiability solving. CheckMate further automates efficient handling of case splitting on arithmetic terms. Experiments show CheckMate scales, analyzing games with trillions of strategies that model phases of Bitcoin's Lightning Network.


INTRODUCTION
Applications of blockchain technology such as cryptocurrencies [27] and decentralized finance [35] are becoming increasingly popular.
Establishing security guarantees of such applications is mostly driven by formal analysis of the underlying cryptographic protocols [3,17,26,34].While powerful, these efforts cannot capture malicious actions that are possible in spite of formal cryptographic guarantees.Game-theoretic security analysis has therefore emerged [31,36], introducing variants of extensive form games (EFGs) [29] for embedding punishment mechanisms within blockchain analysis.
In a nutshell, game-theoretic security analysis enables reasoning about incentive-compatibility: that is, whether malicious yet cryptographically-possible behavior is discouraged via punishment mechanisms.It also enables detecting and even preventing scenarios that could lead directly to security attack vectors [23].Feasibility of game-theoretic models for investigating an underlying protocol's security partially depends on the game completeness, that is, on expressing all possible interactions between players.In consequence, accurate models are likely to be rather large and complex games.For example, while [31] introduces a so-called Closing Game to precisely model the closing phase in Bitcoin's Lightning Network [30], we show there are trillions of possible joint strategies (combinations of player strategies) for the Closing Game (see Example 3.4).As such, manually analyzing game-theoretic security models is not practically viable.In this paper, we therefore introduce the CheckMate framework for automating reasoning about game-theoretic security of blockchain protocols.To the best of our knowledge, CheckMate provides the first automated reasoning framework for enforcing game-theoretic security, (dis)proving, for example, security of real-world protocols used within Bitcoin's Lightning Network (Section 6).Related reasoning approaches for (extensive form) games exist [18], but current techniques are limited to processing games with numeric values as game utility variables enacting punishment or reward mechanisms.In CheckMate, we advocate for the use of symbolic values, guaranteeing security for every possible numeric value, e.g.every possible account balance in decentralized finance applications.
The distinctive feature of CheckMate is a formalization of security properties over game strategies in such a way that the result can be (dis)proved using "only" first-order arithmetic reasoning with limited quantification (Section 4).To this end, we turn applications of blockchain security into a satisfiability modulo theory (SMT) problem, by showing that first-order linear real arithmetic provides an expressive logic to formulate and prove game-theoretic security (Lemma 4.1).Our first-order encoding is exact and, unlike the work of [18,19], does not feature probabilistic (reward) operators.
Instead, we provide a decidable logic for game-theoretic security and omit the computational burden of reasoning with uncertainty.
The added value of our first-order encoding is witnessed when formalizing that deviating from the protocol is never rational (incentive compatibility), and that even if adversaries deviate, honest users are not financially harmed (Byzantine fault-tolerance) (Section 2).We show the formalization is sound and complete: our security proofs imply game-theoretic security and vice versa (Theorem 5.2).In this respect, we introduce novel reasoning approaches on top of SMT solving, scaling and using formal verification not only for enforcing game-theoretic security, but also providing counterexamples and/or refining preconditions where security properties are violated (Section 5).Our Contributions.We bring the following main contributions 1 .
(i) We formalize game-theoretic security properties as firstorder arithmetic formulas over EFG joint strategies (Section 4), reducing security analysis of blockchain transactions to arithmetic reasoning over honest game histories with symbolic game utilities (Lemma 4.1).The use of symbolic utilities differentiates our work from other game-theoretic frameworks [18,19]: symbolic utilities allow us to avoid concurrent game strategies while providing a deterministic, game-theoretic behavior.As such, we also avoid reasoning with probabilistic (reward) operators.(ii) Since players may be willing to forgo some intangible assets, such as opportunity cost, but not actual resources, we introduce weaker immunity (Definition 3.6), strengthening the state of the art in game-theoretic security analysis.Our formalization is sound and complete with respect to their game-theoretic definitions (Theorem 5.2), and inhabits a decidable fragment of first-order arithmetic.(iii) Unlike [31,36], our EFG security properties avoid the use of non-trivial sets, functions and quantifier alternations.We show that this arguably simple logical formalization is both sufficient and necessary to precisely capture game-theoretic security (Theorem 5.2).Moreover, we provide tailored automated reasoning approaches over EFG strategies and bring them into the landscape of SMT solving (Algorithm 1).(iv) Since we reason about symbolic utilities, proving arithmetic relations naturally yields case splits.We guide these case distinctions via unsatisfiable (unsat) core computation in SMT solving (Section 5.1).(v) For EFG properties that are not secure, we provide attack vectors as concrete counterexamples to a violated security property (Section 5.2, Algorithm 2).In addition, we give weakest ordering conditions on utilities which, if assumed as preconditions, ensure security (Section 5.3, Algorithm 3).(vi) We implement our approach in the new tool CheckMate, a fully-automated security reasoning engine for EFGs that requires no user guidance (Section 6).We evaluate Check-Mate on challenging EFGs, including variants of real-world protocols namely closing and routing phases of Bitcoin's Lightning Network.Experiments demonstrate applicability and scalability of CheckMate, (dis)proving security of EFGs with trillions of strategies and thousands of nodes.While , our experiments show that CheckMate succeeds when analyzing the respective protocols in full (Table 1).

MOTIVATING EXAMPLES
We motivate and illustrate our work by considering simplified versions of the closing and routing protocol phases of Bitcoin's Lightning Network [31].Let us emphasize that our running examples from Figures 1-2 are simplified only for the sake of readability.
In experiments, we also evaluate CheckMate on full models of the respective protocols of Bitcoin's Lightning Network (Section 6).In particular, the last two entries of Tables 1 and 2 report on our results when analyzing Bitcoin's Lightning Network in its full complexity.The closing and routing phases of the Lightning Network are modeled as EFGs and visualized as trees in Figures 1 and 2. The start of an EFG is the root, and players' choices lead to different branches.The game ends when a leaf is reached, where a player's gain or loss is called their utility.
Example 2.1 (Simplified Closing Game).In the Simplified Closing Game of Figure 1, player  starts the game and chooses between three options: closing honestly ( ), collaboratively honestly ( ℎ ), or dishonestly ().If  chooses  , both players get the benefit of closing the channel , but player  has to wait until the closing times out, so the utility is reduced by the opportunity cost .If  chooses  ℎ , player  gets to choose between ignoring ( ), i.e. the funds remain locked, or signing (), where both players get the benefit of closing .If  chooses to close dishonestly with some deviating amount   , then if  chooses to ignore ( ), the funds for  are lost; however, if  proves () the attempt was dishonest, all of 's funds () are redistributed to , but the transaction fee  has to be paid.Note that the utilities in the leaves of the game tree are actual variables (, ,  , etc.), not numeric values, and ,  are infinitesimals (see Section 3).
Example 2.2 (Simplified Routing Game).CheckMate can handle games with any finite number of players.To show how an attack vector can arise from collusion between players and outline the main structure of the model of the routing protocol, we include in Figure 2 an EFG with five players, modeling a Simplified Routing Game.Player  is the initiator of the routing transaction, player  is the receiver and players  1 ,  2 and  3 are intermediaries.The routing starts when player  sends a hash of a secret to player ; this step is modeled with action   .Then, a so-called locking phase follows (the four actions ), where players lock funds for the next player in the routing path to unlock, provided they can present 's secret: player  locks the amount  + 3 (where  represents the routing fee), player  1 locks  + 2 , player  2 locks  +  and player  3 locks .Next, the game enters an unlocking phase, where players choose between the honest action  of unlocking their contracts, or to ignore unlocking (  ), resulting in a state where all contracts still locked expire and a leaf is reached.The end utilities of players depend on which contracts are unlocked, which are expired and additionally on two subjective values: the benefit of updating, modeled as a positive infinitesimal , and the opportunity cost, modeled as an infinitesimal .
The path that represents honest behavior is depicted in thick blue lines.CheckMate disproves security of the game, as the path depicted in dashed purple deviates from the honest behavior and corresponds to the so-called Wormhole attack [23].Within this dishonest behavior (attack), player  3 can additionally choose to share the secret with player  1 and thus bypass player  2 entirely.If  1 then chooses to unlock, it results in a negative utility (−) for player  2 , who is further deprived of earning the routing fee  for enabling the transaction, which they would get in the honest scenario depicted in blue.

Game Theory
We define a game to be a static finite object with finitely many players.Players choose from finitely many actions until the game ends, whereupon they receive a utility.We focus on perfect-information Extensive Form Games (EFGs) in which players choose actions sequentially with full knowledge of all previous actions.Games may yield collective benefit or loss, i.e. they are not necessarily zero-sum.Definition 3.1 (Extensive Form Game -EFG).An extensive form game Γ = ( , ) is determined by a finite non-empty set of players  together with a finite tree  = ( , ).A game path ℎ = ( 1 , ...,   ),   ∈  starting from the root of  is called a history.We denote the set of histories by H .There is a bijection between nodes  ∈  and histories ℎ ∈ H that lead to these nodes.
• A history that leads to a leaf is called terminal and belongs to the set of terminal histories T ⊆ H . Terminal histories  are associated with a utility for each player.• Non-terminal histories ℎ are those histories that are not terminal ℎ ∈ H \ T .Non-terminal histories ℎ have a player  (ℎ) ∈  whose turn it is, who may choose from a set of possible actions (ℎ) to take after ℎ.
In game theory, utilities are usually real-or integer-valued numeric constants.Similarly to [31], in our work we however consider utilities as symbolic terms in linear arithmetic capturing all possible utilities with certain constraints.We evaluate variables and constants over the real numbers R extended by a finite set of infinitesimals, closer to zero than any real number.Infinitesimals model subjective inconveniences or benefits that do not relate directly to funds, such as opportunity cost.For our purposes, we model infinitesimals by considering linear terms over R × R, ordered lexicographically: the first component represents the real part, the second the infinitesimal.We write real for the first projection and avoid writing pairs; that is, we write 0 for (0, 0).In the sequel, we use , ,  . . .for real variables, and write , , , . . .for infinitesimals.The utility term  +  −  is therefore represented in our work as (, 0) + (0, ) − (0, ), that is (,  − ).
While utilities depend only on terminal histories, we relate utilities with joint strategies, facilitating formulation of security properties in the sequel.The Simplified Closing Game has 3 • 2 • 2 joint strategies as player  chooses one out of three possible actions, and independently of that  picks one action out of two in both subtrees.Similarly, we reach the conclusion that the Closing Game [31] listed in Table 1 has 1.6307 . . .• 10 13 (16 trillion) joint strategies.

Game-Theoretic Security Properties
Since an adversary may perform an attack for one of two reasons (personal gain or harming somebody), a protocol is gametheoretically secure according to [31,36], if the following two properties hold: (P1) (Byzantine fault-tolerance) Even in the presence of adversaries, honest players do not suffer loss; thus, in a secure protocol an honest player will not receive negative utility, independent of others' behavior.Therefore, there are no "attacks" where somebody is harmed.(P2) (incentive-compatibility) Rational agents do not deviate from the honest behavior, as the honest behavior yields the best payoff.Hence, in a secure protocol, a rational "attacker" is behaving honestly and no adversary gets personal gain by deviation.
In the sequel, we fix an arbitrary EFG Γ = ( , ) and give all definitions relative to Γ. Based on [31], property (P1) is ensured by weak immunity as follows.In our work, we found weak immunity to be too restrictive (see Section 6).We therefore revise [31] and propose weaker immunity to ensure (P1) as follows: ( cr )

Definition 3.5 (Weak Immunity
Strategy  from Example 3.4 is not collusion resilient, since player  could deviate by choosing  ℎ initially and obtain , while by following  they receive only  − .Practicality ensures that for all player decisions, the honest behavior is also "greedy": if all players act selfishly (that is, maximizing their own utilities), the honest choice yields the best utility.Definition 3.8 (Practicality).A joint strategy  in EFG Γ is practical if it is a subgame perfect equilibrium, i.e. a Nash equilibrium in every subgame: ( pr ) Strategy  from Example 3.4 is not practical.In the subgame after history ( ℎ ), the selfish choice for  is to choose action .Assuming player  acts this way, player 's greedy strategy is to choose action  ℎ initially with expected utility  instead of  − .Using ( wi ), ( cr ), and ( pr ), we formalize security as in [31]: Definition 3.9 (Security).A terminal history ℎ * of an EFG Γ is secure if there are three strategies extending ℎ * that satisfy ( wi ), ( cr ) and ( pr ), respectively.
Our notion of security given in Definition 3.9 ensures that players can defend every attack.As the defense strategy may vary depending on the attack, different strategies for ( wi ), ( cr ) and ( pr ) are allowed.

FIRST-ORDER ARITHMETIC THEORY OF SECURITY PROPERTIES
We now introduce our first-order formalization of game-theoretic security, by exploiting and adjusting the EFG security properties of Section 3 within the first-order theory of linear real arithmetic.Our formalization ensures that if a first-order (security) formula is satisfiable, a model for the formula provides a joint strategy for a given honest history of an EFG (Section 4.1).We present our first-order formalization piecewise, as constraints on such models, imposing among others that models must form a joint strategy, the joint strategy should result in a given honest history, and user-supplied assumptions should be considered (Section 4.2-Section 4.4).We consider the game utilities to be symbolic terms evaluated over pairs of real values, as mentioned in Section 3.1.We therefore universally quantify their symbolic variables in our encoding.As before, EFG Γ = ( , ) is arbitrarily fixed.

Joint Strategies and Honest Histories
A joint strategy for an EFG Γ = ( , ) selects exactly one action for each internal node of the tree.We introduce Boolean action variables  ℎ  to indicate whether at non-terminal history ℎ a player chooses action , and constrain these variables  ℎ  so that exactly one variable is assigned for each ℎ.We thus have .
( strat ) Constraint (ALO) ensures that each non-terminal history ℎ has at least one action variable set.The at-most-one constraint (AMO) [28] ensures that no more than one  ℎ  is set.Our next lemma then concludes that a model I of  strat uniquely describes a joint strategy  ∈ S and vice versa.
We start by showing that  is well-defined.Let I ∈ M and define  :=  (I).From I( strat ) = ⊤, it follows that for all ℎ ∈ H \ T , there exists an action  ∈ (ℎ) such that I( ℎ  ) = ⊤ as well as there cannot be two different   ,   ∈ (ℎ) such that I( ℎ   ) = I( ℎ   ) = ⊤.By definition of  , this says exactly that for every ℎ ∈ H \ T , there exists precisely one action  ∈ (ℎ) such that  (ℎ) = .Therefore,  is a function from H \ T to ℎ∈H \T (ℎ) with  (ℎ) ∈ (ℎ) for all ℎ.Hence,  ∈ S .
Lastly, we show the surjectivity of  .We pick an arbitrary  ∈ S and consider I with Since  is a function with  (ℎ) ∈ (ℎ), we know that for all ℎ ∈ H \ T , there exists exactly one  ∈ (ℎ) such that I( ℎ  ) = ⊤.Therefore, I is a model of  strat and I ∈ M. We conclude  is surjective and thus a well-defined bijection.□ Lemma 4.1 is the crux of our work, reducing game-theoretic security analysis to satisfiability modulo first-order linear real arithmetic: game-theoretic security holds iff first-order formulas describing security properties are satisfiable.In what follows, we introduce the first-order formulas capturing game-theoretic security, which then together with Lemma 4.1 enable the automation of (dis)proving game-theoretic security (Section 5).To this end, we extend honest histories and hence further constrain EFG joint strategies.We do so by ensuring that all action variables in the honest history are set.That is, for an honest history ℎ * = ( 1 , . . .,   ), we obtain Consider the Simplified Closing Game with honest history ( ℎ , ).From  strat and  hist , we obtain the following constraints on action variables: ∧

Weak and Weaker Immunity
A joint strategy is weak immune ( wi ) if the utility of each player following the strategy is non-negative, no matter how other players behave.For each possible terminal history, we thus need to ensure that if a player takes the corresponding actions, the resulting utility for the player is greater than or equal to 0. The set of non-terminal histories leading to a terminal history  where it is the turn of player  is H   , as defined in Definition 3.3.We then formalize weak immunity as Moreover, we express weaker immunity ( weri ) as To ensure that models of  wi and  weri yield weak(er) immune joint strategies of our EFG Γ, we respectively combine the constraints  strat and  hist with  wi and  weri .
Example 4.3.In order to find a weak immune joint strategy for the Simplified Closing Game, we add the following formula to the constraints from Example 4.2: Note that the first constraint for player  does not contain an implication.This is because player  does not make a choice at terminal history ( ) and consequently, the empty antecedent is omitted.If we consider the honest history ( ℎ , ), we can simplify the formula by  hist and propositional reasoning, but weak immunity does not hold as the constraint  ∅  ℎ → − ≥ 0 is not satisfied for  > 0. When in turn checking for weaker immunity, we can disregard infinitesimal terms, so the constraints from  weri simplify to: Constraints for .

Collusion Resilience
Within a collusion resilient joint strategy, no subgroup of players benefits when deviating from the honest behavior ( cr ).We thus need to ensure that all possible deviations of a group of players receive total utility less than that obtained by honest behavior.Hence, our formalization in this respect needs to include only the action variables of the players that do not belong to the deviating subgroup, as these are the players whose choices are in accordance with the desired joint strategy.For an honest history ℎ * , we formalize collusion resilience as: Example 4.4.Collusion resilience of the Simplified Closing Game is captured by: Since the game has only two players, the two singleton sets of players are the only strict subgroups of players.If we consider the honest history ( ℎ , ), we set the action variables . The resulting formula is satisfied for all possible values of , ,  and  that satisfy the initial conditions.Hence, the Simplified Closing Game is collusion resilient.
Example 4.5.We also illustrate how our work disproves collusion resilience using the Simplified Routing Game with the honest history (  , , , , ,  ,  ,  ,  ).For the subgroup { 1 ,  3 } and the terminal history (  , , , , ,  ,   1 ,  ), we get the following implication as an instance of  cr : All action variables are set to ⊤ as they are part of the honest history.
As  >  > 0, the formula is not satisfiable.The Simplified Routing Game is thus not collusion resilient as players  1 and  3 can collude profitably.

Practicality
In practical joint strategies, no player has an incentive to deviate in any subgame ( pr ).Thus, we need to inspect deviations from a joint strategy in a subgame starting from some history ℎ, so we write H  |ℎ, to denote H   in the subgame ℎ.As already presented in [31], a practical strategy can be constructed iteratively bottom-up: at every internal node, assuming we have a practical strategy (and thus utility) for its subgames, we can choose the action that yields the best utility for the current player.Using this idea, we formalize practicality as follows: (  ) The formula first quantifies (as a conjunction) over all subgames, represented by non-terminal histories ℎ, and then over terminal histories in the subgames starting at ℎ.We read the implication as follows: the terminal history  is the one that the practical strategy yields, as on the left-hand side of the implication all of  's actions are asserted.On the right-hand side of the implication it is required that the utility at  of the current player (at history ℎ) is better than the utilities from the practical strategies of other children (note that for terminal history  we do not require the first action to be asserted, but only the actions in the child subgame).

AUTOMATED REASONING OF GAME-THEORETIC SECURITY
The first-order formulas of Section 4, combined with Lemma 4.1, provide us with the theoretical foundations for automating security analysis of blockchain protocols presented as EFG trees.We now present our algorithmic advancement on top of satisfiability checking modulo linear real arithmetic (Algorithm 1), allowing us to (dis)prove formulas from Section 4 and hence provide game-theoretic security guarantees.Further, our work yields natural extensions for generating concrete counterexamples whenever security properties are violated (Section 5.2) and infer preconditions to enforce security (Algorithm 3).
For proving the security formulas of Section 4, we focus on automating reasoning about a tuple Π = (Γ, O, inf , ,  wi ,  weri ,  cr ,  pr ), where • Γ is an EFG modeling the protocol of interest; • O ⊆ T is a set of honest histories representing expected behavior; • inf is a set of infinitesimals occurring in the players' utilities; •  is the set of initial constraints on variables occurring in player utilities; •  wi ,  weri ,  cr , and  pr are sets of constraints on variables to hold when checking formulas of Section 4, namely weak immunity ( wi ), weaker immunity ( weri ), collusion resilience ( cr ) and practicality ( pr ), respectively.
Note that the sets ,  wi ,  weri ,  cr and  pr may possibly be empty.
For every honest history in O, our work constructs the respective first-order security formula of Section 4 and uses SMT solving for establishing satisfiability of the respective formula: if a model is found, we construct a joint strategy as described in Lemma 4.1.
Since security properties must hold for all possible values of the utility variables that adhere to the initial conditions , we universally quantify over all variables and add an implication to account for preconditions.We hence translate game-theoretic analysis from Section 4 into the satisfiability solving of ∀ì  .
We next detail our solution towards solving (3), yielding our automated reasoning approach to prove game-theoretic security in Algorithm 1.

Security Reasoning with Case Splitting
We note that formula (3) is too restrictive, as next illustrated.
Example 5.1 (Splits wi ).Consider the EFG of Figure 3 with  = {, } and honest history (), where  > 0. We aim to find a weak immune strategy for this game.Clearly,  must take action , but if  deviates,  must have non-negative utility.The action of  depends on : if  > 0,  should choose  ; if  < 0,  should be chosen; and otherwise, either choice is possible.The game is therefore weak immune for history (), but requires different strategies for different cases.
Example 5.1 shows that during security analysis, we may need to consider several different orderings of linear terms within utilities.Such case splits turn out to be also necessary for real-world protocols, such as the Closing Game [31].In order to account for possible case splits, we modify (3) and introduce preconditions to order terms.To this end, we compute the set   of linear terms appearing in the constructed formulas; for example, for collusion resilience we have: We then consider all consistent total orders ⪯ over   .As we must find models for all such orders ⪯, we reduce solving (3) to solving ∀ (⪯,  ) total order.∃ I ∈ I.
where quantification over total orders ⪯ happens outside SMT solving (see Remark 1) and ⪯ is interpreted as the set of ordering constraints over elements of  , representing the total order it yields.We conclude the following result.
Note that every model I of (5) translates to a strategy  in ( 6) and vice versa, by letting  (ℎ) =  iff I( ℎ  ) = ⊤.The above theorem yields the following result.

Corollary 5.3 (Soundness and Completeness of Encoding).
The encoding of the game-theoretic properties weak immunity, weaker immunity, collusion resilience and practicality using the formulas  strat ,  hist together with  wi ,  weri ,  cr and   , respectively, including case splits (6), is sound and complete.
Note that our first-order formulas encoding game-theoretic security properties are expressed in the decidable theory of first-order linear real arithmetic [6], [16].Since the number of total orders in ( 5) is finite, our formalization is decidable.
Remark 1.For efficient handling of (5), we compute unsatisfiable (unsat) cores to detect which linear terms require case splitting.We introduce labels for inequalities appearing in the formula  sp -one of  wi ,  weri ,  cr or   .For example, if  sp contains  < , we introduce a label ℓ (,) as a new Boolean variable2 , replace the inequality with the implication ℓ (,) →  < , and add ℓ (,) to our encoding.The weak immunity formula  wi then becomes and similarly for  weri ,  cr and   (see [4]).If unsatisfiability of the formula is established, we extract an unsat core composed of our labels and retrieve candidate linear terms for case splits.Example 5.1 yields an unsat core composed of labels ℓ 0,− and ℓ ,0 , from which we conclude that the following three cases need to be analyzed:  > 0,  = 0 and  < 0. Yet, even for a small number of linear terms, there might be a very large number of possible orderings ⪯ between terms to be considered.The number of ⪯ can however be significantly reduced by making two observations: (i) orderings ⪯ must be compatible with  and  sp ; and (ii) orderings must be consistent with real arithmetic.For example, with the set of linear terms , −, 0, we should consider  > 0 > −, − > 0 > , and  = − = 0, but not e.g. > − > 0 or  = 0 > −.
Based on the above, Algorithm 1 summarizes our reasoning approach for proving game-theoretic security properties based on our first-order formalization with case splits.Given an input Π, Algorithm 1 establishes satisfiability of a game-theoretic property (cf.Lemma 4.1), by using an auxiliary SMT solver A to track (remaining) possible terms orderings.If at any point A reports unsatisfiability, there are no more possible orderings ⪯.Constraints  and  sp are added immediately to A. To get an ordering, we ask A for a modelwhich maps real variables to numeric values -from which we infer an ordering ⪯ on linear terms over variables (EvaluateModel).For example, if the model is  = 1,  = 2,  = 3, we obtain the ordering on linear terms 2 −  >  +  =  > 0 >  − .If we find a strategy for a case split, we add a conflict clause to ensure we do not consider the same ordering twice.
We note that in Algorithm 1 the only properties considered are weak(er) immunity, collusion resilience and practicality; these properties are enough to enforce game-theoretic security (Definition 3.9).

Generating Counterexamples to Security
In case there is no joint strategy fulfilling the security property  sp within Algorithm 1, our work provides automated formal analysis explaning why the conditions of  sp are violated and derives concrete counterexamples to security.
Weak(er) Immunity.For the weak(er) immunity property  wi , a counterexample is a harmed player  together with a partial strategy of the other players  −  such that -while following the honest history -no matter how  acts, they cannot avoid receiving a realvalued negative utility.We say that a strategy for a player  follows the honest history ℎ * if at every node appearing in ℎ * , where  is making a choice, the strategy will choose the action in ℎ * .
Definition 5.4 (Counterexamples of Weak(er) Immunity).Let Γ be an EFG and ℎ * the considered honest history.A counterexample to ℎ * being weak(er) immune is a player  together with a partial strategy   − ⊆   − ∈ S  − of the other players such that   − extended by any strategy   of player , which follows the honest history ℎ * , yields a terminal history  and it is minimal with that property.Further, we have for weak immunity (wi), and respectively

) for weaker immunity (weri).
Minimality of the partial strategy   − states that, if any information point   − (ℎ) =  is removed, there exists a strategy   of player  such that the tuple (  ,  ′  − ) does not yield a terminal history, where the  ′  − is   − without action .That means, when following only actions of (  ,  ′  − ), we get stuck at an internal node of the tree.
Example 5.5.The Simplified Closing Game of Figure 1 with honest history ( ℎ , ) is not weak immune.The counterexample is the player  and the partial strategy for player  taking action  after  ℎ (and therefore making the utility of  negative).The partial strategy is minimal, because if we remove the choice of action  for player , after  chooses action  ℎ , we get stuck at the internal node of the game (where  is making a choice), rather than ending in a leaf node, where the utilities of players are known.Note that the partial strategy says nothing about the tree in the subgame after , as we only consider strategies where player  chooses  ℎ at the root node, to follow the honest history.
Collusion Resilience.A counterexample to collusion resilience  cr consists of a group of deviating players  and their partial strategy   ∈ S leading to better-than-honest joint utility for , no matter how the other players  −  react -while following the honest history.

Definition 5.6 (Counterexamples Collusion Resilience).
Let Γ be an EFG and ℎ * the considered honest history.A counterexample to ℎ * being collusion resilient (cr) is a set of deviating players  together with their partial strategy   ⊆   ∈ S  such that   extended by any strategy   − of players  − , which follows the honest history ℎ * , yields a terminal history  and it is minimal with that property.Further, The minimality of   is similar to the minimality of the partial strategy for weak(er) immunity.
Example 5.7.In the Simplified Routing Game of Figure 2, the terminal history (  , , , , ,  ,   1 ,  ) results in a strictly better outcome for the subgroup { 1 ,  3 , } than the honest history, modeling the Wormhole attack (see Section 2).While choosing the honest actions  and , the other players  and  2 are powerless in this scenario.
Practicality.Intuitively, a counterexample to practicality of ℎ * has to provide a reason why a rational player would not follow ℎ * .That is, somewhere along ℎ * , assume after a prefix ℎ, there exists an action  which promises the current player  (ℎ) a strictly better utility than ℎ * .However, a "promised" utility has to be one that results from a practical history  in the subgame after (ℎ, ), otherwise it would not be an actual counterexample to the practicality of ℎ * .Therefore, we define a counterexample to practicality as follows.
Example 5.9.The Simplified Closing Game of Figure 1 with honest history ( ) is not practical.The counterexample is the terminal history ( ℎ , ), that deviates from the honest history already at the root of the game tree.Choosing the action  in the subgame after history ( ℎ ) is practical, as it yields a better utility () for player  than action  (which gives −).At the root it is therefore better for player  to choose action  ℎ over the honest action  , as  ℎ gives utility , which is strictly better than  −  given by  .The history ( ℎ , ) is therefore a valid counterexample to practicality of honest history ( ).

Correctness of Counterexamples.
The various counterexamples to security properties, as introduced above, are evidence for a violated security property, as stated below.
Theorem 5.10 (Counterexamples to Security).For an EFG Γ and an honest history ℎ * , there exists a counterexample to wi, weri, cr or pr of ℎ * according to Definition 5.4-Definition 5.8 iff ℎ * is not weak(er) immune, collusion resilient or practical, respectively.
Computing Counterexamples to  wi ,  weri and  cr .Within our work, we find counterexamples to (violated)  wi ,  weri and  cr using an approach similar to case splitting over term orderings.We first amend formulas  wi ,  weri and  cr with suitable labels.This allows us to detect at which histories the checked property is violated and for which player(s), by inspecting labels in the reasoning core.Each history reflects one choice in the counterexample strategy.For the purpose of counterexample generation, the formula for weak immunity  wi is then rewritten as follows: Formulas  weri and  cr are adjusted analogously and can be found in [4].
We generate counterexamples to  wi ,  weri and  cr by enumerating minimal unsat cores [20].From these unsat cores, (groups of) players and partial strategies are identified, yielding counterexamples to the respective security property.Each unsat core represents a counterexample; thus, by listing and interpreting all unsat cores, we generate all counterexamples to  wi ,  weri and  cr .
Computing Counterexamples to   Generating counterexamples to   is summarized in Algorithm 2, requiring a different approach than for  wi ,  weri and  cr .
Algorithm 2: Counterexamples to Practicality input : an input instance Π = (Γ, O, inf , ,  wi ,  weri ,  cr ,  pr ), an honest history ℎ  ∈ O and the case case for which practicality failed output : the set of all counterexamples  to the practicality of ℎ  in a subcase of case, together with that subcase subcase Algorithm 2 takes as input a game Γ, an honest history ℎ  and the case of term orderings for which practicality analysis failed.Algorithm 2 returns a set of counterexamples (CE) to   , that is, a set of terminal histories, and a subcase of the initial case.Note that the set CE contains all the counterexamples to   in the given refined problematic case.In each iteration of the while-loop of Algorithm 2 (lines 6-25), all practical that yield a strictly better utility for the deviator are listed, then the game tree is cut such that new counterexamples can be revealed (line 7).The variables GT (current game tree), ℎ (guidance on what to cut) and  (subgame to be considered) keep track of the cutting and ensure that the correct terminal histories are added to CE.Additionally, it might be necessary to further specify the ordering of the utility terms, which is considered in line 16 of Algorithm 2.
Based on the above considerations, all counterexamples to practicality for a specific term ordering are thus generated via Algorithm 2, as proven next.Theorem 5.11 (Correctness of Algorithm 2).Consider the output (CE, subcase) of Algorithm 2.Then, the set CE computed by Algorithm 2 contains exactly all counterexamples to ℎ * being practical in subcase.
Proof.(i) We first prove that  ∈ CE implies  is a counterexample in subcase.Let the honest history be ℎ * and  ∈ CE.Assuming subcase, we show that  is of the form (prefix, , ℎ ′′ ), where prefix is the maximal common prefix of  with ℎ * ,  an action such that   (prefix) (ℎ * ) <   (prefix) () and ℎ ′′ practical in Γ | (prefix,) .
Note that in every iteration of the loop ho is a suffix of ℎ * , as only prefixes ℎ of ℎ * are cut off (line 11, 14, and 21).Further, subcase is a subcase of subcase, since subcase is only refined in the algorithm (line 16).The game GT is the subgame of Γ after subgame, possibly without some already removed direct subtrees.This holds as we always consider subgames after ℎ (line 24), which are pieces of ℎ * and are collected in  (line 22).The direct subtree removal happens in line 23 of Algorithm 2. We hence conclude that Additionally,  is a terminal history of the input game Γ.The property left to show is that ℎ ′ = (, ℎ ′′ ), such that ℎ ′′ is practical in Γ | (subgame,) .Note that only direct subtrees of Γ |subgame have been removed in GT, hence GT | () = Γ | (subgame,) .Since ℎ ′ = (, ℎ ′′ ) is practical in GT, ℎ ′′ has to be practical in GT | = Γ | (subgame,) in subcase.Therefore,  is a counterexample in subcase and thus also in subcase, concluding direction (i) of the proof.
(ii) We next show the reverse direction of (i); that is,  is a counterexample in subcase implies  ∈ CE.Let  be the set of all counterexamples in the case subcase.As subcase does not necessarily yield a total order on the utility terms, we fix an arbitrary total order ≤  on the utility terms which is compatible with subcase.We now order elements  ∈  according to (1) length of the common prefix ℎ of  with the honest history ℎ * (shortest first) and within this group into (2) subgroups according to the value   (ℎ) () (decreasingly).
In Algorithm 2, every  ∈ CE occurs once in prStrat 3 as the element with the shortest common prefix with ℎ * .This holds as we always remove at least one direct subtree or move further along ℎ * .Let us now consider the last occurrence of  ′ in prStrat.In this iteration, the tree GT will be cut to at most Γ |ℎ −{ ′ :  ′ = (ℎ,  ′ ,  ′ )}.Since all counterexamples  ′′ with the same prefix ℎ as  and with greater utilities   (ℎ) ( ′′ ) >    (ℎ) () have been found in CE, the corresponding branches are removed from GT in the following iterations of Algorithm 2 as well.
Therefore, (, ) of  = (ℎ, , ) is practical in this tree, implying that (, ) has to appear in prStrat in the next iteration and hence also  ∈ .This contradicts the assumption of Case 1. Case 2: (, ) is practical in Γ |ℎ in ≤  , yielding two further cases.Case 2.1:  = (ℎ, , ) is in the first group , that is, there is no counterexample with a shorter prefix.In this case,  = (ℎ, , ) has to be practical in Γ in ≤  .By assuming the contrary, there exists a counterexample  ′ = (ℎ ′ ,  ′ ,  ′ ), where ℎ ′ is a prefix of ,  ′ is practical in Γ | (ℎ ′ , ′ ) in ≤  , and   (ℎ ′ ) () <    (ℎ ′ ) ( ′ ).Then, ℎ ′ cannot be a prefix of ℎ, as this contradicts  being in the first group of .Further, ℎ can not be a prefix of ℎ ′ , since this contradicts the fact that (, ) is practical in Γ |ℎ in ≤  .Therefore,  is practical in Γ in ≤  , implying however that  has to occur in the first iteration of the loop in prStrat (being practical in subcase).Another case is not possible (similar to Case 1) as a further case split of subcase did not happen.Case 2.2:  = (ℎ, , ) is not in the first group in .Let then ℎ ′ be the maximal common prefix with ℎ * in the group directly before .All the counterexamples  ′ of this group have   (ℎ ′ ) ( ′ ) >   (ℎ ′ ) (ℎ * ).Similar to Case 1, as they all appear in CE, we reach the following tree to be considered: Γ |ℎ ′ minus all the immediate dishonest branches that contain counterexamples.In the subsequent iteration of the algorithm, prStrat has to be empty as there are no more branches that make the condition   (ℎ ′ ) ( ′ ) >   (ℎ ′ ) (ℎ * ) true.Therefore, we go to the if-branch in line 9 and consider Γ | (ℎ ′ , * ) in the following iteration.The action  * is the next action in ℎ * after ℎ ′ .Note that for the tree Γ | (ℎ ′ , * ) ,  is in the first group of counterexamples by construction.Therefore, Case 2.1 applies for the game Γ |ℎ ′ , * , thus counterexample  has to be practical in Γ | (ℎ ′ , * ) 3 only the respective suffix of  occurs since we add the subgame prefix only later to

CE.
and hence has to occur in prStrat in this iteration.This contradicts the assumption that  ∉ CE and overall concludes direction (ii) of the proof.□

Inferring Preconditions for Security
In addition to identifying concrete counterexamples (Section 5.2) in case a security property  sp is not satisfied in Algorithm 1, our work can also determine additional assumptions necessary to ensure that property  sp holds.We support such an extended security analysis by iteratively computing preconditions for the input EFG.
Definition 5.12 (Preconditions to Security).Given a game Γ, an honest history ℎ * , a security property sp and initial conditions  and  sp such that ℎ * violates sp, we say  is a precondition if ∀ (⪯,  ) total order.∃ I ∈ I.
We note that in Definition 5.12, the precondition  strengthens the initial constraints by making the left-hand side of the above implication satisfiable for less total orders, thus ensuring validity of the above implication for more of them.
In Algorithm 3, we show our adjustment of Algorithm 1, allowing us to generate the weakest precondition under which a security property sp is satisfied.If precondition generation is enabled in our work, the solving routine at line 16 in Algorithm 1 does not terminate; instead, it adds the negation of the ordering in the unsolved case  to preconditions in  (the variable pre in line 20 of Algorithm 3) and restarts the solving routine with the new set of initial constraints.With such an adjustment of Algorithm 1, Algorithm 3 allows us to generate weakest preconditions to sp, in the following sense: if  and  are preconditions, then  is weaker than  if is satisfiable for more total orders ⪯ than For proving correctness of Algorithm 3, we first prove the following helping lemma.Lemma 5.13.[Unique Weakest Precondition] Given a game Γ, an honest history ℎ * , a security property sp and finite sets of initial constraints  and  sp , there exists a unique (modulo equivalence) weakest precondition  to make history ℎ * satisfy sp.
Proof.Let  be a precondition, by Definition 5.12, it holds that ∀ (⪯,  ) total order.∃ I ∈ I.
As noted after Corollary 5.3, the satisfiability of the formula depends only on the finitely many total orders of terms in   .Thus, any precondition can be weakened to a list of term orderings to be avoided, which are finitely many.The weakest of these is the one that allows precisely all total orderings of terms in   that are satisfiable and forbids all others, and is thus unique up to equivalence (as a quantifier-free first-order formula can be expressed in many equivalent ways).□ We next proceed with proving correctness of Algorithm 3.
Theorem 5.14 (Weakest Preconditions -Correctness of Algorithm 3).Given a game Γ, an honest history ℎ * and a security property sp that ℎ * violates, Algorithm 3 generates the weakest precondition  which makes ℎ * satisfy sp.
Proof.As Algorithm 3 adjusts Algorithm 1, we only prove that whenever Algorithm 3 terminates (which it does, because we only need to consider finitely many total orders of   ), the generated precondition  (i) is indeed a precondition and (ii) is the weakest.
(i) By construction,  is a conjunction of negated term orderings: Let us write ¬  for  ∈O  ¬ .By construction, we leave out only the term orderings for which the security property holds (line 11 in the Algorithm 3), and hence  is a precondition.
(ii) Let  be the weakest precondition given by Lemma 5.13.Towards a contradiction, assume that  is strictly weaker than ; that is, there exists a total order ⪯ such that is satisfiable and is unsatisfiable.Let  be a model for ì  that satisfies (10).Since  does not satisfy (11), we know that  () = ⊥.Let   be the first ordering in the conjunction  such that  (¬  ) = ⊥.Consider line 20 of Algorithm 3 at the point when ¬  was added to the precondition : the else case of the condition of line 11 implies that the security property is not satisfied in the case   ; further, line 19 implies that there are no more comparisons to be added.As such, for every total order ⪯  that implies the case   , we have which is equivalent to The inequalities in  sp [ ì ] only depend on the total order ⪯  and not on the actual values of ì .Thus, ∃ì  .
Using (12), we get ) Consider now ⪯  the total order on   induced by the model .Since  (¬  ) = ⊥, we know that  satisfies   , so ⪯  implies   as well and (13) holds for ⪯  too.As  is a precondition, by using Definition 5.12 with ⪯  , we obtain I ′ ∈ I such that ∀ì  .
With the model  for ì , the antecedent of the implication in ( 14) holds as  satisfies (10) (and thus satisfies the constraints in ,  sp and  ).Thus, I ′  strat ∧  hist ∧  sp [ ( ì )] holds.With the model  for ì , the antecedent of the implication in ( 15) is also valid, yielding ¬ I ′  strat ∧  hist ∧  sp [ ( ì )] .We thus obtained a contradiction, concluding the proof.□ Example 5.15.The weak immunity property  wi of the game from Example 5.1 for honest history (,  ) is not satisfied if  < 0. Our work identifies this case and reports that there is no weak immune joint strategy given that  < 0. The solving routine of Algorithm 1 is restarted with  ≥ 0 added to  in Algorithm 3, triggering the satisfiability of the such revised weak immunity property  wi .In this case, Algorithm 3 returns one additional precondition, namely  ≥ 0.
We conclude this section by noting that finding sufficient (nontrivial) preconditions to satisfy a security property  sp is not always possible with Algorithm 3: if the existing preconditions  imply the ordering  for which there is no adequate joint strategy, the security property  sp cannot be satisfied by adding more assumptions about the EFG utilities.In this case, the weakest precondition returned by Algorithm 3 is ⊥.

IMPLEMENTATION AND EXPERIMENTAL EVALUATION
Implementation.We implemented our game-theoretic security analysis in the new CheckMate tool 4 , written in Python and using Z3 [7] as the underlying SMT solver of Algorithm 1.The input for CheckMate is a JSON [14] encoding of an input instance Π of Algorithm 1, which is also the current representation language for the EFG.The instance Π is parsed into an internal representation, which is used to construct SMT constraints for (any subset of) the security properties presented in Section 4. CheckMate then executes Algorithm 1 for each property, logging intermediate results such as case splits.CheckMate outputs a joint strategy if a property is satisfied, or a list of counterexamples otherwise; in the latter case, CheckMate also produces preconditions (Section 5.3).In addition, CheckMate supports a verification mode to check whether a joint strategy satisfies a security property.CheckMate only supports EFGs with finite game trees.However, EFGs are known to have the capacity to model many protocols.Further, every step in the game can model an arbitrary long time in the protocol (e.g. the "ignore" actions model unlimited time).An advantage of the trees being finite is that the game-theoretic properties will only quantify over finite sets, implying that the respective security properties can be translated to first-order linear real arithmetic (as shown in Section 4).Benchmarks.Among other benchmarks, we evaluated Check-Mate using the examples of Section 2 as well as real-world blockchain protocols from Bitcoin's Lightning Network [30].These examples are listed as the last four entries of Table 1.Namely, we used the complete model of the Closing Game of [31] and the full model of the routing phase corresponding to the Routing Game of [31] with three players.The honest behavior of the full routing game is similar to the Simplified Routing Game, but players have many 4 Our tool is available at https://github.com/apre-group/checkmate. more actions available, such as sharing the secrets or varying the way they lock funds.The full Routing Game for five (and more) players is a task for future work.
As the modeling process of real-world protocols as EFGs is an intricate and time-consuming process, representing a challenge on its own, we so far have a restricted but representative benchmark set, showcasing the logical expressivity provided by CheckMate to efficiently (dis)prove blockchain security.We are not aware of other efforts providing practical challenges for evaluating formal methods in support of blockchain security.We believe our EFG examples provide an initial set of examples to be further used in verifying blockchain security.
Experimental Results.Table 1 summarizes our experimental results, using an Apple M1 Pro CPU with 10 cores and 32 GB of RAM.The sizes of our EFG examples in terms of nodes and players are listed in columns 2-3.For each honest history (column 4), Table 1 displays CheckMate's results for game-theoretic security.We also report execution times for complete analysis of all properties, without counterexample generation.In column 6 (Calls), the number of SMT calls within CheckMate is listed.Both protocol benchmarks (the Closing Game and the 3-Player Routing Game) hint that even for bigger game trees, the number of case splits is relatively low.
Table 2 displays the number of counterexamples found for each violated property, as well as a precondition strong enough to make the respective property true.We write ⊥ to indicate that no precondition (except ⊥) is strong enough to satisfy the property.Thus, the problem is inherent to the game and is not a matter of the variable values.Due to its size, we do not state the nontrivial precondition  of the Pirate Game, generated by CheckMate in 37 seconds.
Experimental Analysis.CheckMate successfully analyzes the games of Section 2 and correctly identifies the Wormhole attack as one of the 16 counterexamples to collusion resilience in the Simplified Routing Game.Applied to the Closing Game, CheckMate terminates after about 17 seconds for each honest history and correctly identifies required case splits for history ( ℎ , ).The Routing Game is not weak immune, but weaker immune: honest players will not lose "real" resources, but may suffer opportunity cost.The 3-player Routing Game has 21,688 nodes, compared to 221 nodes for the Closing Game.
Our experiments demonstrate the usability and scalability of CheckMate.For example, for analyzing real-world applications (closing and routing phases in the last two lines of Table 1), Check-Mate enabled the automation of reasoning about trillions of game strategies and thousands of game nodes.We are not aware of other automated reasoning approaches handling such and similar EFGs.
The mostly trivial preconditions in Table 2 are not surprising, since we asserted constraints we were aware of as initial conditions.For the Closing Game and history ( ℎ , ), for example, we inherited initial constraints ,  ≥  for weak immunity and  ≠   for practicality from [31].When removing those constraints, CheckMate finds a precondition equivalent to ,  ≥  for weak immunity and one equivalent to  ≠   ∨  −   +   =  for practicality.Thus, CheckMate provides a less restrictive but still sufficient precondition than [31].

RELATED WORK
Game theory opens up new venues in security and privacy analysis [8], particularly within blockchain technologies [21].Gametheoretic modeling approaches in support of blockchain security have recently emerged [31,36], complemented by specific analysis of several attack vectors, such as the griefing attack [24].Our work complements these efforts as we express game-theoretic security in first-order linear real arithmetic and turn protocol security into an SMT-solving problem.Extended with game-theoretic case splitting and counterexample generation, we scale game-theoretic security to large protocols and fully automate it.Our work is thus orthogonal to [31].The work of [5] focuses on game-theoretic security specific to the Ethereum blockchain [35], but does not reason about punishment mechanisms.While these works provide rigorous game-theoretic models, they lack support for automated reasoning, hindering their scalability and computer-aided certification.
Focusing on formal verification for security, the Tamarin [26], Verifpal [17], and Proverif [3] frameworks study general protocols, while the Verisol approach targets the Ethereum blockchain [34].These methods operate on cryptographic security properties, proving whether certain actions are cryptographically possible.Our work complements these techniques by analyzing and establishing whether punishment mechanisms work as intended.
A similar line of research is analysis of cryptographic security properties in rational cryptography [1,12,13,15,22].Rational cryptography does not assume players to be inherently honest or malicious, but instead rational.However, rational cryptography verifies cryptographic alignment of rationality and honesty, whereas our work in CheckMate focuses on incentive/punishment mechanisms modeled via games.
Another game-theoretic security reasoning framework is introduced by [18,19].Here, concurrent stochastic game structures (CGSs) are modeled within probabilistic asynchronous-time temporal logic with rewards (rPATL).The respective CGS are verified via model-checking of PATL formulas.Unlike this framework, our work does not reason with uncertainty.Instead, we provide a decidable first-order logic fragment for proving game-theoretic security.Thanks to our logical precision, we can avoid the computational burden of handling probability (reward) operators.Our EFGs also avoid concurrent game strategies and provide a deterministic game structure.
When it comes to automated game-theoretic analysis, it is worth noting the modeling and verification support offered by Gambit [25], PRISM-games [18] and Open Games [11].These frameworks, however, are restricted to constant numeric utilities and cannot process symbolic utilities, limiting their applicability to reason about all game actions/strategies.We are not aware of other game-theoretic frameworks that natively support symbolic utilities, which is a key feature of CheckMate.Compositional reasoning in Open Games [11] does enable modular analysis, which we aim to further investigate in order to split large EFGs (such as routing games) into subgames.

CONCLUSION AND DISCUSSION
Game-theoretic security analysis provides new ways to derive security guarantees and identify attack vectors.Yet, automation in this area was so far limited, if at all, hindering the applicability and scalability of game-theoretic security analysis.Our work addresses these obstacles and implements novel methods for deciding security properties in games with symbolic utilities.We reduce security analysis to satisfiability solving over game strategies expressed in first-order theory of linear arithmetic.We provide full automation of within the new CheckMate framework, scaling security analysis to very large game trees, by automatically identifying necessary case splits for efficient reasoning.In addition, CheckMate supports the generation of counterexamples and necessary preconditions to security, enabling model repair and synthesis of game properties.
Limitations and Challenges for Future Work.Modeling protocols requires considerable expertise, and the precision of our analysis depends on the accuracy of the underlying model.To maximize application of the CheckMate framework, we must provide ways to accurately and efficiently model protocols as EFGs.Partial automation of the EFG modeling process is therefore a valuable task to be addressed further.
Currently, CheckMate only supports linear utilities.However, protocols exist that naturally involve nonlinear terms over utilities.For example, ratios in market settings produce terms containing multiplication of two variables.While CheckMate internally already supports nonlinear arithmetic formulas over utilities, it comes with the caveat that the resulting SMT queries are also nonlinear and therefore significantly harder.Improving the performance of SMT solving over nonlinear arithmetic in the setting of Check-Mate is its own challenge, which we aim to address in the future.
Finally, extending CheckMate with compositional game analysis is another direction we are already investigating.We believe compositionality may enable us to support randomized game aspects, for example model behavior that is not controllable by any player.In addition, compositional game analysis might ease modeling further real-world protocols as EFGs.

Lemma 4 . 1 (
Model-Strategy Translation).Consider the EFG Γ with joint strategies S .Let M be models of the formula  strat .Then,  : M → S , where
Definition 3.3 (EFG Properties).Let Γ = ( , ) be an EFG.Joint Strategy A joint strategy  is a function mapping every non-terminal history ℎ ∈ H \ T to an action  ∈ (ℎ).The set of joint strategies is S .Single Strategy A strategy   ∈ S  of player  is a function mapping non-terminal histories ℎ ∈ H \ T with  (ℎ) =  to an action  ∈ (ℎ).Similarly, a group of players  ⊂  may have a strategy   ∈ S  .Strategy Deviation If player  deviates from a joint strategy  ∈ S with another strategy   ∈ S  , the resulting joint strategy is denoted  [  /  ].Similarly, for a deviating group of players  ⊂  , we write  [  /  ].  (), we define   (ℎ) :=   ().Subgames Subgames Γ |ℎ of Γ are formed from the same set  of players and a subtree of , and are therefore identified by a history ℎ leading to the subtree  |ℎ .Histories H |ℎ of Γ |ℎ are histories in H with prefix ℎ, and similarly for the utility function  |ℎ and strategies  |ℎ ∈ S |ℎ .In Figure1, a joint strategy  could be player  taking action  initially, with player  taking  after ( ℎ ) and  after ().Player 's single strategy   takes action  initially.Player  receives   () = .The history resulting from  is ( ), and  is a strategy extending history ( ).The subgame for history ( ℎ ) has players  = {, } and has a tree where player  must choose between action  with utility (−, −) and action  with utility (, ).
).A joint strategy  ∈ S in EFG Γ is weak immune if all players  that follow  always receive non-negative utility: Definition 3.6 (Weaker Immunity).A joint strategy  in EFG Γ is weaker immune if all players  that follow  always receive at least ( [  /  ]) .

Table 2 :
Counterexample (CE) and Precondition (PC) analysis provided by CheckMate.> indicates that we found  counterexamples in 10 minutes, but generation has not terminated yet.The practicality result (*) for 3-player Routing is computationally demanding, but begins to produce results after the time limit.At around 60 minutes, we have over 100 counterexamples.TO indicates a timeout after 2 hours.