Papers
Topics
Authors
Recent
Search
2000 character limit reached

CSLib: The Lean Computer Science Library

Published 4 Feb 2026 in cs.LO and cs.PL | (2602.04846v1)

Abstract: We introduce CSLib, an open-source framework for proving computer-science-related theorems and writing formally verified code in the Lean proof assistant. CSLib aims to be for computer science what Lean's Mathlib is for mathematics. Mathlib has been tremendously impactful: it is a key reason for Lean's popularity within the mathematics research community, and it has also played a critical role in the training of AI systems for mathematical reasoning. However, the base of computer science knowledge in Lean is currently quite limited. CSLib will vastly enhance this knowledge base and provide infrastructure for using this knowledge in real-world verification projects. By doing so, CSLib will (1) enable the broad use of Lean in computer science education and research, and (2) facilitate the manual and AI-aided engineering of large-scale formally verified systems.

Summary

  • The paper introduces CSLib's unified formalization of foundational computer science models and algorithms in the Lean proof assistant.
  • It presents a novel deductive verification infrastructure, Boole, enabling scalable and transparent reasoning over imperative code intermingled with Lean specifications.
  • The work fosters compositional proofs and cost analysis by integrating advanced logics with AI-driven verification, paving the way for verified software engineering.

CSLib: Foundations for Lean-Based Formal Computer Science

Introduction and Motivation

"CSLib: The Lean Computer Science Library" (2602.04846) introduces an ambitious large-scale effort to unify computer science formalization within the Lean proof assistant. The project adopts the vision and organizational paradigms established by Mathlib for mathematics, with the explicit intent to catalyze both academic research and practical verified software systems. While Mathlib is widely recognized for its role in the formalization of mathematics, Lean lacked an equivalently comprehensive, compositional, and accessible repository for core computer science concepts, algorithms, and verification infrastructure. CSLib seeks to fill this gap, proposing two primary pillars: the formalization of essential computer science artifacts, and infrastructure for Lean-based formal deductive reasoning over everyday code, including code in mainstream imperative languages.

Pillar 1: Comprehensive Formalization of Computer Science in Lean

CSLib explicitly targets the systematic formalization of models of computation, algorithms, and associated mathematical concepts central to computer science. Rather than isolated modules, CSLib's structure is designed to provide an integrated, reusable, and expansible suite of formalisms. The scope is extensive, including λ\lambda-calculus, automata theory, Turing machines (deterministic, probabilistic, quantum), complexity classes, concurrency models, programming language semantics, and a robust algebra of specification logics (Hoare, temporal, separation logic, etc.). In addition, CSLib includes detailed formalizations of canonical data structures and algorithms, with formal, machine-checked proofs of correctness and asymptotic complexity.

The paper presents compositional Lean APIs supporting complexity analysis as computational effects, exemplified by a monadic framework that tracks cost annotations through algebraic operations. This approach enables both correctness and complexity guarantees to be proved directly in Lean, fostering reusable reasoning principles that extend beyond functional correctness to rigorous resource analysis.

Pillar 2: Deductive Reasoning Infrastructure for Real-World Code

The second pillar is the development of deductive verification infrastructure enabling the verification of everyday imperative code via Lean. The centerpiece of this pillar is "Boole," an intermediate verification language (IVL) embedded in Lean and inspired by Boogie. Boole provides a pseudocode-like syntax for imperative programs, intermixing classical constructs with embedded Lean specifications. The pipeline encompasses transpilation from front-end code (future support for Rust, Python, C++, etc.) to Boole, automated generation of Lean verification conditions (VCs), and subsequent discharge of these VCs using Lean tactics including SMT-based proof search and (prospectively) AI-based automation.

Boole's role goes beyond language support: by generating VCs as readable Lean goals, Boole allows for transparent traceability between source code and verification targets, minimizes the trusted computing base (by leveraging Lean's metaprogramming), and enables modular, scalable verification workflows.

(Figure 1)

Figure 1: CSLib's envisioned pipeline for reasoning about imperative code, from source languages through Boole and Lean-based VC generation and discharge.

Technical Realization

The formal design of CSLib emphasizes compositionality and correctness. Algorithmic complexity is treated orthogonally to functional behavior, supporting a range of cost models. The project delivers Lean implementations of fundamental algorithms (e.g., merge sort) with correctness and optimality guarantees available as machine-checkable theorems. Models such as labeled transition systems and bisimulations are defined as first-class Lean objects, bridging state-based, operational, and algebraic techniques.

In the Boole IVL, users specify contracts directly alongside code—preconditions, invariants, and assertions are all succinctly writable, and the underlying system generates verification conditions faithfully reflecting these specifications. Importantly, the generated VCs leverage existing mathematical infrastructure (Mathlib and CSLib), thus supporting scalable, compositional proofs.

