Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add several FAQ entries on comparisons #1506

Merged
merged 9 commits into from
Oct 3, 2024
Merged

Conversation

bugarela
Copy link
Collaborator

Hello :octocat:

These adds a bunch of FAQ entries for questions like "How does Quint compare to X"? to our website FAQ.

@bugarela
Copy link
Collaborator Author

Hi @p-offtermatt @romac @ivan-gavran ! Tagging you here as you might have good opinions on these. Review is totally optional, but I'd definitely appreciate them ❤️

Copy link
Member

@ebuchman ebuchman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great! Maybe as I final thing we should have a "So, what should I use Quint for" that just summarizes like

  • if you can do static analysis on your code, do it
  • if you need a full mathematical proof, use Lean etc.
  • if you need a full mathematical proof thats also executable code, use Idris etc.
  • if you need a model of your system you can play with to improve your understanding of the protocol and check certain properties, use Quint

or something like that

I think overall highlighting that with Quint its much easier to check invariants on protocols than formally proving it all with an assistant would be helpful


Proof assistants require you to write deductive proofs, while model checkers (as
in Quint), use an inductive approach, exploring all reachable states in a model.
Proof assistants are mostly used for research, and model checking techniques are
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't really critical systems get proven though?

and isn't a lot of focus in like cryptography and ethereum on using proof assistants? we may want to add something to that effect.

would be great for each to add some examples of where they have been used successfully to also ground the comparison

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what I gathered, the meaningful industry use cases is like years of work from several experts. I'll try to find concrete information and add some "they did this but it took this big effort/expertise". In general, CompCert is the biggest example. For ethereum stuff, I need to check how many things are actually done (as opposed to ongoing research).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked through a lot of Veridise's public audit reports. I found one from a while ago where they used coq to verify a zk circuit https://veridise.com/wp-content/uploads/2023/09/VAR-RLN.pdf

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one more: MatterLabs verifying the zk-verifier https://eprint.iacr.org/2024/768.pdf

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, thanks! Will add those and look for more

Co-authored-by: Ethan Buchman <[email protected]>
Copy link
Member

@p-offtermatt p-offtermatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, I think these are useful. Left a few comments

proof system (TLAPS), while Quint doesn't. Therefore, it is possible to write
more advanced formulas in TLA+ than in Quint, even ones that are not
supported by the existing model checkers, and then prove them using the proof
system. Quint restricts you to a fragment of TLA with the intention of
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
system. Quint restricts you to a fragment of TLA with the intention of
system. Quint restricts you to a fragment of TLA+ with the intention of

Not sure whether this is TLA on purpose or its missing the +

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess both the language and the logic could make sense here

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it was on purpose. Both make sense, right. I just figure it is easier to explain to people that both Quint and TLA+ are based on TLA (although both add ZFC on top of TLA, so there is actually more that is shared).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think saying TLA+ in this sentence would be incorrect. Quint is not based on TLA+ the spec language, but on TLA the logic.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this sense, you are correct. But also, I've seen TLA+ described as:

The “+” in TLA+ uses a formal set theory based on ZFC to allow TLA variables to take on many kinds of values (atoms like numbers and strings, finite and infinite sequences, sets, records, and functions).

in some places before (I think Lamport wrote this). And since Quint also has ZFC tihngs, I think it is also right to say it is a fragment of TLA+

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's right. Probably it's better to say "Quint restricts you to a fragment of the underlying logic of TLA+". The underlying logic of TLA+ is TLA plus a variant of ZFC. The "+" also adds non-logical constructs such as modules.

supported by the existing model checkers, and then prove them using the proof
system. Quint restricts you to a fragment of TLA with the intention of
preventing unintentional usage of operators that lead to complicated
behaviors that are hard to debug and understand. Our understanding is that
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like the last sentence so much and would reformulate, but up to you. Isn't the distinction more about Quint wanting to avoid things that "accidentally" blow up the state space, when they could instead be written in a way that is nicer for the size of the state space?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm I don't think we can attribute state space management to the constraints of Quint. What I have in mind here is that in TLA+ you can write x = x' for x' = x, which is exactly the same in terms of state space, but more complex to understand if you are not thinking about math. Then, there are the weirder ones like (x + 1)' = x and f'(x') etc, and the ones which would actually affect the search space as x' > x.

But, mostly, we are just trying to avoid people using the prime operator in different ways as it is not obvious what it would do, and people might expect something different from what it actually means. This also happens with non determinism.

My sentence comes from me believing that people who are more used to math than to programming will like TLA+ better than Quint (at least for the syntax, and they might even be not that bothered by the tooling). A good rule of thumb might be: would you rather read a map like { f(x) : x ∈ S } or S.map(x => f(x))? I can read both fine, but I prefer the second one by far. But there are definitely people who prefer the first.


Proof assistants require you to write deductive proofs, while model checkers (as
in Quint), use an inductive approach, exploring all reachable states in a model.
Proof assistants are mostly used for research, and model checking techniques are
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked through a lot of Veridise's public audit reports. I found one from a while ago where they used coq to verify a zk circuit https://veridise.com/wp-content/uploads/2023/09/VAR-RLN.pdf


Proof assistants require you to write deductive proofs, while model checkers (as
in Quint), use an inductive approach, exploring all reachable states in a model.
Proof assistants are mostly used for research, and model checking techniques are
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines 209 to 219
Quint is used to reason about behaviors of programs and how things change over
time. If you can use a static analyzer to search for a class of errors (i.e.
null checks), you should definitely use that. Use Quint for what you cannot do
with a static analyzer (which is a lot!).

This is also one of the reasons why Quint has a type system. Although we could
check typing using invariants, as people often do in TLA+, we can do it
statically with a regular type checker - and that is much better.

Static analyzers won't be able to tell you if your consensus algorithm does
consensus as you expect, but Quint will.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this one should explain a bit more what static analyzers can be used for and what they cannot - I think it needs a one sentence explanation at the start that lays out what static analyzers even are, on a very high level

Co-authored-by: Philip Offtermatt <[email protected]>

Proving something using one of these tools provides a much stronger guarantee
than verifying something with a model checker. Proofs derive directly from
constructive mathematics, while model checkers are complex implementations on
Copy link
Member

@hvanz hvanz Sep 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Be careful with the expression "constructive mathematics" (https://plato.stanford.edu/entries/mathematics-constructive/).

The logic of Isabelle/HOL is not constructive. I think Lean supports some form of constructive logic but I'm not sure. "Lean is based on a version of dependent type theory known as the Calculus of Constructions." Only Coq is constructive with its Calculus of Inductive Constructions.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, my bad! I thought all of them were used constructive logics. Do you have any suggestions on what would be more accurate here? I just want to say that there is a really low chance that there is an implementation error on the proof assistants that would result in wrong proofs being checked, while there is much more room for mistakes in model checker implementations.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Proof assistants are software and thus can have bugs too. They are generally more trustworthy than model checkers because these proof assistants in particular rely on a small kernel implementing the core logical rules. All proofs reduce to the rules in the kernel. The kernel is very small, probably a few hundred lines of code, so it's easier to check and trust that it faithfully implement the rules.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's good, thanks!

@bugarela
Copy link
Collaborator Author

bugarela commented Oct 3, 2024

Thank you for all the comments! I believe I addressed all of them and it looks much more solid :)

@bugarela bugarela enabled auto-merge October 3, 2024 14:00
@bugarela bugarela merged commit 2a355b2 into main Oct 3, 2024
14 checks passed
@bugarela bugarela deleted the gabriela/faq-comparissons branch October 3, 2024 14:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants