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

מדוע אינטגרציה דרך Uniswap SDK מאבדת עסקאות בשיא

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

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

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

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

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

מה נותנת אינטגרציה מחודשת: אפקט מדיד

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

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

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

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

כיצד להתחבר ל-Uniswap SDK: אפשרויות ומגבלות

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

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

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

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

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

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

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

מדיניות גישה, מפתחות חותם ומגבלות סיכון

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

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

כל סעיף הוא תצורה או מסמך שנמצאים אצלכם, ולא הסכמה בעל פה עם המפתח.

מקרה בוחן: כיצד גדל שיעור הטרנזקציות המוצלחות

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

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

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

במשך חודש של תצפיות שיעור הטרנזקציות המוצלחות עלה מ-64% ל-98%, והדחיות ירדו משליש ל-2%. זמן החציון עד לאישור הצטמצם מ-45 ל-14 שניות, ושיעור העסקאות שבוצעו במחיר גרוע מהמחושב ירד מ-18% ל-3%.

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

מה לעשות אם הבוט כבר עובד ואי אפשר לעצור אותו?

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

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

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

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

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

שאלות טכניות נפוצות על האינטגרציה

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

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

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

מה עם עמלת הרשת בעומס?

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

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

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

לאינטגרציה של בוט מסחר עם Uniswap דרך SDK נזדקק ל:

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

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