TL;DR

  • กลุ่มปัญหาเล็กๆ ที่เกิดขึ้นซ้ำๆ เป็นสาเหตุหลักของความสูญเสียในชั้นสัญญา: reentrancy, การ manipulations oracle, ความล้มเหลวในการควบคุมการเข้าถึง, ข้อผิดพลาดทางคณิตศาสตร์และการตรวจสอบความถูกต้อง, และตรรกะธุรกิจที่มีข้อบกพร่องซึ่งทำงานตามโค้ดที่เขียนไว้ทุกประการ แต่ละกลุ่มปัญหามีตัวอย่างกรณีที่โด่งดังเป็นตัวอย่าง ซึ่งนี่คือวิธีที่อุตสาหกรรมเรียนรู้ที่จะตั้งชื่อให้พวกมัน
  • การตรวจสอบจะวิเคราะห์ภาพถ่ายนิ่งของโค้ดเทียบกับประเภทช่องโหว่ที่ทราบแล้วและเจตนาที่ทีมได้ระบุไว้ ภายในงบประมาณชั่วโมงการทำงานของผู้เชี่ยวชาญ; ส่วนอื่นๆ เกือบทั้งหมด เช่น เศรษฐกิจ ออราเคิล การกำกับดูแล การดำเนินงาน ความพึ่งพา และอนาคต ล้วนอยู่นอกกรอบการตรวจสอบ การอ่านส่วนขอบเขตในรายงานการตรวจสอบให้ข้อมูลมากกว่าการอ่านตราสัญลักษณ์ของมัน
  • เพราะการกระจายความสูญเสียตามสิ่งที่การตรวจสอบไม่ครอบคลุม: การเปลี่ยนแปลงหลังการตรวจสอบ, ส่วนประกอบที่ถูกยกเว้น, การโต้ตอบระหว่างโปรโตคอล, การดำเนินงานที่ถูกบุกรุก และการออกแบบทางเศรษฐกิจ, นอกเหนือจากข้อบกพร่องที่เหลืออยู่ซึ่งการสุ่มตัวอย่างไม่สามารถตรวจพบได้โดยหลีกเลี่ยงไม่ได้ รายชื่อโปรโตคอลที่ผ่านการตรวจสอบแต่ถูกแฮ็กนั้นยาวพอที่จะกลายเป็นประเภทหนึ่งได้
  • มีหลายชั้นและสมมติว่ามีความล้มเหลว: การตรวจสอบหลายครั้งอย่างอิสระ, วิธีการอย่างเป็นทางการและเทคนิค fuzzing ในจุดที่เสี่ยง, การเฝ้าติดตามอย่างต่อเนื่อง, กลไกตัดวงจรทางเศรษฐกิจ, การเปลี่ยนแปลงที่มีล็อกเวลา, โปรแกรมให้รางวัลสำหรับผู้ค้นพบข้อบกพร่อง, และแผนการซ้อมไว้สำหรับวันที่ระบบถูกเจาะ แต่ละชั้นจะจับข้อบกพร่องในรูปแบบที่แตกต่างกัน ซึ่งเป็นจุดสำคัญของการจัดชั้น
ในบล็อกเดียว

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

อะไรที่จริง ๆ แล้วทำให้สัญญาอัจฉริยะล้มเหลว?

ตอบด่วน

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

