פיתוח מערכת ניתוב מפוצל לאופטימיזציית מחיר

הערה: בעת ביצוע הזמנה גדולה דרך DEX יחיד, החלקת מחיר (price slippage) מובטחת ב-3–8% — אפילו ב-Uniswap v3 עם נזילות מרוכזת. בזוגות לא נזילים, השפעת המחיר (price impact) אוכלת אפילו יותר. אנו מפתחים מערכות ניתוב מפוצל (split-routing) — לא טריק שיווקי, אלא חלוקת הזמנות מדויקת מתמטית בין מספר מקורות נזילות. ניתוב מפוצל לוקח בחשבון את עקומות הנזילות של כל בריכה ומוצא את החלוקה האופטימלית, תוך מזעור השינוי הכולל במחיר. לפי מסמך הלבן של Uniswap v3, נזילות מרוכזת מאפשרת עומק מוגבר בטווח צר, אך הזמנה גדולה עדיין גורמת להחלקת מחיר. הגישה שלנו פותרת זאת על ידי הפצת הזרימה בין Uniswap, Curve, Balancer ופרוטוקולים אחרים. צרו קשר לניתוח נזילות מקדים — נעריך את הפרויקט שלכם ונציע ארכיטקטורה מוכנה לשימוש.

למה חלוקה נאיבית לא עובדת

גישה אינטואיטיבית — חלוקה של 50/50 בין Uniswap ל-Curve — נותנת תוצאה לא אופטימלית. החלוקה האופטימלית היא לא ליניארית ותלויה במצב הנוכחי של הבריכות, בעומק הנזילות בטיקים ספציפיים (עבור Uniswap v3), ובשיפוע עקומת הקשר (עבור Curve StableSwap). הבעיה מחמירה בשל העובדה שמצבי הבריכה משתנים בין חישוב המסלול לביצוע העסקה.

איך בוטים של MEV תוקפים ניתוב מפוצל

מערכות ניתוב מפוצל מותקפות בשתי רמות. ראשית, מתקפת הסנדוויץ' הקלאסית: בוט MEV רואה החלפה גדולה ב-mempool, מציב קנייה לפניו ומכירה אחריו, תוך שימוש ב-Flashbots bundles או ב-mempool פרטי. הרמה השנייה עדינה יותר: המסלול מחושב off-chain על סמך מצבי הבריכה בבלוק N, אך מבוצע בבלוק N+2. במשך שני בלוקים, הנזילות בטיק הפעיל של Uniswap v3 עשויה להשתנות, מה שהופך את המסלול האופטימלי לתת-אופטימלי.

בפועל, זה אומר שאלגוריתם הניתוב חייב לשלב סובלנות לשינויי מצב ולחשב מחדש אם התפוקה בפועל חורגת מהצפוי. 1inch מיישמת זאת באמצעות מילוי חלקי עם minReturn; אנו מיישמים מנגנון דומה במבצע ה-on-chain שלנו.

בעיית האטומיות במסלולים רב-שלביים

פיצול על פני מספר עסקאות אינו פיצול — אלא החלפות רציפות. ביצוע אטומי דורש חוזה מאגד (aggregator) שמבצע את כל חלקי המסלול בקריאה אחת דרך multicall או לוגיקת ניתוב מותאמת אישית. אם שלב ביניים נכשל, כל החבילה מתגלגלת לאחור. זה דורש טיפול זהיר בגז: כל הופ נוסף עולה 30–80k גז בהתאם לפרוטוקול.

מה זה ניתוב מפוצל ולמה הוא נחוץ

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

איך אנחנו בונים ניתוב מפוצל

אלגוריתם אופטימיזציית מסלול

הליבה היא מייעל off-chain שפותר את הבעיה של מזעור השפעת המחיר הכוללת. עבור כל DEX, אנו מקבלים עקומת "נפח → מחיר ביצוע":

• Uniswap v2/v3, PancakeSwap: דרך חוזה quoter או סימולציה דרך eth_call עם מצב fork
• Curve: נוסחת StableSwap/Cryptoswap אנליטית
• Balancer: נוסחת WeightedPool או StablePool דרך querySwap
• DODO: PMM (Proactive Market Maker) — עקומה לא ליניארית עם פרמטרי אורקל

