הצעה לשיפור כספא KIP14

הצעה לשיפור: KIP14
שכבה: קונצנזוס
תיאור: הקרשנדו מיזלוג קשיח "הארד פורק"
מחבר: מיכאל סאטון
סטטוס: פעיל

תקציר KIP14

KIP14 מציע את יישום ה-Crescendo Hardfork עבור רשת כספא, תוך פירוט שינויי הקונצנזוס ואסטרטגיית המעבר עבור רכיבים שונים. השינוי העיקרי ב-KIP זה הוא העלייה בבלוקים לשנייה (BPS) מ-1 ל-10, התאמה משמעותית בעלת השלכות רחבות היקף על ביצועי הצומת וכן על דרישות האחסון ורוחב הפס. זה מחייב עדכונים של פרמטרים רבים של קונצנזוס, ובמקרים מסוימים, חשיבה מחדש על מנגנונים קיימים כדי להבטיח שהם יישארו יעילים בקצב הבלוקים המוגבר (למשל, חלון ה-DAA הדליל שהוצג ב-KIP-4).

בנוסף, hardfork זה כולל את הפעלת שיפורים משמעותיים אחרים ב-Kaspa. החל מ-KIP9, המציג מנגנון קריטי לניהול והפחתת התנפחות מצבים, ובכך מווסת דרישות אחסון מתמשכות. זה משלים את KIP13, המווסת את דרישות האחסון החולפות עבור צומת. רכיב עיקרי נוסף המופעל ב-hardfork זה הוא KIP10, המציג קודי הפעלה חדשים של התבוננות פנימית למנוע הסקריפטים של Kaspa. באמצעות התבוננות פנימית כזו, קודי הפעלה אלה מאפשרים את מושג האמנה, המאפשר בקרות מתקדמות על עסקאות, כולל תכנון של כתובות נוספות התומכות במיקרו-עסקאות ומשלימות את KIP-9.

הקשוח הזה מסמן גם את סגירת KIP-1, ה-Kaspa Rust Rewrite. שיפורי הביצועים שאפשרה Rusty Kaspa (RK) מספקים את הבסיס הדרוש לתמיכה בשדרוג זה, ומאפשרים לרשת להתמודד עם הדרישות המוגברות של 10 BPS ומעלה.

מוטיבציה

ה-Crescendo Hardfork הוא שדרוג פרואקטיבי לרשת Kaspa, שהתאפשר בזכות RK. עם TN11 – רשת בדיקה הפועלת במהירות של 10 BPS – הפועלת ביציבות במשך למעלה משנה, הרשת הוכיחה את מוכנותה למעבר זה. על ידי הגדלת הקיבולת והמהירות, שדרוג זה מציב את Kaspa כדי לתמוך בביקוש הצפוי מטכנולוגיות מתפתחות, כולל שכבות חוזים חכמים המופעלות באמצעות עיצוב גשר ZK המתמשך [1].

כל השינויים המתוארים ב-KIP14 (למעט KIP-13 ו-KIP-15) כבר יושמו ונבדקו ב-TN11, ומספקים תובנות חשובות לגבי ביצועיהם ויציבותם. תוצאות אלו מבטיחות שהשינויים המוצעים מוכנים לפריסה ברשת הראשית של Kaspa.

מפרט

שינויים בקונצנזוס

1. שינויים הקשורים ל-BPS

להלן פירוט השינויים הקשורים אך ורק לעלייה ב-bps.

1. הגדלת BPS מ-1 ל-10:

• שינוי זה נשלט על ידי פרמטר קונצנזוס בשם target_time_per_block (מילישניות), אשר שולט בזמן הצפוי בין בלוקים. כדי להגדיל את ה-bps מ-1 ל-10, ה-target_time_per_block יופחת מ-1000 אלפיות השנייה ל-100 אלפיות השנייה.
• התאמה זו תגרום בתורה לאלגוריתם התאמת הקושי להפחית את הקושי פי 10, ובכך להאיץ את יצירת הבלוקים פי עשרה. פרטים נוספים על מעבר זה מסופקים להלן תחת "אסטרטגיית מעבר".

2. כוונון מחדש של פרמטר Ghostdag K:

• קיצור זמן הבלוק מוביל לשיעור גבוה יותר של בלוקים מקבילים. כתוצאה מכך, יש לכייל מחדש את פרמטר Ghostdag K, שהוא פונקציה של 2 λ D (כאשר λ הוא קצב הבלוק ו-D הוא גבול העיכוב האפריורי), כדי לשמור על אבטחת הרשת בהתאם לנוסחת Ghostdag (ראה משוואה 1 מסעיף 4.2 של מאמר PHANTOM-GHOSTDAG [2]).
• כאשר D = 5, δ = 0.01, ה-Ghostdag K החדש מחושב מחדש ל-124 בהתבסס על זנב פואסון שנחתך שם.

