ข้ามไปยังเนื้อหา

กำหนดเวลา Slippage และ calldata ของสวอป: สิ่งที่ต้องตรวจสอบก่อนลงนาม

เรียนรู้วิธีถอดรหัสคำสั่งสวอปบน DEX และตรวจสอบเราเตอร์ ฟังก์ชัน ขอบเขตจำนวน เส้นทาง ผู้รับ และกำหนดเวลาก่อนลงนาม

อัปเดต

เพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำหรือคำชี้ชวนด้านการลงทุน การลงทุนอาจทำให้เกิดการขาดทุน

คำตอบโดยตรง

ก่อนลงนามในสวอปบน 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 ที่ซ้อน

หัวข้อที่เกี่ยวข้อง

แหล่งข้อมูล

การนำทาง

ค้นหาในวิกิ...