Reentrancy เป็นกรณีคลาสสิก สัญญาอัจฉริยะส่งมูลค่าไปยังที่อยู่ภายนอกก่อนที่จะอัปเดตสถานะของตัวเอง และผู้รับ ซึ่งเป็นสัญญาอัจฉริยะอีกตัวหนึ่ง เรียกกลับเข้ามา ก่อนที่การอัปเดตจะเสร็จสิ้น ทำให้มูลค่าถูกดึงออกไปในวงจรซ้ำๆ การแฮ็ก DAO ในปี 2016 ซึ่งมูลค่าความเสียหายประมาณ 60 ล้านดอลลาร์ในขณะนั้น ได้ก่อให้เกิดกรณีนี้และทำให้ Ethereum แบ่งออกเป็นสองส่วน หนึ่งทศวรรษต่อมา reentrancy ยังคงปรากฏตัวอยู่ บางครั้งในรูปแบบที่แปลกประหลาด: เหตุการณ์ Curve ปี 2023 ที่สูญเสียเงินประมาณ 70 ล้านดอลลาร์ในหลายพูล เกิดจากความล้มเหลวของกลไกป้องกัน reentrancy ภายในเวอร์ชันเฉพาะของคอมไพเลอร์ Vyper เอง ซึ่งหมายความว่าสัญญาที่มีตรรกะต้นฉบับถูกต้องถูกคอมไพล์เป็น bytecode ที่ไม่ถูกต้อง ผู้ตรวจสอบที่อ่านโค้ดต้นฉบับอาจมองข้ามปัญหานี้ไปโดยไม่รู้ตัว

การโจมตีแบบ Oracle มุ่งเป้าไปที่ข้อมูลนำเข้า สัญญาที่เชื่อถือข้อมูลราคาสามารถถูกขโมยได้โดยการบิดเบือนราคา และ flash loans จัดหาทุนสำหรับการบิดเบือนภายในธุรกรรมอะตอมิกเดียว Mango Markets ซึ่งสูญเสียประมาณ 114 ล้านดอลลาร์ในปี 2022 เป็นกรณีตัวอย่างที่ชัดเจน และกลไกการโจมตีนี้ยังคงเกิดขึ้นเป็นประจำ; ส่วนหลักของกลุ่มนี้วิเคราะห์รูปแบบการโจมตีดังกล่าว

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

ข้อผิดพลาดทางคณิตศาสตร์และการตรวจสอบความถูกต้องยังคงเกิดขึ้นแม้จะมีภาษาโปรแกรมที่ปลอดภัยขึ้น Cetus ซึ่งเป็น DEX ที่ใหญ่ที่สุดบน Sui ถูกโจมตีจนสูญเสียเงินประมาณ 223 ล้านดอลลาร์ในเดือนพฤษภาคม 2025 เนื่องจากมีการตรวจสอบการล้นค่า (overflow check) ที่เปรียบเทียบกับค่าคงที่ผิด ทำให้ค่าที่ถูกสร้างขึ้นเป็นพิเศษผ่านการตรวจสอบความถูกต้องและทำให้การคำนวณสภาพคล่องเสียหาย ตามรายงานวิเคราะห์หลังเหตุการณ์ สัญญาดังกล่าวได้รับการตรวจสอบความปลอดภัยมากกว่าหนึ่งครั้ง ผลลัพธ์หลังเหตุการณ์มีความสำคัญที่ควรบันทึกไว้: เงินประมาณ 162 ล้านดอลลาร์ถูกแช่แข็งผ่านการดำเนินการร่วมกันของผู้ตรวจสอบความถูกต้อง และถูกโอนเข้าสู่กระบวนการกู้คืนและชดเชยผ่านการลงคะแนนของชุมชน มูลค่าที่ถูกโจมตีทั้งหมดและมูลค่าที่ถูกแช่แข็งหรือโอนเข้าสู่กระบวนการกู้คืนควรรายงานแยกกัน และตัวเลขขาดทุนสุทธิสุดท้ายควรระบุได้ก็ต่อเมื่อมีบัญชีที่มีวันที่ชัดเจนแล้วเท่านั้น ไม่ใช่การคาดการณ์

สุดท้ายคือข้อผิดพลาดทางตรรกะล้วนๆ: โค้ดที่คอมไพล์ได้ ผ่านการทดสอบ ทำตามที่ระบุไว้ แต่กลับให้ผลลัพธ์ที่ผิด Euler Finance สูญเสียเงิน 197 ล้านดอลลาร์ในปี 2023 เนื่องจากกลไกการบริจาคถูกผสานกับตรรกะการชำระบัญชีในลักษณะที่ไม่มีบรรทัดโค้ดใดแสดงให้เห็นอย่างชัดเจน คลาสนี้ไม่มีตัวสแกน เพราะไม่มีสิ่งใดที่ผิดพลาดทางเทคนิค ยกเว้นแนวคิดเท่านั้น