המייעל מפצל את ההזמנה ל-N חלקים ומבצע איטרציות על החלוקה, תוך מזעור התפוקה הכוללת. אנו משתמשים בירידה בגרדיאנט עם דיפרנציאציה מספרית — נגזרות אנליטיות עבור Uniswap v3 עם טיקים אינן טריוויאליות בשל הדיסקרטיות. האלגוריתם מתכנס ב-50–200 איטרציות, ומשיג <100ms על שרת טיפוסי.

מבצע on-chain

חוזה המאגד מקבל מסלול מקודד מהמייעל off-chain: מערך של (address pool, bytes calldata swapData, uint256 portion). המבצע עובר על המערך, קורא לכל בריכה עם החלק המחושב של טוקן הקלט. הוא מאמת actualOutput >= minOutput דרך require, אחרת הוא נכשל.

struct SwapStep {
    address pool;
    address tokenIn;
    address tokenOut;
    uint256 amountIn;
    bytes data; // ABI-encoded call to pool
}

עבור Uniswap v3, struct SwapStep { address pool; address tokenIn; address tokenOut; uint256 amountIn; bytes data; // ABI-encoded call to pool } מכיל data מקודד עם פרמטרים. עבור Curve — exactInputSingle עם exchange, i, j. ממשק אחיד דרך מתאמים (adapters) לכל פרוטוקול.

הגנה מפני MEV

אינטגרציה עם Flashbots Protect RPC כאופציה להזמנות גדולות — העסקה הולכת ישירות ל-builder, תוך עקיפת ה-mempool הציבורי. עבור L2 תואמי EVM (Arbitrum, Optimism), סיכון ה-MEV נמוך יותר בשל sequencers מרכזיים, אך בוטים של MEV כבר מופיעים ב-Base ו-zkSync.

סובלנות החלקת המחיר מוגדרת דינמית: עבור זוגות עם תנודתיות גבוהה (אלטים) — 0.5–1%, עבור stablecoins ב-Curve — 0.05–0.1%.

מה כלול

• תיעוד: תיאור ארכיטקטורה, מפרט API, פרמטרי תצורה.
• קוד מקור: מייעל off-chain (TypeScript/Python) וחוזים חכמים עם בדיקות.
• אינטגרציה: הגדרת פריסה, חיבור front-end, הדרכת צוות.
• תמיכה: שבועיים של ניטור ותיקונים לאחר ההשקה.

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

תהליך

1. ניתוח נזילות (3–5 ימים). פרופיל בריכות ברשתות היעד: עומק נזילות, נפחים טיפוסיים, התפלגות טיקים עבור v3. קביעה אילו DEXים לשלב.
2. פיתוח מייעל (1–2 שבועות). שירות off-chain ב-TypeScript/Python. בדיקות על נתונים היסטוריים דרך The Graph — כמה המסלול האופטימלי עולה על החלפה ישירה במחיר התפוקה.
3. מבצע חוזה חכם (שבוע). פיתוח ובדיקות עם Foundry fork tests על mainnet. בדיקת כל מקרי הקצה: תפוקת אפס, revert בבריכת ביניים, reentrancy דרך callback.
4. אינטגרציה ופריסה. API ל-front-end, תיעוד פרמטרים, פריסה ל-testnet → mainnet דרך Gnosis Safe multisig.

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

מערכת בסיסית עם 3–5 DEXים ברשת אחת — 3–4 שבועות. מאגד רב-רשתי עם ניתוב חוצה L2 דרך גשר — החל מחודשיים. לוחות הזמנים תלויים במספר הפרוטוקולים המשולבים ובדרישות עדכון המסלול בזמן אמת.

מלכודות טיפוסיות בפיתוח

השוואה: ניתוב מפוצל מול החלפה ישירה

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

מסמך לבן של Uniswap v3 • תיעוד Curve Finance

למהנדסים שלנו יש מעל 5 שנות ניסיון ב-DeFi, עם 30+ פרויקטים מוצלחים. אנו מבטיחים קוד שקוף עם מערכת בדיקות מלאה. הזמינו ניתוח נזילות מקדים — נבחר את מערך ה-DEXים האופטימלי עבור הטוקנים שלכם.