ลายเซ็นว่างที่ทำให้ Bonzo Lend พัง: การวิเคราะห์หลังเหตุการณ์การโจมตี Hedera มูลค่า 9 ล้านดอลลาร์

ลายเซ็นว่างที่ทำให้ Bonzo Lend พัง: การวิเคราะห์หลังเหตุการณ์การโจมตี Hedera มูลค่า 9 ล้านดอลลาร์

2026/07/15 11:18:00
รูปภาพที่กำหนดเอง
ในคณิตศาสตร์และวิทยาการคอมพิวเตอร์ ศูนย์แทนความว่างเปล่า—การขาดหายอย่างสมบูรณ์ของค่าตัวเลข แต่ในระบบนิเวศของการเงินแบบกระจายศูนย์ (DeFi) ที่เปราะบางและเชื่อมต่อกันอย่างสูง พารามิเตอร์ "ศูนย์" ที่ไม่ได้รับการตรวจสอบเมื่อเร็วๆ นี้กลับกลายเป็นกุญแจหลักดิจิทัล ในเวลาเพียงไม่กี่นาที ค่าว่างเปล่าเดียวที่ไม่ได้รับการตรวจสอบนี้ได้เปิดใช้งานและดึงเงินกว่า 9 ล้านดอลลาร์สหรัฐออกจากแพลตฟอร์มให้กู้ยืมที่มีชื่อเสียง
 
ผู้เสียหายจากการโจมตีที่น่าสยดสยองครั้งนี้คือ Bonzo Lend ซึ่งเป็นโปรโตคอลการให้กู้ที่ใหญ่ที่สุดที่ดำเนินงานบนเครือข่าย Hedera ในเดือนกรกฎาคม 2026 โปรโตคอลนี้ต้องเห็นมูลค่ารวมที่ถูกล็อก (TVL) ลดลงอย่างน่าตกใจถึง 77% ในทันที เมื่อความตื่นตระหนกแพร่กระจายไปทั่วชุมชน Hedera ผู้สังเกตการณ์ต่างเร่งค้นหาแหล่งที่มาของการรั่วไหล
 
ที่สำคัญ ภัยพิบัตินี้ไม่ได้เกิดขึ้นเพราะระบบอนุญาตของ Hedera ล้มเหลว หรือเพราะการคำนวณการให้กู้หลักของ Bonzo Lend ผิดพลาด แต่ภัยพิบัตินี้เกิดจากช่องโหว่การผสานรวมที่ร้ายแรง: ข้อบกพร่องในการตรวจสอบลายเซ็นที่ร้ายแรงภายในผู้ให้บริการข้อมูลราคาภายนอกของพวกเขา คือ Supra Oracles นี่คือรายงานหลังเกิดเหตุเกี่ยวกับวิธีที่ข้อผิดพลาดทางตรรกะเล็กน้อยเกี่ยวกับ “สิ่งที่ไม่มีอยู่” ทำให้ยักษ์ใหญ่ด้าน DeFi ล้มลง

ลำดับเวลาของการโจมตี: จาก 5 ดอลลาร์เป็น 9,000,000 ดอลลาร์ในวินาที

การดำเนินการโจมตี Bonzo Lend มีความเฉียบแหลมด้วยความเรียบง่าย ต้องใช้ทุนเริ่มต้นน้อยมาก และเกิดขึ้นภายในไม่กี่ขั้นตอนการทำธุรกรรม
 
เพื่อเริ่มต้นการปล้น ผู้โจมตีได้ฝากหลักประกันจำนวนเล็กน้อยและไม่มีนัยสำคัญลงใน Bonzo Lend—โดยเฉพาะอย่างยิ่ง 250 โทเค็น SAUCE ในขณะที่ทำการฝาก หลักประกันนี้มีมูลค่าเพียงไม่กี่ดอลลาร์ น้อยกว่าที่จะซื้อกาแฟได้หนึ่งถ้วย ภายใต้กฎของโปรโตคอลปกติ จำนวนเงินเล็กน้อยนี้จะอนุญาตให้ผู้ใช้ยืมสินทรัพย์ดิจิทัลอื่นๆ ได้เพียงส่วนน้อยของมูลค่าของมัน
 