Governance, Roadmap, and Community Involvement

CSLib adopts a dual-body governance structure: a steering committee for strategic direction and sponsorship, and a maintainer team for technical development and code review. Community contribution is the expected engine of growth and domain coverage, with active plans for outreach, workshops, and documentation development modeled after the Mathlib community's successful practices.

The roadmap envisions, within two years, complete coverage of core undergraduate algorithms, data structures, and theory topics, extensibility to higher-level areas (concurrency, complexity, compilation, randomized and quantum algorithms), and the Boole infrastructure's maturation toward supporting substantial real-world system verification. Integration with ongoing projects in language formalization (e.g., Aeneas for Rust⊸Lean translation) and with the emerging landscape of verified codebases is explicit.

The Role of AI: Opportunities and Cautions

A salient theme is CSLib's envisioned synergy with the current generation of AI-driven formal proof agents. CSLib not only reduces verification burden and amplifies reliability (partly as a bulwark against the increase in AI-generated but potentially unsafe code), but also provides high-quality training data to further advance AI-based theorem proving. The paper emphasizes that the expressivity of Lean and CSLib's abstractions is critical for unlocking the full potential of advanced AI math and code agents. It also recognizes the necessity of rigorous human code review for any AI-contributed formalizations, ensuring soundness and maintaining human comprehensibility.

Implications and Future Prospects

Practically, CSLib's infrastructure directly addresses bottlenecks in cost and feasibility of formal verification for large-scale, real-world systems. The approach portends significant advances in verified systems engineering, compositional proof reuse, and university-level formal methods education. Theoretically, the integration of advanced logics, cost models, and code abstraction mechanisms in Lean opens new avenues for research in formal semantics, program verification, and AI-driven proof generation. Direct standardization around Lean positions CSLib as a likely cornerstone for the next decade of formal computer science.

The project's integration with translingual engineering (e.g., code migration from C/C++/Rust to Lean/Boole), compositional correctness proofs, and cost-aware formalizations, collectively, chart a path toward unifying engineering, research, and education workflows within a single mechanized ecosystem.

Conclusion

CSLib constitutes a paradigm shift in the formalization of computer science, laying the groundwork for both deep theoretical advances and scalable, practical verification of code. By tightly coupling compositional mechanized formalization, extensible code reasoning pipelines, and the emerging capabilities of AI proof agents, CSLib is poised to recalibrate the landscape of formal methods, education, and verified software engineering. Its ongoing success will depend on both technical rigor and active, cross-disciplinary community participation.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Sign Up to Generate All Videos Subscribe on YouTube

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Sign Up to Generate

Explain it Like I'm 14

Explaining “CSLib: The Lean Computer Science Library”

Overview: What is this paper about?

This paper introduces CSLib, a big, open-source project that helps people write computer science ideas and programs in a way that a computer can check their correctness. It uses a tool called Lean, which is a “proof assistant” — think of it as a super-careful math and code checker that only accepts perfectly logical arguments.

There’s already a famous math library for Lean called Mathlib. CSLib aims to be the computer science version of that — a trusted, shared place where important CS concepts, algorithms, and real code are written in a precise language and proven correct.

Key goals and questions

In simple terms, the project focuses on two main goals:

  • Build a computer-checked library of core computer science knowledge.
  • Create tools so everyday code (like Rust or C++) can be verified inside Lean.

The team is asking questions like:

  • Can we collect important CS models (like Turing machines, automata, and programming language semantics) and prove their properties in Lean?
  • Can we build a bridge from normal code to Lean so we can automatically generate the “proof obligations” that need to be checked?
  • Can we make it easy enough that students, researchers, and engineers find it useful day-to-day?

Methods and approach: How does CSLib work?

CSLib has two “pillars” (two big parts of the plan).

Pillar 1: Formalizing computer science

“Formalizing” means writing definitions and proofs in a strict language the computer understands and can check. CSLib is collecting:

  • Models of computation: ways to describe how computers or programs behave, like the λ-calculus (a math model of functions), automata (abstract machines), and Turing machines (a basic model of computation).
  • Logics: special languages for describing program properties, like temporal logic (for systems that change over time) or separation logic (for programs that use memory and pointers).
  • Algorithms and data structures: classic tools like sorting, graphs, hash tables — plus proofs that they work correctly and how fast they are.

A concrete example:

  • Labeled Transition Systems (LTS) are a way to model a system with states and labeled steps (transitions) between states.
  • “Bisimulation” is a formal way to say two systems behave the same: if one can make a step, the other can mimic it, and they keep matching afterward. CSLib writes these ideas in Lean and proves theorems about them (like: if a relation is a bisimulation, its inverse is also a bisimulation).

