ERC-721: استاندارد توکن غیرقانونی

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

خلاصه

استاندارد زیر امکان اجرای یک API استاندارد برای NFT در قراردادهای هوشمند را فراهم می کند. این استاندارد قابلیت های اساسی را برای ردیابی و انتقال NFT ها فراهم می کند.

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

• خاصیت فیزیکی - خانه ها ، آثار هنری منحصر به فرد
• کلکسیون های مجازی - تصاویر منحصر به فرد از بچه گربه ها ، کارت های جمع آوری شده
• دارایی های "ارزش منفی" - وام ، بار و سایر مسئولیت ها

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

انگیزه

یک رابط استاندارد به برنامه های کیف پول/کارگزار/حراج اجازه می دهد تا با هر NFT در Ethereum کار کنند. ما قراردادهای هوشمند ERC-721 ساده و همچنین قراردادهایی را ارائه می دهیم که تعداد زیادی از NFT های خودسرانه را ردیابی می کنند. برنامه های اضافی در زیر بحث شده است.

این استاندارد از استاندارد Token ERC-20 الهام گرفته شده است و از زمان ایجاد EIP-20 بر دو سال تجربه ساخته شده است. EIP-20 برای ردیابی NFT ها کافی نیست زیرا هر دارایی متمایز (غیر قربانی) است در حالی که هر یک از تعداد نشانه ها یکسان (قارچ) است.

تفاوت بین این استاندارد و EIP-20 در زیر مورد بررسی قرار گرفته است.

مشخصات

کلمات کلیدی "باید" ، "نباید" ، "لازم" ، "باید" ، "باید" ، "باید" ، "نباید" ، "توصیه شده" ، "مه" و "اختیاری" در این سند هستندهمانطور که در RFC 2119 شرح داده می شود ، تفسیر می شود.

هر قرارداد سازگار با ERC-721 باید رابط های ERC721 و ERC165 را اجرا کند (مشمول "احتیاط" در زیر):

