اشتباهات قراردادهای NFT

در بازار توکن NFT که همیشه در مسیر رشد و تکامل است، قراردادهای NFT وجود دارند که از اهمیت بالایی برخوردار هستند. البته، در بسیاری از قراردادهای NFT، با وجود طراحی خوب، معمولاً برخی باگ های خاص وجود دارد. پلت فرم Etherscan دارای یک ابزار جستجوی مناسب است که به شما امکان می دهد کدهای بسیاری از قراردادهای ERC721 را با هم مقایسه کنید. با استفاده از این ابزار می توانید از توابع تایید و دیکامپایل استفاده کنید. در این مقاله به بررسی خواهیم پرداخت خطاهای قراردادهای NFT یا بیایید در مورد اصطلاح Anti-model صحبت کنیم.

خطا در بررسی قراردادهای NFT

در قراردادها NFT معمولاً اشتباهات زیادی رخ می دهد و در زیر به اشتباهات قرارداد NFT و همچنین راه حل هایی برای جلوگیری از آنها خواهیم پرداخت.

1- آوردن اطلاعات مربوط به فروش، قیمت و منطق در قرارداد

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

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

اگرچه منطق قرارداد باید بدون تغییر و ثابت باشد، اما باید بتواند استانداردها را به خوبی اعمال کند. اکثر کلون ها تقریباً یکسان هستند. برای اینکه قرارداد برای کاربر قابل انعطاف و قابل اعتماد باشد، اطلاعاتی مانند قیمت گذاری و استراتژی صدور باید کاملاً از منطق زیربنایی قرارداد جدا باشد. همچنین باید طراحی جداگانه و مسئولیت واحد (قانون تک کار) وجود داشته باشد. علاوه بر این، بهتر است در خود قرارداد ERC721 عرضه (MaxSupply) محدود باشد و امکان تغییر آن فقط در دست مدیر باشد.

2- از امنیت نقش محور استفاده نمی شود

یکی دیگر از خطاهای قراردادهای NFT، بدون استفاده از محافظت از نقش. از آنجایی که دسترسی به برخی عملیات (از جمله تغییر یا صدور پارامترهای تحویل) باید فقط برای آدرس‌ها مجاز باشد، قراردادهای توکن به نوعی کنترل دسترسی نیاز دارند. استفاده از مدل Ownable ممکن است ساده ترین راه برای اجرای این نوع کنترل دسترسی باشد. (از آنجایی که این یک نیاز ساده است، معمولاً از قرارداد Ownable OpenZeppelin استفاده می شود.) با این حال، به دلایلی توصیه می شود از امنیت مبتنی بر نقش استفاده کنید.

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

اگر علاقه مند به آشنایی با خدمات بلاک چین برای NFT هستید، می توانید با مراجعه به مقاله بهترین خدمات بلاک چین برای NFT با این خدمات و مزایا و معایب آنها آشنا شوید.

دلیل مهم تری برای استفاده از امنیت مبتنی بر نقش وجود دارد. در واقع، امنیت نقش به افراد اجازه می دهد تا اپلیکیشن (اطلاعات قیمت و فروش) را از خود قرارداد ERC721 جدا کنند. همچنین به افراد این امکان را می دهد که یک قرارداد فردی را به عنوان صادرکننده (ضریب کننده) انتخاب کنند. همچنین به افراد اجازه می‌دهد تا نقش «ناشر» را بدون نیاز به دادن مجوزهای مدیریت کامل به آن اختصاص دهند.

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

3- از ERC-165 یا Introspection استفاده نمی کند

عدم استفاده از ERC-165 یا ویژگی Introspection یکی دیگر از اشکالات قراردادهای NFT است. اکثر قراردادها یا توکن ها از ERC-165 استفاده نمی کنند یا آن را به درستی اجرا نمی کنند. اهمیت ERC-165 در ایجاد قابلیت همکاری است. ERC-165 سازگاری قرارداد را افزایش می دهد و صرافی ها احتمالاً می خواهند در مورد ساختار پاداش افراد برای NFT ها بدانند. برای کاربرد صحیح این استاندارد در قراردادها باید به قوانین زیر توجه کرد:

1- هر کلاس والدی که ERC-165 را پیاده سازی می کند باید در لیست Override قرار گیرد. در چنین مواردی، هنگام استفاده از دستور Super.supportsInterface، آنها نیز به طور خودکار فعال می شوند.

