יצירת חוזים חכמים ב-Solidity באמצעות בינה מלאכותית: אבטחה ומהירות

יצירת חוזים חכמים באמצעות AI: היכן התהליך נשבר

המודל מפיק קוד בביטחון, הוא מתקמפל, ובדיקות דמה עוברות — ובדיוק בגלל זה התקלה נראית תמימה. יצירת חוזים חכמים באמצעות AI מעבירה שגיאות מתחביר לסמנטיקה: שגיאת הקלדה המהדר יתפוס, אבל סדר הבדיקות והרשאות למשיכת כספים הוא לא מנתח.

הקבוצה הנפוצה ביותר — שגיאות בקוד שנוצר סביב העברות. שליחת כספים מופיעה לפני עדכון היתרות, ערך ההחזרה של קריאה ברמה נמוכה מתעלמים ממנו, ספרות עשרוניות של הטוקן ועמלה לא נלקחות בחשבון.

בדיקת לוגיקת ההעברות על עותק של הרשת הראשית עם יתרות אמיתיות חושפת זאת תוך דקות — אם בדיקה כזאת בכלל מתוכננת.

הקבוצה השנייה — הרשאות גישה וקריאות חיצוניות. פונקציית המשיכה נשארת ציבורית בלי מודיפייר, האתחול נקרא שוב, חוזה חיצוני מקבל שליטה לפני קיבוע המצב. פגיעות כזאת בחוזה לא שוברת את הבנייה, אבל נותנת תרחיש מוכן למשיכת כספים.

מחיר נפרד — פריסה בלי בדיקה. חוזה מהודר ב-Solidity הוא בלתי ניתן לשינוי: סף שגוי או כתובת נמען לא ניתן לתקן בעדכון, יש צורך במיגרציית מצב והנפקה מחדש של כתובות אצל כל מי שכבר מקיים אינטראקציה עם החוזה.

לכן אנחנו מחזיקים את היצירה כטיוטה, ולא כריליס: בהמשך מגיעים ניתוח ידני של הרשאות, סדר הבדיקות, מעבר אוטומטי על נתוני קלט וסימולציית תקיפות על עותק של הרשת. להלן — כיצד זה נסגר שלב אחר שלב.

מהירות היצירה מול מחיר הטעות בלוגיקה

יצירה לפי תיאור פורמלי מקצרת את הוצאת הגרסה הראשונה של החוזה ואת התיקונים לו. השלד — תפקידי גישה, אירועים, בדיקות ארגומנטים בקלט, ניתוח מצב — נבנה במעבר אחד, ושינוי כלל מביא לעדכון עקבי של מקומות קשורים, ולא לתיקון ידני בחמש פונקציות.

המחלקות המכניות של שגיאות נעלמות הכי מהר: בדיקה שהוחמצה לכתובת אפס, סדר פעולות שגוי, העברת מצב שנשכחה. היקר ביותר הוא מה שהיצירה לא רואה: לוגיקה כלכלית, סדר קריאות חיצוניות, אינווריאנטים של מצב תחת טרנזקציות מתחרות.

אותם מנסחים ידנית ובודקים בהרצות תכונות על קלטים אקראיים — Echidna מאתרת אותם בעצמה ושוברת את החוזה במקום שבו הדוגמאות לא חשבו עד הסוף.

את תקציב הזמן כדאי לחלק במודע: היצירה מכסה את ההוצאה והתיקונים, וההשקעה הולכת לאינווריאנטים, בדיקות כשל ובדיקה לפני פריסה. הרצה על רשת בדיקה עם אותם פרמטרים כמו ברשת הראשית היא חובה — את מה שנחסך ביצירה אין להחזיר מהבדיקה.

מצבי יצירת חוזים: ידני, תבניתי, גנרטיבי

מצב יצירת החוזה קובע לא את מהירות כתיבת הקוד, אלא את נפח תשומת הלב שנשאר לבדיקת הלוגיקה. פיתוח חוזה ידני נותן שליטה מלאה במבנה האחסון ובסדר הקריאות — זה הכרחי במקום שבו טעות בענף אחד של תנאי מובילה לאובדן כספים.