عکسبرداری استحکام ^0.4.20; ///title ERC-721 استاندارد توکن غیر قابل انعطاف //dev به https://eips. ethereum. org/eips/eip-721 /////// توجه: شناسه ERC-165 برای این رابط 0x80AC58CD است. رابط ERC721 / * erc165 */  ///dev این هنگام مالکیت هرگونه NFT توسط هر مکانیسم تغییر می کند. /// این رویداد هنگام ایجاد NFT (`از == 0) ساطع می شود و از بین می رود /// (`to` == 0). استثنا: در حین ایجاد قرارداد ، هر تعداد NFT /// ممکن است بدون انتشار انتقال ایجاد و اختصاص یابد. در زمان /// هر انتقال ، آدرس تأیید شده برای آن NFT (در صورت وجود) برای هیچ یک تنظیم نشده است. رویداد انتقال(نشانی فهرست شده _از جانب, نشانی فهرست شده _به, uint256 فهرست شده _tokenid); ///dev این وقتی آدرس تأیید شده برای NFT تغییر می کند یا /// مجدداً تأکید کرد. آدرس صفر نشان می دهد که هیچ آدرس تأیید شده وجود ندارد. /// هنگامی که یک رویداد انتقال منتشر می شود ، این همچنین نشان می دهد که تأیید شده است /// آدرس آن NFT (در صورت وجود) برای هیچ یک تنظیم نشده است. رویداد تصویب(نشانی فهرست شده _ صاحب, نشانی فهرست شده _تایید شده, uint256 فهرست شده _tokenid); ///dev وقتی یک اپراتور فعال یا غیرفعال می شود ، این ساطع می شود. /// اپراتور می تواند تمام NFT های مالک را مدیریت کند. رویداد تصویب(نشانی فهرست شده _ صاحب, نشانی فهرست شده _اپراتور, بول _تایید شده); /// notice تمام NFT های اختصاص داده شده به یک مالک را حساب کنید ///dev nfts اختصاص داده شده به آدرس صفر نامعتبر است و این /// عملکرد برای پرس و جو در مورد آدرس صفر پرتاب می کند. ///Param _Owner آدرس برای چه کسی می تواند تعادل را پرس و جو کند /// retu تعداد NFT های متعلق به `_owner" ، احتمالاً صفر تابع تعادل(نشانی _ صاحب) خارجی چشم انداز بازگرداندن (uint256); /// notice صاحب یک NFT را پیدا کنید ///dev nfts اختصاص داده شده به آدرس صفر نامعتبر و نمایش داده شد /// در مورد آنها پرتاب می کنند. ///param _tokenid شناسه برای NFT /// retu آدرس صاحب NFT تابع مالک(uint256 _tokenid) خارجی چشم انداز بازگرداندن (نشانی); /// notice مالکیت یک NFT را از یک آدرس به آدرس دیگر منتقل می کند ///dev پرتاب می کند مگر اینکه "msg. sender" صاحب فعلی باشد ، یک مجاز /// اپراتور یا آدرس تأیید شده برای این NFT. اگر `_ از /// صاحب فعلی نیست. اگر آدرس صفر باشد ، پرتاب می کند. پرتاب می کند اگر /// `_tokenid` یک NFT معتبر نیست. پس از اتمام انتقال ، این عملکرد /// checks if `_to` is a smart contract (code size>0)اگر چنین است ، تماس می گیرد /// `onerc721received" در `_to" و اگر مقدار بازگشت نیست پرتاب می کند /// `bytes4 (keccak256 (" onerc721received (آدرس ، آدرس ، uint256 ، بایت) ")). ///param _ از صاحب فعلی NFT ///param _to صاحب جدید ///param _tokenid nft برای انتقال /// param داده های اضافی بدون فرمت مشخص شده ، در تماس با "_to" ارسال شده است تابع از روی safetransferm(نشانی _از جانب, نشانی _به, uint256 _tokenid, بایت داده ها) خارجی قابل پرداخت; /// notice مالکیت یک NFT را از یک آدرس به آدرس دیگر منتقل می کند ///dev این با یک پارامتر داده اضافی به طور یکسان با عملکرد دیگر کار می کند ، /// به جز این عملکرد فقط داده ها را روی "" تنظیم می کند. ///param _ از صاحب فعلی NFT ///param _to صاحب جدید ///param _tokenid nft برای انتقال تابع از روی safetransferm(نشانی _از جانب, نشانی _به, uint256 _tokenid) خارجی قابل پرداخت; /// @notice انتقال مالکیت NFT -- تماس گیرنده مسئول است /// برای تأیید اینکه «_to» قادر به دریافت NFTS یا موارد دیگر است /// ممکن است برای همیشه گم شوند ///dev پرتاب می کند مگر اینکه "msg. sender" صاحب فعلی باشد ، یک مجاز /// اپراتور یا آدرس تأیید شده برای این NFT. اگر `_ از /// صاحب فعلی نیست. اگر آدرس صفر باشد ، پرتاب می کند. پرتاب می کند اگر /// `_tokenId` یک NFT معتبر نیست. ///param _ از صاحب فعلی NFT ///param _to صاحب جدید ///param _tokenid nft برای انتقال تابع انتقال از(نشانی _از جانب, نشانی _به, uint256 _tokenid) خارجی قابل پرداخت; /// @notice آدرس تایید شده یک NFT را تغییر دهید یا مجدداً تأیید کنید /// @dev آدرس صفر نشان می دهد که هیچ آدرس تایید شده ای وجود ندارد. /// پرتاب می کند مگر اینکه «msg. sender» مالک فعلی NFT یا مجاز باشد /// اپراتور مالک فعلی. /// @param _approved کنترلر NFT تایید شده جدید /// @param _tokenId NFT برای تایید تابع تایید(نشانی _تایید شده, uint256 _tokenid) خارجی قابل پرداخت; /// @notice تأیید را برای مدیریت شخص ثالث ("اپراتور") فعال یا غیرفعال کنید /// همه دارایی های `msg. sender` /// @dev رویداد ApprovalForAll را منتشر می کند. قرارداد باید اجازه دهد /// چندین عملگر در هر مالک. /// @param _operator آدرس برای افزودن به مجموعه اپراتورهای مجاز /// @param _approved درست است اگر اپراتور تایید شود، نادرست برای لغو تایید تابع setApprovalForAll(نشانی _اپراتور, بول _تایید شده) خارجی; /// @notice آدرس تایید شده یک NFT را دریافت کنید /// @dev اگر «_tokenId» یک NFT معتبر نباشد پرتاب می کند. /// @param _tokenId NFT برای یافتن آدرس تایید شده برای /// @retu آدرس تایید شده برای این NFT، یا آدرس صفر اگر وجود ندارد تابع دریافت تایید(uint256 _tokenid) خارجی چشم انداز بازگرداندن (نشانی); /// @notice اگر آدرسی یک اپراتور مجاز برای آدرس دیگری است، پرس و جو کنید /// @param _owner آدرسی که NFTها را در اختیار دارد /// @param _operator آدرسی که از طرف مالک عمل می کند /// @retu اگر «_operator» یک اپراتور تأیید شده برای «_owner» باشد درست است، در غیر این صورت نادرست است تابع برای همه تایید شده است(نشانی _ صاحب, نشانی _اپراتور) خارجی چشم انداز بازگرداندن (بول); > رابط ERC165  /// @notice اگر قراردادی یک رابط را پیاده سازی می کند، پرس و جو کنید /// @param interfaceID شناسه رابط، همانطور که در ERC-165 مشخص شده است /// @dev شناسه رابط در ERC-165 مشخص شده است. این تابع /// کمتر از 30000 گاز مصرف می کند. /// @retu 'true' اگر قرارداد 'interfaceID' و /// «interfaceID» 0xffffffff نیست، در غیر این صورت «نادرست» است تابع پشتیبانی(بایت 4 رابط) خارجی چشم انداز بازگرداندن (بول); > 

