Dependent types and multi-monadic effects in F*

Abstract

We present a new, completely redesigned, version of F*, a language that works both as a proof assistant as well as a general-purpose, verification-oriented, effectful programming language. In support of these complementary roles, F* is a dependently typed, higher-order, call-by-value language with _primitive_ effects including state, exceptions, divergence and IO. Although primitive, programmers choose the granularity at which to specify effects by equipping each effect with a monadic, predicate transformer semantics. F* uses this to efficiently compute weakest preconditions and discharges the resulting proof obligations using a combination of SMT solving and manual proofs. Isolated from the effects, the core of F* is a language of pure functions used to write specifications and proof terms---its consistency is maintained by a semantic termination check based on a well-founded order. We evaluate our design on more than 55,000 lines of F* we have authored in the last year, focusing on three main case studies. Showcasing its use as a general-purpose programming language, F* is programmed (but not verified) in F*, and bootstraps in both OCaml and F#. Our experience confirms F*'s pay-as-you-go cost model: writing idiomatic ML-like code with no finer specifications imposes no user burden. As a verification-oriented language, our most significant evaluation of F* is in verifying several key modules in an implementation of the TLS-1.2 protocol standard. For the modules we considered, we are able to prove more properties, with fewer annotations using F* than in a prior verified implementation of TLS-1.2. Finally, as a proof assistant, we discuss our use of F* in mechanizing the metatheory of a range of lambda calculi, starting from the simply typed lambda calculus to System F-omega and even micro-F*, a sizeable fragment of F* itself---these proofs make essential use of F*'s flexible combination of SMT automation and constructive proofs, enabling a tactic-free style of programming and proving at a relatively large scale.

An overview on smart contracts: Challenges, advances and platforms

“…Liu et al [40] proposed to perform the fuzz testing on smart contracts by iteratively generating random but diverse transactions to detect reentrancy bugs. 1) Readability • Human readable code [34], [35] • Human readable execution [36], [37] • Re-entrancy [38], [39], [40] 2) Functional issues • Block randness [41], [42], [43] • Overcharging [44], [45] Deployment • Bytecode analysis [46], [47], [48], [49], [50], [51], [52], [53] 1) Contract correctness • Source code analysis [54], [55], [56], [57] • Machine learning based analysis [58], [59], [60] • Graph based analysis [61], [62] 2) Dynamic control flow • Path-searching [63] • Execution environment [64] Execution 1) Trustworthy oracle • Third-party involved [65] • Decentralized [66], [67] 2) Transaction-ordering dependence • Sequential execution [68] • Predefining contract [69] 3) Execution efficiency • Execution serialization [70], [71], [72] • Inspection of contract [73] Completion 1) Privacy and Security • Privacy [74],…”

“…In particular, a formal verification method was proposed in [54] to analyze and verify both the runtime safety and the functional correctness of smart contracts (e.g., Ethereum contracts). This method first translates smart contracts into codes written in F * [55], which is a functional programming language mainly used for program verification. This translation can be used to detect abnormal patterns like stack overflow (i.e., exceeding the stack limit).…”

The next 700 relational program logics

“…An important idea in the non-relational verification setting is to encapsulate the specification of a monadic computation inside a monad [Ahman et al 2017;Delbianco and Nanevski 2013;Maillard et al 2019;Nanevski et al 2008aNanevski et al ,b, 2013Swamy et al 2013Swamy et al , 2016, giving the same algebraic footing to both computations and specifications. For instance, stateful computations returning values in A are elements of a state monad St A = S → (A × S) and can be given specifications drawn from the monad W St A = (A × S → P) → (S → P) equipped with the monad structure given by…”

“…(1) specifications are drawn from a monad, ordered by precision [Ahman et al 2017;Delbianco and Nanevski 2013;Maillard et al 2019;Nanevski et al 2008aNanevski et al ,b, 2013Swamy et al 2013Swamy et al , 2016 and (2) one can link any computation with its specification by defining a monad morphism, i.e., a mapping between two monads that respects their monadic structure. In the case of state, an example monad morphism is θ St (c) = λφ s. φ (c s) : St A → W St A mapping a stateful computation to the unary specification monad W St A = (A×S→P)→P, by running it and then checking whether the postcondition holds of the result.…”

Bioinformatics Workflow Management With The Wobidisco Ecosystem

“…The community includes very successful industrial users for whom safety and security matter [24], [25], and has contributed great tooling. OCaml is also more future-proof; as the next generation of safer programming languages and tools, like Coq [26] or F* [27], are often written and/or extract code to OCaml.…”