ความเสี่ยง Reentrancy Attack ในช่วงสัญญาณ BIP-110

BIP-110 เริ่มบังคับสัญญาณพร้อมกับการสนับสนุนนักขุดที่ไม่เพียงพอ

Bitcoin Improvement Proposal 110 เริ่มเข้าสู่ช่วงบังคับสัญญาณตั้งแต่บล็อกที่ 961,632 เป็นต้นไป ในช่วงเวลานี้ โหนดที่บังคับใช้ BIP-110 จะเริ่มปฏิเสธบล็อกที่ไม่ได้ตั้งค่า version bit 4 อย่างไรก็ตาม การสนับสนุนจากนักขุดต่อ BIP-110 ยังคงต่ำกว่าขั้นต่ำที่ต้องการอย่างมาก โดยนักขุดสัญญาณสนับสนุนเพียง 2.53% ของ 2,016 บล็อกก่อนหน้าช่วงเวลานี้ ซึ่งต่ำกว่าค่าที่ต้องการเพื่อการเปิดใช้ในระยะต้นที่ 55% อย่างมาก การยอมรับที่ต่ำนี้ทำให้เกิดโซ่ BIP-110 ส่วนน้อยขึ้นชั่วคราวแต่ไม่นานก็ถูกโซ่ Bitcoin หลักที่โดดเด่นกว่าดึงหน้าไปได้

BIP-110 เสนอข้อจำกัดชั่วคราวเกี่ยวกับขนาดข้อมูล payload และผลลัพธ์ของธุรกรรมใน Bitcoin เพื่อป้องกันการบันทึกข้อมูลที่ไม่ใช่การเงินซึ่งเพิ่มภาระทรัพยากรของโหนด แม้ว่าการบังคับใช้สัญญาณบังคับจะเริ่มที่บล็อก 961,632 แต่ข้อจำกัดของธุรกรรมตามข้อเสนอจะเริ่มมีผลจริงที่บล็อก 965,664 ก็ต่อเมื่อมีการเห็นชอบจากนักขุดเพียงพอ

ข้อจำกัดเชิงเทคนิคของ BIP-110 และผลกระทบต่อความจุข้อมูล

BIP-110 มุ่งกำหนดขีดจำกัดเฉพาะเกี่ยวกับขนาดและประเภของข้อมูลที่อนุญาตในธุรกรรม Bitcoin โดยเน้นไปที่การควบคุมการเติบโตของข้อมูลที่ไม่เกี่ยวข้องกับธุรกรรมหลัก ข้อเสนอจำกัดสคริปต์เอาต์พุตใหม่ส่วนใหญ่ไว้ที่ 34 ไบต์ จำกัดขนาดเอาต์พุต OP_RETURN ไม่เกิน 83 ไบต์ และจำกัดการดันข้อมูลบางอย่างและ witness อยู่ที่ 256 ไบต์

// ตัวอย่าง pseudocode แบบ 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) ที่ถูกสร้างก่อนการเปิดใช้จะได้รับการยกเว้นจากข้อจำกัดใหม่เหล่านี้เพื่อลดผลกระทบทันทีต่อผู้ใช้ Bitcoin และสมาร์ตคอนแทรกต์ที่มีอยู่

เนื่องจากข้อจำกัดเหล่านี้มีเป้าหมายลดธุรกรรมที่มีข้อมูลมาก การนำไปใช้จริงอาจส่งผลกระทบต่อรูปแบบการเขียนสคริปต์และวิธีการฝังข้อมูลที่นักพัฒนากำลังใช้ในปัจจุบัน รวมไปถึงอาจส่งผลต่อ NFTs หรือโครงสร้างชั้นข้อมูลที่พึ่งพาขนาดเอาต์พุตที่ใหญ่กว่า

การสนับสนุนจากนักขุดและพลวัตของความเห็นพ้องต้องกันตามช่วงสัญญาณ BIP-110

ช่วงเวลาสัญญาณสำหรับ BIP-110 ครอบคลุมบล็อกที่ 961,632 ถึง 963,647 ซึ่งในช่วงนี้นักขุดต้องส่งสัญญาณความพร้อมผ่าน version bit 4 เพื่อให้ดำเนินการเปิดใช้ได้ การปฏิบัติตามการส่งสัญญาณเป็นสิ่งจำเป็นเพราะการสนับสนุนนักขุด 55% คือเกณฑ์ที่กำหนดสำหรับการเปิดใช้ก่อนกำหนดและการบังคับใช้ขั้นสุดท้าย