در صورت پذیرش نقل و انتقالات ایمن ، یک برنامه کیف پول/کارگزار/حراج باید رابط کیف پول را پیاده سازی کند.

///dev توجه: شناسه ERC-165 برای این رابط 0x150B7A02 است. رابط ERC721TokenReceiver  /// notice رسیدگی NFT را اداره کنید ///dev قرارداد هوشمند ERC721 این عملکرد را بر روی گیرنده فراخوانی می کند /// پس از "انتقال". این عملکرد ممکن است برای بازگشت و رد کردن /// انتقال. بازگشت غیر از مقدار جادویی باید منجر به /// معامله برگشت یافته است. /// توجه: آدرس قرارداد همیشه فرستنده پیام است. ///param _operator آدرس که عملکرد `safetransferfrom" نامیده می شود ///param _ از آدرس که قبلاً متعلق به نشانه بود ///param _tokenid شناسه NFT که در حال انتقال است ///param _data داده های اضافی بدون قالب مشخص /// retu `bytes4 (keccak256 (" onerc721received (آدرس ، آدرس ، uint256 ، بایت) ")))` /// مگر اینکه پرتاب شود تابع onerc721recied(نشانی _اپراتور, نشانی _از جانب, uint256 _tokenid, بایت _داده ها) خارجی بازگرداندن(بایت 4); > 

پسوند ابرداده برای قراردادهای هوشمند ERC-721 اختیاری است (در زیر به "Caveats" مراجعه کنید). این اجازه می دهد تا قرارداد هوشمند شما به دلیل نام خود مورد بازجویی قرار گیرد و جزئیات مربوط به دارایی هایی را که NFT های شما نشان می دهند ، مورد بازجویی قرار گیرد.

///title ERC-721 استاندارد توکن غیر قابل انعطاف ، پسوند ابرداده اختیاری ///dev به https://eips. ethereum. org/eips/eip-721 // توجه داشته باشید: شناسه ERC-165 برای این کاررابط 0x5B5E139F است. رابط erc721metadata / * erc721 */  /// notice یک نام توصیفی برای مجموعه ای از NFT ها در این قرارداد تابع نام() خارجی چشم انداز بازگرداندن (رشته _نام); /// notice یک نام مختصر برای NFT در این قرارداد تابع سمبل() خارجی چشم انداز بازگرداندن (رشته _سمبل); /// notice یک شناسه منابع یکنواخت مشخص (URI) برای یک دارایی معین. ///dev اگر `_tokenid` یک NFT معتبر نباشد ، پرتاب می کند. URI ها در RFC تعریف شده اند /// 3986. URI ممکن است به یک پرونده JSON اشاره کند که مطابق با "ERC721 باشد /// طرحواره Metadata Json ". تابع توکینی(uint256 _tokenid) خارجی چشم انداز بازگرداندن (رشته); > 

