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

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

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

“กุญแจเซสชัน” เป็นรูปแบบการออกแบบ ไม่ใช่มาตรฐาน Ethereum ที่เป็นหนึ่งเดียว ERC-4337 รองรับการตรวจสอบบัญชีแบบตั้งโปรแกรมได้และการตรวจสอบ `UserOperation` ที่มีกรอบเวลา ส่วนระบบบัญชีแบบโมดูล เช่น ERC-7579 สามารถรองรับตัวตรวจสอบ ตัวดำเนินการ และ hook ได้ สุดท้ายแล้วโค้ดบัญชีและโมดูลที่ติดตั้งเป็นผู้กำหนดว่ากุญแจทำอะไรได้บ้าง การหมดอายุเพียงอย่างเดียวไม่ได้ทำให้เซสชันปลอดภัย และการลบสำเนาออกจากเบราว์เซอร์อาจไม่ได้เพิกถอนอำนาจที่ลงทะเบียนบนเชนหรืออยู่ในหนังสือมอบหมายที่ยังไม่หมดอายุ

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

## วิธีทำงาน

ขั้นตอนทั่วไปมี 5 ระยะ:

1. เจ้าของสร้างคู่กุญแจใหม่บนอุปกรณ์ หรืออนุมัติข้อมูลรับรองที่ระบุผู้ลงนามของเซสชัน ไม่ควรส่งกุญแจส่วนตัวของเซสชันไปยังเซิร์ฟเวอร์ของแอป เว้นแต่การออกแบบระบุชัดว่าเซิร์ฟเวอร์นั้นเป็นผู้รับฝากที่เชื่อถือได้
2. เจ้าของอนุมัตินโยบายด้วยกระเป๋าเงินหลัก บางระบบติดตั้งกุญแจและนโยบายบนเชน ส่วนระบบอื่นใช้หนังสือมอบหมายที่ลงนามแล้ว ซึ่งบัญชีจะตรวจสอบเมื่อมีรายการเข้ามา
3. แอปสร้างรายการและลงนามด้วยกุญแจเซสชัน ในขั้นตอน ERC-4337 ตรรกะ `validateUserOp` ของบัญชีจะตรวจลายเซ็นและนโยบาย การจำลองของ bundler เป็นเพียงการตรวจรับรายการ ไม่ใช่หลักฐานว่ารายการจะดำเนินการสำเร็จหรือปลอดภัย
4. บัญชีต้องบังคับใช้ข้อจำกัดทั้งหมดก่อนดำเนินการ อำนาจที่มีผลจริงสรุปได้เป็น `A_effective = K ∩ P ∩ S`: การครอบครองกุญแจ (`K`) นโยบายที่ตั้งไว้ (`P`) และสถานะปัจจุบันของบัญชีหรือเชน (`S`) ต้องอนุญาตรายการพร้อมกัน
5. เซสชันสิ้นสุดเมื่อหมดอายุ nonce หรือโควตาหมด มีการเพิกถอนโดยชัดแจ้ง ถอดโมดูล หรือใช้เส้นทางทำให้ใช้ไม่ได้แบบอื่นที่ขึ้นกับการนำไปใช้ ตรวจสอบสถานะสุดท้ายของบัญชีบนเชนที่ถูกต้อง

ก่อนอนุมัติเซสชัน ให้ตรวจสอบ:

- ID ของเชน ที่อยู่บัญชีอัจฉริยะ การนำบัญชีไปใช้ และที่อยู่ตัวตรวจสอบหรือโมดูล
- กุญแจสาธารณะของเซสชันหรือตัวระบุข้อมูลรับรอง และสถานที่เก็บข้อมูลส่วนตัว
- ปลายทาง ตัวเลือกฟังก์ชัน โทเค็น และกฎผู้รับที่อนุญาตทั้งหมด รวมถึงขีดจำกัดมูลค่าสินทรัพย์ดั้งเดิมและเพดานต่อครั้งหรือสะสม
- `validAfter`, `validUntil` กฎ nonce จำนวนครั้งที่ใช้ และเวลาวัดจากเวลาประทับของบล็อกหรือแหล่งอื่น
- batch การเรียกซ้อน `delegatecall` การอนุมัติโทเค็น การติดตั้งโมดูล การอัปเกรดบัญชี และลายเซ็นข้อความ ERC-1271 ถูกบล็อกหรือไม่ หากไม่ได้จำเป็นอย่างชัดเจน
- ใครเพิกถอนเซสชันได้ เจ้าของยังมีเส้นทางกู้คืนอิสระหรือไม่ และการเพิกถอนต้องใช้ Gas หรือ bundler หรือ paymaster ที่ทำงานได้หรือไม่

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

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

## ตัวอย่าง

