เขียน Smart Contract

เขียน smart contract ที่รองรับ Chiliz Chain ด้วย Solidity: เวอร์ชัน Solidity และ EVM ที่แนะนำ, decimals ของ CAP-20 token, กลไก gas, และความแตกต่างของ EVM เทียบกับ Ethereum

ตั้งแต่ที่คุณตัดสินใจสร้าง dApp บน Chiliz Chain คุณจำเป็นต้องคำนึงถึงลักษณะเฉพาะของ blockchain ของเรา

แม้ว่า Chiliz Chain จะรองรับ EVM แต่การปฏิบัติต่อมันเหมือน Ethereum ทุกประการอาจนำไปสู่ปัญหาด้านการใช้งาน โดยเฉพาะเรื่อง decimals ของ token และกลไก gas

มาสำรวจกันเลย!

ข้อกำหนดเบื้องต้น

สภาพแวดล้อม

ก่อนที่คุณจะเริ่มเขียน smart contract ตรวจสอบให้แน่ใจว่าสภาพแวดล้อมของคุณพร้อมแล้ว

ประการแรก คุณต้องมีกระเป๋าเงินที่ตั้งค่าสำหรับ Spicy Testnet (สำหรับการพัฒนา) หรือ Chiliz Chain Mainnet (สำหรับการใช้งานจริง)

เชื่อมต่อกับ Chiliz Chain

ประการที่สอง คุณจะต้องมี $CHZ เพื่อจ่าย gas ในการ deploy บน Testnet และ Mainnet ในขณะที่คุณสามารถซื้อ $CHZ บน Mainnet ได้จากกระดานซื้อขาย crypto ทั่วไป คุณสามารถใช้ faucet สำหรับ token บน Testnet

รับ Token Testnet ฟรี

ในแง่ของเครื่องมือ คุณสามารถใช้ Hardhat หรือ Remix ได้ ดูตัวอย่างเช่น:

Deploy ด้วย Remix

สุดท้าย smart contract บน Chiliz Chain เขียนด้วยภาษา Solidity:

Home | Solidity Programming LanguageSolidity Programming Language

Solidity by Examplesolidity-by-example.org

ใช้เวอร์ชัน Solidity และ EVM ที่แนะนำ:

เวอร์ชัน Solidity และ EVM ที่แนะนำสำหรับ Chiliz Chain:

เวอร์ชัน Solidity compiler: 0.8.30 (หรือต่ำกว่า)
เวอร์ชัน EVM เป้าหมาย: prague

Fan Tokens / CAP-20

ลักษณะที่เฉพาะที่สุดของ Chiliz Chain คือมาตรฐาน CAP-20 ซึ่งใช้สำหรับ Fan Tokens

แม้ว่าในเชิงเทคนิคจะเหมือนกับโค้ดมาตรฐาน ERC-20 แต่ CAP-20 token มีการตั้งค่า decimals ที่เฉพาะเจาะจง กล่าวโดยย่อ: มันใช้ 0 decimals ในขณะที่ ERC-20 token ทั่วไปใช้ 18 decimals

Fan Tokens

ดังนั้น หากคุณ deploy Fan Token ด้วย 18 decimals อาจแสดงผลไม่ถูกต้องในกระเป๋าเงินของ ecosystem หรืออาจไม่รองรับการใช้งานร่วมกับ Socios.com ในอนาคต

แนวทางปฏิบัติที่ดีในการเขียน smart contract

ใช้ Library ที่ผ่านการทดสอบแล้ว (OpenZeppelin)

อย่าเริ่มสร้าง smart contract จากศูนย์ แนวทางปฏิบัติด้านความปลอดภัยที่มีประสิทธิภาพมากที่สุดเพียงอย่างเดียวคือการพัฒนาโค้ดของคุณบนพื้นฐานของมาตรฐานที่ผ่านการตรวจสอบจากชุมชน เพื่อลดความเสี่ยงของช่องโหว่

สำหรับการพัฒนาบน Chiliz Chain เราขอแนะนำอย่างยิ่งให้ใช้ OpenZeppelin Contracts ซึ่งมีการ implement token contract ที่ปลอดภัยและผ่านการตรวจสอบจากชุมชน

