ESBMC - An Efficient SMT-based Bounded Model Checker
https://ssvlab.github.io/esbmc/
"ESBMC is an open-source, [...], context-bounded model checker based on satisfiability modulo theories for verifying single- and multi-threaded C/C++ programs. It does not require the user to annotate the programs with pre- or postconditions, but allows the user to state additional properties using assert-statements, that are then checked as well."
1/3
Verifying the #Rust Standard Library - Carolyn Zech, Amazon Web Services
https://invidious.nerdvpn.de/watch?v=8_lzVNs1uPk
(or YT: https://www.youtube.com/watch?v=8_lzVNs1uPk)
Carolyn is also a maintainer of #Kani, the Rust model checker.
She has been so supportive and kind during my struggles with HashMaps and Kani
https://github.com/model-checking/kani/issues/3965
Give her a follow:
https://github.com/carolynzech
Yes, this is another issue with the current #LLM architecture: they can't learn or improve. It's one big monolith - not composed of smaller parts (that could individually be improved or composed with each other).
There _are_ AI architectures that are _actually reliable_...
https://floss.social/@janriemer/114454349034565839
...but our industry has decided to hyperfocus on bullshit machines.
Owi
https://github.com/OCamlPro/owi
Symbolic execution for #Wasm, #C, C++, #Rust and #Zig
"#Owi is an open-source framework for advanced #WebAssembly analysis and manipulation, with a focus on practical symbolic execution and robust tooling. It is designed for researchers, engineers, programming language enthusiasts and practitioners requiring precise, flexible, and extensible support program reasoning."
Totally agree! Unit tests and usage of #LLMs in that area are a bad combo (both for implementation and tests).
However, I'd like to give you some "food for thought":
What if the LLM was generating code against a (human written) #proof?
See this blog post, where they've written a proof with #Kani, a model checker in #Rust and let the #LLM generate the implementation until the proof passes:
People of ACM - Derek Dreyer
https://www.acm.org/articles/people-of-acm/2025/derek-dreyer
"Derek Dreyer is a Scientific Director at the Max Planck Institute for Software Systems (MPI-SWS) [...]. His [...] interests include type systems, semantics of programming languages, verification of concurrent programs, and interactive theorem proving. [...] His goal is “to produce rigorous formal foundations for establishing the safety and reliability of software systems.”"
HACL*, a formally verified cryptographic library written in F*
Flux:
https://flux-rs.github.io/flux/
Flux is a refinement type checker for #Rust that lets you specify a range of correctness properties and have them be verified at compile time.
Crazy!
(❁´◡`❁)
#Rust pattern types RFC:
https://gist.github.com/joboet/0cecbce925ee2ad1ee3e5520cec81e30
Pattern types are a form of refinement types, which allow some subset of #FormalVerification!
https://en.wikipedia.org/wiki/Refinement_type
Tracking Issue for #PatternTypes:
https://github.com/rust-lang/rust/issues/123646
Tracking Issue for generic pattern types OwO:
https://github.com/rust-lang/rust/issues/136574
Implement minimal, internal-only pattern types in the type system:
https://github.com/rust-lang/rust/pull/120131
I'm _really_ looking forward to how #RustLang will evolve in this area!
The Department of Computer Science, University of Oxford has released recordings of the recent Strachey Series Lectures featuring Leo de Moura and Kevin Buzzard:
"Formalizing the Future: Lean's Impact on Mathematics, Programming, and AI" - Leo de Moura, Chief Architect of Lean
Leo discusses how Lean provides a framework for machine-checkable mathematical proofs and code verification, enabling collaboration between mathematicians, software developers, and AI systems. He also outlines the work the Lean Focused Research Organization does to expand Lean’s capabilities and support the community.
Watch Leo's lecture here: https://podcasts.ox.ac.uk/formalizing-future-leans-impact-mathematics-programming-and-ai
"Will Computers Prove Theorems?" with Kevin Buzzard, Professor of Mathematics, Imperial College
Kevin examines the potential for AI systems and theorem provers to assist in mathematical discovery, addressing whether computers might someday find patterns in mathematics that humans have missed, and discusses the integration of language models with formal verification systems.
Watch Kevin's lecture here: https://podcasts.ox.ac.uk/will-computers-prove-theorems
Wow, #FuzzTesting/ #PropertyTesting is actually harder than doing an automatic proof.
I didn't expect that!
The inner magic behind the Z3 theorem prover - Microsoft Research (October 2019):
https://www.microsoft.com/en-us/research/blog/the-inner-magic-behind-the-z3-theorem-prover/
F* (fstar) Interactive Tutorial:
https://fstar-lang.org/tutorial/
I'm only like 10% into the tutorial, but this language is CRAZY (fun)!
I try to learn the fundamentals of it, so I can use the backend of it in #Aeneas... so I can ultimately formally verify my #Rust crate (former attempts with #Creusot and #Kani failed for me).
Aeneas:
https://github.com/AeneasVerif/aeneas
See part two of toot for a toy example of proving function equivalence
1/2
Huh, seems like I really have been living on the bleeding edge (of #FormalVerification):
https://github.com/creusot-rs/creusot/discussions/1477#discussioncomment-12991148
The verification in the prev toot is currently not possible in #Creusot due to missing specs for the `Hash` trait and HashMap more broadly.
Oh well, seems like (at least currently!) I won't be able to fully verify the diffing algorithm of #CSVDiff.
Options I have now are:
- Only verify parts of the algorithm (that don't depend on HashMap ops)
or
- Use fuzzing/property testing
Hm...I'm running into a timeout with #Creusot when trying to verify a simple `add` operation on a HashMap newtype
https://github.com/creusot-rs/creusot/discussions/1477
Does anyone have any idea what's going on here?
Disclaimer: I'm totally new to creusot and #FormalVerification, so please be gentle with me.
Boosts very much appreciated.
Thank you!
Place Capability Graphs: A General-Purpose Model of #Rust’s
Ownership and Borrowing Guarantees (April 2025)
https://arxiv.org/pdf/2503.21691
"We present a novel model of Rust’s type-checking [...], which lifts [...] limitations [of current verification tools], and which can be directly calculated from the #RustLang compiler’s own programmatic representations and analyses. We demonstrate that our model supports over 98% of Rust functions in the most popular public crates...
1/2
creuSAT - A formally verified #SAT solver written in #Rust and verified with #Creusot.
https://github.com/sarsko/CreuSAT
Mindblowing!
Co-Developing Programs and Their Proof of Correctness - the SPARK Programming Language and Analyzer
https://cacm.acm.org/research/co-developing-programs-and-their-proof-of-correctness/
Re: Help us create a vision for Rust's future
In the mid- to long-term I can see #Rust focus more and more on facilitating #FormalVerification - it perfectly aligns with #RustLang's vision of enabling everyone to build _reliable_ and efficient software.
First step is probably to have a common contract language, which might enable interoperability of different verification tools.
(Disclaimer: I'm a total newbie in the field of formal verification, but I find it absolutely fascinating!)