למעלה מ-200 פרויקטים יצרו עותק (fork) של Uniswap v2, אך רובם נכשלו בשקט. הסיבה אינה הקוד—הוא מנוסה בקרב. הבעיה היא שהעותק הועתק כפי שהוא ללא הבנת המכניקה, ונשבר בהתאמה הראשונה. התנגשות אחסון במהלך שדרוג, פרמטרי עמלה מכוילים בצורה שגויה, מנגנון תמחור שבור עקב אתחול מאגר שגוי—זו הסיבה ש"פשוט ליצור עותק של Uniswap" לא עובד ללא ידע מעמיק בפרטים הפנימיים. אנו מתמחים בהתאמת פרוטוקולי DeFi למשימות ספציפיות, עם ביקורת ובדיקה של כל שינוי. הניסיון שלנו: מספר שנים בשוק, עשרות עותקים מוצלחים. התאמת עותק חוסכת עד 70% מהתקציב בהשוואה לבנייה מאפס.
אילו בעיות פותרת התאמת עותק?
השלב הראשון הוא להבין בדיוק מה אנו מעתיקים. Uniswap v2, Uniswap v3, Curve, Aave v3, Compound v3, Balancer v2—לכל אחד יש ארכיטקטורה ומגבלות התאמה משלו.
עותק של Uniswap v2 — הפשוט ביותר. לוגיקת AMM ב-UniswapV2Pair, ראוטר נפרד. התאמות: מבנה עמלות (v2 קבוע 0.3%), טוקנומיקה של טוקן LP, רשימת היתרים לזוגות מסחר. תוספות: רכישה חוזרת באמצעות עמלת פרוטוקול, תגמולי סטייקינג ל-LP.
עותק של Aave v3 — מורכב יותר. הפרוטוקול מודולרי, מעל 20 חוזים. התאמות: רשימת נכסים נתמכים, פרמטרי LTV/סף פירוק, אסטרטגיית ריבית, הפעלה/השבתה של מצב בידוד לנכסים חדשים. אל תיגעו: מתמטיקת InterestRateModel המרכזית ללא הבנה מעמיקה, מכניקת aToken.
עותק של Curve — משימה נישתית להחלפות יציבות. פרמטר A (הגברה) הוא קריטי: גבוה מדי—המאגר לא מאזן מחדש במהלך ניתוק שער, נמוך מדי—החלקה גבוהה. ערך A עבור מאגרי Curve קיימים כוונן בניסוי במשך חודשים.
טעויות נפוצות בעותקים
חישוב עמלות שגוי. ב-Uniswap v2, העמלה נלקחת דרך amountIn * 997 / 1000 (0.3%). אם משנים את העמלה ללא חישוב מחדש של הקבוע, האינווריאנט k = x * y נשבר. עסקאות יעברו, אך יתרת המאגר תהיה שגויה, ו-LP יפסידו כסף.
פריסת אחסון במהלך שדרוג עותק. אם לוקחים את Aave v3 עם ארכיטקטורת proxy ומוסיפים משתנה באמצע האחסון, השדרוג הבא ישבור את האחסון. Aave v3 משתמש במבנה ReserveData שלו בחריץ אחסון N. הוספת שדה לפניו מזיזה את כל הנתונים הבאים.
הגדרת אורקל. Aave v3 משתמש באגרגטורים של Chainlink עם heartbeat וסף סטייה ספציפיים לכל נכס. יצירת עותק בשרשרת חדשה דורשת תמיכת Chainlink בשרשרת זו או החלפת האורקל. שימוש באורקל ללא הגנה נגד מניפולציות (TWAP, מפסק חשמל) הוא וקטור ישיר להתקפות מניפולציית אורקל.
כיצד אנו מתאימים: מחסנית ותהליך
ניתוח מבוסס-הבדלים
אנו לוקחים את הפרוטוקול המקורי מ-GitHub הרשמי, יוצרים עותק למאגר פרטי. כל השינויים עוברים רק דרך pull requests עם תיאור סיבה והשפעה. זה מאפשר git diff מול המקור בכל עת כדי לראות את היקף השינויים המלא.
גודל הבדלים טיפוסי עבור התאמת Uniswap v2 "קלה" עם מנגנון עמלה נוסף הוא 200-400 שורות. אם ההבדלים עולים על 1000 שורות, זה כבר לא התאמה—זה פרוטוקול חדש.
פרמטריזציה באמצעות קונפיגורציות
עותקים טובים שמים פרמטרים הניתנים לשינוי בקונפיגורציות הנשלטות על ידי אדמין במקום לקודד אותם בחוזים. Uniswap v2 עם עמלה משתנה: uint256 public swapFee = 30; // basis points עם setter של onlyOwner ו-timelock. זה מאפשר כיוונון פרמטרים לאחר פריסה ללא שדרוג חוזה.
בדיקת לוגיקה שונה
בדיקות עותק ב-Foundry הן כלי האימות העיקרי. אנו לוקחים עסקאות היסטוריות אמיתיות של הפרוטוקול המקורי, משחזרים אותן מול העותק שלנו, ומשווים תוצאות. פער ביתרות מצביע על שגיאת מתמטיקה.
בדיקות אינווריאנט: עבור AMM—k צריך רק לגדול (לא לקטון) עם כל החלפה. עבור הלוואות—totalDebt לעולם לא עולה על totalSupply. אנו מריצים Echidna ל-100k+ איטרציות.
| פרוטוקול | מורכבות עותק | זמן התאמה טיפוסי | סיכונים עיקריים |
|---|---|---|---|
| Uniswap v2 | נמוכה | 3-7 ימים | מתמטיקת עמלות, אורקל |
| Uniswap v3 | גבוהה | 2-4 שבועות | מתמטיקת Tick, נזילות מרוכזת |
| Aave v3 | גבוהה | 2-4 שבועות | הגדרת אורקל, פרמטרי סיכון |
| Curve StableSwap | בינונית | 1-2 שבועות | פרמטר A, אתחול מאגר |
| Balancer v2 | בינונית | 1-2 שבועות | ארכיטקטורת Vault, מתמטיקת מאגר |
למה להפקיד את העותק בידי אנשי מקצוע?
התאמת עותק מהירה פי 3 מבנייה מאפס ודורשת פחות ביקורות. אתה מקבל פרוטוקול מוכן עם פרמטרים מכוילים, שינויים מאומתים ותיעוד. אנו מבטיחים אבטחה: כל שינוי נבדק עם אינווריאנטים ובדיקות עותק, תיעוד ההבדלים עוקב אחר כל השינויים. התאמת עותק חוסכת עד 70% מהתקציב בהשוואה לבנייה מאפס. עלות ההתאמה מחושבת באופן אישי, אך בממוצע היא נמוכה ב-30-50% מפיתוח מאפס.
מקור: ניתוח של עשרות עותקי פרוטוקולי DeFi בשנים האחרונות.
שלבי התאמת עותק
- ניתוח פרוטוקול והכנת מפרט שינויים.
- פיתוח חוזים מותאמים עם תיעוד הבדלים.
- כתיבת בדיקות עותק ואינווריאנט (Foundry, Echidna).
- ביקורת פנימית של הקוד המותאם.
- פריסה באמצעות
forge scriptוניטור לאחר פריסה.
רשימת בדיקה לפני פריסה
- [ ] כל השינויים מתועדים ב-PR.
- [ ] בדיקות עותק עברו על נתונים היסטוריים.
- [ ] בדיקות אינווריאנט (Echidna)—100k+ איטרציות.
- [ ] ביקורת חוזים מותאמים על ידי צוות חיצוני.
- [ ] סקריפטי פריסה ניתנים לשחזור.
הערכות זמנים
| סוג התאמה | זמן | דוגמאות |
|---|---|---|
| קלה (מכניקת עמלות, רשימת היתרים) | 1-2 שבועות | Uniswap v2 |
| בינונית (פרמטרי מאגר חדשים) | 2-3 שבועות | Curve, Balancer v2 |
| מורכבת (נכסים חדשים, אורקלים) | 2-4 שבועות | Aave v3, Compound v3 |
צור קשר לניתוח חינם של הפרוטוקול שלך—נעריך את המורכבות ונציע תוכנית התאמה אופטימלית תוך יום אחד. קבל ייעוץ לדיון בפרטים וקבלת הערכת עלות.