Skip to main content

วิวัฒนาการทางเทคนิค: สิ่งที่เปลี่ยนแปลงจริง ๆ

🔗 การนำทาง: 📋 INDEX | 📝 Diary Home | 🔍 การวิเคราะห์ | 📊 รายงาน

อ่านเพิ่มเติม: ความท้าทายและวิธีแก้ปัญหา | ความสำเร็จทางเทคนิค | ไทม์ไลน์การพัฒนา

การย้าย Stack​

Hardhat → Foundry (Session 4-5)​

ทำไม: การทดสอบ Hardhat ช้า, deployment scripts เทอะทะ
เมื่อไหร่: หลังจาก 45 commits, 3-4 มิถุนายน
ผลลัพธ์: การทดสอบเร็วขึ้น, เครื่องมือ deployment ดีขึ้น

Web3.js → Viem (Session 7-8)​

ทำไม: Web3.js ดูล้าสมัย, การรองรับ TypeScript แย่
เมื่อไหร่: 5 มิถุนายน ระหว่างทำ frontend ครั้งแรก
ผลลัพธ์: โค้ดสะอาดขึ้น, developer experience ดีขึ้น

Sequential → Multicall3 (Session 9)​

ทำไม: การโหลด NFT 210 ตัวใช้เวลา 30+ วินาที
เมื่อไหร่: 6 มิถุนายน การปรับปรุงประสิทธิภาพ
ผลลัพธ์: เวลาโหลดลดเหลือ 3 วินาที

การพัฒนา Contract​

Version 1: ERC721 พื้นฐาน​

contract CarbonCreditNFT is ERC721, Ownable {
    mapping(uint256 => uint256) public carbonAmount;
}

ปัญหา: ไม่มีระบบ class, มี minting แบบ manual เท่านั้น

Version 2: เพิ่ม Classes​

enum NFTClass { Standard, Platinum }
mapping(uint256 => NFTClass) public nftClass;

ปัญหา: ยังไม่มี batch operations

Version 3: ระบบ Production​

function batchMintWithClass(
    address[] memory recipients,
    NFTClass class,
    uint256 amount,
    string memory unit
) external onlyOwner

ผลลัพธ์: เวอร์ชัน production ปัจจุบัน

วิวัฒนาการ Frontend​

Phase 1: HTML + Web3.js พื้นฐาน​

  • หน้าเดียวสำหรับดู NFT
  • เชื่อมต่อ wallet แบบ manual
  • ไม่มีการจัดการ error

Phase 2: Modular Viem Integration​

  • สถาปัตยกรรมแบบ component-based
  • แชร์ constants ระหว่างไฟล์
  • ข้อความ error ที่ดีขึ้น

Phase 3: Production Interfaces​

  • 6 หน้า HTML ที่แตกต่างกัน
  • CSS แบบ Glassmorphism
  • การปรับปรุงด้วย Multicall3
  • อัปเดตแบบ real-time

ประวัติการ Deploy​

Local Only (Sessions 1-3)​

  • Hardhat local network
  • ทดสอบแบบ manual

First Testnet (Session 6)​

  • Deploy บน Sichang chain
  • Contract verification ทำงานได้

Multi-Chain (Sessions 11-12)​

  • เพิ่ม JIBCHAIN L1
  • ได้ addresses แบบ deterministic
  • Contract เดียวกันบนทั้งสอง networks

ข้อมูล Performance​

ก่อน Multicall3​

  • 210 RPC calls แบบต่อเนื่อง
  • เวลาโหลด 30+ วินาที
  • user experience แย่

หลัง Multicall3​

  • 21 batched calls
  • เวลาโหลด 3 วินาที
  • พร้อมสำหรับ production

การประหยัด Gas​

Contract ตอนแรก​

  • Individual minting: ~50k gas
  • ไม่มี batch operations

Contract ปัจจุบัน​

  • Batch minting: ~45k gas ต่อ NFT
  • Manager contract จัดการการแจกจ่าย

การตัดสินใจทางเทคนิคที่สำคัญ​

สถาปัตยกรรม Smart Contract​

  • NFT ทั้งหมด mint ไปที่ manager contract
  • ระบบสองระดับ: Standard (1 tCO2), Platinum (10 tCO2)
  • การสร้าง SVG on-chain

กลยุทธ์ Multi-Chain​

  • Addresses เหมือนกันผ่าน nonce synchronization
  • ลำดับ deployment เดียวกันบนทุก networks
  • การตั้งค่า RPC ที่สอดคล้องกัน

Frontend Performance​

  • Multicall3 สำหรับทุก batch reads
  • การใช้ component ซ้ำระหว่าง interfaces
  • การ caching ที่จริงจังเท่าที่เป็นไปได้

สิ่งที่ใช้ไม่ได้ผล​

Template Literals ใน HTML​

<!-- สิ่งนี้ใช้ไม่ได้ -->
<p>Contract: ${CONTRACT_ADDRESS}</p>

แก้ไข: ใช้ addresses จริงใน HTML, template literals ใน JS เท่านั้น

Display Limits ที่ hardcode​

// นี่ผิด
const loadCount = Math.min(totalSupply, 20);

แก้ไข: แสดง tokens ทั้งหมดเสมอหรือทำ paginate ให้ถูกต้อง

RPC URLs ที่ปนกัน​

  • ใช้ทั้ง localhost และ white.local แก้ไข: มาตรฐานที่ localhost:8545

Deployment Timeouts​

  • Batch mints ขนาดใหญ่จะ timeout แก้ไข: ทำให้เสร็จแบบ manual ด้วย cast commands

สถาปัตยกรรมปัจจุบัน​

Smart Contracts​

  • NimmanCarbonPass: ERC721 หลักพร้อมฟีเจอร์ carbon
  • NimmanNFTManagerSimple: การจัดการ batch transfer
  • UniservLogoStorageDynamic: การเก็บ SVG on-chain

Frontend Stack​

  • Vanilla HTML/JS พร้อม ES modules
  • Viem สำหรับ Web3 interactions
  • สถาปัตยกรรม shared component
  • Multicall3 สำหรับ performance

Networks​

  • Sichang: Chain ID 700011, testnet หลัก
  • JIBCHAIN L1: Chain ID 8899, testnet รอง
  • Anvil: การพัฒนาและทดสอบ local

บทเรียนที่นำไปใช้​

  1. ใช้เครื่องมือที่ทันสมัย: Foundry > Hardhat, Viem > Web3.js
  2. ปรับปรุงตั้งแต่เนิ่น ๆ: ใส่ Multicall3 ตั้งแต่เริ่มต้น
  3. ทำให้เป็นมาตรฐานทุกอย่าง: RPC URLs, contract addresses
  4. บันทึกการตัดสินใจ: ทำไมถึงเลือกแบบนั้น
  5. ทดสอบอย่างละเอียด: ทุกฟังก์ชัน, ทุก networks