راهنمای ساخت توکن و استانداردهای ERC و BEP

راهنمای جامع ساخت توکن و استانداردهای ERC و BEP؛ از طراحی تا توسعه، آزمایش و استقرار

ساخت توکن روی شبکه‌های بلاکچینی، با توسعه ابزارهای استاندارد و قراردادهای هوشمند، از نظر فنی ساده‌تر از گذشته شده است. بااین‌حال، ایجاد یک توکن قابل اتکا صرفاً به انتخاب نام، نماد و تعداد واحدهای آن محدود نمی‌شود. توسعه‌دهندگان باید استاندارد مناسب، معماری قرارداد هوشمند، قواعد عرضه، سطوح دسترسی، امنیت، هزینه‌های شبکه و الزامات حقوقی را بررسی کنند.

استانداردهای ERC در اکوسیستم اتریوم و BEP در اکوسیستم BNB Chain از مهم‌ترین چارچوب‌های فنی این حوزه هستند. استانداردهایی مانند ERC-20، ERC-721، ERC-1155 و BEP-20 امکان طراحی انواع مختلف توکن را فراهم می‌کنند.

این مقاله با رویکرد آموزشی و اجرایی، مراحل ساخت توکن، تفاوت استانداردها، نمونه کدنویسی، روش آزمایش و استقرار، خطاهای متداول و الزامات راه‌اندازی حرفه‌ای را بررسی می‌کند.

۱. ساخت توکن دقیقاً به چه معناست؟

ساخت توکن به معنای تعریف یک دارایی یا واحد دیجیتال مطابق قواعد یک شبکه بلاکچینی است.

در شبکه‌های سازگار با ماشین مجازی اتریوم (EVM)، بسیاری از توکن‌ها از طریق قرارداد هوشمند ایجاد می‌شوند.

این قرارداد مشخص می‌کند:

• چه تعداد توکن وجود دارد.

• چه کسی مالک هر مقدار از توکن است.

• انتقال توکن چگونه انجام می‌شود.

• آیا ایجاد واحد جدید مجاز است.

• آیا توکن قابل سوزاندن است.

• چه کسانی اختیار اجرای عملیات مدیریتی دارند.

برای ساخت توکن معمولاً نیازی به ایجاد بلاکچین اختصاصی نیست. می‌توان قرارداد هوشمند را روی شبکه موجود مستقر کرد.

بااین‌حال، ایجاد قرارداد توکن به معنای ایجاد بازار، تضمین قیمت، دریافت مجوز مالی یا ایجاد حق مالکیت قانونی نیست.

۲. تفاوت کوین بومی و توکن قراردادی

کوین بومی معمولاً دارایی اصلی یک شبکه است که در سطح پروتکل تعریف می‌شود.

برای مثال، ETH دارایی بومی اتریوم و BNB دارایی بومی BNB Smart Chain است.

در مقابل، یک توکن ERC-20 معمولاً با قرارداد هوشمند روی شبکه اتریوم یا شبکه سازگار با EVM ایجاد می‌شود.

بنابراین توسعه یک توکن جدید لزوماً به معنای ایجاد یک شبکه جدید یا تغییر پروتکل اصلی نیست.

۳. استاندارد توکن چیست و چرا اهمیت دارد؟

استاندارد توکن مجموعه‌ای از قواعد و رابط‌های فنی است که نحوه تعامل برنامه‌ها با توکن را مشخص می‌کند.

این قواعد به کیف پول‌ها، صرافی‌ها، برنامه‌های غیرمتمرکز و سایر قراردادهای هوشمند کمک می‌کنند تا بدون نیاز به طراحی اختصاصی برای هر توکن، با آن تعامل کنند.

برای مثال، اگر یک توکن از رابط ERC-20 پیروی کند، برنامه‌های سازگار می‌توانند از روش‌های استاندارد برای بررسی موجودی و انتقال آن استفاده کنند.

اما استاندارد بودن یک توکن به‌تنهایی تضمین‌کننده امنیت، اعتبار ناشر یا ارزش اقتصادی نیست.

۴. استاندارد ERC چیست؟

ERC مخفف Ethereum Request for Comments است و به دسته‌ای از پیشنهادهای استاندارد در اکوسیستم اتریوم اشاره دارد.