این "طرحواره ابرداده JSON ERC721" است که در بالا به آن اشاره شد.

 "عنوان": "ابرداده دارایی", "نوع": "هدف - شی", "خواص":  "نام":  "نوع": "رشته", "شرح": "دارایی را که این NFT نشان می دهد" مشخص می کند " >, "شرح":  "نوع": "رشته", "شرح": "دارایی را توصیف می کند که این NFT نمایانگر آن است" >, "تصویر":  "نوع": "رشته", "شرح": "URI با اشاره به منبعی با نوع MIME Image/* نمایانگر دارایی که این NFT را نشان می دهد. در نظر بگیرید که هرگونه تصاویر را با عرض بین 320 تا 1080 پیکسل و نسبت ابعاد بین 1. 91: 1 و 4: 5 در نظر بگیرید." > > > 

پسوند شمارش برای قراردادهای هوشمند ERC-721 اختیاری است (در زیر به "Caveats" مراجعه کنید). این به قرارداد شما اجازه می دهد تا لیست کامل NFT ها را منتشر کرده و آنها را کشف کند.

///title ERC-721 استاندارد توکن غیر فرکانس ، پسوند شمارش اختیاری ///dev به https://eips. ethereum. org/eips/eip-721 // توجه داشته باشید: شناسه ERC-165 برای این کاررابط 0x780E9D63 است. رابط ERC721ENOBLE / * erc721 */  /// notice تعداد nfts ردیابی شده توسط این قرارداد /// retu تعداد NFT های معتبر ردیابی شده توسط این قرارداد ، جایی که هر یک از آنها /// آنها دارای یک مالک اختصاص داده شده و پرس و جو است که برابر با آدرس صفر نیست تابع مطبوع() خارجی چشم انداز بازگرداندن (uint256); /// notice nfts معتبر را ثبت کنید /// @dev Throws if `_index`>= `totalsupply ()`. ///param _index پیشخوان کمتر از `totalsupply ()` ` /// retu شناسه توکن برای `_index`th nft ، /// (مرتب سازی سفارش مشخص نشده) تابع TokenbyIndex(uint256 _فهرست مطالب) خارجی چشم انداز بازگرداندن (uint256); /// notice NFT های اختصاص داده شده به یک مالک /// @dev Throws if `_index`>= `تعادل (_owner)` یا اگر /// `_Owner 'آدرس صفر است ، نمایانگر NFT های نامعتبر است. ///Param _Owner آدرس جایی که ما به NFT های متعلق به آنها علاقه مند هستیم ///param _index پیشخوان کمتر از `تعادل (_owner)` /// retu شناسه توکن را برای `_index`th NFT اختصاص داده شده به` _owner` ، /// (مرتب سازی سفارش مشخص نشده) تابع tokenofownerbyindex(نشانی _ صاحب, uint256 _فهرست مطالب) خارجی چشم انداز بازگرداندن (uint256); > 

احتیاط

گرامر رابط 0. 4. 20 استحکام به اندازه کافی بیانگر نیست تا استاندارد ERC-721 را مستند کند. قراردادی که با ERC-721 مطابقت دارد نیز باید از موارد زیر پیروی کند:

• شماره استحکام شماره 3412: رابط های فوق شامل ضمانت های صریح جهش برای هر عملکرد است. ضمانت های جهش پذیری به منظور ضعیف بودن به قوی هستند: قابل پرداخت ، غیر قابل پرداخت ، دید و خالص. اجرای شما باید ضمانت جهش پذیری را در این رابط برآورده کند و ممکن است ضمانت قوی تری داشته باشید. به عنوان مثال ، یک تابع قابل پرداخت در این رابط ممکن است به صورت غیر قابل پرداخت (بدون تغییر حالت مشخص نشده) در قرارداد شما اجرا شود. ما انتظار داریم که انتشار استحکام بعدی به شما اجازه دهد قرارداد سختگیرانه تر از این رابط به ارث ببرد ، اما یک راه حل برای نسخه 0. 4. 20 این است که می توانید این رابط را ویرایش کنید تا قبل از ارث از قرارداد خود ، جهش سختگیرانه تری اضافه کنید.
• شماره استحکام شماره 3419: قراردادی که ERC721METADATA یا ERC721ENULEBLE را اجرا می کند ، ERC721 را نیز پیاده سازی می کند. ERC-721 الزامات رابط ERC-165 را پیاده سازی می کند.
• شماره استحکام شماره 2330: اگر عملکردی در این مشخصات به عنوان خارجی نشان داده شود ، در صورت استفاده از دید عمومی ، یک قرارداد سازگار خواهد بود. به عنوان راه حل نسخه 0. 4. 20 ، می توانید این رابط را ویرایش کنید تا قبل از ارث بردن از قرارداد خود به عموم مردم تغییر دهید.
• شماره های استحکام #3494 ، #3544: استفاده از این.*. انتخاب کننده به عنوان هشدار توسط استحکام مشخص شده است ، نسخه آینده استحکام این را به عنوان یک خطا نشان نمی دهد.

اگر نسخه جدیدتر از استحکام اجازه می دهد تا احتیاط ها به صورت کد بیان شود ، ممکن است این EIP به روز شود و احتیاط ها برداشته شود ، چنین معادل مشخصات اصلی خواهد بود.

بنیاد و پایه

بسیاری از موارد پیشنهادی از قراردادهای هوشمند Ethereum وجود دارد که به ردیابی دارایی های قابل تشخیص بستگی دارد. نمونه هایی از NFT های موجود یا برنامه ریزی شده ، زمین به صورت غیر متمرکز ، پانک های ناشناس در رمزنگاری ها و موارد درون بازی با استفاده از سیستمهایی مانند Dmarket یا Enjincoin هستند. استفاده های آینده شامل ردیابی دارایی های دنیای واقعی ، مانند املاک و مستغلات (همانطور که توسط شرکت هایی مانند Ubitquity یا Propy پیش بینی شده است). در هر یک از این موارد بسیار مهم است که این موارد به عنوان شماره در یک دفترچه "جمع نمی شوند" ، اما در عوض هر دارایی باید مالکیت خود را به صورت جداگانه و اتمی ردیابی کند. صرف نظر از ماهیت این دارایی ها ، اگر یک رابط استاندارد داشته باشیم که امکان مدیریت دارایی های عملکردی و سیستم عامل های فروش را فراهم می کند ، اکوسیستم قوی تر خواهد بود.