ถัดมา ผู้โจมตีเริ่มการโจมตีโดยข้ามการตรวจสอบของ price oracle พวกเขาสร้างและส่งคำสั่งอัปเดตราคาปลอมไปยังสัญญาการตรวจสอบของ oracle คำสั่งนี้มีข้อมูลที่เป็นอันตรายอย่างรุนแรง: มันทำให้ราคาของโทเค็น SAUCE เพิ่มขึ้นอย่างผิดปกติถึง 12 ลำดับขนาด—ซึ่งทำให้โปรโตคอลเชื่อว่าโทเค็น SAUCE หนึ่งหน่วยมีมูลค่าพันล้านดอลลาร์สหรัฐทันที
 
เพื่อผลักดันราคาปลอมนี้ผ่านไป ระบบต้องการลายเซ็นเชิงคริปโตจากโหนดออราเคิลที่ได้รับอนุญาต แทนที่จะพยายามทำลายระบบคริปโตกราฟีที่ซับซ้อนหรือขโมยคีย์ส่วนตัว ผู้โจมตีเพียงปล่อยช่องลายเซ็นไว้ว่าง และส่งสตริงของศูนย์แทนลายเซ็นเชิงคริปโต
 
เนื่องจากมีข้อบกพร่องร้ายแรงในตรรกะการตรวจสอบ สัญญาจึงยอมรับลายเซ็นว่างเป็นลายเซ็นที่ถูกต้อง ทันทีนั้น ระบบประเมินมูลค่าของ Bonzo ได้บันทึกหลักประกัน 250 SAUCE ของผู้โจมตีเป็นสินทรัพย์ที่มีมูลค่ามหาศาล ด้วยการใช้ความมั่งคั่งเทียมที่เกิดขึ้นทันที แฮกเกอร์จึงถอน USDC 6.63 ล้านเหรียญและ wHBAR 34.50 ล้านเหรียญออกจากสระสภาพคล่องของ Bonzo สำเร็จในการดูดเงินทุนของโปรโตคอลก่อนที่จะมีการแจ้งเตือนใดๆ

การเปิดเผยข้อบกพร่องของ "Zero-Signature": รหัสล้มเหลวอย่างไร

เพื่อเข้าใจว่าการโจมตีครั้งนี้เป็นไปได้อย่างไร เราต้องไขความลับทางคณิตศาสตร์ของลายเซ็นดิจิทัล ในเครือข่ายแบบกระจายศูนย์ ลายเซ็นเข้ารหัสทำหน้าที่เหมือนตราขี้ผึ้งดิจิทัล เมื่อโหนดออราเคิลเผยแพร่การอัปเดตราคา มันจะลงนามข้อมูลโดยใช้กุญแจส่วนตัว สัญญาอัจฉริยะที่ปลายทางจะใช้อัลกอริทึมการตรวจสอบเพื่อยืนยันว่าลายเซ็นตรงกับกุญแจสาธารณะที่ได้รับอนุญาตของโหนดออราเคิล
 
โดยทั่วไป หากผู้ใช้ส่งลายเซ็นที่ไม่ถูกต้อง ไลบรารีการตรวจสอบจะพยายามประมวลผลข้อมูลนำเข้าและล้มเหลว เมื่อไลบรารีการตรวจสอบทางคริปโตกราฟีพบข้อมูลนำเข้าที่เสียหาย ว่างเปล่า หรือเป็นศูนย์ทั้งหมด พวกมันไม่ได้เสมอไปที่จะแสดงข้อผิดพลาดอย่างชัดเจน แทนที่จะเป็นเช่นนั้น ไลบรารีมาตรฐานหลายตัวถูกออกแบบมาเพื่อส่งค่าเริ่มต้นเมื่อไม่สามารถแยกแยะลายเซ็นได้ ใน สัญญาอัจฉริยะ ค่าเริ่มต้นนี้เกือบจะเป็นที่อยู่ว่างเปล่าที่แสดงด้วยสตริงศูนย์ยาวๆ
 
