Ivan Gavran

The Case Against Formal Verification, 50 Years Later

2026-08-15T02:00:00+02:00

Engineers are getting excited about software verification! This may come as a surprise, since verification has long been considered useful only in very niche cases (at best; and impractical, useless or a complete waste of time at worst). Yet, the hype around it is clearly here: Google Trends shows a large spike in searches for formal verification/formal methods in the last two years, everybody’s learning Lean, new specification languages are popping up regularly, and there are efforts to verify major applications end-to-end (e.g., the Signal Shot project).

The main driver of this excitement is AI coding. First, AI agents leave a hole in our understanding of the programs they write, thus creating the need for other means of correctness assurance. Second, they make verification itself faster and easier to incorporate into real-world software development. Third, and perhaps the most important for business, if writing programs is made super fast, all future gains will be in the area of software correctness assurance.

Will Wilson of Antithesis declares the victory for this traditionally niche area in his talk titled We won, what now? (The talk, delivered as the opening to Bug Bash 2026, is great, and it gives some good ideas for the future of verification community, given the mainstream adoption.)

In that victorious context, it is interesting to return to one of the classic papers arguing against formal verification, Social Processes and Proofs of Theorems and Programs. Writing in 1979, its authors say:

“We believe that (…) program verification is bound to fail. We can’t see how it’s going to be able to affect anyone’s confidence about programs.”

I will go through the arguments in the paper and examine what recent developments (if any) invalidate them. This is a fun exercise rather than a completely serious one: the paper does not actually claim that all formal methods efforts are doomed (but only full verification). Furthermore, it is far from clear that verification is going to become a regular part of software engineering (what we are seeing are only early signs of interest). Nonetheless, re-examining in 2026 obstacles that were seen as fundamental 50 years ago will hopefully be useful and interesting.

In this argument, the authors of the paper argue against the idea that programming should become more like mathematics in terms of each program corresponding to a theorem that needs a proof. They say: Hold on, it is not the case even in mathematics that proofs of theorems are the end of the process. Instead, the proof is the first step and a means of communication. The really important part happens when other mathematicians internalize the proof, and the claim makes contact with other branches of mathematics or physical reality. This whole process contributes to the claim’s believability.

Comment

Nothing to object to here: proofs of programs do not need to correspond to mathematics exactly. (The argument is against a particular motivation, rather than against fundamentals of software verification.)

Argument 2: Problems with the specification

The first part of the argument goes like this: There is some real-world requirement that is informal (the people involved have a shared intuitive understanding of what the requirement is). This intuitive, informal requirement needs to be translated into a formal specification, which in itself is an informal process. In that process, which is unverified, a lot can be lost or misinterpreted.

Comment

That is a fair point. The counterpoint is that specifications are closer to informal requirements than implementations are (and thus a mistake is easier to spot). Additionally, modern specification languages (such as Quint) enable examining the specification and all its edge-cases interactively, to make sure it really corresponds to our intuition.

The second part of the argument says that the specification is only valuable if it is independent of the implementation. Given the iterative nature of software development, that is almost impossible. Once the independence is lost, we are really just aligning the specification and implementation (and potentially introducing to both similar mistakes).

Comment

I don’t think this was a strong argument even in the past, and especially not with coding agents in the loop. Whenever additional understanding is gained, this is good overall for the development process. Humans, as the final arbiters, decide which way to change the specification, re-examining initial assumptions. Coding agents may be allowed to produce and change code, and to produce proofs. If, however, there is a need to modify the specification, only a human can do that as the final arbiter of what correct means - which brings us back to the first part of Argument 2.

Argument 3: Fully automatic verification is out of reach

Having argued for why verification is bad as a means of communication, the authors shift their attention to the potential of fully automatic verifiers (in which case, we could be happy with the fact that a program was proven correct, even if the proof did not trigger a social process among colleagues). Fully automatic verifiers, the authors argue, are very unlikely to ever be built.

Comment

