פיתוח Fork של Uniswap עבור DEX מותאם אישית
ראינו צוותים שהפסידו מיליונים על Forkים של Uniswap שלא תוכננו כראוי. פשוט להעתיק את המאגר ולשנות את השם זה לא הנדסה. צריך להבין את האינווריאנטים של AMM, להחליט אילו פרמטרים לשנות, לכתוב מחדש בדיקות למתמטיקה ששונתה, ולבצע ביקורת. אחד הלקוחות שלנו איבד 1.2 מיליון דולר בהתקפת flash loan עקב חישוב עמלות שגוי ב-Fork על BSC. כדי להימנע מהפסדים כאלה, בקשו הערכה מקצועית של הפרויקט — צרו קשר להערכה חינם.
איזה Fork לבחור: v2 או v3?
בחירת הגרסה קובעת את המורכבות והיכולות. Uniswap v2 פשוט ומהיר יותר לפיתוח (פי 2 פחות זמן מ-v3), אך v3 מציע יעילות הון גדולה פי 10 עבור מאגרי נזילות גבוהים. הנה השוואה:
טבלת השוואה
| פרמטר | Uniswap v2 | Uniswap v3 |
|---|---|---|
| ארכיטקטורה | פשוטה, x*y=k | נזילות מרוכזת, ticks |
| התאמה אישית | קל לשנות עמלה | מורכב, הרבה מתמטיקה |
| ביקורת Fork | 2-4 שבועות | 4-12 שבועות |
| Forkים קיימים | מאות (PancakeSwap, SushiSwap) | פחות (Pancake v3, Camelot) |
| גז לכל החלפה | ~120k | ~150-200k |
| יעילות הון | נמוכה | גבוהה |
עבור רוב ה-DEXים החדשים, אנו ממליצים להתחיל עם ארכיטקטורת v2 ורמות עמלות מותאמות אישית. נזילות מרוכזת (v3) מוצדקת אם אתם מבינים בבירור כיצד ספקי נזילות (LPs) ינהלו פוזיציות ואתם מוכנים לביקורת מורכבת יותר.
מה אנו מתאימים אישית ב-Fork?
מבנה העמלות. ב-Uniswap v2, העמלה קבועה על 0.3%, עם 0.05% כעמלת פרוטוקול. ב-Fork ניתן:
- לשנות את העמלה הבסיסית (למשל, 0.1% עבור זוגות stablecoin, 1% עבור טוקנים אקזוטיים)
- להוסיף עמלות דינמיות המבוססות על תנודתיות (דורש אורקל או TWAP)
- להפנות את עמלת הפרוטוקול לאוצר DAO, לסטייקינג או ל-buyback של טוקנים
- להוסיף עמלות הפניה: חלק מהעמלה הולך למפנה (דורש מיפוי מפנה → כתובת)
הגבלות ספציפיות לטוקנים. לעיתים קרובות יש צורך בזוגות רק בין טוקנים מאושרים (factory מורשה) או להגביל יצירת מאגרים ללא אישור multisig. זה מתווסף דרך mapping(address => bool) public allowedTokens ומודיפייר ב-createPair.
אורקלים למחיר ו-TWAP. Uniswap v2 מאחסן מחירים מצטברים עבור TWAP — מובנה ב-_update(). Fork יכול להוסיף צילומי מצב תכופים יותר או לשלב Chainlink להגנה מפני מניפולציות. החולשה של TWAP המקורי: עם נזילות נמוכה, חלונות TWAP קצרים (~5 דקות) פגיעים למניפולציות מחיר באמצעות החלפות גדולות.
מדוע 90% מה-Forkים פגיעים להתקפות Flash Loan?
השגיאה ב-Forkים: שינוי לוגיקת העמלות שובר את חישוב האינווריאנט. Uniswap v2 בודק את האינווריאנט לאחר כל הפעולות בעסקה:
require(balance0Adjusted * balance1Adjusted >= uint(_reserve0) * uint(_reserve1) * 1000**2); אם require(balance0Adjusted * balance1Adjusted >= uint(_reserve0) * uint(_reserve1) * 1000**2); מחושב באופן שגוי עקב עמלה לא סטנדרטית, תוקף יכול לרוקן את המאגר באמצעות סדרה של עסקאות flash swap → החלפה חזרה, שכל אחת עוברת את הבדיקה אך יחד מסירות נזילות. גילינו את הבאג הזה בשלושה Forkים על BSC, מה שהוביל להפסדים של 1.2 מיליון דולר, 800 אלף דולר ו-3.5 מיליון דולר.
כל שינוי בלוגיקת העמלות דורש בדיקות fuzz חובה המבוססות על אינווריאנטים ב-Foundry: Echidna או balance0Adjusted של Foundry עם מאות אלפי פרמטרים אקראיים. אינווריאנט: vm.assume.
טוקנים עם עמלת העברה (fee-on-transfer). אם ה-DEX מיועד לטוקנים עם מס, ה-Uniswap v2 הסטנדרטי לא עובד כראוי: החוזה מצפה לקבל k_after >= k_before * (1 - fee) טוקנים אך מקבל amountIn. הפונקציות amountIn * (1 - tax) כבר קיימות ב-Uniswap, אך Forkים מינימליסטיים לעיתים קרובות זורקים אותן, מה ששובר תאימות עם טוקנים פופולריים של BSC.
כיצד אנו בודקים ופורסים את ה-Fork
פיתוח חוזים חכמים — Foundry לכל דבר: בדיקות, פריסה, fuzzing. אנו מבססים את העבודה שלנו על המאגרים הרשמיים Uniswap v2-core + v2-periphery כ-submodules כדי לראות בבירור את ההבדלים. השינויים מינימליים וממוקדים — אנו לא כותבים מחדש מה שעובד.
בדיקות. עבור Fork, הסט המינימלי כולל:
- יצירת זוג, הוספה/הסרה של נזילות
- החלפות בשני הכיוונים עם בדיקת אינווריאנט
- Flash swap עם החזר נכון ושגוי
- חישוב עמלות עבור ערכים לא סטנדרטיים
- בדיקות fuzz על האינווריאנט עם 100k+ איטרציות
- בדיקות Fork על mainnet: טוקנים אמיתיים, יתרות אמיתיות דרך
swapExactTokensForTokensSupportingFeeOnTransferTokens
פרונטאנד. אנו מתאימים את Uniswap Interface (קוד פתוח) או בונים מאפס באמצעות React + wagmi + viem. ה-Uniswap SDK v3 תואם ל-Forkים של v2 עם הגדרת chain וכתובת factory נכונה.
ראוטר אגרגציה. אם יש צורך בניתוב multi-hop דרך המאגרים שלך plus DEXים חיצוניים, אנו משלבים את 1inch Aggregation Protocol או כותבים ראוטר מותאם אישית. זה חשוב ל-UX: משתמשים לא צריכים לחפש מסלולים ידנית.
לוחות זמנים ושלבי פיתוח
| שלב | משך |
|---|---|
| תיעוד הנדסי ותכנון | 3-5 ימים |
| פיתוח חוזים חכמים (Fork v2) | 1-2 שבועות |
| פיתוח חוזים חכמים (Fork v3) | 4-6 שבועות |
| בדיקות fuzz פנימיות | שבוע אחד |
| ביקורת חיצונית (עלות אופיינית $30k–$100k) | 2-4 שבועות |
| פריסת Testnet ו-QA | 1-2 שבועות |
| פריסת Mainnet והגדרת multisig | שבוע אחד |
| תמיכה לאחר השקה | 30 ימים |
מה כלול בעבודה?
- תיעוד הנדסי המפרט את החריגות מהפרוטוקול המקורי
- פריסת Testnet ו-mainnet, כולל הגדרת multisig (Gnosis Safe)
- קוד מקור עם CI/CD, linters וכיסוי בדיקות >90%
- הכשרת הצוות שלך לעבודה עם ה-Fork ופריסת מאגרים חדשים
- תמיכה ל-30 יום לאחר ההשקה
תוכנית התאמה אישית של Fork שלב אחר שלב
- ניתוח דרישות ובחירת גרסת בסיס (v2/v3)
- Fork של המאגר ויצירת submodule עבור הקוד המקורי
- יישום שינויים בחוזים (עמלה, factory, ראוטר) תוך שמירה על ההבדלים
- כתיבת והרצת בדיקות, כולל בדיקות fuzz ו-Fork
- ביקורת אבטחה חיצונית
- פריסת Testnet ובדיקות אינטגרציה
- פריסת Mainnet עם multisig והגדרת נזילות
כמה זמן לוקח הפיתוח?
לוחות הזמנים תלויים במורכבות ההתאמה האישית: Fork v2 עם רמות עמלות שונות לוקח 1-2 שבועות פיתוח plus 2-4 שבועות ביקורת. Fork v3 מלא עם ממשק משתמש מותאם אישית מתחיל מחודשיים. עבור פרוטוקול production, ביקורת על ידי צוות חיצוני היא לא אופציונלית. אנו מבטיחים שקיפות בכל שלב — הניסיון שלנו: 10+ שנים בפיתוח blockchain (5+ שנים ב-DeFi), 40+ חוזים חכמים שפרוסים, ו-20+ ביקורות על Forkים של AMM. בקשו ייעוץ — בואו נדון בפרויקט שלכם.