---
title: "ลายเซ็นมอบสิทธิ์กำกับดูแลปลอดภัยหรือไม่"
description: "เรียนรู้ว่าลายเซ็นมอบสิทธิ์กำกับดูแลอนุญาตอะไร การแยกโดเมนตาม EIP-712, nonce และวันหมดอายุช่วยลดความเสี่ยงจากการนำลายเซ็นกลับมาใช้ซ้ำอย่างไร และควรตรวจสอบอะไรก่อนลงนาม"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ลายเซ็นมอบสิทธิ์กำกับดูแลปลอดภัยหรือไม่

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

<a id="answer"></a>

## คำตอบโดยตรง

ลายเซ็นมอบสิทธิ์กำกับดูแลจะปลอดภัยก็ต่อเมื่อข้อความที่ถอดรหัสแล้วตรงกับการมอบสิทธิ์ที่คุณตั้งใจไว้ทุกประการ และสัญญากำกับดูแลบังคับใช้การป้องกันการนำลายเซ็นกลับมาใช้ซ้ำอย่างเพียงพอ ในการออกแบบโทเค็นลงคะแนนโดยทั่วไป การมอบสิทธิ์จะเปลี่ยนผู้ที่สามารถใช้พลังเสียงของผู้ลงนาม แต่ **ไม่ได้** โอนยอดคงเหลือของโทเค็นหรือให้สิทธิ์ใช้จ่ายโทเค็น อย่างไรก็ตาม สัญญาที่นำขึ้นใช้งานจริงเป็นตัวชี้ขาดว่าลายเซ็นนั้นทำอะไร

ลายเซ็นที่สร้างนอกเชนสามารถส่งโดยผู้ถ่ายทอดธุรกรรมได้ ผู้ลงนามจึงอาจไม่ต้องจ่ายค่า gas แต่ยังคงอนุญาตให้เปลี่ยนสถานะบนเชนได้ ให้ถือว่าลายเซ็นเป็นคำสั่งที่นำไปดำเนินการได้ ไม่ใช่การเข้าสู่ระบบหรือคำขอเชื่อมต่อกระเป๋าที่ไม่มีอันตราย

<a id="mechanism"></a>

## วิธีการทำงาน

กระบวนการ `delegateBySig` ที่ใช้กันทั่วไปมีสี่ขั้นตอน:

1. แอปพลิเคชันเตรียมข้อมูลแบบมีชนิดตาม EIP-712 ซึ่งประกอบด้วยที่อยู่ของผู้รับมอบสิทธิ์, nonce และวันหมดอายุ
2. กระเป๋าลงนาม digest ที่ผูกกับข้อความแบบมีชนิดและโดเมน EIP-712
3. บัญชีใดก็ได้สามารถถ่ายทอดลายเซ็นไปยังสัญญาโทเค็นหรือสัญญากำกับดูแล
4. สัญญากู้คืนหรือตรวจสอบผู้ลงนาม ตรวจ nonce และวันหมดอายุ แล้วบันทึกผู้รับมอบสิทธิ์รายใหม่

โดเมน EIP-712 สามารถมี `name`, `version`, `chainId` และ `verifyingContract` ได้ ฟิลด์เหล่านี้แยกข้อความที่เหมือนกันในด้านอื่นออกจากกันตามแอปพลิเคชัน เวอร์ชัน เครือข่าย และสัญญา ตัว EIP-712 เองระบุไว้อย่างชัดเจนว่า **ไม่ได้** ให้การป้องกันการนำลายเซ็นกลับมาใช้ซ้ำ สัญญาต้องใช้ nonce ไปแล้วหรือทำให้การอนุญาตแต่ละครั้งใช้ได้เพียงครั้งเดียวด้วยวิธีอื่น ส่วนวันหมดอายุจะจำกัดช่วงเวลาได้ก็ต่อเมื่อสัญญาตรวจสอบค่านั้นจริง

ก่อนลงนาม ให้ตรวจสอบรายการทั้งหมดต่อไปนี้กับอินเทอร์เฟซกำกับดูแลอย่างเป็นทางการ เอกสารประกอบ หรือข้อมูลสัญญาที่ตรวจสอบอย่างเป็นอิสระแล้ว:

- `primaryType` และชื่อฟิลด์ต้องอธิบายการมอบสิทธิ์ ไม่ใช่ permit, การโอนโทเค็น, คำสั่งซื้อขาย หรือการอนุญาตจัดการบัญชี
- `verifyingContract` ต้องเป็นสัญญาโทเค็นหรือสัญญากำกับดูแลที่ต้องการบน `chainId` ที่กำลังใช้งาน
- `delegatee` ต้องเป็นที่อยู่ของตัวแทนที่คุณเลือก โดยตรวจสอบที่อยู่เต็มแทนการเชื่อชื่อที่แสดง
- `nonce` ต้องตรงกับ nonce ปัจจุบันของผู้ลงนามในสัญญา และ `expiry` ควรสั้นพอสำหรับขั้นตอนที่ต้องการ
- กระเป๋าควรแสดงข้อมูลแบบมีชนิดทั้งหมด ปฏิเสธคำขอลงนามแบบไม่เห็นข้อมูลหรือค่าแฮชดิบที่คุณไม่สามารถตรวจสอบความหมายซ้ำได้อย่างอิสระ