In the meantime, there has been some in developing automatic verifiers, though human effort (either writing proofs, or writing a suitable model to be model checked) remains crucial. However, LLM-powered tools are closing this gap quickly. Igor Konnov, in his post Formal proofs for distributed protocols with AI may be closer than you think, describes his experience proving the safety of the Ben-Or protocol in Lean.

Argument 4: Even if fully automatic verification were within reach, it would be detrimental

The authors claim that verifiers that simply respond with “VERIFIED” or “NOT VERIFIED” do not contribute to understanding and would leave programmers clueless about how to modify the program further. Furthermore, they argue, having a verified program may reduce the incentive for other layers of defense (e.g., monitoring, rate-limiting and similar).

Comment

This is a weak argument, relying on the worst possible assumptions about how verification tools and programmers’ behaviors would look in the presence of automatic verification.

Argument 5: Real-world systems are too messy to be specified

There is a huge difference, it is correctly noted, between algorithms and real-world systems. Whereas a specification for an algorithm can often be concise and tidy, specifications of real-world systems are ad-hoc, unstable, and messy. Furthermore, in most real-world systems, the algorithms are simple and easy (and thus verifying them is not of great value).

Comment

It is true that not all systems need to be verified. However, in last decades and years, there are changes that push for more verification:

As software is entering critical infrastructure and the world of finance, the stakes get higher.
If we have any hope that a coding agent creates what we want, we should better be able to describe what we want. Of course, this does not always need to be a formal specification, but the goal of precisely specifying our intent becomes more important when we work with coding agents. (This does not imply full verification, but the art of specification too is one of the formal methods tools.)

Argument 6: Software reliability is much more than verification

“The desire to make programs correct is constructive and valuable. But the monolithic view of verification is blind to the benefits that could result from accepting a standard of correctness like the standard of correctness for real mathematical proofs, or a standard of reliability like the standard for real engineering structures. The quest for workability within economic limits, the willingness to channel innovation by recycling successful design, the trust in the functioning of a community of peers–all the mechanisms that make engineering and mathematics really work are obscured in the fruitless search for perfect verifiability.”

Comment

I am fully onboard with this argument. Indeed, full verification of a system is rarely the best way to go about reliability. All other efforts towards software correctness are equally valuable. And those two are not competitors: the increased focus on best methods to bring about correctness is what matters.

## Conclusion This was quite a fun paper to read. The authors make a good point that formal verification is not a magic wand that solves all the correctness issues. Indeed, as they point out, there is much more to software correctness than verification: engineering processes, business considerations, additional layers of defense, and so on.

Because of their focus on full verification, the authors of the paper wrongly dismiss how useful different parts of formal methods are for overall understanding, better design choices, or higher velocity. All that gets amplified with AI coding agents writing the code, leaving humans with the task of specifying what needs to be written and checking that it was written according to the given specification. This makes the work of coding agents easier, too: verification gives them a way to close the loop and tell whether what they wrote was correct.

Thanks to two fellow FM practitioners, Thomas Pani and Ranadeep Biswas, for useful discussions about the paper and this post. It would also be interesting to hear from people outside the bubble who still find formal methods useless.

Blockers and Unblockers: two kinds of AI coding assistants

2025-08-12T02:00:00+02:00

“The worst business idea: AI that calls you on your bullshit… That’s really good” - Paul Bloom (video)

AI coding assistants have been extremely helpful, both in my experience and talking to colleagues and friends. Everybody got a superpower - those who used to be good, now are even better; those who didn’t know much, now have direct access to knowledge; those who were not able to program at all, now scrap their first working programs.

Most commonly, AI assistants unblock us on the way of turning ideas into code. They help avoid context switching needed to look up the documentation of the API we are using, or to summarize pages of forum discussions.¹

Out there in the wild, however, there is a complementary kind of AI coding assistant: those assistants block us from implementing bad ideas. They are perhaps less attractive, since they do not open new doors for us. However, they are equally useful: stopping us from taking a wrong path and getting lost on it.

Not all paths are a good idea.

