פיתוח טוקן ERC-20 במפתח מלא: יצירה, ביקורת, אימות

ERC-20 הוא ממשק, לא יישום. שש פונקציות חובה (totalSupply, balanceOf, transfer, transferFrom, approve, allowance) ושני אירועים (Transfer, Approval). כל השאר הם פרטי יישום שחשובים. הניסיון שלנו — מעל 50 טוקני ERC-20 שהושקו לייצור — מראה שפרטים אלה קובעים אם הטוקן יהיה תואם לפרוטוקולי DeFi או ידרוש שכתוב.

באיזו גישה לפיתוח טוקן ERC-20 לבחור?

הדילמה הראשונה — ניתן לשדרוג (Proxy + Implementation) או בלתי ניתן לשינוי. Proxy מספק גמישות לשינויים, אך כל עסקה דרך delegatecall עולה כ-150,000 גז לעומת 45,000 לחוזה רגיל. חוזים בלתי ניתנים לשינוי זולים פי שלושה למשתמשים ופשוטים יותר לבדיקה. המלצה: לטוקני utility ו-governance — בלתי ניתנים לשינוי; ל-DeFi vaults ופרוטוקולים מורכבים — ניתנים לשדרוג בזהירות.

הנושא השני — שליטה ב-minting. אם ה-minter הוא EOA, זהו סיכון ריכוזיות: המפתח עלול לדלוף או שהבעלים יוכל להנפיק כמות בלתי מוגבלת. פתרון — השתמשו ב-multisig או בחוזה חכם עם תפקיד MINTER. הפרויקטים שלנו תמיד משתמשים ב-AccessControl לניהול מבוזר.

השלישי — אופטימיזציית גז. אי שימוש ב-ERC20Permit (EIP-2612) מאלץ את המשתמש לבזבז שתי עסקאות במקום אחת עבור האינטראקציה הראשונה עם DeFi.

למה להשתמש ב-OpenZeppelin במקום לכתוב מאפס?

OpenZeppelin הוא התקן התעשייתי. הקוד שלהם עבר מאות בדיקות, בשימוש במיליוני חוזים. אל תכתבו ERC-20 מאפס — זה מגדיל את הסיכון לשגיאות ומפחית את אמון האינטגרטורים. הפתרונות שלנו מבוססים על OpenZeppelin עם מודולים מותאמים נוספים.

יישום בסיסי

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol";
import "@openzeppelin/contracts/access/Ownable2Step.sol";

contract MyToken is ERC20, ERC20Burnable, ERC20Permit, Ownable2Step {
    uint256 public constant MAX_SUPPLY = 100_000_000 * 10**18; // 100M токенов

    constructor(
        address initialOwner,
        address treasury
    ) ERC20("My Token", "MTK") ERC20Permit("My Token") Ownable2Step() {
        _transferOwnership(initialOwner);
        _mint(treasury, MAX_SUPPLY); // весь supply при деплое
    }
}

// SPDX-License-Identifier: MIT pragma solidity ^0.8.24; import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol"; import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol"; import "@openzeppelin/contracts/access/Ownable2Step.sol"; contract MyToken is ERC20, ERC20Burnable, ERC20Permit, Ownable2Step { uint256 public constant MAX_SUPPLY = 100_000_000 * 10**18; // 100M токенов constructor( address initialOwner, address treasury ) ERC20("My Token", "MTK") ERC20Permit("My Token") Ownable2Step() { _transferOwnership(initialOwner); _mint(treasury, MAX_SUPPLY); // весь supply при деплое } } הוא הרחבה חשובה: הוא מאפשר אישור דרך חתימות off-chain. זה משפר את חוויית המשתמש (עסקה אחת במקום שתיים) ומפחית גז למשתמש. ERC20Permit במקום Ownable2Step מגן מפני העברת שליטה בטעות לכתובת שגויה.

טוקן Mintable עם בקרת גישה

אם הטוקן צריך להיות מונפק לאחר הפריסה, השתמשו ב-AccessControl:

import "@openzeppelin/contracts/access/AccessControl.sol";

contract MintableToken is ERC20, ERC20Burnable, ERC20Permit, AccessControl {
    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
    uint256 public immutable maxSupply;

    constructor(
        string memory name,
        string memory symbol,
        uint256 _maxSupply,
        address admin
    ) ERC20(name, symbol) ERC20Permit(name) {
        maxSupply = _maxSupply;
        _grantRole(DEFAULT_ADMIN_ROLE, admin);
        _grantRole(MINTER_ROLE, admin);
    }

    function mint(address to, uint256 amount) external onlyRole(MINTER_ROLE) {
        require(totalSupply() + amount <= maxSupply, "Exceeds max supply");
        _mint(to, amount);
    }
}

יש להקצות את MINTER_ROLE לחוזה חכם (תגמולי staking, vesting), לא ל-EOA.

השוואת גישות

למה decimals צריכים להיות 18 (בדרך כלל)

כברירת מחדל, decimals = 18 (כמו ETH). יוצא דופן: USDC/USDT משתמשים ב-6. אם יוצרים stablecoin או wrap — בדקו את ה-decimals של המקור. לעולם אל תשתמשו ב-0 decimals לטוקנים שיסחרו ב-DEX — AMM עובד גרוע עם מספרים שלמים. נתקלנו בפרויקטים שבהם decimals שגויים גרמו לבעיות תאימות עם פרוטוקולים.

שגיאות נפוצות

מס העברה: כל העברה לוקחת אחוז — שובר פרוטוקולי DeFi. אם עדיין צריך, השתמשו ב-whitelist לחוזי Uniswap, Aave, Compound. רשימה שחורה ריכוזית ללא timelock: רע לטוקנים קהילתיים. Reentrancy ב-transfer hooks: אם מוסיפים Ownable או import "@openzeppelin/contracts/access/AccessControl.sol"; contract MintableToken is ERC20, ERC20Burnable, ERC20Permit, AccessControl { bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE"); uint256 public immutable maxSupply; constructor( string memory name, string memory symbol, uint256 _maxSupply, address admin ) ERC20(name, symbol) ERC20Permit(name) { maxSupply = _maxSupply; _grantRole(DEFAULT_ADMIN_ROLE, admin); _grantRole(MINTER_ROLE, admin); } function mint(address to, uint256 amount) external onlyRole(MINTER_ROLE) { require(totalSupply() + amount <= maxSupply, "Exceeds max supply"); _mint(to, amount); } } , ודאו שאינכם קוראים לקוד חיצוני.

שלבי עבודה

אימות ופריסה

# Тесты
forge test -vvv

# Деплой с верификацией
forge script script/Deploy.s.sol \
  --rpc-url $RPC_URL \
  --private-key $PRIVATE_KEY \
  --broadcast \
  --verify \
  --etherscan-api-key $ETHERSCAN_KEY

לאחר הפריסה — אמתו את החוזה ב-Etherscan/Polygonscan. טוקן לא מאומת מעלה חשד לגיטימי מצד בורסות ומשתמשים.

מה כלול בפיתוח טוקן ERC-20 מפתח

• חוזה חכם ב-Solidity עם פונקציות מותאמות (mint, burn, permit, pause, blacklist)
• בדיקות יחידה (Foundry/Hardhat) עם כיסוי >90%
• סקריפטים לפריסה מוגדרים לרשת שלך (Ethereum, Polygon, Arbitrum, BNB Chain)
• אימות בסייר בלוקצ'יין (Etherscan, Polygonscan)
• תיעוד למפתחים ולמשתמשים
• ייעוץ לשילוב פרוטוקולי DeFi
• אחריות — חודש אחד של תיקונים חינם לאחר ההשקה

נעריך את הפרויקט שלך תוך יום עסקים אחד. אנחנו צוות של מפתחי בלוקצ'יין בכירים: 5+ שנים בשוק, 50+ טוקנים שנמסרו. צרו קשר כדי לדון בפרטים ולהזמין פיתוח טוקן ERC-20 מפתח.