ConCert: A Smart Contract Certification Framework in Coq

TL;DR

ConCert introduces a novel framework for embedding and verifying smart contracts in Coq, combining deep and shallow embeddings through meta-programming, enabling formal verification of blockchain contracts.

Contribution

It presents a new embedding approach in Coq for smart contracts, linking deep and shallow embeddings with a soundness theorem, facilitating formal reasoning.

Findings

Verified properties of a crowdfunding contract

Connected deep and shallow embeddings via soundness theorem

Formalized smart contract execution in Coq

Abstract

We present a new way of embedding functional languages into the Coq proof assistant by using meta-programming. This allows us to develop the meta-theory of the language using the deep embedding and provides a convenient way for reasoning about concrete programs using the shallow embedding. We connect the deep and the shallow embeddings by a soundness theorem. As an instance of our approach, we develop an embedding of a core smart contract language into Coq and verify several important properties of a crowdfunding contract based on a previous formalisation of smart contract execution in blockchains.

Equations

$$\displaystyle{\color[rgb]{0,0.1,0.6}{\tau}}~{}{\color[rgb]{0,0.1,0.6}{\sigma}}$$

$$\displaystyle{\color[rgb]{0,0.1,0.6}{p}}$$

$$\displaystyle{\color[rgb]{0,0.1,0.6}{e}}$$

$$v$$

$$resolve\_ind:$$

$$\to \mathtt{option}(\mathtt{list}\mathtt{constr})$$

$$resolve\_ctor:$$

$$\to \mathtt{option}(\mathbb{N}\times \mathtt{constr})$$

$$\begin{aligned} \llbracket-\rrbracket^{t}&:\mathtt{global\_env}\times\mathtt{{\color[rgb]{0,0.1,0.6}{expr}}}\rightarrow\mathtt{{{\color[rgb]{0,0.35,0}term}}}\\ \llbracket{\color[rgb]{0,0.1,0.6}{\overline{i}}}\rrbracket^{t}_{\Sigma}&\overset{def}{=}{{\color[rgb]{0,0.35,0}\overline{i}}}\\ \llbracket{\color[rgb]{0,0.1,0.6}{\lambda x:\tau.e}}\rrbracket^{t}_{\Sigma}&\overset{def}{=}{{\color[rgb]{0,0.35,0}\<fun>~{}(x:}}~{}\llbracket{\color[rgb]{0,0.1,0.6}{\tau}}\rrbracket^{T})~{}{{\color[rgb]{0,0.35,0}=>}}~{}\llbracket{\color[rgb]{0,0.1,0.6}{e}}\rrbracket^{t}_{\Sigma}\\ \llbracket{{\color[rgb]{0,0.1,0.6}{\Lambda A.e}}}\rrbracket^{t}_{\Sigma}&\overset{def}{=}{{{\color[rgb]{0,0.35,0}\<fun>~{}(A:\<Set>)~{}=>}}}~{}\llbracket{\color[rgb]{0,0.1,0.6}{e}}\rrbracket^{t}_{\Sigma}\\ \llbracket{\color[rgb]{0,0.1,0.6}{\<let>~{}x:~{}\tau~{}=~{}e_{1}~{}\<in>~{}e_{2}}}\rrbracket^{t}_{\Sigma}&\overset{def}{=}{{{\color[rgb]{0,0.35,0}\<let>~{}x:}}}~{}\llbracket{\color[rgb]{0,0.1,0.6}{\tau}}\rrbracket^{T}~{}{{\color[rgb]{0,0.35,0}:=}}~{}\llbracket{\color[rgb]{0,0.1,0.6}{e_{1}}}\rrbracket^{t}_{\Sigma}~{}{{\color[rgb]{0,0.35,0}\<in>}}~{}\llbracket{\color[rgb]{0,0.1,0.6}{e_{2}}}\rrbracket^{t}_{\Sigma}\\ \llbracket{\color[rgb]{0,0.1,0.6}{e_{1}~{}e_{2}}}\rrbracket^{t}_{\Sigma}&\overset{def}{=}\llbracket{\color[rgb]{0,0.1,0.6}{e_{1}}}\rrbracket^{t}_{\Sigma}~{}\llbracket{\color[rgb]{0,0.1,0.6}{e_{2}}}\rrbracket^{t}_{\Sigma}\\ \llbracket{\color[rgb]{0,0.1,0.6}{C_{I}}}\rrbracket^{t}_{\Sigma}&\overset{def}{=}\<let>({{\color[rgb]{0,0.35,0}C}},\_):=\mathtt{resolve\_ctor}(\Sigma,{\color[rgb]{0,0.1,0.6}{C}},{\color[rgb]{0,0.1,0.6}{I}})\\ &\qquad\<in>~{}{{\color[rgb]{0,0.35,0}C}}_{{\color[rgb]{0,0.35,0}I}}\\ \end{aligned}\qquad\begin{aligned} \llbracket-\rrbracket^{T}{}&:\mathtt{{\color[rgb]{0,0.1,0.6}{type}}}\rightarrow\mathtt{{{\color[rgb]{0,0.35,0}term}}}\\ \llbracket{\color[rgb]{0,0.1,0.6}{\hat{i}}}\rrbracket^{T}&\overset{def}{=}{{\color[rgb]{0,0.35,0}\overline{i}}}\\ \llbracket{\color[rgb]{0,0.1,0.6}{I}}\rrbracket^{T}&\overset{def}{=}{{\color[rgb]{0,0.35,0}I}}\\ \llbracket{\color[rgb]{0,0.1,0.6}{\tau}}\rrbracket^{T}&\overset{def}{=}\llbracket\tau\rrbracket^{T}\\ \llbracket{\color[rgb]{0,0.1,0.6}{\forall A.\tau}}\rrbracket^{T}&\overset{def}{=}{{\color[rgb]{0,0.35,0}\<forall>~{}(A:\<Set>),}}~{}\llbracket{\color[rgb]{0,0.1,0.6}{\tau}}\rrbracket^{T}\\ \llbracket{\color[rgb]{0,0.1,0.6}{\tau_{1}~{}\tau_{2}}}\rrbracket^{T}&\overset{def}{=}\llbracket{\color[rgb]{0,0.1,0.6}{\tau_{1}}}\rrbracket^{T}~{}\llbracket{\color[rgb]{0,0.1,0.6}{\tau_{2}}}\rrbracket^{T}\\ \llbracket{\color[rgb]{0,0.1,0.6}{\tau_{1}\rightarrow\tau_{2}}}\rrbracket^{T}&\overset{def}{=}{{\color[rgb]{0,0.35,0}\<forall>}}~{}({{\color[rgb]{0,0.35,0}\_:}}\llbracket{\color[rgb]{0,0.1,0.6}{\tau_{1}}}\rrbracket^{T}){{\color[rgb]{0,0.35,0},}}~{}\uparrow_{1}\llbracket{\color[rgb]{0,0.1,0.6}{\tau_{2}}}\rrbracket^{T}\\ \end{aligned}$$

$$\llbracket{\color[rgb]{0,0.1,0.6}{\<fix>~{}f~{}x:\tau_{1}\rightarrow\tau_{2}~{}=~{}e}}\rrbracket^{t}_{\Sigma}\overset{def}{=}{{\color[rgb]{0,0.35,0}\<fix>}}~{}({{\color[rgb]{0,0.35,0}f}}~{}{{\color[rgb]{0,0.35,0}:}}~{}{{\color[rgb]{0,0.35,0}\<forall>}}~{}({{\color[rgb]{0,0.35,0}\_~{}:}}~{}\llbracket{\color[rgb]{0,0.1,0.6}{\tau_{1}}}\rrbracket^{T}){{\color[rgb]{0,0.35,0},}}~{}\uparrow_{1}\llbracket{\color[rgb]{0,0.1,0.6}{\tau_{2}}}\rrbracket^{T})~{}{{\color[rgb]{0,0.35,0}:=}}~{}{{\color[rgb]{0,0.35,0}\<fun>}}~{}({{\color[rgb]{0,0.35,0}x~{}:}}\uparrow_{1}\llbracket{\color[rgb]{0,0.1,0.6}{\tau_{1}}}\rrbracket^{T})~{}{{\color[rgb]{0,0.35,0}=>}}~{}\llbracket e\rrbracket^{t}_{\Sigma}$$

$$\displaystyle\left\llbracket\begin{array}[]{@{}ll@{}}{\color[rgb]{0,0.1,0.6}{\<case>}}&{\color[rgb]{0,0.1,0.6}{e~{}:~{}I~{}\tau_{1}\ldots\tau_{n}~{}\<return>~{}\sigma~{}\<of>}}\\ &{\color[rgb]{0,0.1,0.6}{p_{1}\rightarrow e_{1}}}\\ &\ldots\\ &{\color[rgb]{0,0.1,0.6}{p_{m}\rightarrow e_{m}}}\end{array}\right\rrbracket_{\Sigma}$$