Those blocking assistants have been around for some time already, and were developed as part of the formal methods project. The stated goal of the project is to build tools that can check if the program is doing what it is supposed to do. As a (partly unintentional) side-effect, we got programming and thinking assistants².

Assume we are to implement a new algorithm. We may first sketch the idea on paper, and then go ahead and describe the idea in a specification language. The assistant then reads this description and warns us about the properties that do not hold in our design. We can iterate on this step until the assistant cannot find any more problems in it. The whole process happens before the implementation has even started, thus saving us a lot of time.³

Unfortunately, there are some unsatisfactory parts of the workflow:

We need to decide on the level of abstraction at which we describe the idea to the assistant. If we make a wrong decision here, we may still miss a problem.
We need to put extra effort to use a specification language. Additionally, since not everybody knows the specification language we used, the final specification will not be universally understood.⁴
The analogy with unblocking coding assistants is not complete: the described tools are really “pre-coding assistants” or “design assistants”. This makes them significantly more important, but they feel less magical.

For those reasons, while unblocking assistants are getting ever more popular, the blocking assistants still remain a niche topic. Considering the superpower they give to their users, it is worth incorporating them into our programming practice, and addressing the shortcomings they have.

It is indeed one of the most interesting topics to work on in the coming years.

Notes:

1: A common objection is that this ‘gets the job done’ but hinders learning. That may be true, but the same thing likely happened in the past as well, when we were not in the right frame of mind: sometimes we just want to find a solution to a side-problem that’s blocking our main ideas; other times we want to dive deeper and learn more.

2: Some languages to interact with blocking assistant are TLA+, Lean, FizzBee, Promela, or Quint

3: Compare this to the workflow when not using blocker assistants:

We write the idea on paper (or a markdown page)
We think hard about it, get reviews from colleagues, in an attempt to spot problems
We start implementing it (or even finish the implementation), and then one of the tests reveals a subtle design issue. Now we are back to square one.

4: The problem of the specification language not being a good medium for human-to-human communication is something my colleagues at Informal Systems and I are thinking about and exploring. Our first attempts focus on using Literate Specifications

Synthesizing Formal Models with Tamed LLMs

2025-04-26T02:00:00+02:00

When blockchain systems are said to be trustless, what this really means is that all the trust is put into software. Software vulnerabilities in blockchain world cost millions, and this makes for a strong incentive to ensure blockchain software is correct. Any serious blockchain product will make sure to audit their code thoroughly, very often by multiple independent companies¹.

Formal Methods in Audits

A vanilla way to perform an audit is by getting experienced people inspect the code and reason about what could go wrong in the code logic under the weirdest possible edge cases. A way to make sure that no edge case is missed and to scale the auditing effort is by using formal methods.

Formal methods are a potent tool for ensuring software correctness. They rely on automated logical reasoning to either uncover vulnerabilities or assert their absence.

… and the Problem with Using Them

Unfortunately (and of course), it’s not all smooth sailing: for large codebases and expressive languages, formal methods scale poorly. One common way to address the problem of scalability is to build a formal model of the system and reason about that model instead of the full system implementation. We call the techniques embracing this approach model-based techniques (MBT)².

A formal model is a mathematical abstraction of the software system. We can reason about properties of the model, and establish the connection of the model to the actual implementation using model-based testing techniques. However, because of the initial cost of writing the model and the need for specialized knowledge of the modeling language, model-based techniques are used only exceptionally.

In our recently published paper we we show how to automatically generate models using LLMs in a safe way. We tame LLMs’ propensity for hallucination by setting a hard frame around it through mechanical model synthesis. After receiving initial generated model, we iteratively repair it, until the model conforms to the user’s (partial) specification.

Method Overview

Our method allows the auditor-user to automate parts of the MBT workflow, or take over in the middle of the process. Importantly, at every step, the method provides a valuable artifact to the auditor.

Figure 1: Iterative repair of generated models

