EIP-1155: منبع استاندارد چند توکن

یک رابط استاندارد برای قراردادهایی که چندین نوع توکن را مدیریت می کنند. یک قرارداد مستقر در آن ممکن است شامل هر ترکیبی از نشانه های قارچ ، نشانه های غیر قابل تغییر یا سایر تنظیمات (به عنوان مثال نشانه های نیمه قورباغه) باشد.

خلاصه

این استاندارد یک رابط قرارداد هوشمند را تشریح می کند که می تواند تعداد انواع توکن های قارچ و غیر قابل قارچ را نشان دهد. استانداردهای موجود مانند ERC-20 نیاز به استقرار قراردادهای جداگانه در هر نوع توکن دارد. شناسه توکن استاندارد ERC-721 یک شاخص غیرقانونی است و گروه این افراد غیرقانونی به عنوان یک قرارداد واحد با تنظیمات برای کل مجموعه مستقر می شوند. در مقابل ، استاندارد ERC-1155 Multi Token به هر شناسه توکن اجازه می دهد تا یک نوع توکن قابل تنظیم جدید را نشان دهد ، که ممکن است ابرداده ، عرضه و سایر ویژگی های خاص خود را داشته باشد.

آرگومان _id موجود در مجموعه آرگومان هر عملکرد نشان دهنده نوع خاص یا نوع توکن در یک معامله است.

انگیزه

استانداردهای توکن هایی مانند ERC-20 و ERC-721 نیاز به یک قرارداد جداگانه برای اعزام برای هر نوع یا مجموعه توکن دارند. این امر بسیاری از کد های اضافی را بر روی blockchain Ethereum قرار می دهد و عملکرد خاصی را با ماهیت جدا کردن هر قرارداد توکن در آدرس مجاز خود محدود می کند. با ظهور بازی ها و سیستم عامل های blockchain مانند Enjin Coin ، توسعه دهندگان بازی ممکن است هزاران نوع نوع توکن را ایجاد کنند و نوع جدیدی از استاندارد توکن برای پشتیبانی از آنها مورد نیاز است. با این حال ، ERC-1155 مختص بازی ها نیست و بسیاری از برنامه های دیگر می توانند از این انعطاف پذیری بهره مند شوند.

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

مشخصات

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

قراردادهای هوشمند اجرای استاندارد ERC-1155 باید تمام عملکردهای موجود در رابط ERC1155 را پیاده سازی کنند.

قراردادهای هوشمند اجرای استاندارد ERC-1155 باید عملکرد ERC-165 را پشتیبانی کند و اگر 0xD9B67A26 از طریق آرگومان InterfaceID منتقل شود ، باید مقدار ثابت را درست برگردانند.

گیرنده Token ERC-1155

قراردادهای هوشمند باید تمام عملکردهای رابط ERC1155TokenReceiver را برای پذیرش انتقال اجرا کنند. برای جزئیات بیشتر به "قوانین انتقال ایمن" مراجعه کنید.

قراردادهای هوشمند باید تابع ERC-165 supportsInterface را اجرا کنند و نشان دهنده پشتیبانی از رابط ERC1155TokenReceiver برای پذیرش انتقال باشند. برای جزئیات بیشتر به "قوانین ERC-165TokenReceiver ERC1155" مراجعه کنید.

قوانین انتقال ایمن

برای توضیح بیشتر در مورد نحوه عملکرد استاندارد safeTransferFrom و safeBatchTransferFrom باید با توجه به توابع قلاب ERC1155TokenReceiver، فهرستی از سناریوها و قوانین را دنبال کنید.

سناریوها

سناریوی شماره 1: گیرنده قرارداد نیست.

• onERC1155Received و onERC1155BatchReceived نباید در یک EOA (حساب دارای مالکیت خارجی) فراخوانی شود.

سناریوی شماره 2: تراکنش یک ضرابخانه/انتقال توکن نیست.

• onERC1155Received و onERC1155BatchReceived نباید خارج از فرآیند ضرابخانه یا انتقال فراخوانی شوند.

سناریوی شماره 3: گیرنده تابع(های) رابط ERC1155TokenReceiver لازم را اجرا نمی کند.

