0x ปะทะ Uniswap อย่างเปิดเผย: Hook v4 กว่าครึ่งถูกติดธงว่าอันตราย ใครควรเป็นผู้รับผิดชอบต่อความเปิดกว้าง?

ผู้เขียนต้นฉบับ: เสี่ยวปิ่ง

DEX Aggregator 0x ได้ทิ้งระเบิดข้อมูลเมื่อวันที่ 14 กันยายน: ทีมงานได้วิเคราะห์ Uniswap v4 Hook จำนวน 84,163 รายการบน 6 เชน โดยข้อมูล ณ วันที่ 11 กันยายนสรุปได้ว่า มีเพียง 19.4% ของ Hook ที่ถูกตัดสินว่าปลอดภัย 54.2% เป็นอันตราย และ 26.4% เป็นที่น่าสงสัยว่าเป็นอันตราย

Hayden Adams ผู้ก่อตั้ง Uniswap ได้ตอบกลับบน X ในเวลาต่อมา โดยจุดยืนหลักคือ: การมีอยู่ของ Hook ที่เป็นอันตรายนั้นเป็นผลพลอยได้ที่หลีกเลี่ยงไม่ได้ของระบบที่ไม่ต้องขออนุญาต แต่ผู้ใช้ที่ทำธุรกรรมผ่าน API อย่างเป็นทางการของ Uniswap และ frontend ที่ผ่านการตรวจสอบจะไม่เข้าถึงพูลที่เป็นอันตรายเหล่านี้ ปัญหาอยู่ที่ความสามารถในการกรองเส้นทางของ aggregator ไม่ใช่การออกแบบสถาปัตยกรรมของ v4

การ débate เกี่ยวกับ "ราคาที่ต้องจ่าย" ของ "ความเปิดกว้าง" ใน DeFi จึงปะทุขึ้นต่อสาธารณะระหว่างสองโปรโตคอลชั้นนำเช่นนี้

ข้อกล่าวหาของ 0x: การหลอกลวงราคาเสนอ

รูปแบบการโจมตีที่ 0x อธิบายนั้นมีความเฉพาะเจาะจงมาก: Hook ที่เป็นอันตรายจะแสดงราคาเสนอที่แข่งขันได้สูงในช่วงที่ aggregator สอบถามราคา เพื่อดึงดูดให้ routing engine นำธุรกรรมไปยังพูลของตัวเอง แต่เมื่อทำธุรกรรมจริง Hook จะ篡แก้ไขพารามิเตอร์การกำหนดราคาหรือ注入อัตราค่าธรรมเนียมที่เป็นการลงโทษ ทำให้ผู้ใช้ได้รับสินทรัพย์จริงต่ำกว่าราคาเสนออย่างมาก

0x นิยามการโจมตีนี้ว่า "การหลอกลวงราคาเสนอ" (Quote Spoofing) วิธีการทางเทคนิคที่ใช้ ได้แก่: การตรวจจับสภาพแวดล้อมการทำงานของ EVM (แยกแยะระหว่างการเรียกจำลองและการทำธุรกรรมจริง โดยจะลงมือเฉพาะในช่วงธุรกรรมจริง), การสลับพารามิเตอร์แบบสุ่ม (ทำให้ระบบตรวจจับยากที่จะจำลองพฤติกรรมอันตรายได้อย่างเสถียร) และการเรียกเก็บค่าธรรมเนียมแอบแฝงสูงถึง 18% บนคู่การซื้อขายที่มีสภาพคล่องสูง

ในกรณีที่รุนแรงที่สุด ผู้ใช้ได้รับสินทรัพย์จริงน้อยกว่าราคาเสนอถึง 50% 0x ระบุว่า Hook ที่เป็นอันตรายเหล่านี้ได้สกัดทรัพย์สินหลายแสนดอลลาร์จากผู้ใช้ที่ตั้งค่า slippage tolerance ไว้หลวม