"NFT" انتخاب کلمه

"NFT" برای تقریباً همه مورد بررسی رضایت بخش بود و برای یک جهان گسترده از دارایی های دیجیتال قابل تشخیص بسیار کاربرد دارد. ما می دانیم که "عمل" برای برخی از برنامه های خاص این استاندارد (به ویژه خاصیت فیزیکی) بسیار توصیفی است.

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

شناسه های NFT

هر NFT توسط یک شناسه منحصر به فرد UINT256 در داخل قرارداد هوشمند ERC-721 مشخص می شود. این شماره شناسایی برای زندگی قرارداد تغییر نخواهد کرد. این زوج (آدرس قرارداد ، UINT256 TOKENID) سپس یک شناسه جهانی منحصر به فرد و کاملاً واجد شرایط برای یک دارایی خاص در یک زنجیره اتریوم خواهد بود. در حالی که برخی از قراردادهای هوشمند ERC-721 ممکن است شروع به کار با شناسه 0 و به سادگی برای هر NFT جدید ، مناسب باشد ، تماس گیرندگان نباید فرض کنند که شماره های شناسه الگوی خاصی برای آنها دارند و باید شناسه را به عنوان "جعبه سیاه" رفتار کنند"همچنین توجه داشته باشید که NFT ها ممکن است نامعتبر شوند (نابود شوند). لطفاً توابع شمارش را برای یک رابط شمارش پشتیبانی شده مشاهده کنید.

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

مکانیسم انتقال

ERC-721 یک عملکرد انتقال ایمن SafeTransferFrom (اضافه بار با و بدون پارامتر بایت) و یک عملکرد ناایمن را از آن استفاده می کند. نقل و انتقالات ممکن است توسط:

• صاحب یک NFT
• آدرس تأیید شده NFT
• یک اپراتور مجاز از مالک فعلی NFT

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

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

• در صورت مکث قرارداد ، نقل و انتقالات را مجازات نکنید - هنر قبلی ، cryptokitties قرارداد مستقر ، خط 611
• بلوک لیست آدرس خاصی از دریافت NFT - هنر قبلی ، cryptokitties قرارداد مستقر ، خطوط 565 ، 566
• نقل و انتقالات ناامن را مجازات کنید-Transferfrom پرتاب می شود مگر اینکه برابر باشد با msg. sender یا countof (_to) غیر صفر است یا قبلاً غیر صفر بوده است (زیرا چنین مواردی بی خطر است)
• هزینه ای را برای هر دو طرف یک معامله شارژ کنید-هنگام تماس با یک صفر ، اگر قبلاً آدرس صفر بود ، پرداخت را بازپرداخت کنید ، در صورت تماس با آدرس صفر اگر قبلاً یک آدرس غیر صفر بود ، پرداخت بازپرداخت را بازپرداخت کنید. هنگام فراخوانی هر عملکرد انتقال ، به پارامتر انتقال _to برای مساوی msg. sender نیاز دارید ، به پارامتر انتقال _to نیاز دارید تا آدرس تأیید شده برای NFT باشد
• فقط NFT Registry را بخوانید - همیشه از Safetransferfrom پرتاب کنید ، انتقال دهید ، تأیید کنید و تنظیم کنید

معاملات ناموفق ، بهترین روشی که در ERC-223 ، ERC-677 ، ERC-827 و اجرای OpenZeppelin از Safeerc20. sol مشخص شده است. ERC-20 یک ویژگی کمک هزینه را تعریف کرد ، این مسئله باعث ایجاد مشکل شد و بعداً به مقدار دیگری تغییر یافت ، همانطور که در شماره شماره 438 OpenZeppelin. در ERC-721 ، هیچ کمک هزینه ای وجود ندارد زیرا هر NFT بی نظیر است ، مقدار آن هیچ یا یک نیست. بنابراین ما مزایای طراحی اصلی ERC-20 را بدون مشکلی که بعداً کشف شده است دریافت می کنیم.

ایجاد NFTS ("Minting") و تخریب NFT ها ("سوزاندن") در مشخصات گنجانده نشده است. قرارداد شما ممکن است این موارد را با روش دیگر اجرا کند. لطفاً هنگام ایجاد یا از بین بردن NFT ، مستندات رویداد را برای مسئولیت های خود مشاهده کنید.

