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

הצעה לשיפור: KIP6
שכבה: קונצנזוס, אפליקציה.
תיאור: הוכחת חברות בשרשרת (PoChM).
מחבר: שי ויבורסקי.
סטטוס: טיוטה.

מוטיבציה

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

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

ישנם שני סוגים של הוכחות:

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

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

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

מעניין לציין, בעוד שהרעיון של txR חזק יותר באופן מוחלט מ-PoP, הוא למעשה קל יותר ליישם ב-Kaspa. הסיבה לכך היא שעסקאות שהתקבלו מקבלות טיפול מיוחד: כל בלוק שרשרת שנבחר מכיל את השורש של עץ מרקל של כל העסקאות שהתקבלו על ידי הבלוק (ATMR, ראה להלן). לפיכך, עסקה התקבלה אם ורק אם היא מופיעה בעץ מרקל זה בבלוק שרשרת שנבחר.

לפיכך, כדי לספק הוכחת קבלה עבור עסקה, די לספק את הוכחת מרקל שבלוק B קיבל את עסקה, יחד עם הוכחה כלשהי ש-B היה בלוק שרשרת נבחר. כדי לספק הוכחת פרסום, די לספק הוכחה שבלוק B היה בלוק שרשרת נבחר, שרשרת של כותרות העוברות מ-B לבלוק C כלשהו והוכחת מרקל ש-C קיבל את עסקה.

החלק המשותף לשני סוגי ההוכחות הללו הוא להראות ש-B הוא כותרת של בלוק שרשרת נבחר, כלומר, לספק הוכחת חברות בשרשרת (PoChM, מבוטא כמו המילה הלטינית pacem). זהו מוקד ההצעה הנוכחית.

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

סימונים

בהצעה זו, נוח להשתמש בסימון Past(B) (ביחס ל-Future(B)) כדי לציין את העבר (ביחס ל-future) של בלוק B, כולל בלוק B עצמו. שמות המתודות נכתבים באותיות גדולות כדי להבדיל אותן מהסימון הנפוץ past(B) ו-future(B) שאינו כולל את בלוק B עצמו.

אני משתמש בסימון parent(B,n) כדי לציין את ההורה ה-n שנבחר של B. לשם קיצור, אני משתמש ב-parent(B) במקום ב-parent(B,1). עבור כל n>1 נוכל להגדיר באופן רקורסיבי parent(B,n)=parent(parent(B,n-1)).

כותרות הדורות הבאים

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

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

בהינתן בלוק B, יהי posterity(B) כותרת ההמשך המוקדמת ביותר כך ש-B ∈ Past(posterity(B)), או null אם כותרת מאוחסנת כזו עדיין אינה קיימת. יהי posterity_depth(B) מפיק את המספר השלם n המקיים את B=parent(posterity(B),n).

עבור כל בלוק B, יהי next_posterity(B) כותרת הבלוק עם המאפיין הבא: אם B היא כותרת של פוסט-פורטיה, אז next_posterity(B) היא כותרת של פוסט-פורטיה הבאה. שימו לב שזה מוגדר היטב גם אם B אינו כותרת של פוסט-פורטיה.

לכותרות פוסט-פורטיה יש את המאפיינים החשובים הבאים:

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

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

עסקאות מקובלות ב-Merkle Root (ATMR)

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

הוכחות חברות בשרשרת (PoChM)

כדי לספק txR עבור txn, די לספק את הדברים הבאים:

כותרת של בלוק B והוכחת Merkle ש-txn מופיע ב-B (ATMR)
הוכחה ש-B הופיעה בשרשרת שנבחרה
זה מספיק כדי להוכיח ש-txn אומתה גם אם עסקה סותרת txn' (או כל מספר שלה) נכללה גם בבלוקDAG: כללי האימות מרמזים ש-txn ו-txn' הופיעו שניהם באנטי-קונו של B, וכי txn קדם ל-txn' בסדר GHOSTDAG.

