---
title: "ลายเซ็นกระเป๋าสินทรัพย์ดิจิทัล"
description: "ลายเซ็นกระเป๋าพิสูจน์ว่าคีย์หรือบัญชีสัญญาอนุมัติข้อมูลที่แน่นอนภายใต้กฎตรวจสอบที่กำหนด เรียนรู้ความต่างของข้อความ ธุรกรรม permit การใช้ซ้ำ และฟิชชิง"
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>

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

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

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

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

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

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

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

ERC-191 แยกข้อมูลที่ลงลายเซ็นออกจากการเข้ารหัสธุรกรรม Ethereum ทั่วไป และกำหนดรูปแบบรวมถึง `personal_sign` EIP-712 ผูกฟิลด์ที่มีโครงสร้างกับโดเมนซึ่งอาจมี `name`, `version`, `chainId` และ `verifyingContract` ข้อความเข้าสู่ระบบ ERC-4361 เพิ่มโดเมน URI, ID เชน, nonce และเวลาออก แต่บริการยังต้องตรวจสอบข้อมูลเหล่านี้เอง

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

## ตัวอย่าง

Leah เข้าใช้บริการทางการและได้รับคำขอเข้าสู่ระบบ ERC-4361 ที่มีโดเมนกับ URI ตรงตามคาด nonce ใหม่ และช่วงเวลาสั้น ข้อความขอเพียงการยืนยันตัวตน หลังตรวจโดเมนและบัญชี เธอเซ็น เซิร์ฟเวอร์ตรวจสอบและสร้างเซสชัน ข้อความนี้เองไม่ได้สร้าง allowance ของโทเคนหรือธุรกรรม on-chain

บนเว็บเลียนแบบ ปุ่มยังเขียนว่า “เข้าสู่ระบบ” แต่กระเป๋าแสดงข้อมูล EIP-712 `Permit` ที่มีโทเคน spender จำนวน nonce และ deadline ลายเซ็นอาจให้ relayer สร้างสิทธิ์ใช้จ่ายตามกฎสัญญา Leah ควรปฏิเสธ เพราะข้อความบนปุ่มไม่เปลี่ยนไบต์ที่เซ็น

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

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

- **ความหมายหลอกลวง:** เว็บอาจเรียก permit หรือคำสั่งว่าเข้าสู่ระบบ เชื่อ payload ที่ถอดรหัสและสัญญาที่ตรวจสอบแล้ว ไม่ใช่ปุ่ม
- **การเซ็นแบบมองไม่เห็น:** hash ดิบและไบต์ทึบทำให้ตรวจอย่างเข้าใจไม่ได้ ยกเลิกหากสร้างข้อความที่แน่นอนและเส้นทางทำงานซ้ำด้วยเครื่องมือที่เชื่อถือไม่ได้
- **โดเมนผิด:** ชื่อแบรนด์คุ้นตาไม่ได้ยืนยัน `chainId`, `verifyingContract`, โดเมนเว็บ หรือ URI ตรวจทุกฟิลด์และที่อยู่เต็มแยกต่างหาก
- **Replay หรือการทำงานล่าช้า:** ผู้ที่ได้ลายเซ็นอาจใช้ได้จน nonce ถูกใช้หรือ deadline หมด ใช้ nonce ใหม่ กำหนดเวลาสั้น และอย่าเผยแพร่ลายเซ็น
- **สิทธิ์กว้าง:** permit คำสั่ง คีย์เซสชัน และการทำงานของบัญชีอัจฉริยะอาจอนุญาตสิ่งต่อไปโดยไม่ถามกระเป๋าอีก ตรวจสินทรัพย์ spender ผู้รับ จำนวน ขอบเขต และวิธียกเลิก
- **ผู้ลงลายเซ็นถูกเจาะ:** กระเป๋าฮาร์ดแวร์ป้องกันการดึงคีย์ แต่ทำให้ข้อความอันตรายปลอดภัยไม่ได้ หาก seed phrase หรือคีย์ส่วนตัวรั่ว ให้ถือว่าทั้งบัญชีถูกเจาะ

หากเซ็นคำขอน่าสงสัย ให้เก็บ payload ที่ถอดรหัสและลายเซ็นไว้โดยไม่เผยแพร่ ตัดการเชื่อมต่อเว็บ และระบุรูปแบบลายเซ็น สำหรับ approval หรือธุรกรรม on-chain ให้ตรวจสถานะบนเชนที่ถูกต้องและใช้การเพิกถอน การทำให้ nonce ใช้ไม่ได้ หรือย้ายสินทรัพย์ตามเอกสาร ไม่มีวิธีสากลในการเพิกถอนลายเซ็น off-chain ทุกแบบ และการตัดเว็บไม่ทำให้ลายเซ็นหมดผล

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

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

- **“ทุกลายเซ็นย้ายเงิน”** หลายลายเซ็นใช้ยืนยันตัวตนหรือแสดงเจตนาเท่านั้น แต่บางแบบอนุญาตการย้ายเงินภายหลัง
- **“ไม่มี gas จึงปลอดภัย”** relayer จ่าย gas และส่ง permit คำสั่ง หรือสิทธิ์อื่นที่ลงลายเซ็นแล้วได้
- **“EIP-712 รับประกันความปลอดภัย”** มาตรฐานช่วยการแสดงผลและแยกโดเมน แต่ไม่ป้องกัน replay หรือตรวจคำกล่าวของแอป
- **“ที่อยู่ที่กู้คืนพิสูจน์ความยินยอมโดยเข้าใจ”** มันเชื่อมข้อมูลที่แน่นอนกับคีย์ตามกฎ ไม่ได้พิสูจน์ตัวตน ความเข้าใจ หรือเจตนาเสรี
- **“ลายเซ็นกระเป๋าสัญญาเหมือนบัญชีทั่วไป”** ความถูกต้องตาม ERC-1271 อาจขึ้นกับสถานะและนโยบายปัจจุบัน ผู้ตรวจสอบต้องเรียกสัญญา

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

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

- [ลายเซ็นแบบมีชนิด EIP-712](/th/crypto/eip712-typed-signature/)
- [การอนุมัติกระเป๋า](/th/crypto/wallet-approval/)
- [ความเสี่ยงลายเซ็น Permit2](/th/crypto/permit2-signature-risk/)
- [การจำลองธุรกรรม](/th/crypto/transaction-simulation/)
- [กลโกงฟิชชิง](/th/crypto/phishing-scam/)

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

## แหล่งที่มา

- [ERC-191: Signed Data Standard](https://eips.ethereum.org/EIPS/eip-191) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-22)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-22)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-22)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-22)
- [ERC-4361: Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-22)

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