---
title: "ลายเซ็นข้อมูลแบบมีชนิด EIP-712: โดเมน ไดเจสต์ และการตรวจสอบอย่างปลอดภัย"
description: "EIP-712 ทำให้ข้อความแบบมีโครงสร้างของ Ethereum มีการเข้ารหัสที่แน่นอนและแสดงผลได้ แต่การลงนามอย่างปลอดภัยยังต้องตรวจสอบโดเมน ชนิด ค่า 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.

# ลายเซ็นข้อมูลแบบมีชนิด EIP-712: โดเมน ไดเจสต์ และการตรวจสอบอย่างปลอดภัย

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

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

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

EIP-712 กำหนดวิธีมาตรฐานที่แอป Ethereum ใช้อธิบาย ทำแฮช และขอลายเซ็นสำหรับข้อมูลแบบมีโครงสร้างและมีชนิด คำขอประกอบด้วย `types` `primaryType` `domain` และ `message` ส่วนไดเจสต์คือ `keccak256("\x19\x01" || domainSeparator || hashStruct(message))` การเข้ารหัสจึงให้ผลแน่นอน และกระเป๋าที่รองรับสามารถแสดงแต่ละฟิลด์ได้ชัดกว่าแฮชที่อ่านความหมายไม่ได้

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

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

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

### 1. ระบุการกระทำและเส้นทางตรวจสอบ

พิจารณาว่าคำขอให้อำนาจเข้าสู่ระบบ ตั้งคำสั่ง โหวต ให้ allowance แก่โทเคน โอนสินทรัพย์ เรียกผ่าน relayer หรือทำอย่างอื่น จากนั้นหาคอดที่สร้างไดเจสต์ใหม่และใช้ลายเซ็น สำหรับบัญชีที่ควบคุมด้วยกุญแจภายนอก มักกู้ที่อยู่จากลายเซ็น ECDSA ส่วนบัญชีสัญญาอาจต้องเรียก ERC-1271 `isValidSignature(hash, signature)` และตรวจค่าความสำเร็จ `0x1626ba7e`

### 2. ตรึงโดเมน

ตรวจชนิด `EIP712Domain` และค่าที่แท้จริง ฟิลด์มาตรฐานคือ `name` `version` `chainId` `verifyingContract` และ `salt` แต่มีเพียงฟิลด์ที่ใส่ไว้เท่านั้นที่ถูกแฮช ยืนยันเครือข่ายที่ใช้งาน คอดที่เผยแพร่ และสัญญาตรวจสอบจากแหล่งอิสระ ชื่อ สัญลักษณ์ ป้าย proxy หรือที่อยู่แบบ checksum ที่คุ้นเคยยังไม่เพียงพอ ERC-5267 `eip712Domain()` อาจเปิดเผยโดเมนได้ แต่การรองรับไม่บังคับและยังต้องตรวจพฤติกรรม proxy กับการอัปเกรด

### 3. สร้างกราฟชนิดข้อมูลใหม่

เริ่มจาก `primaryType` รักษาลำดับสมาชิก และรวบรวม struct ที่อ้างถึงแบบเวียนซ้ำ `encodeType` จะต่อท้ายคำจำกัดความเหล่านั้นโดยเรียงตามชื่อชนิด EIP-712 รองรับจำนวนเต็มความกว้างคงที่ `address` `bool` ตั้งแต่ `bytes1` ถึง `bytes32` รวมถึง `bytes` และ `string` แบบไดนามิก array และ struct แต่มาตรฐานไม่ได้กำหนดชื่อย่อ `uint` กับ `int` ชนิดเลขจุดคงที่ หรือค่าแบบวนรอบ

### 4. ถอดความทุกค่าและหน่วย

จับคู่ทุกค่ากับชนิดที่ประกาศและความหมายในแอป ตรวจที่อยู่เต็ม หน่วยจำนวนเต็มดิบ เครื่องหมาย ลำดับ array ผู้รับ spender สินทรัพย์ จำนวน ค่าธรรมเนียม ขีดจำกัด ปลายทาง แฮช calldata และข้อความที่อ่านได้ ค่า `bytes` และ `string` แบบไดนามิกแสดงใน `encodeData` ด้วยแฮช Keccak-256 ของเนื้อหา ส่วน array ใช้แฮชของการเข้ารหัสสมาชิกที่ต่อกัน และ struct ซ้อนใช้ `hashStruct` ของตนเอง

### 5. คำนวณไดเจสต์ใหม่อย่างอิสระ

คำนวณ `typeHash = keccak256(encodeType(primaryType))` แล้วคำนวณ `hashStruct(message) = keccak256(typeHash || encodeData(message))` คำนวณตัวคั่นโดเมนด้วยวิธีเดียวกันและรวมกับไบต์เวอร์ชัน ERC-191 `0x19 0x01` เปรียบเทียบผลจากหน้าแอป ไลบรารีลงนาม สัญญาตรวจสอบ และการคำนวณอิสระ JSON ที่ดูเหมือนกันไม่ได้พิสูจน์ว่าการเข้ารหัสแบบมีชนิดเหมือนกัน

