# Formal methods A field of mathematically based techniques for specifying and verifying properties of software and systems. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Can you design a chip? Announcing the protocol emulator ASIC competition DevFeed: [Can you design a chip? Announcing the protocol emulator ASIC competition]() Original publisher: [Read original article]() Author: Benjamin Devlin Published: 2026-09-10T00:00:00Z Content type: release Language: en Sources: [Jane Street]() Topics: [Chip design](), [Protocol (disambiguation)](), [Hardware](), [Open Source](), [Emulator](), [cpu](), [Reverse Engineering](), [fpga](), [Formal methods](), [Verilog]() Tags: [chip-design](), [cpu](), [emulator](), [ethernet](), [firmware](), [formal-methods](), [fpga](), [hardware](), [i2c](), [jtag](), [open-source](), [peripheral](), [protocol](), [reverse-engineering]() ### AI overview Jane Street announces a competition to design an open-source, general-purpose protocol emulator ASIC. The proposed chip would use a small programmable CPU to read and write pins, count cycles, and implement protocols in firmware, with fabrication planned through IHP and Tiny Tapeout. ### Source excerpt Last month, we asked you to reverse engineer a chip from nothing but its layout and teased a bigger challenge. Results and our favorite writeups are coming soon. In the meantime, here's our next challenge! This time, you're designing the chip, and we'll pay to fabricate our favorite designs! We're particularly interested in projects with unique functionality, as well as those that demonstrate novel approaches to design and verification methodologies! ## Formal methods with Hillel Wayne DevFeed: [Formal methods with Hillel Wayne]() Original publisher: [Read original article]() Author: Gergely Orosz Published: 2026-07-29T16:22:31Z Content type: article Language: en Sources: [The Pragmatic Engineer]() Topics: [Formal methods](), [Formal verification](), [Software Engineering](), [distributed-systems](), [Artificial Intelligence]() Tags: [ai](), [distributed-systems](), [formal-methods](), [formal-verification](), [software-engineering](), [version-control]() ### AI overview Hillel Wayne discusses why formal methods such as TLA+ matter for reliable software, how formal verification tools fit into software development, why distributed systems are difficult to reason about, and whether AI could make these methods more accessible. ### Source excerpt Hillel Wayne explains why formal methods like TLA+ matter, how they help build reliable software, and whether AI will finally bring formal verification into the mainstream. ## The final boss of reliability: formal verification DevFeed: [The final boss of reliability: formal verification]() Original publisher: [Read original article]() Author: Glauber Costa Published: 2026-07-07T00:00:00Z Content type: article Language: en Sources: [Turso Blog]() Topics: [Formal methods](), [Turso](), [SQLite](), [Databases](), [debugging]() Tags: [article](), [bug](), [bugs](), [debugging](), [engineering](), [formal-methods](), [formal-verification](), [sqlite](), [testing](), [turso]() ### AI overview The article explains how Turso is partnering with Aretta AI to add formal verification to its reliability and testing practices. It discusses Turso's SQLite compatibility, deterministic simulation testing, Antithesis, and the cost of finding bugs late in the process. ### Source excerpt How we are partnering with Aretta AI to bring formal verification into Turso's testing arsenal, and the fsync bug it already caught. ## Leanstral 1.5: Proof Abundance for All DevFeed: [Leanstral 1.5: Proof Abundance for All]() Original publisher: [Read original article]() Published: 2026-07-02T13:55:54Z Content type: release Language: en Sources: [Mistral AI Blog]() Topics: [Lean](), [Formal methods](), [Artificial Intelligence](), [Open Source](), [hugging face](), [API](), [Code]() Tags: [apache](), [api](), [code](), [developer](), [formal-methods](), [formal-verification](), [hugging-face](), [launch](), [models](), [open-source](), [reinforcement-learning](), [training]() ### AI overview Mistral releases Leanstral 1.5, an Apache-2.0 licensed model for formal verification in Lean 4. The 6B-active-parameter model reports strong miniF2F, PutnamBench, FATE-H, and FATE-X results, and identifies previously unknown bugs in open-source repositories. ### Source excerpt The most powerful AI platform for enterprises. Customize, fine-tune, and deploy AI assistants, autonomous agents, and multimodal AI with open models. ## Formal methods and the future of programming DevFeed: [Formal methods and the future of programming]() Original publisher: [Read original article]() Author: Yaron Minsky Published: 2026-06-07T00:00:00Z Content type: opinion Language: en Sources: [Jane Street]() Topics: [Formal methods](), [agentic-coding](), [Programming]() Tags: [agentic-coding](), [formal-methods](), [programming](), [software](), [verification](), [verify]() ### AI overview Jane Street explains that the emergence of agentic coding has changed its view of formal methods. The company is now building a team focused on making formal methods more broadly useful for software development, while noting that models assist with the work but cannot independently construct arbitrarily difficult proofs. ### Source excerpt I've been telling people for the last 25 years that Jane Street as an organization was just not interested in formal methods. ## Assumptions weaken properties DevFeed: [Assumptions weaken properties]() Original publisher: [Read original article]() Author: Hillel Wayne Published: 2026-05-20T15:13:16Z Content type: tutorial Language: en Sources: [Newsletter feed for Hillel Wayne's Newsletter]() Topics: [Formal methods](), [Math and Logic](), [Parser](), [JSON]() Tags: [bug](), [formal-methods](), [json](), [math](), [test]() ### AI overview The article explains, using logical implication, why adding assumptions weakens a formal property. It illustrates the idea with tests, formal specifications, fairness constraints, and a JSON parser verified only for ASCII input. ### Source excerpt In some tests are stronger than others, I defined STRONG => WEAK to mean "any system passing test STRONG is also guaranteed to pass WEAK". This uses the logical implication operator, defined as P => Q = !P || (P && Q). Implication may be the most overworked operator in logic. Among other things, it's also used in formal specification, where Spec => Prop means "any system satisfying Spec has property Prop" and ASSUME => Spec means "The assumption ASSUME must hold in order for the system to satisfy Spec." Now let's mush these all together and do some math. To start, "the system has property Prop" is the same as "the system passes the test that checks Prop", so test strength is also property strength. Now let "ASSUME => Prop" mean "the system passes Prop assuming ASSUME is true." In classic logic, if P is true, then obviously !Q || P is true. Further, that is equivalent (just draw the truth table!) to !Q || (P && Q). So for any propositions P and Q, P => (Q => P). In other words, Prop => (ASSUME => Prop). In other other words, "the system passes Prop" is a stronger property than "the system passes Prop whenever our assumptions hold." In other other other words, any assumption added makes a property weaker. This makes intuitive sense to me. A JSON parser that's only been verified with ASCII strings has the property "input only uses ASCII && is valid json => correctly parsed". A better JSON parser that works for all Unicode will have the property "is valid json => correctly parsed", which has fewer assumptions, meaning it's guaranteed to work in a strict superset of cases. It also matches the intuition that "more assumptions means more likely to go wrong". We have a bug whenever Prop is false. The only way for Spec => Prop to be true and Prop be false is if Spec is false, eg our system doesn't satisfy the specification we intended to implement. On the other hand, Spec => (ASSUME => Prop) && !Prop is true whenever Spec and/or ASSUME is false, meaning a correctly-implement ## How we used Quint to find over 10 bugs in SQLite while hardening Turso DevFeed: [How we used Quint to find over 10 bugs in SQLite while hardening Turso]() Original publisher: [Read original article]() Author: Glauber Costa Published: 2026-05-18T00:00:00Z Content type: article Language: en Sources: [Turso Blog]() Topics: [Turso](), [SQLite](), [Formal methods](), [Formal verification](), [API](), [SDKs](), [Test coverage]() Tags: [api](), [article](), [c](), [community](), [engineering](), [formal-methods](), [formal-verification](), [how-to](), [open-source](), [sqlite](), [testing](), [turso]() ### AI overview This article describes how a Turso community member modeled the SQLite C API in Quint, generated execution traces, and ran them against real SQLite to uncover more than 10 bugs. It presents the approach as an effort to strengthen Turso's testing and explore more accessible formal methods. ### Source excerpt A Turso community member modeled the SQLite C API in Quint, ran the generated traces against real SQLite, and uncovered more than 10 bugs along the way. ## New Logic for Programmers (and the future of this newsletter) DevFeed: [New Logic for Programmers (and the future of this newsletter)]() Original publisher: [Read original article]() Author: Hillel Wayne Published: 2026-05-06T17:03:46Z Content type: opinion Language: en Sources: [Newsletter feed for Hillel Wayne's Newsletter]() Topics: [Formal methods](), [Fuzzing/Fuzz testing](), [Testing](), [Programming]() Tags: [developer](), [formal-methods](), [fuzzing](), [newsletter](), [release](), [testing](), [updates]() ### AI overview The author announces version 0.14 of Logic for Programmers, reports progress toward a 1.0 print edition, and shares plans to join Antithesis as a developer educator. The newsletter may shift toward software history and related topics, with its future publishing frequency uncertain. ### Source excerpt So first the immediate news: I just released version 0.14 of Logic for Programmers! This release is pretty similar to 0.13. There are a few rewrites but the vast majority of the changes are layout, copyediting, and technical editing. Full notes here. In related news, I've started doing test prints of the book: There's not a whole lot left to be done. I've gotta fix up some diagrams, do more formatting and proofreading, incorporate some fixes raised by readers, and make a website and back cover. After that, the book should be ready for 1.0. I'm aiming to have print copies purchasable by the end of June! Now the big news: starting August, I'll be a full-time employee of Antithesis, a generative testing platform. Officially my role is "developer educator", and I'll be tasked with making "property-based testing, fuzzing, fault injection, Hegel, Bombadil, and the Antithesis platform understandable to everyday engineers". So the same kind of work I do now, except with far more support and a matching 401(k). I already have three pages of topic ideas you have no idea how excited I am about this So how is this going to affect the newsletter? First, I want to make clear that this is not going to become an Antithesis newsletter. My Antithesis-related work is going to be on their official platforms. I do think one of the best ways to make a topic "understandable" is to write foundational material that's useful to all engineers, whether they're invested in the topic or not. I might share links to things I make along those lines, but they'll be just that, links. At the same time, the content of this newsletter will change a little. Property testing and fuzzing aren't the same as formal methods, but a lot of the foundations overlap, especially in how we think about properties and correctness. I don't know for sure yet, but I suspect that I'll start biasing this newsletter away from Antithesis related topics. So there will probably be less theoretic things like what does undecidabl ## A Look Back on BugBash 2026 DevFeed: [A Look Back on BugBash 2026]() Original publisher: [Read original article]() Author: Mikaël Francoeur Published: 2026-04-27T00:00:00Z Content type: opinion Language: en Sources: [Turso Blog]() Topics: [Software Engineering](), [Testing](), [Formal methods](), [Turso](), [Rust](), [Optimization]() Tags: [formal-methods](), [optimization](), [rust](), [software-engineering](), [testing](), [turso]() ### AI overview A retrospective on BugBash 2026 argues that coding agents may shift measurable software engineering gains toward testing. It discusses deterministic simulation testing, differential testing, fuzzing, example-test DSLs, and formal methods, while emphasizing that correctness involves engineering tradeoffs rather than requiring absolute correctness for every system. ### Source excerpt A summary of the BugBash 2026 conference on software correctness ## LLMs are bad at vibing specifications DevFeed: [LLMs are bad at vibing specifications]() Original publisher: [Read original article]() Author: Hillel Wayne Published: 2026-03-10T17:12:30Z Content type: article Language: en Sources: [Newsletter feed for Hillel Wayne's Newsletter]() Topics: [Formal methods](), [Large Language Model](), [Specifications](), [Artificial Intelligence]() Tags: [ai](), [formal-methods](), [llms](), [nondeterminism](), [specifications](), [verification]() ### AI overview The article examines AI-generated TLA+ and Alloy specifications through a case study. It argues that these specifications may fail to compile or model-check and often contain tautological or obvious properties rather than subtle properties involving concurrency, nondeterminism, or multi-step bad behavior. ### Source excerpt No newsletter next week I'll be speaking at InfoQ London. But see below for a book giveaway! LLMs are bad at vibing specifications About a year ago I wrote AI is a gamechanger for TLA+ users, which argued that AI are a "specification force multiplier". That was written from the perspective an TLA+ expert using these tools. A full 4% of Github TLA+ specs now have the word "Claude" somewhere in them. This is interesting to me, because it suggests there was always an interest in formal methods, people just lacked the skills to do it. It's also interesting because it gives me a sense of what happens when beginners use AI to write formal specs. It's not good. As a case study, we'll use this project, which is kind of enough to have vibed out TLA+ and Alloy specs. Looking at a project Starting with the Alloy spec. Here it is in its entirety: module ThreatIntelMesh sig Node {} one sig LocalNode extends Node {} sig Snapshot { owner: one Node, signed: one Bool, signatures: set Signature } sig Signature {} sig Policy { allowUnsignedImport: one Bool } pred canImport[p: Policy, s: Snapshot] { (p.allowUnsignedImport = True) or (s.signed = True) } assert UnsignedImportMustBeDenied { all p: Policy, s: Snapshot | p.allowUnsignedImport = False and s.signed = False implies not canImport[p, s] } assert SignedImportMayBeAccepted { all p: Policy, s: Snapshot | s.signed = True implies canImport[p, s] } check UnsignedImportMustBeDenied for 5 check SignedImportMayBeAccepted for 5 Couple of things to note here: first of all, this doesn't actually compile. It's using the Boolean standard module so needs open util/boolean to function. Second, Boolean is the wrong approach here; you're supposed to use subtyping. sig Snapshot { owner: one Node, - signed: one Bool, signatures: set Signature } + sig SignedSnapshot in Snapshot {} pred canImport[p: Policy, s: Snapshot] { - s.signed = True + s in SignedSnapshot } So we know the person did not actually run these specs. This is somewhat less of a probl ## Proving What's Possible DevFeed: [Proving What's Possible]() Original publisher: [Read original article]() Author: Hillel Wayne Published: 2026-02-11T18:36:53Z Content type: opinion Language: en Sources: [Newsletter feed for Hillel Wayne's Newsletter]() Topics: [Formal methods](), [Specifications](), [Math and Logic](), [systems]() Tags: [flow](), [formal-methods](), [specifications](), [state](), [statement]() ### AI overview A formal methods consultant introduces possibility properties for reasoning about what can happen in a system, distinguishing them from safety and liveness properties. Using temporal-logic notation and examples involving databases and state machines, the article describes possibility and reachability properties and combinations such as always possible and eventually possible. ### Source excerpt As a formal methods consultant I have to mathematically express properties of systems. I generally do this with two "temporal operators": A(x) means that x is always true. For example, a database table always satisfies all record-level constraints, and a state machine always makes valid transitions between states. If x is a statement about an individual state (as in the database but not state machine example), we further call it an invariant. E(x) means that x is "eventually" true, conventionally meaning "guaranteed true at some point in the future". A database transaction eventually completes or rolls back, a state machine eventually reaches the "done" state, etc. These come from linear temporal logic, which is the mainstream notation for expressing system properties. 1 We like these operators because they elegantly cover safety and liveness properties, and because we can combine them. A(E(x)) means x is true an infinite number of times, while A(x => E(y) means that x being true guarantees y true in the future. There's a third class of properties, that I will call possibility properties: P(x) is "can x happen in this model"? Is it possible for a table to have more than ten records? Can a state machine transition from "Done" to "Retry", even if it doesn't? Importantly, P(x) does not need to be possible immediately, just at some point in the future. It's possible to lose 100 dollars betting on slot machines, even if you only bet one dollar at a time. If x is a statement about an individual state, we can further call it a reachability property. I'm going to use the two interchangeably for flow. A(P(x)) says that x is always possible. No matter what we've done in our system, we can make x happen again. There's no way to do this with just A and E. Other meaningful combinations include: P(A(x)): there is a reachable state from which x is always true. A(x => P(y)): y is possible from any state where x is true. E(x && P(y)): There is always a future state where x is true a ## The Faces of Turso: Meet Alperen Keleş DevFeed: [The Faces of Turso: Meet Alperen Keleş]() Original publisher: [Read original article]() Author: Glauber Costa Published: 2025-08-04T00:00:00Z Content type: article Language: en Sources: [Turso Blog]() Topics: [Turso](), [Open Source](), [Formal methods](), [Programming](), [Rust](), [Databases](), [distributed-systems](), [SQLite]() Tags: [community](), [contribute](), [contributors](), [database](), [distributed-systems](), [formal-methods](), [open-source](), [programming](), [rust](), [sqlite](), [testing](), [turso]() ### AI overview This profile introduces Alperen Keleş, a Turso community contributor and PhD student whose research focuses on formal methods, autonomous testing, and software reliability. It explains how he began contributing to Limbo, Turso's Rust-based SQLite rewrite, because of its focus on distributed systems, databases, deterministic simulation testing, and accessible opportunities for open-source contribution. ### Source excerpt Turso is built by a large community of contributors. Today we get to know Alperen Keles ## Formal Methods: Just Good Engineering Practice? DevFeed: [Formal Methods: Just Good Engineering Practice?]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2024-04-17T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [Formal methods](), [Software Engineering](), [distributed-systems](), [API]() Tags: [api](), [distributed-systems](), [engineering](), [formal-methods](), [software-engineering]() ### AI overview The article argues that formal methods are an important part of good software engineering practice, particularly for large-scale, distributed, and critical low-level systems. It explains that their cost can be offset by reducing rework and the expense of changing systems after their APIs have acquired users. ### Source excerpt Formal Methods: Just Good Engineering Practice? Yes. The answer is yes. In your face, Betteridge. Earlier this week, I did the keynote at TLA+ conf 2024 (watch the video or check out the slides). My message in the keynote was something I have believed to be true for a long time: formal methods are an important part of good software engineering practice. If you're a software engineer, especially one working on large-scale systems, distributed systems, or critical low-level system, and are not using formal methods as part of your approach, you're probably wasting time and money. Because, ultimately, engineering is an exercise in optimizing for time and money1. "It would be well if engineering were less generally thought of, and even defined, as the art of constructing. In a certain important sense it is rather the art of not constructing; or, to define it rudely but not inaptly, it is the art of doing that well with one dollar, which any bungler can do with two after a fashion." Arthur Wellington2 At first, this may seem counter-intuitive. Formal methods aren't cheap, aren't particularly easy, and don't fit well into every software engineering approach. Its reasonable to start with the belief that a formal approach would increase costs, especially non-recurring engineering costs. My experience is that this isn't true, for two reasons. The first is rework. Software engineering is somewhat unique in the engineering fields in that design and construction tend to happen at the same time, and a lot of construction can be started without a advancing much into design. This isn't true in electrical engineering (designing a PCB or laying cables can't really be done until design is complete), or civil engineering (starting the earthworks before you know what you're building is possible, but a reliable way to waste money), or mechanical engineering, and so on. This is a huge strength of software - its mutability has been one of the reasons it has taken over the world - but can a ## Formal-Methods-Based Bugfinding for LLVM's AArch64 Backend DevFeed: [Formal-Methods-Based Bugfinding for LLVM's AArch64 Backend]() Original publisher: [Read original article]() Author: regehr Published: 2022-06-06T14:58:02Z Content type: article Language: en Sources: [Embedded in Academia]() Topics: [Formal methods](), [LLVM](), [Compiler](), [backends](), [Assembly]() Tags: [assembly](), [backend](), [compiler](), [compilers](), [computer-science](), [formal-methods](), [frontend](), [llvm](), [optimization](), [software-correctness]() ### AI overview The article explains how Alive2, a formal methods tool, is extended to validate LLVM's AArch64 backend. The approach lifts compiled AArch64 code into Alive2 IR and checks whether the lifted code refines the original LLVM code, helping identify backend correctness violations. ### Source excerpt [This piece is co-authored by Ryan Berger and Stefan Mada (both Utah CS undergrads), by Nader Boushehri, and by John Regehr.] An optimizing compiler traditionally has three main parts: a frontend that translates a source language into an intermediate representation (IR), a "middle end" that rewrites IR into better IR, and then a backend that [...] ## Formal Methods Only Solve Half My Problems DevFeed: [Formal Methods Only Solve Half My Problems]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2022-06-02T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [Formal methods](), [distributed-systems](), [benchmarking](), [Protocol (disambiguation)](), [Latency](), [Availability](), [Hardware](), [Simulation and Design]() Tags: [availability](), [benchmarking](), [complexity](), [cost](), [design](), [distributed-systems](), [formal-methods](), [hardware](), [latency](), [modelling](), [network](), [prototypes](), [scale](), [simulation](), [verification]() ### AI overview The article argues that formal methods such as TLA+ and P are highly valuable for finding bugs, exploring designs, and documenting protocols in large-scale distributed systems, but they address only part of the questions engineers face. It presents prototyping, closed-form modelling, benchmarking, and simulation as complementary techniques for evaluating latency, cost, hardware needs, availability, durability, overload behavior, and sensitivity to network conditions. ### Source excerpt Formal Methods Only Solve Half My Problems At most half my problems. I have a lot of problems. The following is a one-page summary I wrote as a submission to HPTS'22. Hopefully it's of broader interest. Formal methods, like TLA+ and P, have proven to be extremely valuable to the builders of large scale distributed systems1, and to researchers working on distributed protocols. In industry, these tools typically aren't used for full verification. Instead, effort is focused on interactions and protocols that engineers expect to be particularly tricky or error-prone. Formal specifications play multiple roles in this setting, from bug finding in final designs, to accelerating exploration of the design space, to serving as precise documentation of the implemented protocol. Typically, verification or model checking of these specifications is focused on safety and liveness. This makes sense: safety violations cause issues like data corruption and loss which are correctly considered to be among the most serious issues with distributed systems. But safety and liveness are only a small part of a larger overall picture. Many of the questions that designers face can't be adequately tackled with these methods, because they lie outside the realm of safety, liveness, and related properties. What latency can customers expect, on average and in outlier cases? What will it cost us to run this service? How do those costs scale with different usage patterns, and dimensions of load (data size, throughput, transaction rates, etc)? What type of hardware do we need for this service, and how much? How sensitive is the design to network latency or packet loss? How do availability and durability scale with the number of replicas? How will the system behave under overload? We address these questions with prototyping, closed-form modelling, and with simulation. Prototyping, and benchmarking those prototypes, is clearly valuable but too expensive and slow to be used at the exploration stage. Deve ## High-Throughput, Formal-Methods-Assisted Fuzzing for LLVM DevFeed: [High-Throughput, Formal-Methods-Assisted Fuzzing for LLVM]() Original publisher: [Read original article]() Author: regehr Published: 2022-05-31T14:56:41Z Content type: article Language: en Sources: [Embedded in Academia]() Topics: [Fuzzing/Fuzz testing](), [LLVM](), [Formal methods](), [Testing](), [bug]() Tags: [bug](), [formal-methods](), [fuzzing](), [llvm](), [mutation](), [testing](), [uncategorized]() ### AI overview The article describes mutation-based fuzzing for LLVM optimization passes, combining a custom LLVM IR mutator with the formal methods tool Alive2 to check whether optimizations are correct or buggy. The authors report that generic mutation with radamsa produced mostly invalid or semantically unchanged tests and found no bugs after several days, motivating a structure-aware mutator that preserves LLVM IR invariants. ### Source excerpt [This piece is coauthored by Yuyou Fan and John Regehr] Mutation-based fuzzing is based on the idea that new, bug-triggering inputs can often be created by randomly modifying existing, non-bug-triggering inputs. For example, if we wanted to find bugs in a PDF reader, we could grab a bunch of PDF files off the web, mutate [...] ## Simple Simulations for System Builders DevFeed: [Simple Simulations for System Builders]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2022-04-11T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [Formal methods](), [systems](), [Simulation and Design](), [Python](), [Latency](), [Code](), [Hardware](), [Network](), [Availability]() Tags: [availability](), [cost](), [customers](), [formal-methods](), [hardware](), [latency](), [model](), [network](), [prototyping](), [python](), [queuing](), [scale](), [simulation](), [simulator](), [systems]() ### AI overview This article explains how simple, readable simulations can help system builders investigate properties that formal methods do not directly address, such as latency, cost, hardware needs, network sensitivity, availability, and overload behavior. It presents a Python ski-lift simulator as an example and shows how a small model can produce useful, counterintuitive insights. ### Source excerpt Simple Simulations for System Builders Even the most basic numerical methods can lead to surprising insights. It's no secret that I'm a big fan of formal methods. I use P and TLA+ often. I like these tools because they provide clear ways to communicate about even the trickiest protocols, and allow us to use computers to reason about the systems we're designing before we build them1. These tools are typically focused on safety (Nothing bad happens) and liveness (Something good happens (eventually))2. Safety and liveness are crucial properties of systems, but far from being all the properties we care about. As system designers we typically care about many other things that aren't strictly safety or liveness properties. For example: What latency can customers expect, on average and in outlier cases? What will it cost us to run this service? How do those costs scale with different usage patterns, and dimensions of load (data size, throughput, transaction rates, etc)? What type of hardware do we need for this service, and how much? How sensitive is the design to network latency or packet loss? How do availability and durability scale with the number of replicas? How will the system behave under overload? The formal tools we typically use don't do a great job of answering these questions. There are many ways to answer them, of course, from closed-form analysis3 to prototyping. One of my favorite approaches is one I call simple simulation: writing small simulators that simulate the behavior of simple models, where the code can be easily read, reviewed, and understood by people who aren't experts on simulation or numerical methods. A Quick Example If you hang around with skiers or snowboarders, you'll have heard a lot of talk over the last couple of winters about how crowded resorts have become, and how much time they now spend waiting to ride the ski lift4. Resort operators say that visits have been up only quite modestly, but skiers are seeing much longer waits. Is somebo ## Analyzing Teleport RBAC with Z3: Regexes, queries and formal methods DevFeed: [Analyzing Teleport RBAC with Z3: Regexes, queries and formal methods]() Original publisher: [Read original article]() Author: info@goteleport.com (Andrew Helwer) Published: 2022-01-19T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [Formal methods](), [Access Control](), [Python](), [Software](), [Open Source](), [Software Engineering]() Tags: [access-control](), [formal-methods](), [library](), [open-source](), [python](), [regex](), [regular-expressions](), [security](), [syntax]() ### AI overview This tutorial explains how to use the Z3 theorem prover to analyze Teleport's role-based access control system. It covers checking whether roles admit the same users to the same nodes and handling constraints involving string equality, regular expressions, interpolation, and basic string functions. ### Source excerpt Learn how to use Z3 to ask questions about our RBAC system. Are two roles the same? ## Proofs (and Refutations) using Z3 DevFeed: [Proofs (and Refutations) using Z3]() Original publisher: [Read original article]() Author: Xavier Clerc Published: 2018-02-15T00:00:00Z Content type: article Language: en Sources: [Jane Street]() Topics: [Formal methods](), [Compiler](), [OCaml](), [Development]() Tags: [compiler](), [development](), [formal-methods](), [ocaml](), [tools]() ### AI overview This article describes how Jane Street used the Z3 theorem prover to validate optimizations for the OCaml compiler and identify a subtle bug in one proposed optimization. ### Source excerpt People often think of formal methods and theorem provers as forbidding tools, cool in theory but with a steep learning curve that makes them hard to use in real life. In this post, we're going to describe a case we ran into recently where we were able to leverage theorem proving technology, Z3 in particular, to validate some real world engineering we were doing on the OCaml compiler. This post is aimed at readers interested in compilers, but assumes no familiarity with actual compiler development. ## Dev Update: Formal Methods DevFeed: [Dev Update: Formal Methods]() Original publisher: [Read original article]() Author: Christian Reitwiessner Published: 2016-09-01T19:55:01Z Content type: news Language: en Sources: [Ethereum Foundation Blog]() Topics: [Ethereum](), [Formal verification](), [Solidity](), [Formal methods](), [Coq](), [Compiler](), [Concurrent Programming]() Tags: [compiler](), [developers](), [ethereum](), [formal-methods](), [formal-verification](), [language](), [research-development](), [university](), [verification]() ### AI overview Ethereum announces that Yoichi Hirai is joining the project as a formal verification engineer. The article discusses automatic analysis, manual proof development, and planned formal-methods work for Solidity and Ethereum-related tools. ### Source excerpt Today, I am delighted to announce that Yoichi Hirai (pirapira on github) is joining the Ethereum project as a formal verification engineer. He holds a PhD from the University of Tokyo on the topic of formalizing communicating parallel processes and created formal verification tools for Ethereum in his spare time.... ## How Amazon Web Services Uses Formal Methods DevFeed: [How Amazon Web Services Uses Formal Methods]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2015-03-29T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [Formal methods](), [amazon](), [systems](), [distributed-systems](), [MySQL]() Tags: [amazon](), [article](), [distributed-systems](), [formal-methods](), [mysql](), [systems]() ### AI overview The article announces that "How Amazon Web Services Uses Formal Methods" has appeared in Communications of the ACM. It argues that writing clear specifications helps system designers and programmers understand complex systems, avoid mistakes, and collaborate. It also recommends related reading on Spin and MySQL development, distributed-systems bugs, fault injection, and temporal logic. ### Source excerpt How Amazon Web Services Uses Formal Methods Now in CACM. How Amazon Web Services Uses Formal Methods is in this month's Communications of the ACM. This version isn't changed much from the versions that have been online for a few months, but it's great to see it get some more attention. In the same issue of CACM is Leslie Lamport's Who Builds a House without Drawing Blueprints?. Fans of his writing won't find anything new in there, but it's a perspective and opinion that I love to see gain more traction. We think in order to understand what we are doing. If we understand something, we can explain it clearly in writing. If we have not explained it in writing, then we do not know if we really understand it. And the conclusion: Thinking does not guarantee that you will not make mistakes. But not thinking guarantees that you will. It's a very good take on the subject. As our experiences at Amazon have shown, specification can be an extremely powerful tool in the system designer's and programmer's toolbox. It's even more useful as a team member, where the ability to communicate particularly tough ideas formally and concisely really helps collaboration. Other good formal methods reading this week: A post by Mark Callaghan about using Spin for MySQL development. I haven't spent as much time with Spin (or Promela) as I would like, but it's very interesting. Adrian Colyer wrote a good mini-series this week on SPL, one looking at deep bugs in distributed systems and the other at the background of SPL. He finished up with Lineage-Driven Fault Injection. All three posts, and the papers behind them, are good reading. Not really from this week, or this decade, or century, but still worth it - Lamport's article brought me back to What Good is Temporal Logic?, one of my favorite papers from him. It's extremely interesting to see how his thinking, and chosen framing, has evolved in the last 32 years. ## Use of Formal Methods at Amazon Web Services DevFeed: [Use of Formal Methods at Amazon Web Services]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2014-08-09T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [Formal methods](), [Amazon Web Services]() Tags: [amazon](), [amazon-web-services-aws](), [code](), [concurrency](), [formal-methods]() ### AI overview The article describes how Amazon Web Services uses formal methods, particularly TLA+, to create precise system designs and detect subtle design errors. It explains that precise descriptions make assumptions about failures and concurrency explicit while avoiding the excessive detail of executable code. ### Source excerpt Use of Formal Methods at Amazon Web Services How we're using TLA+ at AWS Late last year, we published Use of Formal Methods at Amazon Web Services about our experiences with using formal methods at Amazon Web Services (AWS). The focus is on TLA+, and why we think it's a great fit for the kind of work we do. From the paper: In order to find subtle bugs in a system design, it is necessary to have a precise description of that design. There are at least two major benefits to writing a precise design; the author is forced to think more clearly, which helps eliminate 'plausible hand-waving', and tools can be applied to check for errors in the design, even while it is being written. In contrast, conventional design documents consist of prose, static diagrams, and perhaps pseudo-code in an adhoc untestable language. Such descriptions are far from precise; they are often ambiguous, or omit critical aspects such as partial failure or the granularity of concurrency (i.e. which constructs are assumed to be atomic). At the other end of the spectrum, the final executable code is unambiguous, but contains an overwhelming amount of detail. We needed to be able to capture the essence of a design in a few hundred lines of precise description. The full paper is worth reading if you're interested in formal methods.