قرارداد هوشمند و Web3: راهنمای کامل ساخت DEX و CEX برای کسب‌وکارهای ایرانی و بین‌المللی

قرارداد هوشمند یک برنامه کوچک است که روی یک بلاکچین مثل اتریوم مستقر می‌شود. هر کس می‌تواند توابع آن را صدا بزند و نتیجه را همه گره‌های شبکه تأیید می‌کنند. مثال ساده: قراردادی که می‌گوید «اگر خریدار مبلغ را واریز کرد، توکن به او منتقل شود». این منطق بدون نیاز به شرکت، بانک یا وکیل اجرا می‌شود.

اما چند تصور غلط رایج وجود دارد. قرارداد هوشمند «هوشمند» به معنای هوش مصنوعی نیست؛ فقط کدی است که دقیقاً همان چیزی را انجام می‌دهد که نوشته شده، چه درست باشد و چه اشتباه. همچنین «قرارداد» به معنای حقوقی کلمه نیست و بدون چارچوب قانونی، خودبه‌خود قابل پیگیری قضایی نیست. و مهم‌تر از همه: اگر قراردادی مستقر شد، تغییر آن سخت یا غیرممکن است. اشتباه در کد، یعنی اشتباه در پولی که دست آن کد است.

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

اکثر پروژه‌ها از شبکه‌های سازگار با EVM شروع می‌کنند، چون ابزارها، کتابخانه‌ها و توسعه‌دهندگان بیشتری دارند. زبان اصلی آن‌ها Solidity است و ابزارهای رایج برای تست و استقرار، Hardhat و Foundry هستند. کتابخانه‌هایی مثل OpenZeppelin پیاده‌سازی‌های بازبینی‌شده استانداردهایی مثل ERC-20 را در اختیار می‌گذارند و بهتر است به‌جای نوشتن از صفر، از همین‌ها استفاده شود.

انتخاب شبکه به هزینه تراکنش، سرعت و مخاطب بستگی دارد. اتریوم اصلی امنیت و اعتبار بالایی دارد اما کارمزد آن در زمان شلوغی بالا می‌رود. شبکه‌های لایه دوم مثل Arbitrum، Optimism و Base کارمزد کمتری دارند و همچنان به امنیت اتریوم تکیه می‌کنند. TRON برای انتقال USDT بسیار رایج است و Solana معماری و زبان متفاوتی دارد (Rust) که مسیر توسعه را جدا می‌کند.

در CEX کاربر ثبت‌نام و احراز هویت می‌کند، دارایی‌اش را به کیف پول صرافی واریز می‌کند و در عمل صرافی نگهدار دارایی او می‌شود. سفارش‌های خرید و فروش وارد یک موتور تطبیق (matching engine) روی سرورهای صرافی می‌شوند و معامله‌ها در پایگاه داده صرافی ثبت می‌شوند، نه روی بلاکچین. بلاکچین فقط هنگام واریز و برداشت وارد کار می‌شود.

این معماری سرعت و تجربه کاربری عالی می‌دهد: سفارش‌های حدی و بازاری، اهرم، پشتیبانی مشتری و درگاه ریالی یا فیات. اما قیمتش اعتماد است. کاربر باید به امنیت و صداقت صرافی اعتماد کند، و تاریخ بازار نمونه‌های متعددی از هک شدن یا ورشکستگی صرافی‌ها را نشان داده است؛ فروپاشی FTX در سال ۲۰۲۲ شناخته‌شده‌ترین مثال است.

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

در DEX کاربر با کیف پول خودش (مثل MetaMask) وصل می‌شود و دارایی‌اش هیچ‌وقت به حساب صرافی نمی‌رود. معامله مستقیم با یک قرارداد هوشمند انجام می‌شود. محبوب‌ترین مدل، AMM یا بازارساز خودکار است: به‌جای دفتر سفارش، یک استخر نقدینگی شامل دو توکن وجود دارد و قیمت بر اساس نسبت موجودی استخر محاسبه می‌شود. در ساده‌ترین حالت (مدل Uniswap نسخه ۲) حاصل‌ضرب موجودی دو توکن ثابت می‌ماند: x × y = k.

نقدینگی را کاربرانی به نام liquidity provider تأمین می‌کنند و در ازای آن سهمی از کارمزد معاملات می‌گیرند. این مدل ریسک‌هایی هم دارد: ضرر ناپایدار (impermanent loss)، لغزش قیمت (slippage) در استخرهای کم‌عمق، و حملاتی مثل front-running و MEV که در آن‌ها ربات‌ها از ترتیب تراکنش‌ها سود می‌برند.

نکته مهم: کپی کردن کد یک DEX معروف از نظر فنی ساده است، اما بخش سخت کسب‌وکار، جذب نقدینگی و کاربر است. بدون نقدینگی، قیمت‌ها بد می‌شوند و کاربر برنمی‌گردد. پس برنامه جذب نقدینگی را از روز اول با طراحی فنی کنار هم بنویسید.

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

بسیاری از پروژه‌ها اصلاً به ساخت صرافی کامل نیاز ندارند. اگر هدف شما ساخت توکن، پاداش وفاداری، فروش اولیه، استخر staking یا بازار NFT است، یک یا چند قرارداد هوشمند به‌همراه یک فرانت‌اند خوب کافی است و هزینه و ریسک بسیار کمتری دارد.

بیشتر حمله‌های بزرگ به پروژه‌های Web3 از چند الگوی مشخص می‌آیند و بیشتر آن‌ها قابل پیشگیری هستند. نکته مهم این است که امنیت یک مرحله پایانی نیست؛ از روز اول باید در طراحی باشد.

از نظر فنی، قرارداد هوشمند در همه‌جا یکسان است؛ تفاوت اصلی در محیط پیرامونی است. در بازار بین‌المللی، مهم‌ترین مسئله پیروی از قوانین هر کشور هدف است: مجوز ارائه خدمات دارایی دیجیتال، الزامات KYC/AML و محدودیت‌های جغرافیایی. این الزامات بین کشورها تفاوت زیادی دارند و باید پیش از ساخت از مشاور حقوقی همان بازار پرسید.

برای کسب‌وکارهایی که در ایران فعالیت می‌کنند یا کاربر ایرانی دارند، چند عامل دیگر هم مطرح است. تحریم‌ها و محدودیت‌های پرداخت، دسترسی به برخی خدمات بین‌المللی (از جمله بعضی صرافی‌ها، پرداخت‌ها و سرویس‌های ابری) را محدود می‌کند و انتخاب زیرساخت را تحت تأثیر قرار می‌دهد. مقررات داخلی حوزه رمزارز نیز ممکن است مرتب تغییر کند. ما مشاوره حقوقی نمی‌دهیم و پیشنهاد می‌کنیم پیش از هر تصمیم، آخرین وضعیت قوانین و الزامات را از منابع رسمی و متخصص حقوقی بررسی کنید؛ نباید هیچ پروژه‌ای بر دور زدن قوانین بنا شود.

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

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

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

اگر قصد ساخت یک پروژه Web3 دارید، تیم سوشو استودیو می‌تواند در طراحی معماری، توسعه و تست قراردادهای هوشمند و ساخت فرانت‌اند dApp همراه شما باشد. با توضیح هدف و بازار هدف‌تان از بخش تماس شروع کنید.