בניית GMX v2: הקמת בורסת חוזים עתידיים תמידיים מבוזרת

פיתוח בורסת חוזים עתידיים תמידיים מבוזרת (Perpetual swap) במודל GMX היא משימה שאנו נתקלים בה באופן קבוע. עם ניסיון של למעלה מעשור בבלוקצ'יין, יותר מ-20 פרויקטי DeFi מצליחים, וחצי עשור בשוק, ראינו הכל. בפרויקט אחד, סוחרים ניצלו עיכוב באורקל לרווח נטול סיכון — נאלצנו לעצב מחדש את מנגנון הביצוע. GMX v2 הוא פרוטוקול עם נפח יומי שיא של למעלה מ-1 מיליארד דולר ו-TVL העולה על 400 מיליון דולר. מדדים מרכזיים: פקודות מתבצעות פי 5 מהר יותר בהשוואה ל-v1, תוך צמצום הזדמנויות ארביטראז' ב-80%. הארכיטקטורה: סוחרים סוחרים עם מינוף מול מאגר נזילות (GM-pools), ספקי נזילות מרוויחים עמלות ונושאים בסיכון כיווני. אורקל: Chainlink Low Latency Feeds המתעדכנים כל כמה שניות, ובוטים של keeper לביצוע פקודות. אם אתה שוקל פיתוח DEX תמידי, מאמר זה מסביר את הארכיטקטורה. להלן מה שקורה מתחת למכסה המנוע.

כיצד מובנה מאגר הנזילות במודל GM?

טוקני GM והרכב המאגר

ב-GMX v2, לכל שוק יש GM-pool משלו: לדוגמה, שוק ETH/USDC מכיל ETH (בטחונות לונג) ו-USDC (בטחונות שורט). טוקן GM מייצג חלק במאגר זה. מחיר טוקן GM = (סך הנכסים במאגר - סך ה-PnL התלוי של סוחרים) / סך היצע GM. כאשר סוחרים רווחיים ביחד, מחיר טוקן GM יורד (המאגר חייב לשלם). כאשר סוחרים מפסידים, GM עולה. LPs וסוחרים נמצאים במשחק סכום אפס.

function getGMTokenPrice(address market) external view returns (uint256) {
    MarketProps memory marketData = getMarketData(market);
    int256 poolValue = getPoolValue(market); // assets по текущим ценам
    int256 pendingPnL = getTotalPendingPnL(market); // нереализованный PnL трейдеров
    uint256 netValue = uint256(poolValue - pendingPnL);
    return netValue * 1e18 / IERC20(market).totalSupply();
}

עמלות השפעה וגורם עומק

אחת המכניקות החכמות ב-GMX v2 היא השפעת המחיר לפתיחת פוזיציות. אם סוחר פותח לונג גדול שיוצר חוסר איזון (לונגים > שורטים), הם משלמים עמלת השפעה נוספת, שיכולה להגיע עד 5% עבור פוזיציות קיצוניות. סוחר שמאזן את חוסר האיזון (פותח שורט במאגר כבד בלונגים) מקבל החזר. זה מחקה עומק ספר פקודות ללא ספר פקודות אמיתי. גורם העומק הוא פרמטר מאגר הנשלט על ידי ממשל שקובע עד כמה ההשפעה גדלה עם גודל הפוזיציה.

ארכיטקטורת חוזים חכמים

מערכת חוזים מודולרית של GMX v2

GMX v2 מחולק למספר שכבות: Router — נקודת כניסה למשתמשים; OrderVault — אחסון זמני של בטחונות; ExchangeRouter — ביצוע פקודות דרך בוטים של keeper; DataStore — אחסון נתונים אחיד באמצעות מפתחות bytes32; EventEmitter — חוזה נפרד רק לאירועים. ארכיטקטורה זו מבטיחה יכולת שדרוג: ניתן להחליף חוזי Handler מבלי לשנות את DataStore. זה קריטי לפרוטוקול שיתפתח לאחר הפריסה.

כיצד פועלת תשתית ה-keeper?

פקודות ב-GMX v2 אינן מבוצעות באופן סינכרוני. משתמש יוצר פקודה (market/limit/stop-loss) → היא נשמרת בחוזה → בוטים של keeper עוקבים אחר פקודות → כאשר התנאים מתקיימים, ה-keeper קורא ל-executeOrder(). למה זה הכרחי: כדי למנוע מהמשתמש לבחור את חותמת הזמן של הביצוע (frontrunning על ידי בחירת רגע הביצוע). ה-keeper מקבל את מחיר Chainlink Low Latency הנוכחי בזמן הביצוע — זה הוגן יותר לשני הצדדים. ה-keeper מקבל עמלת ביצוע (בתשלום מראש על ידי המשתמש) עבור כל ביצוע מוצלח, בדרך כלל $0.50–$2.00 לפקודה. אם הביצוע נכשל, העמלה מוחזרת למשתמש.

// Keeper логика (упрощённо)
async function processOrders() {
    const pendingOrders = await exchangeRouter.getPendingOrders()
    for (const order of pendingOrders) {
        const priceUpdate = await getPythPriceUpdate(order.indexToken)
        try {
            await exchangeRouter.executeOrder(order.key, {
                priceFeedTokens: [order.indexToken],
                priceFeedData: [priceUpdate],
            })
        } catch (err) {
            if (err.message.includes('PRICE_NOT_MET')) continue // limit не достигнут
            logError(order.key, err)
        }
    }
}