แม้ว่ากฎระเบียบบังคับสัญญาณจะถูกนำมาใช้แล้ว แต่สัดส่วนการมีส่วนร่วมของนักขุดที่ต่ำมาก — เพียงราว 2.53% ของบล็อกก่อนหน้า — ชี้ให้เห็นว่าการสนับสนุนยังมีจำกัดและเป็นอุปสรรคต่อการยอมรับในวงกว้าง ภาพนี้แสดงให้เห็นการเกิดโซ่ BIP-110 ส่วนน้อยที่ปรากฏขึ้นแต่ถูกโซ่หลักแซงหน้าอย่างรวดเร็ว ซึ่งสะท้อนถึงความยากลำบากในการเปิดใช้การเปลี่ยนแปลงที่มีความขัดแย้งโดยไร้ความเห็นพ้องกว้างขวาง

ความขัดแย้งและคำวิจารณ์เกี่ยวกับ BIP-110 ภายในระบบนิเวศ Bitcoin

BIP-110 ได้รับคำวิจารณ์อย่างมากจากบุคคลสำคัญในชุมชน Bitcoin รวมถึง Michael Saylor ประธานเจ้าหน้าที่ฝ่ายกลยุทธ์ และ Adam Back ซีอีโอของ Blockstream ผู้วิจารณ์เชื่อว่าข้อเสนอนี้เสี่ยงต่อการแตกแยกเครือข่าย Bitcoin โดยทำให้โหนดที่ใช้ BIP-110 ปฏิเสธธุรกรรมที่ถูกต้องตามกฎเดิม ส่งผลให้เกิดการแยกสายโซ่

คำวิจารณ์นี้สะท้อนถึงความสมดุลที่ละเอียดอ่อนระหว่างการอัปเกรดเครือข่ายที่ต้องการบังคับใช้ข้อจำกัดที่เข้มงวดเพื่อความปลอดภัยหรือการจัดการทรัพยากร และความสำคัญของการรักษาความเห็นพ้องเพื่อหลีกเลี่ยงความขัดแย้ง ในกรณีนี้ การบังคับใช้สัญญาณบังคับและการปฏิเสธบล็อกที่ไม่ส่งสัญญาณของ BIP-110 แสดงสถานการณ์ที่ไม่ปกติซึ่งทำให้เกิดโซ่ส่วนน้อยชั่วคราวก่อนที่โซ่ส่วนใหญ่จะเหนือกว่า

การถกเถียงนี้สะท้อนความตึงเครียดที่กว้างกว่าสำหรับการบริหารจัดการบล็อกเชนระหว่างการพัฒนาที่นำโดยนักพัฒนาและความเต็มใจของนักขุดที่จะยอมรับการเปลี่ยนแปลงเหล่านี้ โดยเฉพาะเมื่อข้อเสนอนั้นจำกัดข้อมูลธุรกรรมและกำหนดกฎการตรวจสอบใหม่

แผนสำรองและสถานะการพัฒนาของโค้ดสนับสนุน BIP-110

การพัฒนาที่เกี่ยวข้องกับ BIP-110 คือการปรับฐานโค้ดการเปลี่ยนแปลง fallback proof-of-work (PoW) โดยนักพัฒนา Bitcoin, Chris Guida เมื่อวันที่ 1 สิงหาคม โดยอิงจากงานเบื้องต้นของผู้ดูแล Bitcoin Knots คือ Luke Dashjr การเปลี่ยนแปลง fallback PoW นี้เป็นแผนสำรองในกรณีนักขุดไม่เห็นด้วยกับการเปิดใช้ BIP-110

// Pseudocode แบบ 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 ที่จำกัดขนาดข้อมูลธุรกรรมสอดคล้องกับแนวปฏิบัติที่ดีที่สุดที่พบในการพัฒนาสมาร์ตคอนแทรกต์ซึ่งการลดพื้นผิวการโจมตีและการใช้ทรัพยากรเป็นเรื่องสำคัญ จากประสบการณ์ของเราใน Soken การกำหนดข้อจำกัดขนาดข้อมูลอย่างเข้มงวดช่วยลดความเสี่ยง เช่น การโจมตี reentrancy ที่ใช้ payload ขนาดใหญ่มากเกินไปหรือไม่คาดคิด แม้ว่า environment ของ scripting ใน Bitcoin จะแตกต่างจากสมาร์ตคอนแทรกต์แบบ Ethereum อย่างมาก แต่แนวปฏิบัติในการจำกัดความซับซ้อนของข้อมูลและบังคับใช้กฎตรวจสอบด้วยความเห็นพ้องนั้นยังสำคัญอย่างยิ่ง

การเปรียบเทียบ: ข้อจำกัดข้อมูลใน BIP-110 เทียบกับข้อจำกัดข้อมูลของสมาร์ตคอนแทรกต์ทั่วไป