ما سؤال کردیم که آیا پارامتر اپراتور در EnerC721Received ضروری است یا خیر. در همه موارد ما می توانیم تصور کنیم ، اگر اپراتور مهم باشد ، آن اپراتور می تواند نشانه را به خود منتقل کند و سپس آن را ارسال کند - سپس آنها از آدرس خواهند بود. به نظر می رسد این امر به این دلیل است که ما اپراتور را صاحب موقت توکن می دانیم (و انتقال به خودشان زائد است). هنگامی که اپراتور توکن را ارسال می کند ، این اپراتور است که به قول خود عمل می کند ، نه اپراتور که به نمایندگی از دارنده توکن عمل می کند. به همین دلیل اپراتور و صاحب توکن قبلی هر دو برای گیرنده توکن قابل توجه هستند.

گزینه های دیگر در نظر گرفته شده: فقط به معامله سبک ERC-20 دو مرحله ای اجازه می دهد ، نیاز به عملکردهای انتقال هرگز پرتاب نمی کند ، به همه توابع نیاز دارد تا یک بولی را که نشان دهنده موفقیت عمل است ، برگردانند.

رابط ERC-165

ما تشخیص رابط استاندارد (ERC-165) را برای افشای رابط هایی که یک قرارداد هوشمند ERC-721 پشتیبانی می کند ، انتخاب کردیم.

EIP آینده ممکن است یک رجیستری جهانی از رابط ها برای قراردادها ایجاد کند. ما به شدت از چنین EIP پشتیبانی می کنیم و این امکان را به شما می دهد که اجرای ERC-721 شما را با واگذاری یک قرارداد جداگانه ، ERC721ENOMEBLE ، ERC721METADATA یا سایر رابط ها را پیاده سازی کند.

گاز و پیچیدگی (با توجه به پسوند شمارش)

این مشخصات در نظر دارد پیاده سازی هایی را که مدیریت چند و تعداد زیادی از NFT های خودسرانه را مدیریت می کند. اگر برنامه شما قادر به رشد است ، از استفاده برای/در حالی که در کد خود استفاده می کنید خودداری کنید (به شماره 4 Cryptokitties مراجعه کنید). اینها نشان می دهد که قرارداد شما ممکن است قادر به مقیاس نباشد و هزینه های گاز بدون محدودیت با گذشت زمان افزایش می یابد.

ما یک قرارداد ، XXXXERC721 را به TestNet مستقر کرده ایم که 340282366920938463374607431768211456 اعمال مختلف (2^128). این کافی است که هر آدرس IPv6 را به صاحب حساب Ethereum اختصاص دهید ، یا مالکیت نانوبوت ها را در اندازه و در کل نیمی از اندازه زمین ردیابی کنید. می توانید آن را از blockchain پرس و جو کنید. و هر عملکرد گاز کمتری نسبت به پرس و جو در ENS می گیرد.

این تصویر واضح است: مقیاس استاندارد ERC-721.

گزینه های دیگر در نظر گرفته شده: اگر به حلقه ای نیاز داشته باشد ، عملکرد شمارش دارایی را حذف کنید ، یک نوع آرایه استحکام را از توابع شمارش برگردانید.

حریم خصوصی

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

ممکن است جالب باشد که یک مورد استفاده را در نظر بگیرید که NFT ها قابل توجه نیستند ، مانند ثبت خصوصی مالکیت دارایی یا یک رجیستری تا حدی خصوصی. با این حال ، حریم خصوصی قابل دستیابی نیست زیرا یک مهاجم می تواند به سادگی (!) با مالک برای هر نشانه ممکن تماس بگیرد.

گزینه های ابرداده (پسوند ابرداده)

ما به عملکردهای نام و نماد در پسوند ابرداده نیاز داریم. هر EIP و پیش نویس ما بررسی کردیم (ERC-20 ، ERC-223 ، ERC-677 ، ERC-777 ، ERC-827) این توابع را شامل می شد.

ما به نویسندگان اجرای یادآوری می کنیم که اگر به استفاده از این مکانیسم اعتراض کنید ، رشته خالی یک پاسخ معتبر به نام و نماد است. ما همچنین به همه یادآوری می کنیم که هر قرارداد هوشمند می تواند از همان نام و نماد قرارداد شما استفاده کند. چگونه مشتری می تواند تعیین کند که قراردادهای هوشمند ERC-721 مشهور (متعارف) خارج از محدوده این استاندارد است.

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

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

گزینه های دیگر در نظر گرفته شده: تمام ابرداده را برای هر دارایی روی blockchain (خیلی گران قیمت) قرار دهید ، از الگوهای URL برای پرس و جو قطعات ابرداده استفاده کنید (الگوهای URL با همه طرح های URL ، به ویژه URL های P2P کار نمی کنند) ، آدرس شبکه MultiDDR (به اندازه کافی بالغ)

اجماع جامعه