As a first step, we transpile the smart contract(s) into a stub of the model: the stub captures interleavings of different actions, but does not capture the actions’ semantics. At this point, the auditor can use generated stubs to run fuzzing tests against the contract.

In the second step, we ask the user to provide a natural language description of each action and a couple of input-output examples. Our method then interacts with an LLM: beside the user’s input, we give the LLM as context the generated stub and best practices of the modelling language together with some examples³. Every time the model is not aligned with user-provided examples, out tool generates the prompt pointing out the inconsistency and requesting new generation.

The main insight on which we based the design of our tool is that the careful separation of concerns between mechanical synthesis (transpilation) and statistical synthesis (LLM-based) is crucial. Relying on an LLM to generate the whole model results in hallucinations (e.g., using non-existent helper functions) or convincingly looking yet wrong models. Conversely, transpiling the full contract into a model is hopeless: even if it worked, it would result in line-by-line re-implementation of the contract, instead of a good abstraction.

Figure 1 provides a high-level overview of our method for transforming a smart contract (CosmWasm in our case) into a model (Quint in our case).

Conclusion

We tested the proposed method on problems from CosmWasm’s Capture the Flag repository, and it was able to create correct models for the problems (which then enabled finding bugs in smart contracts). Furthermore, we used it to find a problem in one of Informal System’s historical audits.

For more details about the method, please read the paper⁴, and get in touch if you’d like to discuss it.

Notes:

1: There are indeed many companies addressing the need for audits: Informal Systems, Certora, Immunefi, Veridise, to name but a few.

2: Have a look at https://mbt.informal.systems/

3: The examples are needed since most of the modelling languages are not part of the mainstream so LLMs may not have previous knowledge about them.

4: The paper was published together with dear colleagues Gabriela Moreira, Jan Corazza, and Daniel Neider at ICST 2025.

AI drivers cannot just pass the road test; AI coders cannot just write a couple of tests

2025-03-09T01:00:00+01:00

When will self-driving cars be ready enough for roads (without any restrictions)? There were many claims of accomplishing full autonomy, but they always turned out to be false. The main challenge lies in handling very rare scenarios, those never seen in the training data.

And yet, how do we decide if a human is ready to drive autonomously? Well, we mostly give candidates a pen-and-paper exam, followed by an hour-long drive around their area. And that’s it, they’re deemed fully autonomous.

The paradox is obvious: contemporary AI systems would pass those exams easily. Why are we still full of doubt about them? It is because our criteria for trusting a human candidate is not based only on the fact that they passed the exam. We trust the candidate because they passed the exam and because they are human.

Humans are predictable enough that we can extrapolate their general driving skill from their behaviour in that short exam. (And as soon as there are signs of unpredictability: e.g., a progressing short-sightedness, influence of alcohol, or similar, we limit the human driver’s autonomy.)

The case of AI programmers

Loosely analogous is the question of when to trust a program written by an AI agent.

For a human programmer, we are often happy enough if there are some tests, witnessing that the program behaves correctly under basic scenarios and under predictable edge cases. Should we expect the same from (statistically) generated programs? Definitely not.

Like in the case of driving, the tests are not the only reason we trust the program. They just support our idea of how humans typically think, and what mistakes they typically make. This lets us anticipate errors and judge when a set of tests is likely sufficient.

An AI agent, on the other hand, could make much weirder and less predictable mistakes.

This unpredictability is why AI agents need to give us much stronger assurance of their programs’ correctness. For instance, by generating loads of tests. Better yet, by creating formal models (e.g., in TLA+, Alloy, or Quint) for the implementation, and connecting the two through model-generated tests.

In short, AI coders—like AI drivers—must do far more than their human counterparts, because of our scepticism of their failure modes. And the scepticism is fully justified, I believe.

Relevant links:

Clover: Closed-Loop Verifiable Code Generation (paper, SAIV 2024)
Accessible Smart Contracts Verification: Synthesizing Formal Models with Tamed LLMs (paper, ICST 2025)
Colimit (a company that aims at automatically fixing CI bugs)
An autonomous car driving into an overturned white truck, video
A discussion on the long-tail scenarios (edge-case scenarios) and potential solutions for the problem in the Wayve’s blogpost