การเน้นชัดเจนใน BIP-110 เกี่ยวกับการลดข้อมูลที่ไม่จำเป็นสะท้อนหลักการเดียวกับความปลอดภัยสมาร์ตคอนแทรกต์ที่ต้องการลดช่องทางการใช้ผิดหรือใช้ทรัพยากรเกินจำเป็น

ข้อคิดด้านความปลอดภัยเกี่ยวกับการโจมตีแบบ reentrancy และข้อจำกัดขนาดข้อมูลในโปรโตคอลบล็อกเชน

แม้ BIP-110 จะไม่ได้แก้ปัญหาช่องโหว่ reentrancy แบบคลาสสิก — ซึ่งเป็นปัญหาที่พบในสมาร์ตคอนแทรกต์ที่สามารถเขียนโปรแกรมได้ — ข้อจำกัดข้อมูลของ BIP-110 มีส่วนช่วยในด้านสุขอนามัยความปลอดภัยโดยลดความซับซ้อนและขนาดของสคริปต์ธุรกรรม ในสมาร์ตคอนแทรกต์สถานะซับซ้อน การโจมตีแบบ 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 ในระดับโปรโตคอล Bitcoin

การดำเนินการเพื่อเปิดใช้ BIP-110 สะท้อนถึงความซับซ้อนของการเปลี่ยนแปลงทางเทคนิค ความเห็นพ้องของนักขุด และการยอมรับในชุมชนในโปรโตคอลบล็อกเชนหลัก การติดตามความคืบหน้าผ่านการบังคับสัญญาณและการสนับสนุนนักขุดที่แทบไม่มีเลยชี้ให้เห็นถึงความสำคัญของการมีส่วนร่วมอย่างกว้างขวางสำหรับการเปลี่ยนแปลงที่ต้องอาศัยความเห็นพ้อง ข้อจำกัดขนาดข้อมูลตามข้อเสนอยังสื่อสารถึงข้อกังวลต่อเนื่องเกี่ยวกับความยั่งยืนของบล็อกเชนและภาระทรัพยากรโหนด ซึ่งเป็นธีมที่สอดคล้องกับความปลอดภัยและการออกแบบสมาร์ตคอนแทรกต์

สำหรับนักพัฒนาและสถาปนิกโปรโตคอล การเข้าใจผลกระทบเชิงปฏิบัติต่อข้อจำกัดข้อมูลดังกล่าวสามารถช่วยชี้แนะแนวทางการออกแบบสมาร์ตคอนแทรกต์ให้สอดคล้องกับข้อจำกัดของเครือข่าย พร้อมทั้งป้องกันความเสี่ยงอย่างเช่นช่องโหว่ reentrancy ล่วงหน้า การสำรวจพลวัตเหล่านี้ผ่านงานตรวจสอบและการวิเคราะห์ความปลอดภัยอย่างละเอียดของ Soken ช่วยเปิดเผยความสัมพันธ์ลึกซึ้งและสนับสนุนการพัฒนาที่มั่นคง ทนทานสำหรับ Bitcoin และเครือข่ายอื่นๆ ต่อไป

องค์กรที่ผสานการอัปเกรดหรือพัฒนาคอนแทรกต์บนโปรโตคอล Bitcoin ที่กำลังพัฒนา จะได้รับประโยชน์จากการประเมินกฎความปฏิบัติตามอย่างสม่ำเสมอเช่น BIP-110 โดยพิจารณาทั้งผลกระทบด้านทรัพยากรและความเป็นไปได้ของความเห็นพ้อง การติดตามพัฒนาการกลไก fallback อย่างต่อเนื่องยังช่วยเตรียมความพร้อมสำหรับสถานะเครือข่ายทางเลือกที่อาจเกิดขึ้นจากข้อพิพาทเกี่ยวกับการอัปเกรด

กรณีนี้ยืนยันบทบาทสำคัญของการวิเคราะห์ความปลอดภัยสมาร์ตคอนแทรกต์อย่างครอบคลุม แม้ในสภาพแวดล้อม scripting ที่ค่อนข้างคงที่ของ Bitcoin ก็จำเป็นต้องมีการตรวจสอบร่วมกับข้อเสนออัปเกรดที่เกิดขึ้นใหม่ การใช้ความเชี่ยวชาญข้ามโปรโตคอลของ Soken ช่วยเปิดเผยช่องทางภัยคุกคามและความซับซ้อนของความเห็นพ้อง ช่วยให้โครงการต่างๆ สามารถออกแบบแอปบล็อกเชนที่ปลอดภัย ทำงานร่วมกันได้ และคาดการณ์เทรนด์โปรโตคอลและการเปลี่ยนแปลงที่ขับเคลื่อนโดยนักขุดได้อย่างมีประสิทธิภาพ