แน่นอนว่าเรื่องของ Blockchain กับโลกของ DeFi หรือ Decentralized Finance นั้นเป็นของคู่กันไปแล้วตอนนี้ ซึ่งในปัจจุบันก็เริ่มมีผู้คนสนใจเข้าไปลงทุนในรูปแบบต่าง ๆ กันมากขึ้นเรื่อย ๆ หากแต่วลีที่ว่า “การลงทุนมีความเสี่ยง ผู้ลงทุนควรศึกษาข้อมูลให้รอบคอบก่อนตัดสินใจลงทุน” นั้นยังคงเป็นจริงในทุกสถานการณ์ รวมทั้งโลกของ DeFi ก็เช่นกัน แล้วอะไรคือความเสี่ยงในโลกของ DeFi บ้าง วันนี้ทางทีมงาน TechTalkThai ได้พูดคุยกับคุณสิทธิณัฐ หาเรือนพืชน์ ผู้ก่อตั้งและ CEO Inspex บริษัท Security Audit อันเป็นที่รู้จักกันดีในวงการของ Blockchain ที่จะมาชี้เป้าให้เห็นถึงความเสี่ยงของวงการ DeFi ให้ได้รู้กัน
Inspex คือใคร? Inspex เป็นบริษัทที่มุ่งเน้นในด้านของระบบความปลอดภัยบน Blockchain และความปลอดภัยบนสัญญาอัจฉริยะ (Smart Contract Security) ด้วยทีมงานผู้ก่อตั้งที่มีประสบการณ์การทำงานด้านระบบความปลอดภัยมาก่อน และหลังจากที่ได้เข้าไปลงทุนและศึกษาเรื่อง Security ในโลก DeFi จึงทำให้พบเห็นความเสี่ยงที่มีอยู่มากมายที่อาจเกิดขึ้นได้ ทำให้เห็นโอกาสที่ในการสร้างบริการ Blockchain & Smart Contract Security ในรูปแบบต่าง ๆ จึงก่อตั้งเป็นบริษัท Inspex ขึ้นมา
สำหรับบริการของทาง Inspex มีอยู่หลากหลายรูปแบบ ได้แก่
- Smart Contract Audit เสมือนเป็นผู้ตรวจสอบสัญญาอัจฉริยะ ที่จะค้นหา issue ความเสี่ยงต่าง ๆ ภายใน Smart Contract แล้วให้คำแนะนำแนวทางในการแก้ไขปัญหาให้กับเจ้าของแพลตฟอร์มได้
- Security Consulting บริการให้คำปรึกษาด้านความปลอดภัยสำหรับการพัฒนา Decentralized Application ตั้งแต่การออกแบบ (design) และการพัฒนา (development) อย่างไรให้มีความปลอดภัย
- Digital Asset Investment Consulting บริการให้คำปรึกษาในการลงทุนสินทรัพย์ดิจิทัลต่าง ๆ ไม่ว่าจะเป็นกองทุน หรือโครงการ DeFi สำหรับผู้ที่สนใจหรือผู้ที่ต้องการคำปรึกษาว่าจะลงทุนบนแพลตฟอร์มใดดี จากประสบการณ์การตรวจสอบรีวิวแพลตฟอร์มมามากมาย
อะไรคือ DeFi ? ต่อยอดมาจาก Blockchain ได้อย่างไร?
เป็นที่รู้กันอยู่แล้วว่าหลักการของ Blockchain นั้นคือการทำระบบให้ข้อมูลมีลักษณะกระจายศูนย์ออกไป (decentralized) เพื่อตัดตัวกลางออกจากขั้นตอนต่าง ๆ หากแต่การเก็บข้อมูลธุรกรรมด้วยรูปแบบเทคโนโลยีเดิม ๆ นั้นมักจะจัดเก็บไว้อยู่ในฐานข้อมูลที่เดียว ซึ่งถ้าหากถูกแก้ไขโดยที่ไม่ได้รับอนุญาตก็จะส่งผลกระทบในด้านความปลอดภัยไม่ว่าจะเป็นการรักษาความลับ (Confidentiality) ความคงสภาพสมบูรณ์ (Integrity) และความพร้อมใช้งาน (Availability) ดังนั้น การนำเอา Blockchain มาประยุกต์ใช้จึงจะช่วยแก้ไขปัญหาดังกล่าวได้เนื่องจากข้อมูลได้มีการกระจายไปที่ทุกคนในโครงข่าย และดำเนินธุรกรรมต่าง ๆ ได้โดยที่ไม่มีตัวกลางนั่นเอง
ด้วยเทคโนโลยีของ Blockchain นี้เอง จึงทำให้เกิดเงินสกุลดิจิทัล (Cryptocurrency) ตัวแรกของโลกที่มีชื่อว่า Bitcoin ซึ่งในเวอร์ชันแรกจะเป็นการบันทึกข้อมูลธุรกรรมแค่บางข้อมูล อย่างเช่นใคร (address หนึ่ง) ส่งเงินให้ใคร (อีก address หนึ่ง) เพียงเท่านั้น เป็นต้น หลังจากนั้นไม่นานได้เกิดเป็น Ethereum และเหรียญ ETH ที่มาพร้อมกับสัญญาอัจฉริยะ (Smart Contract) ซึ่งเป็นชุดคำสั่งที่คนสามารถเรียกใช้งานได้ ทำให้เกิดการประยุกต์ใช้ในลักษณะทางการเงิน (Financial) ไม่ว่าจะเป็นการฝากเงิน ถอนเงิน จึงทำให้เกิด Decentralized Finance ขึ้นมา
วิวัฒนาการของ DeFi
สำหรับแอปพลิเคชันในยุคแรก ๆ นั้นจะเป็น DeFi ที่เขียนบน Smart Contract ในการฝากถอนเงินต่าง ๆ แต่ก็ได้ทำให้เกิดแพลตฟอร์ม DeFi ออกมาอย่างหลากหลาย ตัวอย่างเช่น ศูนย์ซื้อขายแบบกระจาย (Decentralized Exchange : DEX) ที่จะต่างจาก Centralized Exchange อย่าง Bitkub, Satang เนื่องจากไม่มีตัวกลางในการดำเนินการทำ Order Book หรือการจับคู่ซื้อขาย bid offer กัน ซึ่ง DEX จะมีแค่เฉพาะแพลตฟอร์มเท่านั้น จึงทำให้การซื้อขายเกิดเป็นอีกรูปแบบหนึ่งขึ้นมาคือ Auto Market Making (AMM) ที่ขับเคลื่อนด้วยสภาพคล่อง (Liquidity) ที่จะเปิดให้ผู้ใช้งานสามารถนำเหรียญมาแลก (swap) เหรียญกันได้ อย่างเช่นการมีคนเอาเหรียญ A และเหรียญ B มาฝากไว้ในแพลตฟอร์มในอัตราส่วนที่เท่ากันตามราคาตลาด เป็นต้น ซึ่งสิ่งนี้เองที่ทำให้เกิดสภาพคล่องภายใน DEX นั้น ๆ ตามปริมาณคนภายในโครงข่ายนั้นมาแลกเหรียญกันไป ๆ มา ๆ จึงทำให้อัตราแลกเปลี่ยนหรือราคามีการเปลี่ยนแปลงไปนั่นเอง เช่น หากมีคนนำเหรียญนั้นมาขายมากขึ้นก็จะทำให้ราคาถูกลง เป็นต้น
หลังจากวิวัฒนาการเรื่อยมา จึงทำให้เกิดคู่เหรียญในการแลกเปลี่ยนกันเกิดขึ้น ซึ่งกรณีที่คู่เหรียญที่ต้องการแลกนั้นไม่ได้มีอยู่บนแพลตฟอร์มมาก่อน เช่น มีเหรียญ A, B, C แต่มีคู่เหรียญแค่ A กับ B เท่านั้น ถ้าหากว่ามีคนต้องการแลกเหรียญ A ไป C จะทำอย่างไร ? ตัวแพลตฟอร์มนั้น ๆ จะมีการจัดการ routing ให้อัตโนมัติโดยแลกเหรียญ A ไปเหรียญ B ก่อนแล้วค่อยเอาเหรียญ B ไปแลกเหรียญ C ต่อไป ซึ่งกระบวนการเหล่านี้เอง DEX จะดำเนินการให้โดยอัตโนมัตินั่นเอง
DeFi กับรูปแบบที่หลากหลาย
DeFi ในปัจจุบันนั้นมีหลายรูปแบบมาก ตัวอย่างยอดนิยมนั่นคือ Yield Farming คือการนำเอาเหรียญไปฝากไว้ในแพลตฟอร์มเพื่อทำให้เกิดสภาพคล่อง แล้วได้ผลตอบแทนเป็นเหรียญจากแพลตฟอร์มในลักษณะ Governance Token ด้วยการทำ Farming ในลักษณะดังกล่าวนี้จะสามารถกำหนดประเภทสินทรัพย์ (Asset) และบริการทางการเงิน (Financial Service) ได้อย่างหลากหลายซึ่งขึ้นอยู่กับว่าแพลตฟอร์มออกแบบไว้อย่างไร จึงทำให้สามารถต่อยอดการทำ DeFi ให้คล้ายกับระบบธนาคารได้ อย่างเช่น บริการให้ยืมและขอยืมเงิน (Lending and Borrowing) ซึ่งจะทำให้ได้รับตอบแทนเป็นดอกเบี้ย (Interest) มาเป็นผลตอบแทน หรือการเปิดให้กู้ยืมเหรียญหรือสินทรัพย์ออกไป ในบางที่ได้มีการนำแพลตฟอร์มรูปแบบต่าง ๆ มาผสมผสานกันจนทำให้กลายเป็น Leverage Yield Farming ที่สามารถกู้ยืมเหรียญมา Farming เพิ่มเติมเพื่อให้ได้ผลตอบแทนมากขึ้นอีกก็มี
ระยะหลังนี้เริ่มมีแพลตฟอร์มใหม่เกิดขึ้นมาอย่างมหาศาล ตัวอย่างเช่นแพลตฟอร์มรูปแบบ Yield Aggregator อย่าง AutoFarm ที่ผู้ใช้สามารถเอาสินทรัพย์ที่มีไปใส่ไว้ในแพลตฟอร์ม แล้วแพลตฟอร์มจะเลือกให้ว่าจะเอาไปลงทุนในเหรียญใดให้อัตโนมัติเพื่อให้ได้ผลตอบแทนมากที่สุด หรือในบางแพลตฟอร์มจะมีกลยุทธ์การลงทุนที่หลากหลาย (Multistrategy) โดยแบ่งสินทรัพย์ออกเป็นหลายส่วน เพื่อแยกลงทุนในหลายแพลตฟอร์มเพื่อทำให้ผู้ใช้สามารถจัดการสินทรัพย์ได้ง่ายขึ้น คือแค่เอาสินทรัพย์ไปใส่ไว้แล้วก็รอรับผลการลงทุนเท่านั้นเลย อีกรูปแบบที่อาจจะเจอกันมากขึ้นเรื่อย ๆ คือ Yield Optimizer อย่าง Beefy Finance ที่จะช่วยทำ Auto Compound ให้อัตโนมัติโดยจะเก็บผลตอบแทนให้แล้วนำไป Farming ต่อไป ด้วยการเอาไปทบต้นทุนเพื่อทำให้ได้ผลตอบแทนสูงขึ้นอีก
ตัวอย่างแพลตฟอร์ม DeFi ใหม่ ๆ ที่เกิดขึ้น
ความเสี่ยงหรืออันตรายในโลก DeFi ที่มักพบเจอในปัจจุบัน
เช่นเดิม ทุกการลงทุนมีความเสี่ยง โลกของ DeFi ก็เช่นกัน ซึ่งอันตรายที่ผู้ใช้มักจะพบเจอ ตัวอย่างเช่น
- Rug Pull คือการดึงสภาพคล่องออกและล้มเลิกโครงการอย่างฉับพลัน แล้วเทขายเหรียญตัวเองออกมา อันเนื่องมาจากแพลตฟอร์มที่มีความไม่ยุติธรรมอันเนื่องจากสภาพคล่องนั้นเป็นเงินของเจ้าของแพลตฟอร์มเองตอนเริ่มต้น ซึ่งกรณีนี้คือเรื่องของ KubSwap ที่เป็นข่าวออกมานั่นเอง ทั้งนี้ Rug Pull ถือว่าเป็นปัญหาทางเทคนิค เนื่องจากผู้ใช้อาจไม่ได้ศึกษาแพลตฟอร์มดีพอหรือว่าข้อมูลไม่ได้มีมากพอแล้วหลงเชื่อไปลงทุน
- การตั้งใจเขียน Bug หรือ Backdoor ไว้ใน Smart Contract โดยผู้พัฒนาเอง ซึ่งหลังจากมีผู้ใช้งานมากขึ้นแล้วก็จะ exploit เพื่อหาประโยชน์จากช่องโหว่ที่วางเอาไว้
- ช่องโหว่ต่าง ๆ ที่อยู่ภายใน Smart Contract ซึ่งถือว่าค่อนข้างเจาะจงกรณีได้ยาก เนื่องจากอาจจะเกิดได้หลากหลายสาเหตุ เช่น ความผิดพลาดในการคำนวณ หรือการเชื่อมต่อกับแพลตฟอร์มอื่นซึ่งนำไปสู่การถูกโจมตีได้ และเนื่องจากทุกคนเหมือนเป็นเจ้าของแพลตฟอร์ม ดังนั้น เมื่อถูกโจมตีขึ้นมา ผู้ที่ได้ผลกระทบก็คือผู้ที่ใช้งานทั้งหมด อาจจะโดนขโมยเหรียญ หรือว่าราคาเหรียญตกลงอย่างมหาศาล ซึ่งวิธีการแก้ไขปัญหานี้ได้ก็คือการตรวจสอบความปลอดภัยของ Smart Contract โดย Audit Service ต่าง ๆ นั่นเอง
ดังนั้น หากมองเรื่องอันตรายในโลกของ DeFi แล้วอาจจะต้องปรับทัศนคติ (Mindset) กันสักเล็กน้อย เนื่องจากในหลายปัญหาอาจถือได้ว่าเทคโนโลยีทำงานได้อย่างถูกต้องแล้ว แต่อาจเกิดจากความไม่ยุติธรรมในแพลตฟอร์มที่กำหนดไว้ หรือผู้ใช้ไม่ได้มีข้อมูลหรือความสามารถในการตรวจ Smart Contract ได้ดีพอ ซึ่งถ้าหากว่าเป็นเรื่องช่องโหว่ใน Smart Contract แล้วอาจจะต้องพึ่งบริษัท Audit Firm ในการช่วยตรวจสอบให้ จะมีความมั่นใจในมุมของความปลอดภัยมากกว่า
วิธีการสังเกตหรือตรวจสอบอันตรายของ DeFi ในมุมมองของผู้ใช้
กรณีของผู้ใช้งานทั่วไป อาจจะแทบเป็นไปไม่ได้ที่จะสามารถมาอ่านโค้ด Smart Contract ได้อย่างเชี่ยวชาญ (ถ้าไม่ได้เคยเขียนโปรแกรมมาก่อน) ดังนั้น ควรจะต้องตรวจสอบก่อนว่าแพลตฟอร์มที่กำลังจะเลือกใช้นั้นได้ผ่านการ Audit แล้วหรือไม่ และควรศึกษาผลการตรวจสอบ Audit Report จากบริษัท Audit Firm นั้นว่าผล Audit ออกมาเป็นอย่างไรมากกว่าสนใจแต่ผลตอบแทน หรือสนใจอัตราดอกเบี้ยในการปล่อยกู้ยืม หรือ Annual Percentage Rate (APR) กับ Annual Percentage Yield (APY) ที่มักจะมีการประชาสัมพันธ์ออกมาเชิญชวนให้ลงทุน อีกทั้งควรจะต้องศึกษาว่าแพลตฟอร์มนั้น ๆ มีการทำงานอย่างไร มี Use Case อย่างไรมากกว่า และควรเลือกแพลตฟอร์มที่มีความน่าเชื่อถือโดยมี Audit มารับรองแล้ว และมีผู้ใช้งานมาก ๆ เป็นต้น
สำหรับกรณีของผู้ใช้งานที่มีทักษะในการเขียนโปรแกรมอยู่แล้ว แนะนำให้ลองอ่าน Smart Contract ดูเลย ซึ่งส่วนใหญ่จะเป็นภาษา Solidity ที่ค่อนข้างเข้าใจได้ง่ายและตรงไปตรงมา โดยซอร์สโค้ด Smart Contract จะอยู่บน chain อยู่แล้ว แต่ความยากอาจจะกลายเป็นเรื่องความเข้าใจในธุรกิจของแพลตฟอร์มนั้น ๆ แทน โดยในบางกรณีก็พบว่าเจ้าของแพลตฟอร์มประกาศว่าจะทำสิ่งหนึ่งแต่ใน Smart Contract กลับทำอีกสิ่งหนึ่ง เป็นต้น
ส่วนกรณีที่เจ้าของแพลตฟอร์มต้องการตรวจสอบตัวเอง โดยทั่วไปหากยังไม่พร้อมจ้าง Audit เข้ามาตรวจสอบได้อาจจะด้วยสาเหตุเรื่องทุนทรัพย์ เจ้าของแพลตฟอร์มสามารถใช้เครื่องมือในการสแกนโค้ดอัตโนมัติมาช่วยเบื้องต้นได้ ซึ่งมี opensource อยู่แล้ว เช่น Slither เป็นต้น นอกจากนี้ ประโยชน์ของ Audit ไม่ได้ช่วยแค่เรื่องแนะนำในด้านความเสี่ยงและความปลอดภัยเท่านั้น หากแต่ยังช่วยในเรื่องของ Marketing ให้กับเจ้าของแพลตฟอร์มด้วย
Audit เชื่อถือได้แค่ไหน ถ้าผ่านการ Audit แล้วเชื่อได้ 100% ?
ทาง Inspex มีความมั่นใจในบริการว่าสามารถเชื่อถือ Audit Report ของทางบริษัทได้แน่นอน ซึ่งถ้าหากผ่านเกณฑ์ของบริษัท ภายใน Audit Report จะมี Badge ใส่เพื่อยืนยันว่าทางทีมงานได้ตรวจสอบแล้วมีความปลอดภัย หลังจากที่มีการแก้ไขปัญหาตามที่ได้รายงานใน Audit Report แล้ว
แต่ทั้งนี้ ผู้ใช้งานทั่วไปจะต้องเข้าใจวิธีการดูรายละเอียดภายใน Audit Report ด้วย ได้แก่
- Audit Scope ซึ่งเป็นส่วนที่สำคัญที่สุดว่าขอบเขตในการตรวจสอบ Audit ในรายงานนั้นอยู่ที่ใดบ้าง อย่างเช่น ขอบเขตการ Audit อยู่ที่ Commit Hash ใด ซึ่งถ้าหากว่าได้ทำการ Audit ผ่านพ้นไปแล้วเกิดเป็น Commit ใหม่ขึ้นมา ก็จะถือว่าอยู่นอกขอบเขตของการ Audit Report นั้น เป็นต้น
- Audit Finding หรือ Issue ที่ทาง Auditor พบเจอ ส่วนนี้อาจจะยากสำหรับคนทั่วไปเล็กน้อย หากแต่วิธีการดูง่าย ๆ นั่นคือดูที่สถานะ (Status) และระดับความเสี่ยง (Severity) ว่าสูงแค่ไหน ซึ่งถ้าหากว่าเป็นระดับสูงสุดของ Inspex คือ Critical ก็จะต้องพิจารณาจุดนี้เป็นพิเศษ
- Status ของแต่ละ Issue ภายใน Audit Report ของทาง Inspex จะมีอยู่ 4 แบบ คือ
- Resolved คือเจ้าของแพลตฟอร์มทำการแก้ไขช่องโหว่แล้วอย่างถูกต้อง
- Resolved* คือการ Resolve โดยมี Workaround Implementation ขึ้นมา นั่นคือช่องโหว่ดังกล่าวนั้นยังคงอยู่ แต่ด้วยข้อจำกัดต่าง ๆ เจ้าของแพลตฟอร์มเลือกที่จะสร้าง Workaround เพื่อลดความเสี่ยงให้อยู่ในระดับที่ยอมรับได้
- Acknowledged เป็นช่องโหว่ที่เจ้าของแพลตฟอร์มรับทราบปัญหาเรียบร้อยแล้ว ณ เวลานั้น แต่ไม่ได้ดำเนินการแก้ไข อาจจะเนื่องด้วยระดับความเสี่ยงที่ไม่ได้สูงมากนักหรือด้วยข้อจำกัดต่าง ๆ ที่มีอยู่จึงยังไม่ได้ดำเนินการแก้ไข ซึ่งผู้อ่านต้องเข้าใจว่าความเสี่ยงยังอยู่ 100% ตามที่อยู่ในรายงาน แต่เจ้าของแพลตฟอร์มเลือกที่จะรับทราบโดยที่ยังไม่แก้ไขแต่อย่างใด
ถ้า Audit ตรวจเจอปัญหาแล้วแพลตฟอร์มจะอัปเดตแก้ไขได้ทันทีหรือไม่
ด้วยกระบวนการทำงานของทาง Inspex จะมี 2 ขั้นตอนหลัก ๆ คือ Preliminary Report ที่ Inspex จะออกรายงานแจ้งว่ามี Issue อะไรบ้างพร้อมกับให้คำปรึกษาและแนะนำว่ามีแนวทางแก้ไขอย่างไรบ้าง หลังจากนั้นจะขึ้นอยู่กับทางเจ้าของแพลตฟอร์มแล้วว่าจะดำเนินการแก้ไขเมื่อใด ใช้เวลาแค่ไหน ซึ่งเมื่อเจ้าของแพลตฟอร์มได้ดำเนินการแก้ไขเสร็จสิ้นแล้ว ทาง Inspex ก็จะมีกระบวนการทำ Reassessment ใน Issue ที่พบเจอว่ามีการแก้ไขแล้วเรียบร้อยหรือไม่อีกครั้งหนึ่ง ดังนั้น หากการอัปเดตแก้ไขจึงต้องขึ้นกับเจ้าของแพลตฟอร์มว่าจะดำเนินการทันทีหรือไม่ ใช้เวลาเท่าใดนั่นเอง
นอกจากนี้ เรื่องดังกล่าวถือได้ว่าขึ้นอยู่กับแต่ละกรณีว่าจะเป็นอย่างไร ตัวอย่างเช่น บางกรณีได้กำหนดขอบเขตการ Audit กำหนดไว้อยู่ที่โค้ดบน Repository แต่ยังไม่ได้ Deploy ใช้งานจริง หรือโค้ดที่ Deploy ใช้งานอยู่จริงนั้นกลับไม่ตรงเวอร์ชันที่กำหนดให้ตรวจสอบ ก็อาจจะยิ่งใช้เวลามากขึ้นกว่าเดิม เป็นต้น
ดังนั้น ผู้ใช้จึงจำเป็นต้องตรวจสอบใน Audit Report อย่างถี่ถ้วน ทั้งนี้ การที่เจ้าของแพลตฟอร์มจะนำโค้ด Deploy ใช้งานจริงเรียบร้อยแล้วหรือไม่นั้นถือว่าไม่ได้อยู่ในขอบเขตงานของ Auditor แต่อย่างไรก็ดี ส่วนใหญ่เจ้าของแพลตฟอร์มก็มักจะแก้ไข Issue ต่าง ๆ แล้ว Deploy ขึ้น Main Net ก่อนแล้วจึงจะมาแจ้งให้ทาง Inspex ไปช่วยตรวจสอบซ้ำในส่วนนั้นอีกครั้งหนึ่ง
สิ่งที่ต้องเน้นย้ำอีกครั้ง คือ Audit Report เชื่อถือได้ตามขอบเขต Scope of Work หรือ Commit Hash ที่กำหนดไว้เพียงเท่านั้น ถ้าหากเจ้าของแพลตฟอร์มได้มีการแก้ไขโค้ดจนเกิดเป็น Commit ใหม่ขึ้นมาแล้วนำไป Deploy นั่นไม่ได้หมายความว่าจะไม่ได้มีความเสี่ยงแล้วเหมือนดังที่ได้รายงานใน Audit Report นั่นเอง ดังนั้น ความโปร่งใสของเจ้าของแพลตฟอร์มจึงเป็นเรื่องที่สำคัญในเรื่องประเด็นของความสอดคล้องกันของโค้ดที่ผ่านการ Audit และโค้ดที่ใช้ Deploy จริง
แล้วสำหรับคนทั่วไปจะรู้ได้อย่างไรว่าตอนนี้ที่ Deploy ใช้งานอยู่ได้มีการแก้ไขตาม Audit Report ไปแล้ว ?
สิ่งที่ผู้ใช้งานทั่วไปสามารถตรวจสอบได้ง่าย ๆ คือ เจ้าของแพลตฟอร์มได้นำเอาโค้ดไป Deploy ขึ้น Main Net ล่าสุดเมื่อใด ก่อนหรือหลัง Audit Report ที่ได้ประกาศออกมา ซึ่งถ้าหากผู้ใช้พออ่านโค้ดตรวจสอบโค้ดได้บ้างด้วยก็จะสามารถนำโค้ดไปเปรียบเทียบว่าตรงกันแล้วหรือไม่ โดยไม่จำเป็นจะต้องเข้าใจ 100% ก็สามารถทำได้เช่นกัน
หลาย ๆ คน มองว่า มี Audit แล้วจบ ปลอดภัยชัวร์ ?
คำตอบได้รับชัดเจนเลยว่า “ไม่ใช่” ตัวอย่างกรณีของแพลตฟอร์ม Merlin Lab ซึ่งก็ได้ผ่านการ Audit มาหลายเจ้าแล้วก็ตาม หากแต่ทาง Inspex ได้พบเจอเป็นเจ้าแรก ๆ ว่าแพลตฟอร์มได้สร้าง Contract ใหม่ขึ้นมาที่ไม่ได้อยู่ภายในขอบเขต Scope of Work ในการ Audit แล้วนำไป Deploy ขึ้น Main Net ทันทีโดยที่ยังไม่ได้มีใคร Audit มาก่อน จึงทำให้เกิดความเสียหายขึ้นและส่งผลกระทบกับความเชื่อมั่นใน Auditor หลาย ๆ เจ้าขึ้นมา
กรณีนี้แสดงให้เห็นว่าการผ่าน Audit มาหลายเจ้า รวมถึงเจ้าใหญ่ ๆ แล้วก็ตามนั้น ไม่ได้ช่วยให้มั่นใจได้ว่าปลอดภัยชัวร์ หากพูดในอีกมุมหนึ่ง ถ้ามองที่ผลของการ Audit ใน Audit Report นั้นผู้ใช้สามารถเชื่อถือผลดังกล่าวได้อย่างแน่นอน แต่ไม่ได้บอกว่าแพลตฟอร์มที่กำลังใช้งานอยู่นั้นมีความปลอดภัย ไม่สามารถการันตีได้ 100% เนื่องจากขอบเขตการ Audit อาจไม่ได้ครอบคลุมทุกส่วนนั่นเอง แต่ถ้าแพลตฟอร์มดำเนินการตามขอบเขต Scope of Work ที่ระบุใน Audit Report ของ Inspex ทั้งหมดอยู่แล้ว ทางบริษัทก็เชื่อมั่นว่ามีความปลอดภัย
ถ้าหากว่าน้อง ๆ สนใจด้าน Blockchain Security จะต้องเริ่มอย่างไร ?
ทีมงาน Founder และ Co-founder ของ Inspex นั้นก็ทำงานด้าน Traditional Security ทั่วไปมาก่อน ไม่ได้มีประสบการณ์ทำงานด้าน DeFi มาก่อนเช่นกัน ดังนั้น สิ่งที่สำคัญในการเริ่มต้นที่นำมาต่อยอดได้ก็คือ “กรอบความคิด (Mindset)” ในด้าน Information Security กับ IT Security ที่จะต้องมีก่อน ซึ่งจะทำให้เรามองเทคโนโลยีต่าง ๆ ในอีกมุมมองหนึ่ง ที่จะค้นหาปัญหาที่อาจเกิดขึ้นในแพลตฟอร์ม หาช่องโหว่ที่มีแทนการใช้งานแบบทั่วไป
ทั้งนี้ Mindset อาจจะไม่ได้มีรูปแบบการฝึกฝนอะไรที่ตายตัว ดังนั้น น้อง ๆ สามารถเริ่มต้นได้จากพื้นฐานของ Information Security ก่อน เพื่อทำให้เห็นภาพในด้าน Security มากขึ้น แล้วอาจทดลองเลือกภาษาเขียนโปรแกรมสัก 1 ภาษาเพื่อมาศึกษาวิธีการเขียนโปรแกรม (แล้วแต่ความชอบ) ซึ่งอาจจะเป็น Solidity ที่นิยมมาก ๆ ก็ได้ ซึ่งถ้าหากสามารถทดลองทำความเข้าใจได้ก็จะช่วยเสริมความสามารถ ทำให้สามารถอ่านซอร์สโค้ดแพลตฟอร์มได้ด้วยตัวเอง จากนั้น จึงนำเอา Mindset ด้าน Security มาประยุกต์ใช้ว่าโค้ดของแพลตฟอร์มนั้น ๆ น่าจะมีช่องโหว่อะไร หรือว่าจะหาประโยชน์จากการโค้ดที่แพลตฟอร์มเขียนขึ้นมาได้อย่างไร (แต่อย่าไปโจมตีจริง ๆ นะ) ซึ่งช่องโหว่บนภาษา Solidity นั้นก็คล้าย ๆ กับช่องโหว่บนเว็บไซต์ จึงสามารถอิงกับแนวทางของ CWE (Common Weakness Enumeration : https://cwe.mitre.org/) ได้เลย รวมทั้งสามารถศึกษาบทความหรือไกด์ไลน์จาก OpenZeppelin หรือ Consensys ที่ซึ่งเป็นผู้มีประสบการณ์ในด้าน Smart Contract Security เพิ่มเติมด้วยก็จะเสริมให้เข้าใจหลักการ Blockchain Security ได้ดีขึ้น
สิ่งที่ Inspex อยากจะฝากถึงผู้อ่านกับสถานการณ์ของ DeFi และ Cryptocurrency ในปัจจุบัน
คุณสิทธิณัฐได้เน้นย้ำในฐานะ Security Audit Firm ว่า ไม่ว่าท่านผู้อ่านจะเป็นผู้ใช้งานทั่วไปหรือเจ้าของแพลตฟอร์ม อยากจะให้เข้าใจวัตถุประสงค์ที่แท้จริงของการ Audit ที่ไม่ใช่แค่เชิงการตลาดหรือการสร้างรายได้อย่างเดียวเพียงเท่านั้น สิ่งที่อยากให้ผู้อ่านทำอย่างสม่ำเสมอคือ การศึกษาดูรายละเอียดใน Audit Report ให้เข้าใจถึงขอบเขต Scope of Work ในการ Audit ก่อนว่ามีอะไรบ้าง ผลเป็นอย่างไร เพื่อจะได้ช่วยให้สร้างความเข้าใจและความเชื่อมั่นก่อนการลงทุน และไม่ทำให้สินทรัพย์ของท่านนั้นสูญหายไปได้ ส่วนในด้านการลงทุน ขอแนะนำให้ศึกษาข้อมูลของแพลตฟอร์มให้ดีก่อนว่าเป็นอย่างไร ไม่ควรเน้นหวังกำไรจากการลงทุนเพียงอย่างเดียว
ติดต่อ Inspex
สุดท้ายนี้ ทาง Inspex ได้ฝากไว้ว่าทางทีมกำลังพัฒนาเครื่องมือใหม่ที่กำลังจะปล่อยออกมาในเร็ว ๆ นี้ ดังนั้น ใครที่สนใจสามารถติดตามความคืบหน้าของทาง Inspex ได้ผ่านทางเว็บไซต์ https://inspex.co/ หรือบน Facebook https://www.facebook.com/InspexCo/ และหากใครมีข้อสงสัยต้องการสอบถามรายละเอียดเพิ่มเติมก็สามารถติดต่อได้ผ่านอีเมล [email protected]