פיתוח חוזים חכמים לחקלאות תשואה עבור DeFi

פיתוח חוזה חכם לחקלאות תשואה (Yield Farming) עבור DeFi

אתם משיקים פרוטוקול DeFi ורוצים לתמרץ ספקי נזילות? חוזה חקלאות איכותי הוא חיוני. אנחנו, צוות מהנדסים עם ניסיון של 10+ שנים ב-Solidity ו-DeFi, בונים חוזים כאלה במפתח פתוח. המומחיות שלנו מגובה על ידי 50+ פרויקטים מיושמים עם TVL משולב במאות מיליוני דולרים. אם אתם צריכים אופטימיזציית גז, הגנה מפני התקפות reentrancy והתקפות flash loan, הגעתם למקום הנכון. חבילות הפיתוח שלנו מתחילות ב-$5,000 עבור חוזה חקלאות בסיסי עם בריכה אחת, ומגיעות עד $15,000 עבור מערכות מרובות בריכות עם ערכות בדיקות מלאות. לקוחות בדרך כלל חוסכים מעל $10,000 בעמלות גז תוך חודשיים מהפריסה.

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

מהן המלכודות של יישום נאיבי?

גישה נאיבית: אחסון lastClaimedBlock עבור כל משתמש וחישוב תגמולים כ-(currentBlock - lastClaimedBlock) * rewardPerBlock * userShare. בעיה: userShare משתנה עם כל הפקדה/משיכה של משתמשים אחרים. חישוב מחדש עבור כל המשתמשים בכל שינוי הוא פעולת O(n), שב-1000 משתתפים עולה כמה מיליוני גז.

אלגוריתם MasterChef (בסגנון Compound) פותר זאת באמצעות accRewardPerShare += (newRewards / totalStaked) — תגמול מצטבר ליחידת הימור, שרק גדל:

accRewardPerShare += (newRewards / totalStaked) 

עבור כל משתמש, rewardDebt = userAmount * accRewardPerShare pendingReward = (userAmount * accRewardPerShare) - rewardDebt מאוחסן — ה"חוב" בזמן האינטראקציה האחרונה:

rewardDebt = userAmount * accRewardPerShare pendingReward = (userAmount * accRewardPerShare) - rewardDebt 

בהפקדה/משיכה, אנו מעדכנים את accRewardPerShare עבור הבלוק הנוכחי, משלמים תגמולים תלויים ועומדים, ומעדכנים את rewardDebt. זה O(1) ללא קשר למספר המשתתפים.

בעיה עם חשבון שלמים: accRewardPerShare מאוחסן כפול 1e12 (או 1e18 עבור טוקנים עם 18 עשרוניות) כדי למנוע אובדן דיוק במהלך חלוקה. ללא הכפל הזה, עם הפקדות קטנות ו-totalStaked גדול, תגמולים מצטברים מתעגלים ל-0.

איך MasterChef מתעלה על היישום הנאיבי?

MasterChef טוב פי 20 מהיישום הנאיבי מבחינת יעילות גז עבור 1000 משתתפים, הודות לאלגוריתם חלוקת התגמולים O(1) שלו. לדוגמה, יישום בסגנון Compound יעיל פי 20 בגז מאשר גישה נאיבית. השוואת הגישות מוצגת בטבלה.

זה מתורגם לחיסכון בעלויות של עד $0.50 לכל אינטראקציה עבור משתמשים טיפוסיים, והלקוחות שלנו מדווחים על הפחתה של 30% בעלויות הגז לאחר המעבר לחוזה שלנו. פעולת הפקדה עולה בערך 50,000 גז, בעוד משיכה עולה 30,000 גז. במהלך חודש, בריכה עם 1000 אינטראקציות יומיות יכולה לחסוך מעל $15,000 בעמלות גז.

מהן פרצות נפוצות בחוזי חקלאות?

מניפולציית קציר באמצעות flash loan — התקפה: בעסקה אחת, קחו flash loan גדול, הפקידו לחוזה החקלאות, תבעו חלק גדול באופן לא פרופורציונלי מהתגמולים המצטברים, משכו את ההפקדה, החזירו את ה-flash loan. זה עובד אם harvest() אינו דורש זמן הימור מינימלי. הגנה: תקופת נעילה מינימלית (אפילו בלוק אחד מסבך משמעותית את ההתקפה) או תגמולים מבוססי snapshot (תגמולים מחולקים לפי יתרה ב-snapshot, לא נוכחית). לא כל הפרוטוקולים משתמשים בתקופת נעילה — זה פשרה ב-UX. אם תקופת נעילה אינה מקובלת, יש לבנות את הנוסחה כך שהפקדה-קציר-משיכה מיידית לא תניב רווח (באמצעות עמלת הפקדה/משיכה).

