ความเสี่ยงของลายเซ็น Permit2

Permit2 แยกวงเงินที่ใช้ซ้ำได้ออกจากการโอนด้วยลายเซ็นแบบใช้ครั้งเดียว การลงนามอย่างปลอดภัยต้องตรวจสอบ deployment, domain, spender, ผู้รับ, จำนวน, nonce, เส้นตาย, witness และ calldata สำหรับการดำเนินการอย่างแม่นยำ

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

คำตอบโดยตรง

Permit2 รวมระบบการอนุญาตที่ต่างกันสองแบบ AllowanceTransfer จัดเก็บวงเงินที่ใช้ซ้ำได้สำหรับเจ้าของ-โทเค็น-spender พร้อมจำนวน เวลาหมดอายุ และ nonce แบบเรียงลำดับ ส่วน SignatureTransfer ใช้วงเงินสูงสุดที่ลงนามไว้เพียงครั้งเดียวด้วย nonce ใน bitmap แบบไม่เรียงลำดับ และไม่สร้างวงเงิน downstream แบบถาวร ทั้งสองระบบยังต้องอาศัย allowance ของ ERC-20 ที่เจ้าของโทเค็นให้แก่ Permit2

ลายเซ็นที่ผู้ลงนามไม่จ่าย gas สามารถเคลื่อนย้ายสินทรัพย์ได้เมื่อ spender หรือ relayer จ่ายค่าดำเนินการ ตรวจสอบ chain ที่แน่นอน โค้ด Permit2 ที่ deployment แล้ว domain ของ EIP-712 โมดูล โทเค็น spender วงเงินสูงสุดที่ลงนาม calldata ของผู้รับ nonce และเวลาแต่ละชนิด สัญญา Permit2 ที่ถูกต้องไม่ได้ทำให้ spender ผู้รับ router หรือ witness ที่เป็นอันตรายปลอดภัยขึ้น

Chain ID และสัญญาการตรวจสอบตรงกับแอปพลิเคชันที่ต้องการฟังก์ชัน, ผู้ใช้จ่าย, โทเค็น, จำนวน, nonce และกำหนดเวลาได้รับการถอดรหัสมีการตรวจสอบค่าเผื่อที่มีอยู่และความหมายทดแทนมีการจำลองการเปลี่ยนแปลงยอดคงเหลือและการอนุมัติการโทร ผู้รับมอบสิทธิ์ หรือการโอนค่าที่ไม่คาดคิดทำให้เกิดการปฏิเสธ

0 / 5

0 ตรวจสอบรายการแล้ว; 5 รายการยังไม่ได้รับการแก้ไข

การเสร็จสิ้นการตรวจสอบนี้ไม่ได้พิสูจน์ว่าสินทรัพย์ ธุรกรรม หรือระบบมีความปลอดภัย

กลไกการทำงาน

ระบุ chainId เครือข่าย verifyingContract ของ Permit2 runtime code ที่ deployment แล้ว ที่อยู่และ decimals ของโทเค็น ประเภท wallet ของเจ้าของ และแอปพลิเคชันที่ต้องการ ใช้ข้อมูล deployment อย่างเป็นทางการ ที่อยู่หรือป้ายชื่อที่คุ้นเคยเพียงอย่างเดียวไม่เพียงพอ
อ่าน allowance ของ ERC-20 ชั้น upstream จากเจ้าของไปยัง Permit2 และยอดคงเหลือ ระบุว่า approval มีขอบเขตหรือไม่จำกัด และตรวจพฤติกรรมการโอนเฉพาะของโทเค็น ledger นี้ยังคงอยู่หลังลายเซ็น Permit2 หรือวงเงิน downstream ที่จัดเก็บไว้หมดอายุ
ระบุเส้นทางและ primary type ที่ลงนามอย่างแม่นยำ ได้แก่ PermitSingle หรือ PermitBatch ของ AllowanceTransfer หรือ PermitTransferFrom รวมถึงรูปแบบ batch และ witness ของ SignatureTransfer อย่าถือว่า transferFrom เป็น signed type
ถอดรหัส domain ของ EIP-712 และทุกรายการในข้อความ สำหรับ AllowanceTransfer ให้ตรวจโทเค็น uint160 amount, expiration, nonce แบบเรียงลำดับ, spender และ sigDeadline สำหรับ SignatureTransfer ให้ตรวจโทเค็นและจำนวนที่อนุญาต nonce แบบไม่เรียงลำดับ deadline และ spender ที่ผูกจากบริบทของผู้เรียก
ถอดรหัส calldata สำหรับการดำเนินการแยกต่างหาก ใน SignatureTransfer พื้นฐาน SignatureTransferDetails.to และ requestedAmount เป็นพารามิเตอร์การดำเนินการ ไม่ใช่ field ใน permit พื้นฐานที่ลงนามไว้ จำนวนที่ขอเพียงต้องไม่เกินวงเงินสูงสุดที่ลงนาม ตรวจทุกดัชนีของ batch ตลอดจน hash และ type string ของ witness ให้ตรงทุกอักขระ
สอบถาม nonce ของวงเงินแบบเรียงลำดับในปัจจุบัน หรือ word และ bit ของ bitmap แบบไม่เรียงลำดับ จากนั้นจำลองผู้เรียก calldata chain และ state ที่ตรงกัน กระทบยอดผู้รับ การกระทำของ router คุณลักษณะโทเค็น ยอดคงเหลือ และ ledger วงเงินทั้งสอง การจำลองอาจเปลี่ยนตาม state การจัดลำดับ หรือการ reorganize
จำกัดจำนวนและอายุให้น้อยที่สุด หากน่าสงสัย ให้เก็บ typed data ไว้และส่งธุรกรรมถอน approval upstream ถอนวงเงิน downstream หรือทำ nonce invalidation ที่ถูกต้องผ่านช่องทางที่เชื่อถือได้ โดยถือว่าเป็นการแข่งขันใน mempool รอการยืนยันแล้วกระทบยอดการโอน ยอดคงเหลือ วงเงิน และ bit ใน bitmap

