פיתוח סימולטור מסחר דמה בקריפטו

פיתוח מסחר נייר: היכן נשברת הבדיקה

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

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

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

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

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

מה נותן סימולטור סוחר: אפקט במספרים

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

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

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

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

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

מצבי ביצוע עסקאות ודרכי התחברות

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

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

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

איך אנחנו בונים סימולטור: שלבי עבודת הנדסה

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

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

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

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

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

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

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

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

מקרה בוחן: סימולטור מסחר בעומס לפני ואחרי

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

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

מה נבנה מחדש

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

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

• זמן תגובה בשיא: היה — התור גדל, התגובה התארכה לשניות; стало — זמן צפוי באותו פרופיל עומס.
• שיעור אי-ההתאמות בחישובי עסקאות: מ-3–4% לעשיריות האחוז.
• בדיקות ידניות של אסטרטגיות: מעשרות ניתוחים בשבוע לאחדים, וגם הם — לפי תרחישים מסומנים מראש.
• שחזור לאחר כשל: במקום הרצה חוזרת של הסשן — המשך מהפעולה הרשומה האחרונה.

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

במה סימולטור שונה מחשבון דמו של ברוקר?

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

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

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

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

ספקות טכניים: שאלות נפוצות על הסימולטור

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

איך הסימולטור מתחבר למערכת החשבונאית?

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

האם מעגל הבדיקה בטוח לעבודה עם נתונים אמיתיים?

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

אפשר לתמוך בכמה תרחישים ולעשות שימוש חוזר בפיתוחים?

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

נדון במשימה: מה צריך כדי להתחיל פיתוח

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

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

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