[{"data":1,"prerenderedAt":4},["ShallowReactive",2],{"jao3G64dhR":3},"# Jolt Qed: Formally Verifying The Jolt Zk-VM\n\nThis repository contains proofs written using the Lean theorem proving assistant, towards formally verifying the completeness and soundness of the [Jolt zk-VM](https://github.com/a16z/jolt).\nThe project is _still on-going_, and as Jolt is relatively complex, we logically decompose the task of formally verifying Jolt into the components shown below.\nBlocks in green are complete. \nBlocks in yellow are in-progress and, greyed out boxes are not yet started.\nExplicit details about each component, trust assumptions, and current progress can be found [here](https://randomwalks.xyz/blog/jolt-qed/). \nSee [CONTRIBUTING](CONTRIBUTING.md) for information about how to contribute to this project.\n\n```mermaid\nflowchart LR\n    A[\"Bytecode Expansion\"] --> B[\"Jolt Constraints\"] --> C[\"Jolt Sumchecks\"] --> D[\"Jolt Reductions\"] --> E[\"Commitment Scheme\"]\n\n    classDef complete fill:#22c55e,stroke:#15803d,stroke-width:2px,color:#ffffff\n    classDef inprogress fill:#fef3c7,stroke:#d97706,stroke-width:3px,stroke-dasharray:8 4,color:#92400e\n    classDef pending fill:#f3f4f6,stroke:#9ca3af,stroke-width:2px,color:#6b7280\n\n    class A complete\n    class B inprogress\n    class C,D,E pending\n\n```\n\nA self contained manuscript describing the efforts of formally verifying bytecode expansion is available [here](./jolt-qed.pdf)\n\nIf you wanted to dig around the bytecode expansion source code.\n[This file](JoltBytecode/RiscvInstruction.lean) serves as the main entry point for the bytecode expansion project.\nIt contains 3 large match blocks. \nLoosely, it says given a RISC-V instruction, here is \n\n1. The list of assumptions we make to prove equivalence for this instruction.\n2. Here is the theorem statement we wish to prove.\n3. Here is the proof for the above theorem statement. \n\nThere were 67 expandable RISC-V instructions. \nOnly 60 of them were proven. Details about why the remaining seven instructions were unprovable is given in Section 7 of the pre-print.\n\n## Trusted Reference Model and Provenance\n\n`LeanRV64D/` contains the trusted RISC-V reference model used by these proofs.\nIt was generated from [`abiswas3`'s fork](https://github.com/abiswas3/sail-riscv)\nof the official [`riscv/sail-riscv`](https://github.com/riscv/sail-riscv)\nrepository, using [`abiswas3`'s fork](https://github.com/abiswas3/sail) of the\nofficial [`rems-project/sail`](https://github.com/rems-project/sail) compiler.\nThe complete generation process is documented in\n[Sail RISC-V Into Lean](https://randomwalks.xyz/blog/sail-to-lean/). The upstream\nSail compiler and Sail RISC-V model are distributed under the BSD 2-Clause\nLicense. The complete notice is included in\n[`LeanRV64D/LICENSE`](LeanRV64D/LICENSE).\n\n\n## AI Usage And Miscellany\n\nAs is the case for most projects in present times, AI agents assisted us in writing several proofs.\nWe did not any use any particular skills or MCP servers so far (perhaps there are better ways to do this).\nOur process so far has involved opening two panes, one with an editor equipped with a Lean Language Server (LSP), and the other pane with Codex or Claude.\nThe chats were free form.\n\nThe most frequently used pattern was the following.\nA lot of the theorems in the bytecode expansion project are very similar. \nFor instance the work done to prove equivalence of `LBU` and `LB` RISC-V instructions is nearly identical. \nThey differ in the last step in the application of sign vs unsigned extension. \nIn this case, we carefully prove `LB` with guiding comments, and make the proof easily readable (see `LB_main.lean` for example). \nThen, we tell the AI agent to complete the proof for `LBU` following the exact principles and style. \nIt seemed to be able to close the theorems with very limited guidance. \nWe still skim the proof for `LBU`, but do not read it as thoroughly.\nThis strategy has proven to be extremely valuable so far, and saved us a lot of time.\n\nOn the other hand, we found that agents were not as good at designing definitions from scratch (this could change as models improve, or if we used a better setup). \nIt took a lot of back and forth, and iterations for the ISA to reach its current state.\nSo for the Jolt-ISA definition, almost all of it was written by hand, then the AI-agents was asked to do formatting, and check against the rust code. \nAs an effort to enforce human eyes on all critical components of the code, all comments and documentation about the ISA are hand-written.\nWe found AI agents were particularly bad at writing clear documentation. \n\nThis project was completed over a span of two and a half months, during which we learned a great deal about Lean. \nDifferent proofs were written at different phases.\nThis means that some theorems are simpler and easier to follow than others (though all pass, so this does not a security concern).\nThe goal was always to first have a passing proof for the correct theorem statement.\nOften we let an AI agent loose to close the theorem by whatever means necessary. \nThen, we explored the output and made proofs simpler, and more readable (akin to how one would proof things on paper, though this is not always possible).\nThis process shrunk the code base significantly, and led to greater re-use of theorems.\nWe would eventually like to do this for all proofs, but in the interest of time, we have not yet done this.\nContributions which make proofs shorter, more general and simple are **always** welcome.\n",1790445561011]