$${\color[rgb]{0,0.1,0.6}{c_{1}\ldots c_{m}}}\overset{def}{=}\mathtt{resolve\_ind}(\Sigma,{\color[rgb]{0,0.1,0.6}{I}})\qquad\overrightarrow{{\color[rgb]{0,0.1,0.6}{\tau_{i}}}}\overset{def}{=}{\color[rgb]{0,0.1,0.6}{\tau_{1}}},\ldots,{\color[rgb]{0,0.1,0.6}{\tau_{n}}}\qquad\llbracket\overrightarrow{~{}{\color[rgb]{0,0.1,0.6}{\tau_{i}}}}\rrbracket^{T}\overset{def}{=}\llbracket{\color[rgb]{0,0.1,0.6}{\tau_{1}}}\rrbracket^{T},\ldots,\llbracket{\color[rgb]{0,0.1,0.6}{\tau_{n}}}\rrbracket^{T}\qquad\overrightarrow{{\color[rgb]{0,0.1,0.6}{p_{i}\rightarrow e_{i}}}}\overset{def}{=}{\color[rgb]{0,0.1,0.6}{p_{1}\rightarrow e_{1}}},\ldots,{\color[rgb]{0,0.1,0.6}{p_{m}\rightarrow e_{m}}}$$

$$\mathtt{branch}:$$

$$\displaystyle\mathtt{branch}(\overrightarrow{~{}{\color[rgb]{0,0.1,0.6}{\tau_{i}}}},\overrightarrow{{\color[rgb]{0,0.1,0.6}{p_{i}\rightarrow e_{i}}}},{\color[rgb]{0,0.1,0.6}{c}})\overset{def}{=}$$

$$\displaystyle\<let>~{}{\color[rgb]{0,0.1,0.6}{\sigma_{1},\sigma_{2},\ldots,\sigma_{k}}}:=\mathtt{ctor\_args}({\color[rgb]{0,0.1,0.6}{c}})~{}\<in>$$

$$\displaystyle{{\color[rgb]{0,0.35,0}\<fun>}}~{}{{\color[rgb]{0,0.35,0}(x_{1}:}}~{}\llbracket{\color[rgb]{0,0.1,0.6}{\sigma_{1}}}\rrbracket^{T}\big{\{}\llbracket\overrightarrow{~{}{\color[rgb]{0,0.1,0.6}{\tau_{i}}}}\rrbracket^{T}\big{\}})~{}{{\color[rgb]{0,0.35,0}(x_{2}:}}~{}\llbracket{\color[rgb]{0,0.1,0.6}{\sigma_{2}}}\rrbracket^{T}\big{\{}\uparrow_{1}\llbracket\overrightarrow{~{}{\color[rgb]{0,0.1,0.6}{\tau_{i}}}}\rrbracket^{T}\big{\}})\ldots{{\color[rgb]{0,0.35,0}(x_{k}:}}~{}\llbracket{\color[rgb]{0,0.1,0.6}{\sigma_{k}}}\rrbracket^{T}\big{\{}\uparrow_{k-1}\llbracket\overrightarrow{~{}{\color[rgb]{0,0.1,0.6}{\tau_{i}}}}\rrbracket^{T}\big{\}})~{}{{\color[rgb]{0,0.35,0}=>}}~{}\llbracket{\color[rgb]{0,0.1,0.6}{e}}\rrbracket^{t}_{\Sigma}$$

$$\tau [-]:$$

$$e[-]:$$

$$\displaystyle\mathtt{of\_val}(\mathtt{vClosLam}(\rho,x,\tau,{\color[rgb]{0,0.1,0.6}{e}}))\overset{def}{=}$$

$$\displaystyle({\color[rgb]{0,0.1,0.6}{\lambda x:\tau.e}})[\rho^{\prime}]$$

$$\displaystyle\mathtt{of\_val}(\mathtt{vClosFix}(\rho,f,x,\tau_{1},\tau_{2},{\color[rgb]{0,0.1,0.6}{e}}))\overset{def}{=}$$

$$\displaystyle({\color[rgb]{0,0.1,0.6}{\<fix>~{}f~{}x:\tau_{1}\rightarrow\tau_{2}~{}=~{}e}})[\rho^{\prime}]$$

$$of\_val(\mathtt{vConstr}(I,C,v_1\dots v_n))\stackrel{def}{=}$$

$$\displaystyle\mathtt{of\_val}(\mathtt{vTyClos}(\rho,A,{\color[rgb]{0,0.1,0.6}{e}}))\overset{def}{=}$$

$$\displaystyle({{\color[rgb]{0,0.1,0.6}{\Lambda A.e}}})[\rho^{\prime}]$$

$$\displaystyle\mathtt{of\_val}(\mathtt{vTy}({\color[rgb]{0,0.1,0.6}{\tau}}))\overset{def}{=}$$

$$\llbracket e[\rho]\rrbracket^{t}_{\Sigma}=(\llbracket e\rrbracket^{t}_{\Sigma})\big{\{}\llbracket\rho\rrbracket^{t}_{\Sigma}\big{\}}$$

Full text

0.1 Introduction

The concept of blockchain-based smart contracts has evolved in several ways since its appearance. Starting from the restricted and non-Turing-complete Bitcoin script111Bitcoin: A peer-to-peer electronic cash system.

https://bitcoin.org/bitcoin.pdf designed to validate transactions, the idea of smart contracts expanded to fully-featured languages such as Solidity running on the Ethereum Virtual Machine (EVM).222Ethereum’s white paper:

https://github.com/ethereum/wiki/wiki/White-Paper Recent research on smart contract verification discovered the presence of multiple vulnerabilities in many smart contracts written in Solidity [13, 19]. Several times the issues in smart contract implementations resulted in huge financial losses (for example, the DAO contract and the Parity multi-sig wallet on Ethereum). The setup for smart contracts is unique: once deployed, they cannot be changed and any small mistake in the contract logic may lead to serious financial consequences. This shows not only the importance of formal verification of smart contracts but also the importance of principled programming language design. The third generation smart contract languages tend to employ the functional programming paradigm. A number of blockchain implementations have already adopted certain variations of functional languages as a smart contract language. These languages range from minimalistic and low-level (Simplicity [15], Michelson333https://www.michelson-lang.com/), intermediate (Scilla [20]) to fully-featured OCaml- and Haskell-like languages (Liquidity [6], Plutus [7, 17]). There is a very good reason for this tendency. Statically typed functional programming languages can rule out many errors. Moreover, due to the absence (or more precise control) of side effects programs in functional languages behave like mathematical functions, which facilitates reasoning about them. However, one cannot hope to perform only stateless computations: the state is inherent for blockchains. One way to approach this is to limit the ways of changing the state. While Solidity allows arbitrary state modifications at any point of execution, many modern smart contract languages represent smart contract execution as a function from a current state to a new state. This functional nature of modern smart contract languages makes them well-suited for formal reasoning.

The Ethereum Virtual Machine and the Solidity smart contract language remain one of the most used platforms for writing smart contacts. Due to the permissiveness of the underlying execution model and the complexity of the language, verification in this setting is quite challenging. On the other hand, many modern languages such as Acorn,444The Acorn language is an ML-style functional smart contract language currently under development at the Concordium Foundation. Liquidity and Scilla, offer a different execution model and a type system allowing to rule out many errors through type checking. Of course, many important properties are not possible to capture even with powerful type systems of functional smart contract languages. For that reason, to provide even higher guarantees, such as functional correctness, one has to resort to stronger type systems/logics for reasoning about programs and employ deductive verification techniques. Among various tools for that purpose proof assistants provide a versatile solution for that problem.

Proof assistants or interactive theorem provers are tools that allow users to state and prove theorems interactively. Proof assistants often offer some degree of proof automation by implementing decision and semi-decision procedures, or interacting with automated theorem provers (SAT and SMT solvers). Some proof assistants allow for writing user-defined automation scripts, or write extensions using a plug-in system. This is especially important, since many properties of programs are undecidable and providing users with a convenient way of interactive proving while retaining a possibility to do automatic reasoning makes proof assistants very flexible tools for verification of smart contracts.

Existing formalisations of functional smart contract languages mostly focus on meta-theory (Plutus [7], Simplicity [15]) or meta-theory and verification using the deep embedding (Michelson [5]). An exception is Scilla [20], which features verification of particular smart contracts in the Coq proof assistant by means of shallow embedding by hand. Simplicity [15] is a low-level combinator-based functional language and its formalisation allows for translating from deep to shallow embeddings for purposes of meta-theoretic reasoning. None of these developments combines deep and shallow embeddings for a high-level functional smart contract language in one framework or provide an automatic way of converting smart contracts to Coq programs for convenient verification of concrete smart contracts. We are making a step towards this direction by allowing for deep and shallow embeddings to coexist and interact in Coq.

The contributions of this paper are the following:

We develop an approach to verify properties of functional programming languages and of individual programs in one framework. In particular, this approach works for functional smart contract languages and concrete contracts. 2. 2.

We describe a novel way of combining deep and shallow embeddings using the meta-programming facilities of Coq (MetaCoq [3]). 3. 3.

As an instance of our approach, we define the syntax and semantics of $\lambda_{\mathrm{smart}}$ — a core subset of the Acorn language (the deep embedding) and the corresponding translation of $\lambda_{\mathrm{smart}}$ programs into Coq functions (the shallow embedding). 4. 4.

We prove properties of a crowdfunding contract given as a deep embedding (abstract syntax tree) of a $\lambda_{\mathrm{smart}}$ program. 5. 5.

