ฉันเชื่อว่า Uniswap v4 จะเปิดให้ทุกคนใช้งานได้เร็วๆ นี้!
คราวนี้ทีมงาน Uniswap มีเป้าหมายที่ทะเยอทะยานและวางแผนที่จะแนะนำคุณสมบัติใหม่มากมาย [1] รวมถึงการรองรับกลุ่มสภาพคล่องไม่จำกัดจำนวน และค่าธรรมเนียมแบบไดนามิกสำหรับคู่การซื้อขายแต่ละคู่ การออกแบบซิงเกิลตัน การบัญชีฟ้าผ่า Hooks และการสนับสนุนโทเค็น ERC1155 มาตรฐาน. Uniswap v4 ใช้ประโยชน์จากพื้นที่เก็บข้อมูลชั่วคราวที่แนะนำโดย EIP-1153 และคาดว่าจะเปิดตัวหลังจากอัปเกรด Ethereum Cancun
ในบรรดานวัตกรรมใหม่ ๆ กลไก Hook ได้รับความสนใจอย่างกว้างขวางเนื่องจากมีศักยภาพอันทรงพลัง กลไก Hook รองรับการดำเนินการโค้ดเฉพาะที่จุดเฉพาะในวงจรชีวิตของพูลสภาพคล่อง ซึ่งช่วยเพิ่มความสามารถในการปรับขนาดและความยืดหยุ่นของพูลได้อย่างมาก
อย่างไรก็ตาม กลไกตะขอก็สามารถเป็นดาบสองคมได้เช่นกัน แม้ว่าจะทรงพลังและยืดหยุ่น แต่การใช้ Hook อย่างปลอดภัยก็เป็นความท้าทายที่ยิ่งใหญ่เช่นกัน ความซับซ้อนของ hooks ย่อมนำมาซึ่งเวกเตอร์การโจมตีใหม่ๆ ที่อาจเกิดขึ้นอย่างหลีกเลี่ยงไม่ได้ ดังนั้นเราจึงหวังว่าจะเขียนบทความชุดหนึ่งเพื่อแนะนำปัญหาด้านความปลอดภัยและความเสี่ยงที่อาจเกิดขึ้นที่เกี่ยวข้องกับกลไก Hook อย่างเป็นระบบ เพื่อส่งเสริมการพัฒนาความปลอดภัยของชุมชน เราเชื่อว่าข้อมูลเชิงลึกเหล่านี้จะช่วยสร้าง Uniswap v4 Hook ที่ปลอดภัย
ในตอนต้นของบทความชุดนี้ บทความนี้จะแนะนำแนวคิดที่เกี่ยวข้องกับกลไก Hook ใน Uniswap v4 และสรุปความเสี่ยงด้านความปลอดภัยของกลไก Hook
1.กลไก Uniswap V4
ก่อนที่เราจะเจาะลึก เราจำเป็นต้องมีความเข้าใจพื้นฐานเกี่ยวกับกลไกของ Uniswap v4 ตามประกาศอย่างเป็นทางการ [1] และเอกสารไวท์เปเปอร์ [2] Hooks สถาปัตยกรรมซิงเกิลตัน และการบัญชี lightning เป็นหน้าที่ที่สำคัญสามประการในการใช้พูลสภาพคล่องแบบกำหนดเอง และบรรลุการกำหนดเส้นทางที่มีประสิทธิภาพข้ามพูลหลายแห่ง
1.1 ตะขอ
Hooks หมายถึงสัญญาที่ทำงานในขั้นตอนต่างๆ ของวงจรชีวิตของแหล่งรวมสภาพคล่อง ทีมงาน Uniswap หวังว่าจะช่วยให้ใครก็ตามสามารถตัดสินใจแลกเปลี่ยนได้โดยการแนะนำ Hooks ด้วยวิธีนี้ จึงเป็นไปได้ที่จะรองรับค่าธรรมเนียมแบบไดนามิก เพิ่มคำสั่งซื้อแบบ on-chain cap หรือกระจายคำสั่งซื้อจำนวนมากผ่านผู้ดูแลสภาพคล่องโดยเฉลี่ยตามเวลา (TWAMM)
ขณะนี้มีการโทรกลับ Hook แปดรายการ แบ่งออกเป็นสี่กลุ่ม (แต่ละกลุ่มมีการโทรกลับคู่หนึ่ง):
- beforeInitialize/หลังInitialize
- beforeModifyPosition/หลังแก้ไขPosition
- ก่อนสลับ/หลังสลับ
- ก่อนบริจาค/หลังบริจาค
ต่อไปนี้คือขั้นตอนการแลกเปลี่ยน Hooks ที่แนะนำในเอกสารไวท์เปเปอร์ [2]
รูปที่ 1: กระบวนการแลกเปลี่ยน Hook
ทีมงาน Uniswap ได้แนะนำวิธีดำเนินการพร้อมตัวอย่างบางส่วน (เช่น TWAMM Hook[3]) และผู้เข้าร่วมชุมชนก็มีส่วนสนับสนุนด้วยเช่นกัน เอกสารอย่างเป็นทางการ[4] ยังลิงก์ไปยังที่เก็บ Awesome Uniswap v4 Hooks[5] ซึ่งรวบรวมตัวอย่าง Hook เพิ่มเติม
1.2 ซิงเกิลตัน การบัญชีฟ้าผ่า และกลไกการล็อค
ทีมงาน Uniswap ได้แนะนำวิธีดำเนินการพร้อมตัวอย่างบางส่วน (เช่น TWAMM Hook[3]) และผู้เข้าร่วมชุมชนก็มีส่วนร่วมด้วยเช่นกัน เอกสารอย่างเป็นทางการ[4] ยังลิงก์ไปยังที่เก็บ Awesome Uniswap v4 Hooks[5] ซึ่งรวบรวมตัวอย่าง Hook เพิ่มเติม
1.2 ซิงเกิลตัน การบัญชีฟ้าผ่า และกลไกการล็อค
สถาปัตยกรรมซิงเกิลตันและการบัญชีแฟลชได้รับการออกแบบมาเพื่อปรับปรุงประสิทธิภาพโดยการลดต้นทุนและสร้างความมั่นใจในประสิทธิภาพ โดยจะแนะนำสัญญาซิงเกิลตันใหม่ โดยที่กลุ่มสภาพคล่องทั้งหมดจะถูกเก็บไว้ในสัญญาอัจฉริยะเดียวกัน การออกแบบซิงเกิลตันนี้อาศัย PoolManager เพื่อจัดเก็บและจัดการสถานะของพูลทั้งหมด
ในเวอร์ชันก่อนหน้าของโปรโตคอล Uniswap การดำเนินการต่างๆ เช่น การแลกเปลี่ยนหรือเพิ่มสภาพคล่องเกี่ยวข้องกับการถ่ายโอนโทเค็นโดยตรง เวอร์ชัน v4 แตกต่างตรงที่จะมีการแนะนำบัญชี lightning และกลไกการล็อค
👇🏻 กลไกการล็อคทำงานดังนี้:
- สัญญาล็อคเกอร์ขอล็อค PoolManager
- PoolManager เพิ่มที่อยู่ของสัญญาล็อกเกอร์ลงในคิว lockData และเรียกการโทรกลับ lockAcquired
- สัญญาล็อกเกอร์ดำเนินการตรรกะในการเรียกกลับ ในระหว่างการดำเนินการ การโต้ตอบของสัญญาล็อกเกอร์กับพูลอาจส่งผลให้มีการเพิ่มสกุลเงินที่ไม่เป็นศูนย์ อย่างไรก็ตาม เมื่อสิ้นสุดการดำเนินการ เดลต้าทั้งหมดจะต้องกลายเป็นศูนย์ นอกจากนี้ หากคิว lockData ไม่ว่างเปล่า เฉพาะสัญญาล็อกเกอร์สุดท้ายเท่านั้นที่สามารถดำเนินการได้
- PoolManager ตรวจสอบสถานะของคิว lockData และการเพิ่มสกุลเงิน หลังจากการตรวจสอบ PoolManager จะลบสัญญาล็อคเกอร์
โดยสรุป กลไกการล็อคป้องกันการเข้าถึงพร้อมกันและทำให้มั่นใจได้ว่าธุรกรรมทั้งหมดสามารถล้างได้ สัญญาล็อกเกอร์ใช้สำหรับการล็อกตามลำดับ จากนั้นดำเนินธุรกรรมผ่านการเรียกกลับ lockAcquired Hook callback ที่เกี่ยวข้องจะถูกทริกเกอร์ก่อนและหลังการดำเนินการพูลแต่ละครั้ง สุดท้าย PoolManager จะตรวจสอบสถานะ
วิธีการนี้หมายความว่าการดำเนินการจะปรับยอดสุทธิภายใน (เช่น เดลต้า) แทนที่จะดำเนินการถ่ายโอนทันที การปรับเปลี่ยนใดๆ จะถูกบันทึกไว้ในสมดุลภายในของพูล และการโอนจริงจะดำเนินการเมื่อสิ้นสุดการดำเนินการ (เช่น ล็อค) กระบวนการนี้ทำให้แน่ใจได้ว่าไม่มีโทเค็นที่โดดเด่น ซึ่งจะช่วยรักษาความสมบูรณ์ของเงินทุน
เนื่องจากกลไกการล็อค บัญชีความเป็นเจ้าของภายนอก (EOA) ไม่สามารถโต้ตอบกับ PoolManager ได้โดยตรง ปฏิสัมพันธ์ใดๆ จะต้องเกิดขึ้นผ่านสัญญาแทน สัญญานี้ทำหน้าที่เป็นตู้เก็บของกลาง และจำเป็นต้องขอล็อคก่อนดำเนินการใดๆ ของพูล
👇🏻 มีสองสถานการณ์การโต้ตอบสัญญาหลัก:
- สัญญาล็อคเกอร์บางอย่างมาจากฐานรหัสอย่างเป็นทางการหรือถูกปรับใช้โดยผู้ใช้ ในกรณีนี้ เราสามารถนึกถึงการโต้ตอบที่ส่งผ่านเราเตอร์ได้
- สัญญาล็อคเกอร์และ Hook บางอย่างรวมอยู่ในสัญญาเดียวกันหรือควบคุมโดยหน่วยงานบุคคลที่สาม ในกรณีนี้ เราสามารถนึกถึงการโต้ตอบที่เกิดขึ้นผ่าน Hooks ได้ ในกรณีนี้ Hook ต่างก็มีบทบาทเป็นสัญญาล็อคเกอร์และรับผิดชอบในการจัดการการโทรกลับ
2. รูปแบบภัยคุกคาม
ก่อนที่จะหารือเกี่ยวกับปัญหาด้านความปลอดภัยที่เกี่ยวข้อง เราจำเป็นต้องระบุโมเดลภัยคุกคามก่อน เราพิจารณาสองสถานการณ์ต่อไปนี้เป็นหลัก:
- โมเดลภัยคุกคาม 1: ตัวตะขอเองก็ไม่เป็นอันตราย แต่ก็มีช่องโหว่อยู่
- รูปแบบภัยคุกคาม II: Hooks เป็นอันตรายโดยธรรมชาติ
ในส่วนต่อไปนี้ เราจะหารือเกี่ยวกับปัญหาด้านความปลอดภัยที่อาจเกิดขึ้นตามโมเดลภัยคุกคามทั้งสองนี้
2.1 ปัญหาด้านความปลอดภัยในรูปแบบภัยคุกคาม I
โมเดลภัยคุกคาม I มุ่งเน้นไปที่ช่องโหว่ที่เกี่ยวข้องกับ Hook รูปแบบภัยคุกคามนี้ถือว่านักพัฒนาและ hooks ของพวกเขาไม่เป็นอันตราย อย่างไรก็ตาม ช่องโหว่ที่ทราบอยู่แล้วในสัญญาอัจฉริยะอาจปรากฏใน Hooks ด้วย ตัวอย่างเช่น หาก Hook ถูกนำมาใช้เป็นสัญญาที่สามารถอัปเกรดได้ ก็อาจประสบปัญหาที่เกี่ยวข้องกับช่องโหว่ UUPSUpgradeable ของ OpenZeppelin
โมเดลภัยคุกคาม I มุ่งเน้นไปที่ช่องโหว่ที่เกี่ยวข้องกับ Hook รูปแบบภัยคุกคามนี้ถือว่านักพัฒนาและ hooks ของพวกเขาไม่เป็นอันตราย อย่างไรก็ตาม ช่องโหว่ที่ทราบอยู่แล้วในสัญญาอัจฉริยะอาจปรากฏใน Hooks ด้วย ตัวอย่างเช่น หาก Hook ถูกนำมาใช้เป็นสัญญาที่สามารถอัปเกรดได้ ก็อาจประสบปัญหาที่เกี่ยวข้องกับช่องโหว่ UUPSUpgradeable ของ OpenZeppelin
เมื่อพิจารณาจากปัจจัยข้างต้น เราเลือกที่จะมุ่งเน้นไปที่ช่องโหว่ที่อาจเกิดขึ้นโดยเฉพาะในเวอร์ชัน v4 ใน Uniswap เวอร์ชัน 4 Hooks คือสัญญาอัจฉริยะที่สามารถดำเนินการตรรกะที่กำหนดเองก่อนหรือหลังการดำเนินการพูลหลัก (รวมถึงการเริ่มต้น การแก้ไขตำแหน่ง การสลับ และการรวบรวม) แม้ว่า Hooks คาดว่าจะใช้อินเทอร์เฟซมาตรฐาน แต่ก็ยังอนุญาตให้รวมตรรกะที่กำหนดเองได้ ดังนั้นการสนทนาของเราจะจำกัดอยู่เพียงตรรกะที่เกี่ยวข้องกับอินเทอร์เฟซ Hook มาตรฐาน จากนั้นเราจะพยายามระบุแหล่งที่มาของช่องโหว่ที่เป็นไปได้ เช่น วิธีที่ Hooks อาจละเมิดฟังก์ชัน Hook มาตรฐานเหล่านี้
👇🏻 โดยเฉพาะเราจะเน้นไปที่ Hooks สองประเภทต่อไปนี้:
- ตะขอประเภทแรกคือการเก็บเงินทุนของผู้ใช้ ในกรณีนี้ ผู้โจมตีอาจโจมตีตะขอนี้เพื่อโอนเงิน ทำให้เกิดการสูญเสียทรัพย์สิน
- hook ประเภทที่สองจะเก็บข้อมูลสถานะคีย์ที่ผู้ใช้หรือโปรโตคอลอื่น ๆ พึ่งพา ในกรณีนี้ ผู้โจมตีอาจพยายามเปลี่ยนสถานะวิกฤติ ความเสี่ยงที่อาจเกิดขึ้นอาจเกิดขึ้นเมื่อผู้ใช้หรือโปรโตคอลอื่นใช้สถานะที่ไม่ถูกต้อง
โปรดทราบว่า hooks ที่อยู่นอกขอบเขตทั้งสองนี้อยู่นอกขอบเขตการสนทนาของเรา
เนื่องจากไม่มีกรณีการใช้งานจริงสำหรับ Hooks ในขณะที่เขียน เราจะได้รับข้อมูลบางส่วนจากพื้นที่เก็บข้อมูล Awesome Uniswap v4 Hooks
หลังจากการศึกษาเชิงลึกเกี่ยวกับพื้นที่เก็บข้อมูล Awesome Uniswap v4 Hooks (คอมมิตแฮช 3a0a444922f26605ec27a41929f3ced924af6075) เราค้นพบช่องโหว่ที่สำคัญหลายประการ ช่องโหว่เหล่านี้ส่วนใหญ่เกิดจากการโต้ตอบความเสี่ยงระหว่าง hooks, PoolManager และบุคคลที่สามภายนอก และสามารถแบ่งออกเป็นสองประเภทหลัก ๆ ได้แก่ ปัญหาการควบคุมการเข้าถึงและปัญหาการตรวจสอบอินพุต โปรดดูตารางด้านล่างสำหรับการค้นพบที่เฉพาะเจาะจง:
โดยรวมแล้ว เราพบโครงการที่เกี่ยวข้อง 22 โครงการ (ไม่รวมโครงการที่ไม่เกี่ยวข้องกับ Uniswap v4) จากโครงการเหล่านี้ เราเชื่อว่า 8 (36%) มีความเสี่ยง จากแปดโครงการที่มีช่องโหว่ มีหกโครงการมีปัญหาในการควบคุมการเข้าถึง และอีกสองโครงการเสี่ยงต่อการโทรภายนอกที่ไม่น่าเชื่อถือ
2.1.1 ปัญหาการควบคุมการเข้าถึง
ในการสนทนาในส่วนนี้ เรามุ่งเน้นไปที่ปัญหาที่อาจเกิดจากฟังก์ชันการโทรกลับในเวอร์ชัน 4 เป็นหลัก รวมถึงการโทรกลับแบบ hook 8 ครั้งและการล็อกการโทรกลับ แน่นอนว่ายังมีสถานการณ์อื่นๆ ที่ต้องตรวจสอบ แต่สถานการณ์เหล่านี้แตกต่างกันไปตามการออกแบบและอยู่นอกเหนือขอบเขตของการสนทนาของเรา
PoolManager ควรเรียกใช้ฟังก์ชันเหล่านี้เท่านั้น และไม่สามารถเรียกใช้โดยที่อยู่อื่น (รวมถึง EOA และสัญญา) ตัวอย่างเช่น ในกรณีที่รางวัลถูกแจกจ่ายด้วยรหัสพูล รางวัลอาจถูกอ้างสิทธิ์อย่างไม่ถูกต้อง หากบัญชีใด ๆ สามารถเรียกใช้ฟังก์ชันที่เกี่ยวข้องได้
ดังนั้นจึงเป็นสิ่งสำคัญที่จะต้องสร้างกลไกการควบคุมการเข้าถึงที่แข็งแกร่งสำหรับ hooks โดยเฉพาะอย่างยิ่งเนื่องจากสามารถเรียกได้โดยฝ่ายอื่นที่ไม่ใช่พูลเอง ด้วยการจัดการสิทธิ์การเข้าถึงอย่างเข้มงวด กลุ่มสภาพคล่องสามารถลดความเสี่ยงของการโต้ตอบกับ hook ที่ไม่ได้รับอนุญาตหรือเป็นอันตรายได้อย่างมาก
2.1.2 คำถามยืนยันการป้อนข้อมูล
ใน Uniswap v4 เนื่องจากกลไกการล็อค ผู้ใช้จะต้องได้รับการล็อคผ่านสัญญาก่อนที่จะดำเนินการใดๆ ในกลุ่มกองทุน เพื่อให้แน่ใจว่าสัญญาที่เข้าร่วมในการโต้ตอบในปัจจุบันนั้นเป็นสัญญาล็อคเกอร์ล่าสุด
อย่างไรก็ตาม ยังมีสถานการณ์การโจมตีที่เป็นไปได้ กล่าวคือ การเรียกจากภายนอกที่ไม่น่าเชื่อถือ เนื่องจากการตรวจสอบอินพุตที่ไม่เหมาะสมในการใช้งาน Hook ที่มีช่องโหว่:
- ขั้นแรก hook จะไม่ตรวจสอบพูลที่ผู้ใช้ตั้งใจจะโต้ตอบด้วย นี่อาจเป็นพูลที่เป็นอันตรายซึ่งมีโทเค็นปลอมและดำเนินการตรรกะที่เป็นอันตราย
- ประการที่สอง ฟังก์ชั่นขอกุญแจบางฟังก์ชั่นอนุญาตให้มีการโทรภายนอกโดยพลการ
การโทรภายนอกที่ไม่น่าเชื่อถือเป็นอันตรายอย่างยิ่ง เนื่องจากสามารถนำไปสู่การโจมตีได้หลายประเภท รวมถึงสิ่งที่เราเรียกว่าการโจมตีกลับเข้ามาใหม่
การโทรภายนอกที่ไม่น่าเชื่อถือเป็นอันตรายอย่างยิ่ง เนื่องจากสามารถนำไปสู่การโจมตีได้หลายประเภท รวมถึงสิ่งที่เราเรียกว่าการโจมตีกลับเข้ามาใหม่
เพื่อโจมตี hook ที่มีช่องโหว่เหล่านี้ ผู้โจมตีสามารถลงทะเบียนกลุ่มกองทุนที่เป็นอันตรายสำหรับโทเค็นปลอมของเขาเอง จากนั้นจึงเรียก hook เพื่อดำเนินการในกองทุนรวม เมื่อโต้ตอบกับพูล ตรรกะโทเค็นที่เป็นอันตรายจะแย่งชิงโฟลว์การควบคุมเพื่อมีส่วนร่วมในพฤติกรรมที่ไม่พึงประสงค์
2.1.3 มาตรการป้องกันภัยคุกคามรูปแบบที่ 1
เพื่อหลีกเลี่ยงปัญหาด้านความปลอดภัยที่เกี่ยวข้องกับ hooks จำเป็นอย่างยิ่งที่จะต้องตรวจสอบความถูกต้องของการโต้ตอบโดยการบังคับใช้การควบคุมการเข้าถึงที่จำเป็นอย่างเหมาะสมกับฟังก์ชันภายนอก/สาธารณะที่มีความละเอียดอ่อน และตรวจสอบความถูกต้องของพารามิเตอร์อินพุต นอกจากนี้ การป้องกันการเกิดซ้ำอาจช่วยให้แน่ใจว่า hooks จะไม่ถูกดำเนินการซ้ำๆ ในโฟลว์ลอจิกมาตรฐาน ด้วยการใช้ระบบรักษาความปลอดภัยที่เหมาะสม กลุ่มสามารถลดความเสี่ยงที่เกี่ยวข้องกับภัยคุกคามดังกล่าวได้
2.2 ปัญหาด้านความปลอดภัยในรูปแบบภัยคุกคาม II
ในรูปแบบภัยคุกคามนี้ เราถือว่านักพัฒนาและ hook ของเขาเป็นอันตราย เนื่องจากขอบเขตที่กว้าง เราจึงมุ่งเน้นไปที่ปัญหาด้านความปลอดภัยที่เกี่ยวข้องกับเวอร์ชัน v4 เท่านั้น ดังนั้น สิ่งสำคัญก็คือว่า hook ที่ให้มาสามารถจัดการสินทรัพย์ crypto ที่ถ่ายโอนหรือได้รับอนุญาตจากผู้ใช้ได้หรือไม่
เนื่องจากวิธีการเข้าถึง hook จะกำหนดสิทธิ์ที่อาจมอบให้กับ hook เราจึงแบ่ง hooks ออกเป็นสองประเภท:
- Managed Hooks: Hooks ไม่ใช่จุดเริ่มต้น ผู้ใช้จะต้องโต้ตอบกับ hook ผ่านเราเตอร์ (อาจให้โดย Uniswap)
- Hooks แบบสแตนด์อโลน: Hooks เป็นจุดเริ่มต้นที่อนุญาตให้ผู้ใช้โต้ตอบกับพวกเขาโดยตรง
รูปที่ 2: ตัวอย่างตะขอที่เป็นอันตราย
2.2.1 ตะขอที่ได้รับการจัดการ
ในกรณีนี้ สินทรัพย์เข้ารหัสลับของผู้ใช้ (รวมถึงโทเค็นดั้งเดิมและโทเค็นอื่น ๆ) จะถูกโอนหรืออนุญาตไปยังเราเตอร์ เนื่องจาก PoolManager ทำการตรวจสอบยอดเงิน จึงไม่ใช่เรื่องง่ายที่ hook ที่เป็นอันตรายจะขโมยทรัพย์สินเหล่านี้โดยตรง อย่างไรก็ตาม ยังคงมีพื้นผิวการโจมตีที่อาจเกิดขึ้นได้ ตัวอย่างเช่น กลไกการจัดการค่าใช้จ่ายของเวอร์ชัน 4 อาจถูกจัดการโดยผู้โจมตีผ่าน hooks
2.2.2 ตะขออิสระ
สถานการณ์จะซับซ้อนมากขึ้นเมื่อใช้ Hooks เป็นจุดเริ่มต้น ในกรณีนี้ ตะขอจะได้รับพลังมากขึ้นเนื่องจากผู้ใช้สามารถโต้ตอบกับมันได้โดยตรง ตามทฤษฎีแล้ว hook สามารถทำอะไรก็ได้ที่ต้องการด้วยการโต้ตอบนี้
ในเวอร์ชัน v4 การตรวจสอบตรรกะของโค้ดมีความสำคัญมาก ปัญหาหลักคือว่าโค้ดลอจิกสามารถจัดการได้หรือไม่ ถ้า hook สามารถอัพเกรดได้ นั่นหมายความว่า hook ที่ดูปลอดภัยอาจกลายเป็นอันตรายได้หลังจากอัปเกรดแล้ว ซึ่งก่อให้เกิดความเสี่ยงอย่างมาก ความเสี่ยงเหล่านี้ได้แก่:
- ตัวแทนที่สามารถอัพเกรดได้ (สามารถโจมตีได้โดยตรง);
- ด้วยตรรกะการทำลายตนเอง การโจมตีที่เป็นไปได้ในกรณีที่มีการเรียกร้องให้ร่วมกันทำลายตนเองและสร้าง2
2.2.3 มาตรการป้องกันภัยคุกคามรูปแบบ II
การประเมินว่าฮุคนั้นเป็นอันตรายเป็นสิ่งสำคัญหรือไม่ โดยเฉพาะสำหรับ hooks ที่มีการจัดการ เราควรมุ่งเน้นไปที่พฤติกรรมของการจัดการต้นทุน ในขณะที่สำหรับ hooks อิสระ จุดสนใจหลักคือสามารถอัปเกรดได้หรือไม่
3.บทสรุป
การประเมินว่าฮุคนั้นเป็นอันตรายเป็นสิ่งสำคัญหรือไม่ โดยเฉพาะสำหรับ hooks ที่มีการจัดการ เราควรมุ่งเน้นไปที่พฤติกรรมของการจัดการต้นทุน ในขณะที่สำหรับ hooks อิสระ จุดสนใจหลักคือสามารถอัปเกรดได้หรือไม่
3.บทสรุป
ในบทความนี้ เราจะให้ภาพรวมโดยย่อเกี่ยวกับกลไกหลักที่เกี่ยวข้องกับปัญหาความปลอดภัยของ Hook ของ Uniswap v4 ต่อจากนั้น เราจะเสนอโมเดลภัยคุกคาม 2 รูปแบบและสรุปคร่าวๆ เกี่ยวกับความเสี่ยงด้านความปลอดภัยที่เกี่ยวข้อง
ในบทความต่อๆ ไป เราจะทำการวิเคราะห์เชิงลึกเกี่ยวกับปัญหาด้านความปลอดภัยภายใต้โมเดลภัยคุกคามแต่ละแบบ
ความคิดเห็นทั้งหมด