חוזים תבניתיים מקבעים סכימה שכבר נבדקה: הנפקת טוקנים, תפקידים, השהיה, הגבלות על משיכה. נשאר למלא פרמטרים ולא להמציא מחדש את מודל ההרשאות.

מצב גנרטיבי מאיץ את הטיוטה, אבל לא מחליף בדיקה. המודל בונה שלד ותשתית למשימה מסוימת, והמהנדס משווה שורה אחר שורה אריתמטיקה, הרשאות וקריאות חיצוניות: קוד שלא נבדק לא נכנס לסקריפט הפריסה.

בחירת המצב נובעת מאופי המשימה, לא מאופנה. בפועל אנחנו משלבים: טיוטה גנרטיבית לשלד, מודולים תבניתיים לחלקים טיפוסיים, והשלמה ידנית של הליבה והגבולות שבהם מחיר הטעות הוא המקסימלי.

שלבי העבודה: מניתוח המשימה ועד מסירה לתפעול

יצירת קוד על ידי המודל היא טיוטה, לא ארטיפקט מוכן: היא נותנת במהירות מבנה חוזה, אבל לא אחראית למצבי קצה ולהרשאות קריאה. לכן סביב יצירת AI נבנה תהליך הנדסי רגיל, שבו כל תוצאה ניתנת לבדיקה. להלן שלבי היישום שאנחנו עוברים בפרויקט.

1. ניתוח דרישות וסכימת מצבים. מקבעים תפקידים, מעברים ואינווריאנטים: מה החוזה מתיר ומה הוא אוסר תמיד. הסכימה מסוכמת לפני כתיבת הקוד — תיקון שלה אחר כך עולה יותר.
2. יצירת טיוטה. המודל בונה מבנה חוזה ב-Solidity לפי הסכימה המוסכמת: אחסון, פונקציות, אירועים. הגבלות וסגנון מגדירים מראש, כדי שיהיה קל לתחזק את הקוד.
3. בדיקות אבטחה. ניתוח סטטי, בדיקות על ערכי קצה וקבוצות נתונים אקראיות, ניתוח ידני של הרשאות גישה וקריאות חיצוניות. כל בעיה שנמצאת הופכת לבדיקה שלא תפספס אותה יותר.
4. הרצה על רשת בדיקה. משחזרים רצפים אמיתיים של פעולות, כולל שגויים: ביטול טרנזקציה, קריאה חוזרת, אי-זמינות של שירות חיצוני.
5. קבלת התוצאה. משווים כיסוי נתיבים מרכזיים בבדיקות ופערים מול הדרישות המקוריות; דוח עם הבדיקות נשלח ללקוח.
6. מסירה לתפעול. פריסה, קיבוע פרמטרי סביבה, הדרכת צוות הלקוח להרצה ולניטור עבודת החוזה.
7. תקנון תיקונים. איך מבוצע שינוי, מי מאשר, אילו בדיקות חובה לפני פריסה מחדש.

ארטיפקטים של הפרויקט: מפרטים, מודלי איומים, תקנונים

אחרי המסירה נשאר לצוות הלקוח סט מסמכים שלפיו אפשר לפתח ולתחזק את החוזים בלעדינו. זה לא תיקייה עם קבצים, אלא מערכת מקושרת: המפרט קובע התנהגות, מודל האיומים — גבולות אמון, ותקנון התיקונים — סדר השינויים.

כל ארטיפקט נבדק מול הקוד במסירה: אם תיאור האינווריאנטים סותר את הלוגיקה, העבודה לא מתקבלת. להלן מה שנשאר בידיים.

