Believe it or not, Uniswap v4 จะพบกับทุกคนเร็ว ๆ นี้!

คราวนี้ทีม Uniswap ได้กําหนดเป้าหมายที่ทะเยอทะยานและวางแผนที่จะแนะนําคุณสมบัติใหม่ ๆ มากมายรวมถึงกลุ่มสภาพคล่องไม่ จํากัด จํานวนและค่าธรรมเนียมแบบไดนามิกสําหรับแต่ละคู่การซื้อขายการออกแบบ singleton การบัญชีแฟลช Hook และการสนับสนุนมาตรฐานโทเค็น ERC1155 การใช้ที่เก็บข้อมูลชั่วคราวที่แนะนําโดย EIP-1153 Uniswap v4 คาดว่าจะเปิดตัวหลังจากการอัปเกรด Ethereum Cancun ในบรรดานวัตกรรมมากมายกลไก Hook ได้รับความสนใจอย่างกว้างขวางเนื่องจากศักยภาพอันทรงพลัง กลไก Hook ช่วยให้โค้ดเฉพาะสามารถดําเนินการที่จุดเฉพาะในวงจรชีวิตของกลุ่มสภาพคล่องซึ่งช่วยเพิ่มความสามารถในการปรับขนาดและความยืดหยุ่นของพูลได้อย่างมาก อย่างไรก็ตามกลไก Hook ยังสามารถเป็นดาบสองคมได้ แม้ว่าจะทรงพลังและยืดหยุ่น แต่การใช้ Hook อย่างปลอดภัยก็เป็นความท้าทายที่สําคัญเช่นกัน ความซับซ้อนของ Hook ย่อมนํามาซึ่งเวกเตอร์การโจมตีที่อาจเกิดขึ้นใหม่อย่างหลีกเลี่ยงไม่ได้ ดังนั้นเราหวังว่าจะเขียนบทความชุดหนึ่งเพื่อแนะนําปัญหาด้านความปลอดภัยและความเสี่ยงที่อาจเกิดขึ้นเกี่ยวกับกลไก Hook อย่างเป็นระบบเพื่อส่งเสริมการพัฒนาความปลอดภัยของชุมชน เราเชื่อว่าข้อมูลเชิงลึกเหล่านี้จะช่วยสร้าง Uniswap v4 Hooks ที่ปลอดภัย บทความนี้จะแนะนําแนวคิดที่เกี่ยวข้องกับกลไก Hook ใน Uniswap v4 และสรุปความเสี่ยงด้านความปลอดภัยที่เกี่ยวข้องกับกลไก Hook

- 1 - กลไกของ Uniswap V4

ก่อนที่จะลงไปในลึกลับมากขึ้น เราต้องมีความเข้าใจพื้นฐานเกี่ยวกับกลไกของ Uniswap v4 ตามประกาศทางการ [1] และ whitepaper [2] Hooks, singleton architecture, และ flash accounting เป็นคุณสมบัติสำคัญ 3 ประการที่ทำให้สามารถปรับแต่งสระเงินสดและการเชื่อมต่อเส้นทางเป็นอย่างมีประสิทธิภาพข้ามสระเงินสดได้

1.1 Hook

Hooks หมายถึงสัญญาที่ทำงานในช่วงต่างๆของวัฒนธรรมการเงินสดของสระว่ายน้ำ ทีม Uniswap หวังว่าจะเปิดให้ใครๆก็สามารถตัดสินใจเกี่ยวกับการเทรดได้โดยการนำเสนอ Hooks อย่างนี้ โดยที่สนับสนุนเชิงธรรมชาติสำหรับค่าธรรมเนียมแบบไดนามิก คำสั่งซื้อที่เชื่อมต่ออยู่บนเชือกโซ่ หรือตลาดเมเกอร์เฉลี่ยน้ำหนักตามเวลา (TWAMMs) เพื่อแบ่งการสั่งซื้อขนาดใหญ่ ณ ปัจจุบันมี Hooks ชุดที่แบ่งออกเป็นสี่คู่ (แต่ละคู่มีการเรียกกลับหนึ่งครั้งก่อนและหลัง):

• beforeInitialize/afterInitialize
• beforeModifyPosition/afterModifyPosition
• ก่อนสวีท/หลังสวีท
• beforeDonate/afterDonate

ด้านล่างคือกระแสของการสลับเบ็ดเข้าใน whitepaper [2]

รูปที่ 1: การไหลของ Swap Hook