We integrate our shallow embedding with the smart contract execution framework [14] allowing for proving safety and temporal properties of interacting smart contracts.

We discuss the details of our approach in Section 0.2, provide an example of a crowdfunding contract verification in Section 0.3. In Section 0.4 we apply our framework to verify a List module of the Acorn standard library and discuss how our development integrates with the execution framework in Section 0.5. Theorems from Section 0.2.4 and lemmas from Sections 0.3, 0.4 and 0.5 are proved in our Coq development and available at https://github.com/AU-COBRA/ConCert/tree/artefact.

0.2 Our Approach

There are various ways of reasoning about properties of a functional programming language in a proof assistant. First, let us split the properties into two groups: meta-theoretical properties (properties of a language itself) and properties of programs written in the language. Since we are focused on functional smart contract languages and many proof assistants come with a built-in functional language, it is reasonable to assume that we can reuse the programming language of a proof assistant to express smart contracts and reason about their properties. A somewhat similar approach is taken by the authors of the hs-to-coq library [23], which translates total Haskell programs to Coq by means of source-to-source transformation. Unfortunately, in this case, it is impossible to reason about the correctness of the translation.

We would like to have two representations of functional programs within the same framework: a deep embedding in the form of an abstract syntax tree (AST), and a shallow embedding as a Coq function. While the deep embedding is suitable for meta-theoretical reasoning, the shallow embedding is convenient for proving properties of concrete programs. We use the meta-programming facilities of the MetaCoq plug-in [3] to connect the two ways of reasoning about functional programs.

The overview of the structure of the framework is given in Figure 1. As opposed to source-to-source translations in the style of hs-to-coq [23] and coq-of-ocaml555The coq-of-ocaml project page: https://github.com/clarus/coq-of-ocaml we would like for all the non-trivial transformations to happen in Coq. This makes it possible to reason within Coq about the translation and formalise the required meta-theory for the language. That is, we start with an AST of a program in a functional language implemented in Haskell, OCaml or some other language, then we generate an AST represented using the constructors of the corresponding inductive type in Coq (deep embedding) by printing the desugared AST of the program. By printing we mean a recursive procedure that converts the AST into a string consisting of the constructors of our Coq representation. The main idea is that this procedure should be as simple as possible and does not involve any non-trivial manipulations since it will be part of a trusted code base. If non-trivial transformations are required, they should happen within the Coq implementation.

0.2.1 MetaCoq

The MetaCoq project [3] brings together several subprojects united by the use of meta-programming and formalisation of Coq’s meta-theory in Coq. In particular, relevant for this project:

• •

Template Coq — adds meta-programming facilities to Coq. That is, it provides a way to quote Coq definitions by producing an AST represented as an inductive data type term in Coq, and unquote a well-formed inhabitant of term back to a Coq definition.

• •

PCUIC — formalisation of the meta-theory of Polymorphic Cumulative Calculus of Inductive Constructions (PCUIC), an underlying calculus of Coq.666From now on, we will use MetaCoq to refer both to the quote/unquote functionality and to the formalisation of meta-theory.

These features of MetaCoq have been used for defining various syntactic translations from Calculus of Inductive Constructions (CIC) to itself (e.g. parametricity translation [4]), developing a certified compiler CertiCoq [2] and for certifying extraction of Coq terms to the untyped lambda-calculus [10]

Let us consider a simple example demonstrating the quote/unquote functionality.

⬇

(* Quote *)

Quote Definition id_nat_syn := (fun x : nat $\Rightarrow\;$ x).

Print id_nat_syn.

(* tLambda (nNamed "x")

(tInd (mkInd "nat" 0) []) (Ast.tRel 0) : term *)

(* Unquote *)

Make Definition plus_one :=

(tLambda (nNamed "x") (tInd (mkInd "nat" 0 ) [])

       (tApp (tConstruct (mkInd "nat" 0) 1 []) [tRel 0])).

Print plus_one.

(* fun x : nat $\Rightarrow\;$ S x : nat $\rightarrow\;$ nat *)

Our use of MetaCoq explores a new way of using meta-programming in Coq. All existing use cases follow (roughly) the following procedure: start with a Coq term, quote it and perform certain transformations (e.g. syntactic translation, erasure, etc.). In our approach, we go in the different direction: starting with the AST of a program in a functional language we want to reason about, through a series of transformations we produce a MetaCoq AST, which is then unquoted into a program in Coq’s Gallina language (shallow embedding). The transformations include conversion from the named to the nameless representation (if required) and translation into the MetaCoq AST. The deep embedding also serves as input for developing meta-theory of the functional language.

0.2.2 The $\lambda_{\mathrm{smart}}$ Language

As an instance of our approach, we develop an embedding of the “core” of the Acorn smart contract language into Coq. We call this core language $\lambda_{\mathrm{smart}}$. This language contains all the essential features of a realistic functional language: System F type system, inductive types, general recursion and pattern-matching. The grammar of the language is given below.

[TABLE]

Here {\color[rgb]{0,0.1,0.6}{I}}, {\color[rgb]{0,0.1,0.6}{C}}, {\color[rgb]{0,0.1,0.6}{A}}, {\color[rgb]{0,0.1,0.6}{x}} and {\color[rgb]{0,0.1,0.6}{f}} range over strings representing names of inductive types, constructors, type variable names, variable names and fixpoint names respectively. We use de Bruijn indices to represent variables both in expressions and types (denoted {\color[rgb]{0,0.1,0.6}{\overline{i}}} and {\color[rgb]{0,0.1,0.6}{\hat{i}}} respectively). Textual names {\color[rgb]{0,0.1,0.6}{A}}, {\color[rgb]{0,0.1,0.6}{x}} and {\color[rgb]{0,0.1,0.6}{f}} are only needed for decoration purposes making resulting Coq code more readable. Note, that $\lambda_{\mathrm{smart}}$ expressions are extensively annotated with typing information. For instance, we annotate lambda abstractions with the domain type, for fixpoints we store the types for the domain and for the codomain. Moreover, $\<case>$-expressions require explicit type of branches.

The semantics of $\lambda_{\mathrm{smart}}$ is given as a definitional interpreter [18]. This gives us an executable semantics for the language. Moreover, since the core language we consider is sufficiently close to Acorn, our interpreter can serve as a reference interpreter. The interpreter is implemented in an environment-passing style and works both with named and nameless representations of variables. Due to the potential non-termination, we define our interpreter using the fuel idiom: by structural recursion on an additional argument (a natural number). The interpreter function has the following type:777In our development, the interpreter supports two modes of evaluation: with named variables and with de Bruijn representation of variables (nameless). For the purposes of this paper, we will focus on the nameless mode.

⬇

eval : global_env $\rightarrow\;$ nat $\rightarrow\;$ env val $\rightarrow\;$ expr $\rightarrow\;$ res val

We will use the notation $\mathtt{eval}_{\Sigma,\rho}^{n}(e)$ to mean eval$~{}\Sigma~{}$ n $~{}\rho~{}$ e. The global_env parameter provides mappings from names of inductives to their constructors. The next three parameters are: “fuel”, an evaluation environment and a $\lambda_{\mathrm{smart}}$ expression. Note that “fuel” has a different meaning than “gas” for smart contracts: “fuel” is used to limit the recursion depth to ensure termination and not as a measure of computational efforts. The resulting type is res val, where res is a error monad. The errors could be either $\<NotEnoughFuel>$ denoting that fuel provided was not sufficient to complete the execution, or $\<EvalError>$ denoting that execution is stuck. In our Coq development $\<EvalError>$ also carries a error message. Values val are defined as follows:

[TABLE]

Note that we annotate our value with types and variable names. This is required to match the $\lambda_{\mathrm{smart}}$ interpreter with the MetaCoq evaluation relation (see Section 0.2.4).

The outline of the most interesting parts of our interpreter is given in Figure 2. Specifically, we show the evaluation of fixpoints and $\<case>$-expressions. The rest is quite standard and not essentially different from other works using definitional interpreters (e.g. [1]). An essential part of the fixpoint evaluation is how we extend the evaluation environment $\rho$: we evaluate the body of the fixpoint {\color[rgb]{0,0.1,0.6}{e}} in the environment extended with the closure of the fixpoint itself which corresponds to the recursive call. A fixpoint binds two variables: the outermost one corresponds to the recursive call and the innermost is a fixpoint’s argument. Thus evaluating the fixpoint’s body in the environment $v_{2}::v_{1}::\rho$ ensures that once we hit a variable corresponding to the recursive call it will be replaced with the body of the fixpoint again. Note that we perform an additional check if $v_{2}$ is a constructor of an inductive type (possibly applied to some arguments). This is necessary to match the evaluation of $\lambda_{\mathrm{smart}}$ expressions with the MetaCoq evaluation relation. Therefore, it is not possible to pass a function as an argument to a $\lambda_{\mathrm{smart}}$ fixpoint. Although this sounds limiting, the main point of the $\lambda_{\mathrm{smart}}$ semantics is to prove the correctness of the embedding to Coq and fixpoints in Coq are limited to structurally recursive definitions.

