רשתות חלל: איך פועלת הצעת רשת הצד החדש של ביטקוין

צומת המקור: 1544330

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

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

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

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

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

הצעת החללית

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

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

הרעיון הכללי של הצעת כריית המיזוג העיוור שלו הוא שעל ידי שימוש ב- APO, אתה יכול להגדיר מראש קבוצה ארוכה של עסקאות שלוקחות את אותו UTXO ראשוני המוזן לתוכם ולהתחייב ליצור אותו מחדש תמיד. אז תארו לעצמכם Satoshi UTXO בודד, כאשר כל עסקה שנוצרה מראש מבטיחה שאותו UTXO נוצר מחדש כפלט לאחר אישורו. תחשוב על זה כמו סוג של סמן, UTXO המיוחד הזה הוא המזהה שמאפשר לכל מי שמסתכל על הבלוקצ'יין הראשי של ביטקוין לדעת, "זה המקום שבו אני מוצא מחויבות לבלוקים של Sidechain X." זה משאיר בעיה אחת פתוחה: עמלות הכורים. אם יש ליצור מחדש את ה-UTXO עם אותו סכום, אין כסף לשלם עמם עמלות.

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

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

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

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

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

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

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

בסך הכל זה נראה כך: 

מָקוֹר

ראוי גם לציין שניתן ליישם שתי גרסאות של עיצוב זה עם CHECKTEMPLATEVERIFY (CTV) או ללא שינויים כלל. לשתי גרסאות העיצוב הללו יש פשוט פשרות לא אופטימליות.

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

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

אז מה שאנחנו צריכים לעשות כאן זה ליצור עסקה לגמרי מחוץ לשרשרת של עסקאות CTV עבור התחייבות Sidechain ליצור UTXO שמספיק בדיוק כדי לשלם את העמלה עבור עסקת CTV (מכיוון שלא ניתן ליצור פלט שינוי חדש ב- עסקה זו, 100% מהקלט שאתה מוסיף הולך לעמלות), ובתוך העסקה הכנת העמלה UTXO היא המקום שבו אנו מתחייבים לכותרת בלוק sidechain. אז, שלב ראשון: עסקה שיוצרת עמלה משלמת פלט והתחייבות ל-sidechain block header. שלב שני: אנו לוקחים את פלט העמלות ומוסיפים אותו כקלט לעסקת CTV, שכאשר היא מאושרת, "מכרה" את בלוק ה-sidechain הספציפי שלנו. גרסה זו נראית כך:

מָקוֹר

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

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

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

מָקוֹר

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

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

מאמר זה הוא פשוט הראשון בסדרה המתייחסת להצעות העיצוב העיקריות ל-sidechain שפורסמו עבור ביטקוין מאז העיצוב המקורי של 2014. שימו לב לשאר.

זהו פוסט אורח מאת Shinobi. הדעות המובעות הן לגמרי שלהם ואינן משקפות בהכרח את הדעות של BTC Inc או Bitcoin Magazine.

בול זמן:

עוד מ מגזין Bitcoin