Case studies of development of verified programs with Dafny for accessibility assessment

TL;DR

This paper presents 10 case studies using Dafny to develop verified programs, showing promising verification performance but highlighting challenges in manual auxiliary code, informing future automation efforts.

Contribution

It provides empirical evidence on Dafny's accessibility for software engineers through real-world case studies, assessing verification effort and performance.

Findings

Specification code is comparable in size to implementation code.

Dafny verifier is fast, averaging 24 ms per proof obligation.

Manual auxiliary verification code can be significant and challenging.

Abstract

Formal verification techniques aim at formally proving the correctness of a computer program with respect to a formal specification, but the expertise and effort required for applying formal specification and verification techniques and scalability issues have limited their practical application. In recent years, the tremendous progress with SAT and SMT solvers enabled the construction of a new generation of tools that promise to make formal verification more accessible for software engineers, by automating most if not all of the verification process. The Dafny system is a prominent example of that trend. However, little evidence exists yet about its accessibility. To help fill this gap, we conducted a set of 10 case studies of developing verified implementations in Dafny of some real-world algorithms and data structures, to determine its accessibility for software engineers. We found that, on average, the amount of code written for specification and verification purposes is of the same order of magnitude as the traditional code written for implementation and testing purposes (ratio of 1.14) -- an ``overhead'' that certainly pays off for high-integrity software. The performance of the Dafny verifier was impressive, with 2.4 proof obligations generated per line of code written, and 24 ms spent per proof obligation generated and verified, on average. However, we also found that the manual work needed in writing auxiliary verification code may be significant and difficult to predict and master. Hence, further automation and systematization of verification tasks are possible directions for future advances in the field.