ชื่อต้นฉบับ: "IOSG Weekly Brief | มีโอกาสสำหรับการทำเครื่องมือวิเคราะห์ความปลอดภัยของสัญญาอัจฉริยะในเชิงพาณิชย์หรือไม่" #147》
ที่มา: IOSG Ventures
ที่มา: IOSG Ventures
คำอธิบายภาพ
ที่มาของภาพ: https://twitter.com/chainalysis/status
เมื่อพิจารณาจากแนวโน้มการจัดหาเงินทุนและปฏิกิริยาของตลาดในช่วงหลายเดือนที่ผ่านมา ปัจจุบันเงินทุนในตลาดหลักมีความสนใจอย่างมากในการตรวจสอบความปลอดภัยที่มุ่งเน้นไปที่ความทันเวลาของข้อมูลความปลอดภัย การครอบคลุมความเสี่ยง เทคโนโลยีน้ำหนักเบา และไฟร์วอลล์ ในโดเมนการตรวจสอบ)
คำอธิบายภาพ
ที่มาของภาพ: https://twitter.com/chainalysis/status
หากเราถือว่าสัญญาอัจฉริยะในห่วงโซ่ตั้งแต่การพัฒนา >> การปรับใช้ไปจนถึงเครือข่ายบล็อกเชน >> การดำเนินการเป็นวงจรชีวิตที่สมบูรณ์ การวิเคราะห์ความปลอดภัยสำหรับสัญญาอัจฉริยะสามารถแบ่งออกเป็น: ก่อนการใช้งานสัญญา (ก่อนที่เครือข่ายบล็อกเชนจะเปิดตัวอย่างเป็นทางการ) การวิเคราะห์ก่อน กำลังดำเนินการ) และการวิเคราะห์หลังการปรับใช้สัญญาซึ่งครอบคลุมสามประเภทโดยประมาณ: การทดสอบ การตรวจสอบ และการติดตาม ภายใต้แต่ละประเภทมีวิธีการวิเคราะห์และเครื่องมือที่เกี่ยวข้องหลายประเภท (ดังแสดงในรูปด้านล่าง)
PS: ความครอบคลุมการตรวจสอบของสัญญาอัจฉริยะจะตั้งแต่ก่อนการปรับใช้ไปจนถึงหลังการปรับใช้ (การตรวจสอบการอัปเกรดสัญญา)
การวิเคราะห์ความปลอดภัยก่อนการใช้งาน Smart Contract: การทดสอบ + การตรวจสอบ
1.1 การทดสอบ
การทดสอบสัญญาเป็นงานที่นักพัฒนาและผู้ตรวจสอบต้องใช้ความพยายามมากที่สุด ซึ่งแตกต่างจากนักพัฒนาแบบเดิม เนื่องจากลักษณะที่ไม่สามารถแก้ไขได้ของ blockchain เมื่อสัญญาอัจฉริยะถูกปรับใช้บนเครื่องเสมือน EVM จึงเป็นเรื่องยากที่จะเปลี่ยนแปลง ดังนั้น งานส่วนใหญ่ของการวิเคราะห์ความปลอดภัยและการอุดช่องโหว่ด้านความปลอดภัยจึงถูกใช้ไปกับ "ก่อน -การวิเคราะห์" - การทดสอบความปลอดภัยของสัญญาอัจฉริยะก่อนการใช้งาน
ก่อนยอมรับการตรวจสอบอย่างเป็นทางการ ผู้พัฒนาสัญญา/ผู้ตรวจสอบจำเป็นต้องทำการทดสอบพื้นฐานบางอย่างเกี่ยวกับรหัสของสัญญา ยิ่งอัตราความครอบคลุมของการทดสอบเริ่มต้นสูงเท่าใด ก็ยิ่งดีเท่านั้นที่สามารถหลีกเลี่ยงข้อผิดพลาดง่ายๆ จากการเข้าสู่ขั้นตอนการตรวจสอบอย่างเป็นทางการ (โดยทั่วไป สัญญาอัจฉริยะถึง 85 %-90% ของรหัสที่ครอบคลุมโดยการทดสอบเป็นระดับที่เหมาะสม ความครอบคลุมสำหรับโมดูลหลักต้องสูงกว่า 95%))
คำอธิบายภาพ
แหล่งที่มาของรูปภาพ: https://betterprogramming.pub/
คำอธิบายภาพ
"การทดสอบเป็นสิ่งที่ดีสำหรับการค้นหาจุดบกพร่องในโปรแกรม แต่ไม่สามารถพิสูจน์ได้ว่าโปรแกรมไม่ใช่จุดบกพร่อง" - Edsger Wybe Dijkstra (นักวิทยาศาสตร์คอมพิวเตอร์ ผู้ชนะรางวัล Turing Award ปี 1972)
ตามคำจำกัดความของเอกสารอย่างเป็นทางการของ Ethereum การตรวจสอบคือการประเมินโดยละเอียดของซอร์สโค้ดแต่ละบรรทัดของสัญญาอัจฉริยะ และวิธีคิดของผู้โจมตีจะดึงเวกเตอร์การโจมตีที่เป็นไปได้ในสัญญาอัจฉริยะเพื่อค้นหาจุดล้มเหลว ช่องโหว่ด้านความปลอดภัย แนวทางการพัฒนา ขั้นตอนการตรวจสอบประกอบด้วย: การวิเคราะห์แบบคงที่ การวิเคราะห์แบบไดนามิก (การทดสอบ Fuzzing การดำเนินการเชิงสัญลักษณ์) การวิเคราะห์ด้วยตนเอง และการตรวจสอบอย่างเป็นทางการ ดังที่ Dijkstra กล่าวถึงในรูปด้านบน การทดสอบเพียงอย่างเดียวไม่สามารถเชื่อได้อย่างสมบูรณ์ว่าโปรแกรมปราศจากข้อผิดพลาด การตรวจสอบและการตรวจสอบอย่างเป็นทางการเป็นเรื่องเกี่ยวกับเข้าใกล้เป้าหมายของการไม่มีข้อบกพร่องในโปรแกรมมากขึ้น
ค่าใช้จ่ายเงิน
ตามที่บริษัทรักษาความปลอดภัยสัญญาอัจฉริยะ Hacken ต้นทุนเฉลี่ยของอุตสาหกรรมบริการตรวจสอบสัญญาอัจฉริยะอยู่ระหว่าง 5,000 ถึง 30,000 ดอลลาร์ (สำหรับโครงการขนาดเล็กและขนาดกลาง) สำหรับโครงการขนาดใหญ่ บางครั้งค่าใช้จ่ายอาจสูงถึง 500,000 ดอลลาร์หรือมากกว่านั้น ค่าใช้จ่ายในการตรวจสอบสัญญาอัจฉริยะขึ้นอยู่กับความซับซ้อนของโค้ดและขอบเขตงานที่ตกลงกันโดยตรง ปัจจัยอื่นๆ ที่ส่งผลต่อราคา ได้แก่ ความเร่งด่วน ขนาดของสัญญาอัจฉริยะ (จำนวนบรรทัดของโค้ด) จำนวนชั่วโมงวิศวกรรมที่ต้องใช้ในการดำเนินการให้เสร็จสิ้น ความพร้อมของเอกสารที่เกี่ยวข้องกับโครงการ เป็นต้น
ค่าใช้จ่ายด้านเวลา
การตรวจสอบเบื้องต้นใช้เวลาเฉลี่ย 2 ถึง 14 วัน ขึ้นอยู่กับความซับซ้อนของโครงการ ขนาดสัญญาอัจฉริยะ และความเร่งด่วน สำหรับโครงการหรือข้อตกลงขนาดใหญ่ การตรวจสอบเบื้องต้นอาจใช้เวลาถึง 1 เดือน หลังจากการตรวจทานเบื้องต้นเสร็จสิ้น ลูกค้าจะได้รับคำแนะนำเกี่ยวกับการแก้ไขที่จะแนะนำ
ค่าแรงงาน
ตามข้อเสนอแนะจาก Runtime Verification ซึ่งเป็นโครงการลงทุนชั้นนำของ IOSG ในด้านการตรวจสอบอย่างเป็นทางการของบล็อกเชน ต้นทุนแรงงานในการตรวจสอบขึ้นอยู่กับความซับซ้อนของโปรโตคอล สำหรับบริษัทตรวจสอบความปลอดภัยชั้นนำส่วนใหญ่ที่มีประสบการณ์ในอุตสาหกรรมระดับสูงและประสบการณ์ทางวิชาการ โดยทั่วไป การเข้าใจตรรกะทางธุรกิจและเศรษฐศาสตร์โทเค็นของโครงการลูกค้า crypto ไม่ใช่เรื่องยากเกินไป โดยทั่วไป จะใช้เวลาประมาณ 1 ถึง 2 สัปดาห์สำหรับวิศวกรมืออาชีพสองคนทำตามขั้นตอนเริ่มต้นให้เสร็จสิ้น .
แต่ส่วนต่อไปจะขึ้นอยู่กับความต้องการเฉพาะของลูกค้า ลูกค้าบางรายต้องการเพียงการตรวจสอบตรรกะทางธุรกิจขั้นพื้นฐานของโครงการที่ผ่านการตรวจสอบด้วยตนเองเท่านั้น (ดูที่รหัสของพวกเขาและตรวจสอบด้วยตนเองว่าเป็นไปตามตรรกะทางธุรกิจที่จำเป็นหรือไม่) ซึ่งเป็นบริการที่ถูกที่สุด ลูกค้าบางรายต้องการจำลองตรรกะทางธุรกิจและเศรษฐศาสตร์โทเค็น จากนั้นทำการพิสูจน์ทางคณิตศาสตร์ด้วยตนเองเพื่อให้มั่นใจถึงผลลัพธ์ที่สำคัญบางอย่าง เช่น ความปลอดภัย ความสด ความสม่ำเสมอ ฯลฯ ลูกค้ารายใหญ่บางรายเช่น MakerDAO, Ethereum Foundation เป็นต้น หวังว่าจะก้าวไปอีกขั้นและดำเนินการตรวจสอบรหัสอย่างเป็นทางการ (Formal Verification)
คำอธิบายภาพ
เครดิตรูปภาพ: “หลักฐานที่ไม่ดีในการตรวจสอบอย่างเป็นทางการ” โดยทีม Certora ที่ Devcon Bogata
ในแง่ของแอปพลิเคชันขนาดใหญ่จริง การตรวจสอบอย่างเป็นทางการค่อนข้างช้าในแอปพลิเคชันขนาดใหญ่ เมื่อเทียบกับโซลูชันการทดสอบแบบดั้งเดิม สำหรับโครงการ crypto ส่วนใหญ่ การตรวจสอบสัญญาอัจฉริยะก็เพียงพอแล้ว ในแง่ของการป้อนต้นทุนและผลประโยชน์ที่อาจเกิดขึ้น ไม่จำเป็นสำหรับโครงการขนาดเล็ก (หรือค่าใช้จ่ายในการพิสูจน์ว่าโปรแกรมปราศจากข้อผิดพลาดนั้นค่อนข้างสูง) แกนหลัก เหตุผลก็คือการตรวจสอบอย่างเป็นทางการนั้นต้องการการมีส่วนร่วมของผู้มีความสามารถอย่างเป็นทางการระดับมืออาชีพ เนื่องจากมีความซับซ้อนมากในการสร้างข้อกำหนดที่เป็นทางการสำหรับรหัสโครงการ ซึ่งจำเป็นต้องครอบคลุมคุณลักษณะของรหัสสัญญาและกำหนดลักษณะการทำงานของสัญญาในสถานการณ์ต่างๆ . บุคลากรมืออาชีพจะต้องเข้าร่วม (สำหรับผู้อ่านที่สนใจโปรดดู "ก่อนหน้า" ของเราเหตุใดเราจึงเป็นผู้นำรอบนี้ในการยืนยันรันไทม์》)
เครื่องมือทั่วไป
การตรวจสอบสัญญาอัจฉริยะยังคงเป็นอุตสาหกรรมที่ใช้แรงงานมาก และมีข้อกำหนดทางเทคนิคสูงสำหรับบุคลากรที่มีความสามารถ แม้ว่าจะมีเครื่องมือตรวจสอบที่ได้รับความนิยมมากกว่าหนึ่งโหลในตลาด (ส่วนใหญ่พัฒนาโดยบริษัทตรวจสอบความปลอดภัยกระแสหลักหรือนักวิจัยทางวิชาการ) จุดประสงค์ของเครื่องมือตรวจสอบเหล่านี้คือเพื่อค้นหาช่องโหว่ทั่วไป เช่น การพึ่งพาคำสั่งธุรกรรม หมายเลขสุ่ม การประทับเวลา callstack ความลึก การกลับเข้าใหม่ การเรียกผู้รับมอบสิทธิ์ที่เป็นอันตราย ฯลฯ) ดังนั้นจึงเป็นการยากกว่าที่จะพึ่งพาเครื่องมือเหล่านี้ในการดำเนินการตรวจสอบให้เสร็จสิ้น และอาจพลาดช่องโหว่จำนวนมากที่เกี่ยวข้องกับตรรกะทางธุรกิจ โดยปกติแล้ว การตรวจสอบสัญญาอัจฉริยะต้องใช้เครื่องมืออัตโนมัติและการตรวจสอบโค้ดด้วยตนเองร่วมกัน และจำเป็นต้องมีการตรวจสอบด้วยตนเองเป็นกรณีๆ ไป ทั้งนี้ขึ้นอยู่กับตรรกะทางธุรกิจและรูปแบบโทเค็นของสัญญาสมาร์ทของลูกค้า
การวิเคราะห์และตรวจสอบความปลอดภัยของสัญญาอัจฉริยะมักใช้เพื่อตรวจสอบความถูกต้องของโปรแกรม กล่าวคือ การนำโปรแกรมไปใช้นั้นสอดคล้องกับความตั้งใจของโปรแกรมเมอร์ เพราะจริงๆ แล้วบั๊กในโปรแกรมเกิดจากความแตกต่างระหว่างการ Implement ของโปรแกรมและความตั้งใจของผู้เขียนโปรแกรม ความหมายอย่างเป็นทางการที่กล่าวถึงในบทความที่เราแบ่งปันการลงทุนของเราในการตรวจสอบรันไทม์ก่อนหน้านี้เป็นเฟรมเวิร์กภาษาที่ช่วยให้นักพัฒนาสามารถจับคู่จุดประสงค์ในการพัฒนา (นั่นคือ "ความหมาย") และการนำไปใช้งาน (นั่นคือ "ไวยากรณ์" ของภาษาโปรแกรมได้อย่างแม่นยำ) ) เพื่อลดการเกิดบั๊ก
ในด้านการตรวจสอบความปลอดภัยของสัญญาอัจฉริยะ แม้ว่าจะมีเครื่องมือมากมายในท้องตลาด และส่วนใหญ่เป็นโอเพ่นซอร์ส แต่มีเพียงไม่กี่เครื่องมือที่ประสบความสำเร็จในเชิงพาณิชย์ สาเหตุที่แท้จริงของสิ่งนี้จะวิเคราะห์ในภายหลัง กล่าวโดยสรุปก็คือ พึ่งพาการให้บริการด้านความปลอดภัย เครื่องมืออัตโนมัติของผู้ขาย + การอ่านรหัสแต่ละบรรทัดหรือการสร้างแบบจำลองด้วยตนเอง เป็นไปไม่ได้โดยทั่วไปที่จะได้รับรายได้เชิงพาณิชย์จำนวนมากจากการขายเครื่องมือตรวจสอบอัตโนมัติโดยตรง
ตามข้อเสนอแนะจาก Hexens ที่เรานำเสนอเมื่อเร็วๆ นี้ Slither และ MythX เป็นเครื่องมือโอเพ่นซอร์สที่ใช้กันทั่วไปสำหรับการทดสอบการวิเคราะห์ทางสถิตในระยะเริ่มต้น แม้ว่าผลลัพธ์จะไม่เป็นที่น่าพอใจมากนัก สำหรับการทดสอบในระดับที่สูงขึ้น ส่วนใหญ่จะใช้ฟัซเซอร์เช่น Echidna, Forge+บิวด์อินฟัซเซอร์
การวิเคราะห์ความปลอดภัยหลังจากการปรับใช้สัญญาอัจฉริยะ —— การตรวจสอบ
ในบรรดา 10 การโจมตีด้านความปลอดภัยเครือข่ายบล็อกเชนที่พบบ่อยที่สุด Scam มีความถี่สูงสุดและทำให้ผู้ใช้สูญเสียทรัพย์สินมากที่สุดโดยตรง ตามข้อมูลของ Peckshield ในปี 2021 ความสูญเสียทางเศรษฐกิจบนเครือข่ายของ crypto เนื่องจากการหลอกลวงต่างๆ จะสูงถึง 12 พันล้านดอลลาร์สหรัฐ ซึ่งสูงกว่าการสูญเสียที่เกิดจากการโจมตีโดยตรงโดยแฮ็กเกอร์ถึง 6.7 เท่า
การโจมตีหลอกลวงทั่วไป:
ฟิชชิ่ง (เทคนิคฟิชชิ่งทั่วไปคือการส่งอีเมล/เว็บไซต์ขอให้ผู้ใช้รีเซ็ตรหัสผ่าน/กู้คืนบัญชี เมื่อผู้ใช้ลงชื่อเข้าใช้เว็บไซต์ปลอมเหล่านี้ ผู้ใช้จะขโมยคีย์ส่วนตัว)
กรณี: อลิซเข้าสู่ระบบการแลกเปลี่ยนและเชื่อมโยงไปยังกระเป๋าเงิน MetaMask และได้รับหน้าต่างป๊อปอัปที่ระบุว่ากระเป๋าเงินมีข้อบกพร่องและจำเป็นต้องกู้คืนด้วยคำช่วยจำ หลังจากการคืนค่า ทรัพย์สินทั้งหมดในกระเป๋าเงินจะถูกขโมย
การเลียนแบบ/แอบอ้าง (บุคคลที่อ้างว่าเป็นพนักงานหรือตัวแทนของ dapp/สถาบันบางแห่งอาจติดต่อผู้ใช้ทางอีเมล โทรศัพท์ หรือโซเชียลมีเดีย พวกเขาจะขโมยเงินจากผู้ใช้โดยส่งไซต์โรงกษาปณ์/โรงกลั่นปลอมฟรี หรือโดยการแอบอ้างพฤติกรรมเพื่อชักใยเหยื่อ แยกเงินหรือข้อมูลที่ละเอียดอ่อน)
กรณี: รัฐบาลยูเครนยอมรับการบริจาคสกุลเงินดิจิทัลและประกาศการออกอากาศ NFT ผู้แอบอ้างอ้างว่าเป็นรัฐบาลยูเครนเพื่อออกโทเค็นปลอมเพื่อฉ้อโกง
Discord จัดการการไฮแจ็กข้อมูลประจำตัว (ผู้โจมตีเข้าควบคุมบอทของผู้ดูแลระบบที่ชุมชนเชื่อถือเพื่อโพสต์ประกาศปลอม ลิงก์หลอกลวง หรือหลอกล่อเหยื่อให้เลิกใช้สกุลเงินดิจิทัลหรือ NFT)
กรณี: แฮ็กเกอร์ควบคุม NFT แบบบลูชิป เช่น Bored Ape Yacht Club และเซิร์ฟเวอร์ทางการที่ไม่ลงรอยกันอื่นๆ และส่งลิงก์ผิดไปยังสมาชิกเป็นชุดๆ หลังจากที่ผู้ใช้คลิก สินทรัพย์จะถูกขโมยอย่างถาวร
การไฮแจ็ก BGP (โดยอ้างว่ามีคำนำหน้า IP ที่ไม่ได้รับการควบคุมจริง และเพิ่มลงในตารางเส้นทางในเราเตอร์ BGP อินเทอร์เน็ต ผู้โจมตีสามารถจี้ทราฟฟิกของที่อยู่ IP ได้ ในกรณีนี้ เมื่อผู้ใช้พยายาม การเข้าสู่ระบบจะถูกเปลี่ยนเส้นทางไปยังที่อยู่กับดักที่ผู้โจมตีกำหนด)
กรณี: Celer ถูกโจมตีโดยการไฮแจ็ค BGP ส่งผลกระทบต่อผู้ใช้ 32 รายและสูญเสียเงิน 235,000 ดอลลาร์ (2022.08)
โค้ดแบ็คดอร์และกับดัก (ผู้โจมตีซ่อนโค้ดอันตรายที่มีฟังก์ชันพิเศษในโปรแกรมปกติ เช่น โปรแกรมแบ็คดอร์ที่มีฟังก์ชันพิเศษ เช่น การทำลายและลบไฟล์ การส่งรหัสผ่าน การบันทึกแป้นพิมพ์ และการโจมตี DDoS เพื่อขโมยข้อมูลส่วนบุคคลของผู้ใช้)
กรณี: Bob สร้าง NFT บนเว็บไซต์บางแห่ง และพบว่ามันหายไปในอีกสองวันต่อมา เนื่องจากผู้โจมตีฝังคุณสมบัติบางอย่างในรหัส NFT เขาสามารถอนุญาตให้ผู้อื่นทำธุรกรรม NFT หรือทำลาย NFT ของผู้อื่น และไม่สามารถสั่งซื้อได้ เป็นต้น
โค้ดที่เป็นอันตรายส่วนหน้า (ผู้โจมตีจะฝังโค้ดที่เป็นอันตรายลงในส่วนหน้าของเว็บไซต์ เช่น การแลกเปลี่ยน เช่น ระบบการจัดการฉลากของเบราว์เซอร์ผู้ใช้ เพื่อให้สามารถสร้างการอนุมัติที่ผิดพลาดผ่านสตริงของโค้ดที่เป็นอันตรายนี้ ทำให้ทรัพย์สินของผู้ใช้สามารถ ถูกโอนไปยังที่อยู่ของผู้โจมตี)
คำอธิบายภาพ
เครดิตรูปภาพ: GoPlus
เครื่องมือทั่วไป:
เมื่อเปรียบเทียบกับการตรวจสอบความปลอดภัยของสัญญาอัจฉริยะ เนื้อหาทางธุรกิจที่เกี่ยวข้องกับการให้บริการมอนิเตอร์และไฟร์วอลล์นั้นซับซ้อนและมีรายละเอียดมากกว่า
Focus อัปเกรดการตรวจสอบความปลอดภัยของรหัสสัญญาอัจฉริยะก่อนและหลังการปรับใช้สัญญา โดยมักจะผ่านการทดสอบประเภทต่างๆ (การวิเคราะห์แบบคงที่ การวิเคราะห์แบบไดนามิก) เพื่อป้อนชุดค่าเพื่อดูว่าค่าเอาต์พุตและสถานะของสัญญาทำงานตามปกติหรือไม่ ตัวอย่างเช่น สำหรับลอจิกการถ่ายโอนแบบลูกโซ่ทั่วไป (ดังแสดงในรูปด้านล่าง) ผู้ทดสอบทั่วไปจะทำ: ถ่ายโอนอีเธอร์เป็นศูนย์, ถ่ายโอนอีเธอร์ทั้งหมด, ถ่ายโอนมากกว่าอีเทอร์ทั้งหมดเล็กน้อย, ถ่ายโอนอีเธอร์ในปริมาณมากที่สุดเท่าที่จะเป็นไปได้, ถ่ายโอน มูลค่าบัญชีให้กับตัวเองและสิ่งอื่น ๆ เพื่อดูว่าสัญญาสามารถทำตามที่โปรแกรมเมอร์คาดว่าจะทำและบรรลุผลได้หรือไม่
บริการมอนิเตอร์/ไฟร์วอลล์ของการวิเคราะห์ความปลอดภัยของ Focus ในกระบวนการนี้มีปัญหาที่ซับซ้อนกว่าที่ต้องจัดการ และในปัจจุบัน ดูเหมือนว่าบริการรักษาความปลอดภัยที่จัดทำโดยโครงการดังกล่าวให้ความสำคัญกับความกว้างมากขึ้น (ครอบคลุมสัญญาสินทรัพย์ที่เป็นปัญหาในเครือข่ายมากที่สุดเท่าที่จะเป็นไปได้ ล่าสุดระบุถึง URL ฟิชชิ่งของสัญญาที่สงสัยว่ามีพฤติกรรมฉ้อโกง ฯลฯ) พวกเขาจะถูกเปรียบเทียบ ด้วยบริการรักษาความปลอดภัยในการตรวจสอบสัญญาที่เบากว่า มันเกี่ยวข้องกับความเสี่ยงด้านความปลอดภัยหลายอย่างนอกเหนือจากการตรวจสอบความถูกต้องของรหัส เช่น การฉ้อโกงประเภทต่างๆ และการโจมตีที่เกี่ยวข้องกับฟิชชิง นอกเหนือจากการพึ่งพาความสามารถในการวิเคราะห์สัญญาแล้ว การตรวจสอบช่องโหว่เหล่านี้ยังต้องการการอัปเดตฐานข้อมูลความเสี่ยงอย่างต่อเนื่อง เช่น ที่อยู่ที่น่าสงสัย ตรรกะของสัญญาที่น่าสงสัย และรายการทรัพย์สินที่น่าสงสัย
จากการแลกเปลี่ยนกับผู้ปฏิบัติงานในอุตสาหกรรมเมื่อเร็วๆ นี้ เราพบว่าการวางตำแหน่งของบริการ Monitor ต่างๆ นั้นแตกต่างกันจริง ๆ ตัวอย่างเช่น GoPlus ให้ความสำคัญกับการให้บริการ data API แก่ฝ่ายโครงการและแม้กระทั่งไฟร์วอลล์ส่วนหน้าบางส่วน Harpie และ Blowfish จ่าย ให้ความสนใจมากขึ้นในการให้บริการส่วนหน้า , เมื่อผู้ใช้ดำเนินการพฤติกรรมการทำธุรกรรมหรือจำลองการทำธุรกรรมก่อนที่จะเสร็จสิ้นการอนุญาตเพื่อค้นหาปัญหาและป้องกันผู้ใช้จากการทำธุรกรรมที่มีความเสี่ยงด้านความปลอดภัย อ่อนโยน ให้ความสำคัญกับความต้องการของนักพัฒนาและให้บริการ เช่นการตรวจสอบการดำเนินงานสำหรับผู้พัฒนาสัญญาอัจฉริยะ แน่นอนว่าสาขานี้ค่อนข้างใหม่ในปัจจุบันแม้ว่าแพลตฟอร์มการค้าขนาดใหญ่เช่น Opensea ได้ดำเนินการความร่วมมือเชิงพาณิชย์ที่สำคัญกับบางโครงการแล้ว แต่เราเชื่อว่าเส้นทางสู่การค้าในอนาคตยังไม่ชัดเจนและจะมีการแข่งขันสูง ในอุตสาหกรรมเดียวกัน (เพราะเมื่อเปรียบเทียบกับการตรวจสอบโค้ดแล้ว เกณฑ์ทางเทคนิคจะต่ำกว่า)
โอกาสในการพัฒนาธุรกิจและความท้าทายของเครื่องมือวิเคราะห์ความปลอดภัยของสัญญาอัจฉริยะ
1) ในปัจจุบัน หลายคนในอุตสาหกรรมคิดว่าขอบเขตทางการค้าระหว่างการตรวจสอบและไฟร์วอลล์และการตรวจสอบความปลอดภัยยังค่อนข้างคลุมเครือ (ตอนนี้ พวกเขาเป็นบริการ 2B ทั้งหมด และลูกค้าส่วนใหญ่เป็นฝ่ายโครงการ crypto ต่างๆ) ซึ่งสอดคล้องกับ ตรรกะของการพัฒนาธุรกิจที่บริษัทตรวจสอบความปลอดภัยระดับมืออาชีพที่มีส่วนร่วมอย่างลึกซึ้งในสาขาความปลอดภัยของห่วงโซ่เป็นเวลาหลายปีให้บริการตรวจสอบโดยตรง และแม้แต่พัฒนาผลิตภัณฑ์ B2C และ 2C ที่เป็นประโยชน์ต่อผู้ใช้ปลายทางโดยตรง อย่างไรก็ตาม เนื่องจากการติดตามตรวจสอบเพิ่งเริ่มต้นขึ้น รูปแบบการเรียกเก็บเงินและรูปแบบกำไรยังไม่ชัดเจน (ปัจจุบันจะเห็นว่า 2B แยกค่าบริการหรือส่วนแบ่งค่าธรรมเนียมการทำธุรกรรมของโครงการ) หากตลาดดีขึ้น การรักษาความปลอดภัย ตลาดการตรวจสอบจะยังคงอยู่ในอุปทาน > อุปสงค์ และคำสั่งซื้อไม่สามารถดำเนินการได้ ในสถานะที่สมบูรณ์ อาจไม่มีเวลาดูแลตลาดเกิดใหม่นี้ กรอบเวลานี้จะเป็นโอกาสที่ดีสำหรับบริษัทเกิดใหม่ที่เชี่ยวชาญด้านการตรวจสอบ/ ไฟร์วอลล์
2) มีเครื่องมืออัตโนมัติมากมายสำหรับการตรวจสอบสัญญาอัจฉริยะในตลาด และมีเครื่องมือทั่วไปมากกว่าหนึ่งโหล ซึ่งส่วนใหญ่เป็นโอเพ่นซอร์ส รูปแบบธุรกิจของการคิดค่าธรรมเนียมโดยการขายเครื่องมือในทิศทางนี้ยังไม่ได้ผล เหตุผลหลักคือ: 1) ความสัมพันธ์ของเกมระหว่างแฮ็กเกอร์และผู้ปกป้องความปลอดภัยเป็นการแข่งขันทางอาวุธและการโจมตีมักเป็นเป้าหมายที่เคลื่อนไหว เมื่อเครื่องมือรักษาความปลอดภัยพร้อมใช้งาน แฮ็กเกอร์จะพยายามหลีกเลี่ยงและพัฒนารูปแบบการโจมตีใหม่ๆ ดังนั้น เครื่องมือรักษาความปลอดภัยสามารถอัปเดตซ้ำๆ เพื่อเพิ่มเกณฑ์การโจมตีเท่านั้น 2) เครื่องมือส่วนใหญ่มีอุปสรรคสูงในการใช้งาน และมีคนเพียงไม่กี่คนที่รู้วิธีใช้ผลิตภัณฑ์เครื่องมือวิเคราะห์ความปลอดภัยระดับมืออาชีพ ดังนั้นจึงจำกัดขนาดตลาด (แม้ว่าการตรวจสอบรันไทม์ กำลังถูกผลักดันให้นักพัฒนาทั่วไปใช้ Firefly, ConsenSys Dilligence มี MythX ด้วย) 3) เครื่องมือวิเคราะห์ความปลอดภัยสามารถครอบคลุมเฉพาะช่องโหว่หลักๆ เท่านั้น และลูกค้าที่แตกต่างกันตามโมเดลทางเศรษฐกิจของตรรกะทางธุรกิจของโปรโตคอลต้องการให้ทีมตรวจสอบให้บริการแบบกำหนดเองด้วยตนเอง .
ทีมงานยังหวังว่าบริษัทตรวจสอบบัญชีที่ได้รับอนุญาตจากตลาดจะให้บริการตรวจสอบเชิงลึกที่กำหนดเองได้มากขึ้นและประทับตราให้ ดังนั้นการให้บริการตรวจสอบจะเป็นโอกาสที่ดีสำหรับทีมรักษาความปลอดภัยมืออาชีพในการเข้าสู่ผลิตภัณฑ์ที่ปรับขนาดได้
ลิงค์ต้นฉบับ
