การวิเคราะห์ความปลอดภัยของ ERC 1155 NFT Smart Contract

การวิเคราะห์ความปลอดภัยของ ERC 1155 NFT Smart Contract

การวิเคราะห์ความปลอดภัยของ ERC 1155 NFT Smart Contract PlatoBlockchain Data Intelligence ค้นหาแนวตั้ง AI.

อ่านเวลา: 5 นาที

คุณต้องเคยได้ยินเกี่ยวกับโทเค็น cryptocurrency โทเค็นต่างๆ มีบทบาทสำคัญในระบบนิเวศของ web3 โทเค็นเหล่านี้แสดงถึงความเป็นเจ้าของ ความมั่งคั่ง ความน่าเชื่อถือ และอำนาจในสกุลเงินดิจิทัล ส่วนที่สนุกคือคุณสามารถสร้างโทเค็นสกุลเงินดิจิตอลของคุณได้ 

โทเค็นเหล่านี้เป็นสัญญาอัจฉริยะที่เกี่ยวข้องกับฟังก์ชันต่างๆ สำหรับการดำเนินการต่างๆ เช่น การโอน การตรวจสอบยอดคงเหลือ ฯลฯ คุณสามารถสร้างโทเค็นของคุณได้โดยสร้างสัญญาอัจฉริยะสำหรับโทเค็น ถึงกระนั้น เพื่อให้แน่ใจว่าโทเค็นของคุณปลอดภัยและรู้สึกไว้วางใจได้ ERC 20 คือ มาตรฐานสัญญาอัจฉริยะ ที่แนะนำให้ปฏิบัติตามเพื่อสร้างโทเค็นที่ใช้ร่วมกันได้ และ ERC 721 เป็นมาตรฐานสัญญาอัจฉริยะซึ่งใช้เพื่อสร้างโทเค็นที่ไม่สามารถใช้ร่วมกันได้ (NFTs)

ERC 20 และ ERC 721 เป็นโปรโตคอลสัญญาอัจฉริยะที่ได้รับการยอมรับอย่างกว้างขวางสำหรับการสร้างโทเค็น พวกเขาให้สภาพแวดล้อมที่ปลอดภัยและเชื่อถือได้สำหรับโทเค็น และโปรโตคอลเหล่านี้ยังคงพัฒนาและดีขึ้นเรื่อยๆ ขั้นตอนในทิศทางนั้นนำไปสู่การสร้างโปรโตคอลสัญญาอัจฉริยะ ERC 1155 ใหม่สำหรับโทเค็น มาดูกันว่ามีอะไรบ้าง

1. ERC 1155 คืออะไร?

ERC ทั้งหมด เช่น 20 และ 721 เป็นเพียงมาตรฐานสำหรับการสร้างสัญญาอัจฉริยะซึ่งเหมาะกับสถานการณ์ที่แตกต่างกันสำหรับ NFT เรามี ERC 721 และโทเค็นที่ใช้ร่วมกันได้ เช่น USDT และ DAI เป็นไปตามมาตรฐาน ERC 20 ERC 1155 เป็นมาตรฐานหนึ่งที่เกี่ยวข้องกับฟังก์ชันและคุณสมบัติของ ERC 20 และ ERC 721

สมมติว่าคุณต้องการสร้างโปรแกรมที่คุณสร้างสินค้าหลายรายการ ตัวอย่างเช่น คุณต้องการสร้างโทเค็นชื่อทอง อีกโทเค็นชื่อเงินและราชาหนึ่งคน และตรรกะบอกว่าโทเค็นที่มีทองคำและเงินมากกว่าจะเป็นราชา มีกษัตริย์องค์เดียวเท่านั้น เป็นโปรโตคอลที่เรียบง่าย แต่ในการสร้างสิ่งนี้ คุณจะต้องปรับใช้สัญญา 3 ฉบับสำหรับสินทรัพย์ หนึ่งรายการสำหรับโทเค็นทอง อีกฉบับสำหรับเงิน และอีกฉบับสำหรับกษัตริย์ ซึ่งจะเป็น ERC 721 แต่จะเป็นอย่างไรหากคุณปรับใช้สัญญาเพียงรายการเดียวที่แสดงรายการโทเค็นต่างๆ ทั้งหมด

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

