זהו מאמר מערכת של שינובי, מחנך אוטודידקט בחלל הביטקוין ומנחה פודקאסט ביטקוין בעל אוריינטציה טכנולוגית.
הפעם אני הולך לפרק ולדון כיצד פועלות שרשרת הינע; הם הוצעו תחילה ב-2015. מבין כל ההצעות שנדונו עד כה, שרשרת ההינע הם הוותיקים והמתוחמים ביותר מבחינת פרטי יישום ועיצוב ספציפיים, המתועדים ב-BIPs 300 ו 301. פול שטורק, יוצר הקונספט, חשב על כמה מטרות עיצוב ראשיות, ולמרות שזה לא מקיף כלל, הנה כמה:
- יש לבודד כל שרשרת צד כך שכל תקלה או בעיה תשפיע רק על המשתמשים בה.
- אפשר לסובב את שרשרת הצד מבלי להזדקק למזלג חדש עבור כל אחד מהם.
- אפשר העברה של ביטקוין פנימה והחוצה משרשרת צד עם יתד דו-כיווני.
- אפשרו ניסויים חופשיים בעיצוב שהוא מקווה שיייישן את הצורך במטבעות אלטקוינים.
ישנם שני היבטים עיקריים של העיצוב כולו, וזו הסיבה שיש שני BIPs נפרדים. הראשון הוא מנגנון היתד (BIP300), שהוא מה שמאפשר לתפקד הדו-כיווני. Sztorc עיצב משהו שנקרא פקדון קצבאות חשיש, שבמונחים הבסיסיים ביותר, מאפשר לכורים כקבוצה אמורפית להחזיק ביחד את המטבעות בכל השלשלאות הצדדיות. השנייה היא תוכנית כרייה ממוזגת "עיוורת", כאשר המטרה היא לאפשר לכורי ביטקוין להיות יצרני הבלוקים ברמת קונצנזוס מבלי להידרש לאמת את ה-sidechain לשם כך. שני החלקים הללו יחד מציגים מנגנון יתד דו-כיווני ודרך לכורי ביטקוין לקחת חלק בכריית שרשרת הצד תוך ניסיון להפחית את סיכון הריכוזיות שהוא מציג.
BIP300 מפרט היגיון להצעה של רשת צד חדשה, הפעלת רשת צד חדשה, הצעת קבוצת משיכות מאגדת, אישור קבוצת משיכות כזו, היגיון האימות לעסקאות משיכה בפועל ואימות עסקאות הפקדה.
הפעלת שרשרת צד חדשה במסגרת הצעת השרשרת הדרייב דומה מאוד לתהליך של מזלג רך המופעל באמצעות איתות כורים. ההבדל העיקרי הוא, כמובן, שזה לא למעשה מזלג רך - מזלג בודד להפעלת כללי הקונצנזוס של שרשרת הכונן מאפשר לכורים, בכל עת, לאותת להפעיל צידישרשרת חדשה בתוך כללי קונצנזוס של שרשרת הינע. כדי להציע הפעלת רשת צד חדשה, כורה חייב למקם נתוני OP_RETURN בפלט בסיס המטבעות שלו, הכולל מזהה ייחודי עבור אותו רשת צד, מפתח ציבורי לשימוש בפעולות הפקדה, נתוני גרסה, תיאורים הניתנים לקריאה על ידי אדם ו-hash של לקוח התוכנה. וההיסטוריה של GitHub שלו (אין כאן אכיפת קונצנזוס, רק נתונים להתייחסות לבני אדם).
כאשר כורה מציע להפעיל רשת צד חדשה ולכלול את כל הנתונים הדרושים בבסיס המטבעות שלו, זה הופך למעין תקופת "אותות כורה" לגבי האם ליצור או לא ליצור רשת צד חדשה זו מנקודת המבט של קונצנזוס רשת מרכזית. כורה יכול להשתמש בפורמט מיוחד כדי לכלול הצעה בתפוקות בסיס המטבעות שלו, וכורים אחרים יכולים ליצור פלט נוסף בעקבות פורמט שני כדי לאותת להפעלה. הצעת שרשרת צד חדשה דורשת 90% מהחסימות בתקופת קושי לאותת להפעלה על מנת שיצירת רשת צד חדשה תאושר. זה יוצר את מנגנון ה-Peg כדי לאפשר את Sidechain, אבל האינטראקציה בין Sidechain ל-Mainchain היא יותר ניואנסית מזה.
בשלב זה, כל אחד יכול להצמיד מטבעות לשרשרת הצד. כדי להצמד לשרשרת הצד, משתמש פשוט יוצר עסקת שתי קלט עם קלט משלו וה-UTXO התואם ליתרת ה-sidechain עם פלט יחיד המקצה הכל לשרשרת הצד. זה מבטיח של-sidechain יש רק UTXO יחיד המכיל את כל הכספים הנעולים בו. משיכות מטופלות על ידי הצבעת כורים. ל-Mainchain אין הבנה למי הבעלים של מה ב-sidechain, וה-Mainchain יחשב כל משיכה שאושרה על ידי כורים במסגרת מנגנון ההצבעה כתקף. בשל כך, קיים עיכוב ארוך בתהליך הנסיגה. ישנם שני שלבים לתהליך הנסיגה משרשרת צד: הצעת משיכה (צרור), ולאחר מכן שלב הצבעת הנסיגה. הכורים חייבים ליצור פלט OP_RETURN בעסקת בסיס המטבעות שלהם עם hash של עסקת המשיכה המוצעת כדי להציע משיכה. עם זאת, ה-hash הזה, בדומה ל-sighash, מסמן רק התחייבות לחלק מעסקה במקום כולו. היא אינה מתחייבת לקלט UTXO המייצג כספים הנעולים ב-Drivechain או לפלט שמחזיר הכל לא נמשך ל-sidechain UTXO מיוחד. הסיבה לכך היא שכל הפקדות ל-drivechain תיצור UTXO חדש, ובכך תבטל את ההתחייבות לעסקת המשיכה כאשר אנשים הלכו לאמת אותה.
מכאן מתחילה תקופת ההצבעה של הכורים על הצעת הנסיגה. לאחר שהוצע צרור, הכורים יכולים להצביע אם לאשר אותם או לא. כל בלוק שנכרה מאפשר לאותו כורה להגדיל מונה אישורים, למעלה או למטה באחד, או שניים כדי להימנע מלעשות משהו. ישנן מספר מגבלות ספציפיות בנוסף לכך, מכיוון שניתן להחזיק יותר מחבילה אחת עבור רשת צד בודדת - אם כורה בוחר להצביע "כן" (להרים את המונה באחד) עבור חבילת משיכה עבור רשת צדדית צריך הצביעו "לא" (הנמיכו את המונה באחד) עבור כל חבילה אחרת המשויכת לשרשרת הצד הספציפית הזו.
זה כדי להבטיח שאין "משיכות כפולות", כאשר למישהו יש פלט בחבילות מרובות שישלם לו יותר ביטקוין ב-Mainchain ממה שמגיע לו.
מהצד השני, הכורים רשאים גם להצביע לא לכל צרור מוצע. זה אמור לתפקד כמעין אזעקה לכולם שכורה שמאמת את המשיכות הללו (מוודא שהם מטבעות בבעלות לגיטימית ב-sidechain שנמשך) הבחין במשהו לא חוקי שקורה. זכור, נקודת מפתח בעיצוב זה היא שכורים לא צריכים לאמת שום דבר ב-sidechain, אז אלא אם כן הם יבחרו בכל זאת, כורים רבים עשויים להצביע בעד חבילות שהם לא מאמתים. פונקציית אזעקה זו נועדה כדי לקבל התראה שהם צריכים לאמת את החבילות כדי להבטיח שלא מתרחשת משיכה במרמה.
ברגע שחבילה הגיעה לסף הנדרש (13,150 בלוקים, או בערך 90 יום), העסקה המעבדת בפועל את המשיכה הופכת לתוקף וניתן לאשר אותה. אבל מה אנשים עושים אם כורים מאשרים משיכה במרמה שגונבת כסף מה-sidechain? ההצעה של Sztorc היא לעסוק במזלג soft fork (UASF) המופעל על ידי משתמש כדי לבטל את עסקת ה-Pig-out הלא חוקית. זה מהווה סיכון עצום מבחינת קונצנזוס לרשת המרכזית. UASF ב-2017 היה מהלך בסיכון גבוה שרק בקושי הצליח והביטקוין היה קטן בהרבה ממה שהוא היום. ככל שהביטקוין יגדל יותר, כך יהיה קשה יותר לתאם פעולות כאלה.
אם אתה זוכר מה מאמר על שרשראות חלל, עיצוב זה התבסס על כרייה ממוזגת עיוורת (BMM). עיצוב ה-BMM של רובן סומסן הוא למעשה הגרסה השנייה של זה, הראשון הוא העיצוב של Sztorc כפי שנקבע ב-BIP301. מפרט ה-BMM ב-drivechains מורכב משתי הודעות: הודעת בקשה והודעת קבל. שניהם מתואמים בהתאמה באמצעות סוג עסקה מיוחד בשרשרת הראשית ופלט מיוחד בעסקת בסיס מטבעות של כורה.
עסקת הבקשה נבנית על ידי מי שיוצר בלוקים של שרשרת צד. כל הפואנטה של BMM היא שהאדם הזה יכול להיות מישהו שלא כורה, אז עסקת הבקשה היא שם כדי לאפשר להם לשלם לכורים כדי לאשר את חוסם ה-sidechain המוצע שלהם. הצעת בלוק ה-sidechain בונה טרנזקציה הכוללת את ה-hash של בלוק ה-sidechain, המזהה שהוקצה ל-sidechain כאשר הוא נוצר ואת ארבעת הבתים האחרונים של כותרת הבלוק הראשית הקודמת. ישנם שלושה כללי קונצנזוס נוספים החלים על סוגים אלה של עסקאות. ראשית, עסקת בקשה אינה חוקית אלא אם כן יש גם פלט קבלה תואם בטרנזקציית המטבעות של אותו בלוק. זאת על מנת להבטיח שכורים לא יוכלו לגבות עמלה מהבקשה מבלי לקבל ולכרות גם את בלוק ה-sidechain. שנית, עבור כל Sidechain מותר לכלול רק עסקת בקשה אחת בבלוק Mainchain. זאת על מנת להבטיח שרק בלוק אחד מכל רשת צד ניתן לכרות בפועל לכל בלוק ראשי. לבסוף, ארבעת הבייטים האחרונים של הבלוק הראשי הראשי חייבים להתאים. זה מבטיח שבקשה תקפה רק לכרייה בבלוק הבא, ולא ניתן לכרות עסקאות כאלה מאוחר יותר ולגנוב כסף ממציע בלוק צד צדדי לאחר שהבלוק של מישהו אחר נכרה.
הפלט לקבל הוא פשוט מאוד: נתוני כותרת הודעה וה-hash של בלוק ה-sidechain. אם כורה מפעיל בעצמו צומת Drivechain, הם יכולים פשוט להתעלם מעסקאות בקשות ולכלול תמיד פלט קבלה משלהם בבסיס המטבעות שלהם כדי לכרות את בלוקי ה-sidechain שלהם. יחד, שני ההיבטים הללו מאפשרים לכורים להפעיל צומת צד של שרשרת בעצמם, או אחר שאינו כורה לעשות זאת ולשלם לכורה כדי לכרות את הבלוקים שלהם. הרעיון הוא שאם הכורים בעצמם לא יפעילו את ה-sidechains ויאכלו את עלויות האימות הנוספות, אז מישהו אחר יכול לעשות זאת עבורם. אם יש תחרות בין אנשים שאינם כורים המנסים להרוויח עמלות על ה-sidechain, סביר להניח שהם ימשיכו להעלות את העמלה שהם מוכנים לשלם לכורים בעסקת הבקשה שלהם עד שתייצג את רוב העמלות שהם מרוויחים, כאשר הלא- כורה שומר רק על אחוז קטן מהרווח ומשלם את השאר לכורים.
זו המכניקה שמאחורי איך שרשראות ההינע מתפקדות. בשלב הבא, שרשרת צד מאוחדת, ולאחר מכן, לאחר מכן, פירוט של כל השליליים והחסרונות שיכולים להיות לכל עיצוב.
זהו פוסט אורח מאת Shinobi. הדעות המובעות הן לגמרי שלהם ואינן משקפות בהכרח את הדעות של BTC Inc או Bitcoin Magazine.
