הצעה לשיפור: KIP3
שכבה: קונצנזוס.
תיאור: דגימת בלוקים עבור DAA יעיל עם BPS גבוה
מחבר: שי ויבורסקי, מייקל סאטון.
סטטוס: נדחה.
מוטיבציה
אלגוריתם התאמת הקושי דורש שמירה, עבור כל בלוק, על רשימה של N בלוקים בעבר עם המשקל המצטבר הגבוה ביותר. בעת אימות בלוק יש לעבור על רשימה זו כדי לחשב את הכמויות השונות הנדרשות לחישוב יעד הקושי. מכיוון שאורך חלון הקושי תואם לשיקולים בזמן אמת, גודל חלון הקושי הרצוי נמדד בשניות, לא בבלוקים. משמעות הדבר היא שאם נגדיל את קצב הבלוקים בגורם של R, נגדיל את מורכבות התאמת הקושי ב-R^2 (הגורם הראשון נובע מהעובדה שאימות כל בלוק דורש פי R יותר צעדים, והגורם השני הוא מכיוון שבלוקים מופיעים פי R מהר יותר).
זה ממותן חלקית על ידי האופי ההדרגתי של חלון הקושי. כמו הקבוצה הכחולה, כל בלוק יורש את חלון הקושי של ההורה הנבחר שלו ולאחר מכן מתקן אותו בהתאם לבלוקים באנטי-קונוס שלו. פעולה זו ממירה חלק מתקורת המעבד לתקורת זיכרון RAM, אשר גם היא תגדל פי R.
כדי להפחית את התקורה, יישום Golang הנוכחי משתמש בגדלי חלונות שאינם אופטימליים (263 בלוקים לגמישות חותמות זמן, 2641 בלוקים לחלון DAA). כתוצאה מכך, כורים שהשעון שלהם נסחף לעתיד יותר משתי דקות מרוב הרשת, מתעכבים בבלוק שלהם, מה שמקטין את הסבירות שהם יהיו כחולים. מוטיבציה משנית להצעה זו היא להגדיל את גמישות חותמות הזמן (הדורשת הגדלת חלון DAA בהתאם) ביעילות.
דגימת בלוקים
אנו מציעים, במקום להשתמש בכל הבלוקים בעבר, לדגום תת-קבוצה של הבלוקים שישמשו להתאמת רמת הקושי. שיטת הדגימה צריכה להיות:
- דטרמיניסטי: ניתן לחשב זאת מה-DAG והתוצאה תהיה זהה עבור כל הצמתים.
- מחולק באופן אחיד: לכל הבלוקים יש סיכוי דומה להידגם.
- מצטבר: זה לא אמור להיות תלוי בנקודת המבט של בלוק מסוים, כך שזה יוכל לעבור בירושה לבלוקים עתידיים.
- מאובטח: כורה לא אמור להיות מסוגל להשפיע בזול על ההסתברות שהבלוק שלו יידגם, העלות צריכה להיות דומה לסילוק בלוק תקף.
אנו מציעים את שיטת הדגימה הבאה: לדגום בלוק אחד מכל C, בלוק המקיים את הטענה ש-hash של blake2b של hash kHH של הכותרת שלהם מכיל log(C) 0s נגררים. הסיבה שאיננו משתמשים ב-kHH של הכותרת ישירות היא למען עיצוב נקי יותר ולמנוע את התרחיש (הלא סביר, אך האפשרי) שככל שהקושי עולה, נגמרו לנו הביטים. איננו משתמשים ב-hash של blake2b ישירות על הכותרת כדי למנוע מכורה עוין לסנן nonces של blake2b לפני חישוב nonces של kHH (התקפה בעלת עלות שולית בהתחשב בכך שכיום blake2b מהיר ביותר מ-kHH).
מכיוון שדגימה של הבלוקים מסתמכת על kHH של הכותרת, הגיוני יותר לחשב אותה תוך כדי אימות הקושי של הבלוק, ולאחסן שני ערכים בוליאניים, אחד עבור חלון DAA והשני עבור גמישות של זמן ספאם.
(שימו לב ששיטה זו מאפשרת רק לבחור C כחזקה של 2, ישנן שיטות לחדד זאת. לדוגמה, על ידי הגבלת שלושת הביטים הראשונים ל-0, ושני הביטים האחרונים להכיל לפחות 0 אחד, אנו מקבלים הסתברות של (1/8)*(3/4) = 3/32 עבור כל בלוק שידגם. איני רואה סיבה להתייחס לבעיה זו באופן כללי, לא משנה מה קצב הדגימה שנבחר, נוכל להתאים כלל דגימה אד-הוק שיהיה קרוב מספיק)
עדכון: ג'ורג' קונצלי הציע את התנאי הבא לדגימת בלוק אחד מכל C: חשבו על u32 או u16 (LE או BE) של הגיבוב של בלייק כ-V, הגדירו סף T = (((u32::MAX כ-u64 + 1 + C / 2) / C) – 1) כ-u32 ודגמו כל בלוק שיש לו V <= T. ככל שחלק גדול יותר מהגיבוב המשמש עבור T, כך הדיוק שנקבל גבוה יותר. מבחן הבחירה גם זול מאוד.
העובדה ששיטה זו היא דטרמיניסטית ואינספורמטית היא נכונה מטבעה, האחידות נובעת מההנחה הסטנדרטית שבלייק מקרוב מספיק אורקל אקראי. האבטחה נובעת מהעובדה שה-nonce כלול בכותרת, כך (בהנחה שבלייק ו-kHH מתפזרים באופן עצמאי), מספר ה-hashes הצפוי הנדרש כדי למצוא nonce שהופך את הבלוק לתקף וגם נבחר גדול פי C מה-hashes הנדרשים עבור בלוק תקף. ניתן לטעון שנדרש גורם זניח של (C-1)/C כדי שהכורה יכרה באופן עוין בלוק שלא נבחר (ובכך יפגע בתהליך הדגימה), אולם, חוסר הזיכרון של תהליך פואסון מרמז על כך, מותנה בעובדה שהכורה מצא nonce עבור בלוק שנדגם, עדיין יש לו את אותו זמן המתנה צפוי לעבודה על בלוק חדש.
ויסות פליטות
אנו מווסתים כיום פליטות על ידי אי-תגמול על בלוקים מחוץ לחלון הקושי. גישה זו אינה מתאימה כאשר חלון הקושי נדגם. לכן, במקום זאת, אנו מתגמלים רק בלוקים שהציון הכחול המצטבר שלהם הוא לפחות כמו הציון הכחול המצטבר הנמוך ביותר שנצפה בחלון הקושי.
קבועים מוצעים
אנו מציעים את הדברים הבאים:
- הגדל את גמישות חותמת הזמן משתי דקות ל-10 דקות. זה דורש חלון זמן של 20 דקות. אני מציע קצב דגימה של בלוק לכל 10 שניות. הגודל הכולל של חלון גמישות חותמת הזמן יהיה אז 121 בלוקים.
- הגדל את אורך חלון הקושי ל-500 דקות, תוך דגימה של בלוק כל 30 שניות. הגודל הכולל של חלון הקושי יהיה 1000 בלוקים.
בפועל, אורך החלונות וקצב הדגימה כנראה יותאמו מעט לצורך יישום פשוט יותר. אני לא מסביר את ההתאמות מכיוון שהן תלויות בקצב הבלוקים.
קצוות רופפים
- במבט חטוף, זה אולי נראה מדאיג שהגבול על תגמולי הבלוקים הוא הסתברותי ובעל שונות, מכיוון שהוא עלול לערער את לוח הזמנים של הפליטה. עם זאת, מכיוון שזה נכון רק לגבי בלוקים אדומים שלא מוזגו בעבר, ההשפעה היא שולית. יתר על כן, פרוטוקול הגיזום מגביל מאוד את היכולת למזג בלוקים ישנים, והגבול שלהם יהפוך תלול יותר ככל שנגדיל את אורך (בזמן העולם האמיתי) של חלון הקושי. למרות שאני בטוח שההשפעה הזו זניחה, עלינו למדוד אותה ברשת הבדיקה לפני הפריסה לרשת הראשית.
- ה-DAA מכוון מחדש כעת על סמך הקושי הממוצע לאורך חלון הקושי. זה גורם להתאמת הקושי להתעכב בתקופות של שינוי משמעותי בקצב הגיבוב הגלובלי. ייתכן שעדיף להשתמש בממוצע שונה, למשל מתן משקלים רבים יותר לבלוקים חדשים יותר (או פשוט לקחת את הממוצע של חלון משנה קטן).
- בחירת חותמת הזמן החציונית רגישה הרבה יותר לשונות מאשר מיקוד מחדש של הקושי בפועל, עלינו לוודא שהקבועים שנבחרו אינם גורמים לשונות בעייתית.
תאימות לאחור
שובר את כללי הקונצנזוס, דורש hardfork
דחייה
לאחר שיקול דעת נוסף, שמנו לב להתקפה הבאה: כורה גדול חדש שמצטרף לרשת יכול לדכא בלוקים שנדגמו, ובכך למנוע מהרשת להסתגל לרמת הקושי הנוספת. ניתן לפתור זאת בכמה דרכים, כאשר הישירה ביותר היא להשתמש בבלוקים שנדגמו לדגימת חותמות זמן, אך בחירת הקושי בהתאם למספר הכולל של בלוקים שנוצרו, ולא רק לבלוקים שנדגמו. פתרון זה כרוך במורכבות נוספת הנדרשת למעקב אחר מספר הבלוקים שנוצרו בפועל, ועדיין מאפשר לכורה גדול להתערב במידה מסוימת בסבילות סטיית חותמות הזמן (ובכך להחריף את התקפות הקושי, אם כי במידה מוגבלת). כאשר דנו בפתרון, הגענו לגישה שונה המפורטת ב-KIP4. בעוד שגישת KIP4 דומה מאוד להצעה הנוכחית, מצאנו אותה שונה מספיק כדי להצדיק KIP חדש במקום לעדכן את הנוכחי.
גילוי נאות
נכתב במקור על ידי שי ויבורסקי, מיכאל סאטון.
האמור לעיל מובא לצורכי ידע כללי בלבד ואינו מהווה ייעוץ פיננסי, השקעות, מס, או המלצה למסחר בנכסים דיגיטליים או כל ייעוץ אחר ואינו תחליף להתייעצות עם גורם מוסמך.
הכותב / מתרגם ומערכת האתר אינם אחראים לכל נזק, הפסד או טעות הנובעים מהסתמכות על המידע המוצג כאן או במסמכים של צד ג' שתורגמו לעברית.
המסמך תורגם לעברית על ידי צוות kaspa.co.il למען הקהילה
במידה ומצאתם טעות בתרגום נשמח אם תעדכנו אותנו בטופס יצירת קשר