1.1 รหัสโทเค็นใน ERC 1155

คุณต้องทราบวิธีการตรวจสอบยอดคงเหลือในโทเค็น ERC 20 ต่างๆ คุณสามารถโทร ยอดคงเหลือ (ที่อยู่ _owner) ฟังก์ชัน และคุณสามารถรับจำนวนโทเค็นที่อยู่นั้น แต่ ERC 1155 เกี่ยวข้องกับโทเค็นที่แตกต่างกัน ดังนั้นเราจึงจำเป็นต้องระบุรหัสที่แตกต่างกันสำหรับโทเค็นที่แตกต่างกัน เกือบทุกฟังก์ชันที่เกี่ยวข้องกับโทเค็นใช้พารามิเตอร์อย่างน้อยสองตัว ได้แก่ tokenId (เนื้อหาที่คุณต้องการสอบถาม) และที่อยู่ที่คุณต้องการทราบ

ตัวอย่างเช่น สมมติว่าสัญญามี 3 โทเค็น ทอง เงิน และราชา หากต้องการทราบว่าที่อยู่ใดที่อยู่หนึ่งมีทองเท่าใดในโปรโตคอลนั้น คุณสามารถเรียกใช้ฟังก์ชัน balanceOf(ที่อยู่ _เจ้าของ, uint256 _id) ในสัญญาอัจฉริยะ สมมติว่า tokenId สำหรับ gold ถูกระบุเป็น 1 จากนั้นคุณสามารถเรียกใช้ได้ ความสมดุลของ(0x4Bf9DeCE75Bc7C4a9054d5b3BB13D53543eE4096, 1).

2 แนวทางการตรวจสอบสัญญาอัจฉริยะ ERC 1155

ERC 1155 มีมาระยะหนึ่งแล้ว และคุณสมบัติบางอย่างไม่พร้อมใช้งานในโปรโตคอล ERC 20 หรือ ERC 721 ปกติ เช่น การถ่ายโอนเป็นชุด นอกจากนี้ ERC 1155 ยังไม่ค่อยแพร่หลายในตลาด จึงทำให้พื้นที่นี้ไม่ค่อยมีการสำรวจสำหรับนักพัฒนาหลายๆ ราย QuillAudits แบ่งปันข้อมูลเชิงลึกที่สำคัญสำหรับโปรโตคอลที่ต้องการ BUIDL บน ERC 1155 เพื่อให้พวกเขาสามารถช่วยสร้างระบบนิเวศ web3 ที่ปลอดภัยยิ่งขึ้นด้วยการป้องกันตัวเอง 

2.1 อินเทอร์เฟซตัวรับสัญญาณ ERC 1155

เมื่อสัญญา ERC 1155 ของเราโอนสินทรัพย์ไปยังสัญญาอื่นซึ่งโดยทั่วไปเป็นข้อกำหนดในโปรโตคอลเกม web3 สิ่งสำคัญคือต้องมีอินเทอร์เฟซ ERC1155Receiver ในสัญญาการรับสำหรับการทำธุรกรรมโทเค็นที่ประสบความสำเร็จ

ฟังก์ชั่นสองอย่างที่อยู่ภายใต้ ERC 1155 Receiver Interface คือ:-

  • onERC1155Received(ตัวดำเนินการ จาก รหัส ค่า ข้อมูล)
  • onERC1155BatchReceived(ตัวดำเนินการ จาก รหัส ค่า ข้อมูล)

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

ต้องไม่เรียกใช้ฟังก์ชันนี้นอกโรงกษาปณ์หรือกระบวนการถ่ายโอน หากต้องการยอมรับการถ่ายโอน จะต้องส่งคืน bytes4(keccak256(“onERC1155Received(address,address,uint256,uint256,bytes)”)) หากการถ่ายโอนได้รับอนุญาต