Another example: analyzing algorithm speed (complexity) with a simple “stopwatch” effect.

  • CSLib provides a tiny API called TimeM. You can think of TimeM like a box that contains the result of a computation and a counter of how many “steps” it took.
  • A helper function tick adds to the counter wherever you want to count a cost (like a comparison).
  • Using TimeM, they write Merge Sort so it returns both the sorted list and the number of comparisons. Then they prove:
    • It really sorts the list correctly.
    • Its comparisons are bounded by something like n * clog2 n (a standard complexity shape).

This approach makes it clearer to separate “does it work?” from “how fast is it?”, and you can choose what you count as a “step.”

Pillar 2: Reasoning about everyday code (via Boole)

Most code is written in languages like Rust, Python, or C++. How do we verify those inside Lean?

  • CSLib builds an intermediate verification language (IVL) called Boole (inspired by Boogie).
  • You write code plus specs (rules the code must follow) in Boole. For example:
    • A precondition: “n >= 0.”
    • A loop invariant: a rule that must be true every time the loop runs.
    • Assertions: facts that must hold at specific points.
  • The system then generates “verification conditions” — math problems that must be true if your code is correct. These become Lean goals.
  • “Hammers” (automation tools) try to prove these goals. One is an SMT solver, a kind of robot mathematician that solves logical equations and returns a proof that Lean checks.

A simple Boole example in the paper:

  • A program that sums the first n integers.
  • It has a loop invariant that tracks the formula for 0 + 1 + ... + (i-1).
  • The tool generates Lean goals that capture exactly what must be true for the code to be correct.
  • An SMT-based tactic solves all the goals automatically — the code is verified.

Under the hood, CSLib uses projects like Strata and Loom to embed languages in Lean with strong guarantees that the generated verification conditions are trustworthy.

Main findings and why they matter

This is a “vision” paper, but the team already has working pieces:

  • Early formalizations in Lean for models (like transition systems), logics (e.g., linear logic), and classic algorithms (sorting, searching).
  • A lightweight framework (TimeM) to analyze algorithm complexity with proofs.
  • A first version of Boole that:
    • Lets you write code and specs in a clear, pseudocode-like style.
    • Generates readable Lean verification goals.
    • Works with SMT hammers to automatically discharge many proofs.

Why this is important:

  • Software bugs can be expensive or dangerous, especially with AI making code and attackers using AI to find vulnerabilities faster.
  • Formal verification gives high confidence by turning “I tested it” into “I proved it.”
  • CSLib aims to make verification cheaper and more reusable: assemble systems from pre-verified components and use shared proofs.
  • It also creates excellent training data for AI provers, and a language (Lean + CSLib) rich enough for AI to reason about code properties.

The roadmap:

  • 2026: Cover most undergrad-level algorithms and theory topics; mature Boole and its verification pipeline.
  • 2027: Tackle harder areas like complexity theory, concurrency, secure compilation, randomized/quantum algorithms; verify at least one substantial real-world system end-to-end.

Implications and potential impact

  • Safer software: By translating real code into Boole and proving verification conditions in Lean, engineers can catch logic errors and security flaws before they cause harm.
  • Better education: Students can learn algorithms and systems with exact proofs, not just intuition. CSLib can be used in classes to teach correctness and complexity in a hands-on, checked way.
  • Stronger research: Researchers can build on a shared, computer-checked foundation. Results become more reliable and easier to reuse. AI tools trained on CSLib may help discover new algorithms or settle open questions.
  • Community and governance: Like Mathlib, CSLib is community-driven. There’s a steering committee for vision and funding, and maintainers for technical quality. Anyone can contribute formalizations, docs, or translations (like Rust-to-Boole), helping CSLib grow into a universal CS library in Lean.

In short, CSLib aims to make “proof-backed” computer science and verified programming practical, scalable, and widely accessible — for students, researchers, and industry.

View Paper Prompt  View All Prompts 

Knowledge Gaps

Knowledge gaps, limitations, and open questions