הפריט הראשון הוא הוכחת Merkle פשוטה. עם זאת, הפריט השני מסובך יותר. אני מתייחס להוכחה כזו כהוכחת חברות בשרשרת (PoChM, מבוטא כמו המילה הלטינית pacem) עבור B. שאר מסמך זה עוסק במתן PoChM עבור בלוק B שרירותי.

PoChM ללא Hard-Fork

נכון לעכשיו, הדרך הפשוטה ביותר לבנות PoChM עבור B היא לאחסן את כל הקבוצה Future(B) ∩ Past(posterity(B)). התוצאה היא DAG "בצורת יהלום" שהבלוק העליון שלו הוא posterity(B) והבלוק התחתון שלו הוא B. בהינתן DAG בצורה זו כהוכחה, כל צומת יכול לאמת שהבלוק העליון הוא בלוק של המשך, ושהמשך ההורה שנבחר מהבלוק העליון מוביל לבלוק התחתון.

הבעיה עם הוכחה זו היא גודלה. במקרה הגרוע ביותר, היא תהיה בגודל של כ-24 שעות של כותרות. בגודל הנוכחי של 1BPS וכותרת של 248 בתים, זה מסתכם בכ-24 מגה-בייט.

הערה: ניתן לשפר זאת מעט על ידי אחסון הקבוצה כולה רק של הכותרות של בלוקי השרשרת שנבחרו וההורים שלהם, במקום לאחסן את כל הקבוצה. נתונים אלה מספיקים כדי לחשב את ההורה שנבחר של כל בלוק שרשרת שנבחר ולאמת את ההוכחה. עם זאת, נראה שזה לא משפר את הגודל בהרבה. כמו כן, שימו לב שניתן לצבור הוכחות עבור עסקאות רבות שהתקבלו בבלוקים של שרשרת עם אותה עתיד. בפרט, PoChM עבור בלוק B הוא גם PoChM עבור כל בלוק שרשרת C ∈ Future(B) ∩ Past(posterity(B))

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

פשרות ביצועים

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

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

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

ההצעה שלנו "מאזנת" את הגישה השנייה: אנו מוסיפים לכל כותרת את השורש של עץ מרקל המכיל רק כותרות רבות באופן לוגריתמי. זה מאפשר יצירת PoChM בצורת שרשרת כותרות ארוכה לוגריתמית והוכחות מרקל.

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

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

ההצעה שלנו

כותרת הבלוק תכיל שדה חדש בשם שורש מרקל (PMR) של PoChM, המוגדר באופן הבא: יהי k המספר השלם הקטן ביותר כך ש-parent(B,2^k) ∈ Past(next_posterity(B)), אז PMR הוא שורש עץ המרקל המכיל את הכותרות parent(B,2^i) עבור i = 0,…,k-1.

יהי PMR(B,i) הפונקציה שמפיקה הוכחת מרקל ש-hash(parent(B,2^i)) נמצא בעץ ששורשו הוא ה-PMR של B.

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

ההליך ליצירת PoChM עבור בלוק B הוא כדלקמן:

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

אם יש i כלשהו כך ש-posterity_depth(B) = 2^i, אז B עצמו הוא איבר ב-PMR של posterity(B) וכל PoChM הוא הוכחת מרקל אחת.

אם יש i>j כך ש-posterity_depth(B) = 2^i + 2^j, אז ההוכחה תכיל שלושה פריטים:

• כדי להבין איך לאמת את ההוכחה, נבחן אותה בשני מקרים פשוטים:
• אם יש כך ש-posterity_depth(B) = 2^i, אז B עצמו הוא איבר ב-PMR של postity(B) וכל PoChM הוא הוכחת מרקל אחת.
• אם יש i>j כך ש-posterity_depth(B) = 2^i + 2^j, אז ההוכחה תכיל שלושה פריטים:

על ידי אימות ההוכחות והגיבובים לעיל, מאמתים ש-B הוא אכן בלוק שרשרת. ההליך הכללי משתרע באופן דומה.

