פיתוח מערכת הגנה מפני התקפות סנדוויץ' ב-DeFi

מדוע הגנה מפני התקפות סנדוויץ' קריטית לפרוטוקול DeFi

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

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

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

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

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

מה מספקת הגנה מפני התקפות סנדוויץ': השפעות מדידות

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

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

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

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

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

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

גישות להגנה: ערוצים פרטיים, באצ'ינג, מגבלות

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

כיצד בוחרים מנגנון

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

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

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

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

כיצד אנו מיישמים מערכת הגנה מפני התקפות סנדוויץ'

הגנה מפני התקפות סנדוויץ' אינה מסתכמת במסנן אחד ב-mempool. תחילה יש להבין היכן בדיוק אובד הערך: בניתוב ה-swap, ברגע שליחת העסקה או בהגדרות ה-slippage. לכן אנו מתחילים בביקורת של זרימת העסקאות, ולא מתבנית מוכנה.

כיצד בנוי התהליך

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

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

מה הלקוח מקבל לידיו לאחר ההטמעה

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

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

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

מקרה בוחן: הפחתת הפסדים מהתקפות סנדוויץ' במרקטפלייס

מה היה לפני השינויים

מרקטפלייס להלוואות NFT פעל על ממפול ציבורי: בקשות קנייה ומכירה נכנסו לתור באופן גלוי, והבוטים ראו אותן לפני שהעסקה אושרה. שיעור העסקאות שנפגעו מהתקפת סנדוויץ' עמד על 12-14% מכלל ההחלפות הגדולות, והחלקה ממוצעת בקרב משתמשים שנפגעו הגיעה ל-2.8% — לעומת 0.5% שהוצהרו.

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

מה שינו

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

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

מה נהיה

שיעור העסקאות המותקפות ירד מ-12-14% ל-0.6% — היתרה נובעת מתקופות שבהן המרקט-מייקרים עצמם יצאו מהציטוטים. ההחלקה הממוצעת בקרב הנפגעים ירדה מ-2.8% ל-0.4%, כלומר המשתמש מפסיד בעסקה פי שבעה פחות.

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

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

במה שונה ממפול פרטי מבאצ'ינג של טרנזקציות?

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

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

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

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

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

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

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

ספקות טכניים בהגנה מפני התקפות סנדוויץ'

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

אם יש לכם כבר שירות חתימה משלכם או ארנק משמורת, הוא שומר על תפקידו — מה שמשתנה הוא רק מה שנכנס ל-mempool.

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

מה עם אבטחה והרשאות?

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

כיצד בנויה התמיכה לאחר ההשקה?

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

בואו נדון במשימה שלכם להגנה מפני התקפות סנדוויץ'

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

כדי שהשיחה תהיה עניינית, שלחו את הנתונים הראשוניים:

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

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

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