Certifying Findel Derivatives for Blockchain
CCertifying Findel Derivatives for Blockchain
Andrei Arusoaie
Alexandru Ioan Cuza University of Ia¸si [email protected]
Abstract
Derivatives are a special type of financial contracts used to hedge risks or to spec-ulate on the market fluctuations. In order to avoid ambiguities and misinterpre-tations, several domain specific languages (DSLs) for specifying such derivativeshave been proposed. The recent development of the blockchain technologies en-ables the automatic execution of financial derivatives. Once deployed on theblockchain, a derivative cannot be modified. Therefore, more caution should betaken in order to avoid undesired situations.In this paper, we address the formal verification of financial derivatives writ-ten in a DSL for blockchain, called Findel. We identify a list of properties that,once proved, they exclude several security vulnerabilities (e.g., immutable bugs,money losses). We develop an infrastructure that provides means to interac-tively formalize and prove such properties. To provide a higher confidence, wealso generate proof certificates. We use our infrastructure to certify non-trivialexamples that cover the most common types of derivatives (forwards/futures,swaps, options).
Keywords: financial derivatives, certification, blockchain, smart contracts, Coq, Findel
1. Introduction
Financial derivatives [1, 2, 3, 4] play an important role in finance. A financialderivative is a contract between two or more parties whose value is based onunderlying financial assets (e.g., bonds, commodities, etc.). The term derivative captures the idea that the contract derives its value from fluctuations in theunderlying asset. For instance, a car insurance contract derives its value froman insurance index and related events (e.g., an accident may change its value).Derivatives are often used to express complex agreements. Suppose thatJohn is a cereal manufacturer and Tom is a farmer who produces wheat andcorn. Since the price of cereals fluctuates a lot, John believes that it would be avery good idea to have an agreement with Tom at the beginning of the year: hecomputes a convenient price and makes an offer to Tom for buying his productsin advance. If Tom agrees, then John will not be affected by a rise in the priceat the end of the year. If the price drops, then Tom will have an advantage.
Preprint submitted to Elsevier May 29, 2020 a r X i v : . [ c s . L O ] M a y hould John and Tom decide to accept this agreement, they can make accuratepredictions for the future.Typically, financial derivatives are expressed using natural language on awritten document which is authorized by a trusted third party. However, naturallanguage is often ambiguous and lacks precision. This might cause disputesbetween the parties involved, even in the presence of a trusted authority. Ethereum Smart Contract for Findel
Ethereum Blockchain Environment
Step 1 : John issues a Findelderivative by calling theEthreum smart contract forFindel
Step 2:
Tom joins
John'sissued derivative through thesame smart contract for Findel
Step 3:
The Findelderivative is executed by mining nodes in theEthereum networkAn Ethereum smart contractmanages Findel derivatives.Users can register , issue, and join Findel derivatives using thefunctionalities exposed by thissmart contract.
Figure 1: Findel derivatives are managed by an Ethereum smart contract [5] implementedin Solidity [6]. Scenario: John issues a derivative using the Ethereum smart contract; thederivative is now available and anyone can join it. Here, Tom joins the derivative issued byJohn through the same smart contract. Tom becomes the owner of the derivative and thederivative is executed by the miners in the network.
Domain Specific Languages for financial derivatives.
In order to avoid disputes,researchers have proposed simple, non-ambiguous, and executable domain spe-cific languages (DSLs) for describing financial derivatives. Jones et al. [7]proposed such a language which was implemented as a combinator library inHaskell. They have defined a minimal and expressive set of primitives , whichare then used to create complex derivatives. An example is
One(EUR) - a primi-tive for transferring one unit of currency (
EUR ) from one party to another. Newderivatives can be created from basic ones: e.g.,
Scale(k, One(EUR)) multi-plies by k the amount to be transferred. Derivatives expressed using primitivesare composable . For example, And( c , c ) processes the derivatives c and c sequentially. Jones et al. [7] were able to compute the value of a derivative bygiving a valuation semantics to their Haskell combinators.Another language in the same family has been proposed by Gaillourdet [8].It uses similar primitives as in Jones et al. [7] and has a denotational semantics.One of the design goals was to enable standard mathematical analysis, i.e., studywhether sequences of payments are consistent with the contract descriptions.The blockchain technology enables automatic processing of financial deriva-tives via smart contracts . In this context, new DSLs for derivatives have emerged:2indel [9], Marlowe [10], and a contract language introduced by Egelund-M¨ulleret al. [11]. Blockchain.
The blockchain technology is used mainly by cryptocurrencies suchas Bitcoin [12]. It involves a peer-to-peer network of nodes that communicatewith the purpose of contributing to a distributed ledger. This ledger is a chainof blocks of transactions. Only a special category of nodes, called miners , con-tribute to the creation of blocks. Their role is to arrange transactions in blocksin a way that requires computing power. Miners receive a reward as incentive.A block is added to the main ledger by a consensus algorithm. The consensusalgorithm ensures that it is not convenient to change the existing ledger, butonly to add new blocks to it. This is why the blockchain is said to be immutable .Various blockchain platforms such as Ethereum [13, 14] or Cardano [15] allowusers to create smart contracts, i.e., programs that typically handle transactionsinvolving cryptocurrency, but they can also encode complex logic like regularprograms. Miners are incentivised by an execution fee.
Vulnerabilities in Findel.
In this paper we focus on Findel, a DSL based on aset of primitives which is very similar with the set proposed by Jones et al. [7]and Gaillourdet [8]. The main difference is that Findel derivatives can be auto-matically executed in Ethereum (Figure 1). Findel can be regarded as a smartcontracts language for financial derivatives. Therefore, Findel inherits severalvulnerabilities of smart contracts. A comprehensive taxonomy of vulnerabilitiesof smart contracts can be found in [16]. We recall here the vulnerabilties thatare relevant for Findel: • Immutable bugs . Due to the immutability of the blockchain, deployedFindel code cannot be modified. This is consistent with the principles ofEthereum, where code is law . If the Findel code contains a bug, there isno direct way to fix it. • Money lost in transfer . When sending money, one has to specify thecorrect recipient address. Money sent to wrong addresses are lost forever. • Time constraints . In Findel, time constraints are part of the language: acontract issuer can specify time intervals when contracts can be joined. Ifan interested owner fails to join in time, then the owner may lose moneyor other contracts.Programming smart contracts is a tricky task and developers need tools toverify whether their programs are more secure. In this context, formal verifica-tion of smart contracts has started to be a very active field [17, 18, 19, 20, 21].Most of the tools based on formal verification focus on verifying general securityproperties of the Ethereum bytecode (e.g., [22]).
Handling vulnerabilities in Findel.
Many vulnerabilities are caused by a mis-alignment between the intuition of the programmer and the semantics of the lan-guage. The main sources of vulnerabilities in Findel are two statements that (1)3llow participants to swap the parties (issuer and owner) and (2) generate newcontracts. We show here a list of properties that, once verified, could excludecertain vulnerabilities (e.g., immutable bugs, money losses) for the derivative inquestion: (CM)
Derivatives should be free of calculation mistakes . This is a typical bug infinancial contracts where mistakes in mathematical formulas could lead towrong amounts of money to be transferred. In the real world, this is canbe corrected. Unfortunately, a bug in a deployed Findel derivative cannotbe fixed at all, due to immutability of the blockchain. (ES)
Errors caused by external sources should be handled properly. Findel al-lows users to retrieve data from external sources using gateways. A simpleexample is a Findel currency exchange contract, where the exchange rateis provided by an external source. Suppose that Charlie wants to ex-change $10 into euros. So, he joins the issued contract and pays the $10.If the external source fails to provide an exchange rate and the Findel codedoes not handle such situations properly, then Charlie receives nothing inexchange, and losses the $10. (AS) Accidental swaps should be avoided. This property ensures that the gener-ated transactions and contracts have the intended issuer and the intendedowner. Although this may seem easy to check, sometimes this is quitedifficult to detect when statements (1) and (2) are combined. In Findel,the execution of a contract is triggered when someone joins an issued con-tract. Moreover, you cannot force someone to join. Suppose that Johnissues c which specifies that: (a) he pays in advance for cereals, and (b) anew contract c with John as issuer is generated (by c ), where c specifiesthat John must receive cereals in exchange. If Tom joins c , then Tomreceives the payment and he is expected to join c . However, if Tom isdishonest and he does not join c , then John never gets the cereals! Theproblem is that the execution of c depends on Tom, and he might not beinterested in joining it. .In this paper we tackle the formal verification of this kind of propertiesfor Findel contracts. We develop an infrastructure implemented in Coq [23] ,that provides means to execute Findel derivatives, and to formalize, prove, andcertify properties about them.Compared to the other formal verification approaches, these are mostly fo-cused on formalizing and proving generic security properties of Ethereum byte-code [18, 21], and only a few actually certify these properties [22, 19].Compared to the other DSLs [7, 8] in the same family as Findel, none ofthem are designed to be executed on the blockchain. They are mostly focused In Section 2.1.1 we discuss this particular issue in detail. The source code is available online: https://github.com/andreiarusoaie/findel-semantics-coq
4n computing derivatives values or performing conformance analyses. Here wefocus is different: we prove properties that make sense when such derivativesare executed in the blockchain.
Contributions.
The contributions of this paper are:1. A formal semantics of Findel in Coq [23].2. An infrastructure that can be used to certify security properties for themost common types of derivatives (futures/forwards, swaps, options).3. A list of examples that highlight the various security properties thatderivatives have. We use our infrastructure to prove these properties.When a proof of a security property cannot be completed, we show howto detect the source of the problem.4. A practical method for developing proofs for complex derivatives. SinceFindel is composable, proofs can be divided into smaller manageablepieces. We show that proofs of complex derivatives can be done by com-posing smaller proofs.
Paper organisation.
Section 2 introduces the syntax and the informal semanticsof Findel from [9]. Section 2.1.1 contains a motivating example and we discusswhat properties are violated by this example. The Coq encoding of Findel isshown in Section 3. Using the Coq semantics we encode several Findel deriva-tives and then we prove their expected properties in Section 4. We also includea credit default swap - a very popular type of derivative - and we show how itsproofs can be developed incrementally in Section 4.5. We conclude in Section 5.
2. Findel: a DSL for financial derivatives
The syntax and the informal semantics of the Findel language are bothdescribed in Biryukov et al. [9]. Details can be found in the implementationavailable at https://github.com/cryptolu/findel . In this section we useboth sources in order to make a complete description of the language. We donot improve Findel here, we only to formalise its existing semantics.A
Findel contract is a tuple with three components: a description , an issuer and an owner . The issuer and the owner are the parties of the given contract.In the implementation, the issuer and the owner are represented as 20-byte val-ues (i.e., size of an Ethereum account address), and contracts have an additionalcomponent called proposed owner which is also a 20-byte value. This new com-ponent is used to propose a specific owner when issuing a new contract. If theproposed owner field is (default value), then anyone can join the contract.A Findel description is essentially a tree with basic primitives as leaves and composite primitives as internal nodes. The list of available primitives and theirinformal semantics is shown in Table 1.
Example 2.1.
And is a primitive that executes two (sub)contracts, c and c ,sequentially. If at least one of them fails then the changes are reverted. Here isa fixed-rate currency exchange derivative in Findel: rimitive Informal semantics Zero
Do nothing.
One( currency ) Transfer 1 unit of currency fromthe issuer to the owner.
Scale( k , c ) Multiply all payments of c by aconstant factor of k . ScaleObs( a , c ) Multiply all payments of c by afactor obtained from address a . Give( c ) Swap parties of c . And( c , c ) Execute c and then c . Or( c , c ) Give the owner the right to executeeither c or c but not both If( a , c , c ) If b is true, execute c , else execute c , with b obtained from address a . Timebound( t , t , c ) Execute c , if the current timestampis within [ t , t ]. Table 1: The informal semantics of Findel [9].
Additional syntax Desugared syntax
At( t , c ) Timebound( t − δ , t + δ , c ),where δ is just a constant usedto handle the imperfect precisionof time signals in the network Before( t , c ) Timebound( now , t , c ) ,where now is the current time After( t , c ) Timebound( t , ∞ , c ) . Table 2: Additional primitives
And(Give(Scale(11, One(USD))),Scale(10, One(EUR))) . To increase the expressivity of Findel, the language is extended with somesugar syntax as shown in Table 2.
Example 2.2.
A zero-coupon bond (ZCB) can be encoded using At : And(Give(Scale(10, One(USD))),At( now +t, Scale(11, One(USD))))
The execution model of a Findel contract is given by these steps [9]:1. The first party issues a contract. This is a mere declaration of the issuer’sdesire to conclude an agreement and entails no obligations.2. The second party joins the contract and becomes its owner. As a conse-quence, both parties accept the specified rights and obligations.3. The contract is executed immediately:(a) Let the current node be the root of the contract description. If thecurrent node is either Or or Timebound with t > now , postpone6he execution: issue a new contract, with the same parties and thecurrent node as root. The owner can demand later its execution.(b) Otherwise, execute all sub-nodes recursively.(c) Delete the contract. Example 2.3.
A step by step execution of the contract in Example 2.1, whereAlice issues and Bob is the owner: Alice issues the contract and Bob joins it, becoming the contract owner: $ e is owner of Alice 100 50 -Bob 20 30
And(Give(Scale(11, One(USD)))Scale(10, One(EUR))) And executes and Bob is now the owner of two (sub)contracts: $ e is owner of Alice 100 50 -Bob 20 30
Give(Scale(11, One(USD)))Scale(10, One(EUR)) Give executes and Alice becomes an owner: $ e is owner of Alice 100 50
Scale(11, One(USD))
Bob 20 30
Scale(10, One(EUR)) Alice receives 11
USD from Bob: $ e is owner of Alice 111 50 -Bob 9 30
Scale(10, One(EUR)) Finally, Bob receives 10
EUR from Alice: $ e is owner of Alice 111 40 -Bob 9 40 -
The implementation of Findel does not enforce any constraints on the bal-ances of the users that prevents them from building up debt.
Findel has several major limitations. First, there is no way to encode repet-itive behavior in contracts - there are no loops. This is a limitation when onewants to specify a contract should be executed repeatedly for 10 years.Second, by design, Findel is not able to express agreements for more thantwo parties. One can access external gateways to simulate multiple parties, butthis is a very limited workaround.
Recall our cereal manufacturer example from Section 1. Suppose that Johnissues the following option derivative (here, wheat is represented by
USD andcorn by
EUR ): 7 PT = ∆ And (cid:0)
Before(t,Or(Give(One USD),Give(One EUR)))After(t+2, Scale(1, (One GBP))) (cid:1)
John wants to acquire a contract before moment t that gives him a later choice(between wheat and corn). He pays back 1 GBP as incentive for eventual ownersafter t+2 . Unfortunately, John issues a contract with bugs.Suppose that a dishonest participant, Mallory, joins the contract and triggersthe execution of
And . First,
Before is executed and its enclosed contract (i.e., Or ) produces a new contract - a future option - whose execution can be triggeredlater by Mallory. Second, the After primitive gets executed, and John will pay1
GBP after moment t+2 .The contract generated by
After has all the aforementioned properties: (CM) , (ES) , and (AS) . Mallory is able to request 1 GBP from John after t+2 ,and John cannot deny or retract from that.Unfortunately, the future option contract generated by Or violates (AS) :because Mallory is the owner of this contract, she decides not to join thatcontract. So, John cannot claim anything from Mallory and losses money.In Section 4, we show a possible fix of OPT and we prove that in the fixedcontract John has the option to choose the products.
3. A formal semantics of Findel in Coq
The syntax of Findel is fairly small in size and it is encoded in Coq using
Inductive (Figure 2):
Inductive Primitive :=(* basic primitives *)| Zero : -> Primitive| One :Currency -> Primitive(* composite primitives *)| Scale :nat -> Primitive -> Primitive| ScaleObs :Address -> Primitive -> Primitive| Give :Primitive -> Primitive| And :Primitive -> Primitive -> Primitive| Or :Primitive -> Primitive -> Primitive| If :Address -> Primitive -> Primitive -> Primitive| Timebound :nat->nat -> Primitive -> Primitive.
Figure 2: The syntax of Findel in Coq.
Currencies are defined using
Inductive as well:8 nductive Currency :=| USD : Currency| EUR : Currency| GBP : Currency| JPY : Currency| CNY : Currency| SGD : Currency| NONE : Currency.
The additional primitives At , Before , After , and
Sell are simple definitions:
Definition At (t:nat) (p:Primitive) := Timebound (t - δ ) (t + δ ) p.Definition Before (t:nat) (p:Primitive) :=Timebound 0 t p.Definition After (t:nat) (p:Primitive) :=Timebound t INF p. δ is a just parameter which is used to adjust intervals for accepting transactions.The infinite is axiomatised in Coq as follows: Parameter INF : nat.Axiom infinite : forall n, n < INF.
Example 3.1.
When written in Coq, contracts look very similar to what theylooked before. The contract shown in Section 2.1.1, is encoded in Coq as follows:
OPT = ∆ (And (Before t (Or (Give (One USD),(Give (One EUR))))(At t+2 (Scale 1 (One GBP)))) As mentioned in [9], contracts are executed recursively. In [5], a functioncalled execute calls an internal function executeRecursive that actually exe-cutes the contract recursively. The Or primitive needs an extra-argument pro-vided by the owner, and this is handled by yet another function executeOr which calls execute on the primitives specified by the extra-argument. Addresses. Time. Balance.
An address in Findel is represented by a 20-bytevalue. From our perspective, these are just numbers, and this is why we modeladdresses as naturals. We make the following convention: 0 is treated as theconstant , i.e, 0 is the default address. The time is represented as the numberof seconds that passed since a given timestamp. The balance is a function whichtakes an address and a currency, and returns an integer value representing theamount of tokens of the specified currency. An update function for balanceis also provided: it takes an existing balance, an address, a currency and anamount, and produces a new balance.
Gateway. Gateways are the solution that the designers of Findel found to modelinteractions with external data providers. Gateways are smart contracts thatprovide a value, a timestamp, and a proof of authenticity. Before executing acontract, the gateway should be always updated [9]. In Coq, a gateway is a9riple holding an address, a value and a timestamp:
Record Gateway :=gateway { gtw_addr : Address;gtw_value : nat;gtw_timestamp : nat } . Contracts have access to a list of such triples. When a contract queries anaddress, the address is searched in the list, and the corresponding value andtimestamp are returned. If the address is not found, then the execution of thecontract fails. This functionality is provided by a Coq function called query .This function also checks for the freshness of the given data, and fails if thedifference between the current time and the provided timestamp is less thana threshold . The proof of authenticity mechanism is not yet implementedin Tikhomirov [5] and we do not handle it in Coq either. Transactions.
For every transfer of tokens a transaction is registered in a ledger.A transaction is a uniquely identified tuple containing: the id of the contractwhich generated the transfer, the addresses of the participants, the amount ofcurrency transferred, and a timestamp:
Definition Id := nat.Record Transaction :=transaction { tr_id : Id;tr_ctr_id : nat;tr_from: Address;tr_to : Address;tr_amount : nat;tr_currency : Currency;tr_timestamp : Time } . Notation 3.1.
We use { tx : I → O ; V C ; c } to denote a transaction tx where ( tr from tx ) = I , ( tr to tx ) = O , ( tr amount tx ) = V , ( tr currency tx ) = C ,and ( tr ctr id tx ) = id ( c ) , where c generated tx .Contract descriptions vs. Findel contracts. Contract descriptions are separatefrom contract instances. A description only defines what a contract is, not how it is executed [9]. In Coq, a contract description has a unique id, and containsthe code (a tree of primitives), a scale factor, a gateway, and a time intervalspecifying when this description is valid: In [5] this threshold is 30 seconds. ecord ContractDescription :=description { dsc_id : Id;dsc_prim : Primitive;dsc_scale : nat;dsc_gateway_of : list Gateway;dsc_valid_from : Time;dsc_valid_until : Time; } . Notation 3.2.
Let us consider that d is a contract description. In the restof the section we use the following notations id ( d ) = ∆ ( dsc id d ) , prim ( d ) = ∆ ( dsc prim d ) , G ( d ) = ∆ ( dsc gateway of d ) , sc ( d ) = ∆ ( dsc scale d ) , vfrom ( d ) =( dsc valid from d ) , vuntil ( d ) = ( dsc valid until d ) . According to [9], Findel contracts are tuples consisting of a description andtwo addresses (the issuer and the owner). However, for execution, we need moreingredients, as indicated by the implementation in [5]:
Record FinContract :=finctr { ctr_id : Id;ctr_desc_id : Id;ctr_primitive : Primitive;ctr_issuer : Address;ctr_owner : Address;ctr_proposed_owner : Address;ctr_scale : nat; } . When a Findel contract is issued, the description id, the code and the scaleare initialised with the corresponding fields from the description. The proposedowner is either the default value or it is set to a particular address.
Notation 3.3.
Let c be a contract. We use the following notations id ( c ) = ∆ ( ctr id c ) , dsc ( c ) = ∆ ( ctr desc id c ) , prim ( c ) = ∆ ( ctr primitive c ) , issuer ( c ) = ∆ ( ctr issuer c ) , owner ( c ) = ∆ ( ctr owner c ) , po ( c ) = ∆ ( ctr proposed owner c ) ,sc ( c ) = ∆ ( ctr scale c ) . Notation 3.4.
We use (cid:104) c : I → O ; P (cid:105) to denote a contract c whereissuer ( c ) = I , po ( c ) = O , and prim ( c ) = P .Results. A result stores the outcome of the execution of a contract. It containsthe updated balance, the issued contracts, the next available id, and the up-dated ledger: Record Result :=result { res_balance : Balance;res_contracts : list FinContract;res_next : Id;res_ledger : list Transaction } . .2.1. The execute function. The code of a Findel contract is executed recursively. In Coq we define afunction called execute which corresponds to the executeRecursive functionfrom [5]. The inputs of execute are: • the primitive to be executed; • the scale factor; • the addresses of the issuer and the owner; • the balance of the participants; • the current time (received from the network); • the list of available gateways; • the contract id and the description id; • the next available fresh identifier - which is used to assign identifiers tothe generated contracts, if any; • the ledger, i.e., a list of transactions.The output of execute is of type Result . The execution of a contract canproduce a new balance, can generate new contracts, can compute new freshids, and can register new transactions in the ledger. The fresh id generationmechanism is quite simple: execute takes a fresh id as input and uses it asa seed for generating unique identifiers for new contracts. In Section 3.4 weprove that our id generation mechanism is consistent, i.e., the generated ids areunique.The execute function is recursive on P : match P with • if P is Zero , then nothing changes: | Zero => Some (result balance [] n ledger) • if P is One , the balance of the participants is updated, new transactionsare added to the ledger, a new fresh id is generated: | One currency => Some(result(update(update balance I currncy((balance I crncy)-(Z_of_nat scale)))O currency((balance O crncy)+(Z_of_nat scale))) [] (S nextId)((transaction nextId ctr_id I O scalecrncy time) :: ledger)) if P is Scale , then scale the value of the contract: | Scale k c =>(execute c (scale * k) I O balance timegtw ctr_id dsc_id n ledger) • if P is ScaleObs , then the scale for the contract is updated only if thegateway query does not fail: | ScaleObs addr c =>match (query gtw addr time) with| None => None| Some k =>(execute c (scale * k) I O balance timegtw ctr_id dsc_id n ledger)end • if P is Give , then swap the issuer and the owner: | Give c =>(execute c scale O I balance timegtw ctr_id dsc_id n ledger) • if P is And , then execute the contracts sequentially;
And fails if at least oneof its subcontracts fails: | And c1 c2 =>match (execute c1 scale I O balance timegtw ctr_id dsc_id n ledger)with| None => None| Some (result bal1 Is1 n1 ledger1) =>match (execute c2 scale I O bal1 timegtw ctr_id dsc_id n1 ledger1)with| None => None| Some (result bal2 Is2 n2 ledger2) =>Some(result bal2 (Is1 ++ Is2) n2 ledger2)endend • if P is If , then the execution is determined by the gateway: if the gatewayquery fails, then the execution fails; if the value is 0 then execute thesecond contract; otherwise, execute the first contract.13 If addr c1 c2 =>match (query gtw addr time) with| None => None| Some v =>if beq_nat v 0then (execute c2 scale I O balance timegtw ctr_id dsc_id n ledger)else (execute c1 scale I O balance timegtw ctr_id dsc_id n ledger)end • if P is Timebound , then execute the contract only if the current time is inthe time interval; if the current time is less than the inferior limit of theinterval, then a new contract is issued and added to the list of generatedcontracts; otherwise, the execution fails: | Timebound t0 t1 p =>if (t1 Some(result balance[(finctr (S n) dsc_id (Or c1 c2)I O O scale)](S (S n)) ledger) The execution of a Findel contract may generate new contracts. We needto model a ledger of transactions, the balance of the users, an other compo-nents needed to run contracts. We define a general system state as a tuple (cid:104)C , D , B , t, G , i, L , E (cid:105) , which holds: the list of issued contracts C , the list of avail-able contract descriptions D , the balance for each user B , the current globaltime t , a list of available gateways G , the next fresh identifier i , a ledger L anda list of events E . In Coq, a state is represented as follows:14 ecord State :=state { m_contracts : list FinContract;m_descriptions : ContractDescriptions;m_balance : Balance;m_global_time : Time;m_gateway : list Gateway;m_fresh_id : Id;m_ledger : list Transaction;m_events : list Event } . Notation 3.5.
We use the following notations (where s a State . ): C ( s ) = ∆ ( m contracts s ) , D ( s ) = ∆ ( m descriptions s ) , B ( s ) = ∆ ( m balance s ) , E ( s ) = ∆ ( m events s ) , L ( s ) = ∆ ( m ledger s ) , G ( s ) = ∆ ( m gateway s ) , fresh ( s ) = ( m fresh id s ) , time ( s ) = ( m global time ( s )) . The
State is essentially holding all the ingredients of an online marketplacefor Findel derivatives. The marketplace evolves as specified by the followingrules: [Issue]
When issued, a contract c is added to the list of issued contracts havinga unique id i . Initially, the owner field contains the address of the issuer, whilethe proposed owner field contains the address of the intended owner. If the valueof the proposed owner field is 0, then anyone can join this contract. prim ( c ) isinitialised from an existing description. Also an event IssuedFor is triggered,and the global fresh id is incremented: (cid:104)C , D , B , t, G , i, L , E (cid:105)(cid:104) c : C , D , B , t, G , i + 1 , L , ( IssuedFor
O i ) : E (cid:105) d ∈ D , where c is a contract with id ( c ) = i , dsc ( c ) = id ( d ), prim ( c ) = prim ( d ), issuer ( c ) = I , owner ( c ) = I , po ( c ) = O , sc ( c ) = sc ( d ). The rule essentiallysays that the state above the line changes into the state below the line. Also,there is a side condition d ∈ D which needs to be fulfilled in order for the ruleto apply. We used ‘:’ to denote the cons list constructor, i.e., c is added in frontof the list of contracts C . [Join] Joining a contract c is the most complex operation and requires severalconditions. First, ( A ) the owner O who wants to join is either the proposedowner, that is, po ( c ) = O , or anyone can join, that is, po ( c ) = 0. Second,( B ) the root node of the contract primitive should not be an Or : prim ( c ) (cid:54) =( Or ). Third, ( C ) the execution of c is limited within a time interval givenby its corresponding description d : vfrom ( d ) ≤ t ≤ vuntil ( d ). Here, t is thecurrent time. Finally, ( D ) the execution of the associated primitive should besuccessful, that is, execute ( prim ( c ), id ( c ), dsc ( c ), c ( c ), issuer ( c ), O , t , G , L , i )= (cid:104)B (cid:48) , C (cid:48) , i (cid:48) , L (cid:48) (cid:105) . The tuple (cid:104)B (cid:48) , C (cid:48) , i (cid:48) , L (cid:48) (cid:105) is a Result , where B (cid:48) is the updated15alance, C (cid:48) is the list of contracts generated by the primitive, i (cid:48) is the new freshidentifier, and L (cid:48) is the updated ledger. The rule for joining a contract is shownbelow; note that E is enriched with event e = Executed id ( c ): (cid:104) c ∈ C , D , B , t, G , i, L , E (cid:105)(cid:104)C \ { c } ∪ C (cid:48) , D , B (cid:48) , t, G (cid:48) , i (cid:48) , L (cid:48) , e : E (cid:105) ( A ) , ( B ) , ( C ) , ( D )Note that we use c ∈ C to denote that c is in the list of contracts, and C \ { c } to denote that c is removed from C . [Join OR ] This rule handles the case when ( B (cid:48) ) prim ( c ) = ( Or c c ). In thiscase, the owner can execute either c or c . Let (cid:3) be a placeholder variable whichcan be either c or c . If the execution is successful, that is, ( D (cid:48) ) execute ( (cid:3) , id ( c ), dsc ( c ), c ( c ), issuer ( c ), O , t , G , L , i ) = (cid:104)B (cid:48) , C (cid:48) , i (cid:48) , L (cid:48) (cid:105) , then the rule belowapplies: (cid:104) c ∈ C , D , B , t, G , i, L , E (cid:105)(cid:104)C \ { c } ∪ C (cid:48) , D , B (cid:48) , t, G (cid:48) , i (cid:48) , L (cid:48) , e : E (cid:105) ( A ) , ( B (cid:48) ) , ( C ) , ( D (cid:48) )Note that the conditions ( A ) and ( C ) need to be satisfied here as well. Again, e = Executed id ( c ). [Fail] If the execution of a contract fails, that is, ( D (cid:48)(cid:48) ) execute ( (cid:3) , id ( c ), dsc ( c ), c ( c ), issuer ( c ), O , t , G , L , i ) = ⊥ , then the event e (cid:48) = Deleted id ( c ) is triggered: (cid:104) c ∈ C , D , B , t, G , i, L , E (cid:105)(cid:104)C \ { c } , D , B , t, G , i, L , e (cid:48) : E (cid:105) ( A ) , ( C ) , ( D (cid:48)(cid:48) ) . [Tick] The tick rule increments the global time t : (cid:104)C , D , B (cid:48) , t, G (cid:48) , i (cid:48) , L (cid:48) , E (cid:105)(cid:104)C , D , B (cid:48) , t + 1 , G (cid:48) , i (cid:48) , L (cid:48) , E (cid:105) The rules [Join] , [Join OR ] , and [Fail] cannot be applied in the same timebecause their side conditions exclude each other. On the other hand, the rules [Issue] and [Tick] can be applied any time. Also, note that [Join] , [Join OR ] ,and [Fail] are the only rules that actually execute contracts and may producemodifications in the balance, the ledger, and the list of events. Definition 3.1.
The rules above define a relation between states. By s (cid:121) s (cid:48) we denote that there is a step (given by one of the rules [Issue] , [Join] , [Join OR ] , [Fail] , or [Tick] ) from the state s to the state s (cid:48) . We also use s (cid:32) s (cid:48) todenote the reflexive and transitive closure of (cid:121) .3.4. MetapropertiesState consistency. We start by defining what conditions need to be satisfied fora state to be consistent. 16 efinition 3.2.
A state s is consistent if: ∀ c . c ∈ C ( s ) → fresh ( s ) > id ( c ) ; ∀ i . ( Executed i ) ∈ E ( s ) ∨ ( Deleted i ) ∈ E ( s ) → fresh ( s ) > i ; ∀ c . c ∈ C ( s ) → (( Executed id ( c )) (cid:54)∈ E ( s ) ∧ ( Deleted id ( c )) (cid:54)∈ E ( s )) ; ∀ i . ¬ (( Executed i ) ∈ E ( s ) ∧ ( Deleted i ) ∈ E ( s )) . The first two conditions capture the fact that the id field of the state isalways fresh , i.e., it always strictly greater than all the other identifiers. Sincewe do not use hash functions to compute unique identifiers, we have ensure thatour unique identifier generation approach is consistent. The last two conditionsof Definition 3.2 capture the consistency of the generated events. Condition 3ensures that an issued contract cannot be executed or deleted, while condition 4ensures that a contract cannot be both executed and deleted in the same time.The first important metaproperty that we prove is that the (cid:32) relation pre-serves state consistency:
Theorem 3.1.
For all states s , s (cid:48) , such that s is consistent, if s (cid:32) s (cid:48) then s (cid:48) is consistent. The Coq proof of this theorem is based on several lemmas which correspond toeach item in Definition 3.2. These lemmas are proved by induction on (cid:121) . Ledger consistency.
One important property of the ledger is that the registeredtransactions cannot be removed or modified. In Coq, we are able to prove thisfor our semantics as well:
Theorem 3.2.
For all states s and s (cid:48) , and for all transactions t , if s (cid:32) s (cid:48) and t ∈ L ( s ) then t ∈ L ( s (cid:48) ) . The proof is based on the fact that the execute function only appends transac-tions to the ledger, and it never modifies the existing transactions in the ledger.
Events consistency.
The (cid:121) relation triggers several events:
Executed , Deleted ,and
IssuedFor . These events correspond to actions and once an event is trig-gered it means that some action has been performed. For instance, when acontract is issued an
IssuedFor event is triggered, and a potential owner cancheck whether a contract has been issued for him. This action cannot be re-tracted. In Coq, we prove that triggered events cannot be retracted:
Theorem 3.3.
For all states s and s (cid:48) , and for all events e , if s (cid:32) s (cid:48) and e ∈ E ( s ) then e ∈ E ( s (cid:48) ) . The proof is based on the fact that the execute function only generates newevents, and it never modifies the existing list of events.17 ther metaproperties.
A very useful property that we intensively use in our Coqproofs is given by the following lemma:
Lemma 3.1.
For all states s and s (cid:48) , and for all contracts c , if s (cid:121) s (cid:48) and c ∈ C ( s ) then c ∈ C ( s (cid:48) ) or ( Executed id ( c )) ∈ E ( s (cid:48) ) or ( Deleted id ( c ) ∈ E ( s (cid:48) ) . The lemma essentially enumerates the possible outcomes of a step from s to s (cid:48) :either a contract is not executed and it remains available in the contracts of s (cid:48) , or it is executed and a corresponding event was triggered. The proof is byinduction on (cid:121) .Another property that we prove in Coq is that the time cannot go backwardswhen performing steps: Lemma 3.2.
For all s and s (cid:48) , if s (cid:32) s (cid:48) then t ( s ) ≤ t ( s (cid:48) ) . The proof is by induction on both (cid:32) and (cid:121) .
4. Verifying properties of Findel derivatives
In this section we verify the properties (CM) , (ES) , and (AS) for severalFindel derivatives. Sometimes, proofs cannot be completed. In this case weprove a proposition that indicates a vulnerability.All the subsequent properties are formalized and certified in Coq. The fullCoq codebase is available online at https://github.com/andreiarusoaie/findel-semantics-coq . Since everything is already proved and verified inCoq, we do not show any proofs in this section .For convenience, in the rest of this section, we assume that I is always theissuer and O is always the owner. We explicitly mention when their roles change.We also introduce some useful notations and definitions: Notation 4.1. If P is a primitive, then we denote by c P the contract whereprim ( c P ) = P , issuer ( c P ) = I , owner ( c P ) = O , and id ( c P ) = id ( P ) . Definition 4.1.
A contract c is executed between s and s at time t if c ∈C ( s ) , Executed id ( c ) ∈ E ( s ) , time ( s ) = t and s (cid:121) s . Definition 4.2.
A contract c is deleted between s and s at time t if c ∈ C ( s ) , Deleted id ( c ) ∈ E ( s ) , time ( s ) = t and s (cid:121) s . Definition 4.3.
An owner O joins a contract c between states s and s attime t if there are states s and s (cid:48) such that s (cid:32) s , s (cid:48) (cid:32) s and c is executedor deleted between s and s (cid:48) at time t . Most of the proofs are by induction on (cid:121) or (cid:32) , and can be found in the indicatedcodebase. .1. Fixed-rate currency exchange Recall the fixed-rate currency exchange (
FRCE ) shown in Example 2.1. Weprove in Coq that I receives 11 dollars from O , while O receives 10 euros from I : Proposition 4.1.
For all s , s (cid:48) , with s consistent, if O joins c FRCE between s and s (cid:48) then there exists tx such that { tx : I → O ; 10
USD ; id ( c FRCE ) }∈ L ( s (cid:48) ) . Proposition 4.2.
For all s , s (cid:48) , with s consistent, if O joins c FRCE between s and s (cid:48) then there exists tx such that { tx : O → I ; 11
USD ; id ( c FRCE ) }∈ L ( s (cid:48) ) . In Coq, we actually prove a more general version of these properties, wherethe amounts are multiplied by the scale of the contract. These propositionsguarantee the (CM) and (AS) properties. (ES) does not make sense here be-cause no external sources are used.
A more interesting example is a currency exchange derivative where theexchange rate is provided by an external source, i.e., a gateway:
ERCE = ∆ And (Give (Scale n (One USD)))(ScaleObs addr (Scale n (One EUR)))
An interesting question is what happens if the gateway fails to provide an ex-change rate r ? First, we prove that the expected transactions are generated ifthe gateway successfully provides an exchange rate r : Proposition 4.3.
For all s , s (cid:48) , with s consistent, if O joins c ERCE between s and s (cid:48) , and query G ( s ) addr t = r then there exists tx such that { tx : I → O ; sc ( c ERCE ) ∗ r USD ; id ( c ERCE ) } ∈ L ( s (cid:48) ) . Proposition 4.4.
For all s , s (cid:48) , with s consistent, if O joins c ERCE between s and s (cid:48) , and query G ( s ) addr t = r then there exists tx such that { tx : O → I ; sc ( c ERCE ) EUR ; id ( c ERCE ) } ∈ L ( s (cid:48) ) . Second, if the gateway query fails, we prove that the ledger remains un-changed, that is, (ES) : Proposition 4.5.
For all s , s (cid:48) , with s consistent, if c ERCE is executed (ordeleted) between s and s (cid:48) and query G ( s ) addr t ( s ) = None then L ( s ) = L ( s (cid:48) ) . Thus, no transaction has been performed, and the balance of the users is notaffected by the gateway failure.All the propositions in this section guarantee (CM) , (ES) , and (AS) for thisFindel derivative. 19 .3. Zero-coupon bond Our next case study is the zero-coupon bond (Example 2.2), where the issuersells a zero-coupon bond that pays 11
USD in one year for 10
USD : ZCB = ∆ (cid:0) And(Give (Scale (One USD) 10))(At (now+t) (Scale (One USD) 11)) (cid:1)
First, we are concerned about the rights of the issuer:
Proposition 4.6.
For all s , s (cid:48) , with s consistent, if O joins c ZCB between s and s (cid:48) then there is a transaction tx such that { tx : O → I ; sc ( c ZCB ) ∗ USD ; id ( c ZCB ) } ∈ L ( s (cid:48) ) . At generates a new contract which can be executed between now + t − δ and now + t + δ (cf. Table 2). The owner gets paid only if he joins in this timeinterval: Proposition 4.7.
For all s , s (cid:48) , now , t , with s consistent, if O joins c ZCB between s and s (cid:48) , and O joins the contract c OR generated by c ZCB at t (cid:48) ∈ [ now + t − δ, now + t + δ ] then there is tx such that { tx : I → O ; sc ( c OR ) ∗ USD ; id ( c OR ) } ∈ L ( s (cid:48) ) . The hypotheses of the above proposition should be carefully considered: if O does not join in time, the he does not receive 11 USD . The next propositionreveals a security vulnerability (time constraints) that affects O : Proposition 4.8.
For all s , s (cid:48) , now , t , with s consistent, if O joins c ZCB between s and s (cid:48) and O joins the contract c OR generated by c ZCB at t (cid:48) > now + t + δ then Deleted id ( c OR ) ∈ E ( s (cid:48) ) . Deleted is generated by the [Fail] rule, so the ledger remains unchanged andthe owner does not get paid. So, for
ZCB only the properties (CM) and (AS) hold.
Recall the option derivative
OPT from Section 2.1.1:
OPT = ∆ (cid:0) And (Before t (Or (Give (One USD)),(Give (One EUR)))(After t+2 (Scale 1 (One GBP))) (cid:1)
We explained in Section 2.1.1 that Mallory requests and receives 1
GBP after t+2 . This is proved by the next proposition:
Proposition 4.9.
For all s , s (cid:48) , t , with s consistent, if O joins c OPT between s and s (cid:48) before t , and then O joins the contract c After generated by c OPT at t (cid:48) where t (cid:48) > t + , then there is tx such that { tx : I → O ; sc ( c After ) GBP ;id ( c After ) } ∈ L ( s (cid:48) ) . (CM) property.However, it violates (AS) : Proposition 4.10.
For all s , s (cid:48) , with s consistent before t , if O joins c OPT between s and s (cid:48) then O is the owner of any contract generated by c OPT . So I is not the owner of the generated option derivative, and thus, O is the onewho decides whether or not to join the option contract. If O is honest then wecan prove: Proposition 4.11.
For all s , s (cid:48) , with s consistent, if O joins c OPT between s and s (cid:48) before t , and then O joins the contract c Or generated by c OPT after t ,then there is tx such that { tx : O → I ; sc ( c Or ) (cid:3) ; id ( c Or ) } ∈ L ( s (cid:48) ) ,where (cid:3) ∈ { EUR , USD } . Indeed, it is not acceptable for I to depend on O ’s choice. A possible solu-tion for fixing OPT is to replace (Or (Give (One USD)) (Give (One EUR))) with (Give (Or (One USD) (One EUR))) . Since the
Give primitive swaps the roles ofthe participants for the enclosed contracts, I becomes the owner, O becomes theissuer, and thus, I can request the payment from O . With this change we canprove the next propositions that ensure (CM) , (AS) , and (ES) for this contract: Proposition 4.12.
For all s , s (cid:48) , with s consistent, if O joins c OPT (cid:48) between s and s (cid:48) before t , then I is the owner of the contract c Or generated by c OPT (cid:48) whose primitive is (Or (One USD) (One EUR)) and its issuer is O . Proposition 4.13.
For all s , s (cid:48) , with s consistent, if O joins c OPT (cid:48) between s and s (cid:48) before t , and then I joins c Or generated by c OPT (cid:48) , then there is tx suchthat { tx : O → I ; sc ( c Or ) (cid:3) ; id ( c Or ) } ∈ L ( s (cid:48) ) , where (cid:3) ∈ { EUR , USD } .4.5. Credit Default Swap In this section we prove the properties (CM) , (ES) , and (AS) for a verypopular and real-life financial derivative type: credit default swap (CDS). Thistype of derivative enables investors to swap credit risk with another investor.Suppose that Alice buys a financial bond of value price from Bob. The maturityof the bond is 3 years. Every year, Bob has to pay Alice a fee FY , and price when maturity is reached. Alice wants to protect her investment: she joins aCDS issued by a seller C with a better credit rating than Bob. For this, Alicepays an yearly fee F to C . If Bob defaults, then C will pay to Alice the price and the remaining fees: 21 DS = ∆ (And(* first year *)(And(Give (Scale F (One USD)))(pay at t (now+1yr) addr(price + (2 * FY))))(And(* second year *)(yearly check (now+1yr)(now+2yrs)addr price FY F 1)(* third year *)(yearly check (now+2yrs)(now+3yrs)addr price FY F 0))) Since Findel does not allow contracts with three parties, we use a gatewayavailable at address addr that can tell whether Bob defaulted or not. Here wetake advantage of the compositionality of Findel: pay at t and yearly check are Findel contracts as well. First, pay at t pays sum at time t if Bob defaulted: pay at t = ∆ (At t (If addr (Scale sum (One USD)) Zero)) We prove that pay at t has the following property:
Proposition 4.14.
If Bob defaults at time t then the issuer of pay at t pays sum to the owner. Otherwise, no transaction between the involved parties isgenerated by contract pay at t . Second, yearly check is more complex: yearly check = ∆ At t (If addr Zero(And (Give (Scale F (One USD)))(pay at t t’ addr (price + i * FY))))
The contract describes the obligations that parties have at time t : if Bob de-faulted at t , nothing happens. Otherwise, Alice pays F to C, and C pays price+ i * FY at t’ if Bob defaults. The contract is intended to be used inside CDS:at now + 1 year , Alice pays F to C, and at t’ = now + 2 years C pays price+ 1 * FY to Alice if Bob defaulted at t’ . We prove that in Coq: Proposition 4.15.
If Bob defaults at time t , then yearly check does notgenerate any transactions. If Bob does not default at t then the issuer receivesfee F from the owner and a pay at at t’ (price + i * FY) contract withthe same owner is generated. Here, i is the number of fees left to be paid until maturity is reached. Forinstance, if Bob defaults at now + 1 year then C pays to Alice price+2*FY .The financial obligations of C to Alice when Bob defaults are summarizedby Table 4.5. The same table lists the financial obligations of Alice to C. In Coqwe prove that the Findel specification of CDS ensures that these obligations are22 ob defaults at Obligations of C to Alice now + 1 year price + + Timestamp Obligations of Alice to C now F now + 1 year F now + 2 years F Table 3: The financial obligations of the parties. fullfilled by the parties. Moreover, we prove that no other finacial obligation isgenerated by
CDS .The compositional nature of Findel contracts allows us to develop incremen-tal proofs for
CDS . In our proofs for
CDS we reuse Propositions 4.14 and 4.15.The proofs are broken into smaller pieces, and they become less difficult andeasier to manage.
5. Conclusions
The recent developments in the blockchain technologies, especially the sup-port for smart contracts, are a perfect match for financial agreements. In partic-ular, it makes sense to have DSLs for financial derivatives that run directly onthe blockchain, and thus, they are automatically processed by a decentralizednetwork. These languages are specially designed for people in finance. They canfocus on the specification rather than learning how to program smart contracts.Expressing financial derivatives in a specialized DSL may be more precise andless error prone than specifying them in a general purpose smart contracts lan-guage [16]. Either way, mistakes in contracts can happen.Our work is complementary to the efforts in previous research like [7] or [8],where DSLs based on similar primitives as Findel were formalised only withthe purpose of making various analyses or estimating derivatives values. Findelderivatives are executed in the blockchain, making derivatives susceptible ofseveral known vulnerabilities of smart contracts. Our infrastructure is meant tohelp users to discover such vulnerabilities in their financial derivatives.
Future work.
The main disadvantage of Coq is the fact that it is not fullyautomatic. Other tools, like K [24], can help with automation. However, theseare not yet capable to generate certificates. On the other hand it is worthinvestigating whether these tools are more practical than Coq.Automation of proofs remains a challenge for our approach. Coq allows usersto define the so-called tactics which helps with improving the proof language.Here we define several tactics that we use to discharge very common proof goals.However, a deeper investigation on how to define specific tactics is required.23nother piece of future work is an investigation on other financial DSLsthat run on the blockchain, where proving correctness of the encoded financialagreements could help with finding security vulnerabilities.
Acknowledgements.
This work was supported by a research grant of the “Alexan-dru Ioan Cuza”, University of Ia¸si, within the Research Grants program, GrantUAIC, ctr. no. 6/03.01.2018, code GI-UAIC-2017-08.
References [1] A. Steinherr.
Derivatives: The Wild Beast of Finance . Wiley, 1998. ISBN9780471965442.[2] J. Hull.
Options, Futures and Other Derivatives . Options, Futures andOther Derivatives. Pearson/Prentice Hall, 2009. ISBN 9780136015864.[3] A.M. Chisholm.
Derivatives Demystified: A Step-by-Step Guide to For-wards, Futures, Swaps and Options . The Wiley Finance Series. Wiley,2010. ISBN 9780470972953.[4] A. Gottesman.
Derivatives Essentials: An Introduction to Forwards,Futures, Options and Swaps . Wiley Finance. Wiley, 2016. ISBN9781119163497.[5] S. Tikhomirov. Github findel, 2019. URL https://github.com/cryptolu/findel .[6] Solidity docs, 2020. URL https://solidity.readthedocs.io/ .[7] SL Peyton Jones, J-M Eber, J Seward, and Simon Peyton Jones. Com-posing contracts: an adventure in financial engineering. In
ACM SIG-PLAN International Conference on Functional Programming (ICFP’00) ,pages 280–292. ACM Press, September 2000.[8] J.M. Gaillourdet. A software language approach to derivative contracts infinance.
CEUR Workshop Proceedings , 750, 01 2011.[9] A. Biryukov, D. Khovratovich, and S. Tikhomirov. Findel: Secure deriva-tive contracts for ethereum. In
Financial Cryptography Workshops , volume10323 of
LNCS , pages 453–467, 2017.[10] P. Lamela Seijas and S. Thompson. Marlowe: Financial contracts onblockchain. In Tiziana M. and Bernhard S., editors,
Leveraging Applica-tions of Formal Methods, Verification and Validation. Industrial Practice ,pages 356–375, Cham, 2018. Springer International Publishing. ISBN 978-3-030-03427-6.[11] B. Egelund-M¨uller, M. Elsman, F. Henglein, and O. Ross. Automatedexecution of financial contracts on blockchains.
Business & InformationSystems Engineering , 59(6):457–467, Dec 2017. ISSN 1867-0202.2412] S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2009. URL .[13] G. Wood. Ethereum: a secure decentralised generalised transaction ledger.https://gavwood.com/paper.pdf, 2014.[14] V. Buterin. Ethereum : A next-generation smart contract and decentralizedapplication platform, 2013.[15] C. Hoskinson. Why we are building Cardano, 2017. URL https://whycardano.com/ .[16] N. Atzei, M. Bartoletti, and T. Cimoli. A survey of attacks on ethereumsmart contracts sok. In
Proceedings of the 6th International Conference onPrinciples of Security and Trust - Vol 10204 , pages 164–186, New York,NY, USA, 2017. Springer-Verlag New York, Inc. ISBN 978-3-662-54454-9.[17] V. Dwivedi, V. Deval, A. Dixit, and A. Norta. Formal-verification ofsmart-contract languages: A survey. In M. Singh, P.K. Gupta, V. Tyagi,J. Flusser, T. ¨Oren, and R. Kashyap, editors,
Advances in Computing andData Sciences , pages 738–747, 2019. ISBN 978-981-13-9942-8.[18] Y. Wang, S. Lahiri, S. Chen, R. Pan, I. Dillig, C. Born, and I. Naseer. For-mal specification and verification of smart contracts for azure blockchain,April 2019. URL https://arxiv.org/abs/1812.08829 .[19] K. Bhargavan, A. Delignat-Lavaud, C. Fournet, A. Gollamudi, G. Gonthier,N. Kobeissi, N. Kulatova, A. Rastogi, T. Sibut-Pinote, N. Swamy, andS. Zanella-B´eguelin. Formal verification of smart contracts: Short paper.In
Proceedings of the 2016 ACM Workshop on Programming Languagesand Analysis for Security , pages 91–96, New York, NY, USA, 2016. ACM.ISBN 978-1-4503-4574-3.[20] K. Sukrit, G. Seep, D. Mohan, and S. Subodh. ZEUS: analyzing safety ofsmart contracts. In ,page 15, 2018.[21] P. Tsankov, A. Dan, D. Drachsler-Cohen, A. Gervais, F. B¨unzli, andM. Vechev. Securify: Practical security analysis of smart contracts. In
Proceedings of the 2018 ACM SIGSAC Conference on Computer and Com-munications Security , pages 67–82, New York, NY, USA, 2018. ACM. ISBN978-1-4503-5693-0.[22] I. Grishchenko, M. Maffei, and C. Schneidewind. A semantic frameworkfor the security analysis of ethereum smart contracts. In L. Bauer andR. K¨usters, editors,
Principles of Security and Trust , pages 243–269, Cham,2018. Springer. ISBN 978-3-319-89722-6.[23] Coq. The coq proof assistant. URL https://coq.inria.fr/ .2524] T.F. Serbanuta, A. Arusoaie, D. Lazar, C. Ellison, D. Lucanu, and G. Ro¸su.The K primer (version 3.3).