Anthropic, באמצעות צוות Frontier Red Team ובשיתוף חברת שיטות הפורמליות Theorem, מדווחת שקלוד יצר הוכחות שנבדקו מכנית עבור 239 נקודות כניסה לבדיקות ב־123 ספריות קוד פתוח. ההוכחות נוגעות לתכונות מוגדרות של מניעת קריסה ובטיחות זיכרון בתוכניות RISC-V מקומפלות; הן אינן מוכיחות שהספריות נקיות מכל באג, בכל גרסה ובכל סביבת הרצה.
9
5
היקף העבודה בולט: לפי הצוות, היא נמשכה כמה שבועות והניבה כ־180 מיליון שורות של הוכחות בשפת Rocq. החשיבות הרחבה יותר היא האפשרות להשתמש בבינה מלאכותית כדי להפוך אימות פורמלי של תוכנות אמיתיות לנגיש בקנה מידה גדול יותר — תוך הקפדה שהמסקנות יישארו צמודות למה שהוגדר ונבדק בפועל.
3
13
מה ההוכחות מראות
Anthropic אומרת שההוכחות מראות כי התוכניות שנבדקו מסתיימות כרגיל, ללא שגיאות בטיחות זיכרון וללא כשל של טענות בדיקה, לכל קלט שגודלו קטן מ־64 MB, ובהתחשב בתגובות ובפריסות זיכרון של Linux שנכללו במודל — בכפוף להנחות המוצהרות. מדובר בקובצי RISC-V מקומפלים, ולא בערובה מופשטת לגבי כל גרסה של הספרייה או כל דרך שבה ניתן לפרוס אותה.
9
12
במקום להסתפק בהרצת בדיקות fuzzing — שיטה שמנסה מגוון גדול של קלטים כדי לחשוף תקלות — הצוות השתמש בנקודות הכניסה הקיימות של Google OSS-Fuzz כמפרטים פורמליים. קלוד יצר הוכחות על התנהגות כל תוכנית שהוגדרה, לאורך תחום הקלטים שמכוסה במשפט המתמטי.
3
13
Anthropic מתארת את העבודה כניסיון הראשון בקנה מידה גדול להשתמש בבינה מלאכותית לאימות פורמלי של תוכנת ייצור ברמת שפת האסמבלי. זו הצגת החידוש של הצוות עצמו, ולא קביעה היסטורית שאומתה באופן עצמאי.
7
13
למה חשוב שמערכת Rocq בדקה את ההוכחות
קלוד יצר את ההוכחות, ואילו ליבת ההוכחה של Rocq בדקה אותן. כלומר, אין צורך לסמוך על ההיגיון של קלוד או לבקש ממפתחים לעבור ידנית על כל שורת הוכחה כדי לוודא שהן נבדקו מכנית. עם זאת, הבדיקה אינה מבטלת את כל ההנחות: המשפט הפורמלי צריך לתאר את התכונה שמפתחים באמת רוצים, והמודלים והבודק עצמו הם חלק מהיסודות שעליהם נשענת התוצאה.
9
5
Anthropic ודיווחים נוספים מציינים שהעבודה הניבה כ־180 מיליון שורות של הוכחות Rocq — בממוצע כ־600 אלף שורות לכל קובץ בינארי. היקף הקוד ממחיש את גודל המאמץ, אך מספר השורות לבדו אינו מעיד עד כמה רחבה התכונה שהוכחה או אם היא מתאימה לצורכי הפרויקט בסביבת ייצור.
3
12
מה בדיקות עלולות לפספס — ומה דווח שנמצא
בדיקות fuzzing מפעילות מגוון גדול של קלטים, אך כשלעצמן אינן מוכיחות מה יקרה בכל קלט אפשרי בתחום מוגדר. לפי הדיווחים, קלוד מצא ותיקן מאות באגים, ובהם תקלות שחמקו מטריליוני הרצות fuzzing. אלה נתונים המדווחים על הפרויקט הזה, ולא מדידה עצמאית של היתרון הצפוי מאימות פורמלי בפרויקטים אחרים.
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