פיתוח מערכת לביצוע פקודות מוגן מפני MEV

הגנת MEV: היכן בדיוק הולך לאיבוד מחיר ביצוע ההזמנה

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

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

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

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

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

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

מה נותן ביצוע מנוהל של הזמנות בפועל

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

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

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

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

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

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

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

הגנת MEV: השוואת מצבי ניתוב הזמנות

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

השוואת מצבים

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

שלבי הטמעה: מפירוק הזרימה ועד ההשקה

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

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

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

מה נשאר בצוות: תצורות, מדיניות, נהלים

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

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

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

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

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

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

מה הראה פירוק זרימת ההזמנות

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

מה שינו ומה קרה

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

שיעור העסקאות במחיר הצפוי עלה מ-62% ל-94%, הביטולים ירדו מ-11% ל-2%, והתגובה לזרם הזמנות חריג עברה לאוטומציה — שניות בודדות במקום ארבעים פלוס, בלי מעורבות תורן. הפסד באסטרטגיה נפרדת הפסיק להיות תלוי במי שנמצא באותו רגע במשמרת.

במה שליחה פרטית של הזמנות נבדלת ממכרזים

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

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

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

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

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

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

כבר פרוס אצלנו מעגל ביצוע. להרכיב הכול מחדש?

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

האם השהיות עיבוד ההזמנות לא יגדלו?

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

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

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

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

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

מצדנו נחזור עם:

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

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