แต่ละระบบนำไปใช้ต่างกัน ตัวอย่างเช่น สัญญา COMP ของ Compound แฮชผู้รับมอบสิทธิ์, nonce และวันหมดอายุ กำหนดให้ nonce ตรงกับค่าที่เก็บไว้ของผู้ลงนาม เพิ่มค่า nonce นั้น และปฏิเสธลายเซ็นที่หมดอายุแล้ว อินเทอร์เฟซ `Votes` ของ OpenZeppelin ก็มี `delegateBySig` การจัดการ nonce และการตรวจวันหมดอายุเช่นกัน อย่าคิดว่าฟังก์ชันชื่อคล้ายกันในสัญญาอื่นจะมีมาตรการป้องกันเหมือนกัน

<a id="example"></a>

## ตัวอย่าง

มีราตั้งใจมอบ 10,000 คะแนนเสียงให้ที่อยู่ `0xAB...1234` กระเป๋าของเธอแสดง `primaryType: Delegation`, สัญญาโทเค็นลงคะแนนที่ตรวจสอบแล้ว, ID ของเชนที่ใช้งานอยู่, `delegatee: 0xAB...1234`, nonce ปัจจุบัน และวันหมดอายุในอีก 20 นาที หลังตรวจสอบที่อยู่กับแหล่งที่เชื่อถือได้อีกแห่ง เธอลงนาม ผู้ถ่ายทอดส่งข้อความนั้น และสัญญาปล่อย event การมอบสิทธิ์ ยอดโทเค็นของเธอยังคงอยู่ในกระเป๋า ส่วนตัวแทนได้รับพลังเสียงที่เกี่ยวข้องตามกฎของโปรโตคอลนั้น

คราวนี้เปลี่ยนรายละเอียดหนึ่งอย่าง: หน้าเว็บขอ `primaryType: Permit` และระบุผู้ที่มีสิทธิ์ใช้จ่ายโทเค็น หรือ `verifyingContract` เป็นสัญญาที่ไม่เกี่ยวข้อง นี่ไม่ใช่คำสั่งมอบสิทธิ์เดียวกัน แต่อาจอนุญาตให้ใช้จ่ายโทเค็นแทน แม้ปุ่มบนหน้าเว็บจะเขียนว่า "มอบสิทธิ์" และผู้ลงนามไม่ต้องจ่ายค่า gas มีราค็ควรปฏิเสธคำขอนี้

<a id="risks"></a>

## ความเสี่ยงและมาตรการควบคุม

- **ผู้รับมอบสิทธิ์ผิดคน:** การวางยาพิษที่อยู่ ข้อความส่วนตัว และชื่อที่แสดงซึ่งถูกคัดลอกอาจแทนที่ `delegatee` ด้วยที่อยู่ที่ผู้โจมตีควบคุม ตรวจสอบที่อยู่เต็มผ่านข้อเสนออย่างเป็นทางการหรือโปรไฟล์ของผู้รับมอบสิทธิ์
- **การกระทำผิดประเภท:** อินเทอร์เฟซที่เป็นอันตรายอาจขอ EIP-712 ประเภทอื่น เช่น permit อ่าน `primaryType` ทุกฟิลด์ และสัญญาที่ใช้ตรวจสอบ เพราะข้อความบนปุ่มไม่มีคุณค่าด้านความปลอดภัย
- **การนำกลับมาใช้ซ้ำ:** การตรวจ nonce ที่อ่อนแอหรือไม่มีเลยอาจทำให้ใช้ลายเซ็นซ้ำได้ โดเมนที่ไม่ผูกกับเชนหรือสัญญาที่ต้องการอาจเปิดให้ใช้ในบริบทที่ไม่ได้ตั้งใจด้วย ตรวจสอบโค้ดการยืนยันจริง เพราะ EIP-712 เพียงอย่างเดียวไม่ใช่การป้องกันการนำกลับมาใช้ซ้ำ
- **ลายเซ็นที่มีอายุยาว:** ข้อความที่ลงนามแล้วแต่ยังไม่ได้ใช้อาจยังนำไปดำเนินการได้จนกว่าจะหมดอายุหรือ nonce ใช้ไม่ได้ เลือกวันหมดอายุสั้น อย่าเผยแพร่ลายเซ็น และใช้เฉพาะวิธียกเลิกที่โปรโตคอลบันทึกไว้หากจำเป็นต้องยกเลิก
- **การแสดงผลของกระเป๋าที่ทำให้เข้าใจผิด:** ฟิลด์ที่ถูกตัด โดเมนที่ไม่รู้จัก หรือการลงนามแบบไม่เห็นข้อมูล ทำให้ไม่สามารถให้ความยินยอมอย่างมีความหมายได้ ให้ยกเลิกและตรวจคำขอข้อมูลแบบมีชนิดด้วยกระเป๋าหรือตัวถอดรหัสที่แสดงข้อความทั้งหมด
- **ความแตกต่างของบัญชีสัญญา:** กระเป๋าสมาร์ตคอนแทรกต์อาจตรวจสอบลายเซ็นผ่าน ERC-1271 ซึ่งความถูกต้องอาจขึ้นกับสถานะกระเป๋าและนโยบายการอนุญาต ยืนยันว่าทั้งกระเป๋าและสัญญากำกับดูแลรองรับ แทนการสมมติว่าจะกู้คืนลายเซ็นแบบ EOA ได้
- **ผลต่อการกำกับดูแล:** การมอบสิทธิ์อาจรวมศูนย์พลังเสียงหรือทำให้ผู้รับมอบสิทธิ์ที่ไม่น่าเชื่อถือออกเสียงขัดต่อผลประโยชน์ของคุณ ตรวจสอบตัวตน ประวัติการลงคะแนน ผลประโยชน์ทับซ้อน และกระบวนการมอบสิทธิ์ใหม่ของโปรโตคอล

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

