פיתוח מערכות מכירות פומביות אצווה (בסגנון CoW)

כל עסקה בבורסה מבוזרת מושכת בוטים של MEV הפוגעים ברווחים באמצעות התקפות front-running ו-sandwich. אנחנו בונים מערכות מכירה פומבית בסגנון CoW Protocol, המבצעות את כל ההזמנות בו-זמנית במחיר אחד, ומבטלות לחלוטין את המניפולציה. הצוות שלנו מספק פרויקטים סוהריים—מחוזים חכמים ועד ארכיטקטורת solver—ומבטיח הגנה אמינה ופעילות יציבה עם תמיכה מתמשכת.

שירותי פיתוח בלוקצ'יין

שאלות נפוצות

העבודות האחרונות

  • פיתוח אתר חברה B2B ADVANCE
    פיתוח אתר חברה B2B ADVANCE
    1481
  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1335
  • פיתוח אתר עבור BELFINGROUP
    פיתוח אתר עבור BELFINGROUP
    1034
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1293
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    738
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1031

תארו לעצמכם: משתמש רוצה להחליף ETH ב-USDC, אבל כל עסקה ב-Uniswap מזיזה את המחיר ומושכת מיד בוטים של MEV. התקפות Front-running ו-Sandwich אוכלות עד 2% מהסכום. מערכת ביצוע בקבוצות (Batch) בסגנון CoW Protocol פותרת זאת באופן דרסטי — כל ההזמנות בפרק זמן קבוע (לדוגמה, 30 שניות) מתבצעות בו-זמנית במחיר סליקה אחיד. אף תוקף לא יכול להשתלב בזרימת העסקאות כי אין עסקאות בזמן אמת. גישה זו מפורטת ב-תיעוד CoW Protocol.

אנו מתמחים בפיתוח מכירות פומביות בקבוצות (Batch Auctions) לפרויקטים של DeFi. השירותים שלנו מכסים את כל המערכת: מחוזה הסליקה ועד לפנקס ההזמנות מחוץ לשרשרת (Off-Chain Orderbook) ופותר תחרותי (Solver). יש לנו ניסיון של למעלה מ-5 שנים ביישום קבוצות מכירה פומבית, ואנו מבטיחים אפס פרצות MEV. חיסכון משוער בגז: ~$200 לקבוצה (50 הזמנות) לעומת גישה נאיבית.

פיתוח מכירות פומביות בקבוצות: למה זה עדיף על AMM

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

מחיר סליקה אחיד

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

איך מערכת קבוצות מגנה מפני MEV?

ההגנה העיקרית היא מחיר הסליקה האחיד: תוקף לא יכול להכניס את העסקה שלו לפני או אחרי הזמנה ספציפית כי כל ההזמנות מתבצעות באותה קבוצה. בנוסף, אנו משתמשים בפנקס הזמנות מחוץ לשרשרת: משתמשים חותמים על הזמנות באמצעות חתימות EIP-712 מבלי לבזבז גז על הגשה. פותרים (אלגוריתמים תחרותיים) מציעים פתרונות, והחוזה מאמת את נכונותם.

עיצוב הפותר (Solver)

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

השוואת ארכיטקטורות פותר
פרמטר פותר על השרשרת פותר מחוץ לשרשרת + סליקה
ביצועים מוגבל בגז (עד 50 הזמנות) 500+ הזמנות בקבוצה
מורכבות אלגוריתמית פשוטה (חיפוש ליניארי) אופטימיזציה מתקדמת (ILP, גרפים)
עלות גז (סליקה) ~200k גז ~120k גז (חשבונאות פלאש)

יישום חוזה הסליקה

חשבונאות פלאש (Flash Accounting)

במקום העברות ERC-20 רציפות (גישה נאיבית), אנו משתמשים בחשבונאות פלאש: החוזה מנהל פנקס פנימי של תנועות נטו של טוקנים. לאחר עיבוד כל ההזמנות, רק העברות שאינן אפס מתבצעות. זה מפחית גז בפקטור של 2–3 — בולט במיוחד בטיפול ב-100+ הזמנות. חיסכון כולל בגז לקבוצה טיפוסית של 50 הזמנות הוא כ-40%.

struct Order {
    address sellToken;
    address buyToken;
    address receiver;
    uint256 sellAmount;
    uint256 buyAmount; // минимальная сумма покупки (лимит)
    uint32 validTo; // deadline
    bytes32 appData; // metadata
    uint256 feeAmount; // газ компенсация solver'у
    bytes32 kind; // SELL или BUY order
    bool partiallyFillable;
    bytes32 sellTokenBalance; // erc20 / internal / external
    bytes32 buyTokenBalance;
}

חתימות באמצעות תקן EIP-712 ו-EIP-1271 עבור ארנקי חוזה. חוזה הסליקה מאמת struct Order { address sellToken; address buyToken; address receiver; uint256 sellAmount; uint256 buyAmount; // минимальная сумма покупки (лимит) uint32 validTo; // deadline bytes32 appData; // metadata uint256 feeAmount; // газ компенсация solver'у bytes32 kind; // SELL или BUY order bool partiallyFillable; bytes32 sellTokenBalance; // erc20 / internal / external bytes32 buyTokenBalance; } בעת ביצוע הקבוצה.

אימות פתרון על השרשרת

החוזה מקבל מערך של ביצועים והעברות מהפותר. בדיקות:

  1. לכל הזמנה: isValidSignature.
  2. חוק שימור: executedSellAmount * buyPrice >= order.buyAmount.
  3. כל חתימות ההזמנות תקפות.
  4. sum(sellAmounts) >= sum(buyAmounts) לא פג.

תהליך פיתוח מכירות פומביות בקבוצות

שלב משך תוצאה
עיצוב 3-5 ימים מבנה הזמנות, ארכיטקטורת פותר, מודל עמלות
חוזה סליקה 2-3 שבועות אימות הזמנות, חשבונאות פלאש, גיבוי Uniswap
רכיבים מחוץ לשרשרת 1-2 שבועות API של פנקס הזמנות, פותר בסיסי, ממסר חתימות
בדיקות שבוע אחד בדיקות Fuzz, אינטגרציה עם Uniswap v3

מה כלול בעבודה (תוצרים)

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

אנו מבטיחים איכות: כל החוזים עוברים אימות פורמלי וביקורת עם Slither ו-Mythril. למהנדסים שלנו יש ניסיון של 5+ שנים בפיתוח DeFi ויישמו 10+ קבוצות מכירה פומבית לשותפים. התמחור מתחיל ב-$15,000 למערכת בסיסית.

לוחות זמנים

גרסה מפושטת עם פותר על השרשרת (עד 50 הזמנות) — 2-3 שבועות. מערכת מלאה עם פותר חיצוני ותחרות — 4-6 שבועות. העלות נקבעת באופן אישי — צרו קשר להערכת פרויקט. הזמינו יישום מכירה פומבית בקבוצות במפתח אחד וקבלו ייעוץ.