← Latest papers
💻 computer science

Cyclic Proofs in Hoare Logic and its Reverse

This paper establishes the soundness and relative completeness of cyclic proof systems for both partial and total Hoare logic and their duals, reverse Hoare logic, by demonstrating how they replace explicit loop invariants and termination measures with cyclic unrolling rules governed by coinductive and inductive global soundness conditions, respectively.

Original authors: James Brotherston, Quang Loc Le, Gauri Desai, Yukihiro Oda

Published 2026-03-03
📖 5 min read🧠 Deep dive

Original authors: James Brotherston, Quang Loc Le, Gauri Desai, Yukihiro Oda

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are a detective trying to solve a mystery about a computer program. The program is a black box that takes an input (like a number) and spits out an output. Your job is to prove two things:

  1. Will it work? (If I give it a valid starting number, will it eventually stop and give me the right answer?)
  2. Did it do what I thought? (If I see a specific result, can I be sure it came from the specific starting condition I had in mind?)

For decades, computer scientists have used a set of rules called Hoare Logic to solve the first mystery. Recently, they invented a "mirror" version called Reverse Hoare Logic to solve the second.

This paper is like a masterclass on how to solve these mysteries using two different detective techniques: the Old School Method (Axiomatic Proofs) and the New School Method (Cyclic Proofs).

Here is the breakdown in simple terms:

1. The Two Types of Mysteries

  • Standard Hoare Logic (The "Safety" Check):
    • The Question: "If I start with a safe number, will the program stop and give me a safe result?"
    • The Goal: Prove that bad things never happen.
  • Reverse Hoare Logic (The "Bug Hunter"):
    • The Question: "If I see this specific bad result (like a crash or an error), could it have come from this specific starting point?"
    • The Goal: Prove that bad things can happen (so we can find and fix them). This is often called "Incorrectness Logic."

2. The Old School Method: The "Infinite Loop" Problem

In the traditional way of proving these things (Axiomatic Proofs), you have to write a "Loop Invariant."

  • The Analogy: Imagine a hamster running on a wheel. To prove the hamster will eventually stop, you have to write down a rule that says, "Every time the hamster runs a lap, it gets a tiny bit closer to the finish line." You have to invent this rule yourself.
  • The Problem: This is really hard! It's like asking a human to invent a mathematical law on the spot to prove a program works. It's the main reason computers can't automatically check code for bugs yet.

3. The New School Method: Cyclic Proofs (The "Time Loop" Detective)

The authors propose a smarter way called Cyclic Proofs. Instead of inventing a complex rule to stop the hamster, you just let the hamster run and watch what happens.

  • How it works: You draw a map of the program's execution. If the program has a loop, instead of stopping to write a rule, you draw a line back to an earlier point in the map. You create a cycle (a loop in your proof).
  • The Catch: You can't just draw a loop and call it a day. You have to prove the loop is "safe."
    • For Safety (Standard Logic): You prove that if the program runs forever, it's actually doing something useful (like checking conditions) and not just stuck. If it doesn't stop, it means it's running infinitely, which is fine for this type of proof.
    • For Bug Hunting (Reverse Logic): You prove that if the program runs forever, it's actually getting "smaller" or "simpler" in a way that makes sense. If it doesn't stop, it's a contradiction, meaning the bug must exist.

The Magic Analogy:
Think of a Time Loop in a movie (like Groundhog Day).

  • In the Old School method, the hero has to write a diary entry every day explaining why they will eventually break the loop.
  • In the Cyclic method, the hero just lives the day. If they get stuck in the loop, the movie checks: "Is the hero actually learning something new every time, or are they just spinning their wheels?"
    • If they are spinning wheels (infinite descent), the proof fails.
    • If they are making progress (even if they loop back), the proof works.

4. The Big Discovery: Mirror Images

The most exciting part of this paper is that the authors realized these two worlds are mirror images of each other.

  • Standard Logic (Proving safety) and Reverse Logic (Proving bugs) use almost the exact same rules, just flipped upside down.
  • Partial vs. Total:
    • Partial: "If it stops, it's good." (We don't care if it runs forever).
    • Total: "It must stop, and it must be good."
  • The authors showed that the "Time Loop" rules (Cyclic Proofs) work perfectly for all four combinations:
    1. Standard Safety (Partial)
    2. Standard Safety (Total)
    3. Bug Hunting (Partial)
    4. Bug Hunting (Total)

5. Why This Matters

The authors admit that they didn't invent entirely new math. They took existing ideas and put them together in a neat package. But this package is powerful because:

  1. It simplifies things: It shows that "Proving a program works" and "Proving a program is broken" are two sides of the same coin.
  2. It helps automation: By using these "Time Loop" proofs, computers might be able to automatically check code for bugs without needing a human to invent complex "Loop Invariants" first.
  3. It's symmetric: The rules for finding bugs are now just as formal and rigorous as the rules for proving safety.

Summary

Think of this paper as a guidebook for a new kind of detective. Instead of forcing the suspect (the program) to confess by writing a complex statement (the invariant), the detective sets up a surveillance camera (the cyclic proof) that watches the suspect run in circles. If the camera sees the suspect making progress or getting stuck in a way that proves a crime happened, the case is closed.

The authors have shown that this camera works for both "Good Guys" (Safety) and "Bad Guys" (Bugs), and it works whether the program stops or runs forever. It's a unified, elegant way to understand how programs behave.

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →