פיתוח טוקן BEP-20 ברשת BNB Chain: מהרעיון ועד BscScan

תארו לעצמכם לקוח שאומר "רק טוקן BEP-20 פשוט, כמו של כולם." שבוע לאחר מכן, מתברר שהם צריכים minting עם תפקידים, burning, snapshots לאיירדרופים, ואישורים ללא גז באמצעות ERC20Permit. וכל זה חייב לרוץ על BSC עם עמלת עסקה של $0.01. נתקלנו בזה עשרות פעמים — ובכל פעם, חוזה כתוב היטב עם אופטימיזציית גז הציל את המצב.

בואו נפרק, באמצעות דוגמת חוזה אמיתית, איך ליישם את כל התכונות הללו ב-Solidity 0.8.x מבלי להיתקל במלכודות של אימות ואבטחה. BEP-20 על BSC מהיר פי 4 מ-ERC-20 על Ethereum (3 שניות לעומת 12 שניות) וזול פי 100 ($0.01 לעומת $1-50) — אבל רק אם החוזה כתוב נכון.

למה BEP-20 במקום ERC-20?

BEP-20 הוא הגרסה של BNB Chain ל-ERC-20. הממשק זהה, תואם ABI, הכלים זהים — Hardhat או Foundry עם שינויי תצורת רשת מינוריים. אם כבר פיתחתם טוקנים מסוג ERC-20, התאמה ל-BEP-20 לוקחת זמן מינימלי. ההבדל המרכזי: BNB Smart Chain (BSC) משתמשת ב-Proof of Staked Authority (PoSA) עם 21 מאמתים במקום אלפי צמתים של Ethereum. זה נותן בלוקים מהירים (3 שניות) ועסקאות זולות ($0.01–0.05 להעברה סטנדרטית), אבל במחיר של רשת מרכזית יותר.

אילו תכונות הטוקן שלכם באמת צריך?

טוקן בסיסי הוא 30 שורות מעל OpenZeppelin ERC20. השאלה היא לא "איך לכתוב טוקן," אלא "איזו פונקציונליות הפרויקט שלכם צריך?" רשימה טיפוסית:

• Minting ו-burning — היצע מבוקר באמצעות AccessControl
• אישורים ללא גז — ERC20Permit (EIP-2612) לחוויית משתמש
• הצבעה — ERC20Votes לממשל
• Snapshots — נעילת יתרות לאיירדרופים
• Anti-whale — הגבלת כמות עסקה מקסימלית

הנה דוגמת חוזה המשלב מספר הרחבות:

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

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol";

contract MyBEP20Token is ERC20, AccessControl, ERC20Permit, ERC20Votes {
    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
    uint256 public constant MAX_SUPPLY = 1_000_000_000 * 10**18; // 1B токенов

    constructor(address initialAdmin) ERC20("MyToken", "MTK") ERC20Permit("MyToken") {
        _grantRole(DEFAULT_ADMIN_ROLE, initialAdmin);
        _grantRole(MINTER_ROLE, initialAdmin);
    }

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

    function burn(uint256 amount) external {
        _burn(msg.sender, amount);
    }

    function _afterTokenTransfer(address from, address to, uint256 amount) internal override(ERC20, ERC20Votes) {
        super._afterTokenTransfer(from, to, amount);
    }

    function _mint(address to, uint256 amount) internal override(ERC20, ERC20Votes) {
        super._mint(to, amount);
    }

    function _burn(address account, uint256 amount) internal override(ERC20, ERC20Votes) {
        super._burn(account, amount);
    }
}

ניתן לשלב הרחבות נוספות. הטבלה שלהלן מפרטת את הפופולריות ביותר:

מה כלול בעבודה (תוצרים)

לאחר השלמת העבודה, תקבלו:

• קוד מקור של החוזה החכם עם הערות
• תוצאות ביקורת (דוחות Slither, Mythril, Echidna)
• תיעוד למשתמשים ולמפתחים
• גישה לארנק multisig לניהול תפקידים
• הוראות לאינטראקציה באמצעות ethers.js / viem
• תמיכה לאחר הפריסה (חודש של ייעוץ)

תהליך הפיתוח והבטחות

אנו משתמשים באימות פורמלי עם חוזי OpenZeppelin, כיסוי בדיקות של >95% לפונקציות מפתח, ניתוח סטטי עם Slither, ו-fuzzing עם Echidna. זה ממזער סיכונים של reentrancy, גלישה, ופגיעויות אחרות. לצוות שלנו שנים של ניסיון בפיתוח בלוקצ'יין, עם למעלה מ-20 פרויקטים מוצלחים, כולל טוקנים עם reflections ו-pools של staking.

שלבי פריסה

1. ניתוח — הסכמה על פונקציונליות, בחירת מחסנית (גרסת Solidity, הרחבות).
2. פיתוח — כתיבת חוזה עם אופטימיזציית גז ואבטחה בראש.
3. בדיקות — בדיקות יחידה + בדיקות אינטגרציה על testnet.
4. ביקורת — בדיקה עם Slither, Mythril, Echidna. תיקון באגים.
5. פריסה — ל-testnet, ולאחר מכן ל-mainnet עם multisig.
6. אימות — פתיחת קוד מקור ב-BscScan.
7. תיעוד — תיאור פונקציות וממשקים למשתמשים.

ציר זמן: 3 עד 5 ימי עסקים לטוקן סטנדרטי ללא לוגיקה אקזוטית. צרו קשר — נבדוק את הפרויקט שלכם תוך יום אחד.

טעויות נפוצות של מתחילים

רבים שוכחים להשתמש ב-// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; import "@openzeppelin/contracts/access/AccessControl.sol"; import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol"; import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol"; contract MyBEP20Token is ERC20, AccessControl, ERC20Permit, ERC20Votes { bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE"); uint256 public constant MAX_SUPPLY = 1_000_000_000 * 10**18; // 1B токенов constructor(address initialAdmin) ERC20("MyToken", "MTK") ERC20Permit("MyToken") { _grantRole(DEFAULT_ADMIN_ROLE, initialAdmin); _grantRole(MINTER_ROLE, initialAdmin); } function mint(address to, uint256 amount) external onlyRole(MINTER_ROLE) { require(totalSupply() + amount <= MAX_SUPPLY, "Exceeds max supply"); _mint(to, amount); } function burn(uint256 amount) external { _burn(msg.sender, amount); } function _afterTokenTransfer(address from, address to, uint256 amount) internal override(ERC20, ERC20Votes) { super._afterTokenTransfer(from, to, amount); } function _mint(address to, uint256 amount) internal override(ERC20, ERC20Votes) { super._mint(to, amount); } function _burn(address account, uint256 amount) internal override(ERC20, ERC20Votes) { super._burn(account, amount); } } , מה שהופך את ה-minting לזמין לכולם. לעיתים קרובות AccessControl מושמט — משתמשים צריכים לשלם גז על כל אישור. לפעמים החוזה לא מאומת ב-BscScan, מה שגורם לטוקן להיראות חשוד. חלק לא מגבילים היצע מקסימלי — אינפלציה הורגת את המחיר. ולבסוף, שימוש ב-ERC20Permit במקום transfer בחוזי צד שלישי מוביל להפסדים.

הימנעות מהמלכודות הללו חוסכת זמן וכסף. בפרויקט אחד, אופטימיזציית גז הפחיתה הוצאות עמלות ב-$3,000 לחודש. תקננו את התהליך — כל טוקן עובר את אותה סדרת בדיקות. הזמינו פיתוח — קבלו חוזה מוכן עם תיעוד מלא.

ספריית OpenZeppelin: https://github.com/OpenZeppelin/openzeppelin-contracts