Anthropic и компания Theorem, специализирующаяся на формальной верификации, сообщили, что Claude подготовил машинно проверенные доказательства для 239 тестовых точек входа в 123 библиотеках с открытым кодом. Речь идёт о конкретных свойствах безопасности скомпилированных программ для RISC-V и о заданных условиях выполнения — не о доказательстве того, что библиотеки безошибочны во всех ситуациях.
9
5
По словам команды, работа заняла несколько недель. За это время Claude создал около 180 миллионов строк доказательств на языке Rocq. Результат важен не только масштабом: он показывает, что с помощью ИИ формальную проверку, которая обычно требует значительных усилий специалистов, возможно применять к большему числу реальных программ. Но выводы всё равно ограничены тем, что именно было описано и проверено.
3
13
Что именно доказали
Команда использовала существующие тестовые цели Google OSS-Fuzz — проекта, который помогает проверять программы, автоматически подавая на вход множество данных. Их превратили в формальные спецификации: вместо того чтобы только пробовать отдельные варианты, Claude подготовил доказательства о поведении каждой заданной программы в пределах описанного множества входных данных.
3
13
Anthropic сообщает, что проверенные программы должны завершаться штатно, не вызывая ошибок безопасности памяти и не нарушая утверждений программы, для любого входа размером менее 64 МБ. Доказательства учитывают смоделированные ответы Linux и варианты размещения памяти, но действуют только при оговорённых предположениях. Объект проверки — скомпилированные программы для RISC-V, а не абстрактная гарантия для всех версий и способов использования каждой библиотеки.
9
12
Anthropic называет проект первой крупномасштабной попыткой применить ИИ для формальной проверки промышленного программного обеспечения на уровне машинных инструкций. Это характеристика новизны от самой команды, а не независимо установленный исторический консенсус.
7
13
Зачем нужен проверяющий Rocq
Claude создавал доказательства, а ядро проверки Rocq проверяло их механически. Поэтому разработчикам не нужно полагаться на рассуждения модели или вручную перечитывать каждую строку доказательства, чтобы убедиться, что оно принято проверяющей системой. Но машинная проверка не отменяет всех допущений: важно, чтобы формулировка теоремы охватывала нужное разработчикам свойство, а используемые модели и проверяющая система остаются частью основы, которой доверяют.
9
5
По данным Anthropic и других публикаций, общий объём составил около 180 миллионов строк Rocq — в среднем примерно 600 тысяч строк на бинарную программу. Такой объём отражает масштаб работы, но сам по себе не говорит, насколько широко применима конкретная гарантия и соответствует ли она требованиям к программе в реальной эксплуатации.
3
12
Почему одних тестов может быть недостаточно
Фаззинг проверяет программу на множестве входных данных, но сам по себе не доказывает, что она поведёт себя безопасно для каждого возможного входа в заданном диапазоне. В публикациях о проекте говорится, что Claude обнаружил и исправил сотни ошибок, в том числе те, которые не выявили триллионы запусков фаззинг-тестов. Это сообщаемые результаты именно этой работы, а не независимое доказательство того, что формальная верификация всегда эффективнее тестирования.
2
11
Практический вывод не в том, чтобы отказаться от тестов. Формальное доказательство добавляет другой вид уверенности: для указанного свойства и заданных условий оно может подтвердить поведение на всех входах, удовлетворяющих спецификации, а не только на тех случаях, которые попались во время тестирования.
9
2
Почему «проверено» не означает «ошибок нет»
Гарантии относятся к выбранным точкам входа и конкретным скомпилированным программам. Они автоматически не распространяются на все функции библиотеки, варианты сборки, процессорные архитектуры и способы использования кода.
9
5
Важны и условия проверки. В публикациях описаны однопоточные статические программы для RISC-V, работающие в смоделированной среде Linux с фиксированным объёмом памяти. Это не позволяет автоматически делать выводы о версиях для других архитектур или конфигураций, которые могут использоваться в эксплуатации.
12
27
34
Наконец, доказательство подтверждает сформулированную теорему, а не все свойства, которые могут быть важны разработчику. Ошибки могут оставаться за пределами проверки — или в используемых моделях и самой основе, на которую опирается процесс доказательства.
5
31
Что из этого следует для разработчиков
Главный результат проекта — свидетельство того, что помощь ИИ может сделать формальную проверку машинного кода более практичной для реального ПО и применимой в большем масштабе. Это не универсальная оценка стоимости и не гарантия, что такой метод сработает для любой кодовой базы.
7
13
В открытый доступ выложили только часть материалов: один из источников указывает, что опубликованный набор охватывает 25 библиотек и 60 точек входа, а не весь проект. Theorem также объявила программу OSS Verify для проектов с открытым кодом.
32
16
38
Разработчику стоит воспринимать такое доказательство как гарантию с чётко очерченными границами: перед тем как на него полагаться, нужно проверить точку входа, скомпилированную программу, допущения и сформулированное свойство. Результаты дают повод оценить формальную верификацию с помощью языковых моделей наряду с тестированием — но не заменять ею тесты и не считать программу свободной от ошибок.
9
5