### 6. ตรวจการใช้ซ้ำ เวลา และการดำเนินการ

EIP-712 ไม่มีการป้องกัน replay ในตัว ต้องยืนยันว่าสัญญาตรวจผู้ลงนามที่ตั้งใจ ใช้หรือยกเลิก nonce ที่ถูกต้อง บังคับ `deadline` หรือช่วงอายุ ผูกพารามิเตอร์สำคัญทั้งหมด และยังให้ผลตามเจตนาเมื่อ relayer หรือผู้แซงส่งก่อน การแยกโดเมนป้องกันการชนกันเฉพาะโดเมนที่เข้ารหัสจริง ฟิลด์ที่หายหรือผิดอาจเปิดทางให้นำลายเซ็นไปใช้ข้ามสัญญาหรือเครือข่าย

### 7. ลงนามเท่าที่จำเป็นและกระทบยอดผล

ปฏิเสธฟิลด์ซ่อน ชนิดที่อธิบายไม่ได้ ค่าไม่จำกัด กำหนดเวลาที่ไกล สัญญาไม่รู้จัก chain ID ไม่ตรง หน้าจอ blind signing หรือบริบทการดำเนินการไม่ครบ เก็บ JSON แบบมีชนิดและไดเจสต์ที่ตรงทั้งหมด ใช้บัญชีจำกัดวัตถุประสงค์เมื่อทำได้ แล้วตรวจธุรกรรม ใบรับเหตุการณ์ ยอดคงเหลือ allowance nonce สถานะคำสั่ง และ finality การตัดการเชื่อมต่อเว็บไซต์ไม่เพิกถอนลายเซ็นที่ยังใช้ได้หรืออำนาจที่สร้างแล้ว

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

## ตัวอย่างการคำนวณ

### ตัวอย่าง 1: การสร้างชนิดและไดเจสต์

สำหรับ `Order(address maker,address token,uint256 amount,uint256 nonce,uint256 deadline)` ค่า `typeHash` คือแฮช Keccak-256 ของสตริงนี้ทุกตัวรวมลำดับฟิลด์ แฮชข้อความคือ `keccak256(typeHash || maker || token || amount || nonce || deadline)` และสมาชิกที่เข้ารหัสแต่ละตัวใช้ 32 ไบต์ ไดเจสต์สุดท้ายเพิ่ม `0x1901` ตัวคั่นโดเมน และแฮชข้อความ การเปลี่ยน `amount` จาก `250000000` เป็น `250000001` เปลี่ยนไดเจสต์และทำให้ลายเซ็นเดิมใช้ไม่ได้

### ตัวอย่าง 2: หน่วยและกำหนดเวลา

จำนวน `250 USDC` ของโทเคนทศนิยมหกตำแหน่งต้องเข้ารหัสเป็นค่าดิบ `250000000` ไม่ใช่ `250` หากเวลาปัจจุบันคือ `1727000000` และกำหนดหมดอายุคือ `1727000900` ช่วงเวลาคือ `900 seconds = 15 minutes` การแสดงทศนิยมของกระเป๋าและนาฬิกาเครื่องเป็นเพียงตัวช่วย สัญญาตรวจสอบใช้จำนวนเต็มดิบและกฎเวลา on-chain ที่กำหนด

### ตัวอย่าง 3: การควบคุม replay

คำสั่งมี nonce `41` และวงเงินสูงสุด `5 ETH` เมื่อสัญญาทำเครื่องหมาย nonce 41 ว่าใช้แล้ว การส่งครั้งที่สองต้องล้มเหลวแม้ลายเซ็นยังถูกต้องทางคณิตศาสตร์ หากสัญญาไม่ใช้ nonce และการทำซ้ำให้ผลเพิ่ม การใช้ลายเซ็นเดิมอาจอนุมัติ `5 ETH` อีกครั้ง ตัวคั่นโดเมนเพียงอย่างเดียวไม่ป้องกัน replay นี้

### ตัวอย่าง 4: ความถูกต้องของกระเป๋าสัญญา

กระเป๋าสัญญาแบบ 2-of-3 อนุมัติไดเจสต์ขณะที่ตั้งผู้ลงนาม A B และ C ลายเซ็นของ A กับ B อาจทำให้ ERC-1271 คืน `0x1626ba7e` ในวันนี้ หากอัปเกรดโมดูลแล้วแทน B ด้วย D ไบต์ลายเซ็นเดิมอาจใช้ไม่ได้ เพราะความถูกต้องของ ERC-1271 ขึ้นกับสถานะ นโยบาย เวลา และการเรียกภายนอกปัจจุบันได้ การกู้ที่อยู่เพียงอย่างเดียวจึงตัดสินบัญชีสัญญาไม่ได้

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

## ความเสี่ยง