When evaluating $\<case>$ expressions, our interpreter first evaluates all the types (parameters of the inductive and the type of branches), then the discriminee, and if the latter evaluates to a constructor, executes a simple pattern-matching algorithm. The $\mathtt{match\_pat}$ function returns a branch that matches the discriminee. Next, we evaluate the body of the selected branch in the environment extended with the reverse list of the constructor’s arguments.

Note that our interpreter evaluates all the type expressions. This is required since we want to match $\lambda_{\mathrm{smart}}$ evaluation with the evaluation relation of MetaCoq, which evaluates corresponding types. The type evaluation function \mathtt{eval\_ty}:\mathtt{env}~{}\mathtt{val}\times\mathtt{{\color[rgb]{0,0.1,0.6}{type}}}->\mathtt{res}~{}\mathtt{{\color[rgb]{0,0.1,0.6}{type}}} essentially just substitutes values from the evaluation environment and fails if there is no corresponding value found.

Note that we perform some validation of expressions against the evaluation environment. This is again required for our soundness result. We will discuss these questions in Section 0.2.4.

0.2.3 Translation to MetaCoq

We define the translations from the AST of $\lambda_{\mathrm{smart}}$ expressions \mathtt{{\color[rgb]{0,0.1,0.6}{expr}}} and types \mathtt{{\color[rgb]{0,0.1,0.6}{type}}} to MetaCoq abstract syntax \mathtt{{{\color[rgb]{0,0.35,0}term}}} by structural recursion.888By MetaCoq \mathtt{{{\color[rgb]{0,0.35,0}term}}} we mean a corresponding inductive type from the PCUIC formalisation. In our Coq development, before unquoting a PCUIC term, we translate it into a kernel representation. This translation is almost one-to-one, apart from the application case: it is unary in PCUIC and n-ary in the kernel representation, but this part is quite straightforward to handle. Eventually, this translation will be included in the MetaCoq project On Figure 3 we outline the translation functions. We use Haskell-like notation and blue colour for $\lambda_{\mathrm{smart}}$ expressions and types and Coq-like notation and green colour for MetaCoq terms. We assume that the global environment $\Sigma:\mathtt{global\_env}$ contains all inductive type definitions mentioned in $\lambda_{\mathrm{smart}}$ expressions. Under this assumption the translation function $\llbracket-\rrbracket^{t}_{\Sigma}$ is total.

In $\lambda_{\mathrm{smart}}$, we have two kinds of de Bruijn indices: the one for type variables {\color[rgb]{0,0.1,0.6}{\hat{i}}} and the one for term variables {\color[rgb]{0,0.1,0.6}{\overline{i}}}. In the translation, we map both of them to the single kind of indices of MetaCoq. Constructors are translated to MetaCoq constructors by first looking up the corresponding constructor number in the global environment. In MetaCoq (and in the kernel of Coq) constructors are represented as numbers corresponding to the position of a constructor in the list of constructors for a given inductive type. The type of global environments $\mathtt{global\_env}$ is a list of definitions of inductive type. The functions

[TABLE]

are used to look up for inductive type and their constructors. Particularly, $\mathtt{resolve\_ind}$ returns a list of constructors for a given textual name of an inductive type, while $\mathtt{resolve\_ctor}$ returns a position of a constructor in the list of constructor definitions and the constructor definition itself. Translation of a $\lambda_{\mathrm{smart}}$ constructor {\color[rgb]{0,0.1,0.6}{C_{I}}} looks up the corresponding constructor position in the list of constructors for the inductive {\color[rgb]{0,0.1,0.6}{I}}, a translated constructor in MetaCoq is basically a number (a position) annotated with the name of the inductive type: {{\color[rgb]{0,0.35,0}C_{I}}} (and universes, but these are not relevant for us right now). In the translation of {\color[rgb]{0,0.1,0.6}{\<fix>}}, the type of a fixpoint is translated into a $\Pi$-type in MetaCoq. Therefore, the indices of free variables in the codomain type must be incremented (“lifted”) by 1, since $\Pi$-types bind a variable. We denote such increments by $n$ as $\uparrow_{n}$. The other feature of the fixpoint translation is that the body of a fixpoint in MetaCoq becomes a lambda abstraction and since all lambda abstractions must be explicitly annotated with a type of the domain, we provide this type. Again, we have to lift free variables in the type, because the outermost variable index corresponds to the body of the fixpoint itself.

By far the most complex translation case is the pattern-matching. The first complication stems to the representation of branches for {{\color[rgb]{0,0.35,0}\<match>}} in MetaCoq: the branches should be arranged in the same order as constructors in the definition of the corresponding inductive type. In this case, there is no need to store constructor names in each pattern. On the other hand, in $\lambda_{\mathrm{smart}}$ we choose more user-friendly implementation: patterns are explicitly named after constructors and might follow in an order that is different from how the order in the inductive type definition. For that reason, we first resolve the inductive type from the global environment to get a list of constructors. Then, for each constructor in the list, we call the $\mathtt{branch}$ function. As one can see from Figure 3, the translated branches follow the same order as in they appear in the list of resolved constructors, i.e. {\color[rgb]{0,0.1,0.6}{c_{1}\ldots c_{m}}}.

The second difficulty arises from the pattern representation. In MetaCoq, patterns are desugared to more basic building blocks: lambda abstractions. Therefore, every pattern becomes an iterated lambda term. Before we explain how the $\mathtt{branch}$ function works, let us first describe the representation of inductive types in the global environment. Each inductive type definition consists of a name, number of parameters, and the list of constructors. In turn, each constructor consists of a name and a list of argument types. Since $\lambda_{\mathrm{smart}}$’s type system does not feature dependent types, it is sufficient to store a list of arguments for each constructor instead of a full type. Each type in the list of constructor arguments can refer to parameters as if they were bound at the top level for each type. For example, the type of finite maps (in the form of association lists) would look like the following (we use concrete syntax here for the presentation purposes):

⬇

data AcornMap $\#$2 = MNil [] | MCons [$\hat{1}$, $\hat{0}$, AcornMap $\hat{1}$ $\hat{0}$]

In the example above, AcornMap has two parameters (the number of parameters is specified after the type name): a type of keys, and a type of values. The MNil constructor does not take any arguments, and MCons takes a key, a value and an inhabitant of AcornMap. Given this representation of constructors, we continue the explanation of the pattern-matching translation. When pattern-matching on a parameterised inductive, the inductive is applied to some parameters. In order to propagate these parameters to the corresponding constructors, we have to substitute the concrete parameters into each type in the constructor arguments list. We use \mathit{t}\big{\{}\mathit{ts}\big{\}} to denote the MetaCoq parallel substitution of a list of terms $\mathit{ts}$ into a term $\mathit{t}$. In the $\mathtt{branch}$ function, we first look up a branch body {\color[rgb]{0,0.1,0.6}{e}} in the list of branches by comparing the constructor name to the pattern name. Next, we project constructor argument types from a given constructor. Further, since patterns become iterated lambdas in MetaCoq, we need to provide a type for each abstracted variable. Since Coq is dependently typed, variables bound by each lambda abstraction might appear in the types that appear later in the term. Thus, to avoid variable capture in types of lambda arguments, we need to lift the translated types. This is exactly what happens in the $\mathtt{branch}$ function: the resulting MetaCoq term is an iterated lambda abstraction and each argument type is lifted according to the number of preceding lambda abstractions in the translation of a pattern.

The translation of types is mostly straightforward. For the universal types, we choose to produce a $\Pi$-type with the domain in {{\color[rgb]{0,0.35,0}\<Set>}}. Such a choice allows us to avoid dealing with universe levels explicitly, as it is required in MetaCoq. The translation we present works only for a predicative fragment of $\lambda_{\mathrm{smart}}$, but Acorn’s surface language supports only a prenex form of universal types, where all the quantifiers appear at the topmost level. Therefore, this is not a limitation from a practical point of view. Another thing to note is that the translation of definitions of inductive types is not shown in Figure 3, although it is implemented in our Coq development. Instead of giving the full translation in the paper (which involves subtle de Bruijn indices manipulations), let us consider an example. We continue with the finite maps AcornMap. The tricky bit in the translation is to produce a correct type for each constructor considering the number of parameters and taking into account that each $\Pi$-type binds a new variable. Moreover, in MetaCoq the inductive type being defined becomes a topmost variable as well.

The resulting MetaCoq definition of AcornMap (again, in the concrete syntax, but with explicit indices in place of variable names) looks as follows:

⬇

Inductive AcornMap (A1 A2 : Set) :=

| MNil : {{\color[rgb]{0,0.35,0}\overline{2}}} {{\color[rgb]{0,0.35,0}\overline{1}}} {{\color[rgb]{0,0.35,0}\overline{0}}}

| MCons : forall (_ : {{\color[rgb]{0,0.35,0}\overline{1}}}) (_ : {{\color[rgb]{0,0.35,0}\overline{1}}}) (_ : {{\color[rgb]{0,0.35,0}\overline{4}}} {{\color[rgb]{0,0.35,0}\overline{3}}} {{\color[rgb]{0,0.35,0}\overline{2}}}), {{\color[rgb]{0,0.35,0}\overline{5}}} {{\color[rgb]{0,0.35,0}\overline{4}}} {{\color[rgb]{0,0.35,0}\overline{3}}},

