מנגנוני ממשל הביטקוין: פורקים רכים, BIPs והסכמה של מפתחים

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

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

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


הבסיס לשינוי: מערכת הצעות שיפור הביטקוין (BIP)

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

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

אנטומיה של BIP

BIP הוא מסמך מובנה המתאר שינוי, תכונה או שיפור עיצוב ספציפיים לביטקוין. לכל BIP מוקצה מספר רציף (למשל, BIP 1, BIP 341) והוא חייב לעמוד בדרישות מחמירות כדי להיחשב תקף. דרישות אלה מבטיחות בהירות, תקפות טכנית ובחינה יסודית של השפעות לוואי.

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

  1. מוטיבציה: מדוע נדרש שינוי זה? איזו בעיה הוא פותר?
  2. מפרט: הפרטים הטכניים של איך ייושם השינוי בקוד. זה חייב להיות מדויק מספיק כדי שמפתחים מכל העולם יוכלו לקודד נגדו.
  3. תאימות לאחור: האם שינוי זה ישבור תאימות עם גרסאות ישנות יותר של התוכנה? (זה קובע אם השינוי דורש פורק רך או פורק קשה.)

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

תפקיד מפתחי הליבה והמתחזקים

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

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

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

מדוע תהליך ה-BIP הוא חיכוך נדרש

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

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

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

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


שתי הדרכים לשינוי פרוטוקול: פורקים רכים לעומת פורקים קשים

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

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

פורקים רכים: שדרוג התואם לאחור

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

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

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

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

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

פורקים קשים: האופציה הגרעינית

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

אם פורק קשה מופעל, הרשת מתפצלת ממש לשתי שרשראות נפרדות:

  1. השרשרת החדשה: עוקבת אחר קבוצת הכללים החדשה (למשל, גדלי בלוקים גדולים משמעותית).
  2. השרשרת הישנה: ממשיכה לעקוב אחר הכללים המקוריים.

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

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

מבחן הממשל: מדוע חוששים מפורקים קשים

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

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

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


השגת הסכמה: סיגנלינג, ביקורת ואכיפה

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

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

כורים לעומת צמתים: שתי צורות כוח האימות

בממשל הביטקוין, חשוב להבחין בין שני סוגי בעלי כוח:

1. כורים (כוח האשינג)

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

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

2. צמתים מלאים (כוח אכיפה)

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

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

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

מנגנון הפעלה: תפקיד הסיגנלינג

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

גישה נפוצה כוללת שלב סיגנלינג רב-תקופתי, המכונה לעיתים "סיגנלינג יום דגל":

  1. תחילת הסיגנלינג: הקוד החדש משוחרר, וכורים מתחילים לסמן את מוכנותם דרך ראשי בלוקים.
  2. תקופת סף: הרשת צופה במספר קבוע של בלוקים (למשל, 2,016 בלוקים, או כשבועיים).
  3. הפעלה: אם הסף הנדרש (למשל, 95%) מהבלוקים האלה מסמנים מוכנות, השעון מתחיל לתקתק לנעילה בפועל. כמה אלפי בלוקים מאוחר יותר (מספק תקופת חסד), הכלל החדש מופעל לצמיתות.

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

פורקים רכים מופעלים על ידי משתמשים (UASFs): כאשר המשתמשים תופסים את ההגה

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

זה הוביל למושג של פורק רך מופעל על ידי משתמשים (UASF).

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

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

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

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

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


מקרי בוחן בממשל הביטקוין: שיעורים שנלמדו

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

SegWit (BIP 141): מחקר בחיכוך ובפשרה

Segregated Witness, או SegWit, היה אולי הפורק הרך השנוי במחלוקת ביותר בהיסטוריה של ביטקוין. הוצע ב-2015 והופעל בסופו של דבר ב-2017, הדיון של שנתיים מדגיש את הקושי העצום לביצוע שינויים שאינם טריוויאליים.

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

הפתרון: הפתרון כלל שלוש אסטרטגיות ממשל מקבילות:

  1. הסכמה של מפתחים (בחירת פורק רך): מפתחים התעקשו על פורק רך (BIP 141) כדי להימנע מסיכון פיצול השרשרת.
  2. הסכמה כלכלית (הסכם ניו יורק): נעשה ניסיון לפשרה, בעיקר עם עסקים מרכזיים (SegWit2x), אך זה נכשל בסופו של דבר מחמת חוסר אימוץ משתמשים.
  3. כוח משתמשים (UASF/BIP 148): איום ה-UASF היה הגורם המכריע. על ידי סימון נכונות המשתמשים לדחות בלוקים לא תואמים, המשתמשים הוכיחו שהם מחזיקים בכוח הסופי על כללי הרשת.

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

Taproot (BIPs 340, 341, 342): ההצלחה השקטה של Speedy Trial

השוו את ההפעלה הסוערת של SegWit ל-Taproot, שדרוג גדול שהופעל ב-2021. Taproot סיפק שיפורים משמעותיים לפרטיות, יעילות ויכולות חוזה חכם. בשל השיעורים שנלמדו מ-SegWit, תהליך הממשל של Taproot נוצר באמצעות שיטת הפעלה חדשה: Speedy Trial.

מנגנון Speedy Trial: במקום נעילה בזמן קבוע טיפוסי, Speedy Trial קבע סף סיגנלינג של 90% על פני תקופת שבועיים, אך הוא כלל גם תאריך תפוגה.

  • אם 90% מהכורים סימנו תמיכה בחלון, השינוי ינעל במהירות (הצלחה ב-Speedy Trial).
  • אם הסף לא הושג, התהליך ייכשל, ויאלץ את הקהילה לחזור למסגרת השרטוט – פוטנציאלית לשקול גישה UASF שנויה במחלוקת מאוחר יותר.

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

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


ליבת המבוזרות: מדוע הממשל חייב להיות מבולגן

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

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

עלות השינוי לעומת ערך הצפויות

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

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

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

חוסר היעילות של הממשל הוא המחיר שמשלמים להשגת סופיות מטבעית ואמון מבוזר.

תורת המשחקים של נהיגה בפרוטוקול

האבטחה של ממשל הביטקוין מבוססת בסופו של דבר על תורת המשחקים – מחקר קבלת החלטות אסטרטגית בין גופים מתחרים.

לכל משתתף ברשת הביטקוין (כורים, מפתחים ומשתמשים) יש תמריץ מובהק:

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

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

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