เพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำหรือคำชี้ชวนด้านการลงทุน การลงทุนอาจทำให้เกิดการขาดทุน
คำตอบโดยตรง
ก่อนลงนามในสวอปบน DEX ให้ตรวจสอบเครือข่าย สัญญาปลายทาง ฟังก์ชันที่ถอดรหัสแล้ว ที่อยู่โทเคน ขอบเขตอินพุตหรือเอาต์พุต เส้นทาง ผู้รับ และกำหนดเวลาทั้งหมด เปอร์เซ็นต์ที่ส่วนติดต่อแสดงว่าเป็น “slippage” ไม่ใช่คำสั่งบนเชนโดยตัวมันเอง โดยทั่วไปจะใช้คำนวณขอบเขต เช่น amountOutMin หรือ amountOutMinimum สำหรับสวอป exact-input หรือ amountInMax หรือ amountInMaximum สำหรับ exact-output
กำหนดเวลาเป็นข้อจำกัดด้านเวลา ไม่ใช่การรับประกันราคา หากเราเตอร์ตรวจสอบกำหนดเวลาและธุรกรรมทำงานหลังเวลานั้น คำสั่งควร revert แต่ก่อนถึงกำหนด ธุรกรรมยังทำงานที่ราคาใดก็ได้ซึ่งขอบเขตจำนวนอนุญาต กำหนดเวลาที่ยาวทำให้การอนุญาตใช้ได้นานขึ้น ส่วนเวลาที่สั้นเกินไปเพิ่มโอกาสหมดอายุก่อนถูกรวมในบล็อก
Calldata ไม่ได้อธิบายตัวเอง ต้องถอดรหัสด้วย ABI ที่ตรวจสอบแล้วของสัญญาที่ถูกต้องบนเครือข่ายที่เลือก รวมถึง multicall หรือคำสั่ง Universal Router ที่ซ้อนอยู่ หากกระเป๋าเงินไม่แสดงฟิลด์ที่ถอดรหัสอย่างน่าเชื่อถือ อย่าคาดเดาความหมายจากตำแหน่งไบต์หรือฐานข้อมูลชื่อฟังก์ชันเพียงอย่างเดียว
กลไกการทำงาน
ถอดรหัสคำสั่งจริง
ตาม ABI ของ Solidity 4 bytes แรกของ calldata คือ function selector และอาร์กิวเมนต์ที่เข้ารหัสเริ่มจากไบต์ที่ห้า Selector อาจชนกันหรือถูกติดป้ายผิด จึงต้องเทียบกับ ABI ของสัญญาปลายทางที่ตรวจสอบแล้ว พร็อกซี ตัวรวบรวม หรือเราเตอร์อาจห่อสวอปไว้ใน multicall, execute หรือฟังก์ชันอื่น ให้ถอดรหัส payload ที่ซ้อนทุกส่วนซึ่งสามารถโอนโทเคนหรือเปลี่ยนผู้รับสุดท้ายได้
ในสวอป exact-input อินพุตจะคงที่และฟิลด์ป้องกันกำหนดเอาต์พุตขั้นต่ำที่ยอมรับได้ ใน exact-output เอาต์พุตที่ต้องการจะคงที่และฟิลด์ป้องกันจำกัดอินพุต ขอบเขตเป็นศูนย์หรือกว้างผิดคาดอาจทำให้ไม่มีการป้องกันราคาที่มีความหมาย จำนวนทศนิยมของโทเคนสำคัญ: จับคู่ที่อยู่โทเคนแต่ละรายการกับจำนวนทศนิยมและสัญลักษณ์ที่ถูกต้องก่อนเปรียบเทียบจำนวนเต็มดิบ
ตรวจสอบเส้นทาง ผู้รับ และ value
ยืนยันว่าเส้นทางเริ่มด้วยโทเคนที่ใช้จ่ายและจบด้วยโทเคนที่คาดว่าจะได้รับ ตรวจสอบโทเคนตัวกลาง ค่าธรรมเนียมพูล และคำสั่งที่ห่อ แกะห่อ กวาด หรือโอนยอดคงเหลือ ผู้รับควรเป็นกระเป๋าเงินที่ตั้งใจไว้หรือสัญญาที่เข้าใจพฤติกรรมแล้ว ตรวจสอบ value ดั้งเดิมของธุรกรรมด้วย เพราะอาจแยกจากจำนวน ERC-20 ที่เข้ารหัสใน calldata
ค้นหากำหนดเวลา
ตำแหน่งกำหนดเวลาขึ้นอยู่กับรุ่นของเราเตอร์ ฟังก์ชันเราเตอร์แบบ Uniswap V2 มีอาร์กิวเมนต์ deadline และโครงสร้าง ISwapRouter ดั้งเดิมของ Uniswap V3 ก็มีเช่นกัน Universal Router มีทั้ง execute(commands, inputs, deadline) และ overload ที่ไม่มีกำหนดเวลา ดังนั้นอย่าสันนิษฐานว่าทุกสวอปมีกำหนดเวลา หรือกำหนดเวลาอยู่ในพารามิเตอร์สวอปที่ซ้อนแบบเดียวกันเสมอ
โดยทั่วไปกำหนดเวลาจะถูกเทียบกับ timestamp ของบล็อกที่ใช้ขณะทำงาน มันไม่ยกเลิกธุรกรรมที่รออยู่ ไม่รับประกันการรวมอย่างรวดเร็ว และไม่ป้องกันราคาที่เสียเปรียบซึ่งยังอยู่ในขอบเขตจำนวน หากต้องการยกเลิก ผู้ส่งต้องใช้กลไกแทนที่ธุรกรรมของเครือข่ายและกระเป๋าเงิน และไม่รับประกันการแทนที่หลังธุรกรรมเดิมถูกรวมแล้ว
ตัวอย่างโดยละเอียด
ราคาประเมินคาดว่าจะได้รับ 10,000 USDC จากสวอป exact-input และผู้ใช้เลือก slippage 1% หากไม่นับค่าธรรมเนียมที่รวมในราคาแล้ว เอาต์พุตขั้นต่ำที่คาดหวังคือ 9,900 USDC เนื่องจาก USDC ใช้ 6 decimals จำนวนเต็มดิบของขอบเขตนี้คือ 9900000000
แต่คำสั่งที่ถอดรหัสมี amountOutMinimum = 9000000000 หรือ 9,000 USDC ซึ่งอนุญาตให้ได้น้อยกว่าราคาประเมินถึง 10% ไม่ใช่ 1% ผู้รับยังเป็นที่อยู่ที่ไม่คุ้นเคย และกำหนดเวลาอยู่ห่างออกไปหลายชั่วโมง ความไม่ตรงกันเพียงข้อใดข้อหนึ่งก็เพียงพอให้ปฏิเสธคำขอและสร้างใหม่ผ่านส่วนติดต่อที่เชื่อถือได้ หลังสร้างใหม่ ให้จำลองธุรกรรมที่ยังไม่ลงนามรายการเดียวกันกับสถานะล่าสุด และตรวจ payload ที่ถอดรหัสอีกครั้งก่อนลงนาม
รายการตรวจสอบและความเสี่ยง
- เทียบเครือข่ายที่เลือกและที่อยู่เราเตอร์หรือพร็อกซีกับบันทึกการติดตั้งอย่างเป็นทางการของโปรโตคอล
- ถอดรหัสด้วย ABI ของสัญญาที่ตรวจสอบแล้ว เปิดคำสั่งซ้อนและคำสั่งเราเตอร์แทนการตรวจเฉพาะฟังก์ชันชั้นนอก
- เทียบที่อยู่โทเคน ทิศทาง ทศนิยม จำนวนคงที่ ขอบเขตป้องกัน เส้นทาง ระดับค่าธรรมเนียม ผู้รับ และ
valueดั้งเดิม - แปลงกำหนดเวลาเป็นเวลาที่แน่นอนและตัดสินว่าช่วงเวลาที่เหลือเป็นไปตามเจตนาหรือไม่ ให้ถือว่าการไม่มีกำหนดเวลาเป็นตัวเลือกการออกแบบที่ต้องตรวจแยก
- จำลองธุรกรรมเดียวกันจากที่อยู่ผู้ลงนามเทียบกับสถานะล่าสุด การจำลองสำเร็จเป็นหลักฐานเฉพาะสถานะนั้น ไม่ใช่การรับประกันการรวมหรือผลสุดท้าย
- ตรวจการอนุมัติหรือสิทธิ์ Permit2 แยกต่างหาก ขอบเขตสวอปที่ดีไม่ได้ทำให้การอนุญาตโทเคนแบบไม่จำกัดหรือประสงค์ร้ายปลอดภัย
- ขอบเขตแคบอาจ revert จากการเคลื่อนไหวราคาปกติ ส่วนขอบเขตกว้างเพิ่มความเสี่ยงด้านราคาดำเนินการและการโจมตี sandwich ธุรกรรมบนเชนที่ revert แล้วยังอาจใช้ gas
ความเข้าใจผิดที่พบบ่อย
ความเชื่อผิด: เปอร์เซ็นต์ slippage ที่แสดงคือสิ่งที่ลงนาม
โดยทั่วไป payload ที่ลงนามมีขอบเขตจำนวนซึ่งคำนวณจากการตั้งค่านั้น ตรวจสอบจำนวนเต็มจริงและทศนิยมของโทเคน ป้ายในส่วนติดต่อที่ดูถูกต้องไม่ได้พิสูจน์ว่า calldata ใช้ค่าความคลาดเคลื่อนเดียวกัน
ความเชื่อผิด: ทุกสวอปใช้ amountOutMin และ deadline
ชื่อและตำแหน่งต่างกันตามเราเตอร์และฟังก์ชัน สวอป exact-output ป้องกันด้านอินพุต และจุดเข้าใช้งานบางแบบไม่มีกำหนดเวลาหรือวางไว้ในคำสั่งชั้นนอก
ความเชื่อผิด: กำหนดเวลาป้องกันราคาที่ไม่ดี
มันจำกัดเวลาให้ทำงานได้ก็ต่อเมื่อโค้ดที่เรียกบังคับใช้ การป้องกันราคามาจากขอบเขตจำนวน ซึ่งยังอนุญาตการทำงานทุกแบบภายในขอบเขตนั้น
ความเชื่อผิด: ถอดรหัสฟังก์ชันชั้นนอกก็เพียงพอ
ตัวรวบรวมและ universal router อาจมีหลายคำสั่ง สิทธิ์โทเคน การโอน และคำสั่งเก็บกวาด ผู้รับหรือจำนวนที่สำคัญต่อความปลอดภัยอาจอยู่ใน payload ที่ซ้อน
หัวข้อที่เกี่ยวข้อง
- ถอดรหัส calldata ในกระเป๋าเงิน
- รายการตรวจสอบ slippage และเส้นทาง DEX
- การโจมตี sandwich
- Slippage ในการซื้อขายคริปโต
- การจำลองธุรกรรม
แหล่งข้อมูล
- Contract ABI Specification - Solidity Documentation (เข้าถึงเมื่อ: 2026-08-21)
- IUniswapV2Router01.sol - Uniswap (เข้าถึงเมื่อ: 2026-08-21)
- ISwapRouter.sol - Uniswap (เข้าถึงเมื่อ: 2026-08-21)
- Universal Router Commands - Uniswap (เข้าถึงเมื่อ: 2026-08-21)