จุดอ่อนร้ายแรงในสัญญาการตรวจสอบของ oracle อยู่ที่วิธีที่มันจัดการที่อยู่ค่าเริ่มต้นเป็นค่าว่างนี้ สัญญาถูกเขียนโปรแกรมให้ตรวจสอบว่าผู้ลงนามที่กู้คืนได้ตรงกับที่อยู่โหนด oracle ที่ได้รับอนุญาตหรือไม่ อย่างไรก็ตาม นักพัฒนาลืมรวมกฎพื้นฐานหนึ่งข้อ: ปฏิเสธข้อมูลใดๆ ที่มีความยาวลายเซ็นเป็นศูนย์หรือที่อยู่ที่กู้คืนได้คืนค่าเป็นค่าว่าง
 
ยิ่งไปกว่านั้น หากสถานะผู้ลงนามที่ได้รับอนุญาตภายในสัญญาไม่ได้รับการเริ่มต้นหรือกำหนดค่าในลักษณะที่อนุญาตให้มีการตรวจสอบค่าเป็นศูนย์ สัญญาจะเปรียบเทียบที่อยู่ศูนย์ที่ได้รับจากการลงนามล้มเหลวกับพารามิเตอร์ภายในของมันและประกาศว่าตรงกัน เนื่องจากตรรกะการตรวจสอบไม่สามารถแยกแยะระหว่าง “การกู้คืนลายเซ็นล้มเหลว” กับ “ผู้ลงนามที่ได้รับอนุญาตที่ถูกต้อง” สัญญาจึงถือว่าลายเซ็นว่างเปล่าเป็นสัญญาณสีเขียวอย่างสมบูรณ์ อนุมัติข้อมูลราคาปลอม

ปัญหาของออราเคิล: เหตุใดเลโก้ของ DeFi จึงแข็งแรงเท่ากับลิงก์ที่อ่อนแอที่สุด

DeFi มักได้รับการชื่นชมในเรื่อง “ความสามารถในการประกอบกัน” — ความสามารถของโปรโตคอล โทเค็น และเครื่องมือต่างๆ ในการเชื่อมต่อกันเหมือน “เลโก้ทางการเงิน” เพื่อสร้างแอปพลิเคชันทางการเงินที่ซับซ้อน แม้ว่าความสามารถในการประกอบกันจะช่วยเร่งนวัตกรรมอย่างรวดเร็ว แต่ก็ยังก่อให้เกิดความเปราะบางเชิงระบบ ข้อบกพร่องเพียงจุดเดียวในองค์ประกอบพื้นฐานสามารถทำให้โครงสร้างทั้งหมดล่มสลายได้
 
การโจมตี Bonzo Lend แสดงให้เห็นชัดเจนถึงช่องโหว่นี้ Bonzo Lend เองเป็น โปรโตคอลการให้กู้ ที่มีโครงสร้างดีและผ่านการตรวจสอบความปลอดภัยแล้ว อย่างไรก็ตาม โปรโตคอลนี้ต้องพึ่งพา oracle ภายนอกเพื่อให้ข้อมูลราคาที่ถูกต้อง ทันทีที่ระบบตรวจสอบของ oracle ยอมรับราคาเท็จ สัญญาการให้กู้ของ Bonzo ก็ทำงานตามที่เขียนไว้ ทำให้ผู้ใช้ที่มีหลักประกันหนักแน่นสามารถยืมสินทรัพย์ได้
 