Actor Model in CosmWasm

2023-11-11T01:00:00+01:00

CosmWasm (CW) is a popular smart contract platform for Cosmos blockchain ecosystem. It enables writing smart contracts code in Rust, which then gets compiled to Wasm.

In this post, I comment on CosmWasm’s concept of contracts as actors, one of the basic pillars of CosmWasm. There are interesting connections between concurrency (which is where the actor model originates from), Ethereum smart contracts, and the design of CW contracts as actors.

1. Concurrent execution

Concurrency is a model of execution where multiple computations run simultaneously. We can imagine a scheduler that decides on when each of the computations gets to make a couple of steps. The scheduler will make sure that each computation gets scheduled, but otherwise it can choose any interleaving of steps from different computations.

Is this a problem?

If the concurrent computations are fully independent, all is good. Things get more complicated if the concurrent computations have to collaborate.

Shared state

A common model of collaboration between concurrent computations is by sharing state. Assume x and y are two shared variables and observe the following concurrent computation:

x = 1;  |  y = x;   
x = 3;  |  x = y * 2;

Assuming that initially x = y = 0, what is the value of (x, y) at the end of the execution? Depending on the ordering decided by the scheduler, it can be any of (6,3), (2,1), (0,0), and (3,0).

A typical way of dealing with the problem of many possible interleavings is by identifying critical parts of the concurrent execution and putting locks around it. Still, reasoning about different interleavings and locks is not easy. The difficulty arises from the fact that one thread does not know where in the execution is the other thread, and this ignorance is an important feature of concurrency.

Actor Model

As a way to avoid the problems of dealing with shared state, a different programming model is proposed - the actor model. In the actor model, each computation is an actor, which can only access its local variables. The actors communicate by sending messages to each other, and their computation is triggered by messages received from other actors.

Actor model (source: The actor model in 10 minutes)

Each actor has its mailbox in which messages are stored. Typically, they are stored in the first-in-first-out fashion - this means that the order between messages by the same sender is preserved, but tells nothing about the order of messages sent by different senders. Upon receipt of a message, the actor 1) updates its internal state, 2) sends messages to other actors, or 3) instantiates new actors.

Because actors can only communicate by explicitly messaging each other and cannot access each other’s state, there is no need for locks.

2. Ethereum smart contracts

Smart contracts that run on Ethereum blockchain can be roughly described as sequentially run execution units that can call into each other. This is then typical sequential setting, right? Not quite. The problem is that the caller does not know what code a callee might run, and this ignorance brings it closer to the concurrent setting. (I learned about this perspective on Ethereum contracts concurrency from a very interesting paper by Sergey and Hodor, where they call the described setup uncooperative multitasking.) Viewing smart contracts that way, they resemble concurrent execution where each thread can explicitly yield to another thread.

Exactly this concurrent aspect was responsible for one of the most notorious attacks - a reentrancy attack. The comic below explains the gist of the attack: asking a contract to send some funds, and then in handling of the sent funds calling again with the same ask. (For the attack to succeed, the victim contract needs to first send the asked funds, and only afterwards update its internal state.)

3. CosmWasm actor model

Knowing about the re-entrancy attack, the designers of CosmWasm decided to model their contracts as actors. That means there is no calling into other contracts, but only sending them messages, which are executed at some later point. In other words, a contract necessarily modifies its local state first, and only then yields control to other contracts (thus avoiding reentrancy-style attacks).

In that sense, CosmWasm’s execution model is very similar to the actor model as we saw it earlier. Unlike in that description, the order of message handling in CW is strictly determined.

Messages and their handling order

Take the following example, which shows contract A sending the message x to contract B, and how x is handled by B. (If you are not familiar with the Cosmos ecosystem, bank, gov, and staking are standard Cosmos modules. Their exact functioning is not important for the example.)

