הצעה לשיפור: KIP13
שכבה: קונצנזוס
תיאור: טיפול באחסון חולף
מחבר: מיכאל סאטון, coderofstuff
סטטוס: פעיל
מוטיבציה
מאז KIP9, טרנזקציות צורכות כעת שני סוגים של מסות, מסת חישוב ומסת אחסון. מסות אלו משמשות להגבלת צריכת משאבים מסוימת לכל בלוק (אחסון חישובי ואחסון מתמשך, בהתאמה). עם זאת, אף אחת מהן אינה מגבילה ישירות את גודל הבלוק, מבחינת בייט. אנו זקוקים לדרך להגביל את גודל הבייטים של הבלוקים ישירות כדי לקבל שליטה טובה יותר על האחסון ורוחב הפס הגרועים ביותר המשמשים את הצומת.
הקשר
עומסי מטען הופעלו ב-Testnet 11, הפועל במהירות של 10 בלוקים לשנייה (BPS). בתים של מטען מחויבים בגרם לבייט. בקצב של 10 BPS ועם מגבלת מסת הבלוק הנוכחית של 500,000 גרם, באמצעות שימוש במטענים עצומים, ייתכן שאחסון בתקופת הגיזום יוכל לצרוך קרוב ל-1TB של נתונים. כדי להדגים זאת, אנו משתמשים בחישוב הבא:
דרישה ממפעילי צמתים וממשתמשים רגילים שמפעילים צמתים שיהיה להם קרוב ל-1TB פנוי להפעלת צמתים היא בקשה גדולה. עלינו לשקול להפחית את השימוש הגרוע ביותר הזה.
עסקאות אופייניות
אלו הן סוגי העסקאות הנפוצות ביותר שמשתמשי הרשת מבצעים. צריכה טיפוסית של עסקה 1:2 (קלט 1, 2 פלטים) נראית כך
| שדה | נתונים |
|---|---|
| גודל | 316 בתים (bytes) |
| מסת חישוב בפועל | 2036 גרם (grams) |
| *טרנזקציות בשנייה (TPB) | 245 |
| **גודל בלוק כולל | 77,420 בתים (bytes) |
*העסקאות לכל בלוק אם הוא היה מלא לחלוטין בעסקאות כאלה בלבד
**גודל הבלוק הכולל שנצרך אם הבלוק היה מלא בעסקאות כאלה בלבד
באופן דומה, צריכת 2:2 עסקאות (2 כניסות, 2 יציאות) נראית כך
| שדה | נתונים |
|---|---|
| גודל | 434 בתים (bytes) |
| מסת חישוב בפועל | 3154 גרם (grams) |
| *טרנזקציות בשנייה (TPB) | 158 |
| **גודל בלוק כולל | 68,572 בתים (bytes) |
לבסוף, עסקת KRC20 טיפוסית היא בדרך כלל עסקה 1:1 או 1:2. אורך החתימה שלה הוא בערך 261 בתים.
| שדה | נתונים |
|---|---|
| גודל | 429 בתים (bytes) |
| מסת חישוב בפועל | 1819 גרם (grams) |
| *טרנזקציות בשנייה (TPB) | 247 |
| **גודל בלוק כולל | 117,546 בתים (bytes) |
אם נחבר את הגדלים הללו לאורך הגיזום המקסימלי המדויק (גיזום + עומק סופיות) של 10BPS, נקבל גדלי דיסקים במקרה הגרוע ביותר של 120GB, 106GB ו-182GB בהתאמה.
אם נעגל את זה כלפי מעלה ל-125kb לבלוק, נקבל שימוש במקרה הגרוע ביותר של 193GB, שהוא הרבה יותר סביר ונגיש מדרישת המקרה הגרוע ביותר שחושבת בתחילה של 775GB.
בהתחשב בנתונים אלה, נוכל לקבוע את המטרות כדלקמן:
- לשמור על העלויות הנ"ל עבור עסקאות אופייניות (כדי שעדיין נתאים את 150-250 TPB)
- להגביל את גודל הבלוק ל-125KB
ההצעה שלנו
שינויים בקונצנזוס
יישום check_block_mass שהוצג ב-KIP9 בודק האם העסקאות בתוך בלוק מתאימות למגבלת מסת הבלוק. הוא עוקב אחר מסת האחסון ומחשב סכומי מסה באופן עצמאי, ומבטיח שכל מסה כוללת תיכנס למגבלת מסת הבלוק. אנו מציעים את השינויים הבאים:
שינוי 1 – מסה חדשה: מסת אחסון חולפת
הכנס מסה חדשה בשם transient_storage_mass. נשתמש בזה כדי להגביל את גודל הבלוק ל-125KB באופן הבא:
ה-4 לעיל נובעים ישירות מניסיון להקטין את גודל הבלוק ל-125KB (500,000 מסה / 125,000 בתים = 4 מסה / בתים)
שינוי 2 – מעקב עצמאי אחר מסת בלוקים
נזכיר ש-KIP9 הציג מעקב עצמאי אחר compute_mass ו-storage_mass עבור מגבלות מסת בלוקים. שינוי זה נועד להוסיף את transient_storage_mass כמסה נוספת שיש לעקוב אחריה באופן עצמאי.
שינויים בממפול
שינוי 1 – מפתחות שיעורי עמלה
ה-calculated_transient_storage_mass יחושב מראש ויהיה נגיש בתוך ה-mempool. מפתחות תעריפי העמלות יעודכנו כך שיכללו את calculated_transient_storage_mass במסה שלו באמצעות האופרטור max.
כלומר, מפתח תעריפי העמלות מבוסס על מסה כאשר מסה = max(compute_mass, storage_mass, transient_storage_mass).
אופטימיזציה של מנגנון בחירת עסקאות ה-mempool (מעקב אחר כל מסה באופן עצמאי) אינה במסגרת KIP13
שינוי 2 – אימותים
בכל מקום ב-mempool שבו מסת חישוב העסקאות מאומתת (כגון מול גודל סטנדרטי), מסה כזו תשלב transient_storage_mass דרך האופרטור max.
תאימות לאחור
שובר את כללי הקונצנזוס, דורש hardfork
גילוי נאות
נכתב במקור על ידי מיכאל סאטון, coderofstuff
האמור לעיל מובא לצורכי ידע כללי בלבד ואינו מהווה ייעוץ פיננסי, השקעות, מס, או המלצה למסחר בנכסים דיגיטליים או כל ייעוץ אחר ואינו תחליף להתייעצות עם גורם מוסמך.
הכותב / מתרגם ומערכת האתר אינם אחראים לכל נזק, הפסד או טעות הנובעים מהסתמכות על המידע המוצג כאן או במסמכים של צד ג' שתורגמו לעברית.
המסמך תורגם לעברית על ידי צוות kaspa.co.il למען הקהילה
במידה ומצאתם טעות בתרגום נשמח אם תעדכנו אותנו בטופס יצירת קשר
