بررسی اجمالی بندر

بندر یک قرارداد بازار برای ایجاد ایمن و کارآمد سفارشات برای موارد ERC721 و ERC1155 است. هر سفارش حاوی تعداد دلخواه از مواردی است که پیشنهاد دهنده مایل به ارائه ("پیشنهاد") به همراه تعداد دلخواه مواردی است که باید همراه با گیرنده های مربوطه ("توجه") دریافت شود.

فهرست مطالب

• سفارش
• تحقق
• توالی رویدادها
• محدودیت ها و راه حل های شناخته شده

سفارش

هر سفارش شامل یازده مؤلفه کلیدی است:

• پیشنهاد دهنده سفارش کلیه موارد ارائه شده را تأمین می کند و باید سفارش را شخصاً (یعنی msg. sender == پیشنهاد دهنده) انجام دهد یا سفارش را از طریق امضا تأیید کند (یا استاندارد 65 بایت EDCSA ، 64 بایت EIP-2098 یا EIP-1271 بررسی isvalidsignature) یا با لیست سفارش در زنجیره (یعنی اعتبار سنجی).
• منطقه سفارش یک حساب ثانویه اختیاری است که با دو امتیاز اضافی به سفارش متصل است:
  • این منطقه ممکن است با فراخوانی Cancel سفارشاتی را که در آن به عنوان منطقه معرفی شده است ، لغو کند.(توجه داشته باشید که ارائه دهندگان می توانند سفارشات خود را نیز به صورت جداگانه یا برای کلیه سفارشات امضا شده با پیشخوان فعلی خود به طور هم زمان با فراخوانی IncrementCounter لغو کنند).
  • سفارشات "محدود" (همانطور که توسط نوع سفارش مشخص شده است) یا باید توسط منطقه یا پیشنهاد دهنده اجرا شود ، یا باید مطابق با تماس با یک نماینده معتبر در منطقه تأیید شود.
  • The MatheMtype نوع مورد را مشخص می کند ، با انواع معتبر اتر (یا سایر نشانه های بومی برای زنجیره داده شده) ، ERC20 ، ERC721 ، ERC1155 ، ERC721 با "معیارها" (در زیر توضیح داده شده) و ERC1155 با معیارها.
  • توکن حساب قرارداد توکن مورد را تعیین می کند (با آدرس تهی که برای اتر یا سایر نشانه های بومی استفاده می شود).
  • شناسه های شناسه یا شناسه توکن ERC721 یا ERC1155 یا در مورد نوع مورد مبتنی بر معیارها ، یک ریشه مرکل متشکل از مجموعه معتبر از شناسه های توکن برای مورد را نشان می دهد. این مقدار برای انواع موارد اتر و ERC20 نادیده گرفته می شود و می تواند به صورت اختیاری برای انواع موارد مبتنی بر معیارها صفر باشد تا هر شناسه ای را فراهم کند.
  • StartAmount نشان دهنده مقدار مورد مورد نظر است که در صورت تحقق سفارش در لحظه فعال شدن سفارش لازم خواهد بود.
  • Endamount نشان دهنده میزان مورد مورد نظر است که در صورت تحقق سفارش در لحظه انقضاء سفارش لازم خواهد بود. اگر این مقدار با شروع کالای مورد متفاوت باشد ، مقدار تحقق یافته به صورت خطی بر اساس زمان سپری شده از زمان فعال شدن سفارش محاسبه می شود.
  • کامل نشان می دهد که این سفارش از پر کردن جزئی پشتیبانی نمی کند ، در حالی که جزئی امکان پر کردن بخشی از سفارش را فراهم می کند ، با احتیاط مهمی که هر مورد باید توسط بخش تأمین شده قابل تقسیم باشد (یعنی هیچ باقی مانده پس از تقسیم).
  • باز نشان می دهد که تماس برای اجرای سفارش توسط هر حساب می تواند ارسال شود ، در حالی که محدود شده مستلزم اجرای سفارش توسط پیشنهاد دهنده یا منطقه سفارش است ، یا اینکه یک مقدار جادویی که نشان می دهد سفارش در هنگام تماس تأیید شده است ، بازگردانده می شودمعتبر در منطقه.
  تحقق

  سفارشات از طریق یکی از چهار روش انجام می شود:

  • فراخوانی یکی از دو کارکرد "استاندارد" ، تحقق و تحقق بخشنده ، که در آن یک دستور دوم ضمنی با تماس گیرنده به عنوان پیشنهاد دهنده ساخته می شود ، در نظر گرفتن سفارش تحقق یافته به عنوان پیشنهاد ، و پیشنهاد سفارش تحقق یافته به عنوان توجه (باسفارشات "پیشرفته" حاوی کسری که باید در کنار مجموعه ای از "حل کننده معیارها" که یک شناسه را تعیین می کنند و یک اثبات ورود به سیستم مربوط به هر مورد مبتنی بر معیارها بر روی ترتیب برآورده شده است). کلیه موارد پیشنهادی از پیشنهاد دهنده سفارش به تحقق بخش منتقل می شود ، سپس کلیه موارد ملاحظه از Fuffiller به گیرنده نامگذاری شده منتقل می شود.
  • فراخوانی با عملکرد "اساسی" ، با استفاده از یکی از شش نوع مسیر اساسی ارائه شده (ETH_TO_ERC721 ، ETH_TO_ERC1155 ، ERC20_TO_ERC721 ، ERC20_TO_ERC1155 ، ERC721_TO_ERC20 و ERC1155_TO_ERC20)ذیل:
    • این سفارش فقط حاوی یک مورد پیشنهادی واحد است و حداقل یک مورد در نظر گرفته شده است.
    • این سفارش دقیقاً شامل یک مورد ERC721 یا ERC1155 است و آن مورد مبتنی بر معیارها نیست.
    • پیشنهاد دهنده سفارش گیرنده اولین مورد در نظر گرفته شده است.
    • تمام موارد دیگر دارای یک اتر (یا سایر توکن های بومی) یا نوع و نشانه های ERC20 هستند.
    • این سفارش کالای با اتر (یا سایر نشانه های بومی) را به عنوان نوع مورد آن ارائه نمی دهد.
    • StartAmount در هر مورد باید با Endamount آن مورد مطابقت داشته باشد (یعنی موارد نمی توانند مقدار صعودی/نزولی داشته باشند).
    • تمام قسمتهای مورد "نادیده گرفته شده" (یعنی توکن و شناسه های مربوط به آیتم های بومی و شناسه های موجود در موارد ERC20) روی آدرس تهی یا صفر تنظیم شده اند.
    • اگر سفارش دارای یک مورد ERC721 باشد ، آن مورد مقدار 1 دارد.
    • اگر این سفارش دارای چندین مورد در ملاحظه باشد و کلیه موارد ملاحظه ای غیر از اولین مورد در ملاحظه دارای نوع موردی است که مورد آن است ، مبلغ مورد ارائه شده کمتر از مبلغ کلیه مبلغ مورد توجه است که به استثنای اولین مبلغ مورد توجه است.

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

    • در مقایسه با روش اصلی "مسیرهای داغ" ساده به CallData اضافی نیاز دارد.
    • این امر مستلزم تأیید کننده هر مورد در نظر گرفته شده است ، حتی اگر مورد توجه را با استفاده از یک مورد پیشنهاد انجام شود (معمولاً در صورت انجام سفارش که موارد ERC20 را برای یک مورد ERC721 یا ERC1155 ارائه می دهد ، انجام می شود و همچنین شامل موارد ملاحظه ای با همان موارد در نظر گرفته شده است. نوع مورد ERC20 برای پرداخت هزینه).
    • این می تواند منجر به نقل و انتقالات غیر ضروری شود ، در حالی که در مورد "مسابقه" این نقل و انتقالات را می توان به یک مجموعه حداقل تر کاهش داد.
    تعادل و الزامات تأیید

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

    • پیشنهاد دهنده باید تعادل کافی از همه موارد ارائه شده داشته باشد.
    • اگر این سفارش برای استفاده از مجرای نشان نمی دهد ، پیشنهاد دهنده باید مصوبات کافی برای قرارداد بندر برای کلیه موارد ارائه شده ERC20 ، ERC721 و ERC1155 داشته باشد.
    • اگر این دستور برای استفاده از مجرای استفاده شود ، پیشنهاد دهنده باید مصوبات کافی برای قرارداد مجرای مربوطه برای کلیه موارد ارائه شده ERC20 ، ERC721 و ERC1155 داشته باشد.

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

    • بررسی های فوق باید انجام شود تا اطمینان حاصل شود که پیشنهاد دهنده هنوز تعادل و مصوبات کافی دارد.
    • تحقق دهنده باید تعادل کافی از همه موارد در ملاحظه داشته باشد ، به جز مواردی که دارای نوع موردی است که با نوع کالای ارائه شده با سفارش مطابقت دارد - به عنوان مثال ، اگر سفارش تحقق یافته یک مورد ERC20 را ارائه دهد و به یک مورد ERC721 به پیشنهاد دهنده و همان ERC20 نیاز داشته باشد. مورد برای گیرنده دیگر ، تحقق دهنده باید کالای ERC721 را در اختیار داشته باشد اما نیازی به مالکیت کالای ERC20 ندارد زیرا از پیشنهاد دهنده تهیه می شود.
    • اگر Fumfiller برای استفاده از مجرای انتخاب نمی کند ، آنها باید مصوبات کافی را برای قرارداد بندر برای کلیه موارد ERC20 ، ERC721 و ERC1155 به ترتیب به جز موارد ERC20 با نوع موردی که با نوع موردی ارائه شده سفارش داده شده است ، داشته باشند. نوع.
    • اگر Fulfiller برای استفاده از مجرای انتخاب کند ، آنها باید مصوبات کافی برای مجرای مربوطه برای همه موارد ERC20 ، ERC721 و ERC1155 در سفارش انجام شده به جز موارد ERC20 با یک نوع موردی که مطابق با نوع کالای ارائه شده سفارش است ، داشته باشد. بشر
    • اگر دستور برآورده شده اتر (یا سایر نشانه های بومی) را به عنوان موارد در نظر گرفته شود ، برآورده کننده باید بتواند مجموع این موارد را به عنوان msg. value تأمین کند.

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

    • بررسی های فوق باید انجام شود تا اطمینان حاصل شود که پیشنهاد دهنده هنوز تعادل و مصوبات کافی دارد.
    • پس از دریافت کلیه موارد ارائه شده ، باید تعادل کافی از همه موارد در ملاحظه داشته باشد - به عنوان مثال ، اگر دستور تحقق یافته یک مورد ERC20 را ارائه می دهد و به یک مورد ERC721 به پیشنهاد دهنده و همان مورد ERC20 نیاز دارد تا با مبلغی کمتر از گیرنده دیگری به گیرنده دیگری نیاز داشته باشد. یا برابر با مبلغ ارائه شده ، تحقق دهنده نیازی به مالکیت کالای ERC20 ندارد زیرا برای اولین بار از پیشنهاد دهنده دریافت می شود.
    • اگر Fumfiller برای استفاده از مجرای انتخابی انتخاب نکند ، آنها باید مصوبات کافی برای قرارداد بندر برای کلیه موارد ERC20 ، ERC721 و ERC1155 در نظر بگیرند.
    • اگر Fumfiller برای استفاده از مجرای انتخاب کند ، آنها باید مصوبات کافی را برای مجرای مربوطه برای همه موارد ERC20 ، ERC721 و ERC1155 در نظر بگیرند.
    • اگر دستور برآورده شده اتر (یا سایر نشانه های بومی) را به عنوان موارد در نظر گرفته شود ، برآورده کننده باید بتواند مجموع این موارد را به عنوان msg. value تأمین کند.

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

    • هر حساب که منبع ERC20 ، ERC721 یا ERC1155 را برای اعدام که به عنوان بخشی از تحقق انجام می شود ، باید دارای تعادل و تأیید کافی در بندر یا مجرای نشان داده شده در زمان اجرای آن باشد. توجه داشته باشید که اعدام های قبلی ممکن است تراز لازم را برای اعدام های بعدی تأمین کند.
    • مجموع کلیه اعدام های مربوط به اتر (یا سایر نشانه های بومی) باید به عنوان msg. value تهیه شود. توجه داشته باشید که اعدام هایی که پیشنهاد دهنده و گیرنده همان حساب هستند از مجموعه اجرای نهایی فیلتر می شوند.
    پر کردن جزئی

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

    • هنگام ایجاد دستوراتی که از پر کردن جزئی یا تعیین کسری برای پر کردن آن سفارشات پشتیبانی می کند ، کلیه موارد (هم ارائه و هم در نظر گرفته شده) در سفارش باید توسط بخش عرضه شده قابل پاک باشد (یعنی هیچ باقی مانده پس از تقسیم).
    • اگر کسری مورد نظر برای پر کردن بیشتر از مبلغ سفارش کامل باشد ، آن کسری به مقدار باقی مانده برای پر کردن کاهش می یابد. این امر در مورد هر دو تلاش پر کردن جزئی و همچنین تلاش های پر کردن کامل صدق می کند. اگر این رفتار مورد نظر نباشد (یعنی پر کردن باید "همه یا هیچ یک" باشد) ، برآورده کننده می تواند در صورت موجود بودن از یک روش سفارش "اساسی" استفاده کند (که نیاز به پر شدن مقدار کامل سفارش دارد) ، یا از "مطابقت" استفاده کنیدروش سفارش را سفارش دهید و صریحاً سفارش را ارائه دهید که نیاز به مبلغ کامل مورد نظر داشته باشد.
      • به عنوان مثال: اگر یک فرد تحقق دهنده سعی کند 1/2 سفارش را پر کند اما یک تحقق دهنده دیگر ابتدا 3/4 سفارش را پر می کند ، تحقق اصلی در نهایت با پر کردن 1/4 از سفارش خواهد بود.
      • به عنوان مثال: یک پیشنهاد دهنده می تواند یک سفارش جزئی پر برای تهیه حداکثر 10 ETH برای حداکثر 10 مورد ERC721 از یک مجموعه داده شده ایجاد کند. سپس ، هر تحقق دهنده می تواند بخشی از آن سفارش را پر کند تا زمانی که به طور کامل پر شود (یا لغو شود).
      توالی رویدادها سفارش

      هنگام انجام سفارش از طریق Fourfillorder یا FourfillAdvancedOndorder:

      1. سفارش هش
         • هش را برای ارائه موارد ارائه و موارد در نظر بگیرید
         • پیشخوان فعلی را برای پیشنهاد دهنده بازیابی کنید
         • هش را برای سفارش استخراج کنید
      2. اعتبار سنجی اولیه را انجام دهید
         • اطمینان حاصل کنید که زمان فعلی در محدوده سفارش است
         • اطمینان از تماس گیرنده معتبر برای نوع سفارش ؛اگر نوع سفارش محدود شده و تماس گیرنده پیشنهاد دهنده یا منطقه نیست ، با منطقه تماس بگیرید تا مشخص شود آیا سفارش معتبر است
      3. بازیابی و به روزرسانی وضعیت سفارش
         • اطمینان حاصل کنید که سفارش لغو نشده است
         • اطمینان حاصل کنید که سفارش به طور کامل پر نشده است
           • اگر سفارش تا حدی پر شده است ، در صورت لزوم مقدار پر شده را کاهش دهید تا سفارش بیش از حد پر نشود
         • در صورت عدم تأیید اعتبار ، امضای سفارش را تأیید کنید
         • کسری را برای پر کردن بر اساس اولویت + مقدار موجود تعیین کنید
         • وضعیت سفارش به روزرسانی (اعتبار سنجی + کسری پر)
      4. مقدار برای هر مورد را تعیین کنید
         • مبلغ شروع و پایان را مقایسه کنید
           • اگر آنها برابر هستند: کسری را برای هر یک استفاده کنید ، اطمینان حاصل کنید که آن را به صورت تمیز تقسیم کنید و از آن مقدار استفاده کنید
           • اگر اینطور نیست: کسری را برای هر دو اعمال کنید ، اطمینان حاصل کنید که هر دو آنها به صورت تمیز تقسیم می شوند ، سپس بر اساس زمان فعلی ، تناسب خطی را پیدا کنید
      5. معیارها را اعمال کنید
         • اطمینان حاصل کنید که هر معیار حل کننده به یک مورد سفارش مبتنی بر معیارها اشاره دارد
         • اطمینان حاصل کنید که اگر مورد دارای ریشه معیارهای غیر صفر باشد ، شناسه عرضه شده برای هر مورد از طریق اثبات گنجاندن معتبر است
         • هر نوع و شناسه مورد را به روز کنید
         • اطمینان حاصل کنید که تمام موارد باقیمانده مبتنی بر معیارها هستند
      6. رویداد سفارش داده شده را منتشر کنید
         • موارد به روز شده را درج کنید (یعنی پس از تنظیم مبلغ و وضوح معیارها)
      7. انتقال موارد ارائه دهنده از پیشنهاد دهنده به تماس گیرنده
         • بسته به نوع سفارش ، از مجرای یا بندر مستقیماً برای مصوبات منبع استفاده کنید
      8. موارد ملاحظه را از تماس گیرنده به گیرندگان مربوطه منتقل کنید
         • بسته به اولویت بیان شده تحقق بخش ، از مجرای یا بندر مستقیماً برای مصوبات منبع استفاده کنید

      توجه: انجام کار با روش مشابه ، با چند استثناء کار می کند: این ترتیب را از زیر مجموعه ای از عناصر سفارش بازسازی می کند ، از تنظیم میزان مناسب و وضوح معیارها استفاده می کند ، نیاز دارد که مبلغ سفارش کامل پر شود ، و حداقل مجموعه ای از حداقل مجموعه را انجام می دهدنقل و انتقالات به طور پیش فرض هنگامی که کالای پیشنهادی همان نوع و نشانه های مورد نظر اضافی را به اشتراک می گذارد.

      سفارشات مطابقت

      هنگام تطبیق گروهی از سفارشات از طریق مطابقت یا MatchAdvancedorders ، مراحل 1 تا 6 تقریباً یکسان هستند اما برای هر سفارش تهیه شده انجام می شود. از آنجا ، اجرای از تحقق استانداردها منحرف می شود:

      1. تحقق را اعمال کنید
         • اطمینان حاصل کنید که هر تحقق به یک یا چند مورد پیشنهادی و یک یا چند مورد در ملاحظه اشاره دارد ، همه با همان نوع و نشانه ، و با همان منبع تأیید برای هر مورد ارائه و همان گیرنده برای هر مورد در نظر گرفته شده
         • مبلغ موجود در هر مورد و هر مورد در نظر گرفته شده را به صفر کاهش دهید و مبلغ کاهش یافته کل را برای هر یک ردیابی کنید
         • مبلغ کل را برای هر یک مقایسه کنید و مبلغ باقیمانده را به اولین مورد در قسمت مناسب سفارش اضافه کنید
         • برای هر تحقق یک اعدام واحد برگردانید
      2. هر مورد در نظر گرفته شده را اسکن کنید و اطمینان حاصل کنید که هیچ کدام هنوز مقدار غیرزرو باقی مانده است
      3. انتقال را به عنوان بخشی از هر اعدام انجام دهید
         • بسته به نوع سفارش اصلی ، از مجرای یا بندر مستقیماً برای مصوبات منبع استفاده کنید
         • نادیده گرفتن هر اعدام از کجا به == از یا مقدار == 0 (توجه: اجرای فعلی این آخرین بهینه سازی را انجام نمی دهد)
      محدودیت ها و راه حل های شناخته شده
      • از آنجا که کلیه موارد ارائه و ملاحظه در حافظه در مقابل یکدیگر اختصاص می یابد ، سناریوهایی وجود دارد که در آن مبلغ مورد دریافتی واقعی با مبلغ مشخص شده توسط سفارش متفاوت خواهد بود-به ویژه ، این شامل مواردی با مکانیک انتقال هزینه است. سفارشات حاوی مواردی از این طبیعت (یا به طور گسترده تر ، مواردی که دارای برخی از وضعیت پس از تحقق هستند که باید برآورده شوند) باید انواع سفارش "محدود" را اعمال کنند و سفارش را از طریق یک قرارداد منطقه ای انجام دهند که پس از انجام سفارش ، چک های لازم را انجام می دهدتکمیل شده است
      • از آنجا که کلیه موارد پیشنهادی به طور مستقیم از پیشنهاد دهنده گرفته می شود و کلیه موارد ملاحظه مستقیم به گیرنده نامگذاری شده داده می شود ، سناریوهایی وجود دارد که این حساب ها می توانند هزینه گاز تحقق سفارش را افزایش دهند یا بسته به کالای منتقل شده ، سفارشات را به طور کامل انجام دهند. اگر مورد مورد نظر اتر یا یک نشانه بومی مشابه باشد ، یک گیرنده می تواند برگشتی قابل پرداخت را پرتاب کند یا حتی گاز اضافی را نیز از ارسال کننده صرف کند. مکانیک های مشابه توسط هر دو پیشنهاد دهنده قابل استفاده است و در صورتی که مورد مورد نظر یک نشانه با قلاب انتقال (مانند ERC1155 و ERC777) یا اجرای توکن غیر استاندارد باشد ، دریافت می شود. اصلاحات احتمالی برای این دسته از شماره شامل بسته بندی اتر به عنوان WETH به عنوان یک بازپرداخت در صورت عدم موفقیت در انتقال اولیه و اجازه دادن به ارسال کنندگان برای مشخص کردن میزان گاز که باید به عنوان بخشی از یک تحقق معین اختصاص یابد. سفارشاتی که از تحقق صریح پشتیبانی می کنند نیز می توانند برای ترک کالاهای پیشنهادی مشکل ساز یا ناخواسته انتخاب کنند تا زمانی که تمام موارد ملاحظه به طور کامل دریافت شوند.
      • همانطور که ممکن است در هر دنباله ای انجام شود که تحقق بخش مشخص شود تا زمانی که تحقق همه اجرایی باشد ، زیرا سفارشات محدود شده از طریق مناطق قبل از اجرای تأیید می شوند ، و از آنجااگر یک گیرنده اتر قابل پرداخت یا قلاب انتقال 1155 قابل پرداخت باشد ، می تواند حالت اصلاح را در هنگام اجرای آن اصلاح کند. به عنوان مثال ، تصور کنید که یک پیشنهاد دهنده WETH را ارائه می دهد و به برخی از موارد ERC721 به عنوان مورد توجه نیاز دارد ، جایی که ERC721 باید دارای برخی از املاک اضافی مانند عدم استفاده از آن برای نعناع برخی دیگر از موارد ERC721 باشد. سپس ، حتی اگر پیشنهاد دهنده آن را اعمال کند که ERC721 از طریق یک دستور محدود که برای این ملک چک می کند ، دارای آن خاصیت است ، یک تحقق دهنده مخرب می تواند شامل مرتبه دوم (یا حتی فقط یک مورد در ملاحظات اضافی) باشد که از کالای ERC721 استفاده می کند که قبلاً به نعناع فروخته می شودبه پیشنهاد دهنده منتقل می شود. یک دسته از اصلاح برای این مشکل استفاده از سفارشات محدود است که ValidateOrder را پیاده سازی نمی کنند و در واقع مستلزم آن هستند که تحقق سفارش از طریق آنها هدایت شود تا آنها بتوانند اعتبارسنجی پس از تحقق را انجام دهند. راه حل جالب دیگر برای این مشکل که باعث ایجاد ترکیب سفارش می شود ، "مبارزه با آتش با آتش" است و ارائه دهنده ارائه دهنده "معتبر" ERC1155 در مورد سفارشاتی است که نیاز به تضمین های اضافی دارند. این می تواند یک قرارداد باشد که شامل رابط ERC1155 است اما در واقع یک نشانه 1155 نیست ، و در عوض از قلاب محاصره شده به عنوان ابزاری برای تأیید اینکه متغیرهای مورد انتظار تأیید شده اند ، استفاده می کنند ، در صورت عدم موفقیت "انتقال" بازگشتند (بنابراین در این مورداز مثال بالا ، این قلاب اطمینان حاصل می کند که پیشنهاد دهنده صاحب کالای ERC721 مورد نظر است و هنوز از آن برای نعناع دیگر ERC721 استفاده نشده است). محدودیت اصلی این مکانیک میزان داده هایی است که می توان از طریق این مسیر به صورت باند تهیه کرد. فقط سه استدلال ("از" ، "شناسه" و "مقدار") برای استفاده در دسترس هستند.
      • از آنجا که کلیه موارد ملاحظه در زمان ایجاد سفارش تهیه می شود ، تنظیم پویا دریافت کنندگان یا مبلغ پس از ایجاد (به عنوان مثال اصلاحات در اطلاعات پرداخت حق امتیاز) پشتیبانی نمی شود. با این حال ، یک منطقه می تواند اعمال کند که یک ترتیب محدود شده حاوی موارد جدید در ملاحظه محاسبه شده به صورت پویا با استخراج آنها و تهیه آنها به صورت دستی یا اطمینان از حضور آنها از طریق معتبر است زیرا موارد در نظر گرفتن می توانند به طور خودسرانه گسترش یابد ، با احتیاط مهمی که بیش از آن چیزی نیستمبلغ کالای پیشنهادی اصلی را می توان هزینه کرد.
      • از آنجا که تمام موارد مبتنی بر معیارها به یک نشانه خاص گره خورده اند ، هیچ روش بومی برای ساخت سفارشات وجود ندارد که موارد معیارهای متقاطع را مشخص کنند. علاوه بر این ، هر شناسه بالقوه برای یک مورد مبتنی بر معیارهای خاص باید به همان میزان هر شناسه دیگری داشته باشد.
      • از آنجا که سفارشاتی که حاوی مواردی با مقادیر صعودی یا نزولی هستند ممکن است به همان سرعتی که می خواهد پر شود (مثلاً معاملات بیشتر از آنچه انتظار می رود در آن باشد انجام می شود) پر نشود ، این خطر وجود دارد که تحقق آن سفارشات مقدار مورد بیشتری را تأمین کند ، یا مقدار بیشتریمبلغ مورد کوچکتر را از آنچه در نظر گرفته شده یا انتظار می رود ، دریافت کنید. یکی از راه های جلوگیری از این نتایج ، استفاده از همبستگی ها ، تهیه یک دستور متضاد برای تحقق دهنده است که صریحاً حداکثر موارد پیشنهادی مجاز را که باید خرج شود و مواردی را که باید دریافت کنند ، مشخص می کند. در هنگام دستیابی به دستوراتی که شامل مدت زمان مختصر و همچنین مواردی با مقادیر صعودی یا نزولی باشد ، باید مراقبت ویژه ای انجام شود ، زیرا ممکن است در یک پنجره کوتاه از زمان به طرز چشمگیری تغییر کند.
      • از آنجا که همه موارد موجود در سفارشات پشتیبانی از پر کردن جزئی باید هنگام انجام یک پر کردن جزئی "قابل پاک سازی" باشد ، سفارشات با چندین مورد باید با احتیاط ساخته شوند. یک اکتشافی ساده برای شروع با یک بسته نرم افزاری "واحد" (به عنوان مثال 1 مورد NFT A ، 3 NFT مورد B و 5 NFT مورد C برای 2 ETH) و سپس استفاده از یک چندگانه در آن بسته نرم افزاری واحد (به عنوان مثال 7 از این واحدها منجر به نتیجه می شود. سفارش جزئی برای 7 مورد NFT A ، 21 NFT مورد B و 35 NFT مورد C برای 14 ETH).
      • از آنجایی که اتر را نمی توان از یک حساب «گرفت» کرد، هر سفارشی که حاوی اتر یا سایر نشانه های بومی به عنوان آیتم پیشنهادی باشد (از جمله سفارش های آینه ای «ضمنی») باید توسط تماس گیرنده ای که سفارش(ها) را اجرا می کند به عنوان msg. value ارائه شود. این همچنین توضیح می دهد که چرا هیچ نوع مسیر سفارش اولیه ERC721_TO_ETH و ERC1155_TO_ETH وجود ندارد، زیرا در این موارد نمی توان اتر را از ارائه دهنده گرفت. یکی از نکات مهم این مکانیک این است که، از نظر فنی، هر کسی می تواند اتر را از طرف یک پیشنهاد دهنده خاص تامین کند (در حالی که خود پیشنهاد دهنده باید همه موارد دیگر را تامین کند). همچنین به این معنی است که تمام اترها باید در زمانی که سفارش یا گروهی از سفارش ها در ابتدا فراخوانی می شود عرضه شود (و مقدار موجود برای خرج کردن توسط آیتم های پیشنهادی نمی تواند توسط یک منبع خارجی در طول اجرا افزایش یابد، همانطور که در مورد موجودی توکن وجود دارد).
      • از آنجایی که درخواست کننده می تواند به طور دلخواه آرایه پرداختی را تنظیم کند، انجام هایی که در آن همه سفارش های منطبق قبلاً برای آنها امضا شده یا تأیید شده اند، می توانند پس از ارسال، با پیشروی هر نکته را اصلاح کنند. بنابراین، مهم است که سفارش هایی که به این روش انجام می شوند، یا از انواع سفارش های «محدود» با ناحیه ای استفاده کنند که تخصیص مناسب تمدید پرداخت را اعمال می کند، یا اینکه هر کالای پیشنهادی به طور کامل خرج شده باشد و هر کالای پرداختی به طور مناسب در هنگام ایجاد سفارش اعلام شود.
      • از آنجایی که سفارش هایی که تأیید شده اند (از طریق فراخوانی برای اعتبارسنجی) یا تا حدی تکمیل شده اند، از تأیید اعتبار امضا در انجام های بعدی صرف نظر می کنند، سفارش هایی که از EIP-1271 برای تأیید سفارش ها استفاده می کنند ممکن است در حالت ناسازگاری قرار بگیرند که در آن امضای اصلی دیگر معتبر نیست اماسفارش هنوز قابل انجام استدر این موارد، پیشنهاد دهنده باید صراحتاً سفارش مورد نظر را که قبلاً تأیید شده است لغو کند، اگر دیگر مایل به انجام سفارش نیست.
      • از آنجایی که سفارش های تکمیل شده با روش «تکمیل موجود» تنها در صورتی نادیده گرفته می شوند که آن سفارش ها لغو شده باشند، به طور کامل تکمیل شده باشند، یا غیرفعال باشند، ممکن است همچنان برای سفارش های غیرقابل اجرا تلاش شود (مثلاً شامل تأییدیه های لغو شده یا موجودی ناکافی است). این سناریو (و همچنین مشکلات مربوط به قالب بندی سفارش) منجر به شکست کامل دسته می شود. یکی از راه حل های این شرایط شکست، انجام بررسی های اضافی از یک منطقه اجرایی یا قرارداد بسته بندی هنگام ساخت فراخوان و فیلتر کردن دستورات بر اساس آن چک ها است.
      • از آنجایی که پارامترهای سفارش باید پس از لغو ارائه شوند، سفارش هایی که قرار بود خصوصی بمانند (مثلاً به صورت عمومی منتشر نشده اند) پس از لغو قابل مشاهده خواهند بود. در حالی که این سفارش ها بدون امضای متناظر قابل انجام نیستند، لغو سفارش های خصوصی بدون هدف پخش در حال حاضر به ارائه دهنده (یا منطقه، اگر نوع سفارش محدود است و منطقه از آن پشتیبانی می کند) نیاز دارد که شمارنده را افزایش دهد.
      • از آنجایی که ممکن است تلاش های انجام سفارش قبل از گنجاندن در یک بلوک عمومی شود، خطر این وجود دارد که آن سفارش ها در مرحله اول اجرا شوند. این خطر در مواردی که اقلام پیشنهادی حاوی مقادیر صعودی یا اقلام پرداختی دارای مقادیر نزولی هستند، بزرگ تر می شود، زیرا انگیزه ای برای انجام نشدن سفارش وجود دارد تا زمانی که انجام دهنده علاقه مند دیگری برای انجام سفارش مورد نظر تلاش کند. تلاش های اصلاحی شامل استفاده از یک ممپول خصوصی (مثلاً فلش ربات ها) و/یا سفارش های محدود شده است که در آن منطقه مربوطه یک طرح تعهد-افشایی را اجرا می کند.