The order of executing messages is depth-first. Depicting the above code as a message-send graph, it looks like this:

Depth-first ordering of messages is as follows: A, B::x, gov::v, staking::w, bank::y.

Note the two (problematic) properties of this way of executing messages:

If handling of any message fails, the whole transaction fails.
There is no (direct) way to get a return value of a message.

To add a bit more flexibility to messages, CosmWasm introduced submessages. Submessages enable both handling failures and receiving return values (as responses to submessages).

Submessages, their handling order, and dealing with their failures

Submessages are just like messages, except that they carry a special ReplyOn label on them. The ReplyOn can have one of the following values: Always, Error, Success, and Never.

A message with the label ReplyOn:Error will on failure not revert the whole transaction, but a failure will be handled by the sender. The label ReplyOn:Success makes it easy for the sender to receive a return value from the receiver. The label ReplyOn:Always will give a chance to the sender to handle both the success and the failure, and the message with the ReplyOn:Never label is the same as the plain message - no response handling, and reverting the whole transaction upon failure. For more details on what gets handled when, have a look at this table in SEMANTICS.md.

The ordering of submessages is exactly like messages - depth first, with the addition that handling of responses is treated like a message immediately sent in an opposite direction. (Interestingly, this ordering rule was not always that way and is therefore a common point of confusion - see the PR#1922.)

Consider an example similar to the previous one - except that now there is one submessage sent from contract B to contract C.

Its tree-like representation looks like this:

Then, the order of message handling is the following: A, B::x, gov::v, C::z, reply(C->B), staking::w, bank::y. Here, the reply is called if and only if C’s handling of the message z returns success.

Handling of submessage responses and failures

After the submessage handling is finished, the caller gets a chance to handle the result (if the appropriate ReplyOn label is present) in its reply function. One important point about reply is that its return value overwrites the return value of the original caller. Quoting from SEMANTICS.md:

“If reply returns data: Some(value) in the Response object, we will overwrite the data field returned by the caller. That is, if execute returns data: Some(b"first thought") and the reply (with all the extra information it is privy to) returns data: Some(b"better idea"), then this will be returned to the caller of execute (either the client or another transaction), just as if the original execute [had] returned data: Some(b"better idea")”

If there are multiple submessages, the last one overwrites all the previous ones.

TL;DR

CosmWasm’s design of contracts as actors is a neat idea that makes it easier to create safe contracts. One still needs to be aware of the order of message handling and the semantics of responses to use the full power of messages and submessages.

Hope you enjoyed this post, and let me know if something could be improved or needs to be corrected.

Robotic Systems, Powered by Formal Methods

2023-08-25T02:00:00+02:00

This is a summary of the introduction to my PhD thesis defense talk. The talk was based on my work at Max Planck Institute for Software Systems, where I was exploring how one can combine formal methods (FM) and autonomous systems.

Robots helping in a hospital

When deciding whether to use formal methods for the development of a software system, there are three strong arguments in favor of doing so:

FM force us (and even help us) to provide a precise specification of what the system is supposed to do based on the specification,
FM can provide guarantees for software correctness (or find bugs, if they exist),
for some parts of the system, we can even avoid writing code altogether: FM can synthesize provably correct code from the specification

This sounds like a great value proposition. And yet, when the decision time comes, most teams decide against using formal methods.

Why is that so?

There are of course some strawman arguments. ”Programmers are terrified by math“ - says Leslie Lamport. “FM as a discipline constantly overpromises but rarely delivers”, say others. There is also a question of semantics: as soon as a method starts being used in mainstream software development, it is no longer a part of formal methods - it is simply considered regular software engineering.

Realistically, though, it is always about what benefit formal methods are bringing to the table. The three selling points of FM are easily dismissed by:

having precise specification is useful, but my code is already precise enough and clear enough
it is great to have correctness guarantees, but 90% of all bugs I can find by doing basic testing. As for the remaining 10%, it is not the end of the world if they remain in the production code
synthesis only works for some simpler parts of the code, where the programming effort is not all that big

And given that using FM does not come for free (there is a somewhat steep learning curve, immature tool support, and a necessity to keep the specification in sync with code changes), these arguments can be valid sometimes. For instance, when programming a mobile app: it can always be safely restarted after crashing.

Picture by Blutgruppe/Corbis

But what if we are developing a (multi-)robot system? It will likely contain a couple of learned components, so inspecting a code and having a clear idea of what it does is illusionary. Furthermore, robots are big and strong machines operating near humans: we cannot be almost correct, guarantees are necessary. And finally, developing a robotic system requires knowledge from many diverse disciplines. Thus, synthesizing even parts of the overall system and letting programmers focus on the application logic is valuable.

Synthesis for Multi-Robot Systems

Motivated by this reasoning, I decided to explore interactions between formal methods and robotic systems. Concretely, with help of many great collaborators, I first developed a programming model for multi-robot systems in which users give commands describing what needs to be done (in the language of linear temporal logic, LTL), and the system synthesizes all the robots’ actions to accomplish the task. We implemented one system supporting such a model, both in simulation and on a group of Turtlebot robots.

The implemented system receives commands in linear temporal logic (LTL) and takes care of lower-level details (planning, coordination, task assignment, failure recovery,…)

Adaptable Formal Language for Instructing Robots

Following that, I set off to answer the question of how to help non-expert users write correct specifications. This line of work culminated in LTLTalk (read: little talk), a system that uses a natural language description of a task and a single demonstration to infer the formal specification of the task. Through interactions with users, LTLTalk augments its underlying formal language: its language will always remain formal (retaining all its benefits, such as interpretability of the system’s decisions), but it will converge towards the fragment of the natural language spoken by its users.

Reinforcement Learning with Inferred Reward Machines

Finally, the last line of work was about helping reinforcement learning algorithms learn faster and become more interpretable by inferring automaton-like structures called reward machines (prior to our work, these machines were always assumed to be given). For more details about each of these projects, please have a look at the thesis :)