3. קנה מידה של פרמטרים קונצנזוס מבוססי זמן:

מספר פרמטרים המוגדרים באופן מושגי על ידי משך זמן אך מיושמים באמצעות ספירת בלוקים חייבים להיות מדורגים עם ה-bps החדש:

• עומק סופיות (ϕ): בעבר הוגדר למשך זמן של 24 שעות בקצב של 1 bps (86,400 בלוקים), כעת הוא יתאים למשך זמן של 12 שעות בקצב של 10 bps (432,000 בלוקים).
• עומק המיזוג (M): מוגדר למשך שעה אחת, כעת הוא יגדל מ-3600 בלוקים בקצב של 1 bps ל-36,000 בלוקים בקצב של 10 bps.
• עומק גיזום: מחושב כ

איפה ש

• ϕ: עומק סופיות
• M: גבול עומק מיזוג
• L: מגבלת גודל של מערך מיזוגים (ראה להלן)
• K: גוסטדאג K
• נוסחת עומק הגיזום מספקת גבול תחתון, אך ניתן לקבוע את תקופת הגיזום בפועל ארוכה יותר. על ידי הוספת הפרמטרים המותאמים, הגבול התחתון מחושב כ-627,258 בלוקים, המייצגים כ-17.4238 שעות. אנו מציעים לעגל זאת כלפי מעלה ל-30 שעות לשם פשטות ויישום מעשי. תקופה של 30 שעות קרובה יותר לתקופת הגיזום הנוכחית של רשת הרשת הראשית (~51 שעות) ותואמת באופן הדוק את הערך בו נעשה שימוש והשוו לאורך TN11 (~31 שעות).
• מועד בגרות של מטבעות: במקור הוגדר כ-100 שניות או ~100 בלוקים ב-1 bps, כעת זה יתאים ל-1000 בלוקים ב-10 bps.

4. קנה מידה שמרני של פרמטרים המשפיעים על ביצועים:

• מספר הורי בלוק מקסימלי: גדל מ-10 ל-16. בהתבסס על נתוני TN11 רציפים, 16 נשאר הרבה מעל הממוצע של קצות DAG, מה שמבטיח שכל הקצות מתמזגות בדרך כלל על ידי בלוקים עוקבים.
• מגבלת גודל מערך המיזוג (L): גדלה מ-180 ל-248 (2K) כדי להתאים את ה-bps הגבוה יותר תוך שמירה על יעילות האחסון.

5. התאמות למנגנון התגמול של Coinbase:

• התוכנית המתוארת להלן שומרת על מערכת התגמולים ולוח הזמנים של הפליטה שלמים במדויק על ידי העברה רעיונית של התגמול הנוכחי לכל בלוק לתגמול לשנייה בעל ערך שווה.
• באופן ספציפי, טבלת התגמולים תמשיך להתמפות מחודשים לתגמולים, אך התגמול נחשב כעת לתגמול לשנייה. כדי לחשב את התגמול לכל בלוק, התגמול לשנייה מחולק ב-bps.
• יש לנקוט משנה זהירות לחישוב נכון של חודש הפליטה הנוכחי. בעבר, ציון ה-DAA (בעצם ספירת בלוקים) ממופה ישירות לשניות מכיוון שהבלוקים נוצרו בקצב של בלוק אחד לשנייה. לאחר hardfork, עם 10 bps, יש להשתמש בציון ה-DAA בעת ההפעלה כדי לשמור על ספירה מדויקת של שניות.
• שני ערכים מרכזיים משמשים בחישוב חודש הסובסידיה:
  א. deflationary_phase_daa_score: קבוע מכללי הקונצנזוס הנוכחיים המסמן את תחילת שלב הדפלציה.
  ב. crescendo_activation_daa_score: ציון ה-DAA בזמן הפעלת Crescendo, אשר ייקבע כחלק מהטמעת ה-hardfork.
• הקוד הבא מתאר את השינוי הקבוע הנדרש בחישוב חודש הסובסידיה. לאחר מכן ניתן להשתמש בערך subsidies_month המוחזר כמקודם כדי לחלץ את התגמול מטבלת הסובסידיה לפי חודש.

2. הפעלת מערכות KIP קודמות

הפעלת KIP-4: DAA דליל וחלונות זמן חציוניים:

• מעבר לאלגוריתם התאמת קושי (DAA) דליל וחלונות זמן חציוני (MT) דלילים תוך שמירה על משך הזמן הקודם שלהם (2641 שניות עבור DAA; 263 שניות עבור זמן חציוני).
• גודל החלונות הדלילים הללו (בבלוקים) נקבע על ידי חלוקת משך הזמן שלהם במרווחי הדגימה שנבחרו. עבור DAA, בחרנו מרווח דגימה של 4 שניות, וכתוצאה מכך גודל חלון של ⌈2641/4 ⌉ = 661. עבור MT, בחרנו מרווח דגימה של 10 שניות, וכתוצאה מכך ⌈263/10⌉ = 27. ראוי לציין שגדלי חלונות אלה אינם תלויים כעת ב-bps.
• מרווחי דגימה מותאמים לפי bps כדי לחשב קצבי דגימה של בלוקים:

• KIP-9 (מסת אחסון): מציג נוסחת מסת אחסון כדי להפחית ולסדר את צמיחת מערך UTXO בתנאים אורגניים וגם בתנאים עוינים.
• KIP-13 (מסת אחסון חולפת): מיישם מסת אחסון חולפת כדי לווסת את השימוש באחסון לטווח קצר.
• KIP-10 (שיפורי מנוע סקריפטים): מציג התבוננות פנימית ישירה בתוך מנוע הסקריפטים, ומאפשר בקרות מתקדמות בנוגע להתחייבויות ובקרות עסקאות.
• KIP-15 (התחייבות להזמנת עסקאות קנונית רקורסיבית): משנה את שם שדה הכותרת AcceptedIDMerkleRoot ל-SequencingCommitment – מחושב כ-hash(SelectedParent.SequencingCommitment, AcceptedIDMerkleRoot), כאשר AcceptedIDMerkleRoot נגזר באמצעות סדר הקונצנזוס הקנוני של טרנזקציות מקובלות. שינוי זה מאבטח את סידור הטרנזקציות עבור רשתות L2 – ומאפשר עיצובים כמו Accepted Transactions Archival Node (ATAN) (הערה: המימוש הנוכחי שמר על שם השדה המקורי).

4. נוספים

להלן פירוט שינויים קלים נוספים שאינם מצדיקים KIP נפרד.

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

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

שדה המטען כבר כלול ב-hash וב-id של העסקה ביישומים הנוכחיים של Kaspa. עם זאת, לקוחות אחרים עשויים להניח ששדה זה תמיד ריק ועליהם לאמת את היישומים שלהם כדי להתחשב בכך.

שינוי זה מאפשר יישומים ראשוניים של חוזים חכמים בשכבה השנייה, תוך מינוף Kaspa לצורך ריצוף וזמינות נתונים ללא פונקציונליות סליקה עדיין. סיכוני שימוש לרעה או ספאם מופחתים על ידי תקנת אחסון זמני שהוצגה ב-KIP-13. פונקציונליות זו כבר יושמה ב-RK והופעלה עבור TN11 (בקשת משיכה).

ספירת sigop בזמן ריצה
כדי לטפל בחוסר יעילות בספירת sigop סטטית, מנוע הסקריפטים סופר כעת sigops בזמן ריצה. לדוגמה, בסקריפטים התומכים בכתובות נוספות (ראה KIP-10 עבור פרטי הוצאות לווה), הסריקה הסטטית הקודמת עבור opcodes של SigVerify ענישה עסקאות על ידי חיוב עבור sigops ללא קשר לביצוע. עדכון זה סופר רק sigops שבוצעו, מה שמפחית את מסת העסקאות והוריד עמלות, תוך שמירה על תאימות לאחור על ידי מתן אפשרות לעסקאות להתחייב לספירת sigop שעומדת או עולה על ערך זמן הריצה.

אסטרטגיית מעבר

אסטרטגיית הפעלה כללית

ב-Kaspa, ציון ה-DAA של בלוק קובע בדרך כלל מתי מופעלים כללי forking. עם זאת, שינויים מסוימים בקונצנזוס יכולים להשפיע על ציון ה-DAA של הבלוק עצמו, וכתוצאה מכך נוצרת לוגיקה מעגלית. דוגמה בולטת אחת היא הפעלת KIP-4 (חלון DAA דליל), אשר משנה את אופן חישוב ציון ה-DAA. כדי להימנע ממעגל זה, אנו מציעים להשתמש בציון ה-DAA של ההורה שנבחר של הבלוק כדי לקבוע את ההפעלה. תרחיש נוסף שבו יש לקחת בחשבון את ציון ההורה שנבחר הוא העלייה ב-Ghostdag K, מכיוון ש-Ghostdag מחושב לפני שציון ה-DAA ידוע.

כדי לפשט את היישום, אנו מציעים להרחיב שיטה זו לכל השינויים הקשורים ל-header, הכוללים את כל השינויים הקשורים ל-bps (לא כולל תגמולי מטבעות).

עבור KIPs 9, 10 ו-13, כמו גם שינויים בהפעלת payload ו- coinbase תגמולים (כולם קשורים לגוף הבלוק), אנו ממליצים להשתמש בגישה הרגילה והישירה יותר של הסתמכות על ציון ה-DAA של הבלוק עצמו.