ทีม Uniswap ได้สาธิตวิธีการด้วยตัวอย่างบางอย่าง (เช่น TWAMM Hook [3]) และผู้เข้าร่วมชุมชนก็ได้มีส่วนร่วมด้วย ไฟล์เอกสารทางการ [4] ยังลิงก์ไปยังคลังข้อมูล Awesome Uniswap v4 Hooks [5] ที่รวบรวมตัวอย่าง Hook มากกว่า

1.2 โมดูลเดียว, การบัญชีแบบแฟลช, และกลไลล็อก

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

👇🏻 กลไกล็อคทำงานดังนี้: 1. สัญญาล็อคขอล็อคจาก PoolManager 2. PoolManager เพิ่มที่อยู่ของสัญญาล็อคเข้าไปในคิวข้อมูลล็อคและเรียก callback ล็อคที่ได้รับ 3. สัญญาล็อคดำเนินตามตรรกะใน callback การกระทำกับ pool ระหว่างการดำเนินการอาจทำให้เกิดการเพิ่มเงินตราที่ไม่เท่ากับศูนย์ อย่างไรก็ตาม ณ ที่สุดของการดำเนินการ การเพิ่มทั้งหมดต้องเท่ากับศูนย์ นอกจากนี้ถ้าคิวข้อมูลล็อคไม่ว่างเปล่า สัญญาล็อคคนสุดท้ายเท่านั้นที่สามารถดำเนินการ 4. PoolManager ตรวจสอบสถานะของคิวข้อมูลล็อคและการเพิ่มเงินตรา หลังจากการตรวจสอบ PoolManager จะนำสัญญาล็อคออก

โดยสรุปกลไกการล็อคจะป้องกันการเข้าถึงพร้อมกันและทําให้มั่นใจได้ว่าธุรกรรมทั้งหมดสามารถชําระได้ สัญญาล็อกเกอร์ขอล็อคตามลําดับจากนั้นดําเนินการซื้อขายผ่านล็อคการเรียกกลับ การเรียกกลับ Hook ที่สอดคล้องกันจะถูกเรียกใช้ก่อนและหลังการดําเนินการพูลแต่ละครั้ง สุดท้าย PoolManager ตรวจสอบสถานะ ซึ่งหมายความว่าการดําเนินการจะปรับยอดคงเหลือสุทธิภายใน (เช่น เดลต้า) แทนที่จะทําการโอนทันที การปรับเปลี่ยนใด ๆ จะถูกบันทึกไว้ในยอดคงเหลือภายในของพูลโดยการถ่ายโอนจริงจะเกิดขึ้นเมื่อการดําเนินการ (เช่นล็อค) สิ้นสุดลง กระบวนการนี้รับประกันว่าไม่มีโทเค็นที่โดดเด่นรักษาความสมบูรณ์ของเงินทุน เนื่องจากกลไกการล็อกบัญชีที่เป็นเจ้าของภายนอก (EOAs) จึงไม่สามารถโต้ตอบโดยตรงกับ PoolManager ได้ แต่การโต้ตอบใด ๆ จะต้องผ่านสัญญา สัญญานี้ทําหน้าที่เป็นตู้เก็บของตัวกลางโดยขอล็อคก่อนดําเนินการสระว่ายน้ําใด ๆ (12/08)

👇🏻 มีสองสถานการณ์การโต้ตอบสัญญาหลัก:

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

- 2 -โมเดลอันตราย

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

• แบบจำลองการทุจริต I: ตัวติดตั้งเองไม่เป็นอันตราย แต่มีช่องโหว่
• โมเดลการละเมิด II: ตัวตั้งตามเป้าเองเป็นอันตราย

ในส่วนถัดไป เราจะพูดถึงปัญหาด้านความปลอดภัยที่เป็นไปได้ตามแบบจำลองการเสี่ยงสองแบบนี้

2.1 ปัญหาด้านความปลอดภัยใน Threat Model I