بحث قابل توجهی در مورد شماره اصلی ERC-721 رخ داده است ، علاوه بر این ، ما اولین جلسه زنده را در Gitter برگزار کردیم که نمایندگی خوبی داشت و به خوبی تبلیغ می شد (در Reddit ، در کانال Gitter #erc و شماره اصلی ERC-721). با تشکر از شرکت کنندگان:

• iMallinnow Rob از دسامبر بازی / ارائه ملاقات میشیگان اتریوم 7 فوریه
• arachnid نیک جانسون
• Jadhavajay Ajay Jadhav از Ayanworks
• Superphly Cody Marx Bailey - Xram Capital / اشتراک در Hackathon 20 ژانویه / UN Future of Finance Hackathon.
• fulldecent ویلیام Entriken

یک رویداد دوم در Ethdenver 2018 برای بحث در مورد استانداردهای قابل تشخیص دارایی (یادداشت هایی که منتشر می شود) برگزار شد.

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

سازگاری به عقب

ما از مشخصات ERC-20 تعادل ، TotalSupply ، نام و نماد را اتخاذ کرده ایم. یک اجرای همچنین ممکن است شامل اعشار عملکردی باشد که در صورت پشتیبانی از این استاندارد ، UINT8 (0) را برمی گرداند. با این حال ، ما می دانیم که برای پشتیبانی از عملکرد اعشار ، به کلیه پیاده سازی های ERC-721 نیاز دارد.

به عنوان مثال اجرای NFT از فوریه 2018:

• Cryptokitties - سازگار با نسخه قبلی این استاندارد.
• Cryptopunks-تا حدی سازگار با ERC-20 ، اما به راحتی قابل تعمیم نیست زیرا عملکرد حراج را مستقیماً در قرارداد شامل می کند و از نامهای عملکردی استفاده می کند که صریحاً دارایی ها را به عنوان "پانک" معرفی می کند.
• رابط دارایی حراج-نویسنده به یک رابط عمومی برای حراج ðapp (در حال حاضر یخبندان) نیاز داشت. قرارداد "دارایی" او بسیار ساده است ، اما سازگاری ERC-20 ، عملکرد (تأیید () و ابرداده را از دست نمی دهد. این تلاش در بحث برای EIP-173 ذکر شده است.

توجه: "نسخه محدود ، نشانه های کلکسیونی" مانند کارتهای Curio و PEPE نادر دارایی قابل تشخیص نیستند. آنها در واقع مجموعه ای از نشانه های قارچی فردی هستند که هر یک از آنها با قرارداد هوشمند خود با کل عرضه خود (که ممکن است در موارد شدید 1 باشد) ردیابی می شود.

عملکرد onerC721Received به طور خاص در مورد قراردادهای مستقر در قدیمی کار می کند که ممکن است سهواً 1 (درست) را در شرایط خاص بازگرداند ، حتی اگر عملکردی را اجرا نکنند (به اشکال استحکام DelegatecallRetuValue مراجعه کنید). با بازگشت و بررسی یک مقدار جادویی ، ما می توانیم پاسخ های مثبت واقعی را در مقابل این موارد واقعی خالی متمایز کنیم.

موارد آزمون

0xCert ERC-721 Token شامل موارد آزمایشی است که با استفاده از ترافل نوشته شده است.

اجرای

0xCert ERC721 - اجرای مرجع

• MIT دارای مجوز است ، بنابراین می توانید آزادانه از آن برای پروژه های خود استفاده کنید
• شامل موارد آزمون است
• Bounty Active Bugy ، اگر خطایی پیدا کنید ، به شما پرداخت می شود

Su Squares - یک بستر تبلیغاتی که در آن می توانید فضا را اجاره کنید و تصاویر را قرار دهید

• برنامه Bounty Bounty Bugy Su Squares را تکمیل کنید تا با این استاندارد یا اجرای آن مشکلاتی داشته باشید
• استاندارد کامل و تمام رابط های اختیاری را پیاده سازی می کند

ERC721EXAMPLEDEED - یک نمونه اجرا

• با استفاده از قالب پروژه OpenZeppelin پیاده سازی می شود

XXXXERC721 ، توسط ویلیام Entriken - اجرای نمونه ای مقیاس پذیر

• مستقر در TestNet با 1 میلیارد دارایی و پشتیبانی از تمام جستجوی با پسوند ابرداده. این نشان می دهد که مقیاس گذاری مشکلی نیست.

منابع

معیارها

1. استاندارد Token ERC-20.
2. تشخیص رابط استاندارد ERC-165.
3. استاندارد ERC-173 متعلق به آن.
4. استاندارد توکن ERC-223.
5. استاندارد توکن TransferandCall ERC-677.
6. استاندارد توکن ERC-827.
7. سرویس نام Ethereum (ENS). https://ens. domains
8. اینستاگرام - وضوح تصویر چیست؟https://help. instagram. com/1631821640426723
9. طرح JSON. https://json-schema. org/
10. multiaddrhttps://github. com/multiformats/multiaddr
11. کلمات کلیدی RFC 2119 برای استفاده در RFC برای نشان دادن سطح نیاز. https://www. ietf. org/rfc/rfc2119. txt

مسائل

1. شماره اصلی ERC-721. https://github. com/ethereum/eips/issues/721
2. شماره استحکام شماره 2330 - توابع رابط خارجی هستند. https://github. com/ethereum/solidity/issues/2330
3. شماره استحکام شماره 3412 - پیاده سازی رابط: اجازه دهید جهش سختگیرانه تری داشته باشید. https://github. com/ethereum/solidity/issues/3412
4. شماره استحکام شماره 3419 - رابط ها نمی توانند به ارث برده شوند. https://github. com/ethereum/solidity/issues/3419
5. شماره استحکام شماره 3494 - کامپایلر به طور نادرست دلایل عملکرد انتخاب کننده را دلایل می دهد. https://github. com/ethereum/solidity/issues/3494
6. شماره استحکام شماره 3544 - نمی تواند انتخاب عملکرد به نام انتقال را محاسبه کند. https://github. com/ethereum/solidity/issues/3544
7. Cryptokitties شماره 4 شماره 4 - لیست همه بچه گربه های متعلق به یک کاربر O (n^2) است. https://github. com/axiomzen/cryptokitties-bounty/issues/4
8. شماره شماره 438 OpenZeppelin - اجرای روش تأیید ، استاندارد ERC20 را نقض می کند. https://github. com/openzeppelin/zeppelin-solidity/issues/438
9. استحکام DEELEGATECALLRETURNVALUE. https://solidity. readthedocs. io/en/develop/bugs. html#delegatecallretuvalue

بحث

1. Reddit (اعلام اولین بحث زنده). https://www. reddit. com/r/ethereum/Idea/7r2ena/friday_119_live_discussion_on_erc_nonfungible/
2. gitter #eips (اعلام اولین بحث زنده). https://gitter. im/ethereum/eips؟at=5a5a5f823fb48e8c3566f0a5e7
3. ERC-721 (اعلام اولین بحث زنده). https://github. com/ethereum/eips/issues/721#issuecomment-358369377
4. Ethdenver 2018. https://ethdenver. com

پیاده سازی های NFT و سایر پروژه ها

1. cryptokitties. https://www. cryptokitties. co
2. 0xCert ERC-721 نشانه. https://github. com/0xcert/ethereum-erc721
3. مربع سو. https://tenthmainsu. com
4. غیر متمرکزhttps://decentraland. org
5. cryptopunks. https://www. larvalabs. com/cryptopunks
6. dmarkethttps://www. dmarket. io
7. اننجین سکه. https://enjincoin. io
8. ubitquityhttps://www. ubitquity. io
9. propyhttps://tokensale. propy. com
10. Cryptokitties قرارداد مستقر شده است. https://etherscan. io/address/0x06012c8cf97bead5deae23707070f9587f8e266d#code
11. برنامه Bounty Squares Squares. https://github. com/fulldecent/su-squares-bounty
12. xxxxerc721. https://github. com/fulldecent/erc721-example
13. ERC721EXAMPLEDEED. https://github. com/nastassiasachs/erc721exampledeed
14. کارتهای کوریو. https://mycuriocards. com
15. پپه نادرhttps://rarepepewallet. com
16. رابط دارایی حراج. https://github. com/dob/auctionhouse/blob/master/contracts/asset. sol
17. OpenZeppelin Safeerc20. Sol اجرای. https://github. com/openzeppelin/zeppelin-solidity/blob/master/contracts/token/erc20/safeerc20. sol

کپی رایت

حق چاپ و حقوق مربوطه از طریق CC0 از بین رفت.

استناد

لطفاً این سند را به این صورت ذکر کنید:

ویلیام Entriken (fulldecent) ، دیتر شرلی<[email protected]>، یعقوب ایوانز<[email protected]>، نستاسیا ساکس<[email protected]>، "ERC-721: استاندارد توکن غیرقانونی" ، پیشنهادات بهبود اتریوم ، شماره. 721 ، ژانویه 2018. [سریال آنلاین]. موجود: https://eips. ethereum. org/eips/eip-721.

پیشنهادات بهبود اتریوم

• پیشنهادات بهبود اتریوم

پیشنهادات بهبود اتریوم (EIPs) استانداردهای مربوط به بستر اتریوم ، از جمله مشخصات پروتکل اصلی ، API های مشتری و استانداردهای قرارداد را توصیف می کند.