การตรวจสอบ (audit) จริงๆ แล้วตรวจสอบอะไร และอะไรที่อยู่นอกขอบเขตตามการออกแบบ?

ตอบด่วน

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

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

ข้อจำกัดทางโครงสร้างควรระบุไว้อย่างชัดเจน การตรวจสอบเป็นแบบจุดเวลา (point-in-time): commit ที่ได้รับการตรวจสอบคือสิ่งที่ถูกตรวจสอบจริง ส่วนการอัปเกรดที่ปล่อยออกมาสามเดือนต่อมาไม่ได้ถูกรวมอยู่ด้วย การตรวจสอบมีขอบเขตจำกัด: สัญญาที่เกี่ยวข้องโดยตรง สคริปต์การปรับใช้ เครื่องมือบริหารจัดการ และการบูรณาการมักถูกยกเว้นเนื่องจากข้อจำกัดด้านงบประมาณ การตรวจสอบนี้เต็มไปด้วยสมมติฐาน: รายงานมักสมมติว่า oracles เป็นแหล่งข้อมูลที่ซื่อสัตย์, tokens เป็นค่าที่สมเหตุสมผล และกุญแจผู้ดูแลระบบเป็นกุญแจที่เชื่อถือได้ ซึ่งสมมติฐานเหล่านี้คือสิ่งที่ผู้โจมตีไม่ยอมรับเลย การตรวจสอบนี้ไม่คำนึงถึงด้านเศรษฐกิจ เว้นแต่จะมีการซื้อการตรวจสอบด้านเศรษฐกิจแยกต่างหาก: ความสามารถในการชำระหนี้ภายใต้การถูกจัดการ, ความล้มเหลวของแรงจูงใจ และการรวมระบบที่เป็นพิษกับโปรโตคอลอื่นที่ทำงานอยู่ เป็นสาขาวิชาที่ต่างออกไป นอกจากนี้ การตรวจสอบนี้ยังมีความลึกของสแต็กที่จำกัด: คอมไพเลอร์, เครื่องเสมือน และซอฟต์แวร์โหนดที่อยู่ด้านล่างแทบจะไม่ถูกรวมอยู่ในขอบเขตการตรวจสอบเลย ซึ่งนี่คือจุดที่เหตุการณ์ Curve เกิดขึ้น

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

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

Diagram of smart contract audit scope showing reviewed code at the centre surrounded by out-of-scope risks including oracles, upgrades, governance, economics, compiler and operations
รูป 1. สิ่งที่การตรวจสอบสัญญาอัจฉริยะครอบคลุม และพื้นที่ความเสี่ยงที่อยู่นอกกรอบการตรวจสอบ

ทำไมโปรโตคอลที่ผ่านการตรวจสอบแล้วยังสูญเสียเงินหลายร้อยล้าน?

ตอบด่วน

เพราะการกระจายความสูญเสียตามสิ่งที่การตรวจสอบไม่ครอบคลุม: การเปลี่ยนแปลงหลังการตรวจสอบ, ส่วนประกอบที่ถูกยกเว้น, การโต้ตอบระหว่างโปรโตคอล, การดำเนินงานที่ถูกบุกรุก และการออกแบบทางเศรษฐกิจ, นอกเหนือจากข้อบกพร่องที่เหลืออยู่ซึ่งการสุ่มตัวอย่างไม่สามารถตรวจพบได้โดยหลีกเลี่ยงไม่ได้ รายชื่อโปรโตคอลที่ผ่านการตรวจสอบแต่ถูกแฮ็กนั้นยาวพอที่จะกลายเป็นประเภทหนึ่งได้

