---
title: "ERC-1155"
description: "ERC-1155 คือมาตรฐานมัลติโทเค็นของ Ethereum ซึ่งสัญญาเดียวสามารถบันทึกโทเค็นได้หลายประเภท ทั้งแบบทดแทนกันได้ แบบทดแทนกันไม่ได้ หรือแบบผสมตาม ID และโอนหลาย ID พร้อมกันเป็นชุดได้"
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.

# ERC-1155

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

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

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

ERC-1155 คือมาตรฐานมัลติโทเค็นของ Ethereum สัญญาเดียวสามารถดูแลโทเค็นได้หลายประเภท และ `token ID` แต่ละรายการอาจแทนยอดคงเหลือที่ทดแทนกันได้ ไอเท็มที่ทดแทนกันไม่ได้ หรือโครงสร้างอุปทานแบบอื่นที่ผู้พัฒนาเลือกใช้ ดังนั้น คีย์ของสินทรัพย์จึงเป็น `contract address + token ID` ไม่ใช่เพียง ID โทเค็น

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

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

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

1. **ระบุยอดคงเหลือ** `balanceOf(account, id)` จะแสดงจำนวนของ ID หนึ่งที่บัญชีถืออยู่ ส่วน `balanceOfBatch(accounts, ids)` จะสอบถามคู่บัญชีและ ID ที่ตรงกัน สัญญาสองฉบับอาจใช้ ID `1` กับสินทรัพย์ที่ไม่เกี่ยวข้องกัน ดังนั้น ตัวตนที่ครบถ้วนจึงยังต้องประกอบด้วยเครือข่าย ที่อยู่สัญญา และ ID
2. **อนุญาตผู้เรียกใช้** ผู้ถือสามารถโอนยอดคงเหลือของตนเองหรือเรียก `setApprovalForAll(operator, true)` การอนุมัตินี้ครอบคลุม ERC-1155 ทุก ID ที่ผู้ถือเป็นเจ้าของในสัญญานั้น และ `isApprovedForAll(owner, operator)` ใช้ตรวจสอบสถานะ ERC-1155 ไม่มีการอนุมัติแบบเนทีฟที่จำกัดไว้เฉพาะ ID เดียวหรือจำนวนหนึ่ง
3. **ดำเนินการโอนแบบรายการเดียวหรือแบบชุด** `safeTransferFrom` ใช้ย้ายหนึ่ง ID และหนึ่งจำนวน ส่วน `safeBatchTransferFrom` ใช้ย้ายอาร์เรย์คู่ขนาน `ids` และ `values` ซึ่งต้องมีความยาวและลำดับตรงกัน การรวมเป็นชุดอาจลดค่าใช้จ่ายซ้ำซ้อนของธุรกรรม แต่ไม่ได้รับประกันว่าจะถูกกว่าในทุกการนำไปใช้หรือทุกภาระงาน
4. **ตรวจสอบสัญญาผู้รับ** หลังจากอัปเดตยอดคงเหลือและปล่อย event ที่เกี่ยวข้องแล้ว การโอนที่เป็นไปตามมาตรฐานไปยังสัญญาจะเรียก `onERC1155Received` หรือ `onERC1155BatchReceived` หากไม่รองรับ callback ส่งค่าตอบกลับผิด หรือปฏิเสธ โดยทั่วไปการโอนจะถูกย้อนกลับ การตรวจสอบผู้รับช่วยลดโอกาสที่สินทรัพย์จะติดค้างโดยไม่ตั้งใจ แต่ไม่ได้ยืนยันว่าสัญญาผู้รับน่าเชื่อถือหรือมีช่องทางถอนสินทรัพย์
5. **สร้างสถานะย้อนหลังจาก event** การสร้าง การโอน และการเผาทุกครั้งต้องปรากฏใน `TransferSingle` หรือ `TransferBatch` การสร้างใช้ที่อยู่ศูนย์เป็น `from` ส่วนการเผาใช้เป็น `to` ผู้จัดทำดัชนีสามารถคำนวณยอดคงเหลือและอุปทานสุทธิที่สร้างต่อ ID จาก log เหล่านี้ได้ แต่ต้องประมวลผลประวัติทั้งหมด การปรับโครงสร้างเครือข่าย และการย้ายสัญญาอย่างถูกต้อง
6. **เรียกดูเมทาดาทา** ส่วนขยาย URI แบบไม่บังคับอาจส่งคืนเทมเพลตร่วมที่มี `{id}` ไคลเอนต์จะแทนที่ด้วย ID โทเค็นฐานสิบหกที่ใช้อักษรตัวพิมพ์เล็กและเติมเลขศูนย์ด้านหน้าให้ครบ 64 อักขระ โดยไม่มีคำนำหน้า `0x` อย่างไรก็ตาม เมทาดาทายังอาจเปลี่ยนแปลง สูญหาย หรือทำให้เข้าใจผิดได้ เว้นแต่การนำไปใช้และการรับประกันด้านพื้นที่จัดเก็บจะระบุไว้เป็นอย่างอื่น

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

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