ข้อมูลของ 0x เองแสดงว่า ตั้งแต่ปี 2026 เป็นต้นมา แพลตฟอร์มได้ส่งต่อธุรกรรม 81.92 ล้านรายการ คิดเป็นมูลค่าการซื้อขาย 42.67 พันล้านดอลลาร์ โดยประมาณ 70% เกี่ยวข้องกับสภาพคล่องของ Uniswap ในฐานะหนึ่งในช่องทางจัดจำหน่ายภายนอกที่ใหญ่ที่สุดของสภาพคล่อง Uniswap นั้น 0x มีแรงจูงใจทาง商業โดยตรงในการแก้ปัญหานี้ เพราะ Hook ที่เป็นอันตรายสร้างความเสียหายต่อประสบการณ์การซื้อขายของผู้ใช้ 0x ซึ่งส่งผลกระทบต่อชื่อเสียงและปริมาณธุรกรรมของ 0x เอง

การตอบกลับของ Hayden Adams

ตรรกะการตอบโต้ของ Adams สามารถสรุปได้เป็นสามชั้น:

ใครก็สามารถสร้างสัญญาที่เป็นอันตรายบน Ethereum ได้ นี่ไม่ใช่ปัญหาที่มีเฉพาะใน v4 โทเค็น ERC-20 ที่เป็นอันตราย สัญญา honeypot พูล Rug Pull มีอยู่มากมายในยุค v2 และ v3 อยู่แล้ว Hook เพียงแต่ทำให้พฤติกรรมอันตรายมี载体ทางเทคนิคใหม่ สาระสำคัญของการโจมตีไม่ได้เปลี่ยนแปลง ยังคงเป็นการใช้ประโยชน์จากความไว้วางใจโดยปริยายของผู้ใช้ต่อความปลอดภัยของสินทรัพย์บนเชน

Frontend และ API อย่างเป็นทางการของ Uniswap เชื่อมต่อเฉพาะ Hook ที่ผ่านการตรวจสอบแล้ว Niko (@saintniko สมาชิกทีมผลิตภัณฑ์ของ Uniswap) ระบุอย่างชัดเจนในเวลาเดียวกันว่า ผู้ใช้ที่ทำธุรกรรมผ่าน API อย่างเป็นทางการของ Uniswap จะเข้าถึงเฉพาะ Hook ที่ผ่านการตรวจสอบแล้ว จุดยืนของ Uniswap ชัดเจน: ชั้นโปรโตคอลเปิดกว้าง แต่ชั้นแอปพลิเคชันได้ทำการกรองแล้ว

Aggregator ต้องรับผิดชอบต่อการตัดสินใจด้าน routing ของตัวเอง หาก routing engine ของ 0x เชื่อมต่อ Hook ที่ไม่ผ่านการตรวจสอบกว่า 80,000 รายการโดยไม่มีการแบ่งแยก นั่นก็เป็นข้อบกพร่องในการควบคุมความเสี่ยงของ aggregator เอง เช่นเดียวกับที่ตลาดหลักทรัพย์ใด ๆ จะไม่รับผิดชอบต่อการฉ้อโกงนอกตลาด โปรโตคอล Uniswap ไม่ควรรับผิดชอบต่อความผิดพลาดด้าน routing ของ aggregator บุคคลที่สาม

ข้อมูลของ 0x นั้นน่าตกใจเพียงพอ แต่จำเป็นต้องพิจารณาหลายมิติ:

84,163 Hook คือจำนวนรวมที่ "ถูกวิเคราะห์" ไม่ใช่จำนวนที่ "ถูกผู้ใช้โต้ตอบ" ตัวเลขนี้รวม Hook ซอมบี้จำนวนมากที่ไม่เคยมีธุรกรรมจริง พวกมันถูก deploy แต่บางทีอาจไม่เคยถูก route ไปถึงเลย เช่นเดียวกับการนับสัญญาทั้งหมดที่เคย deploy บน Ethereum ซึ่งกว่า 90% อาจไม่เคยถูกเรียกใช้เลย แต่ก็ยังถูกนับรวมในฐานจำนวน

แก่นแท้ที่แท้จริงของการถกเถียง

เมื่อปอกเปลือกรายละเอียดทางเทคนิคและสงครามน้ำลายออก ความขัดแย้งระหว่าง 0x และ Uniswap ชี้ไปที่ปัญหาเก่าแก่ของ DeFi: ความเปิดกว้างของระบบที่ไม่ต้องขออนุญาต (permissionless system) ย่อมมาพร้อมกับการเข้าสู่ระบบของผู้ประสงค์ร้ายอย่างหลีกเลี่ยงไม่ได้

