Interchain Security של Cosmos: ספקים, צרכנים, תגמולים ו-Slashing

Interchain Security (ICS) מחבר שרשראות Cosmos נפרדות באמצעות פרוטוקול Inter-Blockchain Communication (IBC). שרשרת הספק מנהלת מערך מאמתים, ושרשרת הצרכן נעזרת במאמתים זכאים מתוכו כדי להציע ולאשר בלוקים משלה. לכל אחת עדיין יש מכונת מצבים, ספר חשבונות, עמלות, אסימון, ממשל וכללי יישום נפרדים.

״אבטחה משותפת״ אינה פירושה שהמטבעות של מי שהאציל הועברו לצרכן. ה-ATOM שהוקצה נשאר נעול לפי כללי ה-staking של שרשרת הספק. הצרכן מקבל השתתפות של מאמתים הנתמכת בסטייק הזה, והוא יכול לדווח לספק על ראיות להפרות מסוימות. לכן יתרת ארנק, אסימון של הצרכן וסטייק נעול אצל הספק הם דברים שונים.

ICS גם אינו רק גשר לאסימוני IBC. IBC מספק תקשורת מאומתת בין שרשראות, ואילו ICS משתמש ביישום ייעודי לאימות בין־שרשרתי שמעביר עדכונים של מערך המאמתים וראיות להפרות. העברת אסימון יכולה להשתמש ב-ICS-20 בלי לשתף מערך מאמתים. שיתוף מאמתים גם אינו הופך כל יישום או אסימון בצרכן לבטוח.

סקירה של Interchain Security · מונחי Interchain Security

הצרכן אינו חייב לקבל את כל מערך המאמתים של הספק. Partial Set Security (PSS) מאפשר לבחור תת־קבוצה. הגדרת Top N בוחרת מאמתים לפי שיעור מוגדר מכוח ההצבעה אצל הספק. בהגדרת opt-in מאמתים זכאים בוחרים להצטרף לצרכן מסוים. צריך לבדוק את ההגדרה הפעילה כדי לדעת איזה כלל חל.

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

שרשראות Top N דורשות בדרך כלל אישור ממשל של הספק, משום שחלק מהמאמתים עשויים להידרש להשתתף. לעומתן, ניתן להפעיל שרשראות opt-in בלי לחייב מאמתים. אל תניחו מהו מסלול ההשקה רק משום שמדובר ב״שרשרת Cosmos״. בדקו את מזהה השרשרת ואת מזהה הצרכן, את מצב ההשקה, את כללי Top N או opt-in, את פרמטרי ה-power shaping ואת הליך הממשל העדכני; התיעוד והתכונות משתנים.

Partial Set Security · Power shaping · Permissionless ICS

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

כללי ההשתתפות קובעים מי צריך להפעיל צומת צרכן. ב-Top N ההשתתפות עשויה להיות תלויה בכוח ההצבעה אצל הספק ובסף שנקבע; ב-opt-in המאמת בדרך כלל בוחר להשתתף. מגבלות כוח ורשימות עשויות לשנות את המערך הסופי. המאמתים צריכים לבדוק לכל צרכן את תנאי הזכאות, שיוך המפתח, hash של הבינארי, מועד ההפעלה ודרישות הניטור.

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

מדריך המאמתים ושלבי ההפעלה · שיוך מפתחות

כאשר הסטייק או הזכאות אצל הספק משתנים, ייתכן שצריך לעדכן גם את מערך המאמתים של הצרכן. ICS שולח שינויים במערך דרך ערוץ Cross-Chain Validation (CCV). Relayer מעביר הודעות בין השרשראות; כל שרשרת מאמתת את המצב לפי הפרוטוקול ומיישמת את השינוי שלה. ה-relayer אינו מאמת של הצרכן ואינו מחליט אילו חתימות תקפות.

התיאום הזה עשוי לסבך את מועד ההצטרפות והיציאה לעומת שרשרת עצמאית. תכנון CCV הישן מתאר חבילות לשינוי מערך המאמתים והודעות maturity להגנה על unbonding בין שרשראות. המימוש התפתח מאז, ולכן מאמר כללי על ICS אינו יכול להבטיח תוספת זמן אחידה לביטול האצלה אצל הספק. ההתנהגות תלויה בגרסת הפרוטוקול ובהגדרות השרשרת.

לפני שינוי או משיכת האצלה, קראו את התיעוד העדכני של הספק והצרכן ובדקו רשומות unbonding שטרם הבשילו. הבדילו בין תקופת ה-staking הרגילה לבין תיאום נוסף של ICS. גם עיכוב relayer או client לא מעודכן עלולים לעכב חבילה בלי לשנות את הכלל הבסיסי.

סקירת CCV במפרט IBC · מדריך המאמתים

