۴ اشتباه کلیدی در قراردادهای NFT که باید مراقب آنها باشید

در عرصه‌ انیمیشن و توکن‌های NFT، قراردادهای تعریف شده از اهمیت ویژه‌ای برخوردارند. با این حال، بسیاری از این قراردادها به رغم طراحی خوب، هنوز به خطاها و مشکلات خاصی دچار هستند. پلتفرم Etherscan (اتر اسکن) ابزاری را فراهم کرده است که می‌توان با استفاده از آن کدهای مربوط به قراردادهای ERC721 را مقایسه کرد و از ابزارهای تایید و Decompile نیز بهره برد. در این نوشتار، نظر به معرفی نقاط ضعف قراردادهای NFT یا Anti-Pattern (ضد الگو) خواهیم داشت.

نقاط ضعف قراردادهای NFT

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

عدم تفکیک اطلاعات فروش و منطق قرارداد

اولین نقطه ضعف قراردادهای NFT، ناتوانی در تفکیک اطلاعات مرتبط با فروش، قیمت و منطق از خود قرارداد می‌باشد. این شیوه ممکن است ناشی از تمایل به صرفه‌جویی در هزینه‌های استقرار و نگهداری از قرارداد باشد. اما چرا باید از قرار دادن منطق فروش و عرضه در خود قرارداد پرهیز کرد؟

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

نداشتن امنیت مبتنی بر نقش

دیگر خطا در قراردادهای NFT، عدم بکارگیری امنیت مبتنی بر نقش است. برای کنترل دسترسی به برخی عملیات مانند تغییر پارامترهای عرضه، وجود نوعی مکانیزم کنترل لازم است. استفاده از مدل Ownable می‌تواند ایمن‌ترین گزینه باشد، اما مدل‌های Role-Based Security معمولاً می‌توانند این هدف را بهتر تامین کنند.

مدل Ownable ممکن است به سادگی یک شخص را به عنوان مدیر قرارداد مشخص کند. لذا افراد ممکن است تمایل به اتخاذ شیوه‌های پیشگیرانه در برابر حوادث آینده داشته باشند. امنیت مبتنی بر نقش می‌تواند به کاربر این قابلیت را دهد که کاربردهای مشخصی را از خود قرارداد دریافت کرده و به دیزاین‌های مجزا و تنظیمات خاص نیاز داشته باشد.

فقدان استفاده از ERC-165

چالش دیگر، عدم استفاده از ERC-165 یا قابلیت Introspection در بسیاری از قراردادهاست. ERC-165 به ایجاد قابلیت Interoperability کمک می‌کند که سبب افزایش سازگاری قرارداد با سیستم‌های مختلف می‌گردد. از این رو، پیاده‌سازی درست این استاندارد می‌تواند امنیت و کارایی بیشتری را به ارمغان آورد.

برای تحقق این امر، شایسته است که هر کلاس والد که اجراکننده ERC-165 است، در لیست Override قرار گیرد. به این ترتیب، با استفاده از دستور Super.supportsInterface به راحتی قابلیت‌ها فعال خواهند شد.

عدم تست کامل قبل از استقرار

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

تست‌های یونیت بایستی بدون در نظر گرفتن نوع چهارچوب مورد استفاده (مانند Hardhat یا Mocha) انجام شود. جامعه توسعه‌دهندگان همچنین توصیه به استفاده از ابزارهای خودکار برای تسریع در فرایند تست می‌کند. این ابزارها می‌توانند از جمله Certik، Slither و Mythril باشند.

توصیه: اعتبارسنجی قرارداد در اتر اسکن

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


پست های مرتبط