ตารางด้านล่างแสดงการกระจายความรับผิดชอบเชิงโครงสร้างระหว่างการโจมตี ซึ่งแสดงจุดที่เส้นป้องกันล่มสลาย:
ส่วนประกอบ บทบาทของระบบโดยมีจุดประสงค์ ประสิทธิภาพระหว่างการถูกโจมตี บทเรียนเชิงโครงสร้าง
เลเยอร์การตกลงกันของ Hedera รักษาสถานะสมุดบัญชีให้ปลอดภัย จัดลำดับธุรกรรม และรักษาความพร้อมใช้งานของเครือข่าย ดำเนินการอย่างสมบูรณ์แบบโดยไม่มีเวลาหยุดทำงานหรือการโจมตีระดับเครือข่าย ชั้นการตกลงกันของเครือข่ายที่ปลอดภัยไม่รับประกันความปลอดภัยในระดับแอปพลิเคชัน
Supra Oracle ส่งข้อมูลราคาสินทรัพย์ที่ลงนามแล้ว ยืนยันทางคริปโตกราฟี และถูกต้อง ไม่สามารถปฏิเสธลายเซ็นที่เป็นค่าว่างได้ กำลังเผยแพร่ราคาที่เสียหาย ต้องจัดการกับการพึ่งพาด้วยรูปแบบการตรวจสอบแบบศูนย์ความเชื่อ
Bonzo ให้กู้ จัดการสินทรัพย์ที่ฝาก ติดตามอัตราส่วนสุขภาพของเงินกู้ และดำเนินการยืม เชื่อถือข้อมูลราคาที่เข้ามาโดยไม่ตั้งข้อจำกัดสำหรับการเพิ่มขึ้นอย่างฉับพลัน สัญญาอัจฉริยะต้องมีตรรกะป้องกันเพื่อให้สามารถอยู่รอดได้แม้เกิดความล้มเหลวของความพึ่งพา

การแทรกแซงของผู้สวมหมวกขาว: การแข่งขันกับแฮกเกอร์เพื่อชิงเงิน 1 ล้านดอลลาร์

ขณะที่การโจมตีเกิดขึ้นบนสมุดบัญชีสาธารณะ เหตุการณ์รองที่น่าตื่นเต้นก็เกิดขึ้นพร้อมกัน ในบล็อกเชนสาธารณะ รายการธุรกรรมจะมองเห็นได้ใน "mempool" ก่อนที่จะได้รับการยืนยัน ความโปร่งใสนี้ช่วยให้ผู้เล่นรายอื่น ทั้งที่มีเจตนาไม่ดีและมีเจตนาดี สามารถวิเคราะห์การโจมตีที่กำลังเกิดขึ้นแบบเรียลไทม์
 
ไม่นานหลังจากผู้โจมตีหลักเริ่มดูดทรัพยากรของโปรโตคอล นักวิจัยด้านความปลอดภัยอิสระ—ซึ่งมักเรียกว่า “ไวท์แฮต” แฮกเกอร์—สังเกตเห็นการโจมตีที่กำลังเกิดขึ้น รู้ว่าโปรโตคอลทั้งหมดกำลังจะถูกดูดหมด ไวท์แฮตจึงดำเนินการช่องโหว่แบบไม่มีลายเซ็นเดียวกันทันทีเพื่อถอนสินทรัพย์ประมาณ 1 ล้านดอลลาร์
 
กลยุทธ์นี้ ซึ่งเรียกว่า "การวิ่งนำหน้า" เป็นการเคลื่อนไหวป้องกันที่พบบ่อยในด้านความปลอดภัยของ Web3 โดยการรับเงินก่อน ผู้เชี่ยวชาญด้านขาวจึงป้องกันไม่ให้ผู้กระทำผิดขโมยส่วนหนึ่งของสระสภาพคล่อง
 
หลังจากการถอนเงินสำเร็จ แฮกเกอร์สีขาวทันทีติดต่อทีม Bonzo Lend หลังจากยืนยันตัวตนและเจตนาของพวกเขา แฮกเกอร์เชิงจริยธรรมได้คืนเงินทั้งหมด 1 ล้านดอลลาร์สหรัฐไปยังที่อยู่กู้คืนของโปรโตคอล แม้ว่าผู้โจมตีหลักยังคงหลบหนีไปพร้อมกับเงินส่วนใหญ่ แต่การแทรกแซงอย่างรวดเร็วนี้ช่วยรักษาส่วนสำคัญของสินทรัพย์ของชุมชน และแสดงให้เห็นถึงลักษณะเฉพาะของการรักษาความปลอดภัยใน Web3 ที่เน้นความร่วมมือ