הצרכן יכול לשלוח לספק ראיות להתנהגות פסולה של מאמת. תיעוד ICS מבדיל בין downtime לבין equivocation כגון חתימה כפולה. כללי השרשרת, גרסת הפרוטוקול ופרמטרי ההפרה של הצרכן קובעים כיצד מטפלים בראיות; התוצאה עשויה להיות jail, קיצוץ סטייק או שניהם.

אין שיעור ענישה אוניברסלי לכל השרשראות. גם התיעוד הרשמי העדכני אינו מתאר באופן אחיד את תוצאת ה-downtime: מדריך המאמתים מתאר jail אצל הספק בלי קיצוץ, ואילו דף ה-slashing מתאר jail וקיצוץ לפי הפרמטרים של הצרכן. לכן אין להסיק תוצאה כספית מהמונח ״ICS״ בלבד; בדקו את המימוש, התצורה והליך הטיפול בראיות בשרשרת המסוימת. ראיה תקפה לחתימה כפולה יכולה להביא לקיצוץ, jail ו-tombstone אצל הספק.

אם הספק מקצץ סטייק, המאמת והמאצילים עלולים לחלוק בהשפעה הכלכלית לפי כללי ה-staking של הספק. Jail עשוי להסיר את המאמת מהמערך הפעיל של הספק ובעקבות זאת גם ממערכי הצרכנים. אל תניחו שהפרה בצרכן פוגעת רק בתגמולים באסימון של הצרכן.

Slashing שמתחיל בצרכן · מדריך מאמתי Interchain Security

צרכן יכול להקצות חלק מוגדר מתגמולי הבלוק או מהעמלות שלו לספק בתמורה לאבטחה. הנכסים נשלחים מעת לעת דרך ערוץ העברת IBC. הספק מקבל רק denominations שאושרו ברשימה שלו, והזכאות תלויה בכללי הצרכן. לפי התיעוד העדכני, מאמת עשוי להידרש להשתתף ברציפות במשך מספר epochs מוגדר לפני קבלת תגמולים; לאחר מכן מאצילים יכולים לחלוק בהם לפי כללי החלוקה של הספק.

דוגמה היפותטית פשוטה: נניח שהצרכן צבר בתקופה 12,000 יחידות של עמלות ותגמולי אינפלציה זכאים, והממשל קבע שחלק הספק הוא 25%. החשבון נותן 3,000 יחידות שנשלחות לכיוון מאגר תגמולי הספק. הוא אינו קובע את ערכן בדולרים, הקצאה סופית למאמת, מועד חלוקה או תשואה עתידית. אם חלה מגבלת כוח הצבעה, משקל החלוקה עשוי להתבסס על הכוח לאחר ההתאמה בצרכן ולא על כוח המאמת אצל הספק.

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

כללי חלוקת התגמולים · תגמולי מאמתים בשרשרת צרכן

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

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

״מאובטח על ידי Cosmos Hub״ הוא נקודת פתיחה לבדיקה, לא דירוג סיכונים מלא. בררו מי הספק, אילו מאמתים משתתפים, איך כוח ההצבעה שלהם מעוצב, אילו ראיות גוררות קיצוץ, אילו תגמולים נשלחים ומהו תהליך היציאה או המעבר. האבטחה קשורה לתצורה ולתקופת פעילות מסוימות.

מונחים וסוגי אבטחה בין־שרשרתית · ממשל שרשרת צרכן

התחילו בזיהוי ה-chain ID, ה-consumer ID והספק הנכונים. ודאו אם חל Top N או opt-in, אם מגבלות כוח או רשימות משנות את מערך המאמתים, ואם הרשימה שפורסמה משקפת את העדכון האחרון. מספר המאמתים לבדו אינו מראה איך כוח ההצבעה מתחלק.

אם אתם מאמתים או מאצילים, בדקו אם המאמת חייב לבצע opt-in, איזה consensus key משויך לצרכן, אם מופעלת הבינארי הנכונה ואיך מטופלים downtime וחתימה כפולה. קראו את פרמטרי ה-jail וה-slashing הפעילים. בהאצלה, הבחינו בין סטייק ספק נעול לבין תגמולי צרכן שמוצגים בארנק.

לבסוף בדקו את רשימת ה-denom המאושרים, מספר ה-epochs לזכאות, כללי החלוקה והעמלה, סמכויות הממשל של הצרכן, מצב ה-relayer וה-client והליך ה-undelegation או ה-changeover העדכני. אל תערבבו את הפרטים האלה עם staking אצל הספק בלבד או עם העברת אסימון; אלה פעולות שונות.

[Delegation ו-slashing ב-Cosmos Hub](/learn/cosmos-staking-delegation-unbonding-slashing-validator-commission-explained) · [העברות IBC וסיכוני relayer](/learn/cosmos-ibc-transfer-clients-channels-packet-timeouts-relayer-risks-explained) · Staking בקריפטו מול הלוואות DeFi

מקורות ראשוניים: סקירת Interchain Security; מונחים; Partial Set Security; Power shaping; חלוקת תגמולים; slashing ביוזמת הצרכן; מדריך המאמתים; מפרט CCV של IBC.