Below is a single, concrete list of what remains missing, uncertain, or unexplored in the paper, formulated as actionable items for future work.

  • Scope and coverage: a precise, prioritized roadmap for Pillar 1 topics (e.g., which automata, logics, and models will be formalized first) and criteria for “essential computer science concepts” are not specified.
  • Mathlib boundary: explicit policies and technical criteria for when new mathematical lemmas will be contributed upstream to Mathlib versus kept within CSLib are not defined; cross-repo dependency management and naming conventions remain open.
  • Specification logics: detailed mechanized semantics, inference rules, and soundness/completeness proofs for Hoare logic, separation logic, temporal logics, and linear logic in Lean (and how they interoperate) are not provided.
  • Coinduction tooling: support for coinductive proofs (e.g., bisimulation up-to techniques, coinduction principles, proof automation for LTS-based equivalences) is not described.
  • Algorithmic complexity framework: TimeM’s manual tick annotations risk under/over-counting; there is no automated tick inference or static cost checking to ensure annotation correctness.
  • Lower bounds: the framework cannot express or prove asymptotic lower bounds (e.g., “no algorithm solves X faster than f(n)”) or adversary/decision-tree arguments; a plan to formalize RAM/word-query models and lower-bound methods is missing.
  • Multi-resource costs: complexity semantics only capture “time”; there is no support for space, I/O, energy, cache behavior, parallel work/span, or amortized costs, nor a design for multi-dimensional cost models.
  • Average-case and probabilistic complexity: mechanisms to reason about average-case complexity, randomized algorithms (expectations, tail bounds), and concentration inequalities are not yet integrated.
  • Numerical and floating-point verification: treatment of floating-point semantics (IEEE 754), rounding-error analysis, and numerical stability for optimization algorithms (e.g., gradient descent) is absent.
  • Quantum algorithms: formalization of quantum computation models (circuits, states, measurement) and complexity for quantum algorithms is only listed as a target; concrete encodings, semantics, and tooling are unspecified.
  • Data structures: amortized analysis (potential method), persistent/immutable structures, and advanced structures (e.g., heaps with decrease-key, lock-free structures) lack a stated plan for formalization and complexity proofs.
  • Verified algorithm proofs: the mergesort example elides actual Lean proofs for correctness and time bounds; general proof patterns, reusable lemmas, and automation needed to scale algorithm verification are not demonstrated.
  • Interoperability of Pillar 1 with Pillar 2: clear interfaces to reuse Pillar 1 definitions/specifications directly in Boole VCs (including cost semantics) are not yet designed.
  • Boole language design: the type system, memory model, aliasing/ownership discipline, and concurrency abstractions (threads, atomics, channels) are not defined; alignment with Rust/C++ memory models is an open question.
  • Semantics-preserving transpilation: verified translations from mainstream languages (Rust, C++, Python) to Boole—covering unsafe Rust, lifetimes/borrowing, templates/macros, exceptions/panics, FFI—remain unplanned or unspecified.
  • Trusted Computing Base (TCB): a concrete plan to minimize and formally justify the TCB (parser, transpiler, VC generator, proof reconstruction) is missing; proofs of correctness for the VC generator and transpilation are not provided.
  • VC generation guarantees: soundness, relative completeness, and path-sensitivity of Boole’s VC generation (including treatment of loops, recursion, exceptions, and modular reasoning) have not been formally proved.
  • SMT/hammer integration: coverage, scalability, and proof-reconstruction guarantees for theories needed in systems verification (bitvectors, arrays, quantifiers, non-linear arithmetic, floating-point) are unclear; fallback strategies when SMT fails are not described.
  • Concurrency verification: concrete choices and formalization plans for higher-order concurrent separation logic (e.g., Iris-like frameworks in Lean), atomicity/linearizability proofs, fairness, and progress conditions are missing.
  • Cost semantics in Boole: the design to integrate cost semantics directly into Boole (time, space, amortized, parallel costs) and to connect them to TimeM or RAM-model proofs is unspecified.
  • Verified linking and modularity: semantics for separate compilation, linking, generics/templates, and cross-module reasoning (including interface specifications and refinement/secure compilation) are not addressed.
  • Benchmarks and evaluation: quantitative evaluation plans (proof effort, LOC, verification time, automation rates) and standard benchmark suites to compare against other ecosystems (Isabelle/HOL, Coq, Dafny/Boogie) are not defined.
  • Real-world case studies: criteria for “substantially sized real-world system,” selection of target systems, and a staged plan to achieve end-to-end verification (including maintenance under code evolution) are missing.
  • Documentation and education: concrete deliverables (textbooks, tutorials per CS subfield, searchable docs, examples), onboarding workflows, and teaching integrations (course modules, assignments) are not laid out.
  • AI data curation: processes for building high-quality, licensed datasets from CSLib (train/validation splits, benchmarks), ensuring proof readability, and measuring AI tool contributions vs human review are not specified.
  • Human-comprehensibility: methods to ensure AI-generated proofs are understandable (proof style guidelines, refactoring tools, proof repair), beyond manual PR reviews, are not proposed.
  • Sustainability and governance: long-term funding, contributor incentives, CI/CD and versioning policies (especially across Lean releases), and guidelines to avoid fragmentation across CSLib dialects/libraries are not fully elaborated.
  • Inter-project integration: concrete plans to align with Loom, Strata, Aeneas (semantics compatibility, shared interfaces, licensing), and to avoid duplicated effort are not detailed.
  • Security use-cases: end-to-end workflows for securing AI-generated code (threat models, verification pipelines, metrics for risk reduction) and integration with industrial development tooling (build systems, CI gates) are undeveloped.
