چک لیست کامل برای ساخت کلون Uniswap V2 با سالیدیتی

ساخت کلون Uniswap V2 با استفاده از نسخه‌ های مدرن زبان Solidity (یا حتی زبان Huff برای کسانی که به دنبال مسیر سخت‌تر هستند) تجربه‌ای بسیار آموزنده و ارزشمند برای توسعه‌دهندگان قراردادهای هوشمند است. در ادامه، نکاتی کاربردی و توصیه‌هایی برای انجام دقیق و حرفه‌ای این کار ارائه شده است:

تنظیمات پایه برای شروع ساخت کلون Uniswap V2 در سالیدیتی

• از نسخه‌ به‌روز شده سالیدیتی استفاده کنید؛ چرا که این موضوع باعث ایجاد تفاوت‌های نحوی در کد می‌شود.

• به جای استفاده از اعداد ممیز ثابت (fixed-point)، نوع داده‌ های سفارشی تعریف کنید.

• از پیاده‌سازی Solady ERC20 استفاده کنید تا هزینه گس در پیاده‌سازی توکن کاهش یابد.

• به جای محافظت بازدرون‌ریزی Uniswap V2 که دیگر بهینه نیست، از نسخه‌های جدیدتر مثل OpenZeppelin استفاده کنید.

• هنگام پیاده‌سازی اوراکل قیمت، بخش‌هایی که احتمال سرریز (overflow) دارند را داخل بلوک unchecked قرار دهید.

• در سالیدیتی 0.8.0 به بعد، استفاده از SafeMath ضروری نیست؛ آن را از کد حذف کنید.

• اگر روتری جداگانه پیاده‌سازی نمی‌کنید، بررسی‌های مربوط به لغزش قیمت (slippage) را داخل همان قرارداد لحاظ کنید، چون EOAها نمی‌توانند توکن ها را درون تراکنش ارسال کنند.

امنیت و ترتیب اجرای منطقی

• قفل بازدرون‌ریزی (reentrancy lock) را در مکان‌های مناسب قرار دهید. بررسی کنید که آیا Uniswap V2 در برابر بازدرون‌ریزی فقط‌خواندنی (read-only reentrancy) آسیب‌پذیر است یا نه و دلیل آن را بفهمید.

• با توجه به تغییرات جدید در سالیدیتی، می‌توان قرارداد factory را بدون استفاده از اسمبلی ساده‌تر نوشت.

• هنگام استفاده از توکن هایی که کارمزد انتقال دارند (fee-on-transfer) یا رفتاری دینامیک مثل بازتنظیم (rebase) دارند، با دقت بیشتری عمل کنید.

• تابع جذر (square root) را می‌توان با کمک کتابخانه Solady بهینه‌تر پیاده‌سازی کرد، اما در انتخاب جهت گرد کردن، دقت کنید.

کدنویسی تمیز و استاندارد

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

• سبک نگارش Uniswap V2 از استانداردهای حرفه‌ای سالیدیتی پیروی نمی‌کند؛ شما باید از این استانداردها استفاده کنید.

• ردیابی جفت‌ها در factory بهینه نیست؛ سعی کنید منطق این بخش را بازنویسی کرده و مصرف گس را کاهش دهید.

• برخی متغیرهای ذخیره‌سازی را می‌توان به‌ صورت immutable تعریف کرد (این قابلیت در زمان طراحی نسخه V2 وجود نداشت).

• استفاده از custom errors نسبت به require معمولاً هزینه دیپلوی را کمتر می‌کند.

نکات حیاتی برای عملیات burn و mint

• هنگام سوزاندن عرضه اولیه (burn initial supply)، اجازه ندهید مقدار totalSupply به صفر برسد؛ در غیر این صورت مکانیزم محافظتی یونی سواپ در برابر حمله «اولین سپرده‌گذار» بی‌اثر می‌شود.

• ترتیب اجرای عملیات burn، mint و به‌روزرسانی ذخایر باید دقیق و درست باشد؛ ترتیب اشتباه باعث اختلال در محاسبه سهم‌ها می‌شود.

• تابع _safeTransfer در نسخه فعلی در برابر حمله memory expansion آسیب‌پذیر است (احتمالش پایین است اما باید ایمن‌سازی شود). فقط یک مقدار بولی بازگردانده می‌شود، پس فقط یک کلمه را با returndatacopy بخوانید. از خواندن کامل داده بازگشتی پرهیز کنید.

تست‌پذیری و مقاومت در برابر حملات

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

• از موجودی‌ها (balance) یا موجودی استخر به‌ عنوان اوراکل استفاده نکنید؛ این اطلاعات در برابر حملات flash loan آسیب‌پذیر هستند.

• در محاسبه معاملات یا عملیات mint و burn، همیشه گرد کردن را به نفع استخر انجام دهید.

• نوشتن تست‌های واحد (unit tests) را هیچ‌وقت فراموش نکنید؛ این کار پایه‌ ای‌ترین الزام برای اعتبارسنجی امنیت قرارداد است.

مراحل تکمیلی برای ارتقاء عملکرد

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

• تمرین Puppet V2 از مجموعه DamnVulnerableDeFi را انجام دهید؛ در این مرحله باید بتوانید این چالش را به‌ راحتی حل کنید.

راستی! برای دریافت مطالب جدید در کانال تلگرام یا پیج اینستاگرام سورس باران عضو شوید.