หากคุณลงนามแล้วแต่ยังไม่เห็นการส่ง ให้หยุดแชร์ลายเซ็นและตรวจวิธียกเลิกหรือทำให้ nonce ใช้ไม่ได้ตามเอกสารของโปรโตคอล หากมีการมอบสิทธิ์ที่ไม่ต้องการเกิดขึ้นแล้ว ให้มอบสิทธิ์ใหม่ผ่านสัญญาอย่างเป็นทางการและตรวจสอบสถานะใหม่ โดยปกติการมอบสิทธิ์เพียงอย่างเดียวไม่ได้สร้าง allowance ของโทเค็น จึงอย่าสับสนระหว่างการมอบสิทธิ์ใหม่กับการเพิกถอนการอนุมัติ หากคุณลงนาม permit ด้วย หรือเปิดเผย seed phrase หรือ private key ให้ถือว่าเป็นเหตุการณ์ด้านกระเป๋าอีกกรณีหนึ่งที่ร้ายแรงกว่า

<a id="misconceptions"></a>

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

- **"ไม่เสีย gas หมายถึงไม่ได้ให้อำนาจ"** ผู้ถ่ายทอดสามารถจ่ายค่า gas ขณะที่ลายเซ็นยังให้อำนาจของผู้ลงนามได้
- **"EIP-712 ทำให้ทุกลายเซ็นปลอดภัย"** มาตรฐานนี้กำหนดรูปแบบการแฮชข้อมูลแบบมีชนิดและการแยกโดเมน แต่ไม่ได้รวมการป้องกันการนำกลับมาใช้ซ้ำ และไม่สามารถยืนยันว่าผู้ใช้ตั้งใจทำสิ่งที่แสดงจริง
- **"การมอบสิทธิ์โอนโทเค็นของฉัน"** การมอบสิทธิ์ลงคะแนนแบบทั่วไปย้ายหรือกำหนดพลังเสียง ไม่ใช่กรรมสิทธิ์ในโทเค็น แต่มีเพียงสัญญาที่นำขึ้นใช้งานจริงและข้อความที่ถอดรหัสแล้วเท่านั้นที่ยืนยันผลที่แท้จริงได้
- **"ฉันเพิกถอนลายเซ็นนอกเชนได้เสมอ"** ไม่มีธุรกรรมเพิกถอนลายเซ็นแบบสากล วันหมดอายุ การใช้หรือทำให้ nonce ใช้ไม่ได้ และการมอบสิทธิ์ใหม่เป็นกลไกเฉพาะของแต่ละสัญญา
- **"การเปลี่ยนผู้รับมอบสิทธิ์ลบคะแนนเสียงก่อนหน้า"** การมอบสิทธิ์ใหม่เปลี่ยนพลังเสียงในปัจจุบันหรืออนาคตตามกฎของโปรโตคอล แต่อาจไม่ยกเลิกคะแนนที่ลงไปแล้วหรือเปลี่ยน snapshot ในอดีต

<a id="related"></a>

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

- [ลายเซ็นแบบมีโครงสร้าง EIP-712](/th/crypto/eip712-typed-signature/)
- [DAO](/th/crypto/dao/)
- [การโจมตีระบบกำกับดูแล](/th/crypto/governance-attack/)
- [การอนุญาตของกระเป๋า](/th/crypto/wallet-approval/)
- [ลายเซ็นของกระเป๋า](/th/crypto/wallet-signature/)

<a id="sources"></a>

## แหล่งข้อมูล

- [EIP-712: การแฮชและลงนามข้อมูลแบบมีชนิดและมีโครงสร้าง](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-20)
- [Comp.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/Comp.sol) - Compound Finance (เข้าถึงเมื่อ: 2026-08-20)
- [API การกำกับดูแล](https://docs.openzeppelin.com/contracts/5.x/api/governance) - OpenZeppelin (เข้าถึงเมื่อ: 2026-08-20)
- [ERC-1271: วิธีมาตรฐานสำหรับตรวจสอบลายเซ็นของสัญญา](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-20)

Source: https://wiki.fcontext.com/th/crypto/governance-delegation-signature-risk/index.mdx