הצעה לשיפור: KIP15
שכבה: קונצנזוס
תיאור: התחייבויות קנוניות לסידור ורצף עסקאות
מחבר: Mike Zak, Ro Ma
סטטוס: פעיל

מוטיבציה

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

בנוסף, צומת Kaspa גוזם את נתוני העסקאות והכותרת לאחר כ-52 שעות (30 שעות לאחר קרשנדו) מפרסומם. זה מתאפשר על ידי UTXO-commitment המפורסם בכותרת הבלוק של Kaspa, המאפשר ללקוח חדש להוריד את מצב הרשת (הגדרת UTXO שלה) בבלוק B כלשהו ממקור לא אמין, ולאחר מכן לאמת אותו מול UTXO-commitment של B.

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

צומת ארכיון של עסקאות שהתקבלו

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

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

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

תכנון נאיבי יכול ללכת בכיוון הבא:
1 הורד את כותרות הבלוק של שרשרת האב שנבחרה מהקצה ועד לתחילת L2
2 עבור כל בלוק בשרשרת האב הנבחרת מלמטה למעלה:
1. הורד את רשימת העסקאות המקובלות
2. אימות זה מול AcceptedIDMerkleRoot של הבלוק

לעיצוב הנ"ל יש שני פגמים:

1. יש הרבה נתונים בכותרות הבלוקים שהם מיותרים עבור תהליך זה.
2. נכון לעכשיו, AcceptedIDMerkleRoot אינו מתחייב להזמנת עסקאות. (ראה עוד על כך בסעיף הבא)

מיון של AcceptedIDMerkleRoot

נכון לעכשיו, לאחר איסוף כל העסקאות המתקבלות על ידי בלוק, צומת Kaspa ממיין את העסקאות הללו לפי ה-hash שלהן לפני חישוב AcceptedIDMerkleRoot.

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

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

ההצעה שלנו

אנו מציעים שדה כותרת בלוק חדש בשם SequencingCommitment שיחליף את AcceptedIDMerkleRoot.

SequencingCommitment יחושב באופן הבא:

אלגוריתם הגיבוב שיש להשתמש בו הוא אותו אלגוריתם גיבוב המשמש בכל Kaspa עבור עצי merkle (כרגע blake2b).

עיצוב צומת ארכיון של עסקאות מקובלות

בהינתן השינויים הנ"ל ב-Kaspa, ניתן להציע את העיצוב הבא עבור ATAN: כפי שצוין לעיל, הצומת מקשיב ל-VirtualSelectedParentChainChanged ומאחסן עבור כל בלוק שרשרת B:

1. B.TxList – רשימת העסקאות המתקבלות על ידי B, לפי סדר קבלתן.
2. B.SequencingCommitment.
   יש לאחסן נקודת זו החל מבלוק P כלשהו, ​​מסודר מלמטה למעלה.
   P חייבת להיות נקודת גיזום, כך שכל לקוח לא מהימן שיש לו גישה לצומת מלא של Kaspa יוכל לזהות אותה. יש לבחור את P כנקודת הגיזום האחרונה שעבורה כל עסקאות L2 נמצאות בעתיד של P, או שיש איזשהו מחויבות למצב L2 בעתיד של P.

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

ATAN X מסונכרן יכול לאתחל ATAN Y שאינו מהימן, בהנחה של-Y יש גישה לצומת Kaspa מלא באופן הבא:

1. X שולח ל Y
   P.Hash
   ו
   P.SequencingCommitment
2. Y מאמת שהוא מזהה את P כנקודת גיזום.
3. עבור כל בלוק שרשרת B מ-P.SelectedChild ועד Tip:

1. X שולח ל-Y: B.TxList ו-B.SequencingCommitment (לא כולל P.TxList)
2. Y עושה:

1. B.ExpectedAcceptedIDMerkleRoot = B.TxList.MerkleRoot()
2. B.ExpectedSequencingCommitment = hash(B.SelectedParent.SequencingCommitment, B.ExpectedAcceptedIDMerkleRoot)
3. מאמת ש-B.ExpectedSequencingCommitment == SequencingCommitment

שימו לב שאנחנו מתחילים מ-P.SelectedChild, מכיוון שלא ניתן לאמת את P.SequencingCommitment ללא ה-SelectedParent שלו.

קוד לדוגמה

ניתן למצוא את יישום KIP-15 ב-PR הבא: kaspanet/rusty-kaspa#636

תאימות לאחור

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

תודות

תודה למייקל סאטון michael sutton על הדיונים שהובילו לתוכנית KIP זו.

גילוי נאות

נכתב במקור על ידי Mike Zak, Ro Ma

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

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

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