ข้อมูลล่าสุดทำให้รูปแบบนี้สามารถวัดได้เชิงปริมาณ TRM Labs นับได้ 207 เหตุการณ์ในช่วงครึ่งแรกของปี 2026 ซึ่งเป็นจำนวนสูงสุดเป็นประวัติการณ์ แต่ยอดความสูญเสียรวมอยู่ต่ำกว่า 1 พันล้านดอลลาร์ ลดลง 58 เปอร์เซ็นต์เมื่อเทียบกับปีก่อน; การโจมตีสัญญาอัจฉริยะคิดเป็นประมาณ 60 เปอร์เซ็นต์ของเหตุการณ์ทั้งหมด แต่คิดเป็นสัดส่วนเล็กน้อยของมูลค่าความสูญเสีย ในขณะที่การโจมตีโครงสร้างพื้นฐาน กุญแจ สภาพแวดล้อมการลงนาม และการเข้าถึงการดำเนินงาน คิดเป็นประมาณ 76 เปอร์เซ็นต์ของเงินที่สูญเสียไป จากเหตุการณ์ประมาณ 15 เปอร์เซ็นต์ ตัวเลขในปี 2025 บอกเล่าเรื่องราวเดียวกันอย่างชัดเจนยิ่งขึ้น: มีเงินถูกขโมยไปประมาณ 3.4 พันล้านดอลลาร์ โดยส่วนใหญ่มาจากการโจรกรรม Bybit มูลค่า 1.5 พันล้านดอลลาร์ ซึ่งโจมตีกระบวนการลงนามแทนที่จะโจมตีสัญญาใด ๆ ผู้โจมตีจะย้ายไปยังชั้นที่อ่อนแอที่สุด และจากการตรวจสอบมาหลายปี ทำให้ข้อบกพร่องในสัญญาเป็นเป้าหมายที่ยากต่อการโจมตีเมื่อเทียบกับการโจมตีด้านปฏิบัติการ

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

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

Chart comparing smart contract exploits at sixty percent of incidents with a small share of losses against infrastructure and key compromises at fifteen percent of incidents and seventy-six percent of value, per TRM Labs
รูป 2. ครึ่งแรกของปี 2026: สัดส่วนจำนวนเหตุการณ์เทียบกับสัดส่วนมูลค่าตามประเภทการโจมตี

ระบบความปลอดภัยที่จริงจังจะมีลักษณะอย่างไรนอกเหนือจากการตรวจสอบ?

ตอบด่วน

มีหลายชั้นและสมมติว่ามีความล้มเหลว: การตรวจสอบหลายครั้งอย่างอิสระ, วิธีการอย่างเป็นทางการและเทคนิค fuzzing ในจุดที่เสี่ยง, การเฝ้าติดตามอย่างต่อเนื่อง, กลไกตัดวงจรทางเศรษฐกิจ, การเปลี่ยนแปลงที่มีล็อกเวลา, โปรแกรมให้รางวัลสำหรับผู้ค้นพบข้อบกพร่อง, และแผนการซ้อมไว้สำหรับวันที่ระบบถูกเจาะ แต่ละชั้นจะจับข้อบกพร่องในรูปแบบที่แตกต่างกัน ซึ่งเป็นจุดสำคัญของการจัดชั้น

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

รางวัล Bug Bounty เปลี่ยนตลาด: ข้อเสนอที่เปิดรับอย่างต่อเนื่อง ซึ่งมีมูลค่าที่สอดคล้องกับความเสี่ยงอย่างเหมาะสม มอบรางวัลทางกฎหมายให้กับนักวิจัยที่ค้นพบข้อบกพร่อง ซึ่งสามารถแข่งขันได้กับรายได้จากอาชญากรรม รางวัล Bug Bounty ที่ใหญ่ที่สุดใน DeFi ได้จ่ายออกไปหลายล้าน และถือว่ามีต้นทุนต่ำเมื่อเทียบกับมูลค่าที่ได้รับ

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

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

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

ผู้เชี่ยวชาญควรอ่านรายงานการตรวจสอบอย่างไร?