Let us consider the type of MNil. The index {{\color[rgb]{0,0.35,0}\overline{2}}} refers to the topmost variable being the inductive type itself, index {{\color[rgb]{0,0.35,0}\overline{1}}} refers to the parameter A1 and {{\color[rgb]{0,0.35,0}\overline{0}}} to the parameter A2.

Our Coq development contains the definition of AcornMap using the deep embedding as well as standard operations of finite maps.999See theories/examples/FinMap.v file in our Coq development Moreover, we demonstrate how one can covert definitions, given as a deep embedding, to regular Coq definitions by translating and unquoting them. In the same time, one can run programs directly on deep embedding using the interpreter (Figure 2).

0.2.4 Translation Soundness

Since the development of the meta-theory of Coq itself is one of the aims of MetaCoq we can use this development to show that the semantics of $\lambda_{\mathrm{smart}}$ agrees with its translation to MetaCoq (on terminating programs). The idea is to compare the results of the evaluation of $\lambda_{\mathrm{smart}}$ expressions with the weak head call-by-value evaluation relation of MetaCoq up to the appropriate conversion of values. This conversion of values is a non-trivial procedure: $\lambda_{\mathrm{smart}}$ values contain closures, while the MetaCoq evaluation relation is substitution based and produces a subset of terms in the weak head normal form. Therefore, if we want to eventually convert $\lambda_{\mathrm{smart}}$ values to MetaCoq terms, first, we need to substitute environments into the closures’ bodies. E.g. for $\mathtt{vClosLam}(\rho,x,\tau,e)$ we need to substitute all the values from $\rho$ into $e$. This is not possible to do directly, because we cannot substitute values into expressions. Thus, we need to convert all the values to expressions in the environment $\rho$. But this, in turn, requires substituting environments in closures again. To break this circle, we take inspiration from [11] and first define substitution functions purely on $\lambda_{\mathrm{smart}}$ expressions and types:

[TABLE]

These functions implement parallel substitution of the environment represented as a list of expressions. Unfortunately, these functions are partial, due to the fact that we use one environment for term-level values and for type-level-values. We can make this function total by imposing a well-formedness condition. With these substitution operations we now can define a conversion procedure from $\lambda_{\mathrm{smart}}$ values back to expressions:

[TABLE]

Once we have a way of converting values to expressions, we can use the translation function $\llbracket-\rrbracket^{t}$ to produce MetaCoq terms. This gives us a direct way of comparing the evaluation results. Before we state the soundness theorem, we give an overview of some important lemmas forming a core of the proof. First of all, let us mention certain well-formedness conditions for the environments involved in our definitions. It is very important to carefully set up these conditions before approaching the soundness proof.

Definition 1**.**

For a global environment $\Sigma:\mathtt{global\_env}$, evaluation environment \rho:\mathtt{env}~{}\mathtt{{\color[rgb]{0,0.1,0.6}{expr}}} and $\lambda_{\mathrm{smart}}$ value $v:\mathtt{val}$ we say that

1. (WF.i)

$\Sigma$* is well-formed if for all definitions of inductive types, each constructor type is closed for the given number of parameters of the inductive type. E.g. if an inductive type has $n$ parameters, then the type of each constructor has at most $n$ free variables.* 2. (WF.ii)

$\rho$* is well-formed wrt. an expression $e$ when for any type variables mentioned in $e$, if there is a corresponding expression in $\rho$ it corresponds to a type.* 3. (WF.iii)

a value $v$ is well-formed if all the expressions and types in the closures are appropriately closed wrt. corresponding environments in closures and $\rho$ is well-formed in the sense of (WF.ii). E.g. for $\mathtt{vClosLam}(\rho,x,\tau,e)$ we have: $\rho$ contains only well-formed values, $e$ has at most $|\rho|+1$ free variables ($|\rho|$* is the size of $\rho$), $\tau$ is closed type value, and $\rho$ is well-formed wrt. $e$. Additionally, for $\mathtt{vConstr}(I,C,\mathit{args})$, we require that $\mathtt{resolve\_ctor}(\Sigma,I,C)$ returns some value.*

Now, we will state several lemmas crucial for the soundness proof. We will emphasise the use of the conditions (WF.i),(WF.ii) and (WF.iii) throughout these lemmas. We will use the following additional notations: \mathit{t}\big{\{}\mathit{ts}\big{\}} for the MetaCoq parallel substitution as in the translation, $\llbracket\rho\rrbracket^{t}_{\Sigma}$ for translation of all the expressions in $\rho$ from $\lambda_{\mathrm{smart}}$ to MetaCoq and $|\rho|$ for the environment size.

Lemma 1** (Environment substitution).**

For any $\lambda_{\mathrm{smart}}$ expression $e$, well-formed global environment $\Sigma$ (WF.i), well-formed environment $\rho$ wrt. $e$ (WF.ii), such that all the expressions in $\rho$ are closed the following holds

[TABLE]

Lemma 1 says that environment substitution commutes with the translation. The well-formedness condition on $\rho$ ensures that the environment substitution functions are total.

Lemma 2** (Well-formed values).**

For any $\lambda_{\mathrm{smart}}$ expression $e$, such that $e$ has at most $|\rho|$ free variables, number of steps $n$, well-formed evaluation environment $\rho$, such that all the values in $\rho$ are well-formed, if evaluation of $e$ terminates with some value $v$, i.e. $\mathtt{eval}_{\Sigma,\rho}^{n}(e)=\<Ok>~{}v$, then the value $v$ is well-formed ((WF.iii)).

In the interpreter in Figure 2 we perform certain dynamic checks denoted by $\mathtt{validate}$ and $\mathtt{validate\_branches}$. These checks ensure that the condition (WF.iii) is satisfied for values produces by the interpreter. For well-typed expressions, this condition would be automatically satisfied, but currently, we focus on dynamic semantics.

We use the interpreter for $\lambda_{\mathrm{smart}}$ expressions and call-by-value evaluation relation of MetaCoq to state the soundness theorem. The MetaCoq evaluation relation is a subrelation of the transitive reflexive closure of the one-step reduction relation and designed to represent the evaluation of ML languages at Coq level.

Theorem 1** (Soundness).**

For any $\lambda_{\mathrm{smart}}$ expression $e$, number of steps $n$, well-formed global environment $\Sigma$, evaluation environment $\rho$, such that all the values in $\rho$ are well-formed and $e[\rho]$ is closed, if $\mathtt{eval}_{\Sigma,\rho}^{n}(e)=\<Ok>~{}v$, for some value $v$, then $\llbracket e[\rho]\rrbracket^{t}_{\Sigma}\Downarrow\llbracket\mathtt{of\_val}(v)\rrbracket^{t}_{\Sigma}$, where $-\Downarrow-$ is the call-by-value evaluation relation of MetaCoq.

Proof.

By induction on the number of steps of the interpreter $n$. The base case is trivial, since we assume that the interpreter terminates. In the inductive step, the proof proceeds by case analysis on $e$ using Lemma 1 in the cases involving substitution (e.g. cases for let, application and $\<case>$-expressions) and using Lemma 2 to obtain premises that all the values in $\rho$ are well-formed required for applying induction hypotheses. ∎

Corollary 1** (Soundness for closed expressions).**

For any closed $\lambda_{\mathrm{smart}}$ expression $e$, number of steps $n$, well-formed global environment $\Sigma$, if $\mathtt{eval}_{\Sigma,[]}^{n}(e)=\<Ok>~{}v$, then $\llbracket e\rrbracket^{t}_{\Sigma}\Downarrow\llbracket\mathtt{of\_val}(v)\rrbracket^{t}_{\Sigma}$.

Proof.

By Theorem 1, using the fact that the empty evaluation environment is trivially well-formed and the fact that substituting the empty environment does not change $e$. ∎

We can see our translation to MetaCoq as some form of denotational semantics. With this view, we can obtain the adequacy result.

Theorem 2** (Adequacy for terminating programs).**

For any closed $\lambda_{\mathrm{smart}}$ expression $e$, well-formed global environment $\Sigma$, if evaluation of $e$ terminates with value $v$ in $n$ steps and $\llbracket e\rrbracket^{t}_{\Sigma}\Downarrow t$ for some term $t$, then $t=\llbracket\mathtt{of\_val}(v)\rrbracket^{t}_{\Sigma}$.

Proof.

By Corollary 1, using the fact that the MetaCoq evaluation relation is deterministic. ∎

Theorem 2 readily allows, for example, transferring program equivalence from MetaCoq derivations to the $\lambda_{\mathrm{smart}}$ interpreter, provided that the values are not higher-order (i.e. not closures).

In general, we conjecture that one can show adequacy for any program for which there exists a derivation of the MetaCoq big-step evaluation relation. Such a theorem should be stated for well-typed $\lambda_{\mathrm{smart}}$ expressions. Moreover, transferring properties proved for Coq functions to the corresponding evaluations using the interpreter in general also requires resorting to the typing argument. Currently, we do not formalise static semantics and leave these points as future work.