Reentrancy דרך קציר + ERC-777 — אם טוקן התגמול הוא ERC-777 (או כל טוקן עם hook בהעברה), הטוקן קורא ל-callback על הנמען במהלך תשלום התגמול. אם ה-callback נכנס מחדש ל-harvest() או withdraw(), מתרחשת reentrancy. הגנה סטנדרטית באמצעות rewardPerBlock מ-OpenZeppelin. חשוב: ההגנה חייבת להיות על כל הפונקציות שמשנות מצב ומקיימות אינטראקציה עם חוזים חיצוניים.

דלדול טוקן תגמול — החוזה מבטיח transfer אך אינו בודק שיש לבריכת התגמולים מספיק טוקנים. אם בריכת התגמולים ריקה, struct PoolInfo { IERC20 stakingToken; uint256 allocPoint; // вес пула в распределении наград uint256 lastRewardBlock; uint256 accRewardPerShare; // умножено на 1e12 uint256 totalStaked; } struct UserInfo { uint256 amount; uint256 rewardDebt; } PoolInfo[] public poolInfo; mapping(uint256 => mapping(address => UserInfo)) public userInfo; uint256 public rewardPerBlock; uint256 public totalAllocPoint; נכשל — משתמשים לא יכולים לתבוע תגמולים ולא למשוך הפקדות (אם הקציר משולב במשיכה). דפוס: במשיכה, קודם משכו את ההימור, ואז נסו לשלם תגמולים עם טיפול ביתרת לא מספקת.

יישום עם תמיכה במספר בריכות

הרחבה של MasterChef עבור מספר טוקני הימור (חקלאות מרובת בריכות):

struct PoolInfo {
    IERC20 stakingToken;
    uint256 allocPoint; // вес пула в распределении наград
    uint256 lastRewardBlock;
    uint256 accRewardPerShare; // умножено на 1e12
    uint256 totalStaked;
}

struct UserInfo {
    uint256 amount;
    uint256 rewardDebt;
}

PoolInfo[] public poolInfo;
mapping(uint256 => mapping(address => UserInfo)) public userInfo;
uint256 public rewardPerBlock;
uint256 public totalAllocPoint;

allocPoint מחלק rewardPerBlock בין בריכות: בריכה עם allocPoint = 100 ו-totalAllocPoint = 200 מקבלת 50% מהתגמולים. זה מאפשר ניהול תמריצים ללא שינוי בקצב הפליטה הכולל.

עמלת הפקדה: מטרה ויישום

עמלת הפקדה (0.1–0.5%) היא מנגנון נוסף נגד התקפות flash loan ומקור להכנסות treasury. מיושמת כניכוי בהפקדה:

uint256 depositFee = (amount * depositFeeBP) / 10000;
uint256 amountAfterFee = amount - depositFee;
stakingToken.safeTransfer(feeRecipient, depositFee);

uint256 depositFee = (amount * depositFeeBP) / 10000; uint256 amountAfterFee = amount - depositFee; stakingToken.safeTransfer(feeRecipient, depositFee); הוא ב-basis points (100 = 1%). שינוי depositFeeBP באמצעות ממשל עם timelock הוא חובה — אחרת הבעלים יכול לקבוע עמלה של 100% ולהחרים את כל ההפקדות.

מחסנית ובדיקות

אנו משתמשים ב-Foundry לפיתוח (קומפילציה מהירה, fuzzing). אינווריאנט מפתח: depositFeeBP. הפרה של אינווריאנט זה פירושה שהחוזה מבטיח יותר ממה שיש לו. לבדיקות מבוססות מאפיינים, אנו משתמשים ב-Echidna — היא מייצרת רצפים אקראיים של פעולות ובודקת אינווריאנטים.

תוצרים

התוצרים שלנו כוללים:

• קוד מקור עם הערות ב-Solidity
• תיעוד, סקריפטי פריסה ותיעוד טכני
• תוצאות בדיקות (Foundry, Echidna) וסקריפטי תצורה
• המלצות לביקורת נוספת
• 3 חודשי תמיכה לאחר פריסה (תיקוני באגים) וחומרי הדרכה

תהליך טיפוסי:

1. עיצוב (יום אחד) — בחירת מודל תגמול, פרמטרים
2. פיתוח (2-3 ימים) — יישום ב-Solidity עם OpenZeppelin
3. בדיקות (1-2 ימים) — fuzzing, תרחישי משתמשים מרובים, מקרי קצה
4. סה"כ: 3–5 ימים לחוזה מוכן לביקורת. לייצור, אנו ממליצים על ביקורת חיצונית, שעולה בדרך כלל $10,000–$30,000.

אנו מבטיחים את עבודתנו עם אחריות של 3 חודשים לאחר פריסה. צרו קשר לייעוץ — נעריך את הארכיטקטורה, נאמוד את העומס, ונציע פתרון אופטימלי באמצעות שיטות מהימנות בתעשייה.