يتم تغيير ERC-7683، ولا تزال العديد من التفسيرات تصف إصدارًا أقدم من المعيار. النسخة الحالية من مسودة ERC-7683 أكثر تركيزًا على الحلول (resolvers). بدلًا من إجبار كل بروتوكول نية عبر السلاسل على استخدام عقد احتفاظ مشترك واحد، ونظام مزاد واحد، وآلية تسويات واحدة، ونموذج تفويض واحد، أو وظيفة تعبئة وجهة واحدة، يمكن للبروتوكولات الحفاظ على بنية تنفيذها الخاصة مع تعريض الطلبات للحلول عبر طبقة حل مشتركة. هذا التمييز مهم. طلب ERC-7683 هو في جوهره عرض دفع مقابل تحقيق مجموعة محددة من المتطلبات. تقوم الحلول (وتُسمى أيضًا مُكمّلي الطلبات) بتقييم هذه المتطلبات، وتحديد ما هي خطوات التنفيذ الضرورية، وتُلزم رأس المال أو الغاز، وتتوقع الدفع إذا أكملت الطلب بشكل صحيح. يسمح التصميم الحالي للبروتوكول بعرض حمولة خاصة بالبروتوكول غير شفافة إلى جانب عقد حل. يقوم هذا العقد بترجمة الحمولة إلى تمثيل مشترك يحتوي على: • خطوات التنفيذ • المتغيرات • المدفوعات • الافتراضات الصريحة هذا يمنح الحلول القابلة للبرمجة طريقة موحدة لفهم ما يتطلبه الطلب فعليًا، دون الحاجة إلى أن يُنفذ كل حل منطقًا مخصصًا تمامًا لكل بروتوكول نية. يمكن لنموذج التنفيذ المُحلَّل أن يُظهر متطلبات إنفاق الرموز، ومتطلبات الغاز، والقيود الزمنية، والاعتمادات، وسلوك التراجع. يمكن أن تمثل المتغيرات عناوين دفع الحلول، والسلاسل الدافعة، ومخرجات التنفيذ، والجهات التي تستدعي الخطوات، والشهود خارج السلسلة، واستعلامات العقود، واستعلامات الأحداث. كما يدمج ERC-7683 تمثيلات عناوين متوافقة عبر ERC-7930، مما يربط سياق السلسلة بالعنوان بدلاً من الاعتماد فقط على عنوان EVM قياسي بطول 20 بايت. لكن هناك حدود أمنية مهمة. لا يؤدي توحيد ERC-7683 تلقائيًا إلى جعل بروتوكول النية الأساسي آمنًا. تظل عقود التسويات، والجسور، وأنظمة تبادل الرسائل، والرموز، وآليات المزادات، والخدمات خارج السلسلة، والبوابات، وأقفال الموارد، وحماية إعادة التشغيل، ومنطق الإلغاء، وسلوك الاسترداد، والتعبئة الجزئية مخاطر خاصة بالبروتوكول ما لم يتم تمثيلها صراحةً من خلال المتطلبات أو الافتراضات المُحلَّلة. لذلك فإن أمان الحلول أمر بالغ الأهمية. يجب على الحل أن يتحقق بشكل صحيح من حمولته الخاصة بالبروتوكول ويُظهر تمثيلًا يسمح للحل الذي يتصرف بشكل صحيح بفهم ما يجب حدوثه وأي الافتراضات التي سيصبح معها الدفع متاحًا. لا يمكن لحل صحيح أن يجعل نظام تسويات غير آمن آمنًا. ولا يزيل تنسيق الطلب المتوافق مخاطر الحل. يصبح المُكمل عرضةً اقتصاديًا من اللحظة التي يُقرّر فيها التفويضات أو الغاز أو رأس المال أو المعاملات حتى يصبح الدفع المتوقع نهائيًا وقابلًا للإنفاق. بالنسبة للمستخدمين، تظل نقاط التحقق الأساسية عملية: • سلسلة الأصل • الأصل المدخل • سلسلة الوجهة • المستلم • المخرج المتوقع • الموعد النهائي • نطاق التفويض • المعاملة أو البيانات المُوقَّعة المُصنَّفة يتناسب ERC-7683 أيضًا بشكل طبيعي داخل أنظمة النية الأوسع مثل إطار Open Intents Framework، لكنهما ليسا قابلين للتبادل. ERC-7683 هو في المقام الأول طبقة توحيد لحل الطلبات الموجهة للحلول. OIF هو إطار بنية تحتية أوسع يغطي أصل النية، والحل، والتنفيذ، والتسويات، والتجميع، والمكونات ذات الصلة. يُفصّل بحثنا الأخير في TokenToolHub التصميم الحالي لـ ERC-7683، وكيف يختلف عن المسودات السابقة، ودورة حياة الطلب، والحلول، وأمان الحلول، وخطوات التنفيذ، والمدفوعات، والافتراضات، والعناوين المتوافقة، والمخاطر المتعلقة بالحلول التي تظل خارج المعيار نفسه. التحليل الكامل: https://t.co/VK5Yb4wvJ3