- `chainId` ผิดหรือขาดหาย
- `verifyingContract` ปลอมหรือไม่ใช่สัญญาที่คาด
- `name` หรือ `version` ของโดเมนทำให้เข้าใจผิด
- implementation ของ proxy หรือโดเมนเปลี่ยนหลังอัปเกรด
- `primaryType` ผิดหรือชนิดซ่อนที่มีป้ายคล้ายกัน
- ลำดับสมาชิก ลำดับ dependency หรือ encoder ไม่ตรงกัน
- ที่อยู่ถูกย่อ เปลี่ยน หรือใส่ป้ายหลอก
- ทศนิยมโทเคนหรือจำนวนเต็มมีเครื่องหมายผิด
- สมาชิก array, struct ซ้อน หรือ payload `bytes` ถูกซ่อน
- จำนวนไม่จำกัด ขอบเขตกว้าง หรือผู้รับที่ผู้โจมตีควบคุม
- nonce หาย เก่า ใช้ร่วม หรือถูกใช้ผิดวิธี
- กำหนดเวลาหาย ไกล overflow หรือแปลความกำกวม
- replay ข้ามเครือข่าย สัญญา บัญชี หรือการกระทำ
- relayer กัก เซ็นเซอร์ แซงหน้า หรือเปลี่ยนเส้นทาง
- ลายเซ็นเปลี่ยนรูปได้หรือการกู้ ECDSA ผ่อนปรนเกินไป
- ผู้ลงนาม โมดูล threshold สถานะ หรือคอด ERC-1271 เปลี่ยน
- การแสดงผลกระเป๋า blind signing หรือชนิดไม่รองรับล้มเหลว
- JSON หน้าแอปต่างจากไดเจสต์ของสัญญาตรวจสอบ
- การเพิกถอนหรือยกเลิกแพ้การแข่งขันลำดับธุรกรรม
- เข้าใจผลหน้าลงนามผิดเป็นใบรับ การเปลี่ยนสถานะ หรือ finality

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

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

### ความเข้าใจผิด 1: ลายเซ็น EIP-712 คือธุรกรรม

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

### ความเข้าใจผิด 2: การแสดงแบบมีโครงสร้างหมายความว่าคำขอปลอดภัย

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

### ความเข้าใจผิด 3: ตัวคั่นโดเมนป้องกัน replay ทุกแบบ

ตัวคั่นแยกเฉพาะโดเมนที่เข้ารหัส replay ภายในโดเมนเดิมยังต้องใช้ nonce กำหนดเวลา การยกเลิก การบันทึก fill หรือ idempotence และฟิลด์โดเมนที่ไม่ได้ใส่ไม่สร้างขอบเขตใด

### ความเข้าใจผิด 4: กู้ที่อยู่ที่คาดได้ก็พิสูจน์อำนาจแล้ว

การกู้พิสูจน์เพียงลายเซ็นของ EOA เหนือไดเจสต์ ไม่ได้ตรวจความหมายของแอป บัญชีสัญญาต้องใช้กฎ ERC-1271 ของตนแทนการกู้ที่อยู่ทั่วไป

### ความเข้าใจผิด 5: ปิดหน้าหรือตัดการเชื่อมต่อกระเป๋าจะยกเลิกลายเซ็น

ลายเซ็นที่ถูกคัดลอกยังใช้ได้จนกว่า nonce กำหนดเวลา การยกเลิก สถานะ หรือนโยบายของสัญญาตรวจสอบจะทำให้ใช้ไม่ได้ ต้องตรวจสถานะ on-chain ที่เกี่ยวข้อง ไม่ใช่สถานะเซสชัน

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

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

- [Chain ID](/th/crypto/chain-id/)
- [Nonce และกำหนดเวลาของ ERC-2612 Permit](/th/crypto/erc2612-permit-nonce-deadline/)
- [ความเสี่ยงของลายเซ็น Permit2](/th/crypto/permit2-signature-risk/)
- [การอนุมัติจากกระเป๋า](/th/crypto/wallet-approval/)
- [ลายเซ็นกระเป๋า](/th/crypto/wallet-signature/)

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

## แหล่งอ้างอิง

- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-19)
- [ERC-191: Signed Data Standard](https://eips.ethereum.org/EIPS/eip-191) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-19)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-19)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-19)
- [ERC-5267: Retrieval of EIP-712 domain](https://eips.ethereum.org/EIPS/eip-5267) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-19)
- [EIP-2: Homestead Hard-fork Changes](https://eips.ethereum.org/EIPS/eip-2) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-19)
- [Contract ABI Specification](https://docs.soliditylang.org/en/latest/abi-spec.html) - Solidity Documentation (เข้าถึงเมื่อ: 2026-08-19)
- [ERC-7730: Structured Data Clear Signing Format](https://eips.ethereum.org/EIPS/eip-7730) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-19)

Source: https://wiki.fcontext.com/th/crypto/eip712-typed-signature/index.mdx