PoP וקבלת אימות

כדי ליצור קבלה לאימות עבור עסקה:

• מצא את הבלוק B שקיבל את הטרנספורמציה
• פלט: PoChM עבור B, הוכחת מרקל ש-B נמצא ב-ATMR של B

כדי ליצור PoP עבור txn:

מצא את הבלוק C שבו פורסם txn

יהי B בלוק השרשרת המוקדם ביותר שנבחר עם C בעברו

פלט: PoChM עבור B, שרשרת כותרות מ-B ל-C, הוכחת Merkle ש-txn נמצא ב-ATMR של C

שימו לב שניתן למטב את ה-PoP: במקום להשתמש ב-C, מצאו בלוק C' לאורך הנתיב מ-B ל-C' שמקבל txn וממזער את אורך השרשרת מ-B ל-C', השתמשו ב-C' במקום C בשלב האחרון. לאופטימיזציה זו יש את התכונה הטובה שאם txn התקבל, אז ה-PoP המתקבל יהיה זהה לקבלת האימות. עם זאת, ייתכן שהמורכבות המוגברת של יישום האופטימיזציה משמעותית יותר מההפחתה בגודל ההוכחה, אותה יש למדוד בפועל.

צפיפות כותרת הדורות הבאים

כאופטימיזציה סופית, אני שוקל להגדיל את צפיפות הבלוקים המאוחסנים לפעם בשעה. המוטיבציה העיקרית לאופטימיזציה זו היא להפחית את הזמן הנדרש לפני שניתן יהיה ליצור PoChM. תנאי מוקדם ליצירת PoChM הוא ש-stored_header(B) כבר קיים, וצמצום זמן זה מועיל. בנוסף, פעולה זו תפחית באופן משמעותי (בכ-40%) את מורכבות שלב האימות הנוסף ואת אימות ה-PoChM ואת גודל ה-PoChM.

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

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

גודל ה-PoChM

חישוב הגודל האמיתי של PoChM הוא מעט מסובך, מכיוון שהוא תלוי במספר בלוקי השרשרת בין C ל-next_posterity(C) עבור מספר בלוקים C. אם נעיף מבט ב-KGI למשך זמן מספיק, ניתן להשתכנע שהשרשרת שנבחרה גדלה בכבלוק אחד כל שתי שניות (כלומר, ב-1BPS אנו רואים שכמחצית מהבלוקים הם בלוקי שרשרת). כדי לספק גבול עליון אמין, אניח שהשרשרת שנבחרה גדלה בקצב של כבלוק אחד לשנייה. שימו לב שצמיחת השרשרת שנבחרה אינה נשלטת על ידי קצבי בלוקים, אלא על ידי תנאי הרשת. לפיכך, אני מניח שזה מתקיים בסבירות מוחלטת עבור כל קצב בלוק. ייתכן שזה לא יתקיים אם תנאי הרשת ישתפרו במידה ניכרת. עם זאת, בקרוב נראה שאסימפטוטיקת הגדילה (כפונקציה של מספר בלוקי השרשרת בין שני בלוקי המשך רצופים) היא log*loglog קלה מאוד, כך שזה כמעט ולא מהווה דאגה. אדגים זאת עם מספרים קונקרטיים לאחר שנקבל ביטוי לגודל של PoChM.

יהי L_e ו-L_a מייצגים את גודל הכותרת והגיבוב, בהתאמה. יהי N מספר השניות בין שני בלוקים עוקבים של פוסטריטי. עבור בלוק B יהי |B| מייצג את משקל האמינג של הייצוג הבינארי של posterity_depth(B). מכאן נובע ש-PaChM עבור B מכיל |B| הוכחות מרקל ו-|B|-1 כותרות (בפרט, אם B=posterity(B) (שווה ערך ל-posterity_depth(B)=0) אז |B|=0, ואכן ה"הוכחה" ריקה, מכיוון שנתוני הקונצנזוס עצמם מוכיחים ש-B הוא בלוק שרשרת).

