Bidirectional type checking for relational properties

Çiçek, Ezgi; Qu, Weihao; Barthe, Gilles; Gaboardi, Marco; Garg, Deepak

doi:10.1145/3314221.3314603

Cited by 14 publications

(11 citation statements)

References 44 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Following the initial work on linear typing for differential privacy [44], a parallel line of work [6,8] leverages relational refinement types aided by SMT solvers in order to support type-level dependency of privacy parameters (à la DFuzz [29]) in addition to more powerful variants of differential privacy such as (ϵ, δ )-differential privacy. These approaches support (ϵ, δ )-differential privacy, but did not support usable type inference until a recently proposed heuristic bi-directional type system [19]. Although a direct case study of bidirectional type inference for relational refinement types has not yet been applied to differential privacy, the possibility of such a system appears promising.…”

Section: Related Workmentioning

confidence: 99%

Duet: an expressive higher-order language and linear type system for statically enforcing differential privacy

Near

Darais

Abuah

et al. 2019

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

During the past decade, differential privacy has become the gold standard for protecting the privacy of individuals. However, verifying that a particular program provides differential privacy often remains a manual task to be completed by an expert in the field. Language-based techniques have been proposed for fully automating proofs of differential privacy via type system design, however these results have lagged behind advances in differentially-private algorithms, leaving a noticeable gap in programs which can be automatically verified while also providing state-of-the-art bounds on privacy.We propose Duet, an expressive higher-order language, linear type system and tool for automatically verifying differential privacy of general-purpose higher-order programs. In addition to general purpose programming, Duet supports encoding machine learning algorithms such as stochastic gradient descent, as well as common auxiliary data analysis tasks such as clipping, normalization and hyperparameter tuning-each of which are particularly challenging to encode in a statically verified differential privacy framework.We present a core design of the Duet language and linear type system, and complete key proofs about privacy for well-typed programs. We then show how to extend Duet to support realistic machine learning applications and recent variants of differential privacy which result in improved accuracy for many practical differentially private algorithms. Finally, we implement several differentially private machine learning algorithms in Duet which have never before been automatically verified by a language-based tool, and we present experimental results which demonstrate the benefits of Duet's language design in terms of accuracy of trained machine learning models. privacy provides a robust solution to this problem, and as a result, a number of differentially private algorithms have been developed for machine learning [3,13,17,28,42,50,51,54].Few practical approaches exist, however, for automatically proving that a general-purpose program satisfies differential privacy-an increasingly desirable goal, since many machine learning pipelines are expressed as programs that combine existing algorithms with custom code. Enforcing differential privacy for a new program currently requires a new, manually-written privacy proof. This process is arduous, error-prone, and must be performed by an expert in differential privacy (and re-performed, each time the program is modified).We present Duet, a programming language, type system and tool for expressing and statically verifying privacy-preserving programs. Duet supports (1) general purpose programming features like compound datatypes and higher-order functions, (2) library functions for matrix-based computations, and (3) multiple state-of-the-art variants of differential privacy-(ϵ, δ )-differential privacy [25], Rényi differential privacy [38], zero-concentrated differential privacy (zCDP) [16], and truncated-concentrated differential privacy (tCDP) [15]-and can be easily extended to...

show abstract

Section: Related Workmentioning

confidence: 99%

Duet: an expressive higher-order language and linear type system for statically enforcing differential privacy

Near

Darais

Abuah

et al. 2019

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

show abstract

“…ś Relational comprises all the cost analysis examples from [Aguirre et al 2017;Çiçek et al 2017;Radiček et al 2018]. These examples compare the resource usage of the same function on different inputs, for instance, constant-time comparison from section 2.2, or different functions on the same input, for instance, the memory allocation case study compares the memory required by the standard and tail recursive implementations of the length function.…”

Section: Summary Of Examplesmentioning

confidence: 99%

“…Unfortunately, however, performance bugs are as difficult to detect as they are common [Jin et al 2012]. As a result, the problem of statically analysing the resource usage, or execution cost, of programs has been subject to much research in which a broad range of techniques have been studied, including resource-aware type systems [Çiçek et al 2017;Hoffmann et al 2012;Hofmann and Jost 2003;Jost et al 2017;Wang et al 2017], program and separation logics [Aspinall et al 2007;Atkey 2010], and sized types [Vasconcelos 2008].…”

Section: Introductionmentioning

confidence: 99%

Liquidate your assets: reasoning about resource usage in liquid Haskell

Handley

Vazou

Hutton

2019

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

