בניית DEX ל-Swap יציב בסגנון Curve למסחר ב-LST

הבעיה והפתרון עבור נכסים צמודים

לקוח שלנו רצה להשיק DEX למסחר בטוקני LST. Curve Finance מחזיקה ב-$3-5B ב-TVL לא רק בגלל שהיא DEX, אלא בגלל שפתרה בעיה מתמטית ספציפית: עקומת A * n^n * sum(x_i) + D = A * D * n^n + D^(n+1) / (n^n * prod(x_i)) של Uniswap V2 מייצרת החלקה של 1% בעסקאות של רק 0.1% מעומק הבריכה. עבור נכסים שנועדו להיסחר בפריטי (USDC/USDT, stETH/ETH, WBTC/renBTC), זה בלתי מתקבל על הדעת. האינווריאנט של Stable Swap מרכז נזילות סביב הצמד, ומפחית החלקה בסדרי גודל. אנחנו לוקחים את המתמטיקה הזו ומתאימים אותה לפרויקט שלך, עם ניסיון של 5+ שנים בפיתוח פרוטוקולי DeFi ו-15+ פרויקטים שסופקו.

איך עובד Stable Swap?

Curve משתמשת באינווריאנט היברידי המשלב סכום קבוע (x+y=k, אפס החלקה) ומכפלה קבועה (x*y=k, נזילות אינסופית). עבור שני נכסים, הנוסחה היא:

A * n^n * sum(x_i) + D = A * D * n^n + D^(n+1) / (n^n * prod(x_i)) כאשר A הוא מקדם ההגברה, D הוא האינווריאנט, ו-n הוא מספר הנכסים.

מה תפקידו של מקדם ההגברה?

מקדם ההגברה הוא הפרמטר המרכזי. ב-A=0, המערכת מתנהגת כמו Uniswap (מכפלה קבועה). ב-A → ∞, היא מתנהגת כמו סכום קבוע. Curve משתמשת ב-A=100-2000 בהתאם לבריכה. עבור זוגות USDC/USDT, משתמשים ב-A גבוה (100-200) כי נכסים כמעט ולא סוטים מהפריטי. עבור stETH/ETH בהשקה, A היה נמוך יותר כי stETH נסחר בהנחה ו-A גבוה היה מוביל לחוסר איזון בבריכה.

חשוב לציין, ניתן לשנות את A, אבל השינויים חייבים להיות הדרגתיים. Curve מיישמת ramp_A ו-stop_ramp_A עם נעילת זמן של לפחות 7 ימים ומגבלה של שינוי פי 10 לכל התאמה. שינוי פתאומי של A בבריכה לא מאוזנת משנה למעשה את מחיר הנכסים, וזה שקול למניפולציה.

פרטי יישום טכניים

פותר מספרי: שיטת ניוטון

למשוואת האינווריאנט אין פתרון אנליטי עבור D — משתמשים ב-Newton-Raphson. יישום טיפוסי מתכנס ב-4-8 איטרציות תחת יתרות רגילות. הבעיה מתעוררת בבריכה לא מאוזנת מאוד שבה איטרציות עלולות לא להתכנס.

ב-Solidity, זה נראה כמו לולאה עם מגבלה של 255 איטרציות ובדיקה |D_new - D_prev| <= 1. אם זה לא מתכנס, זה חוזר (revert). זה מקרה נדיר, אבל בלעדיו, החוזה עלול להיתקע בלולאה אינסופית תחת התקפה מתוכננת במיוחד.

טיפול בדיוק בין עשרוניות שונות

לסטייבלקוינים שונים יש עשרוניות שונות: ל-USDC יש 6, ל-DAI יש 18, ל-USDT יש 6. פנימית, כל היתרות מנורמלות ל-18 עשרוניות דרך PRECISION_MUL = [1e12, 1e12, 1] (עבור בריכת USDC/USDT/DAI). אי-נרמול נכון יוצר פרצת אריתמטיקה המאפשרת משיכת חלק לא הוגן מהנכסים דרך remove_liquidity_one_coin.

מקרה אמיתי: באחד הפרויקטים שלנו עבור מנפיק LST גדול, ביצענו ביקורת על פורק של Curve וגילינו שגיאת נרמול. הבאג היה מאפשר לתוקף לחלץ יותר טוקנים עם 18 עשרוניות ממה שהפקיד עם 6 עשרוניות. תיקנו את הסקיילינג, והבריכה הושקה ללא תקלות.

מה כלול בחבילת הפיתוח שלנו

השירות שלנו מכסה את מחזור החיים המלא של הפרוטוקול:

• ארכיטקטורת בריכה מלאה (בריכת בסיס או מטה-בריכה): כוללת סקריפטי פריסה וקונפיגורציה.
• יישום חוזים: ליבת StableSwap, טוקן LP, אדמין עם נעילת זמן.
• אינטגרציה של ספקי שערים (אם נדרש): תומך באורקלים פנימיים וחיצוניים.
• סוויטת בדיקות מקיפה: בדיקות יחידה, בדיקות fork-mainnet, ובדיקות fuzz לאינווריאנטים.
• ביקורת אבטחה: ביקורת חיצונית על ידי חברה שותפה או סקירה פנימית על ידי הצוות שלנו.
• תיעוד: תיאור מתמטי, מדריך קונפיגורציה, ומדריך פריסה.
• תמיכה לאחר פריסה: חודש של ייעוץ ותיקוני באגים.
• מפגש הדרכה: לצוות שלך על ניהול בריכה והתאמת פרמטרים.
• גישה לכל מאגרי הקוד וסקריפטי הפריסה.

התהליך מהגדרת דרישות ועד השקה

1. הגדרת דרישות (שבוע): קביעת מספר הנכסים, צורך בספקי שערים, ארכיטקטורה (בריכת בסיס מול מטה-בריכה), מודל עמלות, פרמטרי ממשל.
2. ליבת מתמטיקה (1-2 שבועות): יישום אינווריאנט, שיטת ניוטון עבור D, get_y() לחישוב תפוקה. כיסוי בדיקות מול יישום ייחוס ב-Python של Curve.
3. חוזי בריכה וטוקן LP (1-2 שבועות): exchange, add/remove_liquidity, פונקציות אדמין עם נעילת זמן.
4. בדיקות אינטגרציה (שבוע): בדיקות fork, fuzzing של אינווריאנטים, בדיקות עומס לתרחישי חוסר איזון קיצוני.
5. ביקורת: עבור בריכות עם כספים אמיתיים, ביקורת חיצונית היא חובה. המתמטיקה של Stable Swap אינה טריוויאלית ומכילה מקרי קצה לא ברורים.

לוחות זמנים ושלבים הבאים

לוחות זמנים: 2 עד 4 חודשים מהגדרת דרישות ועד מוכנות לביקורת, תלוי במורכבות הארכיטקטורה.

עלות: חבילת הבריכה הסטנדרטית שלנו עולה $50,000, בעוד שארכיטקטורות מטה-בריכה מתקדמות יכולות לעלות עד $150,000. לקוחות בדרך כלל חוסכים 30% בהשוואה לפיתוח פנימי, מה שמשתווה לחיסכון של $15,000 עד $45,000. עלויות פיתוח לבריכה סטנדרטית מתחילות מ-$50,000.

סיכונים ואיך אנחנו מפחיתים אותם

לפצל את Curve זה מפתה — הקוד פתוח. אבל יש מלכודות:

• תרגום מ-Vyper ל-Solidity: פונקציות @view של Vyper הן קריאה-בלבד ברמת הקומפיילר. מודיפייר ה-view של Solidity לא תמיד מיושם נכון במהלך התרגום. ראינו פורקים שבהם פונקציה שמשנה מצב סומנה בטעות כ-view, מה שהוביל להנחות שגויות של בטיחות.
• Reentrancy קריאה-בלבד: התקפת reentrancy קריאה-בלבד על Curve אפשרה מניפולציה של מחיר טוקן ה-LP במהלך קריאת remove_liquidity. פרוטוקולים שהשתמשו במחיר טוקן ה-LP של Curve כאורקל היו פגיעים. אם הבריכה שלך מתוכננת כאורקל עבור פרוטוקולים אחרים, יישם נעילת reentrancy על כל הפונקציות שמשנות מצב ופיד מחירים נפרד ובטוח לקריאה.

הצוות שלנו מפחית את אלה עם בדיקות קפדניות: אנחנו משתמשים ב-Foundry לבדיקות fork, ב-Echidna ל-fuzzing, וב-Slither לניתוח סטטי. רשימת הבדיקות שלנו כוללת 50+ בדיקות ספציפיות לבריכות בסגנון Curve.

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

היישום שלנו מהיר פי 2 מפורקים מבוססי Vyper בזכות אופטימיזציות Solidity, ואנחנו מבטיחים אפס גלישות אריתמטיות עם OpenZeppelin Math.mulDiv. עם ניסיון של 5+ שנים, 15+ פרוטוקולי DeFi שסופקו, וצוות של 10+ מהנדסי בלוקצ'יין, אנחנו מבטיחים יישום אינווריאנט נכון ובדיקות יסודיות.

ערכת הכלים לפיתוח שלנו

התחילו עכשיו

צרו קשר עבור חבילת פיתוח סוהר. נעריך את הפרויקט שלכם תוך 2 ימי עסקים. השירות שלנו כולל יישום מלא, סוויטות בדיקות, תיאום ביקורת, וחודש של תמיכה לאחר פריסה. קבלו הערכה חינם: עזרנו ל-15+ פרוטוקולים להשיק עם אפס תקלות לאחר השקה.

תוכלו לקרוא עוד על המתמטיקה של StableSwap במסמך המקורי של Curve או בויקיפדיה.