ตามล่าหาล้าน: วิธีที่เงินที่ถูกขโมยออกจากระบบนิเวศของ Hedera

เมื่อแฮกเกอร์กู้ยืม USDC และ wHBAR มูลค่าหลายล้านดอลลาร์สหรัฐโดยใช้หลักประกันปลอม จุดมุ่งหมายหลักของพวกเขาจึงเปลี่ยนไปเป็นการหลบหนีออกจากระบบนิเวศ Hedera ก่อนที่โปรโตคอลจะระงับสัญญาของมัน
 
ผู้โจมตีไม่ได้เก็บสินทรัพย์ที่ถูกขโมยไว้ในรูปแบบเดิม โดยใช้ SaucerSwap แพลตฟอร์มแลกเปลี่ยนแบบกระจายศูนย์ที่ได้รับความนิยมบน Hedera แฮกเกอร์แลกเปลี่ยนโทเค็นที่ยืมมาเป็น Stablecoin และสินทรัพย์พื้นฐานที่มีสภาพคล่องสูงเพื่อหลีกเลี่ยงกลไกการระงับจากศูนย์กลาง
 
ทันทีหลังจากแลกเปลี่ยนโทเค็น ผู้โจมตีได้ใช้สะพานข้ามโซ่ โดยเฉพาะการส่งผ่าน LayerZero โดยการเชื่อมโยงสินทรัพย์ แฮกเกอร์ได้ย้ายเงินที่ขโมยมาเกินกว่า 5 ล้านดอลลาร์สหรัฐไปยัง Ethereum Mainnet โดยตรง
 
เมื่อสินทรัพย์ข้ามไปยังเครือข่ายขนาดใหญ่ที่มีสภาพคล่องสูงเช่น Ethereum การติดตามและกู้คืนสินทรัพย์เหล่านั้นจะยากขึ้นเป็นหลายเท่า funds สามารถแบ่งออกเป็นที่อยู่ใหม่นับร้อยแห่ง ฝากเข้าใน mixer ความเป็นส่วนตัวแบบกระจายอำนาจ หรือแลกเป็นสกุลเงินความเป็นส่วนตัวที่ไม่มีผู้ดูแล ช่องทางหลบหนีที่รวดเร็วและอัตโนมัตินี้แสดงให้เห็นว่าทำไมการติดตามแบบเรียลไทม์และการหยุดชั่วคราวทันทีจึงเป็นการป้องกันที่เป็นไปได้เพียงวิธีเดียวต่อการโจมตีข้ามโซ่ในยุคปัจจุบัน

บทเรียนที่ยาก: วิธีที่โปรโตคอล DeFi สามารถป้องกันตัวเองจากภัยพิบัติของ Oracle

การสูญเสียเงิน 9 ล้านดอลลาร์เป็นบทเรียนที่มีค่าใช้จ่ายสูงมาก แต่ให้ข้อมูลเชิงลึกที่มีค่าอย่างยิ่งแก่นักพัฒนาสัญญาอัจฉริยะที่ต้องการรักษาความปลอดภัยให้กับแอปพลิเคชันของตนจากข้อผิดพลาดในการผสานรวมในอนาคต
 