We assume that the unquote functionality of MetaCoq is implemented correctly. From that perspective, unquote becomes part of the trusted computing base, but we would like to emphasise that one of the goals of the MetaCoq project is to implement the actual kernel of Coq in Coq itself. The current MetaCoq data type term corresponds directly to the constr data type from Coq’s kernel. Therefore, unquote is a straightforward one-to-one mapping of MetaCoq data types to the corresponding OCaml data types of Coq’s kernel. This is in contrast to projects like hs-to-coq and coq-of-ocaml for which the whole translation has to be trusted.

We developed a full formalisation of theorems and lemmas presented in this section in our framework in Coq. We do not use any extra axioms throughout our development, but Theorem 2 uses the determinism of the MetaCoq evaluation relation and the proof of this fact is currently under development in the MetaCoq project. Being able to relate the semantics of $\lambda_{\mathrm{smart}}$ to the semantics of Coq through Coq’s meta-theory formalisation gives strong guarantees that our shallow embedding reflects the actual behaviour of $\lambda_{\mathrm{smart}}$. The described approach provides a more principled way of embedding of functional languages than the source-to-source based approaches. Moreover, the translation involves manipulation of de Bruijn indices, which is often quite hard to get right. Various mistakes in non-trivial places were discovered and fixed in the course of the formalisation.

0.3 The Crowdfunding Contract

As an example of our approach, we consider verification of some properties of a crowdfunding contract (Figure 4). Such a contract allows arbitrary users to donate money within a deadline. If the crowdfunding goal is reached, the owner can withdraw the total amount from the account after the deadline has passed. Also, users can withdraw their donations after the deadline if the goal has not been reached. Contracts like this are standard applications of smart contracts and appear in a number of tutorials.101010The idea of a crowdfunding contract appears under different names: crowdsale, Kickstarter-like contract, ICO contract, etc. Many Ethereum-related resources contain variations of this idea in tutorials (including Solidity and Vyper documentation). A simplified version of a crowdfunding contract is also available for Liquidity: https://github.com/postables/Tezos-Developer-Resources/blob/master/Examples/Crowdfund/Basic.ml We follow the example of Scilla [20] and adopt a variant of a crowdfunding contract as a good instance to demonstrate our verification techniques.

We extensively use a new feature of Coq called “custom entries” to provide a convenient notation for our deep embedding.111111Custom entries are available starting from Coq 8.9.0. The program texts in Figure 4 written inside the special brackets [\ … ], [| … |], and [! … !] are parsed according to the custom notation rules. For example, without using notations the definition of action_syn looks as follows:

⬇

gdInd Action 0 [("Transfer", [(nAnon, tyInd "nat");

              (nAnon, tyInd "nat")]);("Empty", [])] false.

This AST might be printed directly from the smart contract AST by a simple procedure (as we use in Section 0.4). We start by defining the required data structures such as State and Msg meaning contract state and messages accepted by this contract. We pre-generate string constants for corresponding names of inductive types, constructors, etc. using the MetaCoq template monad.121212The template monad is a part of the MetaCoq infrastructure. It allows for interacting with Coq’s global environment: reading data about existing definitions, adding new definitions, quoting/unquoting definitions, etc. This allows for more readable presentation using our notation mechanism. Currently, we use the nat type of Coq to represent account addresses and currency. Eventually, these types will be replaced with corresponding formalisations of these primitive types. We also use abbreviations for the result type and for certain types from the blockchain infrastructure, which we are going to explain later.

The trans_global_dec : global_dec $\rightarrow\;$ mutual_inductive_entry

function takes the syntax of the data type declarations and produces an element of mutual_inductive_entry — a MetaCoq representation for inductive types. For each of our deeply embedded data type definitions, we produce corresponding definitions of inductive types in Coq by using the Make Inductive command of MetaCoq that “unquotes” given instances of the mutual_inductive_entry type. Similar notation mechanism is used to write programs using the deep embedding. The definition of crowdfunding represents a syntax of the crowdfunding contract. We translate the crowdfunding contract’s AST into a MetaCoq AST using the expr_to_term : global_env $\rightarrow\;$ expr $\rightarrow\;$ term function (corresponding to $\llbracket-\rrbracket^{t}_{\Sigma}$ in Figure 3). Here, global_env is a global environment containing declarations of inductive types used in the function definition, expr is a type of $\lambda_{\mathrm{smart}}$ expressions, and term is a type of MetaCoq terms. Before translating the $\lambda_{\mathrm{smart}}$ expressions, we apply the indexify function that converts named variables into de Bruijn indices. The result of these transformations is unquoted with the Make Definition command. After unquoting the translated definitions, they are added to Coq’s global environment and available for using as any other definitions. The crowdfunding contract consists of two functions:

⬇

init : SimpleContractCallContext $\rightarrow\;$ nat $\rightarrow\;$ Z $\rightarrow\;$ State_coq

receive : SimpleChain $\rightarrow\;$ SimpleContractCallContext

        $\rightarrow\;$ Msg_coq $\rightarrow\;$ State_coq

        $\rightarrow\;$ option (State_coq × list SimpleActionBody)

Here SimpleChain is a “contract’s view” of a blockchain allowing for accessing, among other parameters, current slot number (used as a current time); SimpleContractCallContext is a contract call context containing transferred amount, sender’s address and other information available for inspection during the contract call. The type names with the “coq” suffix correspond to the unquoted data types from the Figure 4.

The init function sets up an initial state for a given deadline and goal. The receive function corresponds to a transition from a current state of the contract to a new state. We will provide more details about the execution model in Section 0.5. In the current section we focus on functional correctness properties using pre- and post-conditions. Similarly to [20], we prove a number of properties of the contract using the shallow embedding:

1. (P.i)

the contract receive function preserves the following invariant (unless the “done” flag is set to true): the sum of individual contributions is equal to the balance recorded in the contract’s state; 2. (P.ii)

the donations can be paid back to the backers if the goal is not reached within a deadline; 3. (P.iii)

donations are recorded correctly in the contract’s state; 4. (P.iv)

backers cannot claim their contributions if the campaign has succeeded.

The lemma corresponding to the property (P.i) is given below.

⬇

Lemma contract_state_consistent BC CallCtx msg :

{{ consistent_balance }}

  receive BC CallCtx msg

{{ fun fin txs $\Rightarrow\;$ consistent_balance fin }}.

In the example above we use the Hoare triple notation {{P}}c{{Q}} to state pre- and post-conditions for the state before and after the contract call. The post-condition also allows for stating properties of outgoing transactions. We define consistent_balance as follows:

⬇

Definition consistent_balance (lstate : State_coq) :=

$\sim$ lstate.(done_coq) $\rightarrow\;$

sum_map (donations_coq lstate) = balance_coq lstate.

i.e. the contract balance is consistent if before the contract is marked as “done” the sum of individual contributions is equal to the balance.

Given the definitions above, one can read the lemma in the following way: if the balance was consistent in some initial state, then execution of the receive method gives a new state in which the balance is again consistent. Note that the receive is a “regular” Coq function and it is a shallow embedding of the corresponding crowdfunding definition (Figure 4) produced automatically by our translation.

0.4 Verifying Standard Library Functions

