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

הצעה לשיפור: KIP4
שכבה: קונצנזוס.
תיאור: חלונות דלילי קושי (Sparse Difficulty Windows)
מחבר: שי ויבורסקי, מיכאל סאטון, ג'ורג' קונצלי.
סטטוס: פעיל.

מוטיבציה

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

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

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

קושי בחלונות

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

כיום, חלון של בלוק B באורך L הוא קבוצת בלוקי L*BPS בעבר של B עם העבודה הכחולה הגבוהה ביותר.

חלונות קושי הם חלונות המשמשים לקביעת כיצד להתאים מחדש את יעד הקושי. אלגוריתם התאמת הקושי משתמש למעשה בשני חלונות:

• חלון גמישות חותמת הזמן, המשמש להגבלת הסטייה המותרת מחותמת הזמן הצפויה.
• חלון הקושי, המשמש לקירוב הסטייה של זמן יצירת הבלוק מהזמן הצפוי.

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

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

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

חלונות דלילים

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

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

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

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

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

ההצעה שלנו

מאלה נוכל להגדיר כמות חדשה sparsity = אורך*BPS/גודל. באופן אינטואיטיבי, אנו משתמשים ב"בלוק אחד מכל בלוק sparsity". שימו לב ש-sparsity הוא הכמות היחידה המושפעת על ידי ה-BPS, ובפרט הגדרת sparsity=1 משחזרת את החלונות הנוכחיים, שאינם דלילים.

אנו מניחים גם שלכל בלוק B יש סדר קבוע כלשהו למעבר על קבוצת המיזוג של B, בקרוב נציע סידור מפורש שאנו מוצאים מתאים. ברגע שסידור כזה זמין, נגדיר באופן אינטואיטיבי את החלון על ידי התחלה עם החלון של B.selected_parent ולאחר מכן מעבר על B.merge_set, בכל פעם מוסיפים בלוק אחד ואת בלוקי sparsity-1 המדלגים, תוך הסרת הבלוקים עם blue_work הנמוך ביותר מהחלון כדי לשמר את גודלו.

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

אנו מגדירים עבור כל בלוק B שדה בשם B.window(size,sparsity) המכיל min_heap מוגבל, בעל עדיפות על ידי blue_work וגובל על ידי size. משמעות הדבר היא שאם ישנם אלמנטים של size ב-B.window, אז בכל פעם שאלמנט נדחף לתוך B.window(size,sparsity), B.window(size,sparsity).extract_min() מתבצע באופן אוטומטי, תוך שמירה על גודל הערימה.

שימו לב שהשדה B.window(size,sparsity) הוא זמני: הוא אינו מאוחסן עם הבלוק, אלא מאוחסן במטמון. במקרה שהאב הנבחר של B אינו מאוחסן במטמון, שדה זה יחושב תוך כדי תנועה.

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

ההליך לחישוב B.window(size,sparsity) הוא כדלקמן:

הערות:

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

נותר לציין את הסדר שבו עוברים את B.merge_set, אנו מציעים להשתמש ב-blue_work בסדר יורד. כלומר, החל מה-blue_work הגבוה ביותר. בדרך זו, סדר קבוצת המיזוג תלוי בעתיד, מה שמקשה על המשחק.

ויסות פליטות

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

קבועים מוצעים

אנו מציעים את הדברים הבאים:

• גמישות חותמת זמן: אורך=1210 (כ-20 דקות), גודל=121.
• רמת קושי: אורך=30000 (500 דקות), גודל=1000.

תאימות לאחור

שובר את כללי הקונצנזוס, דורש hardfork

גילוי נאות

נכתב במקור על ידי שי ויבורסקי, מיכאל סאטון, ג'ורג' קונצלי.

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

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

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