รู้จัก นักตรวจสอบโค้ด! ในโลกคริปโท “Smart Contract Security Audit”

รู้จัก นักตรวจสอบโค้ด! ในโลกคริปโท “Smart Contract Security Audit”

══════════════

มีนักตรวจสอบโค้ดแล้วยังไง? ไฉนเรื่องการแฮ็กไม่จบไม่สิ้น ทั้งที่แทบจะทุกโปรเจกต์ก็ผ่านการ Audit มาแล้วหนิ! ทันทีที่อ่านบทความนี้จบคุณจะเข้าใจเลยว่า โปรเจกต์ใดๆ แม้ผ่านมือเหล่า Auditor แต่มันจะยังมีแง่มุมของ "ความเสี่ยงที่นักพัฒนายอมรับได้” อีกนะ! สิ่งนี้หมายความว่า ผู้สอบได้แจ้งความเสี่ยงไปแล้วส่วนจะแก้ไขหรือไม่ “บังคับไม่ได้” และนี่เองคือจุดสำคัญที่ชาวคริปโทต้องรู้!

.

.

Ethereum บล็อกเชนหลักที่จุดพลุการใช้งานบล็อกเชน - โปรเจกต์ DeFi

.

Ethereum นั้นถือเป็นบล็อกเชน (Blockchain) หลักอันหนึ่งที่ถูกเริ่มใช้งานมาตั้งแต่ปี 2013 โดยมีส่วนแตกต่างจากบล็อกเชนแบบดั้งเดิมในหลายๆ ส่วน แต่ส่วนที่สร้างความแตกต่างจากบล็อกเชนโดยปกติได้มากที่สุด นั่นคือการเพิ่มส่วนของ EVM (Ethereum Virtual Machine) เข้ามาในระบบ

.

EVM เป็นระบบที่ทำให้บล็อกเชนนั้นสามารถจำสถานะ machine state หรือก็คือกลายเป็นระบบคอมพิวเตอร์ขึ้นมา ซึ่งระบบดังกล่าวทำให้ใครก็สามารถจะเขียนการโปรแกรมบนระบบ Ethereum ได้ ซึ่ง โปรแกรมดังกล่าวถูกเรียกในชื่อ smart contract หรือที่เราคุ้นหูกับคำว่า “สัญญาอัจฉริยะ” นั่นเอง

.

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

.

จุดนี้เองถือเป็นก้าวสำคัญที่ทำให้เทคโนโลยีบล็อกเชน กลายเป็นโครงสร้างเทคโนโลยีสำคัญของโลกและระบบทางการเงินแบบไร้ศูนย์กลาง (DeFi) การมาของ Ethereum จึงเปิดโอกาสให้ใครก็สามารถดำเนินการสร้างระบบทางการเงินและระบบต่างๆ มากมายให้เกิดขึ้นได้ในโลกของบล็อกเชนไม่ว่าจะเป็น DeFi, GameFi และอื่นๆ อีกมากมาย

.

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

.

การที่จะให้ developer ซึ่งเป็นคนเขียน smart contract เองแถมยังต้องทำหน้าที่ตรวจสอบยืนยันตัวเองว่าโปรแกรมปลอดภัยก็ใช่เรื่อง จึงเป็นที่มาของการกำเนิดบริษัทหรือหน่วยงานที่ตรวจสอบ smart contract เหล่านั้นว่ามีความเสี่ยงหรือไม่ และมีการดำเนินงานตามที่ผู้พัฒนาได้กล่าวจริงหรือไม่ นั่นจึงเป็นที่มาของการเกิดสิ่งที่เรียกว่า “Smart Contract Security Audit” นั่นเอง

.

อะไรคือ “Smart Contract Security Audit”?

.

Smart contract security audits ถือเป็นเรื่องปกติที่ต้องทำ สำหรับการดำเนินการธุรกิจในสายของระบบทางการเงินแบบไร้ตัวกลาง (DeFi) เพราะด้วยความที่ DeFi นั้นเป็นระบบที่พยายามจะมาแทน ลักษณะการทำงานแบบต่างๆ ของระบบทางการเงินดั้งเดิม ไม่ว่าจะเป็นการฝาก-ถอน, การแลกเปลี่ยน, การลงทุนในกองทุนและอื่นๆ ดังนั้น โปรเจกต์ DeFi ต่างๆ จึงจำเป็นต้องแสดงถึงความโปร่งใสของระบบตัวเอง

.

แน่นอนว่าพอเป็นระบบ DeFi นั่นหมายความว่า โปรแกรมทั้งหมดจะถูกเขียนในรูปแบบของ smart contract แล้วนำไปใช้งานบนระบบบล็อกเชน เมื่อเป็นแบบนั้นแล้วจะทราบได้อย่างไรล่ะว่า DeFi ที่บอกว่าได้ผลตอบแทนสูงๆ นั้นปลอดภัยจริงหรือไม่ ไม่ใช่เรื่องหลอกลวง หรือนักพัฒนาเขียนโค้ดได้อย่างปลอดภัยจริงๆ

