פיתוח מערכת קופיטריידינג לבורסת קריפטו כפתרון מלא

מדוע קופיטריידינג נשבר עם גידול במספר המנויים

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

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

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

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

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

מה הפתרון נותן: מהירות עסקאות, עומס וסוג הכשלים

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

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

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

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

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

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

אפשרויות חיבור לבורסה: מתי כל גישה מתאימה

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

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

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

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

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

מה אנחנו מוסרים לידיים: סכמות, גישות ותקנות

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

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

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

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

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

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

מדדים לפני ואחרי

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

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

במה שונה העתקה פרופורציונלית מהעתקת מראה

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

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

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

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

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

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

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

איך מטופל ביצוע חלקי של עסקה?

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

האם ניתן לנהל קופיטריידינג בכמה בורסות בו-זמנית?

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

איך נשמרים מפתחות הגישה לחשבונות?

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

מה יקרה בעת גידול חד במספר המנויים?

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

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

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

שלחו לפי סעיפים את מה שידוע:

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

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