---
title: "มาตรฐานโทเค็น"
description: "มาตรฐานโทเค็นคืออินเทอร์เฟซร่วมสำหรับการออก โอน อนุมัติ และตรวจหาโทเค็นบนบล็อกเชน บทความนี้เปรียบเทียบ ERC-20, ERC-721 และ ERC-1155 และอธิบายว่าสิ่งใดที่ความเข้ากันได้รับประกันหรือไม่รับประกัน"
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-20** แทนหน่วยที่ใช้แทนกันได้ แต่ละหน่วยแลกกับหน่วยอื่นของโทเค็นเดียวกันได้
- **ERC-721** แทนโทเค็นที่ใช้แทนกันไม่ได้และมีตัวระบุเฉพาะ เช่น ของสะสมชิ้นเดียวหรือสิทธิ์ในทรัพย์สิน
- **ERC-1155** แทนโทเค็นหลายชนิดทั้งแบบใช้แทนกันได้ ใช้แทนกันไม่ได้ หรือกึ่งใช้แทนกันได้ในสัญญาเดียว และรองรับการทำงานแบบชุด

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

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

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

มาตรฐานระบุฟังก์ชันที่เรียกได้และเหตุการณ์ที่ปล่อยออกมา การเชื่อมต่อ ERC-20 มักตรวจ `balanceOf`, `totalSupply`, `transfer`, `approve`, `transferFrom` และ `allowance`; การเชื่อมต่อ ERC-721 ตรวจความเป็นเจ้าของและการอนุมัติผ่าน `ownerOf`, `safeTransferFrom`, `approve`, `setApprovalForAll` และมักรวม `tokenURI` ส่วน ERC-1155 เพิ่ม `balanceOfBatch`, `safeBatchTransferFrom` และแบบแผน `URI` ร่วมสำหรับโทเค็นหลาย ID

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

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

## ตัวอย่าง

สมมติว่าตลาดซื้อขายรับสินทรัพย์ที่โฆษณาว่าเป็น NFT แอปสามารถตรวจสอบเครือข่ายและที่อยู่สัญญา ตรวจหาอินเทอร์เฟซ ERC-721 อ่านความเป็นเจ้าของ และจำลองการโอนจำนวนน้อยได้ จากนั้นควรตรวจขอบเขตการอนุมัติ ข้อจำกัดการโอน การควบคุมการอัปเกรด และดูว่าเมทาดาทาเปลี่ยนแปลงได้หรืออยู่บนระบบนอกเชน

หากตลาดเดียวกันรับไอเท็มเกมด้วย ERC-1155 อาจเหมาะกว่า เพราะสัญญาเดียวเก็บโทเค็นหลาย ID ได้ และการโอนแบบชุดอาจลดต้นทุนธุรกรรม มาตรฐานช่วยให้เรียกเมธอดที่ถูกต้อง แต่ไม่ได้ยืนยันว่าไอเท็มแท้ หายาก มีสภาพคล่อง หรือบังคับใช้ได้ตามกฎหมาย

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

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

- **การใช้งานที่ไม่เป็นไปตามมาตรฐานหรือหลอกลวง:** สัญญาอาจใช้ชื่อคุ้นเคยแต่เปลี่ยนพฤติกรรมที่คาดหวังหรือเพิ่มข้อจำกัดการโอน
- **ความเสี่ยงด้านการอนุมัติ:** สิทธิ์ `approve` หรือโอเปอเรเตอร์ที่กว้างเกินไปอาจให้ผู้ใช้จ่ายที่ถูกเจาะย้ายสินทรัพย์ได้ ควรยกเลิกสิทธิ์ที่ไม่จำเป็น
- **ฮุกและการเรียกซ้ำ:** callback ของผู้รับในการโอน NFT และโทเค็นหลายชนิดสร้างเส้นทางประมวลผลและการโต้ตอบเพิ่มขึ้น
- **ความเสี่ยงด้านเมทาดาทาและตัวตน:** ข้อมูล `tokenURI` หรือ `URI` อาจเปลี่ยน หายไป หรือชี้ไปยังเนื้อหาที่ไม่ตรงกับสินทรัพย์ที่อ้าง
- **ความเสี่ยงด้านการบริหารและเศรษฐศาสตร์:** คีย์อัปเกรด การหยุดหรือบัญชีดำ ค่าลิขสิทธิ์ ค่าธรรมเนียม และสภาพคล่องต่ำอาจกำหนดผลลัพธ์จริง

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

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

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

### มาตรฐานทำให้โทเค็นปลอดภัยหรือไม่

ไม่ มาตรฐานอธิบายความคาดหวังด้านการทำงานร่วมกัน ความปลอดภัยยังขึ้นกับการใช้งาน บทบาทพิเศษ เส้นทางอัปเกรด เศรษฐศาสตร์โทเค็น ส่วนหน้า และตลาดโดยรอบ

### ERC-20, ERC-721 และ ERC-1155 ใช้แทนกันได้หรือไม่

ไม่ ยอดคงเหลือ ERC-20 ใช้แทนกันได้ ความเป็นเจ้าของ ERC-721 ติดตามตาม ID และ ERC-1155 ติดตามโทเค็นหลายประเภท แอปต้องใช้รูปแบบการโอน การอนุมัติ ยอดคงเหลือ และเหตุการณ์ที่ตรงกัน

### การรองรับจากกระเป๋าหรือตลาดพิสูจน์ความแท้หรือไม่

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

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

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

- [Ethereum](/crypto/ethereum/)
- [ERC-20](/crypto/erc20/)
- [ERC-721](/crypto/erc721/)
- [ERC-1155](/crypto/erc1155/)
- [สัญญาอัจฉริยะ](/crypto/smart-contract/)

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

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

- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (accessed: 2026-08-21)
- [ERC-721: Non-Fungible Token Standard](https://eips.ethereum.org/EIPS/eip-721) - Ethereum Improvement Proposals (accessed: 2026-08-21)
- [ERC-1155: Multi Token Standard](https://eips.ethereum.org/EIPS/eip-1155) - Ethereum Improvement Proposals (accessed: 2026-08-21)
- [ERC-165: Standard Interface Detection](https://eips.ethereum.org/EIPS/eip-165) - Ethereum Improvement Proposals (accessed: 2026-08-21)
- [Token Standards](https://ethereum.org/en/developers/docs/standards/tokens/) - Ethereum.org (accessed: 2026-08-21)

Source: https://wiki.fcontext.com/th/crypto/token-standard/index.mdx