.

โดยปกติแล้วผู้ใช้งานทั่วไปมักจะไม่สามารถอ่าน smart contract ได้ ดังนั้น ไม่มีทางที่จะตรวจสอบ smart contract ได้เองว่าปลอดภัยหรือไม่ ประกอบกับนักพัฒนาเองก็คงไม่สามารถมาบอกได้ว่า smart contract นั้นปลอดภัยเพราะตัวเองก็เป็นคนพัฒนาเอง ดังนั้น จึงจำเป็นต้องหาหน่วยงานอื่นมาช่วยยืนยันให้แทน นั่นคือ “Smart Contract Security Auditor Firm” หรือ “บริษัทให้บริการการตรวจสอบ smart contract” นั่นเอง

.

“Smart contract security auditor เป็นผู้ที่ต้องเข้าใจถึงวิธีการเขียนและเข้าใจถึงการดำเนินงานของ smart contract และระบบที่ตรวจสอบอย่างชัดเจนแบบที่สุด เพื่อให้สามารถเข้าใจถึง scenario การดำเนินงานต่างๆ ที่จะถูกดำเนินการโดยระบบดังกล่าวและนำไปสู่การประเมินความเสี่ยงที่อาจจะเกิดขึ้นได้ในแง่มุมต่างๆ และรวมถึงการดำเนินงานของ smart contract นั้นตรงกับที่ผู้คิดค้นระบบได้ประกาศไว้ใน white paper หรือไม่”

.

ขั้นตอน ของกระบวนการ audit smart contract

.

.

เริ่มต้นด้วยการทำความเข้าใจ smart contract ของระบบก่อน

.

ในหลายๆ ครั้งนักพัฒนามักจะมองข้ามส่วนสำคัญของระบบไปนั่นคือ เอกสารที่เกี่ยวข้องกับโปรเจกต์เหล่านั้น ไม่ว่าจะเป็น flow ของแอปพลิเคชัน, whitepaper ที่ไม่ได้เขียนกระบวนการดำเนินงานในส่วนต่างๆ ,ความชัดเจนของ business requirement เป็นต้น ซึ่งนั่นทำให้การตรวจสอบนั้นจำเป็นต้องใช้เวลามากขึ้น เพราะสืบเนื่องด้วยทางผู้ตรวจสอบจำเป็นต้องทำความเข้าใจระบบเหล่านั้นด้วยตัวเองนั่นเอง

.

ดำเนินการตรวจสอบหาความเสี่ยงของ smart contract

.

หลายๆ คนอาจจะมองว่าการดำเนินการ smart contract security audit นั้นเป็นการค้นหาช่องโหว่ที่อาจเกิดขึ้นได้กับระบบนั้นๆ แต่เปล่าเลย! จริงๆ แล้ว smart contract security auditor นั้นเป็น “ผู้หาความเสี่ยงทางด้านความปลอดภัย” ให้เสียมากกว่า

.

