פיתוח בוט frontrunning: היכן בדיוק הולך לאיבוד הרווח
עסקת frontrunning מניבה רווח בדיוק פעם אחת — למי שהצליח להיות ראשון בבלוק. ברגע שנוצרת הזדמנות רווחית, כל המשתתפים עם גישה ל-mempool רואים אותה, ומתחיל מרוץ שבו זכייה של אחד שווה להפסד של האחרים. לכן פיתוח בוט frontrunning בלי לפרק צווארי בקבוק אוכל עמלות מהר יותר משהוא מניב תוצאה.
צוואר הבקבוק — מהירות התגובה. בין הופעתה של עסקה זרה ב-mempool לבין שליחת העסקה שלנו צריך לקרוא את מצב ה-pool, להרכיב קריאה, לחתום עליה ולהפיץ אותה בין הצמתים. כל שלב מוסיף השהיה, והמתחרים פועלים במקביל ולעיתים קרובות קרובים יותר לצמתים. הפסד של שברירי שנייה משמעו שההזדמנות כבר נלקחה.
תשלום יתר על עמלת הרשת — סעיף ההפסד השני. כדי לעלות מעל מתחרה בתור לבלוק, צריך להעלות את תוספת העדיפות, ובמכרזים צפופים היא אוכלת את כל הפער. חלק מהניסיונות נכנסים לבלוק כבר בלי מרווח רווח: ה-gas שולם, והתוצאה אינה.
הפעלות שווא משלימות את התמונה. בלי סימולציה של התוצאה על snapshot של המצב, הבוט מגיב לעסקאות שאחרי ביצוע לא נותנות ארביטראז': ה-pool מיושר, ה-slippage גבוה מהצפוי, המגבלות לא עוברות. זו תחרות על עסקאות של אחרים בלי זכייה. בהמשך — כיצד הסיבות האלה נסגרות ארכיטקטונית.
מה נותן פתרון מוכן: מהירות תגובה ושיעור עסקאות
בוט frontrunning ברשת Ethereum — אלה שלושה שכבות עצמאיות, והתוצאה מוגבלת על ידי האיטית שבהן. אין טעם להאיץ את השליחה אם האות מהתור נקרא באיחור, והעמלה נבחרת בעיוורון. בהמשך — מה נותנת כל שכבה ובמה היא נמדדת.
האזנה לתור העסקאות: כיצד מצטמצמת ההשהיה
אנחנו מחזיקים צומת מקומי ונרשמים לזרם של עסקאות לא מאושרות, ולא מבצעים polling לרשת לפי לוח זמנים. הפענוח מועבר לתהליך נפרד: ה-payload מנותח באופן אינקרמנטלי, וקריאות לא רלוונטיות מסוננות לפי כתובות ו-selectors לפני הסימולציה היקרה.
ההשהיה מהופעת העסקה בתור ועד להחלטה מוכנה מצטמצמת פי כמה — צוואר הבקבוק עובר מהרשת לעיבוד שלנו, ועליו יש לנו שליטה.
שכבת האסטרטגיה ושליחת עסקאות: סינון אותות ובקרת עמלה
מועמד מוערך לפי התועלת הצפויה תוך התחשבות במצב ה-pool ובהזמנות מתחרות, ולא רק לפי עצם קיומה של עסקה גדולה. העמלה מחושבת מחדש בכל בלוק: עמלה נמוכה מדי משאירה את העסקה תלויה, גבוהה מדי אוכלת את התועלת — לכן לשליחה עובר רק מה שעובר את הסף, והשאר נזרק לפני החתימה. החלפה של עסקה תקועה ושליחה חוזרת פועלות אוטומטית, בלי התערבות ידנית.
בפועל משתנים שלושה דברים מדידים: שיעור העסקאות שמגיעות לכניסה לבלוק עולה; נעלם סוג של כשלים בגלל מצב מיושן ועמלה שהוגדרה לא נכון; זמן ההשבתה של האסטרטגיה מפסיק להיות הפסד שקט — שחזור המצב לוקח דקות, ולא שעות של תצפית.
מצבי עבודה: השוואת גישות והמגבלות שלהן
המצב קובע מי מקבל את ההחלטה על העסקה — אלגוריתם או מפעיל, ואיזה סיכון הצוות מוכן להחזיק בכל פעולה. בהמשך — שלוש תצורות שבוחרים ביניהן בעת הגדרת אסטרטגיית frontrunning, והמגבלות שלהן.
מצב אוטומטי: מהירות מול שליטה
הבוט בעצמו מרכיב את העסקה, חותם עליה ושולח אותה עם מחיר gas גבוה מהשוק והגנה מפני slippage — העסקה נכנסת לאותו בלוק שבו נמצאת עסקת היעד. הרווח בזמן כאן מקסימלי, אבל אין אדם בלופ: בירידה חדה בנזילות הבוט יבצע כניסה במחיר לא משתלם ולא ישאל.
מצב חצי-אוטומטי: אישור מפעיל בעסקאות גדולות
פעולות קטנות עוברות אוטומטית, וגדולות נכנסות לתור לאישור: המפעיל רואה הערכת תוצאה, מרווח gas והסתברות לכניסה לבלוק. השהיה של שנייה-שתיים סוגרת חלק מההזדמנויות, אבל חוסמת כניסות מפסידות והפעלות על אנומליות שוק.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| אוטומטי | זוגות נזילים, זרימת עסקאות יציבה | אין שליטה באנומליות |
| חצי-אוטומטי | עסקאות גדולות, נזילות דקה | השהיית אישור |
| תצפית | הרצת ניסיון של אסטרטגיה, ביקורת | עסקאות לא מבוצעות |
מצב תצפית כותב ללוג מה הבוט היה מספיק לעשות: פרמטרי gas, תוצאת סימולציה, סטיית מחיר. לפי הנתונים האלה מכווננים ספים ומחליטים אילו עסקאות למסור לאוטומציה.
שלבי הטמעה: מביקורת אסטרטגיה ועד מסירת הקונטור
פיתוח בוט frontrunning מתחיל לא בקוד, אלא בתשובה לשאלה: בזכות מה הפתרון מנצח במרוץ ואיך לבדוק זאת לפני יציאה לרשת הראשית. לכן הצעדים הראשונים הם ביקורת אסטרטגיה ותכנון סביבה, ורק אחר כך הרכבה והרצות. בהמשך — שלבי ההטמעה בסדר שבו אנחנו עוברים אותם.
ביקורת והגדרת השערה
- ביקורת האסטרטגיה הנוכחית — מפרקים את לוגיקת בחירת העסקאות, מקורות האותות ואת הנקודות שבהן הקונטור מאבד זמן או מפסיד למתחרים.
- תרשים הסביבה והצומת — קובעים היכן ממקום הצומת, כיצד הוא מתחבר לרשת, אילו ערוצי שליחת עסקאות נדרשים ואיך מאורגן אתחול מחדש בעת תקלה.
- תיאום כללי ביצוע — תעדוף, ביטול והחלפה של עסקאות, מגבלות על עלות gas, התנהגות במרוץ שהפסדנו.
- השערה בצורה מדידה — מקבעים מדדים שמאשרים כשירות: שיעור ניסיונות מוצלחים, זמן מהאות ועד השליחה, מספר ההזדמנויות שהוחמצו.
הרצת בדיקה ומסירת קונטור
- הרצת בדיקה על נתונים היסטוריים — משחזרים בלוקים וזרמי עסקאות מהעבר, ומשווים את התנהגות האסטרטגיה לזו המחושבת.
- נראות ומנגנוני הגנה — מדדים, התראות, עצירה אוטומטית בסטייה מפרופיל העבודה הצפוי.
- מסירת הקונטור ללקוח — פריסה בתשתית שלכם או על משאבים ייעודיים, הרשאות, נוהל עדכון אסטרטגיה והדרכת הצוות שלכם.
ערכת אספקה: תצורות, תרשימי סביבה ונוהלים
אחרי ההשקה נשאר ללקוח לא רק בוט עובד, אלא כל ערכת האספקה: תצורות ותרשימי סביבה, נוהלי הפעלה, מדיניות גישה למפתחות ותיעוד האסטרטגיה. בלי הארטיפקטים האלה התחזוקה הופכת לתלות בספק, וכל שינוי ממתין לאישור.
תצורות ותרשימי סביבה
- תצורות סביבה: כתובות צמתי Ethereum, מסלולים חלופיים, מגבלות gas וכללי nonce.
- תרשים סביבה: הפרדה בין קונטור בדיקות לקונטור ייצור, נקודות כשל, סדר מעבר ביניהם.
- תיאור התשתית כקוד: פריסה, ניטור והתראות משוחזרים בפקודה אחת.
- פרופילי אסטרטגיה עם פרמטרי סיכון: תשואה מינימלית לעסקה, תקרת עלויות, מגבלות תדירות.
- מדיניות גישה למפתחות: אחסון מפתחות חתימה, הפרדת תפקידי חתימה ומשיכה, רוטציה.
- תרשים זרימות נתונים: מעסקאות נכנסות ועד יומן עסקאות ומדדים.
נוהלי הפעלה ותיעוד
- תיעוד האסטרטגיה: לוגיקת בחירת הזדמנויות, תנאי כניסה, סימני אנומליה.
- נוהל הפעלה ועצירה: בדיקות לפני התחלה, כיבוי בטוח בלי לאבד עסקאות.
- נוהל עדכונים: בדיקת גרסה חדשה בקונטור בדיקות, סדר rollback.
- הנחיות לאירועים: עסקאות תקועות, עליית עלויות, כשל צומת, סדר הסלמה.
- מפת ניטור: מדדים נאספים, ספי התראות, מקבלי הודעות.
- יומן שינויי תצורה עם אפשרות לחזור למצב הקודם.
מקרה בוחן: איך נבנתה מחדש האסטרטגיה וצומצם שיעור העסקאות הכושלות
לפני הבנייה מחדש פירקנו את יומן העסקאות שנשלחו: אילו אירועים הבוט תפס, עם איזה סף רווח הוא נכנס ולמה העסקה לא הגיעה לביצוע. לצורך השוואת מסלולים וסטטוסים השתמשנו בנתוני Flashbots — הם הראו שחלק מהבקשות איבדו משמעות עוד לפני הכניסה לתור.
מה היה לפני בניית האסטרטגיה מחדש
התגובה הייתה לכל אירוע ב-mempool עם סף רווח קבוע ומגבלת gas כוללת. הסף לא התחשב בצפיפות התור, ולכן הבוט נכנס לעסקאות שבהן העמלה אכלה את כל הפער, והתחרה בעצמו כששלח כמה עסקאות על אותה הזמנה.
מה השתנה אחרי הבנייה מחדש
ה-pipeline חולק לשלבים עצמאיים: איסוף אירועים, הערכת כדאיות, סימולציה ושליחה — לכל אחד מגבלות משלו. סף הרווח מחושב דינמית לפי עומס הרשת ועומק ה-pool, וכפילויות נחסמות לפני השליחה, ולא אחרי כישלון.
| מדד | לפני | אחרי |
|---|---|---|
| שיעור עסקאות כושלות | 62% | 18% |
| ביטולים בגלל חוסר gas | 41% | 9% |
| עסקאות חוזרות על הזמנה אחת | עד 4 | 1 |
| עסקאות שנחסמו בסימולציה לפני שליחה | 0% | 55% |
אסטרטגיית הבחירה הפכה לניתנת לבדיקה: כל החלטה ניתנת להסבר לפי הלוגים, ושינויי הספים נבדקים על בלוקים היסטוריים בלי סיכון לקונטור הייצור.
מה לעשות אם הבוט כבר פרוס אבל לא יוצא לרווח?
אבחון בוט frontrunning מתחיל לא בקוד, אלא בפירוק התוצאה לרכיבים: כמה עסקאות הקונטור מביא לסיום, איזה חלק נופל בעת השליחה וכמה gas נשרף לחינם. כל עוד אין פירוק כזה, כל כיוונון נוסף הוא ניחוש, כי המינוס בדרך כלל מורכב משלושה מקורות שונים, והם מטופלים אחרת.
הראשון — השהיה: הזמן מהופעתה של עסקה זרה ועד שליחת העסקה שלנו, איכות הצומת והנתיב אליו, מהירות הרכבת הבלוק מחדש אצל קונטורים מתחרים. אם הבוט מפסיד באופן עקבי בשברירי שנייה, הבעיה אינה בלוגיקת ההימור אלא בתשתית הגישה, והתאמת פרמטרי האסטרטגיה כאן לא תשנה דבר.
השני — הכלכלה של עסקה בודדת. העמלה על כניסה לבלוק עולה מהר יותר מהרווח, עסקאות שהוחזרו מחייבות gas, והביצוע בפועל סוטה מהמודל: slippage ומחיר הכניסה האמיתי אוכלים את המרווח יותר משגיאת האות.
השלישי — סגמנט וסינון. Pool עם נזילות דקה, טוקנים בלי בדיקת חוזה, כניסה ברגעי תחרות שיא על בלוק — המינוס כאן הוא מבני, הוא חוזר כמעט בכל עסקה ולא מפוצה בתיקונים נקודתיים.
את התשובה לשאלה ״לכתוב מחדש או לכוונן״ נותן אותו פירוק. אם ההפסדים מרוכזים בגישה לזרם ההזמנות, בצומת או בשוק הנבחר — כתיבה מחדש של הארכיטקטורה זולה יותר מכיוונון אינסופי של פרמטרים. אם הדליפות מקומיות — מדיניות gas, ספי כניסה, טיפול בכשלים — כיוונון נוסף נותן תוצאה במספר איטרציות.
שאלות טכניות: עמלות רשת, תחרות, עמידות בכשלים
לפני תיאום הארכיטקטורה אנחנו סוגרים חמישה ספקות טכניים שעולים לרוב בהגנת הפרויקט: עומס יתר ברשת ותחרות על מקום בבלוק, אובדן קשר עם הצומת, ספק ציבורי במקום צומת עצמאי, נראות ומסגרת משפטית.
מה לעשות כשהרשת עמוסה והעמלות ממריאות?
בשיא, עמלת הבסיס של הבלוק עולה פי כמה, ועסקה עם תעריף קודם פשוט תלויה ב-mempool. הבוט מחשב מחדש את מחיר הכניסה לפני כל קריאה ושומר על תקרה — בחריגה ממנה האסטרטגיה מפספסת הזדמנות במקום להיכנס למינוס.
קטיעת קשר עם הצומת תשאיר את הבוט בלי עסקאות?
הלקוח עובד עם pool של צמתים שווי-ערך ועובר ביניהם בעת אובדן חיבור, ותור המשימות נשמר לדיסק. אחרי שחזור הקשר הבוט משלים את השליחה ומשווה את המצב מול השרשרת, ולא מול המטמון שלו.
אפשר להסתפק בצומת ציבורי במקום בצומת עצמאי?
ספק ציבורי מתאים למחקר ולהרצות בדיקה, אבל במצב ייצור הוא מוסיף השהיה ומגבלות קצב בקשות משותפות. צומת עצמאי עם מצב שרשרת מלא מסיר את זה: ה-mempool נראה במלואו, ההשהיה צפויה, והבקשות שלכם לא עוברות לצד שלישי.
איך לדעת שהבוט עובד נכון?
אוספים מדדים לכל שלב: שיעור העסקאות שנכנסו לבלוק, זמן מזיהוי ועד שליחה, הפעלות של מנגנוני הגנה, מספר ההזדמנויות שהוחמצו. מעל זה — התראות כאשר המדדים חורגים מהסף.
איפה המסגרת המשפטית?
הטכניקה ניטרלית, את המגבלות קובעים תחום השיפוט וייעוד הרווח: ליווי עסקאות עצמך, ארביטראז' או שירות לזרם של אחרים. את התרשים ונקודות הבקרה אנחנו מתארים, את ההערכה המשפטית הלקוח סוגר עם עורך הדין שלו, ותרחישים שנויים במחלוקת אנחנו חוסמים בשלב התכנון.
נדון במשימה: ממה נתחיל ומה יידרש מכם
אנחנו מתחילים בשיחה על המשימה, ולא בהצעה תבניתית: איזו רשת ואילו פלטפורמות במוקד, איזה זרם עסקאות אתם רוצים לראות, מה אתם מחשיבים כתוצאה — שיעור המרוצים שניצחתם, יציבות בשעות שיא או צפיות עלויות.
בוט frontrunning הוא השערה הנדסית, לכן בשיחה הראשונה מחדדים מגבלות זמן תגובה, כללי הפלטפורמות ואיך אתם ת�דקו את האפקט.
אחרי השיחה נחזור עם הערכה ותוכנית עבודה: רצף השלבים, מה מתקדם במקביל, באיזה שלב נציג תוצאה ביניים. הרכב הצוות נבנה לפי התרחיש — מהנדס צמתים, מפתח אסטרטגיות, מומחה תשתיות.
מה יידרש מכם כדי שהתחלת הפרויקט לא תיתקע:
- תיאור המטרה בגדלים מדידים: איזו פעילות אנחנו תופסים, באילו פלטפורמות ובאילו זוגות;
- הרשאות גישה לצמתי הרשת או לספק שמוסר את זרם העסקאות, ובנפרד — לקונטור הבדיקות;
- מתקן מבודד עם אמצעי בדיקה: את האסטרטגיה מריצים שם, ולא על זרימה אמיתית;
- רשימת תפקידים וגבולות גישה, כדי שהמפתחות שלכם לא יגיעו למאגר משותף;
- אחראי מצדכם, שמקבל תוצאות ביניים ועונה על שאלות בנוגע לנוהלי הפלטפורמות;
- נכונות לבדוק השערות על נפחים קטנים ולהשוות מדידות לפני ואחרי שינויים.
ברגע שהגישות והקריטריונים יתכנסו, תחילת הפרויקט היא עניין של ימים: את הגרסה העובדת הראשונה נציג בקונטור הבדיקות, עם מדידות ופירוק צווארי בקבוק. תארו את המשימה במייל או בשיחה — נחזור עם הערכה ותוכנית עבודה.