פיתוח DEX עם ספר הזמנות: היכן הארכיטקטורה נשברת
ספר הזמנות על בלוקצ'יין — לא העברה של התאמת בורסה לחוזים חכמים. הזמנות לימיט, עדיפות מחיר וזמן, ביצוע חלקי וביטול צריכים להיות ניתנים לשחזור במקום שבו סדר העסקאות נקבע על ידי הוולידטור, ולא על ידי מנוע הבורסה.
המקור הראשון לכשלים — חוסר סנכרון במצב. בזמן שעסקה תלויה בתור להכללה, המחיר כבר זז, ושתי הזמנות מנוגדות באותו בלוק רואות עץ הזמנות שונה. חוזה שמתאים לפי תמונת מצב מיושנת, סוגר עסקה במחיר שכבר אינו קיים בשוק.
הסוג השני — הזמנות תקועות. אם ביטול לא נכנס לבלוק, הנזילות נשארת פורמלית בספר ההזמנות, למרות שהבעלים כבר לא יכול לנהל אותה. פיתוח DEX כאן דורש מנגנון של הסרה כפויה ומחזור חיים מפורש של הזמנה, אחרת בספר מצטברים נפחים פנטומיים ומתקלקל חישוב עומק השוק.
הבעיה השלישית — עלות ביצוע בלתי צפויה. עמלת הרשת משתנה בין החתימה להכללה, והטייקר מקבל מחיר שונה מזה שראה על המסך. ארכיטקטורת DEX חייבת להגביל החלקה ולדחות ביצוע שחורג מהגבולות שנקבעו, ולא למתוח את העסקה בכל מחיר.
כל שלושת הכשלים — לא באגים במימוש, אלא תוצאה של פשרה בין שקיפות החישובים למהירות התגובה. להלן ננתח כיצד זה נסגר ברמת ארכיטקטורת DEX.
מה נותן ספר הזמנות ברשת: מהירות, נזילות, כשלים
ספר הזמנות ברשת — זה ספר משלו, שבו נפגשות הזמנות לימיט של קונים ומוכרים. התאמת ההזמנות מתבצעת מחוץ לרשת, ותוצאת החישוב נרשמת בה: הרשת שומרת את תוצאת העסקה, ולא כל שינוי בציטוט.
זמן ביצוע העסקה נקבע לא על ידי המתנה לבלוק הבא, אלא על ידי רגע ההתאמה של ההזמנות — הזמנת לימיט מנוגדת נסגרת מיד. כך נעלמת ההשהיה העיקרית: אין צורך להמתין עד שמצב הפול ישתנה כדי שהמחיר יהיה מקובל.
עומק הנזילות מתרכז במקום אחד: ספקי נזילות מחזיקים ציטוטים בספר משותף, ולא בפולים מפוזרים. הספרד מצטמצם, וההחלקה על נפח גדול נראית מראש — לפי הספר, ולא לפי הביצוע בפועל.
עמידות בפני כשלים כאן היא תוצאה של יכולת חיזוי. נעלם סוג שלם של כשלים: אין קפיצת מחיר בין הבדיקה לעסקה, אין מרוץ למצב הפול, וביצוע חלקי מחליף סירוב מלא של ההזמנה. שיעור הפעולות הכושלות יורד: הזמנה או מבוצעת, או נשארת בספר, ותמונת המצב של הספר משוחזרת לאחר כשל בצומת.
את החישוב מוציאים ל-Ethereum, שבו המצב הסופי ניתן לאימות על ידי כל משתתף, ולא רק על ידי מפעיל הבורסה. זה גם שומר על אפקטים מדידים: זמן עד לחישוב, ספרד ושיעור הכשלים נראים ביומנים ובסטטיסטיקת הספר, ולא רק בדיבורים.
פורמטים של בורסה: ספר הזמנות, פול נזילות, היברידי
פורמט המסחר קובע את כל השאר: היכן פיזית נמצאת הנזילות, מי נושא בסיכון אי-ביצוע ואיך מחושבת מחיר העסקה. מבחירה זו תלויים גם החוזים, גם דרישות החישוב, וגם האם בכלל ביצוע הזמנות לימיט יכול להיות צפוי.
שלושת הפורמטים של הבורסה נבדלים לא ב'טוב יותר — גרוע יותר', אלא בסוג השוק שעבורו הם תוכננו. להלן המגבלות של כל אחד, והן מתגלות כבר בעומס, ולא בסביבת בדיקות.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| ספר הזמנות | עסקאות תכופות בזוגות יציבים, נדרש מחיר ביצוע מדויק להזמנת לימיט | את הספר צריך למלא במשהו: בלי תמריץ למרקט-מייקרים ההחלקה גדלה |
| פול נזילות | השקה עם מספר קטן של משתתפים, זנב ארוך של זוגות | המחיר תלוי בגודל הפול, הזמנת לימיט לא מבטיחה ביצוע, יש סיכון להפסדים בלתי קבועים |
| מודל היברידי | נדרש דיוק של הספר, אבל מרקט-מייקרים משלך עדיין מעטים | חוזים מורכבים יותר: שני מקורות מחיר, כללי עדיפות וארביטראז' ביניהם |
בפועל המודל ההיברידי נותן התחלה טובה יותר: פול נזילות מכסה זוגות שמרקט-מייקרים לא נכנסים אליהם, וספר ההזמנות לוקח על עצמו מכשירים גדולים. משלמים על זה בסיבוך החוזים — סדר העדיפות בין מקורות המחיר מתארים לפני תחילת הפיתוח, אחרת חישוב העסקה מתפצל בין המשתתפים.
פיתוח DEX: שלבים מניתוח המשימה ועד מסירת הקוד
הרצף ההנדסי לספר הזמנות שונה מהחלפה פשוטה של טוקנים: חלק מהלוגיקה חי מחוץ לרשת, והחישוב של העסקה צריך לעבור במלואו או לא לעבור כלל. לכן ניתוח תרחישים ובדיקת חוזים — לא פורמליות, אלא מה שמונע מהפרויקט לשכתב את הליבה לאחר ההשקה.
- ניתוח תרחישי מסחר. קובעים את סוגי ההזמנות, כללי ביצוע חלקי, ביטול ועדיפות בתור, התנהגות בעת מחסור בנזילות ופער מחיר בין הספר לרשת.
- תכנון הסכמה. מגדירים מה עובר לרשת ומה נשאר בהתאמת ההזמנות, כיצד נשמר מצב הספר, מי ומה חותם בעת החישוב, כיצד מאורגנים הפקדה ומשיכה של כספים.
- מימוש החוזים. כותבים מודולים לחישוב עסקה, החזקת כספים עד לביצוע, עמלות והרשאות גישה; מפרידים חלקים ניתנים לשדרוג מחלקים בלתי ניתנים לשינוי, כדי שהשדרוג לא יגע ביתרות המשתמשים.
- בדיקת החוזים. בדיקות יחידה ובדיקות מקצה לקצה, מערכות נפרדות לביצוע חלקי, ביטול, קריאה חוזרת וחישוב עמלות; ניתוח הרשאות גישה לפי תפקידים.
- בדיקה ברשת בדיקות. מחזור מלא של הפקדת כספים, מסחר, חישוב ומשיכה. בודקים התנהגות בעת כשלים ובהחזרת כספים מהזמנה שבוטלה.
- ריצות עומס. מעריכים כיצד הספר מחזיק זרם הזמנות, היכן גדלה השהיית התגובה וכמה מצב עובר לרשת ליחידת זמן.
- מסירת קוד. מאגר, סביבות פרוסות, סכמות, תיאור החוזים וסדר שדרוגם, רשימת מגבלות ידועות ותוכנית שיפורים.
תארו אילו תרחישי מסחר דרושים לכם בדיוק — נחזור עם הערכת לוחות זמנים והרכב העבודות לפי שלבים.
חוזים, סכמות זרימה ותקנות שחרור
לאחר סיום הפיתוח של DEX, נשאר לצוות שלכם לא 'קופסה שחורה', אלא ערכת ארטיפקטים שלפיה ניתן לפתח ולתחזק את המערכת בלעדינו. הכל נאסף למאגר שלכם ולמסמכים פנימיים — עם הערות היכן מותר לבצע תיקון באופן עצמאי והיכן נדרשת בדיקה מחייבת.
- קוד מקור של חוזים חכמים עם ניתוח פרמטרים המוגדרים בעת פריסה: עמלות, מגבלות, רשימת זוגות נסחרים — כדי ששינוי תנאים לא ידרוש שכתוב הלוגיקה.
- סכמות זרימה לכל תרחיש: הצבת הזמנה, ביטול, התאמת הזמנות מנוגדות, חישוב ומשיכת כספים — מהחתימה של המשתמש ועד לחישוב הסופי של העסקה.
- מדיניות גישה ומפת תפקידים: מי רשאי לשנות פרמטרים, מי מנהל את הקופה, אילו פעולות מאושרות בכמה חתימות ומה לעשות בעת אובדן מפתח.
- תקנון שדרוג: סדר אישור, מערכת בדיקות לפני שחרור, חלון חזרה לגרסה קודמת ואחראי לכל שלב.
- דוח ביקורת עם רשימת הערות ועדיפויות: חלק נסגר לפני השחרור, חלק נשאר כחוב מבוקר עם לוחות זמנים ברורים.
- הוראות ניטור: אילו אירועי חוזים ומדדי ספר ההזמנות מסמנים בעיה לפני שהמשתמשים מבחינים בה.
- בדיקות ותסריטי פריסה — שחרור חוזר ובדיקת שינויים אורכים דקות, ולא ימים של עבודה ידנית.
מקרה בוחן: ספר הזמנות תחת עומס שיא ומה השתנה
הלקוח — צוות בורסה עם מודל היברידי: התאמה בספר ההזמנות מחוץ לרשת, חישובים בחוזים חכמים ברשת תואמת Ethereum.
בעת רישום זוג פופולרי וברגעים של תנודות חדות בשוק הספר לא עמד בעומס: תור ההתאמה פיגר אחרי זרם ההזמנות, חיוב היתרות לא תאם את מצב הספר, ובשיא עד 14% מההזמנות נדחו בגלל זמן המתנה. פערים אלה תוקנו ידנית על ידי מהנדסי הלקוח — כמה פעמים בשבוע.
מה עשינו
את ההתאמה הוציאו לשירות נפרד עם תור ועיבוד באצוות: הזמנות נאספות לקבוצות, ולרשת עובר חישוב אחד לקבוצה, ולא עסקה נפרדת לכל עסקה.
החוזים נכתבו מחדש למינימום פעולות אחסון: שדות נארזו למשבצות משותפות, היסטוריית העסקאות הוחלפה באירועים, עמלות חושבו מחוץ למחזור ההתאמה, ועיבוד חוזר הוגן במפתח שמסנן כפילויות. מטמון הספר ותמונות מצב תקופתיות הסירו את הצורך בחישוב מחדש מלא של הספר בכל עדכון.
מה קרה
שיעור ההזמנות הנדחות בשיא — מ-14% ל-0.3%, זמן אישור העסקה התקצר מ-6-8 שניות ל-1-2 לפי האחוזון ה-99. התערבויות ידניות בעבודת הבורסה: היו 3-4 בשבוע, ברבעון שלאחר ההשקה — אף לא אחת.
שיא תפוקת המערכת גדל פי שלושה על אותה חוות שרתים, והפער בין היתרות לספר הפסיק לשחזר את עצמו בריצות עומס.
בנוסף הוספנו מצב צל: החוזה החדש מחשב במקביל לפעיל, והפער נראה לפני המיתוג. בנוסף התראות על עומק הספר והתעכבות התור — הצוואר הצר כעת נראה תוך דקות, ולא לאחר תלונות סוחרים.
במה ספר הזמנות שונה מפול נזילות
ספר הזמנות מרכיב מחיר מהזמנות לימיט: מייקרים מציבים הזמנות, טייקרים לוקחים אותן, ומנוע ההתאמה מאחד נפחים מנוגדים לפי עדיפות 'מחיר — זמן'. פול נזילות Uniswap עובד אחרת — המחיר נקבע על ידי נוסחה מיחס הרזרבות, והעסקה מבוצעת כנגד כל הפול, ולא כנגד צד נגדי.
ההחלקה בספר תלויה בעומק הספר במחיר הנבחר: בשוק רגוע הזמנה גדולה עוברת כמעט ללא הפסדים, בזוג דליל היא קורעת כמה רמות. בפול ההחלקה גדלה באופן לא ליניארי עם גודל העסקה ביחס לרזרבות, וספק הנזילות נושא בנוסף בסיכון להפסדים בלתי קבועים כאשר המחיר בורח.
הדרישות לספקי נזילות גם הן שונות. הספר זקוק למרקט-מייקרים מקצועיים, תוכניות תגמול ושליטה בספרד — אחרת הספר מתרוקן והספרד מתרחב. לפול מספיקים ספקים פסיביים: החוזה עצמו תומך בקוטב, אבל הוא עקרונית לא יודע לבצע הזמנות לימיט, סטופ-לוס ועבודה עם מינוף ללא שכבת לוגיקה נפרדת.
מורכבות התחזוקה נעה אחרת. הספר — זה התאמת הזמנות, מנוע סיכונים, ביטולים, ביצועים חלקיים, ביקורת ועמידות בפני כשלים; הפול — סט חוזים קומפקטי וצפוי, שקל יותר לבדוק ולעדכן. לכן בפועל בוחרים לעתים קרובות בהיברידי: הספר נותן דיוק מחיר ושליטה, הפול — השקה מהירה ונזילות מהיום הראשון.
שאלות טכניות: עמלות רשת, השהיות, עדכונים
עמלת הרשת והשהיית האישור קובעות אם המסחר ב-DEX ירגיש כמו בבורסה. בשעות שיא עלות הפעולה עולה פי כמה, והעסקה נתקעת בתור הלא מאושרות, כשהמחיר כבר זז. עבור ספר ההזמנות זה קריטי: המשתמש מקבל החלקה במקום שבו ציפה לביצוע במחיר שלו.
אנו מפרידים בין התאמה לחישוב: השוואת ההזמנות מתבצעת מחוץ לרשת, לבלוקצ'יין עובר רק החישוב הסופי לפי קבוצות עסקאות. פעולה אחת סוגרת עשרות התאמות — העמלה לעסקה יורדת, וביטול הזמנה בכלל לא דורש רישום ברשת. להלן תשובות לשאלות שנשאלות לפני ההתחלה.
כיצד נשלטת עמלת הרשת בשיא?
לפני שליחת החישוב אנו מעריכים את עלות הפעולה הנוכחית ושומרים על גבול עליון: יקר יותר — העסקה לא תעבור. לא עברנו את הגבול — החישוב עובר לקבוצה הבאה, ההזמנה נשארת פעילה.
האם ספר ההזמנות יספיק להגיב ללא השהיות?
ההתאמה מתבצעת בזיכרון, התגובה להזמנה חתומה — שברירי שנייה. ההזמנה מבוצעת במחיר שצוין בה או לא מבוצעת כלל: התאמה חלקית לא מושכת את העסקה לפי השוק, לכן החלקה נוצרת רק במקום שבו המשתמש עצמו הגדיר אותה.
כיצד מתעדכנים החוזים ומה עם האבטחה שלהם?
אנו מפרידים בין הלוגיקה לאחסון: המצב נשאר במקום, רק מודול החישוב משתנה, והעדכון עובר דרך השהיה ואישור במספר מפתחות. לפני העלאה — בדיקות אינווריאנטים, הרצה על עותק רשת עם היסטוריית פעולות אמיתית וביקורת בלתי תלויה. חזרה אחורה — על ידי החלפת המודול בחזרה, ללא מיגרציה של יתרות.
נדון במשימה: ננתח את הסכמה ונחזור עם הערכה ותוכנית
ניתן לדון במשימת פיתוח DEX גם ללא מפרט טכני מוכן — מספיק לתאר מה כבר קיים ולאן אנו שואפים. ככל שהנתונים הראשוניים ספציפיים יותר, כך ניתוח הסכמה מדויק יותר: אנו לא מנחשים את מודל הביצוע והמשמורת, אלא מחשבים לפי התנאים שלכם.
- זוגות וסוגי הזמנות: לימיט, מרקט, סטופ, מכרז סגירה — מכך נגזרת מבנה הספר.
- מודל איחוד ההזמנות: כולו על השרשרת, מחוץ לשרשרת עם שכבת חישוב, או היברידי.
- משמורת: מי מחזיק בכספים, כיצד מאורגנים הפקדות ומשיכות, האם יש צד נגדי לחישוב.
- רשתות ונכסים: היכן פורסים, האם נדרש גשר, האם מתוכנן רישום טוקנים.
- מה כבר נעשה: טיוטות חוזים, מאגר, סכמות נתונים, דוחות בדיקות קוד.
- מגבלות: פרטיות הזמנות, דרישות גישה, אינטגרציות חיצוניות.
בשיחה הראשונה אנו מנתחים את זרימת ההזמנות והחישובים, נקודות מחלוקת ומחלקות סיכון — מניפולציות בספר, עסקאות מקדימות, כשל שכבת החישוב. לאחר מכן אנו חוזרים עם תוכנית עבודה: הרכב המודולים, סדר השלבים, מה נסגר באיטרציה הראשונה, אילו בדיקות נכנסות לאספקה יחד עם הקוד.
הערכת הפרויקט נשענת על היקף החוזים, מורכבות איחוד ההזמנות ודרישות העמידות בפני כשלים — בלי הנחות של 'נברר אחר כך'.
תארו את המשימה בפורמט נוח — נחזור עם הערכה ותוכנית.