ดังนั้น การตรวจสอบ smart contract จะไม่ได้เป็นเพียงการแนะนำในการป้องกันช่องโหว่ของระบบที่อาจเกิดขึ้นได้เท่านั้น (สามารถดูรายละเอียด top 10 dasp vulnerability ได้ที่ https://dasp.co/) ยังรวมถึงการเขียน smart contract ใดๆ ที่อาจส่งผลให้เกิดผลกระทบของการดำเนินงานของ dasp ในแง่มุมต่างๆ อีกด้วย

.

ซึ่งในหลายๆ ครั้งความเสี่ยงเหล่านั้นไม่เพียงแค่มองไปที่การดำเนินงานของ user เท่านั้น แต่รวมถึง admin หรือก็คือ high privilege user นั่นเอง

.

ยกตัวอย่าง transferOwnership function เป็นฟังก์ชันสำหรับการ transfer ownership ของ smart contract ดังกล่าวให้ผู้อื่น แต่จะเกิดอะไรขึ้น หากเราใส่ address ผิดล่ะ? เพราะหากเราใส่ address ผิดเพียงตัวอักษรเดียวอาจทำให้ smart contract ไม่สามารถดำเนินการได้อีกเลยก็เป็นไปได้

.

ดังนั้น เราอาจจะต้องมีระบบป้องกันการผิดพลาดขึ้นมาเพื่อลดความเสี่ยงดังกล่าวนั่นเอง โดยยกตัวอย่างการแก้ไขให้ทำระบบย้าย ownership ใหม่ โดยการเพิ่มระบบส่วนของการ claim smart contract ก่อนที่จะเปลี่ยนเจ้าของอย่างทันที เพื่อป้องกันความผิดพลาดนั่นเอง ซึ่งจากตัวอย่างดังกล่าวจะเห็นว่า “ความเสี่ยงของระบบ จึงไม่ใช่มีเพียงแค่เรื่องของช่องโหว่เท่านั้น”

.

ทาง Auditor แจ้งความเสี่ยงและวิธีการแก้ไขให้ทาง developer ได้รับทราบ

.

หลังจากดำเนินการตรวจสอบเรียบร้อยแล้ว ทางทีมงานนักพัฒนาจำเป็นต้องแก้ไขในส่วนใดบ้าง และวิธีการแก้ไขเป็นอย่างไร ซึ่งในเรื่องของวิธีการแก้ไขนั้นขึ้นอยู่กับความเชี่ยวชาญของ auditor เองว่า จะดำเนินการในลักษณะการแนะนำโดยคร่าวๆ (generic recommendation) หรือเป็นลักษณะของ code ตัวอย่างการแก้ไข (example fixed code) โดยนักพัฒนาสามารถที่จะเลือกว่าจะแก้ไขหรือไม่ก็ได้ ขึ้นอยู่กับทีมงานนักพัฒนาและเหตุผลในทางธุรกิจ

.

“อย่างไรก็แล้วแต่ smart contract auditor ก็ต้องดำเนินการระบุสถานะการแก้ไขดังกล่าวใน report เช่นเดียวกัน ดังนั้น ในหลายๆ ครั้งจะพบว่าใน report ของ smart contract auditor จะระบุไว้เป็น acknowledged /confirmed เท่านั้น เพราะ developer นั้นไม่ดำเนินการแก้ไขด้วยเหตุผลทาง business นั่นเอง ซึ่งถือว่าเป็นการยอมรับความเสี่ยงของทีมงานเจ้าของ platform นั้นๆ นั่นเอง”

.

และในการรับความเสี่ยงครั้งนี้ ก็อาจส่งผลตามมาในภายหลังก็เป็นได้เช่นเดียวกัน ยกตัวอย่าง กรณีล่าสุดที่เกิดขึ้นเมื่อวันที่ 2 ธันวาคม 2022 ที่โปรเจกต์ Ankr protocol ถูกแฮ็ก และต้องสูญเงินไปถึง 5 ล้านดอลลาร์ ซึ่งจาก twitter ของ CZ, CEO ของ Binance นั้นเหตุเกิดจาก private key ของ developer นั้นหลุดไปทำให้ผู้โจมตีสามารถไปดำเนินการชี้ไปยัง smart contract ใหม่ได้

.

ซึ่งในประเด็นนี้จริงๆ แล้ว auditor ระดับโลกอย่าง Peckshield เคยแจ้งในตอนทำ audit ไปแล้ว [6] แต่ทาง Ankr protocol ก็ยังเลือกที่จะใช้ private key เดียวแบบเดิม ไม่มีการใช้งาน multi-sig ตามที่ Peckshield แนะนำแต่อย่างใด นั่นหมายความว่า Peckshield ได้แจ้งความเสี่ยงดังกล่าวไปแล้ว และ Ankr protocol ก็เลือกที่จะยอมรับความเสี่ยง (Accept the risk) นั้น โดยไม่มีการแก้ไขใดๆ และด้วยความเสี่ยงดังกล่าวนำไปสู่การถูกโจมตีในที่สุดนั่นเอง

.

“และแม้ว่าสถานะจะเป็น acknowledged/confirmed แต่ทีมงานเจ้าของ platform ก็มักจะให้เหตุผลว่าทำไมถึงไม่ดำเนินการแก้ไขดังกล่าว เพื่อให้ผู้ใช้งานโดยทั่วไปเมื่อเข้ามาอ่าน report ดังกล่าวแล้วเป็นคนตัดสินใจเองว่าจะยังคงใช้งาน platform นั้นๆ หรือไม่”

.

Developer ดำเนินการแก้ไข smart contract และดำเนินการตรวจสอบซ้ำ

.

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

.

ดำเนินการออก final report

.

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

.

.

บทสรุป

.

Smart contract security audit นั้นถือเป็นเรื่องที่จำเป็นอย่างมากสำหรับแพลตฟอร์มใดๆ ที่ดำเนินธุรกรรมบนบล็อกเชน เพราะด้วยความที่จำเป็นต้องสร้างความโปร่งใสต่อการให้บริการ และตรวจสอบการป้องกันความเสี่ยงใดๆ ที่อาจจะเกิดขึ้นได้กับแพลตฟอร์ม

.

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

.

.

บทความโดย: สุเมธ จิตภักดีบดินทร์ - CEO & Founder at Valix Consulting

.

.

Reference

[1] https://www.coindesk.com/.../how-do-ethereum-smart.../

[2] https://ethereum.org/en/developers/docs/evm/

[3] https://dasp.co/

[4] https://github.com/.../ValixConsulting-Audit-Report...

[5] https://twitter.com/cz_binance/status/1598575867311132673...

[6] https://assets.ankr.com/.../smart_contract_security_audit...

-----------------------------------