כיצד אנו בונים פרוטוקולי ביטוח מבוזרים
פיתוח מערכת ביטוח מבוזרת מתחיל במציאת האיזון בין תמריצים, אימות קריפטוגרפי ועמידות בפני התקפות. Nexus Mutual איבדה פעם 8 מיליון דולר עקב מניפולציה בהצבעות תביעות — זו בעיית עיצוב מכניסטית מערכתית, לא באג ב-Solidity. אנו מתכננים פרוטוקולים העומדים בפני מניפולציה כלכלית, פגיעויות טכניות והתקפות ממשל. לצוות שלנו ניסיון של 10+ שנים בפיתוח בלוקצ'יין ומעל 50 חוזים חכמים בייצור, כולל פרויקטים עם TVL העולה על 100 מיליון דולר. כל חוזה עובר בדיקות Slither, Mythril ואימות פורמלי של אינווריאנטים עם Echidna.
מאגר הון וחיתום — פיתוח המערכת המבוזרת
הבסיס הוא מאגר הון של כספים מספקי LP הנוטלים סיכון תמורת חלק מהפרמיות. חיתום כיסוי ספציפי (למשל, ניצול חוזה חכם ב-Aave v3) יוצר תת-מאגר עם הון ייעודי ותמחור מבוסס סיכון. התמחור משתמש במודל Poisson: הסתברות תביעה λ כפול תשלום ממוצע μ. פרמיה = λ × μ × סכום_כיסוי × משך. הפרמטר λ מתעדכן בהתבסס על תביעות היסטוריות — ידנית דרך ממשל או דרך אורקל על-רשת עם נתוני ביקורת ואירועים.
אם פרמטרי סיכון מאוחסנים על-רשת ומתעדכנים דרך ממשל, נוצר וקטור — תוקף יכול לשדל להוריד את λ עבור פרוטוקול מסוים, לקנות כיסוי זול, לארגן ניצול ולקבל תשלום. הגנה: נעילת זמן על עדכוני פרמטרי סיכון ו-multisig עם מפתחות מפוצלים לפרמטרים קריטיים.
כיצד אנו מאמתים תביעות?
שלוש גישות לאימות, כל אחת עם פשרות. השוו ביניהן בטבלה:
| גישה | מהירות | עלות | עמידות בפני מניפולציה |
|---|---|---|---|
| אופטימית (בסגנון Kleros) | גבוהה (שעות) | נמוכה | בינונית (תלויה במשתתפים) |
| הצבעת Commit-reveal | בינונית (ימים) | גבוהה (גז להצבעה) | גבוהה (עם הגנה מפני flash loan) |
| טריגר פרמטרי (אורקל) | מיידי | מינימלית | גבוהה (הגנת TWAP) |
אימות אופטימי (בסגנון Kleros). תביעה נחשבת תקפה כברירת מחדל אם איש אינו מערער עליה בתוך תקופת_ערעור (למשל, 72 שעות). ערעור דורש הפקדה מהמערער. אם מערערים, זה עובר לבוררות דרך Kleros Court או דומה. מהיר וזול למקרים שאינם שנויים במחלוקת, אך פגיע ל"רוב שקט" — איש אינו מערער כי סיכון ההפקדה אינו משתלם.
הצבעת Commit-reveal על ידי מעריכים. מחזיקי טוקן דמוי NXM מפקידים טוקנים, מצביעים עם hashes סגורים, ואז חושפים. הצד עם הרוב מקבל תגמול, המיעוט מפסיד את ההפקדה (מכניקת נקודת Schelling). דורש השתתפות פעילה של הקהילה. פגיע להתקפות flash loan: לשאול טוקנים כדי להצביע, להצביע, להחזיר. הגנה מפני flash loan בהצבעה: הצבעת snapshot — כוח ההצבעה נקבע בבלוק N, ההצבעה מתרחשת בבלוק N+k. Flash loan לא עובד כי הטוקנים חייבים להיות בארנק לפני האירוע, שעדיין אינו ידוע.
טריגר פרמטרי (אורקל). תשלום מתרחש אוטומטית כאשר מתרחש אירוע על-רשת — למשל, אם מחיר אורקל Chainlink חורג >X% במשך Y בלוקים, או אם ה-TVL של הפרוטוקול יורד >50% ב-24 שעות. אין צורך בהצבעה, אך מכסה רק סיכונים הניתנים לתיאור פרמטרי. מתאים לכיסוי depeg, מפולות פירוק, ניצולי גשרים עם נתונים ציבוריים.
אנו בונים מערכת היברידית: טריגרים פרמטריים לתביעות קטנות אוטומטיות, ו-commit-reveal עם הגנה מפני flash loan לגדולות. גישה זו מעבדת 80% מהתביעות הקטנות אוטומטית תוך דקות, מהיר פי 10 ממערכות הצבעה טהורות.
מדוע יעילות הון חשובה לספקי LP
ספק LP מפקיד 100 ETH ומקבל cvETH — טוקן המייצג חלק במאגר. ניתן להשתמש ב-cvETH ב-DeFi (staking, בטחונות) כל עוד אין תביעות פעילות. כאשר תביעה מופעלת עבור סכום X, החוזה נועל את החלק המתאים של cvETH עד שתהליך האימות מסתיים. זה מבטל את בעיית ריצת הבנק: LP אינו יכול למשוך כספים עד שכל התביעות התלויות נגד חלקו במאגר נפתרות.
יישום טכני: vault ERC-4626 למאגר ההון + פונקציה מותאמת lockShares(address lp, uint256 amount) עם בקרת גישה המוגבלת לחוזה ClaimsManager. המבנה הפנימי משתמש ב-ERC-4626 עם הרחבה למנגנון הנעילה. ה-vault שומר מיפוי lockedShares, שגדל רק כאשר lockShares נקרא על ידי ClaimsManager. כאשר תהליך התביעה מסתיים, המניות נפתחות. זה מאפשר מעקב מדויק אחר הון זמין למשיכה.
ארכיטקטורת חוזה
InsuranceCore (proxy UUPS)
├── CapitalPool (ERC-4626)
├── CoverageManager (создание/управление покрытиями)
├── ClaimsManager (процесс клеймов)
│ ├── ParametricOracle (Chainlink + кастомные триггеры)
│ └── VotingEngine (commit-reveal)
├── PricingEngine (расчёт премий)
└── GovernanceTimelock (изменение параметров)Proxy UUPS עם אחסון namespaced ERC-7201 הוא חובה — כי הפרוטוקול ישודרג. ללא אחסון namespaced, השדרוג הראשון עם משתנה נוסף ישבור את מבנה האחסון של ClaimsManager.
אילו פגיעויות אנו סוגרים?
Reentrancy בתשלומים. ClaimsManager.processPayout() מבצע קריאה חיצונית לחוזה טוקן. אם הכיסוי נקוב ב-ERC-777 (עם hook של tokensReceived), תוקף יכול לקרוא רקורסיבית ל-processPayout לפני עדכוני מצב. פתרון: nonReentrant + Checks-Effects-Interactions קפדני, מצב התביעה משתנה לפני ההעברה.
מניפולציית אורקל דרך flash loan. טריגר פרמטרי על מחיר — תוקף לוקח flash loan, מוריד את המחיר ב-DEX, הטריגר מופעל, מקבל תשלום, מחזיר את ה-flash loan. הגנה: Uniswap v3 TWAP במקום מחיר ספוט, תקופת TWAP מינימלית של 30 דקות. החזקת מחיר מניפולטיבי ברשת הראשית למשך 30 דקות הופכת את עלות ההתקפה לעולה על כל סכום כיסוי סביר.
השתלטות ממשל. אם ממשל הפרוטוקול הוא דרך הצבעת טוקנים, והטוקן ניתן לקנייה או השאלה, ניתן ללכוד את הממשל. פתרון סטנדרטי: נעילת זמן על ביצוע הצעות (48-72 שעות), המעניקה לקהילה חלון תגובה. לפרמטרים קריטיים — multisig עם קוורום >50% + נעילת זמן. כתובת Guardian עם יכולת וטו למקרי חירום.
הבנת ביטוח פרמטרי
ביטוח פרמטרי הוא תשלום אוטומטי כאשר מתרחש אירוע אובייקטיבי על-רשת. לדוגמה, פרוטוקול מכסה הפסדים מניצול אם ה-TVL יורד מתחת לסף. טריגרים כאלה אינם דורשים הצבעה ומעובדים מיידית, מה שהופך אותם לאידיאליים לסיכונים סטנדרטיים. עם זאת, הם מכסים רק תרחישים מוגדרים בבירור. אנו משלבים אותם עם הצבעה למקרים מורכבים, ומשיגים איזון בין מהירות וגמישות.
תהליך הפיתוח — שלב אחר שלב
- ניתוח ועיצוב מכניסטי (1-2 שבועות). הגדרת סיכונים מכוסים, מבנה מאגר ההון, מכניקת תמחור, זרימת תביעות מלאה. כתיבת מפרט פורמלי עם אינווריאנטים: מאגר ההון מכסה תמיד לפחות 100% מהכיסוי הפעיל, תביעה אינה יכולה להיות משולמת פעמיים.
- פיתוח חוזים (3-4 שבועות). Solidity + Foundry. כל אינווריאנט הופך לבדיקה מבוססת מאפיינים ב-Echidna. בדיקות Fork משתלבות עם אורקלים של Chainlink ו-Uniswap TWAP על נתוני רשת ראשית אמיתיים.
- ביקורת פנימית (שבוע). Slither, Mythril, סקירה ידנית מול רשימת SWC. תשומת לב מיוחדת: כל נתיבי התשלום, כל נקודות עדכון פרמטרי הסיכון, כל המקומות עם קריאות חיצוניות.
- ביקורת חיצונית (2-4 שבועות). לפרוטוקולים עם TVL משמעותי — חובה. עלות ביקורת חיצונית נעה בדרך כלל בין 30,000 ל-60,000 דולר, דומה לעלות הפיתוח. התקציב נכלל בפרויקט מראש.
- Testnet + תגמול באגים (1-2 שבועות). פריסה ב-Sepolia/Arbitrum Goerli, פתיחת תוכנית פגיעות דרך Immunefi או Code4rena.
- פריסה ברשת הראשית. דרך Gnosis Safe multisig. תקרת TVL ראשונית — השקה רכה עם כיסוי מוגבל לאימות המכניקה בייצור.
עלות הפיתוח מחושבת באופן אישי לאחר דיון בארכיטקטורה ובדרישות. פרויקטים טיפוסיים מתחילים ב-50,000 דולר לפרוטוקול בסיסי ומתרחבים עם המורכבות.
אתגרים נפוצים במהלך ביקורת
במהלך הביקורת החיצונית, לעיתים קרובות מופיעות בעיות עם אינטגרציית אורקל והגנה לא מספקת מפני flash loan בהצבעה. אנו מתכוננים לכך על ידי הרצת בדיקות fuzz עם Echidna וסימולציית התקפות מראש. זה מפחית את מספר הממצאים ומאיץ את תהליך הביקורת.מה כלול
- תיעוד מלא של ארכיטקטורה ועיצוב מכניסטי
- קוד מקור של חוזים חכמים עם בדיקות יחידה ובדיקות מבוססות מאפיינים
- אינטגרציה עם אורקלים של Chainlink ו-Uniswap TWAP
- פריסת testnet ורשת ראשית עם multisig (Gnosis Safe)
- מדריך תפעול וניהול
- תמיכה ל-30 יום לאחר ההשקה (תיקוני באגים קריטיים)
הערכות לוחות זמנים
| שלב | משך | תוצאה |
|---|---|---|
| פרוטוקול בסיסי (טריגר פרמטרי + מאגר פשוט) | 4-6 שבועות | פרוטוקול עובד ב-testnet |
| מערכת מלאה (הצבעה, ממשל, שדרוגיות) | 2-3 חודשים | פריסה ברשת ראשית עם ביקורת |
| ביקורת חיצונית נוספת | 2-4 שבועות | דוח ביקורת |
לוחות הזמנים תלויים מאוד במורכבות העיצוב המכניסטי מראש. אנו לוקחים פרויקטים מקצה לקצה: מרעיון לרשת ראשית עם ביקורת. צרו קשר כדי לדון בפרויקט שלכם. הזמינו פיתוח ביטוח מבוזר עם ערבויות אבטחה.