เพื่อป้องกันช่องโหว่ที่ไม่มีลายเซ็น นักพัฒนาต้องใช้แนวทางการเขียนโค้ดอย่างเข้มงวดและป้องกันไว้ล่วงหน้า การปรับปรุงโครงสร้างหลักประกอบด้วย:
  • การตรวจสอบที่อยู่เป็นค่า null อย่างชัดเจน: อย่าถือว่าฟังก์ชันการตรวจสอบลายเซ็นประสบความสำเร็จโดยอัตโนมัติ กระบวนการตรวจสอบทางคริปโตกราฟีทุกครั้งต้องตรวจสอบอย่างชัดเจนว่าความยาวของลายเซ็นมากกว่าศูนย์ และยืนยันว่าที่อยู่ผลลัพธ์ไม่ได้แก้ค่าเป็นค่า null (0x00...00) หากได้ค่า null กลับมา รายการธุรกรรมต้องยกเลิกทันที
  • สถาปัตยกรรม Oracle ที่ซ้ำซ้อน: การพึ่งพาผู้ให้บริการ oracle เพียงรายเดียวสร้างจุดล้มเหลวเพียงจุดเดียว โปรโตคอล DeFi ที่มั่นคงควรดึงราคาสินทรัพย์จากเครือข่าย oracle ที่เป็นอิสระหลายแห่ง (เช่น Chainlink, Pyth และ Supra พร้อมกัน) หากข้อมูลหนึ่งรายการเบี่ยงเบนอย่างมีนัยสำคัญจากค่ามัธยฐานของข้อมูลอื่นๆ โปรโตคอลควรแจ้งเตือนความไม่สอดคล้องกันและหยุดการทำงานโดยอัตโนมัติ
  • ตัวป้องกันราคาบนโซ่: โปรโตคอลการให้กู้ยืมต้องมีการจำกัดอัตราและขอบเขตความเบี่ยงเบนของราคา แม้ว่าออราเคิลจะอ้างว่ามูลค่าโทเค็นเพิ่มขึ้นหนึ่งล้านล้านเท่าในหนึ่งบล็อก เซอร์กิตเบรกเกอร์ภายในสัญญาอัจฉริยะควรปฏิเสธการอัปเดตนี้เป็นข้อผิดพลาด และหยุดการกู้ยืมหรือการชำระบัญชีทุกอย่างจนกว่าจะมีการตรวจสอบด้วยตนเองโดยผู้ดูแลระบบ

อนาคตของการตรวจสอบสัญญาอัจฉริยะ: เหตุใดเราจึงต้องทดสอบขีดจำกัด

การโจมตี Bonzo Lend เปิดให้เห็นข้อจำกัดที่ร้ายแรงในแนวทางการตรวจสอบความปลอดภัยของ Web3 ปัจจุบัน การตรวจสอบความปลอดภัยหลายครั้งมุ่งเน้นไปที่การยืนยันว่าตรรกะทางธุรกิจของสัญญาทำงานได้ภายใต้เงื่อนไขที่คาดหวัง—มักเรียกว่าการทดสอบแบบ "happy-path"
 
อย่างไรก็ตาม ผู้โจมตีในโลกจริงไม่ได้ปฏิบัติตามเส้นทางที่เป็นไปได้ตามปกติ พวกเขาค้นหาโดยเฉพาะอย่างยิ่งเงื่อนไขขอบ เงื่อนไขที่ยังไม่ได้รับการเริ่มต้น และข้อมูลขาเข้าที่ไม่คาดคิด วงการด้านความปลอดภัยต้องเปลี่ยนไปสู่การทดสอบกรณีขอบอย่างรุนแรง เพื่อค้นหาข้อบกพร่องที่ซ่อนอยู่ก่อนที่โค้ดจะถูกเปิดใช้งานบน Mainnet
 
เพื่อให้บรรลุเป้าหมายนี้ โปรโตคอลต้องทำให้วิธีการทดสอบขั้นสูง เช่น การฟัซซิงและการตรวจสอบอย่างเป็นทางการ เป็นมาตรฐานบังคับ การฟัซซิงเกี่ยวข้องกับการใช้เครื่องมืออัตโนมัติเพื่อส่งข้อมูลเข้าสู่สัญญาอัจฉริยะเป็นจำนวนล้านๆ รายการที่สุ่ม ผิดรูปแบบ และว่างเปล่า — รวมถึงสตริงไบต์ว่างและลายเซ็นเป็นค่าว่าง หากสัญญาการตรวจสอบถูกทดสอบด้วยการฟัซซิงอย่างเข้มงวด การหลีกเลี่ยงด้วยลายเซ็นศูนย์จะถูกแจ้งเตือนทันที
 
ในที่สุด ผู้ให้บริการ oracle ของบุคคลที่สามต้องยอมรับมาตรฐานความปลอดภัยที่สูงขึ้นด้วย เนื่องจากข้อมูลเหล่านี้ทำหน้าที่เป็นรากฐานสำหรับกิจกรรมทางเศรษฐกิจหลายร้อยล้านดอลลาร์ รหัสการตรวจสอบของพวกเขาจึงต้องได้รับการพิจารณาอย่างรอบคอบเทียบเท่ากับเครือข่ายระดับหนึ่งที่พวกเขาสนับสนุน