استانداردهای ERC می‌توانند قواعد مشترکی برای توکن‌ها، قراردادهای هوشمند و تعامل برنامه‌ها تعریف کنند.

استانداردهای مهم

هر استاندارد برای مسئله متفاوتی طراحی شده است و انتخاب آن باید بر اساس نیاز پروژه انجام شود.

۵. استاندارد ERC-20 چیست؟

ERC-20 یکی از شناخته‌شده‌ترین استانداردهای توکن قابل‌تعویض است.

در این استاندارد، واحدهای یک توکن از نظر قواعد تعریف‌شده یکسان هستند.

توابع اصلی

totalSupply: مقدار کل توکن‌های موجود را گزارش می‌کند.

balanceOf: موجودی یک نشانی را مشخص می‌کند.

transfer: مقدار مشخصی توکن را منتقل می‌کند.

approve: اجازه مصرف مقدار مشخصی توکن را به نشانی دیگری می‌دهد.

allowance: مقدار مجوز مصرف باقی‌مانده را گزارش می‌کند.

transferFrom: انتقال توکن از طرف دارنده را در محدوده مجوز امکان‌پذیر می‌کند.

رویدادها

دو رویداد اصلی این استاندارد عبارت‌اند از:

• Transfer

• Approval

این رویدادها برای ثبت و رهگیری عملیات قرارداد اهمیت دارند.

۶. استاندارد ERC-721 چیست؟

ERC-721 برای توکن‌های غیرقابل‌تعویض طراحی شده است.

هر توکن شناسه مشخصی دارد و می‌تواند نماینده یک دارایی یا گواهی متمایز باشد.

کاربردهای احتمالی

• گواهی دیجیتال آثار هنری

• شناسه دارایی

• مجوز دیجیتال

• اقلام منحصربه‌فرد در بازی‌ها

• گواهی عضویت

نکته مهم

ایجاد NFT به‌تنهایی مالکیت حقوق مؤلف، اصالت اثر یا مالکیت فیزیکی دارایی را اثبات نمی‌کند.

این موضوعات باید از طریق قراردادها و سازوکارهای معتبر مشخص شوند.

۷. استاندارد ERC-1155 چیست؟

ERC-1155 امکان مدیریت چند شناسه توکن در یک قرارداد را فراهم می‌کند.

این شناسه‌ها می‌توانند برای واحدهای هم‌نوع یا دارایی‌های منحصربه‌فرد استفاده شوند.

مثال

فرض کنید یک پلتفرم آموزشی سه نوع دارایی دیجیتال دارد:

۱. اعتبار مصرفی دوره‌ها

۲. گواهی‌های اختصاصی

۳. اقلام دیجیتال محدود

در بعضی طراحی‌ها، ERC-1155 می‌تواند مدیریت این مجموعه را در یک قرارداد امکان‌پذیر کند.

مزیت احتمالی

پشتیبانی از عملیات دسته‌ای می‌تواند در برخی سناریوها هزینه تعاملات را کاهش دهد.

اما انتخاب ERC-1155 باید با بررسی سازگاری کیف پول‌ها، بازارها و نیازهای پروژه انجام شود.

۸. استاندارد BEP چیست؟

BEP مخفف BNB Evolution Proposal است.

این پیشنهادها استانداردها و تغییرات مرتبط با اکوسیستم BNB Chain را توصیف می‌کنند.

یکی از مهم‌ترین آن‌ها BEP-20 است که برای توکن‌های BNB Smart Chain طراحی شده است.

تفاوت مهم BEP-2 و BEP-20

BEP-2 مربوط به BNB Beacon Chain بود؛ شبکه‌ای که در چارچوب تحول اکوسیستم BNB Chain از چرخه فعالیت خارج شده است.

BEP-20 مربوط به BNB Smart Chain است.

بنابراین برای آموزش ساخت توکن جدید روی BNB Smart Chain، تمرکز اصلی باید بر BEP-20 باشد، نه BEP-2.

۹. استاندارد BEP-20 چیست؟

BEP-20 رابطی استاندارد برای توکن‌های قابل‌تعویض روی BNB Smart Chain تعریف می‌کند.

این استاندارد از ERC-20 الهام گرفته و بسیاری از توابع اصلی آن را حفظ کرده است.

به همین دلیل، توسعه‌دهندگانی که با Solidity و ERC-20 آشنا هستند، می‌توانند بخش مهمی از دانش خود را در BNB Smart Chain نیز به کار بگیرند.

بااین‌حال، پیروی از ERC-20 به‌تنهایی به معنای رعایت همه جزئیات مشخصات BEP-20 نیست؛ سازگاری باید با مستندات رسمی و آزمایش قرارداد تأیید شود.

۱۰. مقایسه ERC-20 و BEP-20

هزینه تراکنش و سرعت تأیید در دو شبکه یکسان نیست و به شرایط شبکه و نوع عملیات بستگی دارد.

انتخاب شبکه صرفاً بر اساس ارزان‌تر بودن کارمزد، تصمیم کاملی نیست.

۱۱. پیش‌نیازهای ساخت توکن

برای شروع توسعه، چند پیش‌نیاز ضروری وجود دارد.

دانش فنی

آشنایی مقدماتی با قرارداد هوشمند، Solidity، کیف پول و تراکنش‌های بلاکچینی.

کیف پول توسعه

کیف پول سازگار با شبکه هدف برای امضای تراکنش‌های استقرار و آزمایش.

محیط توسعه

ابزارهایی مانند Remix، Hardhat یا Foundry.

کتابخانه استاندارد

استفاده از پیاده‌سازی‌های معتبر مانند OpenZeppelin Contracts.

شبکه آزمایشی

برای آزمون قرارداد پیش از استقرار روی شبکه اصلی.

دارایی کارمزد

مقدار لازم از دارایی بومی شبکه آزمایشی یا اصلی.

مستندات پروژه

تعریف دقیق نام، نماد، عرضه، حقوق کاربران و اختیارات مدیریتی.

۱۲. انتخاب معماری توکن

پیش از کدنویسی باید مشخص شود:

• توکن قابل‌تعویض است یا غیرقابل‌تعویض؟

• عرضه ثابت دارد یا متغیر؟

• چه کسی می‌تواند توکن جدید ایجاد کند؟

• آیا امکان سوزاندن وجود دارد؟

• آیا انتقال محدود می‌شود؟

• آیا قرارداد قابل ارتقاست؟

• چه کسی اختیارات مدیریتی را در اختیار دارد؟

• آیا توکن نماینده حقوق مالی یا قانونی است؟

این تصمیم‌ها باید در سند مشخصات فنی و اقتصادی پروژه ثبت شوند.

۱۳. آموزش ساخت یک توکن ساده ERC-20

برای آموزش، یک توکن فرضی با نام Example Learning Token و نماد ELT در نظر می‌گیریم.

ویژگی‌های نمونه:

• عرضه اولیه: یک میلیون واحد

• تعداد اعشار: ۱۸

• عرضه ثابت پس از استقرار

• بدون قابلیت ایجاد واحد جدید

• بدون قابلیت توقف انتقال

• بدون مالیات تراکنش

• بدون امکان مسدودسازی توسط مدیر

این طراحی برای یادگیری مناسب است، اما به معنای آمادگی برای استفاده مالی واقعی نیست.

نمونه قرارداد Solidity

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

import {
    ERC20
} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract ExampleLearningToken is ERC20 {
    constructor() ERC20("Example Learning Token", "ELT") {
        _mint(msg.sender, 1_000_000 * 10 ** decimals());
    }
}

توضیح کد

pragma solidity: محدوده نسخه کامپایلر را مشخص می‌کند.

import: پیاده‌سازی استاندارد ERC-20 را از کتابخانه OpenZeppelin وارد می‌کند.

contract: قرارداد توکن را تعریف می‌کند.

constructor: هنگام استقرار قرارداد اجرا می‌شود.

ERC20: نام و نماد توکن را مقداردهی می‌کند.

_mint: عرضه اولیه را ایجاد و به نشانی مستقرکننده اختصاص می‌دهد.

در این نمونه، تابع عمومی برای ایجاد توکن جدید تعریف نشده است؛ بنابراین پس از استقرار، قرارداد مسیر معمولی برای افزایش عرضه ندارد.

همچنین مقدار یک میلیون واحد با درنظرگرفتن ۱۸ رقم اعشار به کوچک‌ترین واحدهای توکن تبدیل می‌شود.

۱۴. چرا استفاده از OpenZeppelin توصیه می‌شود؟

کتابخانه OpenZeppelin مجموعه‌ای از قراردادهای قابل استفاده مجدد را برای استانداردهای شناخته‌شده ارائه می‌کند.

استفاده از کتابخانه معتبر می‌تواند نیاز به پیاده‌سازی دستی بخش‌های پیچیده را کاهش دهد.

اما چند نکته ضروری است:

• از نسخه مشخص و معتبر کتابخانه استفاده شود.

• وابستگی‌ها در پروژه ثبت شوند.

• کد اختصاصی جداگانه آزمایش شود.

• تغییرات غیرضروری در پیاده‌سازی استاندارد انجام نشود.

• برای کاربردهای حساس، بررسی امنیتی مستقل صورت گیرد.

استفاده از OpenZeppelin به‌تنهایی تضمین نمی‌کند که قرارداد نهایی بدون آسیب‌پذیری باشد.

۱۵. ساخت توکن بدون نوشتن دستی قرارداد

یکی از ابزارهای آموزشی و توسعه‌ای، OpenZeppelin Contracts Wizard است.

این ابزار امکان انتخاب استاندارد و ویژگی‌های قرارداد را فراهم می‌کند و کد اولیه تولید می‌کند.

مراحل کلی

۱. ورود به ابزار Contracts Wizard

۲. انتخاب ERC-20

۳. تعیین نام و نماد

۴. تعیین قواعد عرضه

۵. انتخاب قابلیت‌های موردنیاز

۶. بررسی کد تولیدشده

۷. انتقال کد به محیط توسعه

۸. کامپایل و آزمایش

۹. استقرار آزمایشی

۱۰. بررسی امنیت و مستندات

کد تولیدشده باید پیش از استقرار واقعی بررسی شود. استفاده از ابزار تولید کد جایگزین تحلیل فنی و امنیتی نیست.

۱۶. آموزش استقرار آزمایشی با Remix

Remix یک محیط توسعه تحت وب برای قراردادهای هوشمند Solidity است.

مرحله اول: آماده‌سازی کد

یک فایل Solidity ایجاد و کد قرارداد را در آن قرار دهید.

مرحله دوم: انتخاب کامپایلر

نسخه‌ای از کامپایلر انتخاب شود که با محدوده تعریف‌شده در قرارداد و وابستگی‌ها سازگار باشد.

مرحله سوم: کامپایل

قرارداد را کامپایل و خطاهای احتمالی را بررسی کنید.

مرحله چهارم: آزمایش محلی

ابتدا از محیط شبیه‌سازی‌شده Remix برای استقرار و تعامل استفاده کنید.

مرحله پنجم: اتصال کیف پول آزمایشی

پس از آزمون محلی، کیف پول را به شبکه آزمایشی موردنظر متصل کنید.

مرحله ششم: استقرار

قرارداد را با حساب آزمایشی مستقر کنید.

مرحله هفتم: بررسی

آدرس قرارداد، تراکنش استقرار و مقدار عرضه را ثبت و بررسی کنید.

مرحله هشتم: انتقال آزمایشی

مقدار محدودی توکن میان دو نشانی آزمایشی منتقل کنید.

این مراحل باید با رعایت امنیت کیف پول انجام شوند. عبارت بازیابی و کلید خصوصی نباید در وب‌سایت‌ها یا ابزارهای ناشناس وارد شوند.

۱۷. ساخت توکن BEP-20 روی BNB Smart Chain

BNB Smart Chain از محیط اجرایی سازگار با EVM پشتیبانی می‌کند.

در نتیجه، بسیاری از ابزارهای توسعه Solidity برای این شبکه نیز قابل استفاده‌اند.

مراحل کلی

۱. انتخاب BNB Smart Chain به‌عنوان شبکه هدف

۲. بررسی مشخصات رسمی BEP-20

۳. طراحی قرارداد سازگار

۴. کامپایل قرارداد

۵. استقرار در محیط آزمایشی BSC

۶. بررسی توابع و رویدادها

۷. آزمون انتقال و مجوز مصرف

۸. بررسی امنیت

۹. تأیید کد قرارداد در مرورگر بلاکچین

۱۰. تصمیم‌گیری درباره استقرار اصلی

نکته فنی

هرچند ERC-20 و BEP-20 بسیار شبیه‌اند، نباید بدون بررسی مشخصات رسمی، یک قرارداد را صرفاً به دلیل اجراشدن روی BSC کاملاً منطبق با BEP-20 دانست.

