בדיקה ואימות פורמלי עבור Web3 Smart Contract Security

זמן קריאה: 9 דקות

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

1. יש צורך באבטחה תמיד.

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

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

1. בדיקת חוזים חכמה
2. אימות פורמלי של חוזים חכמים

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

2. בדיקת חוזה חכמה

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

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

2.1 אוטומטי

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

2.1.1. בדיקות פונקציונליות

נניח שאתה כותב תוכנית לקחת שני מספרים, a ו-b ולאחר מכן מחזיר את החיבור של שני המספרים. אז כדי לבדוק את התוכנית, אתה נותן 2 ו-8 ומזין את התוצאה הצפויה להיות 10. עכשיו כשהתוכנית פועלת, היא אמורה להחזיר גם 10. אם כן, אז זה עובד בסדר, והקוד שלנו נכון, אבל אם זה לא, אז יש שגיאה כלשהי בקוד שלנו. 

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

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

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

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

2.1.2. ניתוח סטטי

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

2.1.3. ניתוח דינמי

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

ידני 2.2

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

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

2.2.1 ביקורת קוד:- 

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

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

2.2.2 באג באונטי:-

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

3. אימות פורמלי של חוזים חכמים

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

3.1 מהו המפרט הפורמלי?

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

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

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

3.1.1 מפרט

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

// Specification: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public view returns (uint) {
// Implementation details are not relevant to the specification
// …
}

דגם 3.1.2

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

// Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public view returns (uint) {
return a + b;
}

3.1.3 מנוע אימות

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

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

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

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

pragma solidity 0.7.6; // Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint)
function add(uint a, uint b) public pure returns (uint) {
return a + b;
} // Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public pure returns (uint) {
return a + b;
} // Specification: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function test_add(uint a, uint b) public pure returns (bool) {
uint expected = a + b;
uint actual = add(a, b);
return expected == actual;
} // Verification: Verify the correctness of the add function contract TestAdd {
function test_add(uint a, uint b) public view returns (bool) {
return CertoraProver.verify(test_add, a, b);
}
}

בדוגמה לעיל, אנו מגדירים חוזה חכם של Solidity הכולל מודל של פונקציית התוספת, מפרט לפונקציה ומנוע אימות (Certora Prover) שיכול לאמת את נכונות הפונקציה. אנו מגדירים גם פונקציית בדיקה (test_add) שניתן להשתמש בה כדי לוודא את נכונות הפונקציה.

3.2 בדיקה לעומת אימות פורמלי

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

3.3 טכניקות לאימות פורמלית

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

3.3.1 בדיקת דגם

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

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

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

3.3.2 הוכחת משפט

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

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

4. סיכום

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

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

28 צפיות

• הפצת תוכן ויחסי ציבור מופעל על ידי SEO. קבל הגברה היום.
• Platoblockchain. Web3 Metaverse Intelligence. ידע מוגבר. גישה כאן.
• מקור: https://blog.quillhash.com/2023/02/16/testing-and-formal-verification/