کارکرد اصلی

یک رابط استاندارد برای نشانه های غیرقانونی (NFT). یعنی نشانه هایی که هر کدام یک شناسه منحصر به فرد دارند.

انگیزه

در سه سال از زمان تصویب ERC-721 توسط جامعه اتریوم ، نشانه های غیرقانونی خود را به عنوان یک فرصت جدید باورنکردنی در طیف گسترده ای از رشته ها ثابت کرده اند: کلکسیون ، هنر ، بازی ، امور مالی ، واقعیت مجازی ، املاک و مستغلات و موارد دیگربشر

این استاندارد دروس آموخته شده در این آزمایش اولیه را ایجاد می کند و با استفاده از ویژگی های منحصر به فرد از blockchain نزدیک ، امکانات را بیشتر می کند:

• یک زمان اجرا ناهمزمان و مشخص ، به این معنی که دو قرارداد را می توان همزمان در قسمت های مختلف اجرا کرد
• یک مدل ذخیره سازی ذخیره سازی که هزینه های گاز را از خواسته های ذخیره سازی شبکه جدا می کند و باعث ذخیره بیشتر زنجیره ای می شود (به پسوند ابرداده مراجعه کنید) و هزینه های معامله فوق العاده کم

با توجه به این ویژگی ها ، این استاندارد NFT می تواند با یک تعامل کاربر انجام شود که سایر blockchains به دو یا سه نیاز دارند. قابل توجه ترین NFT_TRANSFER_CALL است که توسط آن یک کاربر اساساً می تواند یک نشانه را به یک تماس با یک قرارداد جداگانه وصل کند. سناریوی مثال:

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

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

• ERC-721
• EIP-1155 برای چند توکنی
• استاندارد توکن قارچ نزدیک ، که برای اولین بار پیشگام تکنیک "انتقال و تماس" بود

توضیح در سطح مرجع

یادداشت :

• تمام مبالغ ، مانده و کمک هزینه توسط U128 محدود است (حداکثر مقدار 2 ** 128 - 1).
• Token Standard از JSON برای سریال سازی آرگومان ها و نتایج استفاده می کند.
• مقادیر در آرگومان ها و نتایج به صورت رشته های Base-10، به عنوان مثال."100". این کار برای جلوگیری از محدودیت JSON در حداکثر مقدار صحیح 2**53 انجام می شود.
• قرارداد باید تغییر در فضای ذخیره سازی را هنگام افزودن و حذف از مجموعه ها دنبال کند. این در این استاندارد توکن قابل تعویض اصلی نیست، بلکه در استاندارد ذخیره سازی گنجانده شده است.
• برای جلوگیری از تغییر یا حذف قرارداد مستقر، نباید هیچ کلید دسترسی در حساب خود داشته باشد.

رابط NFT