۱۸. تفاوت استقرار روی شبکه آزمایشی و اصلی

شبکه آزمایشی برای توسعه و بررسی عملکرد استفاده می‌شود.

توکن‌های آزمایشی معمولاً ارزش اقتصادی واقعی ندارند و برای شبیه‌سازی عملیات به کار می‌روند.

شبکه اصلی محیط واقعی ثبت تراکنش‌هاست و استقرار قرارداد در آن می‌تواند پیامدهای مالی و عملیاتی داشته باشد.

توصیه اجرایی

هیچ قرارداد توکنی نباید صرفاً پس از یک کامپایل موفق روی شبکه اصلی مستقر شود.

پیش از استقرار اصلی باید آزمون‌ها، بررسی امنیت، ارزیابی حقوقی و تأیید مشخصات پروژه انجام شده باشد.

۱۹. آزمون‌های ضروری قرارداد توکن

آزمون عرضه

آیا مقدار عرضه اولیه درست است؟

آزمون انتقال

آیا انتقال موجودی میان حساب‌ها مطابق انتظار انجام می‌شود؟

آزمون موجودی ناکافی

آیا انتقال بیش از موجودی رد می‌شود؟

آزمون مجوز مصرف

آیا approve و transferFrom مطابق قواعد عمل می‌کنند؟

آزمون رویدادها

آیا رویدادهای Transfer و Approval به‌درستی منتشر می‌شوند؟

آزمون اختیارات

آیا کاربران غیرمجاز از اجرای عملیات مدیریتی منع می‌شوند؟

آزمون شرایط مرزی

آیا قرارداد در مقادیر صفر، مقادیر بزرگ و شرایط غیرمعمول درست رفتار می‌کند؟

آزمون یکپارچگی

آیا قرارداد با کیف پول‌ها و برنامه‌های موردنظر سازگار است؟

۲۰. قابلیت Mint و Burn

Mint چیست؟

Mint به معنای ایجاد واحدهای جدید توکن است.

اگر پروژه به عرضه متغیر نیاز داشته باشد، باید قواعد ایجاد واحد جدید به‌روشنی تعریف شوند.

Burn چیست؟

Burn به معنای کاهش عرضه توکن از طریق سازوکار تعریف‌شده در قرارداد است.

ریسک مهم

اگر اختیار ایجاد توکن بدون محدودیت در اختیار یک حساب قرار گیرد، دارندگان ممکن است با ریسک افزایش عرضه مواجه شوند.

در مقابل، محدود کردن عرضه نیز به‌تنهایی تضمین‌کننده ارزش اقتصادی توکن نیست.

۲۱. مدیریت اختیارات قرارداد

در قراردادهای پیچیده ممکن است نقش‌های مدیریتی تعریف شوند.

برای مثال:

• مدیر صدور

• مدیر توقف اضطراری

• مدیر ارتقا

• مدیر تنظیم پارامترها

هر اختیار مدیریتی باید توجیه مشخصی داشته باشد.

اصل حداقل دسترسی

هر حساب باید فقط اختیارات ضروری برای انجام وظیفه خود را داشته باشد.

استفاده از چندامضایی

در بعضی پروژه‌ها، کیف پول چندامضایی می‌تواند وابستگی به یک کلید مدیریتی را کاهش دهد.

اما چندامضایی نیز جایگزین سیاست‌های امنیتی و حاکمیتی مناسب نیست.

۲۲. قرارداد قابل ارتقا یا غیرقابل ارتقا؟

در طراحی غیرقابل ارتقا، منطق قرارداد مستقرشده معمولاً قابل تغییر مستقیم نیست.

در طراحی قابل ارتقا، سازوکارهایی مانند قرارداد واسط ممکن است امکان تغییر منطق اجرایی را فراهم کنند.

مزایای احتمالی ارتقا

• اصلاح خطا

• افزودن قابلیت

• سازگاری با نیازهای جدید

ریسک‌ها

• تمرکز اختیار

• تغییر غیرمنتظره رفتار قرارداد

• خطا در سازگاری داده‌ها

• آسیب‌پذیری سازوکار ارتقا

انتخاب این معماری باید پیش از توسعه انجام شود.

۲۳. امنیت قراردادهای توکن

ساخت توکن حرفه‌ای بدون ارزیابی امنیتی کامل نیست.

مهم‌ترین حوزه‌های بررسی عبارت‌اند از:

کنترل دسترسی: چه کسی اختیار اجرای عملیات حساس را دارد؟

مدیریت مجوزها: آیا کاربران ممکن است به قراردادهای دیگر مجوز بیش از نیاز بدهند؟

وابستگی خارجی: آیا قرارداد به اوراکل، پل میان‌زنجیره‌ای یا سامانه دیگری وابسته است؟

قابلیت ارتقا: چه کسی می‌تواند منطق قرارداد را تغییر دهد؟

مدیریت کلید: کلیدهای مدیریتی چگونه محافظت می‌شوند؟

آزمون و حسابرسی: آیا سناریوهای شکست بررسی شده‌اند؟

پایش: آیا رخدادهای غیرعادی قابل شناسایی هستند؟

۲۴. اشتباهات رایج در ساخت توکن

اشتباه اول: استفاده از کد ناشناس

کپی‌کردن قرارداد از منابع نامعتبر می‌تواند خطرناک باشد.

اشتباه دوم: تعریف اختیار نامحدود برای مدیر

اختیارات نامحدود ممکن است اعتماد کاربران را کاهش دهد.

اشتباه سوم: استقرار بدون آزمایش

کامپایل موفق به معنای عملکرد صحیح نیست.

اشتباه چهارم: بی‌توجهی به مجوزهای انتقال

مدیریت نادرست allowance می‌تواند خطرات امنیتی ایجاد کند.

اشتباه پنجم: انتخاب شبکه فقط بر اساس کارمزد

امنیت، زیرساخت و جامعه کاربران نیز اهمیت دارند.

اشتباه ششم: وعده سود یا قیمت تضمینی

وجود توکن، تضمینی برای بازدهی اقتصادی ایجاد نمی‌کند.

اشتباه هفتم: نبود مستندات حقوقی

حقوق دارندگان و مسئولیت ناشر باید روشن باشد.

۲۵. چگونه توکن در کیف پول نمایش داده می‌شود؟

پس از استقرار قرارداد، ممکن است کیف پول به‌صورت خودکار توکن را شناسایی نکند.

در این حالت، کاربر ممکن است نیاز داشته باشد نشانی قرارداد و شبکه صحیح را به کیف پول معرفی کند.

اطلاعات مهم

• شبکه

• نشانی قرارداد

• نماد توکن

• تعداد اعشار

هشدار

نام و نماد توکن منحصربه‌فرد نیستند.

برای تشخیص توکن باید نشانی قرارداد را از منبع معتبر بررسی کرد.

۲۶. تأیید کد قرارداد در مرورگر بلاکچین

مرورگرهای بلاکچین امکان مشاهده تراکنش‌ها و اطلاعات قرارداد را فراهم می‌کنند.

در بسیاری از شبکه‌ها، توسعه‌دهنده می‌تواند کد منبع قرارداد را برای تطبیق با کد مستقرشده تأیید کند.

اهمیت تأیید کد

• افزایش قابلیت بررسی عمومی

• تسهیل تحلیل فنی

• کمک به شناسایی توابع قرارداد

• بهبود شفافیت عملیاتی

اما تأیید کد به معنای حسابرسی امنیتی یا تأیید اعتبار اقتصادی پروژه نیست.

۲۷. هزینه‌های واقعی ساخت توکن

هزینه ساخت توکن تنها شامل کارمزد استقرار نیست.

هزینه‌های پروژه می‌تواند شامل موارد زیر باشد:

• تحلیل کسب‌وکار

• طراحی توکنومیکس

• توسعه قرارداد

• آزمون

• حسابرسی امنیتی

• مشاوره حقوقی

• طراحی کیف پول و رابط کاربری

• مستندسازی

• پشتیبانی

• پایش امنیت

• مدیریت عملیات

در پروژه‌های ساده آموزشی، هزینه فنی ممکن است محدود باشد.

اما پروژه‌ای که حقوق مالی واقعی یا دارایی کاربران را مدیریت می‌کند، به سطح بسیار بالاتری از کنترل نیاز دارد.

۲۸. آیا توکن پس از ساخت قابل معامله می‌شود؟

ایجاد توکن به‌تنهایی باعث ایجاد بازار معاملاتی نمی‌شود.

برای معامله، باید زیرساخت، طرف معامله، نقدشوندگی و شرایط قانونی مناسب وجود داشته باشد.

همچنین پذیرش توکن در یک صرافی یا پلتفرم معاملاتی به تصمیم و الزامات آن مجموعه وابسته است.

نکته مهم

قابلیت انتقال فنی توکن با امکان معامله قانونی و نقدشوندگی اقتصادی تفاوت دارد.

۲۹. الزامات حقوقی ساخت و عرضه توکن

ساخت فنی یک قرارداد هوشمند و عرضه اقتصادی آن دو فعالیت متفاوت‌اند.

در برخی حوزه‌های قضایی، عرضه توکن ممکن است مشمول مقررات مربوط به دارایی‌های رمزنگاری‌شده، خدمات مالی یا اوراق بهادار باشد.

در اتحادیه اروپا، مقررات MiCA برای بخش‌هایی از بازار دارایی‌های رمزنگاری‌شده چارچوب مشخصی تعریف کرده است.

در ایران نیز وضعیت حقوقی هر پروژه باید بر اساس آخرین مقررات و ماهیت واقعی فعالیت بررسی شود.

بنابراین نباید از امکان فنی ایجاد توکن، مجاز بودن فروش عمومی یا جذب سرمایه را نتیجه گرفت.

۳۰. مطالعه موردی: توکن آموزشی برای یک پلتفرم فرهنگی

فرض کنیم پلتفرمی فرهنگی قصد دارد واحد دیجیتالی برای دسترسی به خدمات آموزشی ایجاد کند.

نیاز اولیه

کاربران بتوانند اعتبار مشخصی دریافت و برای استفاده از خدمات مصرف کنند.

گزینه اول: پایگاه داده متمرکز

اگر خدمات تنها در یک سامانه ارائه می‌شوند، اعتبار متمرکز ممکن است کافی باشد.

گزینه دوم: ERC-20

اگر انتقال اعتبار میان چند برنامه مستقل ضروری باشد، توکن قابل‌تعویض می‌تواند بررسی شود.

گزینه سوم: ERC-721

اگر هدف صدور گواهی دیجیتال منحصربه‌فرد برای هر دوره باشد، ERC-721 ممکن است مناسب‌تر باشد.

گزینه چهارم: ERC-1155

اگر سامانه انواع مختلف اعتبار و گواهی را مدیریت کند، ERC-1155 می‌تواند یکی از گزینه‌ها باشد.

نتیجه

انتخاب استاندارد باید بر اساس ماهیت دارایی و نیاز کاربران انجام شود.

همچنین برای گواهی‌های غیرقابل‌انتقال، باید محدودیت انتقال و الزامات اعتبارسنجی جداگانه طراحی شوند.

۳۱. نقشه راه حرفه‌ای ساخت توکن

مرحله اول: تحلیل نیاز

تعریف مسئله، کاربران و کارکرد اقتصادی.

مرحله دوم: بررسی ضرورت توکن

مقایسه با راهکارهای متمرکز و بدون توکن.

مرحله سوم: انتخاب استاندارد

بررسی ERC-20، ERC-721، ERC-1155 یا BEP-20.

مرحله چهارم: طراحی مشخصات

تعیین عرضه، اختیارات، محدودیت‌ها و حقوق کاربران.

مرحله پنجم: توسعه قرارداد

استفاده از کتابخانه‌های معتبر و نسخه‌های مشخص.

مرحله ششم: آزمون خودکار

بررسی رفتار عادی و شرایط شکست.

مرحله هفتم: استقرار آزمایشی

اجرای قرارداد در محیط کنترل‌شده.

مرحله هشتم: ارزیابی امنیت

بازبینی کد، آزمون و در صورت نیاز حسابرسی مستقل.

مرحله نهم: بررسی حقوقی

تعیین الزامات صدور، انتقال و عرضه.

مرحله دهم: استقرار اصلی

استقرار با فرایند کنترل‌شده و ثبت مستندات.

مرحله یازدهم: پایش و پشتیبانی

نظارت بر رخدادها، مدیریت کلیدها و پاسخ‌گویی به کاربران.

۳۲. پرسش‌های متداول

آیا ساخت توکن بدون برنامه‌نویسی ممکن است؟