ระบบ Hook ของ v4 เป็นการก้าวกระโดดเชิงสถาปัตยกรรมที่ใหญ่ที่สุดในประวัติศาสตร์ของ Uniswap ตรรกะของพูลใน v2 และ v3 นั้นตายตัว พฤติกรรมของพูลทั้งหมดถูกกำหนดโดยโค้ดของโปรโตคอลอย่างสมบูรณ์ v4 เปิดพฤติกรรมของพูลให้กับนักพัฒนา ใครก็สามารถเขียนตรรกะที่กำหนดเองได้ และรันโค้ดใด ๆ ก่อนและหลังการทำธุรกรรม สิ่งนี้นำมาซึ่งนวัตกรรมเช่น StablePair Hook (ค่าธรรมเนียมแบบไดนามิก), DualPool Hook (ผลตอบแทนจากเงินทุนที่ไม่ได้ใช้งาน), Permissioned Pools (การตรวจสอบความสอดคล้อง) และย่อมเปิดประตูสู่การใช้ประโยชน์ในทางที่ผิดอย่างหลีกเลี่ยงไม่ได้

ตรรกะของ Uniswap คือ: คุณค่าที่สร้างโดยความเปิดกว้างนั้นยิ่งใหญ่กว่าความสูญเสียที่เกิดจากพฤติกรรมอันตรายมาก การกรองความปลอดภัยควรทำในชั้นแอปพลิเคชัน (frontend, API, aggregator) ไม่ใช่การจำกัดนวัตกรรมในชั้นโปรโตคอล

ซึ่งสอดคล้องกับปรัชญาการออกแบบของ Ethereum เอง Ethereum จะไม่阻止คุณจากการ deploy สัญญาที่เป็นอันตราย แต่กระเป๋าเงินและ frontend จะกรองพวกมัน

ตรรกะของ 0x คือ: เมื่อ Hook มากกว่าครึ่งเป็นอันตราย ภาระการกรองในชั้นแอปพลิเคชันก็ใหญ่เกินไปอย่างไม่สมเหตุสมผล อย่างน้อยชั้นโปรโตคอลควรมีเครื่องมือที่ดีกว่าเพื่อช่วยให้ downstream ระบุและแยกแยะ Hook ที่เป็นอันตรายได้ 0x ระบุว่าตัวเองได้阻止พูลที่เป็นอันตรายจากการเข้าสู่ routing ผ่านเทคโนโลยีการตรวจจับและการตรวจสอบพูลเงินแล้ว แต่ต้นทุนของสงครามอาวุธนี้สูงขึ้นเรื่อย ๆ

ผลกระทบที่แท้จริงต่อผู้ใช้

หากคุณทำธุรกรรมผ่าน frontend อย่างเป็นทางการของ Uniswap (app.uniswap.org) ความเสี่ยงที่จะได้รับผลกระทบจาก Hook ที่เป็นอันตรายนั้นต่ำมาก เพราะ Uniswap อ้างว่า API ของตนเชื่อมต่อเฉพาะ Hook ที่ผ่านการตรวจสอบแล้ว

หากคุณทำธุรกรรมผ่าน aggregator บุคคลที่สาม (0x, 1inch, Paraswap ฯลฯ) ความเสี่ยงขึ้นอยู่กับความสามารถในการกรอง Hook ของ aggregator เหล่านั้น 0x อ้างว่าตัวเองได้สร้างกลไกการตรวจจับและ阻止แล้ว ส่วน aggregator อื่น ๆ มีระดับการป้องกันที่แตกต่างกัน

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

หลักการป้องกันตัวเองง่าย ๆ: ตรวจสอบว่า frontend การทำธุรกรรมของคุณมีกลไกการกรอง v4 Hook หรือไม่ หากคุณไม่แน่ใจ ให้ยึดการใช้ frontend อย่างเป็นทางการของ Uniswap ตั้งค่า slippage tolerance ให้เหมาะสม รายงานของ 0x แสดงว่า Hook ที่เป็นอันตรายมุ่งเป้าไปที่ผู้ใช้ที่ตั้งค่า slippage ไว้หลวมเป็นหลัก