ข้อสรุป: การฟื้นฟูความเชื่อมั่นในระบบนิเวศที่ไม่ต้องพึ่งความเชื่อ

การโจมตี Bonzo Lend เป็นการเตือนให้ระลึกถึงธรรมชาติที่ไม่ยอมให้อภัยของสัญญาอัจฉริยะ ใน Web3 โค้ดคือกฎหมาย และ EVM ไม่ได้สนใจเจตนาของคุณ ช่องว่างทางตรรกะเล็กน้อยเกี่ยวกับ "สิ่งที่ไม่มีอะไร" สามารถลบล้างการพัฒนาหลายปีและทรัพย์สินหลายล้านดอลลาร์ที่ผู้ใช้ไว้วางใจได้ทันที
 
หลังจากการโจมตี ทั้ง Bonzo Lend และ Supra Oracles ได้เร่งดำเนินการแก้ไขช่องโหว่และรักษาความปลอดภัยโครงสร้างพื้นฐานที่เหลืออยู่ แม้ว่าเหตุการณ์นี้จะเจ็บปวด แต่บทเรียนที่ได้รับจะนำไปสู่มาตรฐานการผสานรวมที่ปลอดภัยยิ่งขึ้นในทุกพื้นที่ของ DeFi สำหรับนักพัฒนาและนักลงทุน alike ข้อสรุปที่สำคัญที่สุดคือเรียบง่าย: อย่าเคยถือว่าความปลอดภัยของการผสานรวมเป็นเรื่องแน่นอน ทดสอบขีดจำกัดของโค้ดของคุณ และตรวจสอบให้แน่ใจเสมอว่าเกิดอะไรขึ้นเมื่อคุณไม่ป้อนข้อมูลใดๆ เลยเข้าสู่ระบบของคุณ

คำถามที่พบบ่อย:

Q1: ข้อบกพร่อง “Zero-Signature” หมายความว่าการเข้ารหัสของบล็อกเชนถูกทำลายแล้วหรือไม่?

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

Q2: ทำไม Bonzo Lend จึงเชื่อถือราคาของ SAUCE ที่ถูกปั่นสูงเกินจริงอย่างไม่น่าเชื่อโดยอัตโนมัติ?

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

Q3: ผู้ใช้ DeFi ทั่วไปสามารถทำอะไรเพื่อป้องกันตัวเองจากการถูกโจมตีที่เกี่ยวข้องกับ oracle?

แม้ผู้ใช้จะควบคุมโค้ดของโปรโตคอลไม่ได้ แต่สามารถจัดการความเสี่ยงของตนเองได้ เพื่อปกป้องทุนของคุณ ให้กระจายสินทรัพย์ของคุณไปยังแพลตฟอร์มอิสระหลายแห่ง หลีกเลี่ยงโปรโตคอลที่พึ่งพาแหล่งข้อมูลเดียวสำหรับสินทรัพย์เฉพาะทาง และเลือกแพลตฟอร์มที่มีระบบออราเคิลหลายแหล่งที่ผสานรวมอย่างเปิดเผยและระบบปิดกั้นฉุกเฉินบนโซ่ที่แข็งแกร่ง
 
ข้อจำกัดความรับผิด: เนื้อหานี้มีจุดประสงค์เพื่อการให้ข้อมูลเท่านั้น และไม่ถือเป็นคำแนะนำในการลงทุน การลงทุนในคริปโตเคอเรนซีมีความเสี่ยง โปรดทำการวิจัยด้วยตัวเอง (DYOR)

คำปฏิเสธความรับผิดชอบ: หน้านี้แปลโดยใช้เทคโนโลยี AI เพื่อความสะดวกของคุณ สำหรับข้อมูลที่ถูกต้องที่สุด โปรดดูต้นฉบับภาษาอังกฤษ