วิธีประเมินรายงานการตรวจสอบสมาร์ตคอนแทรกต์

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

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

การตรวจสอบสมาร์ตคอนแทรกต์คืออะไร

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

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

ส่วนต่าง ๆ ของรายงานการตรวจสอบทั่วไป

ทีละขั้นตอน: วิธีประเมินรายงาน

1. ยืนยันว่ารายงานเป็นของจริง

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

2. เทียบขอบเขตกับสิ่งที่ดีพลอยจริง

รายงานควรระบุคอมมิตของโค้ดหรือที่อยู่สัญญา ตรวจสอบบนบล็อกเอ็กซ์พลอเรอร์ว่าสัญญาที่ดีพลอยตรงกัน ช่องว่างที่พบบ่อย:

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

3. อ่านสิ่งที่พบที่ร้ายแรงก่อน

ไปที่ปัญหาระดับวิกฤตและระดับสูงทันที สำหรับแต่ละข้อ ให้ถามว่า:

• ถูกระบุว่าแก้ไขแล้วหรือไม่ และผู้ตรวจสอบยืนยันการแก้ไขหรือไม่?
• หากเป็นเพียง “รับทราบ” แทนที่จะแก้ไข ทีมให้เหตุผลว่าอย่างไร?
• เกี่ยวข้องกับสิทธิ์ของผู้ดูแลระบบหรือไม่ เช่น ความสามารถในการมิ้นต์โทเคน หยุดการโอนชั่วคราว หรือถอนเงิน?

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

4. ตรวจสอบวันที่

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

5. ประเมินผู้ตรวจสอบ

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

6. อ่านข้อจำกัดความรับผิดชอบและข้อจำกัด

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

ทำความเข้าใจระดับความรุนแรง

ผู้ตรวจสอบส่วนใหญ่ใช้มาตรวัดที่คล้ายกัน แม้คำนิยามจะต่างกันไปในแต่ละบริษัท:

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

สัญญาณเตือนในรายงานการตรวจสอบ

• ไม่มีรายละเอียดขอบเขต แฮชของคอมมิต หรือที่อยู่สัญญา
• ปัญหาระดับวิกฤตถูกระบุว่า “รับทราบ” โดยไม่มีการแก้ไข
• สิ่งที่พบเกี่ยวกับสิทธิ์ของเจ้าของที่โปรเจกต์พยายามลดความสำคัญ
• รายงานโฮสต์อยู่แค่ที่โปรเจกต์
• คำโฆษณาอย่าง “ปลอดภัย 100%” หรือ “ปลอดภัยเต็มที่ด้วยการตรวจสอบ”
• การตรวจสอบลงวันที่ไว้นานก่อนการเปลี่ยนแปลงโค้ดครั้งใหญ่

สิ่งที่การตรวจสอบไม่ได้บอกคุณ

แม้การตรวจสอบที่ดีก็ไม่ได้ตอบคำถามเหล่านี้:

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

ใช้การตรวจสอบร่วมกับการตรวจสอบอื่น ๆ เช่น โปรแกรม bug bounty สาธารณะ การตรวจสอบอิสระหลายครั้ง ระยะเวลาใช้งานจริงที่ไม่มีเหตุการณ์ร้ายแรง และการควบคุมของผู้ดูแลระบบที่โปร่งใส

สรุป

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