פיתוח חוזה כריית נזילות
כאשר פרוטוקול משיק כריית נזילות, המשימה האופיינית היא לחלק תגמולי טוקנים באופן יחסי לנזילות שסופקה. במבט ראשון, זה סטייקינג פשוט, אבל לאחר הפריסה צצים עשרות מקרי קצה: התקפות flash loan, התקפת אינפלציה על חוזה ריק, אובדן דיוק מעיגול. לקוח אחד איבד 50,000 דולר עקב אובדן דיוק בגרסה הראשונה — לאחר מכן כתבנו מחדש את הארכיטקטורה, תוך יישום יתרה וירטואלית ראשונית וקנה מידה של 1e18. הצוות שלנו פתר בעיות אלו ביותר מ-50 פרויקטים, מ-IDOs קטנים ועד חוות multi-chain עם TVL > 200 מיליון דולר. אנחנו לא כותבים חוזה אחיד לכולם — כל פרויקט דורש התאמה אישית לכלכלת הטוקנים הספציפית שלו, ביקורת reentrancy ואופטימיזציית גז. צרו קשר כדי לפתח חוזים אמינים — נכין ארכיטקטורה והערכת עלות תוך יום אחד.
איך עובדת המתמטיקה של חלוקת תגמולים
האלגוריתם הבסיסי הוא MasterChef מ-Synthetix StakingRewards. הרעיון המרכזי: תגמול מצטבר ליחידת סטייק (rewardPerTokenStored).
uint256 public rewardPerTokenStored;
function rewardPerToken() public view returns (uint256) {
if (totalSupply == 0) return rewardPerTokenStored;
return rewardPerTokenStored + (
(block.timestamp - lastUpdateTime) * rewardRate * 1e18 / totalSupply
);
}
function earned(address account) public view returns (uint256) {
return (balanceOf[account] * (rewardPerToken() - userRewardPerTokenPaid[account]) / 1e18) + rewards[account];
}עדכונים מתרחשים רק בעת סטייק/משיכה/קבלת תגמול, לא בכל בלוק — O(1) ללא קשר למספר המשתתפים. השגיאה מבלוקים בדידים ממוזערת באמצעות קנה מידה של 1e18.
מה לגבי תגמולים מוגברים ורב-תגמולים?
במודלים כמו Convex/Curve, הסטייק האפקטיבי תלוי בטוקני ממשל נעולים (veTokens). הנוסחה:
effective_balance = min(0.4 * balance + 0.6 * (totalSupply * veBal / veTotalSupply), balance) זה מפחית לחץ מכירה על טוקן התגמול אך דורש בדיקה קפדנית במצב של veBalance אפסי. עבור רב-תגמולים, כל טוקן שומר על uint256 public rewardPerTokenStored; function rewardPerToken() public view returns (uint256) { if (totalSupply == 0) return rewardPerTokenStored; return rewardPerTokenStored + ( (block.timestamp - lastUpdateTime) * rewardRate * 1e18 / totalSupply ); } function earned(address account) public view returns (uint256) { return (balanceOf[account] * (rewardPerToken() - userRewardPerTokenPaid[account]) / 1e18) + rewards[account]; } משלו. הפניה: Synthetix StakingMultiRewards.
| פרמטר | Masterchef | תגמולים מוגברים | רב-תגמולים |
|---|---|---|---|
| מורכבות | נמוכה | בינונית | גבוהה |
| עלות גז | 50-70k | 70-90k | 90-120k |
| עמידות להתקפת אינפלציה | כן (יתרה וירטואלית) | כן | כן |
| גמישות כלכלת טוקנים | נמוכה | גבוהה | גבוהה |
| סיכון לאובדן דיוק | נמוך | בינוני | בינוני |
הגנה מפני פרצות בכריית נזילות
-
התקפת אינפלציה על הפקדה ראשונה. הכנס יתרה וירטואלית ראשונית (
effective_balance = min(0.4 * balance + 0.6 * (totalSupply * veBal / veTotalSupply), balance)) שלעולם לא נמשכת, או דרוש הפקדה מינימלית. - התקפת flash loan. הגדר תקופת סטייק מינימלית (נעילה) — 1-7 ימים. חלופה: הבשלה של תגמולים (שחרור ליניארי על פני N ימים). אפילו הבשלה של 24 שעות הופכת את ההתקפה ללא רווחית.
-
הטרדה דרך עדכוני סטייק. הפוך את
rewardPerTokenStoredל-O(1), הימנע מלולאות על מערכים. - אובדן דיוק. קנה מידה עם 1e18, צבור שאריות.
פרטי יישום של תגמולים מוגברים
לוגיקה פנימית: בעת סטייק/משיכה, חשב מחדש את `effectiveBalance` של המשתמש בהתבסס על משקל ה-veToken שלו. שמור מיפוי `effectiveBalances`. בעת עדכון `rewardPerToken`, השתמש בסכום היתרות האפקטיביות במקום totalSupply הגולמי.השוואת עלויות גז לתוכניות מורכבות
| פעולה | חווה בסיסית | רב-תגמולים | מוגבר |
|---|---|---|---|
| סטייק | 60k | 90k | 80k |
| משיכה | 55k | 85k | 75k |
| קבלת תגמול | 50k | 80k | 70k |
החוזים שלנו זולים ב-20-30% מיישומים טיפוסיים בזכות פריסת אחסון קומפקטית וחישובים מחוץ לשרשרת. לדוגמה, חיסכון של 30k גז לפעולה יכול לחסוך עד 5,000 דולר בחודש בעמלות על בריכה פעילה. חיסכון נוסף: שימוש במשתני VIRTUAL_TOTAL_SUPPLY = 1e18 מפחית את עלות הפריסה ב-15-20%.
איך אנחנו עובדים
- ניתוח (0.5 יום). קביעה: טוקן תגמול אחד או כמה, צורך בהגברה, נעילה מינימלית, שיטת מימון תגמולים (ידנית או אוטומטית).
- עיצוב ארכיטקטורה (0.5 יום). בחירת תבנית, חישוב rewardRate, עיצוב אירועים לאינדוקס.
- פיתוח (2-3 ימים). יישום חוזה עם בדיקות formant ובדיקות fuzzing על חשבונות.
- ביקורת פנימית (יום אחד). הרצת Slither, Mythril, Echidna. תיקון בעיות.
- פריסה (0.5 יום). סקריפט פריסה, אימות ב-Etherscan, העברת בעלות ל-multisig.
מה כלול בעבודה
- קוד מקור מלא של החוזים עם הערות ובדיקות (Foundry/Hardhat).
- דוח מפורט על אופטימיזציית גז עם מדידות.
- מדריך לשילוב subgraph (The Graph) לאירועים.
- תמיכה ל-30 יום לאחר הפריסה: התאמות פרמטרים, פריסה מחדש אם נדרש.
- תיאום עם ביקורת חיצונית (לפי בקשה).
למה להזמין פיתוח מאיתנו?
פיתחנו חוזים לפרוטוקולים עם TVL של עד 500 מיליון דולר וביצענו יותר מ-20 ביקורות פנימיות. הניסיון שלנו כולל שילוב עם אורקל Chainlink, גשרים בין-שרשרתיים (LayerZero, Wormhole), והגנה מפני MEV. פרויקטים שאנחנו תומכים בהם עוברים ביקורות חיצוניות ללא בעיות קריטיות. אנחנו מבצעים ביקורת חוזי נזילות לפרצות. קבלו ייעוץ לפרויקט שלכם כבר עכשיו — צרו קשר כדי להכין ארכיטקטורה והערכת עלות.







