Lean 4.35 : quatre noyaux supplémentaires pour vérifier les preuves formelles
Sommaire
En bref
- Lean v4.35 ajoute la commande lake check pour revalider les développements avec plusieurs noyaux indépendants, dont con-leche, le premier noyau Lean écrit et prouvé consistent en Lean lui-même.
- Cinq noyaux au total (le noyau officiel, con-leche, con-ron en Rust, nanoda, lean4lean) peuvent être exécutés en parallèle via lake check --paranoid pour détecter les bugs de noyau qui auraient survécu à un seul vérificateur.
- Con-leche s'exécute 30% plus vite que le noyau officiel sur Mathlib et élimine une classe complète de bugs : les erreurs de programmation du kernel lui-même, grâce à sa preuve formelle de cohérence.
- La motivation est explicite : des agents IA ont découvert des failles critiques dans le kernel Lean en août et août, d'où le renforcement de la robustesse.
Ce que dit la source
Le noyau Lean (le proof checker) a subi au moins deux exploitations graves par des agents IA (postmortems publiés en août). Lean renforce donc sa défense en offrant aux utilisateurs la capacité de revalider leurs preuves avec plusieurs implémentations de kernel indépendantes, réduisant le risque qu'une faille unique invalide silencieusement une proof library entière.
- Con-leche est le premier kernel Lean prouvé formellement consistent en Lean lui-même, implémenté par Claude Opus/Fable sous supervision de Joachim Breitner à la Lean FRO, éliminant les bugs de programmation du kernel mais pas ceux du compilateur ou runtime.
- Con-ron est la version Rust de con-leche, vérifiée via Aeneas (outil de preuve Lean pour Rust), ajoutant une couche de protection contre les bugs du compilateur Lean ou du runtime Lean en les isolant des bugs potentiels du compilateur Rust.
- Sur Mathlib complet, con-leche exécute 0.69x les instructions du kernel officiel et complète la vérification en ~100 secondes sur 8 threads, sans pénalité de performance.
- Les quatre kernels supplémentaires (nanoda, lean4lean, con-leche, con-ron) s'exécutent tous en parallèle via lake check --paranoid dans un sandbox, et le processus est exécutable localement pour chaque développement.
- Lean 4.35 inclut aussi une variante du kernel officiel compilée avec un allocateur mémoire durci qui transforme la corruption mémoire en abort vérifiable plutôt qu'une réponse silencieusement fausse.
Dans les commentaires
Débat partagé entre reconnaissance technique et questions de proportionnalité. Les commentateurs applaudissent le design (Lean + IA = productivité formelle), mais plusieurs demandent des clarifications : la distinction entre "verified" (prouvé consistent) et "cross-check" (juste différentes implémentations), le paradoxe de la vérification infinite (checkers all the way down), ou le risque résiduel dans les couches compilateur/runtime que même plusieurs kernels ne capturent pas.
- Un commentateur conteste le vocabulaire : "AI agents are very effective at finding vulnerabilities" est imprecis ; il faudrait dire "weaknesses" car toute vulnérabilité est une faiblesse, mais l'inverse n'est pas vrai.
- Plusieurs demandent une clarification sur le sens de "verified" : s'agit-il d'une preuve formelle de cohérence (ce qu'est con-leche) ou simplement de cross-checks entre implémentations différentes (ce que font les autres kernels) ? La source use des deux sens sans toujours les distinguer.
- Un argument sceptique soulève le problème des dépendances partagées : les algorithmes d'arithmétique de précision arbitraire réutilisent souvent les mêmes sources (Knuth) ; si un bug y existe, il pourrait affecter la fois con-leche et con-ron malgré leur indépendance affichée.
- Un commentateur demande directement : pourquoi vérifier un kernel Lean avec Lean lui-même plutôt que de choisir une logique radicalement différente (par ex. Coq) ? La source ne l'adresse pas.
- Le fil observe que Lean + IA redéfinit sociologiquement la formalization : certains mathématiciens contestent moins l'IA que le fait que la collaboration open-source et la preuve formelle ont annulé le prestige du travail solitaire héroïque.
Notre lecture
Cette annonce est solide techniquement : con-leche + con-ron constituent une réponse défendable au risque que le kernel Lean soit lui-même bugué (risque élevé après deux exploitations IA en 2 mois). La stratégie multi-kernel est saine : plutôt que d'ajouter un kernel supposément "parfait", Lean accepte que tous les kernels peuvent avoir des bugs et les force à voter. Le coût opérationnel pour les utilisateurs est minimal : un flag --paranoid remplace un seul appel. Reste des questions non résolues : l'échelle (Mathlib = 2,5M LoC ; le repo Courtade–Kumar dépasse déjà 50M LoC ; Lean FRO prépare des libs de 1B+ LoC) ; le vérificateur de vérificateur ne remonte pas indéfiniment. Pour une équipe utilisant Lean en critique (consensus ou cryptographie), la commande --paranoid vaut le coup. Pour des mathématiques pures, c'est probablement du confort supplémentaire. À surveiller : lean4lean, dont la vérification arrivera dans quelques mois.