[สัมภาษณ์] มุมมองโลก DeFi จาก Inspex บริษัท Security Audit ในวงการ Blockchain

แน่นอนว่าเรื่องของ Blockchain กับโลกของ DeFi หรือ Decentralized Finance นั้นเป็นของคู่กันไปแล้วตอนนี้ ซึ่งในปัจจุบันก็เริ่มมีผู้คนสนใจเข้าไปลงทุนในรูปแบบต่าง ๆ กันมากขึ้นเรื่อย ๆ หากแต่วลีที่ว่า “การลงทุนมีความเสี่ยง ผู้ลงทุนควรศึกษาข้อมูลให้รอบคอบก่อนตัดสินใจลงทุน” นั้นยังคงเป็นจริงในทุกสถานการณ์ รวมทั้งโลกของ DeFi ก็เช่นกัน แล้วอะไรคือความเสี่ยงในโลกของ DeFi บ้าง วันนี้ทางทีมงาน TechTalkThai ได้พูดคุยกับคุณสิทธิณัฐ หาเรือนพืชน์ ผู้ก่อตั้งและ CEO Inspex บริษัท Security Audit อันเป็นที่รู้จักกันดีในวงการของ Blockchain ที่จะมาชี้เป้าให้เห็นถึงความเสี่ยงของวงการ DeFi ให้ได้รู้กัน

สำหรับบริการของทาง 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]