רווחים:
- יכולת להשתמש בבינה מלאכותית כדי לייצר מסגרות, בדיקות וסקירת טיוטות המבוססות על ספריות מוכחות (למשל OpenZeppelin) ולהבין שבני אדם מבטיחים אבטחת ייצור
- יכולת לאמת את גרסת הקוד, הדפוס ובקרת הגישה המיוצרים על ידי בינה מלאכותית באמצעות קומפילציה, בדיקות ו-testnet
- היכולת להבחין בהידור זה לא אומר שהוא מאובטח וכי testnet וביקורת חיוניים.
כתיבת חוזה חכם שונה מתוכנה רגילה: הקוד שאתה כותב הוא ציבורי, בלתי ניתן לשינוי, ותוכנית שמזיזה כסף ישירות. ביחידה זו תלמדו כיצד להשתמש בבינה מלאכותית כעוזר לפיתוח חוזים חכם; נלמד מהפקת טיוטה ועד כתיבת מבחן, משחזור דפוס ועד אופטימיזציה של גז (עמלת עסקה). אבל בואו נהיה ברורים מההתחלה: AI מייצר שרטוטים; בני אדם מבטיחים קוד מאובטח שנכנס לייצור.
קרקע ראשונה: שפה וסביבה
שפת החוזים החכמים הנפוצה ביותר היא Solidity (השפה של Ethereum ו-EVM - Ethereum Virtual Machine, המכונה הוירטואלית עליה רצים חוזים - רשתות תואמות). האלטרנטיבה היא Vyper (שפה דמוית פייתון שמטרתה להיות מוגבלת וקריאה יותר). הקוד שלך צורך גז (העלות של כל עסקה לבלוקצ'יין); קוד לא יעיל הוא יקר. שמירה על מונחים אלה ברורים בהקשר שאתה נותן אותם ל-AI היא המפתח לקבלת פלט מדויק.
המקום שבו הבינה המלאכותית היא הכי חשובה היא לא ב"כתיבה מאפס" אלא בהפקת המסגרת + תבנית טובה: התחלה תואמת תקנים, שרטוט להוסיף עליו את המומחיות שלך.
שכבות של שימוש ב-AI בקידוד
1. יצירת שלדים. AI כורה במהירות את השלד של אסימון סטנדרטי (ERC-20) או NFT (ERC-721 - תקן נכס דיגיטלי ייחודי). אבל הקפד לגרום ל-AI להשתמש בספרייה מוכחת: למשל, OpenZeppelin (ספריית הקבלנים הסטנדרטית המהומכת והמבוקרת של הקהילה). הכלל הוא להשתמש בבלוק שנבדק במקום לכתוב אבטחה מאפס.
2. תיאור פונקציה וסקירה. הסבר פונקציה קיימת ל-AI מאפשר לך לזהות שגיאות לוגיות מוקדם.
3. יצירת בדיקות. בינה מלאכותית טובה ביצירת מקרי בדיקה למקרי קצה: אפס קלט, מספר גדול מאוד, מתקשר לא מורשה, שיחה חוזרת. זה מזכיר את אחד התרחישים שמדלגים עליהם.
4. גז וקריאות. AI מסמן דפוסים יקרים כמו כתיבת אחסון מיותרת ומציע חלופות.
רמז: הנחה את הבינה המלאכותית "להתבסס על החוזים המבוקרים של OpenZeppelin, לשכתב את האבטחה מאפס." זה הרבה יותר מסוכן עבור AI לכתוב קוד אבטחה מקורי מאשר להשתמש בספרייה שנבדקה.
הנחיה חלשה / הנחיה חזקה
הנחיה חלשה:
כתוב לי חוזה סמלי.
הנחיה זו מסוכנת: לא ברור איזה תקן, איזו רשת, איזו ספריה, איזו דרישת אבטחה. ה-AI מייצר קוד אקראי, אולי מיושן או לא מאובטח.
הנחיה עוצמתית:
תפקידך: מפתח סולידיטי בכיר. צור טיוטת אסימון ERC-20 עבור שרשרת תואמת EVM. כללים:- מבוסס על ERC20 המבוקרים של OpenZeppelin וחוזים הניתנים לבעלים.- כתוב את שורת ה-Solidity והרישיון (SPDX) במפורש.- רק לבעלים יש הרשאה להטביע; להוסיף מכסה נגד לחיצה אינסופית. - הוסף הערת NatSpec לכל פונקציה. - כתוב אבטחה מאפס; השתמש בבלוק הסטנדרטי. - הוסף אזהרה בסוף: "זוהי טיוטה; נדרשת ביקורת ובדיקה". סמן את האזורים שאתה לא בטוח לגביהם עם // TODO.
הבדל: הנחיה חזקה נותנת תפקיד ברור, תקן, ספרייה, גבול אבטחה, תיעוד וציפיות אימות.
ארבע תבניות הניתנות להעתקה
1) שלד מבוסס תקנים:
תפקידך: מפתח Solidity. צור מסגרת חוזה [ERC-20 / ERC-721 / staking] המבוססת על ספרייה מבוקרת של OpenZeppelin. כתוב רישיון SPDX וגרסת פרגמה. הוסף בקרת גישה (מי יכול להתקשר) לכל פונקציה חיצונית. המצאת אבטחה מחדש; השתמש בלוקים סטנדרטיים. זו טיוטה.
2) סקירת פונקציות:
בחנו את הפונקציה הבאה כמו מפתח בכיר: מה היא עושה, אילו מצבים היא משנה, מי יכול לקרוא לה? סמן שגיאות לוגיות אפשריות וסיכוני אבטחה כהיפותזה, ומקשר כל אחת מהן לשורה בקוד. אל תגיד "בטוח" על הסף; רק רשום את נקודות תשומת הלב.
3) טיוטת תרחיש בדיקה:
הצע מקרי בדיקה עבור חוזה זה (יכול להיות טיוטה עבור Foundry/Hardhat). כיסוי ספציפי למקרי הגבלה: אפס קלט, מספר גדול מאוד, שיחה לא מורשית, שיחה חוזרת, אין מספיק כספים. כתבו מה כל בדיקה מאשרת.
4) סקירת גז וקריאות:
בחוזה זה סמנו את הדפוסים שיכולים להוזיל את עלות הגז: כתיבת אחסון מיותרת, שיחה חיצונית בלולאה, חישוב חוזר. הסבר את ההבדל לפני/אחרי בכל הצעה. המלץ על אופטימיזציות פורצות אבטחה; אם זה לא ברור, אמור "שאל את המבקר".
שלושה מארזים קטנים (במספרים)
מקרה 1 - השלד נשמר 4 שעות. צוות אחד כרה את השלד של חוזה הבשלה מבוסס ספרייה מבוקר עם AI תוך 30 דקות; זה לקח ~4 שעות באופן ידני. הצוות הקדיש זמן לאבטחה ובדיקות. הרווח לא הגיע מהעברת אבטחה, אלא מהאצת המסגרת המייגעת.
מקרה 2 - מלכודת גרסה מיושנת. ה-AI ייצר דפוס ששולח את'ר גולמי בהעברה, וזה כבר לא מומלץ מכיוון שנתוני האימון מיושנים. היזם שם לב לכך ושינה אותו לדפוס הנוכחי מבוסס שיחות ומוגן כניסה חוזרת. שיעור: ספריית הבינה המלאכותית/התבנית של ה-AI תמיד מאושרת כעדכנית; AI אינו יודע מעבר לתאריך הפסקת האימון.
מקרה 3 - טיוטת בדיקה הופיעה באג נסתר. בדיקת "מתקשר לא מורשה" שה-AI ייצרה גילתה שהמפתח שכח בקרת גישה בפונקציה. רק לבעלים חסר קו אחד, נתפס תוך 5 דקות ב-testnet; יכול היה להיות אובדן כספים ברשת המרכזית. שיעור: AI מכסה נקודה עיוורת אנושית בבדיקה.
זכירת דפוסי אבטחה עם AI
AI טוב בלהזכיר לך דפוסי פגיעות ידועים כמו רשימת בדיקה. הדפוסים הנפוצים ביותר:
- כניסה חוזרת: ביצוע שיחה חיצונית ללא עדכון הסטטוס. פתרון: צו בדיקות-אפקטים-אינטראקציות, שומר כניסה חוזר.
- חוסר בקרת גישה: כל אחד יכול לקרוא לפונקציה הקריטית.
- הצפת מספרים שלמים: Modern Solidity תופס את רובם, אבל עדיין סיכון בקוד ברמה נמוכה.
- אימות קלט לא הולם: כתובת אפס, בקרת כמות אפס.
- תלות אורקל: אמון עיוור בנתונים חיצוניים (כגון מחיר).
שימו לב: בינה מלאכותית יכולה לזכור את הרשימה הזו, אבל היא לא יכולה להבטיח אם פריט ברשימה נמצא בקוד הספציפי שלכם. רשימת הבדיקה היא התחלה; זה לא תחליף לבקרת מיכל.
קבלת ההקשר הנכון: הסוד לקוד טוב מ-AI
איכות הקוד שה-AI מייצר תלויה ישירות באיכות ההקשר שאתה נותן לו. ב-Web3 זה קריטי במיוחד כי פרט אחד קטן (איזו שרשרת, איזו גרסת Solidity, איזה תקן אסימון) משנה את הפלט כולו. הקשר טוב כולל:
- שרשרת יעד וסביבה: Ethereum mainnet או Layer 2 (Sidechain זול יותר שפועל על גבי ה-Mainchain)? עלות הדלק וכמה תכונות משתנות לפי הרשת.
- גרסה וספרייה: איזו גרסת Solidity, איזו גרסת OpenZeppelin? אם לא צוינה גרסה, בינה מלאכותית עשויה לייצר דפוסים מיושנים והוצאו משימוש.
- דרישות אבטחה: האם יש מכסה, האם ניתן להשהות אותה, האם ניתן להגדיל אותה? אלה צריכים להיאמר מההתחלה.
- אילוצים: מגבלות ברורות כמו "אל תשתמש בהרכבה", "הימנע מקריאה חיצונית", "ייעל גז אך שמור על קריאות".
טכניקה חזקה נוספת היא לבקש תחילה מה-AI את התוכנית, ולאחר מכן את הקוד: "תחילה רשום את הפונקציות של החוזה הזה ומה כל אחד יעשה; כתוב את הקוד ברגע שאאשר אותו." זה תופס את ה-AI הולך בכיוון הלא נכון מוקדם ומאפשר לך לשמור על ההחלטה האדריכלית.
רמז: שאל את ה-AI "למה כתבת את הקוד הזה ככה?" לִשְׁאוֹל. הסבר הרציונל גם יזרז את הלמידה וגם יעלה על פני השטח כל שגיאה לוגית (למשל הנחת אבטחה כוזבת). אל תסמוך על הפלט של AI שלא יכול להגן על הקוד שלו.
טעויות נפוצות
- הוספת אבטחה ל-AI מאפס. השתמש בספרייה שנבדקה.
- לא מאשר את הגרסה/דפוס המיוצר על ידי ה-AI. ייתכן שנתוני האימון ישנים.
- עקיפת רשת בדיקות. כל טיוטה צריכה לרוץ ברשת הבדיקה לפני שהיא עולה לאוויר.
- לא מוסיף NatSpec/תיעוד. בדיקה ותחזוקה הופכים לקשים.
- "זה מורכב, אז זה בטוח" תפיסה שגויה. הידור אינו אומר להיות בטוח.
- שוכחים בקרת גישה. זו אחת הטעויות הנפוצות והיקרות ביותר.
לסיכום
- בכתיבת חוזים חכמה, AI מייצרת מסגרות, בדיקות וטיוטות סקירה; אנוש מבטיח בטיחות בייצור.
- בנה אבטחה לא מאפס אלא מבוסס על ספריות מוכחות (למשל OpenZeppelin).
- העדכניות של הגרסאות והתבניות המיוצרות על ידי YZ מאושרת תמיד.
- בדלי בדיקה הם בעלי ערך בלכידת כתמים עיוורים אנושיים (מקרים מוגבלים, בקרת גישה).
- הידור אינו אומר להיות בטוח; testnet וביקורת הם חובה.
משימת יישום
עבור אסימון ERC-20 פשוט, צור טיוטה באמצעות הנחיית "שלד מבוסס סטנדרטים" למעלה. לאחר מכן: (1) בדוק אם הוא משתמש בספרייה מסומנת, (2) בדוק את בקרות הגישה, (3) צור בדיקות עם הפקודה "טיוטת מקרה בדיקה" ולמעשה הרץ לפחות מבחן מתקשר נוכל אחד. מצא וציין לפחות נקודת אבטחה אחת שה-AI פספס.
רשימת בדיקה
- [ ] ציינתי בבירור את התקן והשרשרת בהנחיה.
- [ ] רציתי הפקה מוכחת מבוססת ספרייה.
- [ ] רישיון SPDX וגרסת פרגמה זמינים.
- [ ] יש בקרת גישה בכל פונקציה קריטית.
- [ ] יצרתי והרצתי בדיקות למקרי הגבלה.
- [ ] אישרתי שהספרייה/התבנית מעודכנת.
- [ ] סימנתי את הקוד לביקורת ובדיקה; לא קיבלתי את זה ללא פיקוח ב-mainnet.