กระเป๋าเงินเกมสร้างเซสชันที่ใช้ได้ 24 ชั่วโมง โดยอนุญาตให้เรียกเฉพาะสัญญาเกมที่ตรวจสอบแล้ว บล็อก `delegatecall` และการอนุมัติโทเค็น จำกัดมูลค่าสินทรัพย์ดั้งเดิมไว้ที่ `0.02 ETH` ต่อครั้ง และจำกัดยอดใช้จ่ายรวมไว้ที่ `20 USDC` เกมส่งการเคลื่อนไหวที่อนุญาตได้โดยไม่ต้องยืนยันซ้ำ แต่คำขอโอน NFT ที่ไม่เกี่ยวข้องต้องไม่ผ่านการตรวจสอบ

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

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

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

- **นโยบายกว้างเกินไป:** ปลายทางแบบ wildcard ตัวเลือกที่ไม่จำกัด การอนุมัติโทเค็นไม่จำกัด batch หรือ `delegatecall` อาจทำให้กุญแจที่ “จำกัด” มีอำนาจเกือบเท่าเจ้าของ ใช้รายการอนุญาตที่ชัดเจนและห้ามการดำเนินการระดับผู้ดูแล
- **กุญแจถูกขโมย:** ที่เก็บของเบราว์เซอร์ บันทึก สำเนาสำรอง ส่วนขยาย มัลแวร์ และอุปกรณ์ร่วมอาจเปิดเผยกุญแจ หากรองรับ ให้เลือกที่เก็บแยกหรือป้องกันด้วยฮาร์ดแวร์ อายุสั้น และเพดานสะสมต่ำ
- **การบังคับใช้ผิดพลาด:** บัญชี ตัวตรวจสอบ ตัวดำเนินการ หรือ hook อาจถอดรหัสการเรียกผิดหรือไม่ครอบคลุมเส้นทางอื่น ใช้การติดตั้งที่ตรวจสอบแล้ว โค้ดที่ผ่านการทบทวน การตรวจสอบความปลอดภัย และการทดสอบการหลีกเลี่ยง
- **การเล่นซ้ำและสับสนบริบท:** การจัดการ nonce ที่อ่อนแอหรือไม่ผูกกับเชน บัญชี โมดูล หรือนโยบายที่ตั้งใจ อาจทำให้นำกลับมาใช้ได้ ตรวจโดเมนที่ลงนามอย่างถูกต้องและการป้องกันการเล่นซ้ำบนเชน
- **ความเข้าใจผิดเรื่องหมดอายุ:** `validUntil` อาจจำกัดรายการ ERC-4337 เพียงรายการเดียวโดยไม่ลบกุญแจที่ลงทะเบียน วงเงินโทเค็น หรือหนังสือมอบหมายอื่นโดยอัตโนมัติ ตรวจสถานะจริงของทุกสิทธิ์หลังหมดอายุ
- **การเพิกถอนล้มเหลว:** การลบข้อมูลในเครื่องลบเพียงสำเนาหนึ่งของความลับ เพิกถอนผ่านเส้นทางที่เอกสารบัญชีกำหนดและตรวจผลบนเชน เก็บ Gas ให้พอและมีเส้นทางสำรองที่เจ้าของควบคุม
- **โมดูลอัปเกรดได้หรือเป็นอันตราย:** โมดูลอาจมีสิทธิ์ดำเนินการสูง และการอัปเกรดอาจเปลี่ยนพฤติกรรมนโยบาย ตรวจเจ้าของ ระยะหน่วงการอัปเกรด สิทธิ์หยุด ที่อยู่การนำไปใช้ และขั้นตอนถอดโมดูล
- **การใช้ Gas และการสนับสนุนในทางที่ผิด:** เซสชันอาจใช้เงินบัญชีเป็นค่า Gas หรือใช้ไม่ได้เมื่อ paymaster ปฏิเสธ จำกัดพฤติกรรมค่าธรรมเนียมเมื่อทำได้และรักษาเส้นทางส่งรายการอิสระ

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

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

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

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

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

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

- [การแยกนามธรรมของบัญชี](/th/crypto/account-abstraction/)
- [ความเสี่ยงของ ERC-4337 Paymaster](/th/crypto/erc4337-paymaster-risk/)
- [การจัดการกุญแจส่วนตัว](/th/crypto/private-key-management/)
- [การจำลองธุรกรรม](/th/crypto/transaction-simulation/)
- [ลายเซ็นกระเป๋าเงิน](/th/crypto/wallet-signature/)

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

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

- [Session Keys & Delegation](https://docs.erc4337.io/smart-accounts/session-keys-and-delegation.html) - ERC-4337 Documentation (เข้าถึง: 2026-08-21)
- [ERC-4337: Account Abstraction Using Alt Mempool](https://eips.ethereum.org/EIPS/eip-4337) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-21)
- [ERC-7579: Minimal Modular Smart Accounts](https://eips.ethereum.org/EIPS/eip-7579) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-21)
- [Safe Modules](https://docs.safe.global/advanced/smart-account-modules) - Safe Docs (เข้าถึง: 2026-08-21)

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