ابزارهای تولید قرارداد می‌توانند فرایند ایجاد کد را ساده کنند؛ اما برای پروژه واقعی همچنان به بررسی فنی و امنیتی نیاز است.

آیا برای ساخت ERC-20 باید بلاکچین اختصاصی داشت؟

خیر. می‌توان آن را روی اتریوم یا شبکه‌های سازگار مستقر کرد.

آیا ERC-20 و BEP-20 یکسان‌اند؟

خیر. شباهت زیادی دارند، اما استانداردهای متعلق به اکوسیستم‌های متفاوت هستند و جزئیات انطباق باید بررسی شود.

آیا می‌توان یک توکن را هم‌زمان روی اتریوم و BSC داشت؟

می‌توان قراردادهای متناظر یا سازوکارهای میان‌زنجیره‌ای طراحی کرد؛ اما وجود توکن روی دو شبکه به‌تنهایی به معنای یکپارچگی عرضه یا قابلیت انتقال مستقیم نیست.

آیا می‌توان عرضه توکن را بعداً تغییر داد؟

به طراحی قرارداد بستگی دارد. اگر قابلیت ایجاد یا سوزاندن توکن پیش‌بینی نشده باشد، تغییر عرضه ممکن است امکان‌پذیر نباشد.

آیا قرارداد هوشمند پس از استقرار قابل اصلاح است؟

به معماری بستگی دارد. قراردادهای غیرقابل ارتقا معمولاً امکان تغییر مستقیم منطق را ندارند.

آیا هر توکن ERC-20 معتبر است؟

خیر. رعایت استاندارد فنی به معنای اعتبار اقتصادی، حقوقی یا امنیتی نیست.

آیا ساخت توکن به معنای امکان فروش آن است؟

خیر. فروش یا عرضه عمومی ممکن است الزامات قانونی جداگانه داشته باشد.

جمع‌بندی

ساخت توکن روی شبکه‌های بلاکچینی از نظر فنی در دسترس‌تر شده است، اما طراحی و راه‌اندازی حرفه‌ای آن نیازمند مجموعه‌ای از تصمیم‌های فنی، اقتصادی، امنیتی و حقوقی است.

استانداردهای ERC-20، ERC-721، ERC-1155 و BEP-20 ابزارهایی برای پیاده‌سازی انواع توکن فراهم می‌کنند، اما هیچ استانداردی به‌تنهایی موفقیت یک پروژه را تضمین نمی‌کند.

برای پروژه‌های آموزشی، استفاده از قرارداد ساده، کتابخانه معتبر و شبکه آزمایشی مناسب است.

برای پروژه‌های تجاری، باید طراحی حقوق، توکنومیکس، کنترل دسترسی، امنیت، تجربه کاربری و عملیات پشتیبانی نیز تکمیل شود.

اصل راهبردی: ساخت توکن یک فعالیت فنی است؛ ایجاد یک اکوسیستم توکنی پایدار، یک مسئله جامع کسب‌وکار، فناوری و حکمرانی است.

منابع تخصصی

۱. Ethereum — Token Standards
https://ethereum.org/developers/docs/standards/tokens/

۲. ERC-20: Token Standard
https://eips.ethereum.org/EIPS/eip-20

۳. ERC-721: Non-Fungible Token Standard
https://eips.ethereum.org/EIPS/eip-721

۴. ERC-1155: Multi Token Standard
https://eips.ethereum.org/EIPS/eip-1155

۵. BNB Chain — BEP-20 Specification
https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP20.md

۶. OpenZeppelin Contracts
https://docs.openzeppelin.com/contracts/5.x

۷. OpenZeppelin Contracts Wizard
https://wizard.openzeppelin.com/

۸. OpenZeppelin — Developing Smart Contracts
https://docs.openzeppelin.com/contracts/5.x/learn

۹. Remix IDE
https://remix.ethereum.org/

۱۰. European Union — MiCA Regulation
https://eur-lex.europa.eu/eli/reg/2023/1114/oj

یادداشت تحریریه: کد ارائه‌شده نمونه آموزشی است و پیش از استفاده در پروژه واقعی باید با نسخه مشخص وابستگی‌ها کامپایل، آزمایش و از نظر امنیتی بررسی شود. این مقاله مجوز یا توصیه‌ای برای عرضه عمومی و فروش توکن محسوب نمی‌شود.