סיכוני Reentrancy ב-BIP-110 בשלב הסיגנלינג

BIP-110 התחלת איתות חובה עם תמיכה לא מספקת של כורי הכורה

הצעת השיפור Bitcoin Improvement Proposal 110 נכנסה לשלב האיתות החובה שלה החל מחסום 961,632. במהלך שלב זה, צמתים שמאכפים את BIP-110 החלו לדחות חסימות שלא הגדירו את ביט הגרסה 4. עם זאת, תמיכת הכורים ב-BIP-110 נותרה נמוכה בהרבה מיתר דרישות ההפעלה; הכורים איתתו תמיכה רק ב-2.53% מתוך 2,016 החסימות שקדמו לחלון הנוכחי, הרחק מתחת לסף של 55% הנדרש להפעלה מוקדמת. שיעור אימוץ נמוך זה הוביל להופעת שרשרת מיעוט BIP-110 זמנית אך זו התדרדרה במהירות מאחורי שרשרת הביטקוין הדומיננטית.

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

המגבלות הטכניות של BIP-110 ומשמעויותיהן על קיבולת הנתונים

BIP-110 מבקש להטיל מגבלות ספציפיות על גודל וסוגי הנתונים המותרים בעסקאות ביטקוין, תוך התמקדות בעיקר בשליטה על גידול של נתונים שאינם עסקה. הוא מציע להגביל רוב הסקריפטים החדשים של ביציאות ל-34 בייט, להגביל את ביציאות OP_RETURN ל-83 בייט, ולהגביל דחיפות מסוימות של נתונים ואלמנטים של witness לגודל מירבי של 256 בייט.

// קוד דמיוני בסגנון Solidity להמחשת בדיקת גודל דומה
function validateOutputScriptSize(bytes memory outputScript) internal pure returns (bool) {
    // אכיפת גודל מירבי של 34 בייט לרוב הסקריפטים החדשים
    if (outputScript.length > 34) {
        revert("Output script size exceeds 34 bytes limit");
    }
    return true;
}

function validateOpReturnSize(bytes memory opReturnData) internal pure returns (bool) {
    // אכיפת גודל נתוני OP_RETURN עד 83 בייט
    if (opReturnData.length > 83) {
        revert("OP_RETURN data exceeds 83 bytes limit");
    }
    return true;
}

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

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

תמיכת הכורים ודינמיקת הקונצנזוס המשוקפת בחלון האיתות של BIP-110

חלון האיתות של BIP-110 מתפרש מחסימות 961,632 עד 963,647, שבמהלכו הכורים חייבים לאותת על מוכנות באמצעות ביט גרסה 4 כדי להתקדם לקראת הפעלה. עמידה בדרישת האיתות קריטית שכן סף התמיכה של 55% בכורים הוא התנאי להפעלה מוקדמת ולאכיפה סופית.

למרות שקיימות כללי אכיפה למערכת האיתות החובה, שיעור ההשתתפות הנמוך של הכורים—רק כ-2.53% מהחסימות הקודמות—מצביע על תמיכה מוגבלת ואתגרים לקבלה רחבה ברשת. בהתאמה, נוצרה ענף מיעוט של BIP-110 אך הוא הוברח במהירות על ידי השרשרת הראשית, מה שממחיש את הקושי בהפעלת שינויים מעוררי מחלוקת ללא הסכמה רחבה.

מחלוקת וביקורת סביב BIP-110 בקהילת הביטקוין

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

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

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

אפשרויות גיבוי ומצב הפיתוח של קוד התמיכה ב-BIP-110

פיתוח משני הקשור ל-BIP-110 הוא האתחול מחדש של קוד שינוי fallback proof-of-work (PoW) שביצע מפתח ביטקוין כריס גוידה ב-1 באוגוסט, המבוסס על עבודת ראשונית של מנהל Bitcoin Knots לוק דאשר. שינוי ה-PoW הזה מוגדר כאפשרות גיבוי במידה וכורים יתנגדו להפעלת BIP-110.

// קוד דמיוני בסגנון Solidity המתאר מנגנון fallback מופשט
contract PoWFallback {
    bool public bip110Rejected;

    function checkPoWChange() external view returns(bool) {
        if (bip110Rejected) {
            // הפעלת חוקי fallback PoW
            return true;
        }
        return false;
    }
}

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

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

השוואה: מגבלות הנתונים של BIP-110 מול מגבלות נתונים טיפוסיות בחוזים חכמים

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

התבוננות אבטחתית על Reentrancy ומגבלות גודל נתונים בפרוטוקולי בלוקצ’יין

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

// דפוס פגיע פשוט של reentrancy
contract VulnerableContract {
    mapping(address => uint256) public balances;

    function withdraw(uint256 amount) external {
        require(balances[msg.sender] >= amount, "Insufficient balance");

        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Failed to send Ether");

        balances[msg.sender] -= amount; // עדכון מצב אחרי קריאה חיצונית – פגיע
    }
}

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

// דפוס בטוח: עדכון מצב לפני הקריאה
function withdraw(uint256 amount) external {
    require(balances[msg.sender] >= amount, "Insufficient balance");

    balances[msg.sender] -= amount; // עדכון מצב לפני קריאה חיצונית

    (bool success, ) = msg.sender.call{value: amount}("");
    require(success, "Failed to send Ether");
}

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

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

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

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

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