ตอบด่วน

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

เริ่มจากขอบเขตก่อน: สัญญาใด, commit ใด, สิ่งใดถูกยกเว้น, และ bytecode ที่ถูก deploy ตรงกับโค้ดที่ได้รับการตรวจสอบหรือไม่; เครื่องมือ block explorer ทำให้การตรวจสอบเป็นไปได้จริง และความไม่ตรงกันเกิดขึ้นบ่อยพอที่จะตรวจสอบเป็นประจำ การตรวจสอบ commit A ไม่กล่าวถึง commit B

อ่านสมมติฐานเหมือนรายชื่อพื้นผิวการโจมตี "เราสมมติว่าผู้ดูแลระบบเป็นคนซื่อสัตย์" หมายความว่าความเสี่ยงจากการถูกเจาะกุญแจผู้ดูแลระบบเป็นความเสี่ยงที่คุณต้องประเมิน "พฤติกรรมของ Oracle อยู่นอกขอบเขต" หมายความว่าแบบแผน Mango ยังไม่ได้รับการตรวจสอบ ทุกสมมติฐานที่ระบุไว้คือขอบเขตที่การตรวจสอบหยุดลง และขอบเขตคือจุดที่ผู้โจมตีมักหาช่องโหว่

ประเมินผลการตรวจสอบจากวิธีการตอบสนองมากกว่าจากจำนวนข้อบกพร่อง รายงานที่มีข้อบกพร่องระดับวิกฤตที่แก้ไขแล้วสิบสองข้ออาจสะท้อนถึงทีมที่ทุ่มเทและผู้ตรวจสอบที่ละเอียดถี่ถ้วน ส่วนรายงานที่ไม่มีข้อบกพร่องอาจสะท้อนถึงการตรวจสอบที่ผิวเผิน รูปแบบที่น่ากังวลคือข้อบกพร่องที่ได้รับการยอมรับแต่ยังคงถูกปล่อยออกไป หรือถูกแก้ไขด้วยวิธีที่ผู้ตรวจสอบไม่เคยตรวจสอบซ้ำ ตรวจสอบว่ามีการตรวจสอบซ้ำหลังการแก้ไขหรือไม่ เพราะข้อบกพร่องที่เกิดจากการแก้ไขเป็นปัญหาที่มักเกิดขึ้นซ้ำ

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

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

คำถามที่มักถูกถาม

โปรโตคอลที่ผ่านการตรวจสอบแล้วปลอดภัยที่จะใช้หรือไม่?

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

ทำไมไม่ทำการตรวจสอบจนกว่าจะไม่มีจุดอ่อนเหลือให้ค้นพบ?

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

ความแตกต่างระหว่างการตรวจสอบ (audit) และการตรวจสอบอย่างเป็นทางการ (formal verification) คืออะไร?

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

โปรแกรมรางวัลสำหรับบั๊ก (bug bounties) ทำงานได้จริงหรือไม่?

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

ในฐานะผู้ใช้ ตัวชี้วัดที่ดีที่สุดเพียงอย่างเดียวที่สะท้อนวัฒนธรรมความปลอดภัยของโปรโตคอลคืออะไร?

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

แหล่งข้อมูลและข้อมูลเพิ่มเติม

แหล่งอ้างอิงหลักสำหรับบทความนี้ อัปเดต ณ เดือนกรกฎาคม 2026 ตัวเลขที่ผันผวนจะได้รับการตรวจสอบใหม่ทุกครั้งในการทบทวนรายไตรมาส

แบบทดสอบด่วน: มันติดไหม?

คำถามสองสามข้อเพื่อตรวจสอบพื้นฐานที่มาถึง คำตอบพร้อมคำอธิบายจะตามมา และไม่มีใครให้คะแนนคุณนอกจากผลงานในอนาคตของคุณ

คำถาม 1/5
การตรวจสอบสัญญาอัจฉริยะ (smart contract audit) คืออะไรกันแน่?

ข้อมูลนี้มีประโยชน์ไหม