การใช้ smart contract มาตรฐานช่วยให้มั่นใจได้ว่า token ของคุณรองรับกระเป๋าเงินที่รู้จักกัน (เช่น MetaMask) และ Chiliz ecosystem (Socios.com)

แนวทางปฏิบัติ EVM ทั่วไป

ไม่ว่าจะใช้ chain ใด รูปแบบสามข้อนี้เป็นสิ่งที่ต้องปฏิบัติในการพัฒนา Solidity อย่างปลอดภัย

รูปแบบ "Checks-Effects-Interactions"

นี่คือการป้องกันหลักของคุณจาก Reentrancy Attacks โครงสร้างฟังก์ชันของคุณต้องเป็นลำดับนี้เสมอ:

Checks: ยืนยัน input และเงื่อนไข (เช่น คำสั่ง require)
Effects: อัปเดตสถานะของ smart contract (เช่น ลดยอดคงเหลือ)
Interactions: โต้ตอบกับ smart contract อื่นหรือส่งเงิน (เช่น transfer)

การควบคุมสิทธิ์การเข้าถึงที่แข็งแกร่ง

อย่าปล่อยให้ฟังก์ชันที่ละเอียดอ่อนไม่ได้รับการป้องกัน หากฟังก์ชันสร้าง token เปลี่ยนค่าธรรมเนียม หรืออัปเกรดตรรกะ จะต้องมีการจำกัดสิทธิ์

แบบง่าย: ใช้ Ownable สำหรับ smart contract ที่มีผู้ดูแลระบบคนเดียว
แบบซับซ้อน: ใช้ AccessControl สำหรับ smart contract ที่ต้องการหลายบทบาท (เช่น MINTER_ROLE, ADMIN_ROLE)

การยืนยัน Input

สมมติว่า input ทั้งหมดเป็นอันตราย ใช้คำสั่ง require() ที่ต้นฟังก์ชันของคุณเสมอเพื่อยืนยันพารามิเตอร์

ตัวอย่างเช่น:

ตรวจสอบ address ที่เป็นศูนย์ (address(0))
ตรวจสอบจำนวนที่เป็นศูนย์เมื่อทำการโอน
ยืนยันว่าความยาวของ array ตรงกันหากส่ง array หลายตัว
เป็นต้น

รายละเอียดการ implement เฉพาะของ Chiliz

แม้ว่า Chiliz Chain จะรองรับ EVM แต่มี "กฎเฉพาะ" บางอย่างที่ต้องใช้ โดยเฉพาะเรื่อง decimals ของ token

การรองรับ CAP-20 (Fan Tokens)

หากคุณกำลังเขียน smart contract ที่โต้ตอบกับ Fan Tokens (เช่น Staking Pool สำหรับ $PSG หรือ $BAR) คุณต้องจัดการกับ 0 decimals

ซึ่งหมายความว่า:

อย่าสมมติว่า 1 Token = 10^18 units สำหรับ Fan Tokens 1 Token = 1 unit
หลีกเลี่ยงการ hardcode 1e18 ในคณิตศาสตร์ของคุณหาก smart contract ของคุณตั้งใจให้ใช้งานได้ทั่วไป ใช้ฟังก์ชัน token.decimals() แบบ dynamic แทน

การ optimize Gas บน Chiliz

ธุรกรรมบน Chiliz Chain มีราคาถูกกว่า Ethereum อย่างมาก แต่โค้ดที่ไม่ได้รับการ optimize ก็ยังอาจทำให้เกิดความล่าช้าหรือธุรกรรมล้มเหลวในช่วงที่มีการใช้งานสูง (เช่น ระหว่างการแข่งขันที่ถ่ายทอดสด)

นี่คือสามวิธีในการประหยัด gas:

ใช้ Custom Errors: แทนที่จะใช้ข้อความ string ยาวๆ ใน require ให้ใช้การกำหนด error เพื่อประหยัด gas
จัดลำดับตัวแปร state ให้พอดีกับ slot ขนาด 32 ไบต์ วาง uint128, address และ bool ไว้ติดกันให้มากที่สุด
ควรใช้ external สำหรับฟังก์ชันที่ไม่ถูกเรียกใช้ภายใน smart contract เอง

อัปเดตล่าสุด 6 วันที่ผ่านมา

สิ่งนี้มีประโยชน์หรือไม่?