Conclusion

Coming back to the initial question of when to insist on using formal methods, the conclusion is this: the more intricate the system is and the greater the price of failure, there is bigger need for using formal methods. The robotics domain is one such example, which furthermore offers some unique opportunities (objects and actions are concrete, thus interacting with users through examples becomes easier).

Of course, having high incentives is only a part of the story. The other part is building scalable, polished, user-friendly FM tools that every programmer will love to use, as well as providing learning material to ease the adoption of the technology.

Given how much of the world runs on software, increasing the level of trust in our software is a moral imperative. I thus hope that the work described in this post contributes towards making software (and autonomous systems in particular) more reliable.

This post was first published on 6.6.2022, here.

Ivan Gavran

The Case Against Formal Verification, 50 Years Later

Argument 1: Mathematical proofs are about social processes

Comment

Argument 2: Problems with the specification

Comment

Comment

Argument 3: Fully automatic verification is out of reach

Comment

Argument 4: Even if fully automatic verification were within reach, it would be detrimental

Comment

Argument 5: Real-world systems are too messy to be specified

Comment

Argument 6: Software reliability is much more than verification

Comment

Blockers and Unblockers: two kinds of AI coding assistants

Synthesizing Formal Models with Tamed LLMs

Formal Methods in Audits

… and the Problem with Using Them

Method Overview

Conclusion

AI drivers cannot just pass the road test; AI coders cannot just write a couple of tests

The case of AI programmers

Actor Model in CosmWasm

1. Concurrent execution

Is this a problem?

Shared state

Actor Model

2. Ethereum smart contracts

3. CosmWasm actor model

Messages and their handling order

Submessages, their handling order, and dealing with their failures

Handling of submessage responses and failures

TL;DR

Robotic Systems, Powered by Formal Methods

Why is that so?

Synthesis for Multi-Robot Systems

Adaptable Formal Language for Instructing Robots

Reinforcement Learning with Inferred Reward Machines

Conclusion