התמודדות עם קושי בהסתגלות במהלך המעבר

ב-Kaspa, ציון ה-DAA של בלוק קובע בדרך כלל מתי מופעלים כללי forking. עם זאת, שינויים מסוימים בקונצנזוס יכולים להשפיע על ציון ה-DAA של הבלוק עצמו, וכתוצאה מכך נוצרת לוגיקה מעגלית. דוגמה בולטת אחת היא הפעלת KIP-4 (חלון DAA דליל), אשר משנה את אופן חישוב ציון ה-DAA. כדי להימנע ממחזור זה, אנו מציעים להשתמש בציון ה-DAA של ההורה שנבחר של הבלוק כדי לקבוע את ההפעלה. תרחיש נוסף שבו יש לקחת בחשבון את ציון ההורה שנבחר הוא העלייה ב-Ghostdag K, מכיוון ש-Ghostdag מחושב לפני שציון ה-DAA ידוע.

כדי לפשט את היישום, אנו מציעים להרחיב שיטה זו לכל השינויים הקשורים ל-header, הכוללים את כל השינויים הקשורים ל-bps (לא כולל תגמולי מטבעות).

עבור KIPs 9, 10 ו-13, כמו גם שינויים בהפעלת payload ו- coinbase תגמול (כולם קשורים לגוף הבלוק), אנו ממליצים להשתמש בגישה הרגילה והישירה יותר של הסתמכות על ציון ה-DAA של הבלוק עצמו.

טיפול בהתאמת קושי במהלך המעבר
בעת המעבר ל-10 bps, מתעורר אתגר משמעותי מכיוון שחלון ה-DAA לאחר ההפעלה משתרע הן על תקופות ה-1 bps והן על תקופות ה-10 bps. נדרשת שיקול דעת מדוקדק כדי למנוע ירידה גדולה מדי בקושי הנגרמת עקב קצב ייצור בלוקים איטי יותר בתחילת החלון. יתר על כן, אימוץ KIP-4 מציג שכבה נוספת של מורכבות, שכן אנו עוברים מחלון DAA מלא לחלון דליל.

פתרון מוצע

כדי להתמודד עם אתגרים אלה, מוצעת הגישה הבאה:

• איפוס חלון ה-DAA: יש לאפס את חלון ה-DAA בנקודת ההפעלה ועליו לכלול רק בלוקים שנכרו לאחר ההפעלה.
• חישוב קושי עבור בלוקים ראשוניים:
• חלון ריק: כאשר החלון ריק (כלומר, ההורה שנבחר נכרה לפני ההפעלה), יש להגדיל את יעד הקושי פי 10, המשקף את ה-bps החדש. התאמה זו מפחיתה את כמות העבודה הנדרשת למציאת בלוק פי עשרה, וכתוצאה מכך עלייה פי עשרה בקצב הבלוק עם אותו קצב גיבוב.
• חלון חלקי: עבור בלוקים שבהם החלון מכיל כמה בלוקים לאחר ההפעלה אך עדיין לא הגיע לגודל המינימלי הנדרש, יש להשתמש ברמת הקושי של ההורה שנבחר כפי שהיא.
• גודל חלון מינימלי: יש להגדיר את גודל החלון המינימלי לערך בטווח של 60-661 בלוקים, המקבילים לכ-4-44 דקות, כדי לאזן בין יציבות ותגובתיות.

כוונון נקודת גיזום

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

כללים מחמירים לגבי נקודות גיזום

• סמנו את Bn כבלוק בעומק n בשרשרת שנבחרה. שימו לב שהגדרת העומק נותרה ללא שינוי מהכללים הנוכחיים.
• עבור כל בלוק B שנכרה לאחר ההפעלה, יהי pre(B) יסמן את נקודת הגיזום של אב השרשרת האחרון שלו שנכרה לפני ההפעלה.
• סמנו את עומק הגיזום החדש כ-P. נקודת הגיזום עבור בלוק B לאחר ההפעלה, המסומן כ-π(B), נקבעת על ידי הכלל הבא: π(B) : = max(pre(B),BP).

תודות

אני מודה ל-@coderofstuff על עזרתו בניהול ה-hardfork המפורט ב-KIP הזה, ולכל המפתחים והחוקרים המרכזיים של Kaspa על עבודתם החרוצה לקראת מאמץ אדיר זה.

הפניות

• [1] L1<>L2 bridge design
• [2] PHANTOM GHOSTDAG: A Scalable Generalization of Nakamoto Consensus
• [3] Prunality Analysis

גילוי נאות

נכתב במקור על ידי מיכאל סאטון, coderofstuff

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

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

המסמך תורגם לעברית על ידי צוות kaspa.co.il למען הקהילה
במידה ומצאתם טעות בתרגום נשמח אם תעדכנו אותנו בטופס יצירת קשר