Probabilistic programs are programs with the ability to sample from probability distributions. Hence, their executions have a stochastic nature, and - in contrast to arbitrary nondeterministic programs - it makes sense to study their expected (or average) behavior. Probabilistic programs appear as implementations of randomized algorithms, where sampling is exploited to ensure that expensive executions have a low probability, in cryptographic protocols, where randomness is essential for encoding secrets, as well as in statistics and artificial intelligence, where programs are becoming a popular alternative to graphical models for describing complex distributions. The behavior of probabilistic programs is often counterintuitive — a consequence of the well-known fact that humans have difficulties reasoning about stochastic processes. In combination with their various applications, the counterintuitive nature of probabilistic programs means that ensuring their correctness must be based on verification and analysis methodologies that are rigorous, tool-supported, and, ideally, automated.

Projects in this direction generally aim to develop, improve, and evaluate such techniques.

What you can expect when working in this direction:

• We will study and apply rigorous theoretical foundations to develop novel analysis techniques for an agreed-upon aspect of probabilistic programs. For example, we studied formal reasoning about expected runtimes and a program’s sensitivity to small input changes in past projects.

• Depending on the focus, topics may involve implementing a research prototype and evaluating to what extent the proposed foundational technique (or an existing one) can be automated.

• Prior knowledge about (non-probabilistic) formal methods, logic, and probability theory is beneficial but not required.

Rust is a modern systems programming language with a focus on performance and concurrency. Its powerful type system enables the Rust compiler to give safety guarantees, such as the absence of memory access violations and race conditions, that go well beyond other programming languages (C, C++, Java, etc.). Prusti is an extension of the Rust compiler that enables developers to annotate their programs with formal specifications that are then verified at compile-time; potential specification violations are represented just like any other compiler error. A key feature of Prusti is that it leverages Rust’s type system to reduce the number of auxiliary annotations, such as loop invariants, that are required from the user to verify a specification successfully. Prusti can thus be seen as a lightweight approach to obtain stronger safety guarantees than those already provided by the Rust compiler.

What you can expect when working in this direction:

• Topics in this direction may include case studies in which you apply state-of-art verifiers to real-world programs, designing novel verification techniques for currently unsupported languages features, and implementing new features in existing tools like Prusti.

• Prior knowledge about Rust, program verification, and compilers is beneficial but not required.

Separation logic is a popular formalism for Hoare-style verification of programs that manipulate resources, such as dynamically allocated memory, linked data structures, or critical sections accessible to multiple threads. Its assertion language extends first-order logic by two connectives - the separating conjunction and the magic wand - that enable writing concise specifications of how resources can be split-up and combined again. Separation logic builds upon these connectives to champion local reasoning about the resources employed by programs. That is, program parts can be verified by considering only those resources they access - a fundamental property for building scalable verification and static analysis tools. Peter O’Hearn’s CACM article gives an excellent first introduction to separation logic. At the foundation of virtually every automated approach based on separation logic lies the entailment problem: is every model of one formula also a model of another formula? For example, deductive verifiers need to solve entailments whenever they invoke the rule of consequence. While the entailment problem is undecidable in general, its central role in verification has triggered a massive interest in decidable fragments and incomplete entailment solvers.

What you can expect when working in this direction:

• Topics in this direction can be both theoretical and practical. Theoretical aspects typically involve studying the decidability and complexity of the entailment problem in an agreed-upon fragment of separation logic. Practical aspects include implementing prototypical entailment solvers and comparing them to other state-of-the-art tools.

• Prior knowledge on mathematical logic or program verification is beneficial but not required.