• מפרט החוזה — תפקידים, מצבים ומעברים, קריאות חיצוניות ואירועים: מה החוזה חייב לעשות ומה אסור.
• תיאור אינווריאנטים — תנאים שמתקיימים בכל תרחיש, עם קישור לקטעי קוד ולבדיקות אוטומטיות.
• מודל איומים — וקטורי תקיפה על החוזה הספציפי, הערכת השלכות והגבלות מובנות: לימיטים, עיכובי משיכה, השהיה.
• תקנון תיקונים — מי ואיך מבצע שינויים, אילו בדיקות חובה לפני עדכון, איך לחזור לגרסה קודמת.
• הרשאות גישה — מפת תפקידים ומפתחות: למי יש אילו סמכויות, היכן נשמרות, איך מועברות ומבוטלות.
• תיעוד תחזוקה — פריסה, מיגרציות מצב, מעקב אחר אירועים, תקלות טיפוסיות וסדר פעולות.
• דוח בדיקות — מה נמצא בניתוח סטטי ובניתוח ידני, מה נסגר, ומה הושאר במודע.

הסט חי יחד עם הקוד: תיקון גורר עדכון של המפרט ומודל האיומים, אחרת התיעוד סוטה מהחוזה תוך שבועיים.

מקרה בוחן: שיעור הכשלים בלוגיקת העברות ירד פי שלושה

הלקוח — פלטפורמה לתשלומים שוטפים לשותפים. חוזי ההעברות נכתבו ידנית לכל מבצע: הרשאות היו בידי מפתח יחיד, לא היו לימיטים על סכומים ונמענים, וגם לא היה תפקיד נפרד לעצירת פעולות.

במהלך רבעון הצטברו כמה תחקירים: העברות יצאו לכתובת מסביבת בדיקה, חלק מהתשלומים עברו פעמיים בקריאה חוזרת, ולא היה כלי לבטל פעולה שגויה.

המהנדסים שלנו העבירו את הוצאת החוזים ליצירה מתבניות מאומתות: מנתח סטטי Slither מריץ כל וריאציה וחוסם פריסה כשיש הערות. התפקידים פוצלו — יוזם תשלום, מאשר, מנהל האוצר ותפקיד השהיה נפרד; פעולות קריטיות דורשות שני אישורים.

מה השתנה

שיעור התקריות בלוגיקת העברות ירד פי שלושה: מתשע פניות ברבעון לשלוש, וכל השלוש — שגיאות בנתוני קלט, לא בקוד. הוצאת חוזה חדש אורכת שעות במקום כמה ימים, ושיעור הנתיבים הנבדקים אוטומטית עלה מ-40 ל-90%.

הוגדרו לימיטים גם לפעולה בודדת וגם ליממה, כך שטעות אחת לא מרוקנת יותר את כל האוצר. הניתוח מתבצע לפי הלוג: רואים איזה תפקיד יזם את הפעולה, מי אישר ובאיזה שלב פעלה ההגבלה; ביטול — השהיה והעברה חוזרת, בלי תיקון ופריסה מחדש של החוזה.

במה בדיקה פורמלית שונה מביקורת קוד?

בדיקה פורמלית וביקורת קוד עונות על שאלות שונות ולא מחליפות זו את זו. הראשונה מוכיחה תכונות: לפי המפרט נבדק מתמטית שאף נתיב הרצה לא מפר אותו. השנייה קוראת את המימוש ומחפשת את מה שלא היה במפרט.

הוכחת תכונות עוברת בכל הענפים, כולל הנדירים: אינווריאנט יתרה, אי-הגעה לחשבון שלילי, שמירת הרשאות מנהל. אבל נבדק בדיוק מה שנוסח — תכונה שלא נכנסה למודל, בדיקה פורמלית לא תראה. זה גבול הישימות שלה.

לביקורת מגיע מה שלא מתפורמל: הנחות כלכליות, סדר קריאות חיצוניות, התנהגות אורקלים וצדדים שכנגד, לוגיקת פונקציות אדמין. תרחישים ידניים תופסים שגיאה בקונספט — כשהחוזה עושה בדיוק מה שכתוב, אבל כתוב לא מה שהמוצר צריך. מודל יאשר שגיאה כזאת, לא ימצא אותה.

מכאן הסיכון המרכזי — תחושת ביטחון שווא. הסימון «מאומת פורמלית» לא אומר שהמפרט נכון, וביקורת שעברה לא מבטיחה היעדר שגיאה בנתיב נדיר שלא הורץ ידנית.

