פיתוח מערכות Intent Solver ל-DeFi

משתמשים מפסידים עד 3% בהחלקת מחיר (בהזמנות גדולות, מדובר באלפי דולרים) עקב עיכובים בין החתימה לביצוע. מערכות Intent Solver פותרות בעיה זו. מקרה אחרון: לקוח עם הזמנה גדולה חווה החלקת מחיר משמעותית. לאחר יישום ניתוב מפוצל על פני מספר מאגרי נזילות, ההפסדים ירדו באופן דרמטי. אנו מתכננים ובונים מערכות Solver מלאות לפרוטוקולי DeFi. המהנדסים שלנו הם מפתחי Solidity מנוסים עם 5+ שנים בבלוקצ'יין ו-15+ פרויקטים בתיק העבודות שלהם.

הבעיה: ביצוע DeFi מסורתי

המודל המסורתי של DeFi: המשתמש מציין מסלול ביצוע מדויק—איזה DEX, איזה מאגר, איזו החלקת מחיר. אם המחיר זז בזמן שהעסקה נמצאת ב-mempool, היא נדחית והגז מתבזבז. ארכיטקטורה מבוססת Intent הופכת את זה: המשתמש אומר "אני רוצה לפחות X טוקנים מסוג B תמורת Y טוקנים מסוג A," חותם על ה-intent, ורשת של Solvers מתחרה כדי לבצע אותו בצורה אופטימלית.

CoW Protocol, UniswapX, ו-1inch Fusion הם יישומים בוגרים של ביצוע מבוסס Intent. אבל הלוגיקה של ה-Solver מאחוריהם היא תשתית תחרותית שניתן לבנות עבור הפרוטוקולים שלכם. אנו מבטיחים ביקורות חוזה והגנת MEV ברמת הארכיטקטורה.

איך מערכות Intent/Solver עובדות

מחזור החיים של Intent

1. המשתמש יוצר מבנה UserIntent עם פרמטרי ביצוע.
2. חותם על חתימה טיפוסית EIP-712 (מחוץ לרשת, ללא גז).
3. ה-intent מתפרסם לרשת p2p או לשרת מכירות פומביות מרכזי.
4. Solvers מתחרים במשך 30-60 שניות: כל אחד מחשב מסלול ומגיש הצעת מחיר.
5. חוזה הסילוק מאמת את החתימה, משווה הצעות מחיר, ומבצע את הטובה ביותר.
6. ה-Solver מקבל חלק מהעודף (ההפרש בין המחיר הטוב ביותר למחיר המוצג).

struct UserIntent {
    address sellToken;
    address buyToken;
    uint256 sellAmount;
    uint256 minBuyAmount; // Minimum acceptable, solver должен дать >= этого
    uint256 deadline;
    address recipient;
    bytes32 nonce; // Защита от replay
}

struct SolverBid {
    bytes32 intentHash;
    uint256 buyAmount; // Сколько buyToken solver даёт
    bytes executionData; // Encoded calldata для исполнения
    address solver;
    bytes signature;
}

מפרט: EIP-712

איך חוזה הסילוק עובד

חוזה הסילוק הוא קריטי. עליו:

1. לאמת את החתימה EIP-712 של המשתמש
2. לבחור את הצעת המחיר הטובה ביותר (מקסימום struct UserIntent { address sellToken; address buyToken; uint256 sellAmount; uint256 minBuyAmount; // Minimum acceptable, solver должен дать >= этого uint256 deadline; address recipient; bytes32 nonce; // Защита от replay } struct SolverBid { bytes32 intentHash; uint256 buyAmount; // Сколько buyToken solver даёт bytes executionData; // Encoded calldata для исполнения address solver; bytes signature; } )
3. לבצע את buyAmount של ה-Solver
4. לבדוק לאחר הביצוע: המשתמש קיבל executionData
5. אם לא, לדחות את כל העסקה

תבנית ביצוע: ה-Solver קורא ל->= minBuyAmount עם העברה מאושרת מראש. חוזה הסילוק:

• לוקח settle() מהמשתמש (באמצעות אישור מראש או permit)
• מבצע את ה-calldata השרירותי של ה-Solver (המרה ב-DEX, שרשרת המרות)
• בודק שיתרת sellToken של המשתמש גדלה ב-buyToken

Calldata שרירותי מה-Solver הוא וקטור התקפה. אנו מיישמים רשימה לבנה של חוזים מורשים או אימות קפדני: calldata יכול לקרוא רק לנתבי DEX מאושרים מראש.

ארכיטקטורת Solver

Router

ה-Solver חייב למצוא את מסלול הביצוע הטוב ביותר תוך ~10-30 שניות. זו בעיית מציאת נתיב על גרף נזילות:

interface LiquiditySource {
  type: 'uniswapV3' | 'curve' | 'balancer' | 'uniswapV2';
  address: string;
  fee: number;
  token0: string;
  token1: string;
  liquidity: bigint;
  sqrtPriceX96: bigint;
}

async function findOptimalRoute(
  sellToken: string,
  buyToken: string,
  sellAmount: bigint,
  sources: LiquiditySource[]
): Promise<Route> {
  // Строим граф всех пулов
  const graph = buildLiquidityGraph(sources);
  // Ищем все пути длиной 1-3 hop
  const paths = findAllPaths(graph, sellToken, buyToken, maxHops=3);
  // Для каждого пути считаем expectedOutput с учётом price impact
  const quotes = await Promise.all(
    paths.map(path => simulatePath(path, sellAmount))
  );
  // Оптимальное разделение между несколькими путями (split routing)
  return optimizeSplit(paths, quotes, sellAmount);
}

ניתוב מפוצל הוא היתרון המרכזי של Solver חכם. פיצול הזמנה על פני מספר מסלולים מפחית את השפעת המחיר ומניב מחיר ממוצע טוב יותר מאשר המרה אחת גדולה. ה-Solvers שלנו מטפלים בעד 100 Intents בשנייה—פי 3 מהר יותר מיישומים טיפוסיים.

למה ניתוב מפוצל משפר יעילות

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

נתוני מאגר בזמן אמת

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

• מינוי WebSocket לאירועי >= minBuyAmount דרך Alchemy/Infura—השהיה ~500ms, מספיק לרוב המקרים
• צומת מלא משלו עם IPC—השהיה ~50ms, ל-Solvers בתדירות גבוהה
• ניטור Mempool—ה-Solver רואה עסקאות ממתינות ומתחשב בהן בחישוב המחיר

עבור Uniswap V3: מצב המאגר (sqrtPriceX96, tick, liquidity) חייב להתעדכן באופן מצטבר לאחר כל אירוע Swap. חישוב מחדש מלא דרך RPC איטי מדי.

צירוף מקרים של רצונות (CoW)

אם שני משתמשים רוצים להחליף טוקנים הפוכים, ה-Solver יכול להתאים ביניהם ישירות ללא DEX. קונה A רוצה להחליף ETH ל-USDC. קונה B רוצה להחליף USDC ל-ETH. ה-Solver מתאים ביניהם ישירות, חוסך לשניהם גז והחלקת מחיר. זה יתרון ייחודי של סילוק אצווה.

הגנת MEV

ארכיטקטורה מבוססת Intent מגנה מטבעה מפני frontrunning: ה-intent חתום עם interface LiquiditySource { type: 'uniswapV3' | 'curve' | 'balancer' | 'uniswapV2'; address: string; fee: number; token0: string; token1: string; liquidity: bigint; sqrtPriceX96: bigint; } async function findOptimalRoute( sellToken: string, buyToken: string, sellAmount: bigint, sources: LiquiditySource[] ): Promise<Route> { // Строим граф всех пулов const graph = buildLiquidityGraph(sources); // Ищем все пути длиной 1-3 hop const paths = findAllPaths(graph, sellToken, buyToken, maxHops=3); // Для каждого пути считаем expectedOutput с учётом price impact const quotes = await Promise.all( paths.map(path => simulatePath(path, sellAmount)) ); // Оптимальное разделение между несколькими путями (split routing) return optimizeSplit(paths, quotes, sellAmount); } , כך שהתקפות סנדוויץ' בלתי אפשריות—אם המחיר הסופי גרוע מהסף, העסקה נדחית. עם זאת, ה-Solver עצמו יכול להיות קורבן ל-frontrunning על העסקאות שלו. פתרון: סכמת commit-reveal להצעות מחיר במכירה הפומבית.

מה כלול

מכירה פומבית מרכזית לעומת רשת P2P

ערימת טכנולוגיות

• Solidity — חוזה סילוק, סוגי EIP-712, רשימה לבנה של DEX
• TypeScript + viem — לוגיקת Solver, מציאת נתיב, אינטגרציות DEX
• Foundry — בדיקת חוזה סילוק, במיוחד מקרי קצה
• Redis — מטמון מצב מאגר, תור Intents
• בדיקות Fork של Hardhat — סימולציה של מסלולים מרובי-קפיצות מורכבים על Fork של Mainnet

התהליך שלנו

ניתוח (3-5 ימים). הגדרת היקף: אילו טוקנים, אילו DEXים, מכירה פומבית מרכזית או p2p, מודל מונטיזציה של Solver.

פיתוח חוזה סילוק (1-2 שבועות). חתימת EIP-712, לוגיקת מכירה פומבית, בדיקות אבטחה. תשומת לב מיוחדת לביצוע calldata שרירותי.

פיתוח Solver (1-2 שבועות). מציאת נתיב, ניהול מצב בזמן אמת, חישוב הצעת מחיר. בדיקות (שבוע אחד). בדיקות Fork על Mainnet, סימולציה של תרחישי CoW, בדיקות עמידות ל-MEV.

לוח זמנים ועלות

מערכת בסיסית ל-DEX יחיד עם ביצוע פשוט של קפיצה אחת: 1-2 שבועות, עלות החל מ-$15,000. מערכת מלאה מרובת-DEX עם ניתוב מפוצל, CoW ומכירה פומבית: 4-6 שבועות, עלות בדרך כלל $40,000-$60,000. העלות נקבעת לאחר הניתוח. צרו קשר—נעריך את הפרויקט שלכם תוך יום אחד. קבלו ייעוץ על ארכיטקטורה ואופטימיזציית גז.

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