Threat Model I มุ่งเน้นไปที่ช่องโหว่ที่เกี่ยวข้องกับ Hook เอง รูปแบบภัยคุกคามนี้ถือว่านักพัฒนาและ Hook ของพวกเขาไม่เป็นอันตราย อย่างไรก็ตาม ช่องโหว่ที่รู้จักที่มีอยู่ในสัญญาอัจฉริยะอาจปรากฏใน Hooks ด้วย ตัวอย่างเช่นหากมีการใช้ Hook เป็นสัญญาที่อัปเกรดได้อาจพบปัญหาที่เกี่ยวข้องกับช่องโหว่เช่น OpenZeppelin UUPSUpgradeable จากปัจจัยข้างต้นเราเลือกที่จะมุ่งเน้นไปที่ช่องโหว่ที่อาจเกิดขึ้นเฉพาะในเวอร์ชัน 4 ใน Uniswap v4 Hooks เป็นสัญญาอัจฉริยะที่สามารถใช้ตรรกะที่กําหนดเองก่อนหรือหลังการดําเนินการพูลหลัก (รวมถึงการเริ่มต้นการปรับเปลี่ยนตําแหน่งการแลกเปลี่ยนและการรวบรวม) แม้ว่า Hooks คาดว่าจะใช้อินเทอร์เฟซมาตรฐาน แต่ก็อนุญาตให้มีตรรกะที่กําหนดเองได้ ดังนั้นการสนทนาของเราจะถูก จํากัด ไว้ที่ตรรกะที่เกี่ยวข้องกับอินเทอร์เฟซ Hook มาตรฐาน จากนั้นเราจะพยายามระบุแหล่งที่มาของช่องโหว่ที่อาจเกิดขึ้น เช่น Hooks อาจใช้ฟังก์ชัน Hook มาตรฐานเหล่านี้ในทางที่ผิดอย่างไร

👇🏻 โดยเฉพาะ, เราจะเน้นที่การใช้กั้นสองประเภทต่อไปนี้:

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

โปรดทราบว่าตะขอนอกขอบเขตทั้งสองนี้ไม่ได้กล่าวถึงที่นี่ เนื่องจากไม่มีกรณีการใช้งาน Hook ในโลกแห่งความเป็นจริงในขณะที่เขียนนี้เราจะนําข้อมูลบางส่วนจากที่เก็บ Awesome Uniswap v4 Hooks หลังจากการศึกษาเชิงลึกของที่เก็บ Awesome Uniswap v4 Hooks (commit hash 3a0a444922f26605ec27a41929f3ced924af6075) เราพบช่องโหว่ที่รุนแรงหลายประการ ช่องโหว่เหล่านี้ส่วนใหญ่เกิดจากการโต้ตอบที่มีความเสี่ยงระหว่างเบ็ด PoolManager และบุคคลที่สามภายนอกและสามารถแบ่งออกเป็นสองประเภท: ปัญหาการควบคุมการเข้าถึงและปัญหาการตรวจสอบอินพุต การค้นพบที่เฉพาะเจาะจงแสดงอยู่ในตารางด้านล่าง:

สรุปแล้วเราพบว่ามีโครงการที่เกี่ยวข้อง 22 โครงการ (ไม่รวมถึงโครงการที่ไม่เกี่ยวข้องกับ Uniswap v4) ในโครงการเหล่านี้ เราเชื่อว่ามีช่องโหว่ 8 (36%) โครงการ ใน 8 โครงการที่มีช่องโหว่ มีปัญหาในการควบคุมการเข้าถึง 6 โครงการ และ 2 โครงการอื่นที่มีช่องโหว่ต่อการเรียกใช้ภายนอกที่ไม่น่าเชื่อถือ

2.1.1 ปัญหาควบคุมการเข้าถึง

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

2.1.2 ปัญหาการตรวจสอบข้อมูลนำเข้า

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

• ตัวตราไม่ยืนยันสระว่ายน้ำที่ผู้ใช้ตั้งใจจะโต้ตอบ นี่อาจเป็นสระว่ายน้ำที่เป็นอันตรายด้วยตลอดจนมีโลจิกที่อันตราย
• ฟังก์ชันเบ้าคีย์บางส่วนอนุญาตการเรียกใช้ภายนอกอย่างอิสระ

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

2.1.3 มาตรการป้องกันสำหรับโมเดลอันตราย I

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

2.2 ปัญหาด้านความปลอดภัยใน Threat Model II

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

• Managed Hooks: ตัวก้าวลองไม่ใช่จุดเข้าใช้งาน ผู้ใช้ต้องปฏิสัมพันธ์กับก้าวลองผ่านเราเตอร์ (อาจจะได้รับการ提供โดย Uniswap)
• Standalone Hooks: ตัวตั้งครั้งเดียว: ตัวตั้งครั้งเดียวคือจุดเข้าใช้งาน ที่ทำให้ผู้ใช้สามารถทำงานกับมันโดยตรง

รูปที่ 2: ตัวอย่างของการติดตั้งแบบที่ไม่ดี

2.2.1 การจัดการ ฉลาก

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