ใน AllowanceTransfer ค่า sigDeadline จำกัดเวลาที่ permit ซึ่งลงนามแล้วใช้สร้างหรือปรับปรุงอำนาจที่จัดเก็บได้ ส่วน expiration จำกัดระยะเวลาที่อำนาจนั้นใช้จ่ายได้ Deadline ของ SignatureTransfer จำกัดการดำเนินการครั้งเดียว EIP-712 ให้การ hash แบบมีชนิดและการแยก domain ไม่ได้ให้การป้องกัน replay หรือความปลอดภัยของเจตนา ขอบเขตเหล่านี้มาจากกฎ nonce และ deadline ของ Permit2

สำหรับ wallet แบบสัญญา ความถูกต้องของ ERC-1271 ขึ้นอยู่กับนโยบาย isValidSignature โมดูล threshold และโค้ดของ wallet ในขณะนั้น ป้ายชื่อ wallet หน้าจอ hardware wallet ที่แสดงไม่ครบ และการจำลองที่สำเร็จเป็นเพียงข้อมูลประกอบ ไม่ใช่การรับประกัน การตัดการเชื่อมต่อ frontend ไม่ได้ถอน approval หรือลายเซ็นใด

ตัวอย่าง

ledger วงเงินสองชั้น วงเงินโทเค็นแบบจำกัดที่ให้แก่ Permit2 เริ่มต้นที่ 1,000 USDC และ PermitSingle จัดเก็บ 600 USDC ให้ spender S หลัง S โอน 225 USDC จำนวนที่จัดเก็บเหลือ 600 - 225 = 375 USDC ขณะที่วงเงิน upstream มาตรฐานแบบจำกัดเหลือ 1,000 - 225 = 775 USDC การหมดอายุหรือถอน 375 ไม่ได้ล้าง 775 โดยอัตโนมัติ โทเค็นที่ไม่เป็นมาตรฐานอาจต่างออกไป
ผู้รับและจำนวนแบบใช้ครั้งเดียว SignatureTransfer ลงนามวงเงินสูงสุด 250 USDC และ calldata ขอ 180 USDC ให้ร้านค้า หากยอดคงเหลือและวงเงิน upstream เพียงพอ การดำเนินการโอน 180 ได้ nonce จะถูกใช้ ทำให้ 70 USDC ที่เหลือนำกลับมาใช้ไม่ได้ หาก calldata ระบุผู้โจมตีเป็นผู้รับ permit พื้นฐานเพียงอย่างเดียวไม่ขัดขวางการเปลี่ยนปลายทางโดย spender ที่ผูกไว้
bitmap ของ nonce แบบไม่เรียงลำดับ สำหรับ nonce 513 จะได้ wordPos = 513 >> 8 = 2, bitPos = 513 & 255 = 1 และ mask = 1 << 1 = 2 การดำเนินการตั้ง bit 1 ของ word 2 การใช้ 513 ซ้ำจะล้มเหลว ส่วน nonce 512 ที่ bit 0 ยังคงเป็นอิสระ
การแข่งขันในการถอนสิทธิ วงเงินที่จัดเก็บคือ 400 USDC เจ้าของเผยแพร่ธุรกรรมถอนเป็นศูนย์ แต่การโอน 300 USDC ดำเนินการก่อน ทำให้เหลือ 100 USDC จากนั้นธุรกรรมถอนที่ตามมาตั้งส่วนที่เหลือเป็น 0 วงเงินสุดท้ายที่เป็นศูนย์ไม่ได้ย้อนคืนความเสียหาย 300 USDC ที่เกิดขึ้นแล้ว จึงต้องกระทบยอดลำดับธุรกรรมและยอดคงเหลือ

