GHOSTDAG
GHOSTDAG - איך כולם מגיעים לאותו סדר בתוך BlockDAG?
BlockDAG מאפשר לשמור בלוקים שנוצרו במקביל בתוך אותו מבנה.
אבל זה עדיין לא מספיק.
אם שני בלוקים נוצרו במקביל, המבנה יכול להגיד:
"שניהם קיימים ושניהם מחוברים לאותו עבר."
הוא לא אומר לבדו:
איזה מהם צריך להיחשב קודם כשבודקים את העסקאות שבתוכם?
בשביל זה Kaspa משתמשת ב-GHOSTDAG.
למה בכלל צריך סדר?
נניח שבבלוק אחד נמצאת עסקה:
נועה → דן: 30 KAS
ובבלוק שנוצר במקביל נמצאת עסקה אחרת:
נועה → מאיה: אותם 30 KAS
אפשר לשמור את שני הבלוקים בתוך ה-BlockDAG.
אבל אי אפשר לקבל את שני התשלומים.
כדי שכל המחשבים יקבלו אותה תשובה, הם צריכים להגיע לאותו סדר.
אם העסקה לדן קודמת - אחריה כבר אי אפשר להשתמש שוב באותו כסף למאיה.
לכן:
שמירת הבלוקים היא בעיה אחת.
קביעת הסדר שלהם היא בעיה אחרת.
GHOSTDAG נותן לכל ה-Nodes אותם כללים לקביעת הסדר
כל Node רואה את ה-BlockDAG ומפעיל עליו את אותם כללי GHOSTDAG.
הכללים מסתכלים על:
איך הבלוקים מחוברים זה לזה, ועל עבודת ה-Proof of Work שנעשתה.
מכיוון שכל ה-Nodes משתמשים באותם כללים, הם יכולים להגיע לאותה תשובה לגבי איך לסדר את ההיסטוריה.
זה לא תלוי בשאלה:
"איזה בלוק הגיע אליי ראשון?"
Node אחד יכול לשמוע קודם על בלוק אחד, ו-Node אחר על השני.
הסדר צריך לבוא מכללי הפרוטוקול - לא מסדר ההגעה למחשב מסוים.
GHOSTDAG בוחר דרך מועדפת בתוך הגרף
אפשר לחשוב על ה-BlockDAG כמו על רשת של הרבה דרכים מחוברות.
GHOSTDAG מזהה דרך מרכזית שמייצגת את ההיסטוריה המועדפת לפי כללי הפרוטוקול ועבודת ה-Proof of Work.
אבל הוא לא פשוט זורק את כל מה שלא נמצא בדיוק על הדרך הזאת.
גם בלוקים שנוצרו במקביל יכולים להשתלב בסדר הכולל.
זה אחד ההבדלים החשובים לעומת שרשרת שבה בסופו של דבר נשאר קו ראשי אחד.
ומה הם "בלוקים כחולים" ו"בלוקים אדומים"?
GHOSTDAG מסווג בלוקים כחלק מהדרך שבה הוא מנתח את הגרף.
חלק מהבלוקים מסווגים Blue וחלק Red.
אבל חשוב לא לפרש את הצבעים בצורה לא נכונה:
Blue לא אומר "בלוק טוב".
Red לא אומר "בלוק מזויף" או "בלוק רע".
הצבע מתאר את המקום של הבלוק בתוך חישוב GHOSTDAG ואת היחסים שלו לבלוקים האחרים.
גם בלוק Red יכול להיות בלוק תקין שנוצר על ידי כורה ישר.
למתחיל מספיק לדעת:
הצבעים עוזרים ל-GHOSTDAG לסדר את העבודה שנעשתה במקביל.
לא צריך להבין את החישוב המדויק כדי להבין את הרעיון.
יש גבול שנקבע מראש לכמות המקביליות ש-GHOSTDAG תוכנן אליה
אם שני כורים ישרים עובדים כמעט יחד כי המידע עוד לא הספיק לעבור ביניהם - זה מצב טבעי ברשת.
GHOSTDAG מתוכנן להתמודד עם כמות מסוימת של עבודה כזאת שנעשית במקביל.
בתוך כללי הפרוטוקול יש גבול שנקבע מראש ומתאים לתנאי הרשת שאליהם GHOSTDAG תוכנן.
לא צריך לזכור מספר כדי להבין את הנקודה:
Kaspa לא מניחה שכל בלוק חייב להגיע לכולם לפני שהבלוק הבא נוצר.
הפרוטוקול בנוי מראש להתמודד עם מצב שבו כמה בלוקים נוצרים לפני שהמידע הספיק להתפשט לכולם.
אחרי שנקבע סדר, עדיין צריך לבדוק את העסקאות
GHOSTDAG לא אומר:
"כל מה שיש בכל בלוק מתקבל."
הוא עוזר לקבוע סדר מוסכם של ההיסטוריה.
אחרי שיש סדר, ה-Nodes עדיין מפעילים את כללי העסקאות.
נחזור לדוגמה:
- בלוק אחד כולל נועה → דן: 30 KAS.
- בלוק מקביל כולל נועה → מאיה: אותם 30 KAS.
- GHOSTDAG עוזר לקבוע סדר מוסכם בין הבלוקים.
- העסקה הראשונה לפי הסדר יכולה להוציא את הכסף.
- כשהעסקה השנייה נבדקת, הכסף כבר אינו זמין - ולכן היא לא יכולה להתקבל.
לכן חשוב להפריד:
GHOSTDAG קובע סדר.
כללי העסקאות קובעים מה תקין בתוך הסדר הזה.
וזה מה שמאפשר ל-BlockDAG להיות שימושי
בלי GHOSTDAG היה לנו גרף של בלוקים מחוברים - אבל עדיין היינו צריכים דרך שבה כל ה-Nodes יוכלו להשתמש בו כאותה היסטוריה.
אפשר לסכם:
BlockDAG אומר מי מחובר למי.
GHOSTDAG קובע איך לסדר את ההיסטוריה המחוברת הזאת.
כללי העסקאות קובעים אילו פעולות מתקבלות בתוך הסדר.
למה זה חשוב לקצב בלוקים גבוה?
ככל שבלוקים נוצרים לעיתים קרובות יותר, יותר טבעי שכמה מהם ייווצרו לפני שהמידע על האחרים הגיע לכל הכורים.
במקום להתייחס לכל מקרה כזה כבעיה שבה חייבים להשאיר רק ענף אחד, Kaspa יכולה:
לשמור את הבלוקים המקבילים מחוברים, ואחר כך לסדר אותם לפי GHOSTDAG.
זה חלק מרכזי במה שמאפשר ל-Kaspa לעבוד עם קצב בלוקים גבוה.
אבל עכשיו עולה שאלה חדשה:
אם נוצרים יותר בלוקים בשנייה - מה זה באמת אומר על כמות העסקאות ועל המהירות שהמשתמש מרגיש?