למה אינטגרציה של 1inch API נשברת תחת עומס
סוואפ דרך 1inch API הוא לא בקשה אחת, אלא שרשרת: לקבל הצעת מחיר, להרכיב מסלול, לחתום על טרנזקציה, לשלוח אותה לרשת. השבר קורה בכל שלב, ולרוב בשלישי.
בין תשובת האגרגטור לחתימה חולפות שניות, שבהן המאגרים כבר השתנו: אם סובלנות להחלקה לא מוגדרת או מוטמעת בקוד קשיח, החוזה ידחה את העסקה בגלל הסכום המינימלי שיתקבל. המשתמש משלם על gas ורואה דחייה.
הנקודה השנייה — המסלול עצמו. בשעות שיא הנזילות מפוזרת על פני עשרות מאגרים, וחלק מהנתיבים פשוט לא נבנים: האגרגטור עונה שאין מסלול, או מחזיר אפשרות עם מחיר שאי אפשר להציג למשתמש.
העומס על ההחלפה מוסיף timeouts ומגבלות על קצב הבקשות — הממשק מציג שגיאה של האגרגטור, אף שיש נזילות בשוק.
הנקודה השלישית — הצעת מחיר מיושנת. אם האפליקציה לא מבקשת מחדש את המחיר לפני החתימה ולא משווה אותו למצב בפועל של המאגרים, הטרנזקציה יוצאת עם נתונים בני עשר שניות.
כאן מתרכז עיקר השבירות של סוואפים: בשעות שקטות הכול עובר חלק, ובשיא שיעור הדחיות גדל פי כמה — ההפסדים נופלים בדיוק בתקופה שבה המחזור מקסימלי.
נפרט איך זה נסגר — מבקשה חוזרת להצעת מחיר ועד מסלול גיבוי למקרה של כשל במסלול הראשי.
מה נותנת אגרגציית נזילות: אפקט במדדים
מאגר אחד הוא שער אחד ותקרת נפח אחת: הזמנה גדולה מזיזה את המחיר בתוכו ומפסידה בהחלקה. אגרגציית נזילות מפצלת את ההזמנה לחלקים ומפזרת אותם בין כמה מקורות, תוך איסוף שאריות מנוגדות בדרך.
1inch מחזיר מסלול מוכן יחד עם התוצאה הצפויה — יתרון בשער מופיע בלי סריקה ידנית של פלטפורמות ולוגיקת השוואה עצמאית של הצעות מחיר.
אפקט ההטמעה נראה במדדי ההחלפה. שיעור סוואפים מוצלחים — כמה הזמנות הגיעו לביצוע ולא נפלו בחישוב. סטיית השער בפועל מזה שהוצג למשתמש — הפסדים בין אישור העסקה לכניסה לבלוק. שיעור המקרים שבהם, כאשר הנזילות עזבה את המאגר הראשי, המסלול נבנה מחדש למסלול גיבוי.
עמידות בשעות שיא — מדד נפרד. בתנועה חדה של השוק מאגר בודד נכנס לחוסר איזון, וחלק מהעסקאות נופלות בגלל החלקה. זה סוג של כשלים שנסגר כמעט לחלוטין: פיצול ההזמנה לצעדים קצרים, חישוב מחדש של המסלול לפני השליחה ונתיב גיבוי מפחיתים את התלות בירידה של מקור אחד.
בפועל גדל שיעור ההזמנות המבוצעות, יורד מספר החזרות והבירורים הידניים, והשער עבור המשתמש מתנהג בצורה צפויה גם בחלון שקט וגם בחלון תנודתי. את המדדים אנחנו מודדים לפני ואחרי — ומאמתים את האפקט בנתונים, לא בהבטחה.
מצבי עבודה של 1inch API: קריאה, מתווך, אצוות
מצב הקריאה קובע היכן נשמרים הסודות, מי אחראי על המגבלות וכמה טרייה הצעת המחיר שמגיעה למשתמש. קריאה ישירה ל-1inch API מאפליקציה מבוזרת נותנת השהיה מינימלית, אבל המפתח עובר ל-bundle בצד הלקוח, וקצב הבקשות נספר לפי כתובת חיצונית — בזמן זינוק בתעבורה חלק מהפניות נופלות. בפועל בוחרים באחת מארבע אפשרויות.
| מצב | מתי מתאים | מגבלות המצב |
|---|---|---|
| קריאה ישירה לאגרגטור | אב-טיפוס, תרחיש החלפה אחד, השהיה מינימלית | הסוד זמין בצד הלקוח, אין מכסה משותפת, קשה לתעד ולדבג |
| דרך מתווך משלנו | עומס ייצור, כמה ממשקים, נדרשים ביקורת ומגבלה משותפת | ועוד חוליית השהיה אחת, נדרשת שכבה משלנו לחזרות ולבקרת כשלים |
| בקשות אצווה | תיק, מסך עם כמה זוגות, השוואת מסלולים | כשל חלקי וגדלים שונים של תשובות — נדרש פירוק שגיאות מפורש לכל רכיב |
| מטמון הצעות מחיר | עדכון תכוף של הממשק בלי עומס על האגרגטור | מחיר מיושן מוביל להחלקה, חובה חישוב מחדש לפני החתימה |
מטמון הוא לא מצב נפרד, אלא תוספת מעל כל אחד מהם: את התשובה מחזיקים שניות ומעדכנים לפני חתימת הטרנזקציה, אחרת המשתמש מאשר מסלול לפי מחיר ישן. עבור אצוות מגדירים מראש התנהגות בזמן כשל חלקי: מסלול לא זמין לא צריך להפיל את כל המסך.
בחירת המצב היא פשרה בין השהיה, שליטה בסודות ועמידות לכשלים. בהמשך נסביר איך מצבים אלה משתלבים באפליקציה אחת בלי כפילות לוגיקה.
סדר ההטמעה: מביקורת ועד מסירת נהלים
סדר ההטמעה בנוי כך שההחלפה תעבוד על זוגות אמיתיים לפני שהעסקה הראשונה עם כספים אמיתיים תיכנס לקוד. כל שלב מסתיים בארטיפקט שאפשר לבדוק — תרשים, קונפיגורציה, דוח עומס — ולא ב״מוכן״ בעל פה.
- ביקורת אינטגרציה. מפרקים היכן כיום מבוצעת ההחלפה, אילו זוגות ונפחים עוברים, מי מנהל מפתחות ומגבלות, איך מטופלים כשלים. בפלט — מפת הזרימות הנוכחיות ורשימת מקומות שבהם 1inch מחליף לוגיקה קיימת או מתייצב לצידה.
- תרשים זרימות. מתעדים את מסלול הבקשה: קבלת הצעת מחיר, בדיקת סובלנות להחלקה, זמן החיים שלה, חתימה ושליחה לרשת. בנפרד מסמנים נקודות כשל — חריגה מזמן התשובה של האגרגטור, עסקה שנדחתה, פער שער בין החישוב לביצוע.
- הגדרה. מחברים את שיטות האגרגטור, סוגרים טיפול בשגיאות, חזרות והגנה מפני כפילות פעולות. סובלנויות ופרמטרי הצעות מחיר מוציאים לקונפיגורציה, לא לקוד, כדי לשנות אותם בלי להוציא build חדש.
- בדיקת עומס. מריצים בקשות מקבילות להצעות מחיר ולעסקאות, בודקים התנהגות בזמן אי-זמינות של האגרגטור ודעיכה בשיא. המטרה — זמן תשובה צפוי ותור כשלים מובן, לא שיא בדוח.
- קבלת ההחלפה. משווים מסלולים וסכומים בפועל בפלט, מבצעים עסקאות קטנות ברשת הראשית, בודקים החזר כספים בזמן תקלה בכל שלב.
- מסירת נהלים. מוסרים תרשימים, קונפיגורציות, מדדים והוראות rollback: משמרת תורנית צריכה להבין מה לעשות כשעסקאות נדחות ואיך לחזור למסלול ההחלפה הקודם.
מה נשאר אצלכם: קונפיגורציות, תרשימים, נהלים
אינטגרציה עם 1inch היא לא רק קוד ניתוב: התמיכה חיה בהגדרות, מכסות ונהלים. לכן אנחנו מוסרים ערכה שלפיה הצוות שלכם יוכל לפתח את ההחלפה ולהגיב לתקלות בכוחות עצמו, בלי לפנות אלינו.
- קונפיגורציות החלפה. פרמטרים שהוצאו מהקוד: רשימת רשתות וטוקנים, ספי החלקה, עדיפות מסלולים, כתובות מקבלי עמלה. משתנים בלי build מחדש של האפליקציה.
- תרשימי אינטראקציה. דיאגרמה של נתיב הבקשה מהממשק לאגרגטור ובחזרה: מי חותם על העסקה, היכן מחושבת מחיר סופי, באילו נקודות כשל נראה ראשון.
- מגבלות בקשות. טבלת מכסות לכל מקור חיצוני עם מרווח לעומס שיא, כללי ניסיונות חוזרים ותיאור התנהגות כשהמכסה נגמרת.
- נהלי תפעול. מה לבדוק בהוספת רשת או טוקן חדשים, איך לעדכן ספרי עזר, צ'ק-ליסט לשחרור שינויים וסדר אישור תיקונים.
- התראות כשל. ספים ונמענים: עלייה בשיעור מסלולים כושלים, פער בהצעות מחיר, השהיית תשובה מעל המותר, עצירת משימות רקע.
- תוכנית התאוששות. סדר פעולות בזמן דעיכת נתב: מעבר למקור גיבוי, מצב אישור עסקאות ידני, קריטריונים לחזרה לשגרה.
- הרשאות ותיעוד. תפקידים בפאנלים, מפתחות עם הרשאות מוגבלות, סדר רוטציה שלהם והוראות קצרות למהנדס תורן.
מקרה בוחן: איך סוואפים הפסיקו להישבר בשעות שיא
מה היה לפני האינטגרציה
מקרה האינטגרציה הזה התחיל בשירות להחלפת טוקנים, שבו המשתמש מחליף נכס בקליק אחד. המסלול נבנה דרך מאגר נזילות אחד, ובשעות שיא זה לא הספיק: כשהפעילות ברשת גברה, המחיר זז בין הצגת הצעת המחיר לאישור העסקה.
התוצאה — שיעור הסוואפים המוצלחים ירד ל-76–78%, וזמן התגובה להצעת מחיר התארך עד 10–12 שניות; חלק מהמשתמשים עזבו בלי לחכות להחלפה.
מה שינו ואיך זה עובד
חיברנו את האגרגטור 1inch: הוא מפצל את ההחלפה בין כמה מאגרים ובוחר נתיב עם השער הסופי הטוב ביותר, ולא מקבע מקור אחד. את הצעת המחיר מחשבים מחדש עם זמן חיים קצר ומעדכנים לפני שליחת העסקה — מגבלת ההחלקה מחושבת מהמחיר העדכני, לא מזה שהמשתמש ראה. למקרה שמקור מסוים לא זמין השארנו מסלול גיבוי: ההחלפה לא נעצרת אם מאגר לא עונה או עונה לאט.
תוצאות ההטמעה
שיעור הסוואפים המוצלחים בפרקי שיא עלה ל-97–98%, זמן התגובה של ההחלפה התקצר ל-2–3 שניות והפסיק לגדול תחת עומס. דחיות בגלל החלקה יצאו מרשימת הסיבות המובילות לעסקאות כושלות — את מקומן תפסו שגיאות משתמש: חוסר כספים וחתימה שנדחתה.
הרצות עומס בשעות שיא הראו אותה תמונה כמו בחלונות שקטים — התנהגות השירות הפסיקה להיות תלויה בשעה ביום.
מה לעשות אם האגרגטור כבר מוטמע, אבל הצעות המחיר לא תואמות
הפער כמעט תמיד נולד לא בתוך האגרגטור, אלא בנקודה שבה אתם משווים מספרים. הצעת המחיר מחושבת למצב אחד של המאגרים, והחתימה יוצאת בבלוק הבא, והמסלול בין הרגעים האלה נבנה מחדש.
בנוסף, הצעת המחיר בדרך כלל לא כוללת את העמלה של האגרגטור עצמו ואת עלות הביצוע, לכן בהשוואה של "מחשבון מול יתרת הארנק" יהיה פער תמיד, אפילו באינטגרציה תקינה.
אבחון מסלולים מתחיל בפירוק של איך הנפח התחלק. בודקים דרך אילו מקורות נזילות עבר הפיצול, איזה חלק עבר לכל מאגר והאם הפיצול השתנה בין שתי בקשות זהות ברצף.
אם המסלול שונה בכל פעם על אותו נפח בדיוק, אתם קולטים רעש נזילות ומתעדים לא תקלה אלא בנייה מחדש תקינה — אז צריך לתקן את לוגיקת ההשוואה, לא את הקריאה עצמה.
בדיקת כדאיות העסקה מצטמצמת לשלושה מספרים: הנפח המינימלי שיתקבל, ההשפעה על המחיר והסובלנות להחלקה שהוגדרה. סיבה נפוצה לפער מדומה — השוואת נפחים בטוקנים עם דיוק שונה או בלי התחשבות ב-wrapped ether: החלפה דרך הטוקן המקורי ודרך העטיפה שלו נותנות תוצאות שונות בפלט באותו מסלול.
החתימה לא תואמת לחישוב כשפג תוקף הטרנזקציה, נעשה שימוש חוזר ב-nonce של הרשאת חיוב, מזהה הרשת שונה או שהנמען הוא כתובת אחרת. מקור נוסף — הצעת המחיר התבקשה מענף אחד של הראוטר, וההחלפה נבנית עבור אחר: הפרמטרים דומים, אבל החוזה מבצע אחרת. זה מטופל בהשוואת שתי התשובות לפני החתימה, ולא בניסיונות חוזרים בעיוורון.
בנייה מחדש ממוקדת של הלוגיקה נראית כך: הצעת המחיר מתבקשת ממש לפני החתימה, החלון ביניהן מוגבל, הנפח המינימלי נבדק שוב כבר אחרי קבלת גוף הטרנזקציה, והתוצאה בפועל נכתבת לניטור יחד עם זו המחושבת. אז הפער מפסיק להיות חידה ומגיע כאירוע עם סיבה ידועה.
שאלות טכניות נפוצות על אינטגרציית החלפה
במעבר ל-1inch API לקוחות בודקים בערך את אותם דברים: האם שכבה חדשה תשבור חוזים שכבר עובדים, מה קורה בהחלפה כושלת ואיך בנויות ההרשאות. להלן תשובות למה שהכי часто עולה בשלב ההערכה.
האם אפשר להחליף קריאה ישירה לחוזה ההחלפה באגרגטור?
כן, ובדרך כלל מתחילים מזה. קריאה ישירה נותנת מחיר טוב יותר בתוך מאגר אחד, והאגרגטור מפצל את הסכום לכמה מסלולים ומרכיב תוצאה מכל מקורות הנזילות. אין צורך לכתוב מחדש את לוגיקת השירות — משתנה רק שכבת הכנת הטרנזקציה.
מה קורה אם ההחלפה לא עברה?
הטרנזקציה נדחית לפני חיוב הכספים: המחיר עבר את גבול ההחלקה או שפג תוקף המסלול. בתשובה מגיע קוד סיבה שלפיו אפשר להבדיל בין המקרים. ניסיון חוזר נבנה על חישוב טרי, לא על זה השמור.
איך מונפקים הרשאות ומפתחות?
המפתח מונפק לשירות מסוים עם הגבלה לפי מקור הבקשות ומגבלה יומית של פניות, וניתן לבטלו בלי לעצור את האפליקציה. מפתחות פרטיים של הארנק לא נכנסים למעגל הזה — החתימה נשארת בצד שלכם.
איך לבדוק שהמסלול נבנה נכון?
לפני החתימה מתבקש חישוב: הנפח הצפוי בפלט, רשימת המקורות והסכום המינימלי עם התחשבות בהחלקה. הערכים מושווים לגבול שלכם, ורק אחר כך הטרנזקציה יוצאת לרשת. החישוב והביצוע בפועל נרשמים בלוג — הפער נראה מיד.
האם האינטגרציה תשפיע על חוזים קיימים?
לא, אם ההחלפה מופרדת לשכבה נפרדת: חוזים ישנים ממשיכים לעבוד דרך אותם ממשקים. המעבר נעשה בהדרגה — קודם על חלק מהנפח, עם rollback לקריאה ישירה באמצעות הגדרה אחת.
נדבר על המשימה שלכם: נחזור עם הערכה ותוכנית
כדי שהערכת האינטגרציה תהיה עניינית ולא "לפי תחושה", בהתחלה מספיקים שלושה דברים: איזו רשת ואילו זוגות טוקנים המוצר שלכם משרת, איך כיום חותמים ושולחים טרנזקציה ואילו מגבלות הרשאה יש לצומת. אם חלק כבר מיושם — שלחו את קוד ההחלפה הנוכחי עם האגרגטור: ננתח ונציע מה להשתמש מחדש ומה לשכתב.
בתשובה נחזיר הערכת היקף עבודה, תרשים פתרון עם נקודות כשל מפורשות ותוכנית שלבים עם לוחות זמנים להטמעה. בנפרד נפרט את כל מה שיעבור אליכם במסירת התיעוד — כדי שאפשר יהיה לנהל תמיכה בצוות שלכם, בלי מעורבותנו.
- פירוק תרחיש ההחלפה שלכם: מסלולים, החלקה, פלט מינימלי מקובל לעסקה.
- תרשים פתרון: היכן נמצא האגרגטור, איך מטופלים כשלים וניסיונות חוזרים.
- הערכת אינטגרציה לפי שלבים — בהיקף עבודה, לא במספר ממוצע אחד.
- תוכנית עבודה עם לוחות זמנים להטמעה ונקודת ביקורת שבה רואים תוצאה.
- רשימת הרשאות ומפתחות שנדרשים מכם, עם דרישות לאחסון ורוטציה שלהם.
- ערכת תיעוד: קונפיגורציות, תיאור שיטות, סדר פעולות למשמרת תורנית.
כדי לדון במשימה, מספיק מכתב עם תיאור התרחיש והמצב הנוכחי. נחזור עם הערכה ותוכנית — ואם האינטגרציה כבר עובדת, נתחיל מהביקורת שלה: לעיתים קרובות מהר יותר לשפר את ההחלפה מאשר להרכיב אותה מחדש.