גודל כל הוכחת מרקל הוא (2log(logN))+1)L_a, כך שהגודל הכולל של ה-PaChM הוא (2log(logN))+1)L_a|B| + L_e(|B|-1). במקרה הגרוע ביותר, יש לנו ש-|B| = log(N) כך שנקבל גבול של (2log(logN))+1)logNL_a + L_e*(logN-1). בהנחה ש-L_e=32 בייט ו-L_a=280 בייט ו-N=86400 (כלומר, שבלוק עתידי נדגם פעם ב-24 שעות), זה מגיע ל-9 קילובייט.

הגדלת צפיפות העתיד העתידי לפעם בשעה (כלומר, הגדרת N=3600) תקטין את גודל ה-PoChM הגדול ביותר ל-6 קילובייט.

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

גודל ה-txR זהה לגודל ה-PoChM עד הוכחת Merkle אחת. שימו לב שגודל הוכחת מרקל כזו אינו log(logN) מכיוון שה-ATMR אינו מכיל כותרות בלוקים אלא עסקאות. לפיכך, גודל הוכחת מרקל זו הוא לוגריתמי במספר העסקאות המתקבלות על ידי B, והוא כפוף לאימוץ ולקצבי בלוקים. כדי לקבל גבול עליון רופף, יש לקחת בחשבון תרחיש שבו כל בלוק מכיל 300 עסקאות וממזג 99 בלוקים (למשל 100BPS בהנחה של עיכוב רשת ממוצע של שנייה אחת). בתרחיש זה, ה-ATMR יכיל כ-30000 עסקאות, כך שהוכחת מרקל תכיל את העסקה עצמה ו-29 גיבובים, מה שהופך אותה לגודל של כ-1KB.

עלות משאבים

צפיפות צאצאים של 24 שעות:

• אחסון קבוע: נכון לעכשיו, מאוחסנים נתוני ספר חשבונות לשלושה ימים, המכילים כ-260,000 כותרות. אחסון מספר דומה של כותרות דורש כ-8.5 מגה-בייט.
• אחסון מצטבר: גיבוב נוסף לכל כותרת עתידית מגדיל את צמיחת המצב בכ-11 קילובייט בשנה.
• אימות בלוקים: השלב החדש דורש חישוב שורש מרקל של עץ בגובה logN המכיל בלוקי שרשרת. מכיוון שכבר יש גישה אקראית מהירה לכל בלוקי השרשרת, החלק הכבד ביותר בחישוב הוא מספר הגיבובים, כאשר מספר הגיבובים הנדרש הוא 2*logN-1. בהנחה של קצב גידול שרשרת נבחר של בלוק אחד לשנייה, זה הופך ל-32 גיבובים. כאשר אין הרבה ארגון מחדש, זה מגיע ל-32 גיבובים/שנייה. אם איכשהו קצב גידול השרשרת הנבחר יגדל, נניח, ל-10 בלוקים לשנייה, זה יהפוך ל-39 גיבובים לבלוק או 390 גיבובים לשנייה. באמצעות גיבוב יעיל כמו blake2, חישוב כמות כזו של גיבוב הוא זניח אפילו עבור מעבדים חלשים מאוד.

צפיפות צאצאים של שעה אחת:

• אחסון קבוע: כמו לעיל
• אחסון מצטבר: 23 כותרות נוספות ביום מצטברות לכ-2.3 מגה-בייט בשנה
• אימות בלוקים: מספר הגיבובים לשנייה יקטן ל-23 גיבובים לשנייה עבור גידול שרשרת נבחר של בלוק אחד לשנייה, או ל-300 גיבובים לשנייה עבור גידול שרשרת נבחר של 10 בלוקים לשנייה.

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

תאימות לאחור

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

גילוי נאות

נכתב במקור על ידי שי ויבורסקי.

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

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

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