2- اگر یک رابط پیاده سازی در کلاس والد نباشد، می توان آن را با استفاده از یک کلمه یا عبارت به صورت زیر اضافه کرد:

مثال:

اگر کد دارای کلاس والد نیست که بتواند ERC-165 را پیاده سازی کند، نوع دوم باید ذکر شود. همچنین اگر کد کاربری هیچ رابطی غیر از ERC-165 پیاده سازی شده توسط کلاس والد را پیاده سازی نکند، کاربر نیازی به نوع دوم ندارد. اگرچه اجرای صحیح ERC-165 بسیار مهم است، اما کاملا اختیاری است. با استفاده از این پیاده سازی، یک کاربر می تواند توکن سازگار با بسیاری از سیستم ها، از جمله مبادلات یا حتی سیستم های اجرا نشده داشته باشد. استفاده از ERC-165 با توسعه میدان و در طول زمان افزایش خواهد یافت.

بسیاری از ابزارهای توکن NFT تاکنون ساخته شده اند که برای شناخت آن ها می توانید به مقاله بهترین ابزار NFT مراجعه کرده و نحوه عملکرد آن ها را درک کنید.

4- قبل از استقرار به طور کامل تست نشده است

قبل از اجرای دیگری به طور کامل آزمایش نمی شود خطاهای قراردادهای NFT f حتی اگر رمز ERC721 استاندارد باشد و تمام کتابخانه‌های والد و کلاس‌های شخص ثالث بدون تغییرات خاصی استفاده شوند، و برای اطمینان از ایمن بودن کاربر و آزمایش کد شخص ثالث، باز هم باید به طور کامل کد خود را آزمایش کند. قبل از استقرار کد در شبکه اصلی، کاربران تنها یک فرصت برای آزمایش و رفع مشکل دارند. اول از همه، کاربر باید Unit Testing را انجام دهد. مهم نیست که چه نوع چارچوبی برای آزمایش استفاده می شود. می توان از فریم ورک های اترها، هاردات و موکا استفاده کرد.

هنگام انتخاب چارچوب تست باید نکات مهمی مانند پوشش تست، پوشش شدید موارد، پوشش مبارک کیس و عمق و وسعت موارد لبه را در نظر گرفت. حتی اگر کاربر از کدهای قبلاً تست شده (OpenZeppelin) استفاده کند، باز هم ممکن است کد مربوط به موارد بالا باشد، بنابراین باید دوباره تست شود. همچنین، OpenZeppelin در گذشته باگ هایی داشته است که ممکن است در آینده دوباره ظاهر شوند.

کاربران می توانند یک مجموعه آزمایشی برای تمام توکن های ERC721، توکن های ERC1155، توکن های ERC20 و غیره آماده کنند. و از آنها در هر پروژه برای صرفه جویی در زمان استفاده کنید. آنها همچنین می توانند عناصر بیشتری را به پروژه ها اضافه کنند و استانداردها را سفارشی کنند. این باعث صرفه جویی در وقت آنها می شود. تست های واحد باید شامل اجرای استاندارد ERC165، عملیات اساسی (مسائل و انتقالات)، کنترل دسترسی، توقف (در صورت توقف قرارداد) و غیره باشد. کاربران می توانند از یکی از بسته های پلتفرم Nodejs به نام Solidity-Coverage برای تست پوشش خود استفاده کنند.

استفاده از ابزارهای خودکار در تست ها می تواند کمک زیادی به کاربران کند. به طور معمول، شرکت های بزرگ تست امنیت مانند Certik و Consensys از استانداردهای صنعتی مانند Manticore، Slither و Mythril استفاده می کنند. Solidity-Coverage درصد پوشش تقریبی تست های واحد کاربر را نشان می دهد. Solgraph همچنین ابزاری برای مشاهده روابط و ارتباطات در کد قراردادی است. همچنین می تواند در برنامه ریزی آزمون مفید باشد. اکیدنا نیز ابزار پیچیده و مفیدی است. بهتر است کاربران همیشه از روش تست اول استفاده کنند تا علاوه بر پوشش تست خوب، تست ها به مشخصات پروژه نزدیکتر باشد. به طور خلاصه می توان گفت که باید به موارد زیر توجه کرد:

1. در تمامی موارد باید تست کامل و کامل ماژول انجام شود.
2. تست دستی
3. استفاده از ابزارهای خودکار از جمله Slither، Manticore، Mythril، Echidna و Solidity-coverage

توصیه: قرارداد را در اسکن اتر تأیید کنید

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