ดูที่พารามิเตอร์:-

  1. โอเปอเรเตอร์:- ที่อยู่ที่เริ่มต้นการถ่ายโอน (เช่น msg.sender) 
  2. จาก:- ที่อยู่ที่เคยเป็นเจ้าของโทเค็น
  3. id:- ID ของโทเค็นที่กำลังโอน 
  4. ค่า:- จำนวนโทเค็นที่กำลังโอน 
  5. ข้อมูล: - ข้อมูลเพิ่มเติมที่ไม่มีรูปแบบที่ระบุ 

2.2 ไม่มีฟังก์ชันการอนุมัติ ()?

หากคุณเคยทำงานกับ ERC 20 หรือ ERC 721 คุณจะพบกับฟังก์ชันการอนุมัติ () ซึ่งอนุญาตให้บางที่อยู่รับโทเค็นที่ได้รับอนุมัติจากยอดคงเหลือของเจ้าของ ตัวอย่างเช่น หาก A ต้องการอนุมัติ B ในการรับโทเค็น 100 โทเค็นของ DAI จากนั้น A สามารถเรียกใช้ฟังก์ชันการอนุมัติ โดยบอกว่า B มีสิทธิ์ได้รับโทเค็น DAI 100 โทเค็น และต่อมา B สามารถทำธุรกรรมด้วยจำนวนเงินดังกล่าวได้

แต่ ERC 1155 ไม่มี อนุมัติ ฟังก์ชันสำหรับโทเค็นเดียว เรามี setApprovalForAll(ตัวดำเนินการที่อยู่ บูลอนุมัติ) ฟังก์ชัน ซึ่งเรียกโดยเจ้าของและรับตัวดำเนินการพารามิเตอร์ที่อยู่ ซึ่งเป็นที่อยู่ของผู้ใช้จ่ายหรือที่อยู่ที่เราต้องการอนุมัติโทเค็นของเรา ดังนั้นเราจึงไม่สามารถโทรหา อนุมัติ ฟังก์ชันหรือให้การอนุมัติสำหรับโทเค็นเดียวจากรายการโทเค็น ERC 1155 ของเรา แต่การเข้าถึงโทเค็นทั้งหมดจะได้รับการอนุมัติทันที ทีมพัฒนาจำเป็นต้องตระหนักถึงสิ่งนี้ หากเพิกเฉย สิ่งนี้อาจนำไปสู่การสูญเสียครั้งใหญ่และทำให้โปรโตคอลเสียหายได้

2.3 การตรวจสอบปกติบางอย่าง

สองส่วนข้างต้นได้สำรวจการตรวจสอบที่เกี่ยวข้องกับ ERC 1155 ที่ไม่ซ้ำกันสองรายการ ในส่วนนี้ เราจะทำการตรวจสอบตามปกติซึ่งไม่จำเป็นต้องอธิบายอย่างลึกซึ้งมากนัก

  1. คำนึงถึง ID:- ทุกฟังก์ชันภายนอกหรืออินเทอร์เฟซที่ทำงานร่วมกับ ERC 1155 จำเป็นต้องมีรหัสโทเค็นที่ระบุเพื่อใช้เป็นอินพุต
  2. Burn/Mint:- เมื่อใดก็ตามที่เรียกใช้ฟังก์ชันเหล่านี้ จะต้องเปลี่ยนยอดคงเหลือและ totalSupply สำหรับรหัสโทเค็นที่ระบุเท่านั้น
  3. ความคล้ายคลึงของ ERC 20:- คุณสมบัติหลายอย่างเหมือนกับมาตรฐานโทเค็น ERC 20 การปฏิบัติตามแนวทางความปลอดภัยสำหรับ กกพ. 20 ก็จะช่วยในเรื่องนี้ได้เช่นกัน
  4. Re-entrance:- ตามที่กล่าวไว้ ERC 1155 ตรวจสอบอินเทอร์เฟซที่รองรับในลอจิกการถ่ายโอน ดังนั้นจึงมีสถานการณ์ต่างๆ ที่อาจส่งผลให้เกิด ช่องโหว่ที่กลับเข้ามาใหม่. ขอแนะนำให้เก็บตัวแก้ไขการป้องกันการไม่กลับเข้าที่ในฟังก์ชันที่เกี่ยวข้อง

3 ข้อสรุป

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

17 เข้าชม

ประทับเวลา:

เพิ่มเติมจาก ควิลแฮช