In our Coq development, we show how one can verify Acorn library code by proving $\lambda_{\mathrm{smart}}$ functions (obtained by printing the Acorn AST as $\lambda_{\mathrm{smart}}$ AST) equivalent to the corresponding functions from the standard library of Coq. In particular, we provide an example of such a procedure for certain functions on lists. The similar approach is mentioned as a strong side of Coq in comparison to Liquid Haskell [27]. In general, our framework will be applicable for verification of standard libraries of various functional languages (not even necessarily languages for smart contracts) since data types such as lists, trees, finite maps, etc. are ubiquitous in functional programming. In addition, $\lambda_{\mathrm{smart}}$ is essentially a pure fragment of various functional general-purpose languages (ML-family, Elm) and smart contract languages (Liquidity, Simplicity, Sophia131313A functional smart contract language based on ReasonML: https://dev.aepps.com/aepp-sdk-docs/Sophia.html) making it a good target for integration.

Figure 5 shows how we obtain the shallow embedding from the $\lambda_{\mathrm{smart}}$ List module of the Acorn standard library. We start with the concrete syntax (Figure 5(a)). Next, from the Acorn parser, which is a part of the Concordium infrastructure, we obtain an AST. This AST is printed to obtain a Coq representation (which we call $\lambda_{\mathrm{smart}}$) using a simple printing procedure implemented in Haskell (Figure 5(b)). From the module AST in Coq we produce a shallow embedding by using the translation described in Section 0.2.3 and the TemplateMonad of MetaCoq to unquote all the definitions in the module. We use translateData and translateDefs function to translate and unquote all the definitions of data types and functions respectively. The translateDefs is defined as follows:

⬇

Fixpoint translateDefs ($\mathrm{\Sigma}$ : global_env) (es : list (string * expr))

: TemplateMonad unit:=

match es with

| [] $\Rightarrow\;$ tmPrint "Done."

| (name, e) :: es’ $\Rightarrow\;$

coq_expr $\leftarrow\;$ tmEval all (expr_to_term $\mathrm{\Sigma}$ (reindexify 0 e)) ;;

print_nf ("Unquoted: " ++ name);;

tmMkDefinition name coq_expr;;

translateDefs $\mathrm{\Sigma}$ es’

end.

The expr_to_term $\mathrm{\Sigma}$ corresponds to $\llbracket-\rrbracket^{t}_{\Sigma}$ from Figure 3. In the Acorn AST received from the parser, the index spaces for type variables and term variables are separated. We merge them into a single index space with the reindexify function. Finally, tmMkDefinition unquotes the translated MetaCoq term and adds it to the Coq environment. After that, we can interact with the unquoted definitions as if they were written by hand.

On the shallow embedding we establish an isomorphism between Acorn lists and Coq lists by defining two functions to_acorn and from_acorn composing to identity. We can state the following: foldr f a l = fold_right f a(from_acorn l) where foldr is an Acorn function and fold_right comes from the standard library of Coq. Similarly for the list concatenation. Now, we can transfer properties of these functions without the need of reproving:

⬇

Lemma foldr_concat (A B : Set) (f : A $\rightarrow\;$ B $\rightarrow\;$ B)

                  (l l’ : AcornList A) (i : B) :

foldr f i (concat l l’) = foldr f (foldr f i l’) l.

Proof. autorewrite with hints;apply fold_right_app. Qed.

Currently, we use autorewrite to automate such proofs, but in the future, we consider using more principled techniques like [25].

0.5 The Execution Framework

In the context of blockchains smart contracts are small programs that are published to the nodes of the system and associated with some address. Calls happen when a transaction is made to this address and nodes execute the program when seeing such a transaction, which additionally can contain input parameters to the program. Smart contracts typically survive across calls and are thus long-lived stateful objects that end up being executed multiple times. In addition smart contracts interact with the blockchain in various ways, for example by making calls to other smart contracts or by transferring money owned by the smart contract into other accounts. The blockchain software thus keeps track of extra information about the smart contract: its monetary balance and the local state that the particular smart contract wishes to persist between calls.

For these reasons it does not suffice to prove only functional correctness properties if one wants to achieve strong guarantees. As an example, we would like to prove that the crowdfunding contract in Figure 4 has enough money when it attempts to pay back the funders. Here simple functional correctness is uninteresting since the crowdfunding contract just takes its own balance as an input to the function. Instead we would like a more comprehensive model of a blockchain capturing the semantics of transactions that affect state such as the balance. Such a model is given in [14] which provides a Coq formalization of a small-step operational semantics of blockchain execution. In this framework one can reason about multiple deployed and interacting contracts with the system tracking the balance and local state of each contract. This small-step semantics is used to define a trace type, and we can specify our stronger safety properties as properties that hold for any blockchain state reachable through a trace. Here we differentiate between blockchain state, which is the full state of the entire blockchain, and local state, which simply is the state that some particular contract wants the blockchain to persist for it. Logically the local state of a smart contract is one part of the blockchain state, but the blockchain state also contains information like the balance of each account in the system. By using the traces it is furthermore possible to define temporal properties.

As a running example, we continue with the crowdfunding contract from Section 0.3. We demonstrate how the property (P.i) (Section 0.3) can be transformed into a safety property and prove that the balance stored in the internal state of the contract is always less or equal to the actual balance recorded in the blockchain state.

In [14] contracts are represented as two functions init and receive. The init function is called when the contract is deployed and allows the contract to establish its initial local state, while the receive function is called after deployment when transactions are sent to the contract. These functions are provided with information about the blockchain and the receive function allows the contract to interact with the blockchain more actively, such as by making transactions to other accounts. The init and receive functions are partial allowing contracts to communicate that they were called with invalid parameters.

To be able to state lemmas, we need to do some extra work by wrapping the functions init and receive from Figure 4 to have compatible signatures. In the execution framework, these functions take Chain and ContractCallContext types that are generalized over the type of addresses used. For our particular contract we use “plain” inductive types SimpleChain and SimpleContractCallContext for which addresses are always natural numbers. Thus we instantiate the execution framework’s addresses as natural numbers and then define conversion functions between the types from the execution framework and the simple variants used by the crowdfunding contract. In effect the resulting functions have the following types:

⬇

wrapped_init : Chain $\rightarrow\;$ ContractCallContext

                $\rightarrow\;$ Setup

                $\rightarrow\;$ option State_coq

wrapped_receive : Chain $\rightarrow\;$ ContractCallContext

                $\rightarrow\;$ State_coq $\rightarrow\;$ option Msg_coq

                $\rightarrow\;$ option (State_coq * list ActionBody)

The Setup type here is just for packing together parameters to the init function: deadline and goal. Another requirement for using the execution framework is to provide instances for serialisation/deserialisation of the local state (State_coq) and messages (Msg_coq). These instances can be automatically generated by the execution framework for the simple non-recursive data types used in the crowdfunding contract. With these instances in place, we can put together init and receive to define a contract:

⬇

Definition cf_contract : Contract Setup Msg_coq State_coq :=

build_contract wrapped_init init_proper wrapped_receive receive_proper.

Here init_proper and receive_proper are proofs showing that the wrapped functions respect extensional equality on the input parameters.

Now we are ready to formulate a safety property of the crowdfunding contract:

⬇

Lemma cf_balance_consistent bstate cf_addr lstate :

reachable bstate $\rightarrow\;$

env_contracts bstate cf_addr = Some (cf_contract : WeakContract) $\rightarrow\;$

cf_state bstate cf_addr = Some lstate $\rightarrow\;$

consistent_balance lstate.

One can read this lemma as follows: for any reachable blockchain state bstate, for an instance of the crowdfunding contract deployed at the address cf_addr with some local state lstate, the balance recorded in the local state is consistent with the map of individual contributions.

Next, we state and prove the following lemma:141414The lemma presented in the paper is a corollary of a more general theorem which generalises over any outstanding actions, somewhat similarly to a theorem about the Congress contract in [14]. We leave out the details here, but full proofs of all the lemmas from this section is available in our Coq development.

⬇

Lemma cf_backed_after_block {ChainBuilder : ChainBuilderType}

      prev hd acts new cf_addr lstate :

builder_add_block prev hd acts = Some new $\rightarrow\;$

env_contracts new cf_addr = Some (cf_contract : WeakContract) $\rightarrow\;$

cf_state new cf_addr = Some lstate $\rightarrow\;$

(account_balance (env_chain new) cf_addr>=balance_coq lstate)%Z.

This lemma says that after adding a new block,151515For our purpose a block can be thought of as just a list of transactions. for any instance of the crowdfunding contract deployed at the address cf_addr, the actual contract balance (the one recorded in the blockchain state) is greater or equal to the balance recorded in the local state (used in all operations of the contract’s “logic”). In essence our integration with the execution framework allows us to prove that the contract tracks its own balance correctly even in the face of potential reentrancy or nontrivial interactions with other contracts and accounts. This is unlike previous work such as [20] which only considers a single contract in isolation, or [5], which focuses on functional correctness properties. This lemma in combination with cf_balance_consistent also gives a formal argument that the contract’s account has enough money to cover all individual contributions.

Having our shallow embedding integrated with the execution framework, one can imagine many more important safety and temporal properties of the contract. For example, if the contract is funded, there will ever be at most one outgoing transaction (to the owner), or if the contract is not funded and the deadline has passed users can get their contributions back. We leave this for future work.

0.6 Related Work

In this work, we focus on modern smart contract languages based on a functional programming paradigm. In many cases, various small errors in smart contracts can be ruled out by the type systems of these languages. Capturing more serious errors requires employing such techniques as deductive verification (for verification of concrete contracts) and formalisation of meta-theory (e.g. to ensure the soundness of type systems). The formalisation of the Simplicity language [15] features well-developed meta-theory, including a formalisation of the operational semantics of the Bit Machine allowing for reasoning about computational resources. But this formalisation does not focus on using the shallow embedding for proving properties of smart contracts and Simplicity is a low-level language in comparison to $\lambda_{\mathrm{smart}}$ (Simplicity is a non-Turing-complete first-order language and does not feature algebraic data types).

The work on Scilla [20] focuses on verification of concrete smart contracts in Coq. It considers a crowdfunding smart contract example translated into Coq by hand, and the correspondence to Scilla’s meta-theory is not clear. A recent paper on Scilla [21] gives a formal definition of the language semantics, but does not feature mechanised proofs.

The formalisation of the Plutus Core language [7] covers the meta-theory of System $F_{\omega}^{\mu}$ — a polymorphic lambda calculus with higher-order kinds and iso-recursive types. The main difference with $\lambda_{\mathrm{smart}}$ is the absence of “native” inductive types. Another work on Plutus [17] shows how to compile inductive types into System $F_{\omega}^{\mu}$. The compilation procedure is type-preserving (which follows from the intrinsic encoding used in the formalisation); computational soundness is left as future work.

The Michelson language formalisation [5] defines an intrinsic encoding of the language expression along with its interpreter in Coq. The Coq development uses a weakest precondition calculus on deeply-embedded Michelson expressions for smart contract verification. The semantics of the Liquidity language given in [6] provides the rules for compilation to Michelson, but there is no corresponding formalisation in a proof assistant. The Sophia smart contract language also belongs to the family of functional smart contract languages based on ReasonML, but there is no corresponding formalisation available.

There are several well-developed formalisations of variations of System $F$  [12, 24, 11, 28]. Among these, [11] features an interpreter and helped us to shape our representation of the language in Coq.

The purpose of the Program tactic in Coq [16, 22] is to embed a functional language into Coq allowing for writing specifications in types. Our work can be seen as the first step towards making a certified version of such a tactic.

Finally, meta-programming techniques have also been shown to be useful in the dependently typed setting in other proof assistants: Agda’s Reflection library [26], meta-programming frameworks in Lean [9] and Idris [8] employ techniques similar to MetaCoq.

0.7 Conclusion and Future Work

We have presented the ConCert smart contract verification framework. An important feature of our approach is the ability to both develop a meta-theory of a smart contract language and to conveniently reason about particular programs (smart contracts). We proved soundness theorems relating meta-theory of the smart contract language with the embedding. Such an option is usually not available for source-to-source translations. We applied our approach to the development of an embedding of the $\lambda_{\mathrm{smart}}$ smart contract language and provided a verification example of a crowdfunding contract starting from the contract’s AST. We also demonstrated how our framework can be used to verify “standard library” functions common to functional programming languages by proving them equivalent to Coq standard library functions. Moreover, we integrated the shallow embedding with the smart contract execution framework which gives access to properties related to the interaction of smart contracts with the underlying blockchain and with each other. Our work addresses a number of future work points from a recent Scilla paper [21]: we provide a shallow embedding, integrate it with a reasoning framework for safety and temporal properties and implement a reference evaluator in Coq. To the best of our knowledge, the ConCert framework together with the execution model described in Section 0.5 is the first development allowing to verify functional smart contracts against a blockchain execution model by automatic translation to the shallow embedding.

Our framework is general enough to be applied to other functional smart contract languages. We consider benchmarking our development by developing “backends” for translation of other languages (e.g. Liquidity, Simplicity, etc.). Extending the formalisation of the $\lambda_{\mathrm{smart}}$ language meta-theory is also among our goals for the framework. An important bit of the meta-theory is the cost semantics allowing for reasoning about “gas”. We would like to give a cost semantics for the deep embedding and explore how it can be extended on the shallow embedding. Another line of future work is extending Acorn with specification annotations similar to the Russell language [22] used for Coq’s Program tactic. That would allow programmers to specify properties of smart contract that become obligations in the resulting Coq translation.

Acknowledgments

We would like to thank the Oak/Acorn team for discussions about the language.

.8 A Counter contract in Acorn

We show how one can obtain the shallow embedding of a simple contract in Acorn and verify some properties using our framework.161616This example is available in the theories/examples/AcornExamples.v file of our Coq development https://github.com/AU-COBRA/ConCert/tree/artefact First, we start with a Acorn program written in concrete syntax.

⬇

module Counter where

import Prim

import Prod

import Blockchain

import Maybe

data Msg = Inc [Int64] | Dec [Int64]

data CState = CState [Int64, {address}]

definition owner (s :: CState) =

case s of

 CState _ d $\rightarrow\;$ d

definition balance (s :: CState) =

case s of

 CState x _ $\rightarrow\;$ x

definition count (c :: Blockchain.ReceiveContext) (s :: CState)

             (callerOr :: Blockchain.Caller)

             (amount :: Amount) (msg :: Maybe.Maybe Msg) =

case msg of

Maybe.Nothing $\rightarrow\;$ Prod.Pair [CState] [Prim.Transaction] s Prim.TxNone

Maybe.Just msg0 $\rightarrow\;$

  case msg0 of

    Inc a $\rightarrow\;$

      let newS =CState (Prim.plusInt64 (balance s) a) (owner s) in

      Prod.Pair [CState] [Prim.Transaction] newS Prim.TxNone

    Dec a $\rightarrow\;$

      let newS = CState (Prim.minusInt64 (balance s) a) (owner s)

      in Prod.Pair [CState] [Prim.Transaction] newS Prim.TxNone

From the printing procedure implemented in Haskell that takes the AST of an Acorn program as input, we obtain a $\lambda_{\mathrm{smart}}$ AST of data type definitions and functions corresponding to the Counter module.

⬇

Definition CounterData := [gdInd "Msg" 0 [("Inc_coq", [(None, tyInd "Z")]); ("Dec_coq", [(None, tyInd "Z")])] false; gdInd "CState" 0 [("CState_coq", [(None, tyInd "Z");(None, tyInd "string")])] false].

⬇

Definition CounterFunctions := [ ("owner", eLambda "x" ((tyInd

"CState")) (eCase ("CState", []) (tyInd "string") (eRel 0)

[(pConstr "CState_coq" ["x0";"x1"], eRel 0)])) ;("balance",

eLambda "x" ((tyInd "CState")) (eCase ("CState", []) (tyInd "Z")

(eRel 0) [(pConstr "CState_coq" ["x0";"x1"], eRel 1)])); ("count",

eLambda "x" ((tyInd "ReceiveContext")) (eLambda "x" ((tyInd

"CState")) (eLambda "x" ((tyInd "Caller")) (eLambda "x" (tyInd

"nat") (eLambda "x" ((tyApp (tyInd "Maybe") ((tyInd "Msg"))))

(eCase ("Maybe", [(tyInd "Msg")]) ((tyApp (tyApp (tyInd "Pair")

((tyInd "CState"))) ((tyInd "Transaction")))) (eRel 0) [(pConstr

  "Nothing_coq" [], eApp (eApp (eApp (eApp (eConstr "Pair"

  "Pair_coq") (eTy ((tyInd "CState")))) (eTy ((tyInd

  "Transaction")))) (eRel 3)) (eConst "TxNone")); (pConstr

  "Just_coq" ["x0"], eCase ("Msg", []) ((tyApp (tyApp (tyInd

  "Pair") ((tyInd "CState"))) ((tyInd "Transaction")))) (eRel 0)

  [(pConstr "Inc_coq" ["x0"], eLetIn "x" (eApp (eApp (eConstr

    "CState" "CState_coq") (eApp (eApp (eConst "plusInt64") (eApp

    (eConst "balance") (eRel 5))) (eRel 0))) (eApp (eConst

    "owner") (eRel 5))) ((tyInd "CState")) (eApp (eApp (eApp (eApp

    (eConstr "Pair" "Pair_coq") (eTy ((tyInd "CState")))) (eTy

    ((tyInd "Transaction")))) (eRel 0)) (eConst "TxNone")));

    (pConstr "Dec_coq" ["x0"], eLetIn "x" (eApp (eApp (eConstr

    "CState" "CState_coq") (eApp (eApp (eConst "minusInt64") (eApp

    (eConst "balance") (eRel 5))) (eRel 0))) (eApp (eConst

    "owner") (eRel 5))) ((tyInd "CState")) (eApp (eApp (eApp (eApp

    (eConstr "Pair" "Pair_coq") (eTy ((tyInd "CState")))) (eTy

    ((tyInd "Transaction")))) (eRel 0)) (eConst

    "TxNone")))])]))))))].

We assume that primitive data types are available for the translation:

⬇

Module Prim.

Inductive Transaction := txNone.

Definition plusInt64 := Z.add.

Definition minusInt64 := Z.sub.

Definition TxNone := txNone.

End Prim.

Next, we import Acorn “standard library” definitions before unquoting. These definitions were also produced by the same printing procedure.

⬇

Import Prim.

Import AcornProd.

Import AcornMaybe.

Import AcornBlockchain.

Now, we add all the data types, required for translating count, to the global environment.

⬇

Definition gEnv := ((StdLib.$\mathrm{\Sigma}$ ++ AcornMaybe.Data ++ AcornBlockchain.Data ++ AcornProd.Data ++ CounterData)%list).

We translate data types and the counter contract to MetaCoq and unquote them using the template monad.

⬇

Run TemplateProgram (translateData CounterData).

Run TemplateProgram (translateDefs gEnv CounterFunctions).

After that, we can interact with the shallow embedding in a usual way.

⬇

Print Msg.

(* Inductive Msg : Set := Inc_coq : Z $\rightarrow\;$ Msg | Dec_coq : Z $\rightarrow\;$ Msg *)

Print count.

(* count =

fun _ x0 _ _ x3 $\Rightarrow\;$

match x3 with

| @Nothing_coq _ $\Rightarrow\;$ Pair_coq CState Transaction x0 TxNone

| @Just_coq _ (Inc_coq x5) $\Rightarrow\;$

   Pair_coq CState Transaction

    (CState_coq (plusInt64 (balance x0) x5) (owner x0)) TxNone

| @Just_coq _ (Dec_coq x5) $\Rightarrow\;$

   Pair_coq CState Transaction

    (CState_coq (minusInt64 (balance x0) x5) (owner x0)) TxNone

end

  : ReceiveContext $\rightarrow\;$ CState $\rightarrow\;$ Caller

    $\rightarrow\;$ nat $\rightarrow\;$ Maybe Msg $\rightarrow\;$ Pair CState Transaction *)

Using the shallow embedding, we can show a simple functional correctness property:

⬇

Lemma inc_correct init n i fin tx ctx amount caller :

(* precondition *)

balance init = n $\rightarrow\;$

(* sending "increment" *)

count ctx init caller amount (Just_coq _ (Inc_coq i)) = Pair_coq _ _ fin tx $\rightarrow\;$

(* result *)

balance fin = n + i.

Proof. intros Hinit Hrun. inversion Hrun. subst. reflexivity. Qed.