// ساختار پایه ای که برای یک توکن برگردانده می شود. اگر قرارداد استفاده می شود // برنامه های افزودنی مانند مدیریت تأیید، فراداده یا موارد دیگر ویژگی های // ممکن است در این ساختار گنجانده شود. نوع رمز =   token_id: رشته,  مالک_id: رشته, >  /******************/ /* تغییر روش ها */ /******************/  // انتقال ساده. انتقال یک «token_id» از مالک فعلی به // `receiver_id`. // // الزامات // * تماس گیرنده روش باید برای اهداف امنیتی 1 یوکت Ⓝ ودیعه را ضمیمه کند // * اگر توسط شخصی غیر از مالک توکن تماس گرفته شود، قرارداد باید وحشت زده شود، // در صورت استفاده از مدیریت تایید، یکی از حساب های تایید شده // * «approval_id» برای استفاده با پسوند مدیریت تأیید است، ببینید // آن سند برای توضیح کامل. // * اگر از مدیریت تأیید استفاده می کنید، قرارداد باید حساب های تأیید شده را باطل کند // انتقال موفقیت آمیز // // استدلال ها: // * `receiver_id`: حساب معتبر NEAR که رمز را دریافت می کند // * `token_id`: نشانه انتقال // * `approval_id` (اختیاری): شناسه تایید مورد انتظار. عددی کوچکتر از // 2^53، و بنابراین به عنوان JSON قابل نمایش است. به مدیریت تایید مراجعه کنید // استاندارد برای توضیح کامل. // * `یادداشت` (اختیاری): برای موارد استفاده که ممکن است از نمایه سازی یا // ارائه اطلاعات برای انتقال تابع nft_transfer(  گیرنده_id: رشته,  token_id: رشته,  تایید_id: عدد|خالی,  یادداشت: رشته|خالی, ) >  // انتقال رمز و فراخوانی متدی در قرارداد گیرنده. یک موفق // گردش کار به یک نتیجه اجرای موفقیت آمیز به فراخوان در NFT ختم می شود // قرارداد با روش «nft_resolve_transfer». // // می توانید این را شبیه به پیوست کردن توکن های بومی NEAR به a در نظر بگیرید // فراخوانی تابع. این به شما امکان می دهد تا هر توکن غیر قابل تعویض را در یک تماس به یک متصل کنید // قرارداد گیرنده. // // الزامات: // * تماس گیرنده روش باید برای امنیت 1 یوکت Ⓝ ودیعه را ضمیمه کند // اهداف // * اگر توسط شخصی غیر از مالک توکن تماس گرفته شود، قرارداد باید وحشت زده شود، // در صورت استفاده از مدیریت تایید، یکی از حساب های تایید شده // * قرارداد دریافت کننده باید "nft_on_transfer" را مطابق با اجرا کند // استاندارد. اگر اینطور نیست، قرارداد FT «nft_resolve_transfer» باید انجام شود // با شکست قرارداد متقابل حاصل تماس بگیرید و انتقال را به عقب برگردانید. // * قرارداد باید رفتاری را که در «nft_resolve_transfer» توضیح داده شده است، اجرا کند // * «approval_id» برای استفاده با پسوند مدیریت تأیید است، ببینید // آن سند برای توضیح کامل. // * اگر از مدیریت تأیید استفاده می کنید، قرارداد باید حساب های تأیید شده را باطل کند // انتقال موفقیت آمیز // // استدلال ها: // * `receiver_id`: حساب معتبر NEAR که رمز را دریافت می کند. // * `token_id`: رمزی برای ارسال. // * `approval_id` (اختیاری): شناسه تایید مورد انتظار. عددی کوچکتر از // 2^53، و بنابراین به عنوان JSON قابل نمایش است. به مدیریت تایید مراجعه کنید // استاندارد برای توضیح کامل. // * `یادداشت` (اختیاری): برای موارد استفاده که ممکن است از نمایه سازی یا // ارائه اطلاعات برای انتقال. // * `msg`: اطلاعات مورد نیاز قرارداد دریافت کننده را مشخص می کند // به منظور انجام صحیح انتقال. می تواند هر دو تابع را نشان دهد // فراخوانی و پارامترهایی که باید به آن تابع منتقل شوند. تابع nft_transfer_call(  گیرنده_id: رشته,  token_id: رشته,  پیام: رشته,  تایید_id: عدد|خالی,  یادداشت: رشته|خالی, ): وعده >   /****************/ /* مشاهده روش ها */ /****************/  // توکن را با «token_id» یا «null» در صورت عدم وجود چنین نشانه ای برمی گرداند. تابع nft_token(token_id: رشته): رمز|خالی > 

رفتار زیر لازم است، اما نویسندگان قرارداد ممکن است نام این تابع را غیر از nft_resolve_transfer معمولی که در اینجا استفاده می شود، بگذارند.