สัญญาเกมกำหนด ID `1` ให้เหรียญทอง ID `7` ให้บัตรผ่าน และ ID `42` ให้ดาบที่มีชิ้นเดียว Alice ถือ `balanceOf(Alice, 1) = 500`, `balanceOf(Alice, 7) = 3` และ `balanceOf(Alice, 42) = 1`

- Alice เรียก `safeBatchTransferFrom` โดยกำหนด `ids = [1, 7, 42]` และ `values = [120, 1, 1]` หากผ่านการตรวจสอบ ยอดคงเหลือใหม่ของเธอคือ `500 - 120 = 380`, `3 - 1 = 2` และ `1 - 1 = 0` ส่วนผู้รับจะได้รับจำนวนที่ตรงกัน
- สัญญาปล่อย `TransferBatch` หากผู้รับเป็นสัญญา สัญญานั้นต้องยอมรับชุดรายการผ่าน `onERC1155BatchReceived` มิฉะนั้น ธุรกรรมทั้งหมดจะถูกย้อนกลับและการเปลี่ยนแปลงยอดคงเหลือทั้งสามรายการจะไม่เกิดขึ้น
- ID `42` ทำหน้าที่เหมือนโทเค็นที่ทดแทนกันไม่ได้ เพราะตรรกะการออกและการโอนรักษาอุปทานไว้ที่ `1` เท่านั้น ERC-1155 ไม่ได้บังคับกฎนี้ สัญญาเดียวกันอาจสร้าง ID `1` เพิ่มในภายหลังได้ตามการควบคุมสิทธิ์ของตนเอง

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

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

- **อำนาจของผู้ดำเนินการครอบคลุมกว้าง** ผู้ดำเนินการที่ประสงค์ร้ายหรือถูกเจาะระบบและได้รับอนุมัติผ่าน `setApprovalForAll` อาจย้ายทุก ID ที่ผู้ถือเป็นเจ้าของในสัญญานั้น ตรวจสอบที่อยู่ผู้ดำเนินการและสัญญา ใช้กระเป๋าแยกเมื่อเหมาะสม และเพิกถอนการอนุมัติที่ไม่จำเป็นแล้ว
- **อำนาจในการสร้าง ระงับ และอัปเกรด** สิ่งเหล่านี้เป็นคุณสมบัติของการนำไปใช้ ไม่ใช่การรับประกันจากมาตรฐาน ควรตรวจสอบผู้ถือบทบาท ผู้ดูแล proxy timelock ส่วนขยายอุปทาน และดูว่าการอัปเกรดสามารถเปลี่ยนยอดคงเหลือหรือกฎการโอนได้หรือไม่
- **เมทาดาทาไม่ตรงกับสินทรัพย์** URI หรือไฟล์ JSON ที่โฮสต์ไว้อาจเปลี่ยนไป แม้ ID บนเชนจะคงเดิม ตรวจสอบแฮชของเนื้อหา ความคงทนของพื้นที่จัดเก็บ คำมั่นของผู้ออก และสิทธิที่แสดงอยู่นอกสัญญาโทเค็น
- **ข้อผิดพลาดในการเชื่อมต่อระบบ** กระเป๋าและผู้จัดทำดัชนีอาจจับคู่อาร์เรย์ชุดผิด พลาด event ในอดีต จัดการการปรับโครงสร้างเครือข่ายไม่ถูกต้อง หรือสับสน ID เดียวกันระหว่างสัญญาและเครือข่าย ควรกระทบยอดการเรียกสัญญา log และยอดคงเหลือสุดท้าย
- **ความเสี่ยงจากผู้รับและ reentrancy** callback ของผู้รับจะเรียกใช้โค้ดภายนอกระหว่างขั้นตอนการโอน การนำไปใช้และโปรโตคอลที่เชื่อมต่อกันต้องจัดลำดับสถานะและมีการป้องกัน reentrancy ที่เหมาะสม การรองรับ callback เพียงอย่างเดียวไม่ถือเป็นการตรวจสอบความปลอดภัย
- **ความเสี่ยงด้านต้นทุนและสภาพคล่อง** การโอนเป็นชุดยังคงใช้ gas และจะถูกย้อนกลับทั้งชุดหากเงื่อนไขที่จำเป็นข้อใดข้อหนึ่งล้มเหลว ERC-1155 ไม่ครอบคลุมสภาพคล่องของตลาด การกำหนดราคา ค่าลิขสิทธิ์ การเชื่อมข้ามเครือข่าย การไถ่ถอน หรือการบังคับใช้สิทธินอกเชน

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

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

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

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

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

- [ERC-20](/th/crypto/erc20/)
- [ERC-721](/th/crypto/erc721/)
- [NFT](/th/crypto/nft/)
- [มาตรฐานโทเค็น](/th/crypto/token-standard/)

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

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

- [ERC-1155: มาตรฐานมัลติโทเค็น](https://eips.ethereum.org/EIPS/eip-1155)
- [API ของ ERC1155](https://docs.openzeppelin.com/contracts/5.x/api/token/erc1155)

Source: https://wiki.fcontext.com/th/crypto/erc1155/index.mdx