ความเสี่ยง

chain ID, deployment หรือ runtime code ไม่ถูกต้อง
verifying contract ปลอมหรือไม่ตรงความคาดหมาย
สับสนระหว่าง AllowanceTransfer กับ SignatureTransfer
spender หรือผู้เรียกเป็นอันตรายหรือระบุผิด
ผู้รับถูกเลือกผ่าน calldata สำหรับการดำเนินการ
จำนวนที่ขอใกล้วงเงินสูงสุดที่ลงนาม
ที่อยู่ สัญลักษณ์ decimals หรือหน่วยดิบของโทเค็นผิด
approval ERC-20 upstream แบบถาวรหรือไม่จำกัด
จำนวน downstream หรือ expiration มากเกินไป
สับสนระหว่าง deadline, sigDeadline และ expiration
nonce แบบเรียงลำดับล้าสมัยหรือถูกรบกวนด้วยการแข่งขัน
ใช้ bit ใน bitmap ซ้ำหรือ mask สำหรับ invalidation กว้างเกินไป
hash ของ witness หรือ type string ที่แน่นอนไม่ตรงกัน
รายการ batch ถูกซ่อน ซ้ำ หรือจัดดัชนีผิด
การแสดงผล frontend หรือ calldata ต่างจากเจตนา
ธุรกรรมถอนสิทธิแพ้การแข่งขันใน mempool หรือ MEV
โมดูล ผู้ลงนาม threshold หรือ upgrade ของ ERC-1271 เปลี่ยน
โทเค็นแบบ fee-on-transfer, rebasing, paused, blocked หรือ callback
state ของการจำลองเปลี่ยน การจำลองล้มเหลว หรือเกิดการ reorganize
เข้าใจผิดว่าการยืนยันจาก hardware wallet หรือการตัดการเชื่อมต่อคือความปลอดภัย

ความเข้าใจผิดที่พบบ่อย

ลายเซ็นที่ไม่แสดงคำขอ gas ไม่สามารถย้ายโทเค็นได้ บุคคลอื่นสามารถจ่าย gas สำหรับการดำเนินการ
ที่อยู่ Permit2 อย่างเป็นทางการพิสูจน์ว่า spender และผู้รับปลอดภัย Permit2 สามารถดำเนินการตามอำนาจที่เป็นอันตรายได้อย่างถูกต้อง
SignatureTransfer และ AllowanceTransfer สร้างสิทธิถาวรแบบเดียวกัน แบบแรกใช้ครั้งเดียว ส่วนแบบหลังจัดเก็บวงเงินที่ใช้ซ้ำได้
การตัดการเชื่อมต่อหรือถอนสิทธิชั้นหนึ่งยกเลิกทุกเส้นทางและลายเซ็นที่รอดำเนินการ state ของ upstream, downstream และ nonce แยกกัน และยังมีการแข่งขันอยู่
EIP-712, hardware wallet หรือการจำลองที่สำเร็จพิสูจน์เจตนาและ finality แต่ละอย่างช่วยให้มองเห็นหรือทดสอบได้ดีขึ้น แต่ไม่แทนที่การตรวจ field, calldata และ state ที่ยืนยันแล้ว

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

แหล่งข้อมูล

Overview - Uniswap Developers (เข้าถึงเมื่อ: 2026-08-13)
Allowance Transfer - Uniswap Developers (เข้าถึงเมื่อ: 2026-08-13)
Signature Transfer - Uniswap Developers (เข้าถึงเมื่อ: 2026-08-13)
Deployments - Uniswap Developers (เข้าถึงเมื่อ: 2026-08-13)
PermitHash.sol - Uniswap Permit2 (เข้าถึงเมื่อ: 2026-08-13)
EIP-712: Typed structured data hashing and signing - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-13)
ERC-1271: Standard Signature Validation Method for Contracts - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-13)
ERC-20: Token Standard - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-13)