פיתוח בורסה מבוזרת (DEX) מקצה לקצה

פיתוח DEX: היכן נשבר אב-הטיפוס של הבורסה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מצבי מסחר: מאגר נזילות מול ספר הזמנות

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

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

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

תהליך פיתוח DEX: מהסכמה ועד ההשקה

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

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

תוצרי הפרויקט: קונפיגורציות, סכמות, תקנונים

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

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

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

מקרה בוחן: כיצד הסרנו החלקה בשוק דק

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

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

מה שינו

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

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

מה התוצאה

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

מה לעשות אם הבורסה כבר הושקה על סטאק אחר?

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

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

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

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

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

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

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

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

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

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

מה קורה בעת דליפת מפתח או אירוע?

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

נדון במשימה: מה לשלוח להערכה

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

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

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