View Paper Prompt  View All Prompts 

Practical Applications

Overview

Below are practical applications that follow directly from CSLib’s findings, methods, and innovations (Lean-based formalization of CS, the Boole intermediate verification language, Lean-native verification condition generation, and reusable proof/data assets). Each item notes sectors, potential tools/products/workflows, and key assumptions/dependencies.

Immediate Applications

These can be piloted or deployed now using the current CSLib codebase, Boole-on-Strata prototypes, and existing Lean/Mathlib tooling.

  • Bold, reusable reference library of verified algorithms and data structures — software, education
    • Use CSLib’s growing catalog (sorting/searching, lists, graphs) with machine-checked correctness and complexity guarantees as a drop-in reference for implementation and benchmarking.
    • Tools/workflows: CSLib packages; TimeM complexity API; Lean proofs bundled with executable specs.
    • Assumptions/dependencies: coverage still expanding; engineers need Lean familiarity; performance tuning may require hand optimization when re-implementing in production languages.
  • Curriculum modernization for undergraduate CS (algorithms, theory, PL) — education
    • Adopt CSLib to teach proofs of correctness/complexity, operational semantics, automata, λ-calculi; assign Boole exercises with loop invariants and assertions.
    • Tools/workflows: Boole dialect on Strata, #prove_vcs, Lean-SMT hammer; CSLib modules for LTS/bisimulation.
    • Assumptions/dependencies: instructor onboarding; classroom computing setup for Lean; documentation quality.
  • Rapid prototyping of new algorithms with executable specifications and complexity proofs — academia, R&D labs
    • Formalize novel algorithm ideas with correctness and complexity captured by TimeM, iterate on cost models by moving tick annotations.
    • Tools/workflows: Lean + TimeM; Mathlib big-O; small-scale Boole stubs for imperative variants.
    • Assumptions/dependencies: manual tick placement is error-prone; proofs may need expert guidance.
  • Lightweight deductive verification in CI for small modules — software
    • Gate merges on proving Boole annotations (pre/postconditions, loop invariants) for internal utilities and critical routines (e.g., bounds checks, index arithmetic).
    • Tools/workflows: Boole-to-Lean VC generation (#prove_vcs); smt tactic via Lean-SMT; CI job running lake build + proof scripts.
    • Assumptions/dependencies: Boole feature set is evolving; good for loop-heavy, local properties; requires developer training.
  • Formal modeling of systems with LTS and bisimulation — networking, distributed systems, control
    • Specify and compare protocol/state-machine designs via bisimulation; refactor or optimize implementations with formal behavioral equivalence in hand.
    • Tools/workflows: CSLib LTS and IsBisimulation; Lean proof scripts; test harness linking models to reference traces.
    • Assumptions/dependencies: abstraction gap between models and deployed code; trace alignment requires care.
  • Early-stage security hardening of AI-generated code — software security
    • Verify invariants and absence of trivial defects in assistant-produced snippets (e.g., integer overflows, precondition handling) before integration.
    • Tools/workflows: wrap snippets in Boole with requires/assert; auto-discharge with smt; code-review checklist referencing Lean goals.
    • Assumptions/dependencies: snippet scale must remain small-to-moderate; translation from host language may be manual.
  • Complexity budgeting for APIs and services — software, finance, gaming
    • Track and bound comparisons/operations with TimeM to avoid algorithmic DoS or tail-latency spikes; document complexity budgets with proofs.
    • Tools/workflows: TimeM.tick in verified reference implementations; CI reports of worst-case bounds; ops handbooks citing proven limits.
    • Assumptions/dependencies: mapping from theoretical ticks to wall-clock depends on hardware/data distribution.
  • Seed corpus for training AI formalizers/provers — AI, academia
    • Use CSLib’s high-quality Lean definitions and proofs as training/finetuning data for theorem-proving models and proof-repair tools.
    • Tools/workflows: dataset export pipelines; permissive licensing; evaluation harnesses on CSLib-style tasks.
    • Assumptions/dependencies: careful curation to avoid leakage/overfitting; alignment with community licenses.
  • Verified building blocks for smart contracts (off-chain development reference) — finance, web3
    • Reference proofs for arithmetic utilities, sorting, set/map behaviors to guide on-chain implementations and audits.
    • Tools/workflows: CSLib proofs as audit artifacts; mapping specs to Solidity/Move implementations.
    • Assumptions/dependencies: no direct Solidity/Move transpilation yet; auditors must accept spec-to-code traceability argument.
  • Reproducible research artifacts — academia
    • Publish papers with CSLib-backed mechanized theorems (e.g., reductions, complexity bounds), ensuring exact reproducibility.
    • Tools/workflows: public CSLib branches; GitHub CI that checks proofs; artifact badges in venues.
    • Assumptions/dependencies: community norms; reviewer familiarity with Lean.

Long-Term Applications

These require additional research and engineering (language semantics coverage, Boole feature growth, automation, scale).

  • End-to-end verification pipeline for Rust/C++/Python via Boole transpilers — software
    • Automatically translate annotated source to Boole, generate Lean VCs, discharge with hammers, and ship proof certificates with builds.
    • Tools/products: Rust→Boole, C++→Boole, Python→Boole transpilers; Lean VC pipeline; “proof-gated” CI; artifact attestation.
    • Assumptions/dependencies: fully formalized language semantics; soundness of transpilers; performance of solvers/Lean.
  • Verified operating systems and systems software — software, defense
    • Extend seL4-style results with Lean/Boole, leveraging separation logic and pointer models for memory safety and concurrency.
    • Tools/products: Boole with heap/pointer semantics and Iris-like separation logic; concurrency reasoning; proof libraries for schedulers.
    • Assumptions/dependencies: mature concurrency support; TCB minimization; proof cost and maintainability.
  • Verified cryptographic primitives and protocol stacks (TLS, QUIC) — security, finance, web
    • Prove functional correctness, memory safety, and constant-time properties; generate compliance artifacts for audits.
    • Tools/products: bit-level/spec-level math in CSLib; constant-time side-channel models; verified parsers/serializers.
    • Assumptions/dependencies: realistic side-channel models; integration with high-performance code; auditor acceptance.
  • Certified compilers and secure compilation pipelines — developer tools, safety-critical
    • End-to-end proofs that compiled binaries preserve source-level specs (including cost/complexity where needed).
    • Tools/products: Pillar-1 PL semantics; verified passes; translation validation; regression-proof frameworks.
    • Assumptions/dependencies: full language coverage; practical proof modularity; integration into toolchains.
  • Verified concurrent and distributed protocols (consensus, choreographies) — cloud, blockchain
    • Mechanize safety/liveness for Raft/Paxos, CRDTs, and choreographic code generation with guaranteed adherence to global types.
    • Tools/products: Boole extensions for concurrency; choreography-based synthesis (inspired by VeyMont); liveness proof automation.
    • Assumptions/dependencies: scalable temporal/separation logic; failure and network models; monitoring hooks.
  • Robotics and cyber-physical systems safety proofs — robotics, automotive, aerospace
    • Use LTS/bisimulation (and extensions to hybrid systems) to guarantee controller equivalence, safety envelopes, and mission logic invariants.
    • Tools/products: hybrid dynamics libraries; plant-controller co-modeling; HIL verification workflows.
    • Assumptions/dependencies: continuous-time semantics; sensor/actuator uncertainty models; real-time constraints.
  • Verified ML/AI pipelines (training loops, resource bounds, guardrails) — AI, healthcare, finance
    • Prove invariants for data preprocessing, optimizer implementations, convergence preconditions, and safety filters for model I/O.
    • Tools/products: probabilistic/stochastic models in CSLib; auto-diff semantics; cost semantics for GPU/TPU kernels (abstracted).
    • Assumptions/dependencies: scalable probabilistic reasoning; hardware cost models; evolving ML stacks.
  • Critical infrastructure firmware and grid control logic — energy, IoT
    • Verify low-level C code for controllers (bounds, timing, fail-safe transitions), reducing outage and safety risks.
    • Tools/products: C→Boole pipeline; timing/cost semantics; library of control invariants; audit-ready proofs.
    • Assumptions/dependencies: real-time scheduling models; integration with vendor toolchains; certification pathways.
  • Formally verified smart contracts and DeFi primitives — finance
    • Translate Move/Solidity to Boole, prove safety (no reentrancy/overflow), economic invariants, and gas/cost bounds.
    • Tools/products: Solidity/Move→Boole; cost/gas semantics; invariant libraries for AMMs/auctions.
    • Assumptions/dependencies: precise EVM/Sui/Aptos semantics; auditor/regulatory alignment; gas model stability.
  • Data privacy and policy compliance proofs — enterprise, public sector
    • Encode access control, data lineage, and DP constraints in Lean; verify ETL/analytics code meets regulatory requirements (e.g., HIPAA/GDPR).
    • Tools/products: policy DSL embedded in Lean; connectors for Spark/SQL pipelines; attestations for audits.
    • Assumptions/dependencies: accepted formalizations of policies; sound translation of dataflows; changing regulations.
  • Marketplace of verified components — software supply chain
    • Distribute machine-checked libraries (containers, parsers, crypto, numerics) with proof badges and supply-chain signatures.
    • Tools/products: package registries with proof metadata; SBOM + proof artifact bundling; policy-driven dependency resolution.
    • Assumptions/dependencies: standard proof formats; reproducible builds; ecosystem incentives.
  • Proof-aware IDEs and AI copilots — developer tooling
    • IDEs surface Boole annotations, generate VCs on the fly, and propose Lean proofs or counterexamples; AI assistants trained on CSLib.
    • Tools/products: VS Code extensions; local/remote proof services; AI “proof repair” and “invariant suggestion.”
    • Assumptions/dependencies: latency/UX; robustness of AI suggestions; privacy for enterprise code.
  • Verified quantum and probabilistic algorithms — quantum computing, security
    • Formalize correctness and resource bounds of quantum routines (e.g., Grover/Shor) and classical probabilistic algorithms.
    • Tools/products: CSLib quantum/probabilistic models; bridges to Qiskit/Cirq; cost semantics for qubits/depth.
    • Assumptions/dependencies: stabilized quantum IR semantics; noise/error models; toolchain interop.
  • Scale-out education and certification — education, policy
    • National/industry certifications requiring mechanized proofs in CS curricula; micro-credentials for verified-software skills.
    • Tools/products: standardized CSLib courseware; exam platforms with Lean integration; certification authorities.
    • Assumptions/dependencies: educator training; accessible tooling; policy buy-in.
  • Regulatory standards with proof artifacts — aerospace, automotive, medical
    • New/updated standards accept Lean/CSLib artifacts as evidence for safety/security (akin to DO-178C/ISO 26262 extensions).
    • Tools/products: compliance profiles; proof review guidelines; third-party audit services.
    • Assumptions/dependencies: regulator engagement; scalable, reviewable proof structures; long-term tool stability.

Cross-cutting assumptions and risks

  • Automation: success depends on strong hammers (SMT/ATP/AI) and scalable Lean proof engineering.
  • Semantics fidelity: front-end translators must be sound and cover large language subsets (Rust/C++/Python/Move/Solidity).
  • Trusted computing base (TCB): transpilation and VC generation must remain small, auditable, and formally justified.
  • Performance and developer UX: verification must fit CI budgets and be approachable for non-experts.
  • Community and maintenance: sustained contributions, documentation, and governance are critical for breadth and longevity.
View Paper Prompt  View All Prompts 

Glossary

  • Aeneas project: A translation pipeline that maps a subset of Rust into proof assistants to enable formal verification. "The Aeneas project \cite{ho2022aeneas}, which translates a sizeable subset of Rust into several proof assistants (including Lean), offers a model of such a pipeline."
  • Bisimulation: A relation between system states ensuring they can mutually simulate each other’s transitions, establishing behavioral equivalence. "defines bisimulations, a key notion of equivalence between system states."
  • Boogie (IVL): A widely used intermediate verification language that serves as a backend for several verification tools. "Perhaps best-known is the Boogie IVL~\cite{thisisboogie2,boogieIVL}, which is used by many systems (e.g., Dafny~\cite{leino2010dafny}, Viper~\cite{viper}, CIVL~\cite{civl}, and the Move Prover~\cite{move})."
  • Boole: An intermediate verification language and ecosystem embedded in Lean for specifying and verifying imperative programs. "CSLib's Pillar 2 will be based on a new IVL called Boole, partly inspired by Boogie, but also leveraging the capabilities and advantages of Lean."
  • Choreographic languages: Programming notations that describe the global interactions of concurrent components from a high level. "Choreographic languages"
  • Choreographic programming: A methodology and theory for deriving correct concurrent programs from high-level choreographies. "as found in research on choreographic programming \cite{Montesi23,RubbensBH24}"
  • Cost semantics: A semantic framework that enriches program execution with a notion of cost to reason about complexity. "including cost semantics (to support reasoning about and proving theorems about computational complexity)"
  • Deductive verification: A method of proving program correctness by generating and discharging logical verification conditions derived from code and specifications. "Our approach builds on the rich tradition of deductive verification techniques and tools~\cite{Floyd67,Hoare69}"
  • Deep embedding: Representing a language within a host proof assistant by explicitly encoding its syntax and semantics as data structures. "dialects, which are deeply embedded in Lean."
  • Hammers (proof): Automated proof tactics that integrate external solvers or AI to discharge proof goals in a proof assistant. "Goals in Lean can be proved by hand or by invoking hammers, which are general-purpose tactics for automating proofs of Lean goals."
  • Hoare logic: A logic for reasoning about imperative programs using preconditions, postconditions, and invariants. "Hoare logic is a standard mechanism for specifying procedural code;"
  • Intermediate verification language (IVL): A language used as a target for translating programs and specifications to facilitate verification-condition generation. "intermediate verification languages (IVLs)"
  • Isabelle: A general-purpose interactive theorem prover used for formal specification and proof. "the Isabelle \cite{nipkow2002isabelle} framework."
  • Labeled Transition System (LTS): A formal model of computation that represents states and labeled transitions between them. "Definition of a Labeled Transition System (``LTS''), which models the observable behavior of the possible states of a discrete computational system."
  • Lean proof assistant: An interactive theorem prover and programming language based on dependent type theory. "the Lean proof assistant."
  • Lean-SMT: A tool that connects Lean to SMT solvers by translating goals, obtaining certificates, and replaying proofs in Lean. "This tactic uses the Lean-SMT tool \cite{leansmt} to translate a goal into an SMT formula, call a solver, get a proof certificate, and then replay the proof step-by-step in Lean."
  • Linear logic: A substructural logic that treats propositions as resources, useful for reasoning about state and concurrency. "linear logic is suitable for reasoning about resource usage and concurrent behaviors."
  • Loom: A Lean-based framework for defining embedded languages with guarantees about verification condition generation. "such as Loom~\cite{gladshtein2026foundational} and Strata."
  • Monadic API: An interface using monads to model computational effects—in this paper, to track and reason about time/step costs. "A monadic API for complexity analysis of elementary algorithms."
  • Operational semantics: A formal description of how program statements execute, step-by-step, to define program behavior. "initial Lean formalizations of operational semantics"
  • Petri nets: Graphical and mathematical models of concurrent systems based on places, transitions, and tokens. "Petri nets"
  • Process calculi: Formal models for describing and analyzing concurrent, communicating systems. "Process calculi"
  • Query models: Abstract models for measuring computational complexity via the number of queries/oracle accesses rather than machine steps. "explicit RAM and query models."
  • RAM models: Abstract machine models (Random Access Machine) used to analyze algorithmic time complexity with random access memory. "explicit RAM and query models."
  • Reduction system: A formalism describing how terms are transformed via rewrite or reduction rules, used to define computation. "Reduction System"
  • Resource-bounded Turing machines: Turing machines augmented with explicit limits on resources (e.g., time, space) to define complexity classes. "resource-bounded Turing machines"
  • Secure compilation: Compilation that preserves security properties from source to target, even in adversarial contexts. "secure compilation"
  • Separation logic: A Hoare-style logic enabling local reasoning about mutable heap and aliasing in low-level imperative code. "separation logic simplifies the specification of low-level imperative computations;"
  • seL4: A formally verified microkernel demonstrating end-to-end proof of correctness for an OS kernel. "seL4 \cite{klein2009sel4}, the world's first formally verified operating system kernel."
  • Shallow embedding: Representing a language in a host logic by reusing the host’s syntax/semantics directly (as opposed to deep embedding). "shallowly-embedded languages"
  • SMT: Satisfiability Modulo Theories; decision procedures that determine satisfiability of logical formulas over background theories. "SMT-based hammers."
  • Strata: A Lean-based framework for creating domain-specific languages (“dialects”) with integrated verification tooling. "the Boole dialect of Strata"
  • Temporal logics: Logics for specifying and reasoning about the evolution of system properties over time. "temporal logics are natural for specifying properties of stateful systems;"
  • Trusted computing base (TCB): The minimal set of components that must be correct for the overall verification to be sound. "minimizing the trusted computing base (TCB);"
  • Verification condition: A logical obligation generated from code and specs that, if proved, ensures correctness. "generate verification conditions in Lean."
  • Verification condition generator: A tool that derives proof obligations from programs and their specifications. "a prototype verification condition generator"
View Paper Prompt  View All Prompts 

Open Problems

We found no open problems mentioned in this paper.

Collections

Sign up for free to add this paper to one or more collections.

Sign Up

Tweets

Sign up for free to view the 1 tweet with 91 likes about this paper.

Sign Up for Free

HackerNews

  1. CSLib: The Lean Computer Science Library (3 points, 0 comments) 

Reddit

  1. CSLib: The Lean Computer Science Library (9 points, 7 comments)