עמלות מימון ועמלות הלוואה

ל-GMX v2 יש שני סוגים של עמלות רציפות למחזיקי פוזיציות: עמלת הלוואה — עמלה עבור שימוש בנזילות המאגר. מחושבת כ-(openInterest / poolLiquidity) * borrowingFactor * time. בניצול גבוה, היא יכולה להגיע ל-0.1% לשעה. עמלת מימון — מנגנון איזון בין לונג לשורט. הצד עם open interest גדול יותר משלם לצד השני. היא מצטברת דרך מדד מצטבר דומה למדד הריבית של Aave. כאשר פוזיציה נסגרת חלקית, יש לחשב עמלות מצטברות בצורה נכונה. שגיאה כאן מובילה להפסד או רווח ישיר לסוחרים על חשבון המאגר.

למה להשתמש ב-Chainlink Low Latency ו-Pyth?

GMX v1 השתמש ב-Chainlink Feeds סטנדרטיים (עדכון כל כמה דקות או בסטייה של >0.5%). זה יצר ארביטראז': המחיר ב-CEX זז, Chainlink עוד לא עודכן — פתח פוזיציה במחיר הישן, סגור אותה בחדש. GMX v2 עבר ל-Chainlink Low Latency Feeds — עדכונים כל כמה שניות דרך אישור מחיר חתום off-chain. ה-keeper כולל את המחיר החתום ישירות בעסקת הביצוע. Pyth Network היא מערכת אורקל push חלופית במהירות דומה. שילוב שתיהן כעיקרית/גיבוי הוא הסטנדרט לפרוטוקולים בייצור.

פרמטרי מאגר וממשל

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

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

השוואת גרסאות: GMX v2 מול v1 — מהירות אורקל

GMX v2 מעבד פקודות פי 5 מהר יותר בזכות Low Latency Feeds.

תוצרים: מה כלול בפיתוח DEX תמידי?

פיתוח DEX תמידי turnkey שלנו כולל:

• מפרט מתמטי (1–2 שבועות). כל הנוסחאות: שיעור הלוואה, שיעור מימון, השפעת מחיר, תמחור טוקן GM, מחיר חיסול — מאומתות פורמלית לפני שורת קוד אחת.
• חוזי ליבה (6–10 שבועות). DataStore, EventEmitter, OrderVault, ExchangeRouter, חשבונאות פוזיציות. בדיקות Foundry עם כיסוי של 90%+, בדיקות אינווריאנטים של Echidna.
• תשתית Keeper (2–3 שבועות). בוטים ב-TypeScript, ניטור, גיבוי במקרה של השבתת RPC.
• אינטגרציית Frontend (2–4 שבועות). hooks של wagmi/viem לנתוני מאגר, בניית פקודות, subgraph של The Graph להיסטוריה.
• ביקורת (4–6 שבועות). DEX תמידי הוא פרוטוקול מורכב. הביקורת חייבת לכסות גם חוזים חכמים וגם מכניקות כלכליות (סימולציית ניצול כלכלי).
• תיעוד והכשרת צוות (1–2 שבועות). תיעוד טכני מפורט, מדריכי API, גישה לקוד מקור, והדרכות למפתחים שלך.
• תמיכה לאחר פריסה (3 חודשים). ניטור, התראות ותיקונים חמים.

תהליך הפיתוח

1. אנליטיקה ומפרט: פורמליזציה של המתמטיקה, בחירת מחסנית טכנולוגית, עיצוב ארכיטקטורה.
2. פיתוח חוזים חכמים: כתיבת קוד באמצעות Foundry, כתיבת בדיקות אינווריאנטים.
3. אינטגרציית אורקל ותשתית keeper: הגדרת Chainlink Low Latency, Pyth, פיתוח בוטים.
4. אינטגרציית Frontend: חיבור דרך wagmi, יצירת ממשק למסחר וניהול מאגר.
5. בדיקות וביקורת: QA פנימי, ביקורת חיצונית של חוזים חכמים ומודלים כלכליים.
6. פריסה וניטור: פריסה על mainnet, הגדרת ניטור והתראות.

לוח זמנים והערכות עלות

MVP של DEX תמידי עם שוק אחד (ETH) ותשתית keeper — 2–3 חודשים, בדרך כלל $50,000–$100,000. פלטפורמה מלאה עם מספר שווקים, ממשל, טוקנומיקת GM ו-frontend — מ-5–6 חודשים, בדרך כלל $150,000–$300,000. חיסכון של עד 30% בהשוואה לבנייה מאפס בזכות רכיבים לשימוש חוזר. העלות מחושבת לאחר מפרט טכני. צור קשר להערכה מקדימה. הזמן פיתוח DEX תמידי turnkey — קבל ייעוץ. אנו מבטיחים תמחור שקוף ולוחות זמנים קבועים. 10+ שנים בבלוקצ'יין, 20+ פרויקטי DeFi מצליחים, 5+ שנים בשוק — הפרויקט שלך בידיים טובות.