2.2.2 Standalone Hooks

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

• พร็อกซี่ที่สามารถอัพเกรดได้ (ซึ่งสามารถถูกโจมตีโดยตรง)
• โลจิกที่มีการทำลายตัวเอง อาจถูกโจมตีพร้อมกับการเรียกใช้ selfdestruct และ create2

2.2.3 มาตรการป้องกันสำหรับแบบจำลองอันตราย II

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

- 3 - สรุป

ในบทความนี้ เราจะกล่าวถึงกลไกหลักที่เกี่ยวข้องกับประเด็นความปลอดภัยของ Uniswap v4 Hook อย่างสั้น ๆ จากนั้นเราจะนำเสนอโมเดลอันตรายสองรูปแบบ และกล่าวถึงความเสี่ยงด้านความปลอดภัยที่เกี่ยวข้องอย่างสั้น ๆ ในบทความต่อไป เราจะทำการวิเคราะห์อย่างละเอียดเกี่ยวกับประเด็นความปลอดภัยภายใต้แต่ละโมเดลอันตราย อยู่รอดูความเคลื่อนไหว!

อ้างอิง

[1] วิสัยทัศน์ของเราสำหรับ Uniswap V4
https://blog.uniswap.org/uniswap-v4

[2] ฉบับร่างของเอกสาร Whitepaper ของ Uniswap v4
https://github.com/Uniswap/v4-core/blob/main/whitepaper-v4-draft.pdf

[3] Uniswap v4 TWAMM Hook
https://blog.uniswap.org/v4-twamm-hook

[4] ตัวอย่างของการเชื่อมต่อ
https://docs.uniswapfoundation.org/hooks/hook-examples

[5] การเชื่อมโยง Uniswap v4 ที่น่าทึ่ง
https://github.com/fewwwww/awesome-uniswap-hooks

[6] UUPSUpgradeable อันตรายหลังการตาย
https://forum.openzeppelin.com/t/uupsupgradeable-vulnerability-post-mortem/15680

เกี่ยวกับ BlockSec BlockSec เป็น บริษัท รักษาความปลอดภัยบล็อกเชนชั้นนําระดับโลกที่ก่อตั้งขึ้นในปี 2021 โดยผู้เชี่ยวชาญที่มีชื่อเสียงในอุตสาหกรรมความปลอดภัย บริษัท มุ่งมั่นที่จะเพิ่มความปลอดภัยและการใช้งานสําหรับโลก Web3 เพื่อส่งเสริมการนํา Web3 มาใช้อย่างกว้างขวาง เพื่อให้บรรลุเป้าหมายนี้ BlockSec ให้บริการตรวจสอบความปลอดภัยของสัญญาอัจฉริยะและโซ่ EVM การพัฒนาความปลอดภัยการทดสอบและระบบสกัดกั้นแฮ็กเกอร์ที่เรียกว่า Phalcon สําหรับเจ้าของโครงการแพลตฟอร์มการติดตามและตรวจสอบกองทุนที่เรียกว่า MetaSleuth รวมถึงปลั๊กอินประสิทธิภาพสําหรับผู้สร้าง web3 ที่เรียกว่า MetaDock ปัจจุบัน บริษัท ให้บริการลูกค้ามากกว่า 300 รายรวมถึงโครงการที่มีชื่อเสียงเช่น MetaMask, Compound, Uniswap Foundation, Forta, PancakeSwap และได้รับเงินทุนสองรอบรวมหลายสิบล้านดอลลาร์จากสถาบันการลงทุนเช่น Oasis Capital, IDG Capital และ Distributed Capital โฮมเพจ:www.blocksec.com

Twitter：https://twitter.com/บล็อกSecTeam

Phalcon: https://phalcon.xyz/

MetaSleuth: https://metasleuth.io/

MetaDock: https://blocksec.com/metadock

Disclaimer：

1. บทความนี้ถูกนำมาจาก [บล็อกSec]. ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [บล็อกSec]. หากมีข้อติเตียนต่อการนำเผยแพร่นี้ โปรดติดต่อGate ศึกษาทีม และพวกเขาจะดำเนินการโดยเร็ว
2. คำประกาศความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นที่ปรึกษาด้านการลงทุนใด ๆ
3. การแปลบทความเป็นภาษาอื่นๆ ทำโดยทีม Gate Learn หากไม่ได้กล่าวถึง การคัดลอก การแจกจ่าย หรือการลอกเลียนแบบบทความที่ถูกแปลนั้นถือเป็นการละเมิด