מערכת לזיהוי התקפות MEV: הגנת DeFi מפני sandwich ו-front-running

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

שירותי פיתוח בלוקצ'יין

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1375
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1349
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    794
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1087
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1032
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1129

זיהוי MEV: היכן נשברת ההגנה של פרוטוקול DeFi

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

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

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

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

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

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

האפקט של זיהוי MEV: מה משתנה במטריקות

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

זמן תגובה לעסקה חשודה

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

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

שיעור המתקפות שנהדפו והסוג שנעלם של כשלים

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

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

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

מצבי הגנה: ניטור מקוון, ניתוח בדיעבד, היברידי

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

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

מגבלות התוכנית המקוונת

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

מתי מספיק ניתוח בדיעבד

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

שלבי הטמעה: מביקורת זרימת עסקאות ועד מסירה

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

ביקורת ותרשים כללים

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

הגדרה, בדיקה, קבלה

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

מה מועבר לידיים: תצורות, כללים, תקנונים

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

תצורות ותרשימים

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

תקנונים והרשאות גישה

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

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

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

מה היה לפני

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

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

מה השתנה אחרי

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

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

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

במה נבדל ניטור מקוון מניתוח בדיעבד

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

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

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

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

ספקות טכניים: הפעלות שווא ועומס

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

כיצד מסננים הפעלות שווא?

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

איזה עומס ייפול על התשתית הנוכחית?

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

מה לעשות בתרחישי מתקפה לא סטנדרטיים?

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

האם זה תואם להגנה שכבר פרוסה?

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

נדון במשימה: מה נדרש מצדכם

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

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