מבלוקצ'יין ל-DAG: להיפטר ממתווכים

במאמר זה אספר לכם על DAG (Directed Acyclic Graph) והיישום שלו בספרי חשבונות מבוזרים, ונשווה אותו לבלוקצ'יין.

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



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

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

כורים הם מתווכים העומדים בינך לבין ספר החשבונות המבוזר.

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

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

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

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

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

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

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

1. מה קרה?
2. באיזה סדר זה קרה?

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

אם זה היה בלוקצ'יין, הכורים היו מחליטים מה קורה. מה שהכורה מחליט לכלול בבלוק זה מה שקורה. כל מה שהוא לא כולל בבלוק לא קורה.

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

כיצד לקבוע את סדר העסקאות ב-DAG?

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

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

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

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

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

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

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

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

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

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

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

עכשיו איך אנחנו שולטים בהוצאות כפולות?

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

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

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

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

זהו כלל חשוב מאוד המאפשר לכל המערכת להיות עמידה בפני ניסיונות צנזורה. 

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

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

מקור: www.habr.com