לכן מחלקים את המעגל: אינווריאנטים של הליבה — חשבונאות, הרשאות, לימיטים — עוברים למודלים פורמליים, אינטגרציות ומעגלי אדמין מכסים בביקורת עם תרחישים ידניים. בדוח מפרטים בנפרד מה נשאר לא מוכח.

ספקות טכניים נפוצים לפני ההתחלה

הספקות לפני ההתחלה הם כמעט תמיד אותם ספקות: מי אחראי לטעות בלוגיקה, מה עושים עם חוזה שכבר נפרס, למי שייכות הזכויות על התוצאה והאם אפשר לבדוק קוד בלי לפרסם אותו בגישה פתוחה. להלן תשובות ישירות, בלי הסתייגויות בסגנון «תלוי במשימה».

יש לנו כבר חוזה פרוס — אפשר לשפר אותו?

כן. מצלמים את המצב הנוכחי ברשת, משווים את הלוגיקה להתנהגות בפועל ומציעים תוכנית: תיקון נקודתי, הרחבה דרך פרוקסי או פריסה מחדש עם העברת רשומות מצטברות והרשאות גישה.

למי שייכות הזכויות על הקוד?

זכויות בלעדיות על קוד המקור, קונפיגורציות והתיאור עוברות ללקוח לאחר הקבלה — בלי הגבלות על המשך פיתוח בידי מהנדסים חיצוניים. הפיתוחים הפנימיים שלנו נכנסים לפרויקט כתלויות רגילות עם רישיון פתוח.

אפשר לבדוק את התוצאה בלי לפרסם את קוד המקור?

כן. הרצת הבדיקות מתבצעת במעגל סגור אצל הלקוח או בסביבה מבודדת, אתם מקבלים דוח, סכימת מצבים וניתוח נתיבים קריטיים. פרסום במרשם פתוח הוא החלטה נפרדת, והוא לא נדרש לבדיקת הלוגיקה.

מה כלול בתחזוקה אחרי ההשקה?

ניטור אירועי החוזה, תגובה לתקריות, עדכון תלויות ותיקונים לפי שינוי דרישות. בנפרד מקבעים סדר כוננות וזמן תגובה לפנייה.

נדון במשימה ונחזור עם הערכה ותוכנית

הערכה מדויקת של העבודה נשענת לא על ניחושים, אלא על נתוני מקור. ככל שתתארו באופן קונקרטי יותר את החוזים ואת מקומם במוצר, כך נניח פחות הנחות בתוכנית היישום — וכך פחות יזוזו לוחות הזמנים כבר בתהליך.

• תפקיד החוזים במוצר: טוקן וחלוקה, אסקרו, הצבעה, גישה בתשלום — מזה תלוי היקף הלוגיקה ועומק הבדיקות.
• רשת היעד ודרישות תאימות: האם נדרשים תקני ERC-20, ERC-721 או ERC-1155, קריאות חיצוניות לאורקלים וגשרים.
• קוד קיים: חוזים נוכחיים, תבניות ופיתוחים — ננתח ונאמר מה נעשה בו שימוש חוזר ומה נכתוב מחדש.
• מודל הרשאות: מי מנפיק, מקפיא ומעדכן את החוזה; האם נדרשים תפקידים, השהיה, ריבוי חתימות ומנגנון עדכון לוגיקה.
• אינטגרציות: ארנקים, צד שרת, אינדקסרים ושירותים חיצוניים שאיתם החוזה מחליף נתונים.
• עומס צפוי ורגישות לעלות טרנזקציות — משפיע על מבני נתונים ואחסון מצב.
• פורמט העבודה ולוחות זמנים: יצירה חד-פעמית עם בדיקה או תחזוקה עם השלמות אחרי ההשקה.

אחרי הניתוח נחזור עם תוכנית יישום לפי שלבים ונקודות סקירה, רשימת בדיקות — ניתוח סטטי, פזזינג, כיסוי בדיקות לנתיבים קריטיים — מפת סיכונים עם הערכת הסתברות ותרחישי נסיגה, וכן הרכב העבודה ולוחות זמנים לכל שלב.

תארו את המשימה בצורה חופשית: זה מספיק כדי לדון בה בצורה עניינית ולחזור עם הערכה ותוכנית.