מדוע הציטוטים בבורסות שונות נבדלים וכיצד זה שובר את המסחר
הבדלי ציטוטים אינם נדירות ואינם תקלה של בורסה בודדת, אלא מצב נורמלי של השוק. מאגר בפלטפורמה אחת מעדכן את היתרות לאחר עסקה גדולה, בעוד שאחרת עדיין מחזיקה בערכים הקודמים, והנתב כבר בונה לפיהם מחיר.
אם מערכת השוואת המחירים dex קוראת יתרות באיחור של עשרות שניות, היא מציגה מחיר שכבר אינו קיים בשוק: הארביטרז'ר לוקח את הפער, וההמרה שלכם מבוצעת בשער הגרוע ביותר.
שורש הבעיה טמון באופן שבו בנוי עדכון מצב המאגרים. היתרות משתנות עם כל סוואפ, ובין רגע העסקה לרגע שבו המחיר החדש הגיע לחלון התצוגה שלכם חולף זמן.
ככל שהנזילות במאגרים עמוקה יותר והעסקאות תכופות יותר, כך הנתונים מתיישנים מהר יותר: ציטוט שנלקח לפני דקה כבר אינו רלוונטי עבור זוג פעיל. יתרות מיושנות מסוכנות בכך שהן נראות אמינות — המספרים תקפים, פשוט מהעבר.
השכבה השנייה — החלקה שאינה נראית ברגע הנתון. השער שמציג האגרגטור הוא המחיר לפני העסקה. ברגע שההזמנה נכנסת למאגר, היא עצמה מזיזה את היתרות, והמחיר בפועל מתברר כגרוע יותר.
במאגרים דקים הפער בין התצוגה לביצוע מגיע לכמה אחוזים, ועליו בדיוק מפסידים כסף גם סוחרים וגם שירותים שבונים על נתונים כאלה את הלוגיקה שלהם.
המקור השלישי לשגיאות — הניתוב. כאשר מפצלים הזמנה גדולה בין כמה מאגרים, האגרגטור חייב להתחשב בכך שכל צעד עוקב משנה את היתרות של הקודם. בלי חישוב מחדש של המצב לאחר כל צעד, המחיר המחושב סוטה מהמחיר בפועל, והפער בציטוטים גדל יחד עם גודל ההזמנה.
לסיכום: כל עוד הנתונים על המאגרים מגיעים באיחור, וההחלקה אינה נלקחת בחשבון בחישוב, כל השוואת מחירים נשארת משוערת. מפרקים כיצד זה נסגר — מאינדוקס מצב המאגרים בזמן אמת ועד חישוב מחיר הביצוע עם התאמה לעומק.
מה נותנת אינדקסציה off-chain ו-realtime API
אינדקסציה off-chain מעבירה את עיקר העבודה מהבלוקצ'יין למסד נתונים עצמאי: האינדקסר מאזין לאירועים של פולים, מחשב מחדש רזרבות ומחירים לאחר כל עסקה ושומר את התוצאה באחסון, שממנו ה-API מספק קוטבוציות.
החוזה החכם נשאר מקור האמת, אך בקשת הלקוח כבר לא ממתינה לאישור בלוק — התשובה מגיעה מנתונים מוכנים מראש בתוך עשרות מילישניות במקום שניות.
מהירות התגובה מורכבת משני דברים: מטמון חם לזוגות פופולריים והיעדר קריאות רשת סינכרוניות לכל בקשה. כאשר המשתמש פותח השוואת מחירים, המערכת כבר מחזיקה ערכים עדכניים עבור כל המרקטים הנמעקבים, ולכן הפלט אינו תלוי במידת העומס על הצומת באותו רגע.
כיסוי הפולים גדל לא "בעין", אלא הודות לנרמול: האינדקסר מביא פורמטים שונים של מרקטים למודל אחיד של זוג, טוקן ועמלה, ולכן להשוואה נכנסים גם בורסות גדולות וגם פולים קטנים שבדרך כלל נופלים מהפלט.
עמידות בפני עומס מובטחת בכך שקריאה וכתיבה מופרדות: שיאי בקשות נתקלים במטמון וברפליקות, ולא באינדקסר, ועדכון הקוטבוציות נמשך גם בעלייה מרובה בתעבורה.
האפקט המעשי — השוואת מחירים נשארת נכונה ומהירה ברגעים שבהם השוק נע בעצמה הרבה ביותר, והרחבת רשימת הפולים אינה מחייבת לכתוב מחדש את צד הלקוח. מפרקים כיצד זה בנוי במימוש קונקרטי.
דרכים לקבל שערי חליפין: קריאה ישירה, אינדקסר, היברידי
שלוש גישות נבדלות לא ב"מהירות" במובן הכללי, אלא במקום שבו נוצרת השהיה ובמי משלם על כל בקשה. קריאה ישירה של חוזים מספקת את הנתונים העדכניים ביותר — אתם פונים לבריכה ברגע בקשת המשתמש ומקבלים את המצב בבלוק הנוכחי.
המחיר לכך הוא השהיית רשת בכל קריאה וגידול במספר הפניות לצומת ביחס ישר לתעבורה: במאות השוואות בו-זמניות צומת ציבורי מתחיל להחזיר שגיאות, וצומת פרטי דורש רזרבה ברוחב פס.
אינדקסר מעביר את העומס לצד שלו: משימת רקע מאזינה לאירועי הבריכות, מחשבת מחדש את הרזרבות ושומרת את התוצאה במסד נתונים משלו. בקשת המשתמש מטופלת ממנו בתוך מילישניות בודדות, ועלות הפנייה לרשת אינה תלויה במספר המבקרים.
המגבלה היא השהיית נתונים: בין האירוע בבלוקצ'יין לעדכון הרשומה חולף זמן, ובארגונים מחדש של השרשרת נדרש rollback של מצבים שכבר נרשמו, אחרת בתוצאות יישארו מחירים מהענף שנעלם.
ההיברידי סוגר את שני הקצוות: האינדקסר מחזיק את הזרם העיקרי ומחזיר תשובה מהירה, והקריאה הישירה מופעלת נקודתית — עבור עסקאות גדולות, זוגות נדירים ורגעים שבהם הפער בין המחיר המחושב למחיר בפועל עובר סף. כך ההשהיה נשארת נמוכה בבקשות המוניות, והדיוק — גבוה במקומות שבהם טעות יקרה יותר.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| קריאה ישירה של חוזים | מספר קטן של זוגות, בדיקות חד-פעמיות, נדרש מחיר בבלוק הנוכחי | השהיה בכל קריאה, עלות הבקשות גדלה עם התעבורה, הצומת הופך לצוואר בקבוק |
| אינדקסר | הרבה זוגות ובריכות, זרם השוואות גבוה, נדרשת תגובה מהירה | השהיית נתונים בעת עדכון, rollback בארגונים מחדש, תשתית משלו וניטור |
| היברידי | אגרגטור בייצור עם תעבורה המונית ותרחישים רגישים לדיוק | מורכב יותר לתחזוקה: שני ענפי איסוף, כללי הצלבה וספי פער |
הבחירה נקבעת על ידי פרופיל העומס: כל עוד מדובר בעשרות בקשות בדקה, קריאה ישירה פשוטה יותר וכנה יותר מבחינת עדכניות. ברגע שהשוואת מחירים הופכת לתרחיש המוני, האינדקסר מפסיק להיות אופטימיזציה והופך לתנאי לפעילות תקינה, וההיברידי — לדרך לא לשלם בדיוק עבור מהירות.
איך אנחנו בונים את המערכת: מביקורת מאגרים ועד מסירה
העבודה מתנהלת בשלבים, ובכל שלב הלקוח רואה תוצאה ביניים, ולא "מהדורה גדולה בסוף". הסדר בנוי כך ששגיאות במודל הנתונים ובלוגיקת הניתוב יצופו לפני שהן יהפכו לפערים בשערים בפרודקשן.
- ביקורת מאגרים ומקורות. אוספים רשימה של בורסות ומאגרים שבאמת מספקים נזילות בזוגות הנדרשים: בודקים עומק, עמלות, זמינות ואיכות של ממשקים ציבוריים, יציבות מסירת הנתונים. מסננים החוצה מאגרים ריקים, שבהם יש מחיר אבל אין נפח — אחרת האגרגטור יציג שער יפה אך בלתי ניתן לביצוע.
- תכנון הסכימה. קובעים כיצד מאחסנים מאגרים, טוקנים, זוגות ותמונות מצב של רזרבות, כיצד מקשרים ביניהם וכיצד מחשבים מחיר תוך התחשבות בעמלות ובהחלקה. כאן גם מקבעים את פורמט התגובה של ה-API, כדי שהפרונטאנד והצרכנים החיצוניים יקבלו מבנה אחיד.
- הגדרת האינדוקסציה. מרימים איסוף נתונים מהמקורות: מנויים לאירועים וסקר תקופתי למי שלא מספק זרם. מגדירים חישוב מחדש של נתיבים בעת שינוי רזרבות וכללי הסרת כפילויות, כדי שאותו זוג לא יימשך ממספר מקורות פעמיים.
- בדיקה על נתונים היסטוריים. מריצים את הלוגיקה שנאספה על תקופות קודמות: משווים את המחירים המחושבים למה שהיה בפועל במאגרים, תופסים פערים בתנועות חדות של השוק ובזוגות נדירים. זה מסנן שגיאות שבזרם חי נראות רק ברגע של תנודתיות.
- עומס ועמידות. בודקים כיצד המערכת מתנהגת עם גידול במספר הזוגות והבקשות, מה קורה כאשר מקור בודד אינו זמין וכיצד האינדוקסציה מתאוששת במהירות לאחר תקלה.
- מסירת תיעוד. מוסרים תיאור של סכימת הנתונים, הוראות לחיבור מאגרים חדשים ולהגדרת ספים, וכן הסבר כיצד לקרוא את מדדי האינדוקסציה.
- ליווי לאחר ההשקה. עוזרים עם העדכונים הראשונים: הוספת בורסות, שינוי לוגיקת החישוב, תגובה לשינוי פורמטים אצל המקורות.
סדר כזה נותן תוצאה צפויה: עד لح moment המסירה לצוות הלקוח יש מערכת עובדת להשוואת מחירי DEX והוראה ברורה כיצד לפתח אותה בכוחות עצמו.
מה נשאר אצל המזמין לאחר ההטמעה
לאחר מסירת הפרויקט לא נשאר אצלכם "קופסה שחורה", אלא מערכת עובדת עם סט מלא של תיעוד הנדסי. אינדקסר הקוטיזציות הוא קו ייצור שחי ומשתנה: מתווספים פולים חדשים, בורסות משנות חוזים, העומס על ה-API גדל. לכן אנחנו מוסרים את כל מה שדרוש להפעלה עצמאית ולפיתוח ללא הצוות שלנו.
- קונפיגורציות של האינדקסר — קבצים עם תיאור המקורות, כתובות הפולים, מרווחי הסקר וכללי נרמול המחירים. משנים את רשימת הבורסות או מוסיפים פול חדש על ידי עריכת הקונפיג, ללא בנייה מחדש של הליבה.
- תרשימי זרימות נתונים — מקבלת אירוע מהרשת ועד לכתיבה לאחסון ולמסירה ל-API. ניתן לראות היכן מתבצעת דה-דופליקציה, היכן מחושבת המחיר הממוצע המשוקלל והיכן נקודות הכשל.
- מדיניות גישה — הפרדת הרשאות לקריאה ולכתיבה, מפתחות לצרכנים חיצוניים של ה-API, מגבלות קצב בקשות ברמת הלקוח.
- נהלי עדכון — כיצד להעלות גרסה חדשה של האינדקסר, כיצד לשנות את סכמת האחסון ללא השבתה וכיצד לחזור לגרסה קודמת אם משהו השתבש.
- תיעוד API — תיאור נקודות הקצה, פורמטי התגובה, קודי השגיאה ודוגמאות בקשות. די בכך כדי שמפתחיכם יחברו את האגרגטור למוצר שלהם ללא התכתבות איתנו.
- ניטור והתראות — בדיקות מוגדרות לזמינות המקורות, השהיית האינדוקס ופערי מחירים. אתם יודעים על הבעיה לפני המשתמשים.
- הוראות פריסה — הקמה שלב-אחר-שלב של המערכת מאפס בתשתית שלכם, כולל תלויות ומשתני סביבה.
כל ארטיפקט אנחנו עוברים יחד עם הצוות שלכם במסירה: מראים מה נמצא היכן, כיצד לשנות זאת ומה לבדוק לאחר השינויים. תארו את המשימה — נחזור עם הערכה ותוכנית מסירה.
מקרה בוחן: כיצד אגרגטור שערי חליפין הפסיק לפגר אחרי השוק
הלקוח הגיע עם אגרגטור שערי חליפין עובד: הפרונטאנד הציג מחירים, אך הסוחרים התלוננו שעד לרגע הלחיצה המחיר כבר נעלם.
המדידות אישרו את החשש הגרוע ביותר — הנתונים פיגרו אחרי השוק בממוצע ב-8 שניות, ובגלל סקירה של בריכות "פופולריות" בלבד, כ-30% מהנזילות עברו מתחת לרדאר האינדוקסציה. בשוק תנודתי משמעות הדבר הייתה הפסד שיטתי בביצוע ואובדן אמון בשירות.
מה שינו
פירקנו את מסלול השער מהאירוע ברשת ועד לתגובת ה-API וכתבנו אותו מחדש בשלוש שכבות. האינדקסר נרשם לאירועי הבריכות באמצעות מנויי זרימה במקום סקירה תקופתית — רזרבות חדשות נכנסות לעיבוד ברגע השינוי, ולא לפי לוח זמנים.
מצב הבריכות נשמר בזיכרון עם יומן שינויים: חישוב המחיר מתבצע לפי הרזרבות העדכניות, ולא לפי התמונה האחרונה מהמסד.
הכיסוי הורחב לכל הבריכות ברשתות היעד, כולל אלו עם נזילות נמוכה: חלקם במסלולים הוא בדיוק מה שיצר את ההחלקה שהאינדקס הישן לא ראה. ה-Realtime API מספק שערים דרך חיבור קבוע עם מנוי לזוגות ספציפיים — הלקוח מקבל עדכון מיד, ללא בקשות חוזרות.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| השהיית שער | ~8 שנ' | ~1.2 שנ' |
| כיסוי בריכות | ~70% | מלא |
| עדכון מחיר | לפי לוח זמנים | לפי אירוע ברשת |
ההשהיה קוצצה הודות לוויתור על הסקירה ועל כתיבות מיותרות למסד בנתיב החם. כיסוי מלא הסיר סוג של שגיאות שבהן המסלול נבנה לפי תמונה חלקית של נזילות. בנפרד טיפלנו ביציבות: בעת ניתוק החיבור האינדקסר מדביק אירועים שהוחמצו לפי היומן, כך שהפער מול הרשת אינו מצטבר.
את הפרויקט הובילו המהנדסים שלנו על סטאק Chainlink לזרמי אורקל ושירותי אינדוקסציה משלנו. אם אגרגטור שערי החליפין שלכם נתקע על השהיה או כיסוי חלקי של בריכות — תארו את המשימה, נחזור עם הערכה ותוכנית.
במה שונה אינדוקסציה off-chain משאילתות on-chain?
שאילתת on-chain היא קריאה לחוזה שקוראת את מצב המאגרים ישירות ברגע הפנייה.
עבור מערכת השוואת מחירים ב-DEX משמעות הדבר היא שכל עדכון של ציטוט מחיר עולה בגז, והתוצאה מוגבלת למה שקריאה אחת מספיקה להחזיר: כדי לאסוף מחיר על פני עשרות מאגרים ומסלולים, יש либо לפצל את השאילתות, либо להשלים עם תמונה חלקית. המהירות כאן נעצרת לא בתשתית שלנו, אלא בזמן הבלוק ובמגבלות על נפח החישוב בטרנזקציה אחת.
אינדוקסציה off-chain הופכת את המשוואה: האינדקסר מאזין לאירועים של המאגרים, אוסף רזרבות ועסקאות למסד נתונים משלו ומחשב מחדש את המחירים אצלו. החוזה נשאר מקור האמת, אבל אנחנו קוראים אותו פעם אחת — בזמן האינדוקסציה, ולא בכל בקשת משתמש.
מכאן שתי השלכות: עלות הגז מפסיקה להיות תלויה במספר הפניות ל-API, ומהירות התגובה נקבעת על ידי מסד הנתונים שלנו, ולא על ידי זמן הבלוק.
בעלות הגז ההבדל מהותי. גישת on-chain משלמת על כל בקשה ומתקשה להתרחב: גידול במספר הזוגות והמסלולים מגדיל את ההוצאה באופן ליניארי. off-chain משלמת באופן קבוע על האינדוקסציה — זרם אירועים אחד משרת כל מספר של לקוחות, והמחיר לא עולה יחד עם העומס על ההשוואה.
במהירות, on-chain מוגבל בתדירות הבלוקים ובהשהיית האישור — ציטוט מחיר טרי מגיע באיחור, וחישוב כבד על פני מאגרים רבים פשוט לא נכנס לקריאה אחת.
off-chain מחזיר תוצאה מאינדקס מוכן תוך אלפיות שנייה ומעדכן אותו עם הגעת האירועים, ולכן חלון השוואת המחירים נשאר רלוונטי בתדירות בקשות גבוהה.
גם מורכבות התחזוקה שונה. לוגיקת on-chain חיה בחוזה: אי אפשר לתקן אותה בלי דיפלוי, וטעות בחישוב המסלול עולה ביוקר.
אינדקסר off-chain מתעדכן כמו שירות רגיל, אבל דורש משמעת משלו — טיפול בארגוני מחדש של השרשרת, סנכרון מחדש לאחר תקלה, והצלבת המצב שלו עם החוזה, כדי שהאינדקס לא יתפצל מהמציאות.
ספקות טכניים נפוצים בבחירת קבלן
לפני שדנים בלוחות זמנים ובהיקף העבודה, לקוחות בודקים שלושה דברים: האם המערכת תשרוד כשל של צומת או רשת, האם היא תתמודד עם מאגרים לא סטנדרטיים, ומה באמת קורה בשבועות הראשונים לאחר ההפעלה. להלן — תשובות למה שעולה לרוב בשיחות טכניות.
כיצד המערכת מתנהגת אם צומת או רשת אינם זמינים?
האינדקסר אינו תלוי במקור אחד: זרמי נתונים מגיעים במקביל ממספר צמתים ומספקי גיבוי, ובמצב של ירידה בתפקוד של אחד מהם התעבורה מופצת מחדש ללא עצירת הפלט. מצב המאגרים והשער נשמרים באחסון מקומי, ולכן ה-API ממשיך לספק את הציטוטים המאושרים האחרונים בזמן שהרשת מתאוששת.
לאחר חזרת הקשר האינדקסר מדביק את הבלוקים שהוחמצו ומשווה סכומי ביקורת — לא נותרות אי-התאמות בהיסטוריה.
האם אתם תומכים ברשתות ובמאגרים לא סטנדרטיים?
מאגרי AMM סטנדרטיים מתחברים לפי תבנית מוכנה, ואילו לא סטנדרטיים — מאגרים עם נוסחאות לא ליניאריות, מספר טוקנים בזוג או לוגיקת עמלות משלהם — מנותחים בנפרד ומתוארים כללי חישוב המחיר עבור החוזה הספציפי.
רשימת הרשתות מתרחבת ללא כתיבה מחדש של הליבה: מתווסף מתאם לרשת החדשה, ושאר המערכת אינה נפגעת. אם המאגר משנה את המכניקה, המתאם מתעדכן באופן ממוקד.
כמה זמן לוקח ההטמעה וכיצד בנוי הניטור?
קו העבודה הראשון עם אינדוקסציה ו-API מוקם באיטרציות: תחילה הליבה והרשתות הבסיסיות, לאחר מכן מאגרים לא סטנדרטיים והרחבת הכיסוי. במהלך העבודה אתם רואים תוצאה ביניים, ולא רק את הסופית.
הניטור מכסה את השהיית האינדוקסציה, אי-התאמת ציטוטים בין מקורות וזמינות ה-API — בחריגה מהספים מגיעה התראה, ולא תלונת משתמש. המדדים והלוגים נשארים אצלכם, ולכן מצב המערכת שקוף גם לאחר המסירה.
בואו נדון במשימה שלכם לאיסוף קוטבוציות
כדי שההערכה תהיה עניינית ולא "ממוצע שוק", אנחנו צריכים מכם שלושה דברים: רשימת הבורסות והרשתות שמהן אתם אוספים קוטבוציות, דרישות לגבי תדירות העדכון ועומק ההיסטוריה, וכן העומס הצפוי — כמה לקוחות ובקשות בשנייה המוצר שלכם מחזיק.
עם סט זה אנחנו מבינים איזה היקף של אינדוקסציה off-chain יידרש והיכן צווארי הבקבוק: בסקירת המקורות, בנרמול הזוגות או במסירה דרך realtime API.
מכאן אנחנו עובדים כך: המהנדסים שלנו מנתחים את המקורות מבחינת מגבלות על תדירות הבקשות ויציבות התגובות, משווים את הדרישות שלכם להתנהגות בפועל של הבורסות ורק לאחר מכן קובעים את הארכיטקטורה ותוכנית העבודה.
אם עבור חלק מהזוגות אין objectively מספיק נתונים, נאמר זאת ישירות — במקום הבטחות "נאסוף הכל" תקבלו תמונה כנה של הכיסוי.
מה תקבלו בסיום הדיון:
- ניתוח המקורות שלכם: אילו בורסות ורשתות מספקות קוטבוציות ביציבות, והיכן נדרשות סכמות סקירה עוקפות;
- הערכת הפרויקט בפירוט לפי שלבים — מאיסוף ועד מסירה ב-API;
- תוכנית עבודה עם סדר ההפעלה: תחילה ליבת האינדוקסציה, לאחר מכן שכבת ה-realtime וההיסטוריה;
- סכמת אחסון ונרמול זוגות, כדי שהשוואת מחירים תהיה נכונה בין הפלטפורמות;
- דרישות לתשתית בהתאם לעומס הצפוי שלכם;
- סיכונים לכל מקור ואפשרויות לסגירתם;
- ייעוץ מהנדס שכבר עשה אגרגטורים דומים — לשאלות הספציפיות שלכם.
תארו את המשימה: אילו בורסות ורשתות, איזו תדירות עדכון נדרשת, כיצד המוצר ישתמש בנתונים. נחזור עם הערכת הפרויקט ותוכנית עבודה — עם שלבים, לוחות זמנים ומה יידרש מצדכם.