// زنجیره «nft_transfer_call» از تماس های متقابل را نهایی کنید. // // فرآیند «nft_transfer_call»: // // 1. فرستنده «nft_transfer_call» را در قرارداد NFT فرا می خواند // 2. قرارداد NFT توکن را از فرستنده به گیرنده منتقل می کند // 3. قرارداد NFT «nft_on_transfer» را در قرارداد گیرنده فراخوانی می کند // 4+.[قرارداد گیرنده ممکن است تماس های متقابل دیگری برقرار کند] // N. قرارداد NFT زنجیره وعده را با "nft_resolve_transfer" حل می کند و ممکن است // انتقال رمز به فرستنده // // الزامات: // * قرارداد باید تماس با این تابع توسط هر حسابی به جز خود را ممنوع کند // * اگر زنجیره وعده شکست خورد، قرارداد باید انتقال توکن را برگرداند // * اگر زنجیره وعده با «true» حل شود، قرارداد باید به توکن برگردد // "owner_id". // // استدلال ها: // * "previous_owner_id": مالک اصلی NFT. // * "receiver_id": آرگومان "receiver_id" داده شده به "nft_transfer_call" // * "token_id": آرگومان "token_id" داده شده به "nft_transfer_call" // * "acproved_account_ids" (اختیاری): در صورت استفاده از مدیریت تایید، قرارداد باید ارائه شود // ضبط حساب های تأیید شده اصلی در این استدلال ، و این موارد را بازیابی کنید // حساب های تأیید شده و شناسه های تأیید آنها در صورت بازگشت. // // اگر توکن با موفقیت به "reciver_id" منتقل شود ، درست باز می گردد. تابع nft_resolve_transfer(  prior_owner_id: رشته,  گیرنده_id: رشته,  token_id: رشته,  تأیید شده_ ACCOUNT_IDS: خالی|رکوردرشته, عدد>, ): بولی > 

رابط گیرنده

قراردادهایی که می خواهند از nft_transfer_call استفاده کنند باید موارد زیر را اجرا کنند:

// بعد از دریافت یک نشانه غیر قابل استفاده ، برخی از اقدامات را انجام دهید // // الزامات: // * قرارداد باید تماس های این عملکرد را به مجموعه ای از NFT سفید شده محدود کند // قراردادها // // استدلال ها: // * `sender_id`: فرستنده` nft_transfer_call` // * `قبلی_OWNER_ID`: حسابی که قبل از آن صاحب NFT بود // به این قرارداد منتقل شده است ، که در صورت استفاده می تواند با `sender_id` متفاوت باشد // گسترش مدیریت تأیید // * "token_id": آرگومان "token_id" داده شده به "nft_transfer_call" // * `msg`: اطلاعات لازم برای این قرارداد برای دانستن نحوه پردازش // درخواست. این ممکن است شامل نام روش و/یا استدلال باشد. // // اگر توکن باید به "sender_id" برگردانده شود ، درست برمی گردد تابع nft_on_transfer(  شناسه فرستنده: رشته,  prior_owner_id: رشته,  token_id: رشته,  پیام: رشته, ): وعدهبولی>; 

اره

• 2022-11-21: پارامتر APPROVEL_ID را به عنوان اختیاری در توضیحات عملکرد نیز اختیاری کنید.
• 2022-02-03: نام فیلد ساختار توکن به روز شده. شناسه به token_id تغییر یافت. این مطابق با اجرای فعلی اسناد استاندارد و Rust SDK است.
• 2021-12-20: آرگومان به روز شده nft_resolve_transfer تأیید شده_Account_ids به عنوان نوع null | ضبط به جای null | رشته []. این به قراردادها راهی برای بازگرداندن حساب های تأیید شده اصلی و شناسه های تأیید آنها می دهد. اطلاعات بیشتر را می توان در این بحث یافت.
• 2021-07-16: به روز شده NFT_TRANSFER_CALL ARGRAPOVAL_ID به شماره نوع | تهی به جای رشته | تهی. همانطور که گفته شد ، انتظار نمی رود که شناسه های تصویب از حد JSON 2^53 فراتر رود.