Liquid Haskell is an extension to the type system of Haskell that supports formal reasoning about program correctness by encoding logical properties as refinement types. In this article, we show how Liquid Haskell can also be used to reason about program efficiency in the same setting. We use the system's existing verification machinery to ensure that the results of our cost analysis are valid, together with custom invariants for particular program contexts to ensure that the results of our analysis are precise. To illustrate our approach, we analyse the efficiency of a wide range of popular data structures and algorithms, and in doing so, explore various notions of resource usage. Our experience is that reasoning about efficiency in Liquid Haskell is often just as simple as reasoning about correctness, and that the two can naturally be combined.In this article, we take inspiration from [Radiček et al. 2018] and implement a monadic datatype to measure the abstract resource usage of pure Haskell programs. We then use Liquid Haskell's [Vazou 2016] refinement type system to statically prove bounds on resource usage. Our framework supports the standard approach to cost analysis, which is known as unary cost analysis and aims to establish upper and lower bounds on the execution cost of a single program, together with the more recent relational approach [Çiçek 2018], which aims to calculate the difference between the execution costs of two related programs or between one program on two different inputs.Reasoning about execution cost using the Liquid Haskell system has two main advantages over most other formal cost analysis frameworks [Radiček et al. 2018]. First of all, the system allows correctness properties to be naturally integrated into cost analysis, which helps to ensure that cost analyses are valid. And secondly, the wide range of sophisticated invariants that can be expressed and automatically verified by the system can be exploited to analyse resource usage in particular program contexts, which often leads to more precise and/or simpler analyses.By way of example, Liquid Haskell can automatically verify that Haskell's standard sort function returns an ordered list (of type OList a) with the same length as its input, even when the result is embedded in the Tick datatype that we use to measure resource usage: sort :: Ord a => xs:[a] → Tick { zs:OList a | length zs == length xs } Applying our cost analysis to this function then allows us to prove that the maximum number of comparisons required to sort any list xs is O(n log n), where n = lenдth xs: sortCost :: Ord a => xs:[a] → { tcost (sort xs) <= 4 * length xs * log 2 (length xs) + length xs } Moreover, we can also combine correctness and resource properties to show that the maximum number of comparisons becomes linear when the input list is already sorted: sortCostSorted :: Ord a => xs:OList a → { tcost (sort xs) <= length xs }The aim of this article is to develop, prove correct, and evaluate a system that supports the above form of reasoning. To this end, t...

show abstract

“…Intuitively, we think of P as being a subtype of the unit type 1, as one can always discard "an atom of potential". From this, it follows that P k <∶ P when ≤ k. More potential can always be used in place of less 10 . Note the contravariance in this subtyping rule: the ordering in amounts of potential is the opposite of the ordering on numbers.…”

Section: Cost and Potentialmentioning

confidence: 91%

“…To simplify some of the boilerplate involved in implementing the functions corresponding to each algorithmic judgment, we introduce a monadic discipline inspired by the implementation of BiRelCost [10]. We use a combined state/error monad called 'a checker to simultaneously handle the four fully structural contexts and the substructural one via the I/O method (hence state, not reader), as well as managing type errors.…”

Section: Ast Freshening Passmentioning

confidence: 99%

Languages With Potential

Cutler¹

View full text Add to dashboard Cite

While decades of research into formal verification have brought provable correctness guarantees closer to being a part of developers' everyday reality, provable guarantees about algorithmic complexity are harder to come by. This is not for lack of effort. Algorithmic complexity and program cost don't play nicely with abstraction, and so they can prove a difficult target for the kinds of compositional analysis that formal tools handle best. However, the classical algorithm analysis technique known as amortized analysis [75] is promising in this regard: it allows one to selectively break abstraction barriers to precisely and compositionally calculate program costs.In this thesis, we leverage amortized analysis to make two contributions which make some progress towards our goal of provable cost guarantees for the masses.We begin by taking a cue from the interactive theorem proving school of software verification.We develop a functional language called LambdaAmor, which provides a rich refinement type system for in-language amortized cost analysis. We begin with a previously-developed core calculus called λ-Amor [64], transform it to an algorithmic type system which is amenable to implementation, and subsequently implement the language in OCaml.Next, we move to considering a more lightweight method of analyzing the cost of programs, namely the extract-and-solve method of recurrences. This technique is already used (explicitly or otherwise) by practitioners of functional languages, and regularly included in introductory CS curricula. However, the technique is informal, error-prone, and not immediately applicable to amortized cost analysis. Following on work by Danner et al. [19], we formalize the process of amortized analysis by recurrence extraction as a language-to-language translation, and use this to prove the technique's correctness. v 1. INTRODUCTION 7 This is somewhat inaccurate: the presence of a sum construct in the language of index terms breaks linearity, but this is rarely a problem in practice. 8 The ∀j ∶ N... being irrelevant is crucial here: since one cannot pattern match on the value of j, the cost of the computation must be uniform in j.10 Alternatively, this can be thought of as being analogous to width subtyping for records.

show abstract

Bidirectional type checking for relational properties

Cited by 14 publications

References 44 publications

Duet: an expressive higher-order language and linear type system for statically enforcing differential privacy

Duet: an expressive higher-order language and linear type system for statically enforcing differential privacy

Liquidate your assets: reasoning about resource usage in liquid Haskell

Languages With Potential

Contact Info

Product

Resources

About