אינטגרציה עם CoW Protocol להגנה מפני MEV

הפסדי MEV בהחלפה: כיצד פועלת אינטגרציית CoW Protocol

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

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

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

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

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

חישוב אצווה של הזמנות: מה משתנה בעסקאות

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

מחיר ביצוע: חישוב אחד לכל האצווה

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

שיעור העסקאות הכושלות יורד פי כמה

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

יירוט: הגנה בסדר הביצוע עצמו

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

מה אנחנו מתעדים במטריקות

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

CoW Protocol: מצבי חיבור ומגבלות

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

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

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

שלבי חיבור: מביקורת הזרימה ועד להשקה

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

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

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

מה אנחנו מוסרים: קונפיגורציות, סכימות, תקנונים

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

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

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

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

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

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

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

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

מקרה בוחן: שיעור התקפות סנדוויץ' בזרימה לפני ואחרי

לפני: יירוט בממפול פתוח

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

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

אחרי: ביצוע באצווה במקום הזמנה גלויה

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

מה השתנה במספרים: שיעור העסקאות שבוצעו גרוע מהציטוט ירד מ~12% ל-0.3%, החלקה ממוצעת — מ-0.6–1.2% ל-0.05–0.15%, שיעור החזרות עקב בדיקת החלקה — מ-7% ל-1%. את סף הסטייה המותר מחזיקים קפדני, ולא עם מרווח ליירוט.

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

מכרז אצווה לעומת החלפת AMM: מה ההבדל

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

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

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

ניתוח ספקות טכניים נפוצים

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

מי אחראי אם פותר חיצוני לא ביצע את ההזמנה?

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

מה בדיוק נבדק לפני החיבור?

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

האם ניתן להעביר רק חלק מהזרימה?

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

נדון במשימה: סדר התחלת העבודה

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

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

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

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