• انتقال باید با یک اخطار زیر برگردانده شود.
  • اگر توکن(های) ارسال شده بخشی از اجرای ترکیبی استاندارد دیگری باشد، قوانین آن استاندارد خاص در مورد ارسال به یک قرارداد اکنون ممکن است به جای آن رعایت شود. به بخش «سازگاری به عقب» مراجعه کنید.

  سناریوی شماره 4: گیرنده تابع(های) واسط لازم ERC1155TokenReceiver را پیاده سازی می کند اما مقدار ناشناخته ای را برمی گرداند.

  • انتقال باید برگردانده شود.

  سناریوی شماره 5: گیرنده تابع(های) واسط لازم ERC1155TokenReceiver را پیاده سازی می کند اما یک خطا ایجاد می کند.

  • انتقال باید برگردانده شود.

  سناریوی شماره 6: گیرنده رابط ERC1155TokenReceiver را پیاده سازی می کند و دریافت کننده یک و تنها یک تغییر تعادل است (به عنوان مثال safeTransferFrom فراخوانی شده).

  • موجودی های انتقال باید قبل از فراخوانی قلاب ERC1155TokenReceiver در قرارداد گیرنده، به روز شده باشد.
  • قبل از فراخوانی قلاب ERC1155TokenReceiver در قرارداد گیرنده، رویداد انتقال باید برای منعکس کردن تغییرات موجودی منتشر شود.
  • یکی از onERC1155Received یا onERC1155BatchReceived باید در قرارداد گیرنده فراخوانی شود.
  • قلاب onERC1155Received باید در قرارداد گیرنده فراخوانی شود و قوانین آن رعایت شود.
    • برای قوانین بیشتر که باید از آنها پیروی کنید، به "قوانین دریافت شده onERC1155" مراجعه کنید.
    • برای قوانین بیشتر که باید رعایت شوند، به «قوانین onERC1155BatchReceived» مراجعه کنید.

    سناریو شماره 7: گیرنده رابط ERC1155TokenReceiver را پیاده سازی می کند و دریافت کننده بیش از یک تغییر تعادل است (به عنوان مثال SafeBatchTransferfrom نامیده می شود).

    • کلیه نقل و انتقالات تعادل که در تماس با یک قلاب ERC1155TokenReceiver ارجاع می شوند ، باید قبل از اینکه قلاب ERC1155TokenReceiver در قرارداد گیرنده فراخوانده شود ، به روز شود.
    • تمام رویدادهای انتقال باید قبل از اینکه یک قلاب ERC1155TokenReceiver در قرارداد گیرنده فراخوانده شود ، منعکس کننده تغییرات تعادل فعلی باشد.
    • onerc1155received یا onerc1155batchreceived باید هر چند بار لازم را به گیرنده خواسته شود به گونه ای که هر تغییر تعادل برای گیرنده در سناریو به حساب می آید.
      • ارزش جادویی بازگشت برای هر تماس قلاب باید طبق "قوانین onerc115555" و "قوانین onerc115555batchreceived" بررسی و عمل شود.
      • برای قوانین بیشتر که باید رعایت شوند، به «قوانین onERC1155BatchReceived» مراجعه کنید.
      • برای قوانین بیشتر که باید از آنها پیروی کنید، به "قوانین دریافت شده onERC1155" مراجعه کنید.

      سناریو شماره 8: شما خالق قراردادی هستید که رابط ERC1155TokenReceiver را پیاده سازی می کند و نشانه ها (ها) را روی یک آدرس دیگر در یک یا هر دو onerc115555-batchreceived ارسال می کنید.

      • حمل و نقل باید پذیرش در نظر گرفته شود و سپس در یک زمینه جدید ، یک امنیت جدید یا ایمن را در یک زمینه جدید آغاز کند.
        • MAGINE ALLICNANCE CECCAK256 تجویز شده برای قلاب گیرنده که فراخوانده می شود باید پس از موفقیت در حمل و نقل برگردانده شود.
        • اگر منطق قرارداد بخواهد در این مورد مالکیت نشانه (های) خود را حفظ کند ، ممکن است این کار را انجام دهد.

        سناریو شماره 9: شما در حال انتقال نشانه ها از طریق یک تماس API غیر استاندارد یعنی یک API خاص اجرای و نه Safetransferfrom یا SafeBatchTransferFrom هستید.

        • در این سناریو تمام به روزرسانی های تعادل و قوانین خروجی رویدادها همان است که اگر یک عملکرد انتقال استاندارد خوانده شده است.
          • یعنی یک بیننده خارجی هنوز هم باید بتواند تعادل را از طریق یک عملکرد استاندارد پرس و جو کند و باید با تعادل یکسان باشد که به تنهایی توسط رویدادهای انتقال و انتقالبا تعیین می شود.
          • با این حال ، در حالی که توابع SafetransferFrom یا SafeBatchTransferFrom باید در صورت عدم اجرای یک قرارداد دریافت کننده رابط ERC1155TokenReceiver ، بازگردد ، ممکن است یک عملکرد غیر استاندارد با انتقال ادامه یابد.
          • به "اجرای قوانین API انتقال خاص" مراجعه کنید.

          قاعده

          قوانین safetransferfrom:

          • تماس گیرنده باید تأیید شود تا نشانه های منتقل شده از حساب _ از حساب (به بخش "تأیید" مراجعه کنید).
          • اگر _to آدرس صفر باشد ، باید برگردید.
          • اگر تعادل دارنده برای توکن _id پایین تر از _value ارسال شده به گیرنده باشد ، باید برگردید.
          • باید به هر خطای دیگری برگردید.
          • برای بازتاب تغییر تعادل باید رویداد انتقال را منتشر کند (به بخش "Transfersingle and TransfertBatch Event" مراجعه کنید).
          • After the above conditions are met, this function MUST check if _to is a smart contract (e.g. code size>0)در این صورت ، باید با onerC1155Received در _to تماس گرفته و به طور مناسب عمل کنید (به بخش "onerc1155received" مراجعه کنید).
            • آرگومان _DATA ارائه شده توسط فرستنده برای انتقال باید با محتوای آن بدون تغییر در عملکرد قلاب ENERC11555RECEIVE از طریق آرگومان _DATA آن منتقل شود.

            قوانین SafeBatchTransferfrom:

            • تماس گیرنده باید تأیید شود تا تمام نشانه های منتقل شده از حساب _ از حساب (به بخش "تأیید" مراجعه کنید).
            • اگر _to آدرس صفر باشد ، باید برگردید.
            • اگر طول _ids برابر با طول _values نباشد ، باید برگردید.
            • اگر هر یک از تعادل (های) نگهدارنده (ها) برای نشانه (ها) در _ids کمتر از مقدار (های) مربوطه در _ مقادیر ارسال شده به گیرنده باشد ، باید برگردید.
            • باید به هر خطای دیگری برگردید.
            • باید رویداد (های) Transcersingle یا TransfertBatch را به گونه ای منتشر کند که تمام تغییرات تعادل منعکس شود (به بخش "Transfersingle and TransfertBatch Event" مراجعه کنید).
            • تعادل و وقایع باید به ترتیب آرایه ای که ارسال شده اند رخ دهد (_ids [0]/_ مقادیر [0] قبل از _ids [1]/_ مقادیر [1] و غیره).
            • After the above conditions are met, this function MUST check if _to is a smart contract (e.g. code size>0)در این صورت ، باید با onerC1155Received یا onerc1155batchreceive در _to تماس بگیرید و به طور مناسب عمل کنید (به بخش "onerc1155received و onerc1155555batchreceived" مراجعه کنید).
              • آرگومان _DATA ارائه شده توسط فرستنده برای انتقال باید با محتوای آن بدون تغییر در عملکرد (های) قلاب ERC1155TokenReceiver از طریق آرگومان _DATA خود منتقل شود.

              قوانین رویداد Transfersingle و Transferbatch:

              • از انتقال باید استفاده شود تا نشان دهد که یک تعادل واحد بین یک جفت _ از و _to رخ داده است.
                • ممکن است چندین بار برای نشان دادن تغییرات متعدد در معامله منتشر شود ، اما توجه داشته باشید که Transferbatch برای این کار برای کاهش مصرف گاز طراحی شده است.
                • استدلال _operator باید آدرس حساب/قراردادی باشد که برای انتقال آن تصویب شده است (باید msg. sender باشد).
                • آرگومان _ از آدرس دارنده باید باشد که تعادل آن کاهش یافته است.
                • استدلال _to باید آدرس گیرنده باشد که تعادل آن افزایش یافته است.
                • آرگومان _id باید نوع توکن منتقل شود.
                • آرگومان _Value باید تعداد نشانه هایی باشد که تعادل نگهدارنده توسط آن کاهش می یابد و با آنچه که تعادل گیرنده افزایش می یابد مطابقت دارد.
                • هنگام مینینگ/ایجاد نشانه ها ، آرگومان _from باید روی 0x0 تنظیم شود (یعنی آدرس صفر). به "Minting/ایجاد و سوزاندن/از بین بردن قوانین" مراجعه کنید.
                • هنگام سوزاندن/از بین بردن نشانه ها ، آرگومان _to باید روی 0x0 تنظیم شود (یعنی آدرس صفر). به "Minting/ایجاد و سوزاندن/از بین بردن قوانین" مراجعه کنید.
                • این ممکن است با یک عنصر واحد در لیست منتشر شود تا نشان دهنده تغییر تعادل مفرد در معامله باشد ، اما توجه داشته باشید که Transfersingle برای این کار برای کاهش مصرف گاز طراحی شده است.
                • استدلال _operator باید آدرس حساب/قراردادی باشد که برای انتقال آن تصویب شده است (باید msg. sender باشد).
                • آرگومان _FROM باید آدرس دارنده باشد که تعادل آن برای هر جفت ورودی در _ids و _values کاهش یافته است.
                • آرگومان _to باید آدرس گیرنده باشد که تعادل آن برای هر جفت ورودی در _ids و _values افزایش یافته است.
                • آرگومان آرایه _IDS باید حاوی شناسه های توکن در حال انتقال باشد.
                • آرگومان آرایه _Values باید حاوی تعداد نشانه هایی باشد که برای هر ورودی مربوطه در _ids منتقل می شود.
                • _ids و _values باید همان طول داشته باشند.
                • هنگام مینینگ/ایجاد نشانه ها ، آرگومان _from باید روی 0x0 تنظیم شود (یعنی آدرس صفر). به "Minting/ایجاد و سوزاندن/از بین بردن قوانین" مراجعه کنید.
                • هنگام سوزاندن/از بین بردن نشانه ها ، آرگومان _to باید روی 0x0 تنظیم شود (یعنی آدرس صفر). به "Minting/ایجاد و سوزاندن/از بین بردن قوانین" مراجعه کنید.
                • برای اطمینان از صحت سفارش رویداد در مورد ورود مجدد معتبر (به عنوان مثال اگر یک گیرنده در صورت دریافت قرارداد به سمت دریافت) تعادل حالت و مانده وقایع باید قبل از تماس با قرارداد خارجی مطابقت داشته باشد.

                قوانین onerc1155555:

                • استدلال _operator باید آدرس حساب/قراردادی باشد که برای انتقال آن تصویب شده است (باید msg. sender باشد).
                • آرگومان _ از آدرس دارنده باید باشد که تعادل آن کاهش یافته است.
                  • _ از یک نعنا باید 0x0 باشد.
                  • یعنی باید استدلال _data بدون تغییر را که از طریق SafetransferFrom یا SafeBatchTransferFrom برای این انتقال ارسال شده است ، منتقل کنید.
                  • اگر مقدار بازده بایت 4 باشد (keccak256 ("onerc11555received (آدرس ، آدرس ، uint256 ، uint256 ، بایت)"))) انتقال باید تکمیل شود یا در صورت عدم تحقق شرایط دیگر برای موفقیت باید برگردد.
                  • اگر قرارداد گیرنده را پرتاب یا برگرداند ، معامله باید برگردانده شود.
                  • همه تماس های برگشتی نشان دهنده تغییرات تعادل متقابل منحصر به فرد است.
                  • مجموعه کلیه تماس های مربوط به onerc1155received و onerc1155batchreceive تمام تغییرات تعادل را که در طول معامله به ترتیب ارسال شده رخ داده است ، توصیف می کند.

                  قوانین onerc1155batchreceived:

                  • استدلال _operator باید آدرس حساب/قراردادی باشد که برای انتقال آن تصویب شده است (باید msg. sender باشد).
                  • آرگومان _ از آدرس دارنده باید باشد که تعادل آن کاهش یافته است.
                    • _ از یک نعنا باید 0x0 باشد.
                    • یعنی باید آرگومان _data بدون تغییر ارسال شده از طریق فراخوان safeBatchTransferFrom برای این انتقال ارسال شود.
                    • اگر مقدار بازگشتی بایت 4 باشد (keccak256("onERC1155BatchReceived(آدرس، آدرس،uint256[]، uint256[]، بایت)")) اگر شرایط دیگری برای موفقیت برآورده نشد، انتقال باید تکمیل شود یا باید برگردد.
                    • اگر قرارداد گیرنده را پرتاب یا برگرداند ، معامله باید برگردانده شود.
                    • همه تماس های برگشتی نشان دهنده تغییرات تعادل متقابل منحصر به فرد است.
                    • مجموعه کلیه تماس های مربوط به onerc1155received و onerc1155batchreceive تمام تغییرات تعادل را که در طول معامله به ترتیب ارسال شده رخ داده است ، توصیف می کند.

                    قوانین ERC1155TokenReceiver ERC-165:

                     

                    • اجرای عملکرد ERC-165 supportsInterface باید به صورت زیر باشد:

                       

                    • اگر 0x01ffc9a7 از طریق آرگومان interfaceID ارسال شود، باید مقدار ثابت true را برگرداند. این نشان دهنده پشتیبانی ERC-165 است.
                    • اگر 0x4e2312e0 از آرگومان interfaceID عبور داده شود، باید مقدار ثابت true را برگرداند. این نشان دهنده پشتیبانی ERC-1155 ERC1155TokenReceiver است.
                    • نباید بیش از 10000 بنزین مصرف کند.
                      • این باعث می شود که آن را زیر 30000 گاز مورد نیاز ERC-165 نگه می دارد، نیاز به ذخیره گاز را کاهش می دهد و عوارض جانبی احتمالی تخلیه گاز در طول تماس را به حداقل می رساند.

                      اجرای قوانین API انتقال خاص:

                      • اگر از یک تابع API خاص پیاده سازی برای انتقال توکن(های) ERC-1155 به قرارداد استفاده می شود، اگر گیرنده رابط ERC1155TokenReceiver را پیاده سازی می کند، قوانین safeTransferFrom یا safeBatchTransferFrom (در صورت لزوم) همچنان باید رعایت شوند. اگر اجرا نشد، اجرای غیر استاندارد باید برگردد اما ممکن است ادامه یابد.
                      • یک مثال:
                      • یک کاربر تایید شده تابعی مانند تابع myTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values) را فراخوانی می کند..
                      • myTransferFrom موجودی آدرس های _from و _to را برای همه _id و _values به روز می کند.
                      • myTransferFrom TransferBatch را با جزئیات آنچه از آدرس _from به آدرس _به منتقل شده است منتشر می کند.
                      • myTransferFrom بررسی می کند که آیا _to یک آدرس قرارداد است یا خیر و تشخیص می دهد که چنین است (اگر نه، انتقال را می توان موفق در نظر گرفت).
                      • در این مرحله Mytransferfrom باید بلافاصله معامله را برگرداند زیرا دریافت نشانه (ها) صریحاً توسط عملکرد onerc1155batchreceived پذیرفته نشده است.
                      • اگر با این حال mytransferfrom مایل به ادامه آن باشد ، باید از supportsinterface (0x4e2312e0) در _to تماس بگیرد و اگر مقدار ثابت را برگرداند ، معامله باید برگردانده شود ، زیرا اکنون مشخص شده است که یک گیرنده معتبر است و مرحله پذیرش قبلی شکست خورد.
                      • توجه: اگر می خواستید قبلاً آن اطلاعات را جمع آوری کرده و عمل کنید ، مانند سناریوی استانداردهای ترکیبی ، می توانید در یک مرحله قبل از SuppliNterface (0x4e2312e0) تماس بگیرید.
                        • توجه: این ممکن است در صورت ارسال به آدرس که انتظار دریافت نشانه های ERC-1155 را ندارد ، به نشانه های غیرقابل برگشت منجر شود.
                        • مانده هایی که به روز شده اند باید دارای رویدادهای انتقال معادل ساطع شده باشند.
                        • اگر این قرارداد باشد ، باید یک آدرس گیرنده بررسی شود و در صورت لزوم عملکرد (های) ERC1155TokenReceiver HOOK باید از آن فراخوانی شود.
                        • تعادل (و وقایع مرتبط) که در تماس با یک قلاب ERC1155TokenReceiver ارجاع می شوند ، باید قبل از اینکه قلاب ERC1155TokenReceiver فراخوانی شود ، به روز شود (و ساطع می شود).
                        • مقادیر بازگشت توابع قلاب ERC1155TokenReceiver که خوانده می شوند در صورت اجرای آنها باید رعایت شود.
                        • فقط توابع انتقال غیر استاندارد ممکن است اجازه دهد تا نشانه ها به یک قرارداد گیرنده ارسال شود که عملکردهای لازم برای قلاب ERC1155TokenReceiver را اجرا نمی کند. SafeTransferFrom و SafeBatchTransferFrom باید در این مورد برگردند (مگر اینکه این یک اجرای استانداردهای ترکیبی باشد "سازگاری به عقب" را ببینید).
                        • Minting/ایجاد و سوزاندن/از بین بردن قوانین:

                        یک عملیات نعناع/ایجاد در اصل یک انتقال تخصصی است و باید این قوانین را رعایت کند:

                        • برای پخش وجود شناسه توکن بدون تعادل اولیه ، قرارداد باید رویداد انتقال از 0x0 به 0x0 را منتشر کند ، با خالق توکن به عنوان _operator و یک _Value از 0.
                          • "قوانین رویداد Transfersingle و TransfertBatch" باید مطابق مناسب برای نعناع (ها) (یعنی تک آهنگ ها یا دسته ها) دنبال شود ، اما استدلال _FROM باید روی 0x0 (یعنی آدرس صفر) تنظیم شود تا انتقال به عنوان نعناع به ناظران پیمانکاری پرچم گذاری شود.
                          • توجه: این شامل نشانه هایی است که تعادل اولیه در قرارداد به آنها داده می شود. تعادل قرارداد همچنین باید بتواند با وقایع به تنهایی مشخص شود به این معنی که مانده های اولیه قرارداد (به عنوان مثال در ساخت و ساز) باید وقایع را منتشر کنند تا این تعادل را نیز منعکس کند.
                            • "قوانین رویداد Transfersingle و TransfertBatch" باید برای سوختگی (ها) (یعنی تک آهنگ ها یا دسته ها) پیروی شود ، اما استدلال _to باید روی 0x0 (یعنی آدرس صفر) تنظیم شود تا انتقال به عنوان سوختگی به ناظران قرارداد را پرچم گذاری کند.
                            • هنگام سوزاندن/از بین بردن شما مجبور نیستید در واقع به 0x0 منتقل شوید (که خاص آن است) ، فقط آرگومان _to در این رویداد باید مطابق بالا روی 0x0 تنظیم شود.
                            • حتی در یک مورد استانداردهای غیر ایمن و/یا ترکیبی ، قوانین رویداد فوق هنوز هم باید هنگام مینینگ/ایجاد یا سوزاندن/از بین بردن رعایت شود.
                            • نمونه ای از استحکام از keccak256 ثابت برای مقادیر جادویی مختلف (این ممکن است توسط اجرای استفاده شود):

                            ابرداده

                            مقدار URI امکان تعویض شناسه توسط مشتری را فراهم می کند. اگر رشته در هر URI وجود داشته باشد ، مشتریان باید این کار را با شناسه توکن واقعی به شکل شش ضلعی جایگزین کنند. این امر به تعداد زیادی از نشانه ها اجازه می دهد تا با تعریف یک URI یک بار ، برای تعداد زیادی از نشانه ها ، از همان رشته های زنجیره ای استفاده کنند.

                            قالب رشته شناسه شش ضلعی جایگزین باید حروف الفبا باشد: [0-9A-F] بدون پیشوند 0x.

                            • قالب رشته شناسه شش ضلعی جایگزین باید در صورت لزوم صفر را به طول 64 کاراکتر هگز هدایت کند.
                            • نمونه ای از چنین URI: https: //token-cdn-domain/. json با https جایگزین می شود: //token-cdn-domain/000000000000000000000000000000000000000000000000CCE0. JSON اگر مشتری ارجاع می دهد 314592

                            پسوندهای فوق داده

                            پسوند ERC1155METADATA_URI اختیاری را می توان با تشخیص رابط استاندارد ERC-165 شناسایی کرد.

                            اگر پسوند ERC1155METADATA_URI اختیاری شامل شود:

                            اگر 0x0E89341C از طریق آرگومان رابط منتقل شود ، عملکرد ERC-165 پشتیبانی می کند که باید مقدار ثابت را واقعی برگرداند.

                            • اگر تغییر با یک رویداد قابل بیان باشد ، تغییرات در URI باید رویداد URI را منتشر کند (یعنی پویا/برنامه ای نیست).
                            • یک اجرای ممکن است رویداد URI را در طی یک عمل نعنا منتشر کند اما اجباری نیست. در صورت عدم انتشار ، یک ناظر ممکن است در زمان نعناع از عملکرد URI ، ابرداده Uri را در زمان نعناع از عملکرد URI واکشی کند.
                              • طرحواره ERC-1155 ابرداده uri json

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

                              قالب رشته شناسه شش ضلعی جایگزین باید حروف الفبا باشد: [0-9A-F] بدون پیشوند 0x.

                              • قالب رشته شناسه شش ضلعی جایگزین باید در صورت لزوم صفر را به طول 64 کاراکتر هگز هدایت کند.
                              • نمونه ای از چنین URI: https: //token-cdn-domain/. json با https جایگزین می شود: //token-cdn-domain/000000000000000000000000000000000000000000000000CCE0. JSON اگر مشتری ارجاع می دهد 314592

                              بومی سازی

                              بومی سازی ابرداده باید برای افزایش یکنواختی ارائه در همه زبانها استاندارد شود. به همین ترتیب ، یک روش پوشش ساده برای فعال کردن محلی سازی ارائه شده است. اگر پرونده ابرداده JSON حاوی یک ویژگی محلی سازی باشد ، ممکن است از محتوای آن برای تهیه مقادیر بومی شده برای زمینه هایی که به آن نیاز دارند استفاده شود. ویژگی محلی سازی باید یک زیر هدف با سه ویژگی باشد: URI ، پیش فرض و محلی. اگر رشته در هر URI وجود داشته باشد ، باید توسط همه نرم افزارهای مشتری با محل انتخاب شده جایگزین شود.

                              json schema

                              نمونه موضعی

                              تصویب

                              عملکرد SetApprovalForall به یک اپراتور اجازه می دهد تا کل مجموعه نشانه ها را به نمایندگی از تأیید کننده مدیریت کند. برای اجازه تأیید زیر مجموعه ای از شناسه های توکن ، رابط کاربری مانند رابط تأیید Scoped ERC-1761 پیشنهاد شده است. همتای تأیید شده برای هر وضعیتی که توسط SetApprovalForall تعیین شده است ، درون نگری فراهم می کند.

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

                              بنیاد و پایه

                              گزینه های فوق داده

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

                              عملکرد نام (برای نام دارایی های قابل خواندن انسان ، زنجیره ای) از استاندارد حذف شد تا به ابرداده JSON اجازه دهد نام دارایی قطعی باشد و کپی کردن داده ها را کاهش دهد. این امر همچنین باعث می شود تا محلی سازی برای نام ها ، که در غیر این صورت هر رشته زبان در زنجیره ای ذخیره می شود ، گران قیمت خواهد بود ، و به ذکر نفخ رابط استاندارد نیست. در حالی که این تصمیم ممکن است یک بار کوچک برای مجریان برای میزبانی یک فایل JSON حاوی ابرداده اضافه کند ، ما معتقدیم که هرگونه اجرای جدی ERC-1155 در حال حاضر از ابرداده JSON استفاده خواهد کرد.

                              ارتقاء

                              الزام به انتشار Transfersingle یا Transferbatch در تغییر تعادل حاکی از آن است که اجرای معتبر ERC-1155 مجدداً به آدرس قرارداد جدید باید رویدادها را از آدرس قرارداد جدید منتشر کند تا در حالت نهایی قرارداد کاهش یافته باشد. معتبر است که فقط تعداد حداقل رویدادها را منتشر کنید تا تنها تعادل نهایی را منعکس کنید و تمام معاملات را که منجر به آن حالت شده است حذف کنید. الزام انتشار این رویداد اطمینان از این است که وضعیت فعلی قرارداد همیشه فقط از طریق رویدادها قابل ردیابی است. برای کاهش نیاز به انتشار رویدادها هنگام تغییر آدرس قرارداد ، استفاده از الگوی پروکسی را در نظر بگیرید ، مانند شرح داده شده در EIP-2535. این همچنین از ارائه آدرس قرارداد پایدار برای کاربران سود بیشتری خواهد داشت.

                              تصمیم طراحی: پشتیبانی از غیر دسته ای

                              این استاندارد از توابع SafetransferFrom و onerC115555 استفاده می کند زیرا آنها برای نقل و انتقالات از نوع توکن به طور قابل توجهی ارزان تر هستند ، که مطمئناً یک مورد استفاده مشترک است.

                              تصمیم طراحی: فقط نقل و انتقالات ایمن

                              این استاندارد فقط از نقل و انتقالات به سبک ایمن پشتیبانی می کند ، و این امکان را برای قراردادهای گیرنده فراهم می کند که به عملکرد EnerC1155555555555555555555555.

                              اثری از ورود به سیستم تضمین شده

                              از آنجا که اکوسیستم Ethereum همچنان در حال رشد است ، بسیاری از DAPP ها برای بازیابی و طبقه بندی داده ها به پایگاه داده های سنتی و خدمات API Explorer متکی هستند. استاندارد ERC-1155 تضمین می کند که گزارش های رویداد ساطع شده توسط قرارداد هوشمند ، داده های کافی را برای ایجاد یک سابقه دقیق از تمام مانده های فعلی توکن فراهم می کند. یک پایگاه داده یا اکسپلورر ممکن است به رویدادها گوش کند و بتواند جستجوهای ایندکس و طبقه بندی شده از هر نشانه ERC-1155 را در قرارداد ارائه دهد.

                              تصویب

                              عملکرد SetApprovalForall به یک اپراتور اجازه می دهد تا کل مجموعه نشانه ها را به نمایندگی از تأیید کننده مدیریت کند. برای اجازه تأیید زیر مجموعه ای از شناسه های توکن ، رابط کاربری مانند رابط تأیید Scoped ERC-1761 پیشنهاد شده است. همتای تأیید شده برای هر وضعیتی که توسط SetApprovalForall تعیین شده است ، درون نگری فراهم می کند.

                              محدود کردن تأیید به مجموعه خاصی از شناسه های نشانه ، مقادیر یا سایر قوانین ممکن است با یک رابط اضافی یا یک قرارداد خارجی انجام شود. دلیل منطقی این است که ERC-1155 را تا حد امکان عمومی برای همه موارد استفاده بدون تحمیل یک طرح تأیید خاص در مورد پیاده سازی هایی که ممکن است به آن احتیاج نداشته باشد ، نگه دارد. از رابط های تأیید توکن استاندارد می توان استفاده کرد ، مانند رابط تأیید SCOPED ERC-1761 پیشنهادی که با ERC-1155 سازگار است.

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

                              در طول بحث های طراحی الزاماتی وجود داشته است که این استاندارد هنگام ارسال به آدرس های قرارداد ، به ویژه ERC-721 در زمان نوشتن ، با استانداردهای موجود سازگار باشد. برای پذیرایی از این سناریو ، در صورت عدم اجرای یک قرارداد ، با توجه به بخش "قوانین انتقال ایمن" در بالا ، به طور خاص "سناریو شماره 3: گیرنده عملکرد رابط ERC1155TokenReceiver را پیاده سازی نمی کند ، برخی از افراد با منطق بازگرداندن وجود دارد."

                              از این رو در اجرای قرارداد ترکیبی ERC-1155 باید یک تماس اضافی در مورد قرارداد گیرنده انجام شود و قبل از هرگونه تماس قلاب به onerc1155receive یا onerc1155batchreceived بررسی شود. بنابراین ترتیب کار باید باشد:

                              اجرای باید با استفاده از عملکرد گیرنده (0x4e2312e0) در قرارداد گیرنده تماس بگیرد و حداقل 10،000 گاز را تأمین کند.

                              1. اگر تماس عملکرد موفق شود و مقدار بازده مقدار ثابت باشد ، اجرای آن به عنوان یک اجرای منظم ERC-1155 انجام می شود ، با تماس (ها) به قلاب های EnerC1155Received یا Enerc1155batchreceive و قوانین مرتبط.
                              2. اگر تماس عملکردی از بین نرود یا مقدار بازده مقدار ثابت نباشد ، اجرای می تواند فرض کند که قرارداد گیرنده یک ERC1155TokenReceiver نیست و از قوانین استاندارد دیگر آن برای نقل و انتقالات پیروی می کند.
                              3. توجه داشته باشید که اجرای خالص یک استاندارد واحد به جای یک راه حل ترکیبی توصیه می شود ، اما نمونه ای از قرارداد ترکیبی ERC-1155/ERC-721 در بخش منابع تحت اجراها مرتبط است.

                              نکته مهم این است که حتی اگر نشانه ها با قوانین استاندارد دیگری ارسال شوند ، رویدادهای انتقال ERC-1155 هنوز باید منتشر شود. این به این ترتیب است که طبق قوانین استاندارد ERC-1155 ، می توان تعادل را به تنهایی از طریق وقایع تعیین کرد.

                              استفاده

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

                              نقل و انتقالات دسته ای

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

                              یکی دیگر از مزیت های نقل و انتقالات دسته ای استاندارد ، توانایی یک قرارداد هوشمند برای پاسخ به انتقال دسته ای در یک عملیات واحد با استفاده از onerc1155batchreceived است.

                              توصیه می شود که مشتری ها و کیف پول ها هنگام ارسال انتقال دسته ای ، شناسه های توکن و مقادیر مرتبط (به ترتیب صعودی) را مرتب کنند ، زیرا برخی از پیاده سازی های ERC-1155 هنگام مرتب سازی شناسه ، صرفه جویی قابل توجهی در هزینه گاز را ارائه می دهند. برای نمونه ای از این موارد ، به بازی های Horizon Games - اجرای استاندارد "بسته بندی شده بسته بندی شده" مراجعه کنید.

                              تعادل دسته

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

                              شمارش از وقایع

                              به منظور حفظ روشن کردن الزامات ذخیره سازی برای قراردادهای اجرای ERC-1155 ، شمارش (کشف شناسه ها و مقادیر نشانه ها) باید با استفاده از سیاهههای مربوطه انجام شود. توصیه می شود مشتریانی مانند مبادله و کاوشگران blockchain یک پایگاه داده محلی حاوی شناسه توکن ، تأمین و URI را در حداقل حفظ کنند. این می تواند از هر رویداد Transfersingle ، TransfertBatch و URI ساخته شود ، از بلوک شروع می شود که قرارداد هوشمند تا آخرین بلوک مستقر شده است.

                              بنابراین قراردادهای ERC-1155 باید با دقت از رویدادهای انتقال یا Transfermbatch در هر نمونه ای که نشانه ها ایجاد می شوند ، ذوب می شوند ، منتقل می شوند یا از بین می برند.

                              نشانه های غیرقانونی

                              استراتژی های زیر نمونه هایی از چگونگی ترکیب توکن های قارچ و غیر قابل استفاده در همان قرارداد است. استاندارد به نحوه اجرای یک اجرای باید این کار را صادر کند.

                              بیت های شناسه تقسیم

                              128 بیت برتر پارامتر UINT256 _ID در هر عملکرد ERC-1155 ممکن است شناسه پایه پایه را نشان دهد ، در حالی که 128 بیت پایین ممکن است شاخص غیرقانونی را نشان دهد تا آن را منحصر به فرد کند.

                              توکن های غیر قابل تغییر با استفاده از یک دسترسی دهنده مبتنی بر شاخص به مجموعه داده های قرارداد/توکن می توانند در تعامل باشند. بنابراین برای دسترسی به یک نشانه خاص در یک قرارداد داده مختلط و یک غیرقانونی خاص در آن مجموعه ، می توان به عنوان منتقل شد.

                              برای شناسایی یک مجموعه/دسته غیرقانونی به عنوان یک کل (یا یک قارچ) فقط می توانید از طریق آرگومان _id به عنوان شناسه پایه را عبور دهید. اگر اجرای شما از این تکنیک استفاده می کند ، این به طور طبیعی به معنای شاخص غیرقانونی است که باید 1 مبتنی بر باشد.

                              در داخل کد قرارداد ، دو قطعه از داده های مورد نیاز برای دسترسی به فرد غیرقانونی با UINT128 قابل استخراج است (

                              0) و همان ماسک با 128 تغییر یافت.~توجه داشته باشید که 128 یک شماره دلخواه است ، یک اجرای ممکن است انتخاب کند که چگونه آنها دوست دارند این تقسیم به عنوان مناسب برای مورد استفاده آنها باشد. ناظر این قرارداد به سادگی رویدادهایی را نشان می دهد که انتقال تعادل و نعناع اتفاق می افتد و ممکن است تعادل را با استفاده از آن اطلاعات به تنهایی ردیابی کند. برای اینکه یک ناظر بتواند نوع (غیر قربانی یا قارچ) را از یک شناسه به تنهایی تعیین کند ، آنها باید فرمت بیت های تقسیم شده را بر اساس اجرای آن بدانند.

                              اجرای مرجع ERC-1155 نمونه ای از استراتژی Split ID BITS است.

                              نشانه های غیرقانونی طبیعی

                              روش ساده دیگر برای نشان دادن غیر فنی ، اجازه دادن به حداکثر مقدار 1 برای هر نشانه غیرقانونی است. این به طور طبیعی دنیای واقعی را آینه می کند ، جایی که موارد منحصر به فرد دارای مقدار 1 و موارد قارچ است که دارای مقدار بیشتر از 1 هستند.

                              منابع

                              معیارها

                              اجرای

                              مقالات و بحث ها

                              کپی رایت

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

                              استناد

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

                              ویتک رادومسکی ، اندرو کوک ، فیلیپه کاستونگوی ، جیمز تین ، اریک بینت ، رونان ساندفورد ، "EIP-1155: استاندارد چند توکن" ، پیشنهادات بهبود اتریوم ، شماره. 1155 ، ژوئن 2018. [سریال آنلاین]. موجود: https://eips. ethereum.org/eips/eip-1155.

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

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

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