يكمل Erik Zhang ثلاثية مصادقة Neo باستخدام NEP-33

قام إريك تشانغ، المؤسس المشارك لـ Neo، بنشر NEP-33، وهو الاقتراح الثالث لتعزيز Neo الذي طرحه خلال أسبوعين. يحدد المعيار آلية النقل المستندة إلى URI والتي تسمح للتطبيقات المحلية باستدعاء تطبيقات المحفظة للمصادقة، واستكمال حزمة ثلاثية الطبقات تعمل على توحيد كيفية تسجيل المستخدمين للدخول باستخدام محفظة Neo الخاصة بهم.

يتبع NEP-33 NEP-20، الذي أنشأ قواعد مصادقة التشفير، وNEP-21، الذي حدد واجهة موحدة للتطبيقات اللامركزية للتواصل مع موفري المحفظة. حيث يتعامل هذان المعياران مع منطق المصادقة وإمكانيات المحفظة، يعالج NEP-33 نقطة الدخول: كيف يقوم أحد التطبيقات بتسليم طلب المصادقة إلى المحفظة وتلقي النتيجة.

ما يتيحه هذا

قبل NEP-33، لم تكن هناك طريقة موحدة لتطبيق الهاتف المحمول أو سطح المكتب لاستدعاء محفظة Neo للمصادقة.

نفذت كل محفظة وتطبيق تنسيق الاستدعاء ورد الاتصال الخاص بها، مما أدى إلى حدوث تجزئة. يقدم NEP-33 neoauth://، وهو نظام URI مخصص يمنح التطبيقات الأصلية نقطة دخول عالمية "تسجيل الدخول باستخدام Neo". يقوم نظام التشغيل بتوجيه الطلب إلى محفظة متوافقة، والتي تقوم بإرجاع النتيجة عبر عنوان URI لرد الاتصال.

يمكن الآن للمطورين الذين يعتمدون على Neo دمج مصادقة المحفظة دون كتابة كود خاص بالمحفظة لكل مزود.

بالإضافة إلى ذلك، تم تصميم NEP-33 مع وضع التوافق الأمامي في الاعتبار. في تعليق على طلب سحب GitHub الخاص بالاقتراح، تناول Zhang سؤالًا حول ما إذا كان يجب وجود مخططات URI منفصلة لإصدارات شبكة Neo المختلفة:

نظرًا لأن تنسيقات العناوين N3 وN4 متماثلة، فليست هناك حاجة للتمييز بينهما. وهذا مجرد بروتوكول طبقة النقل. توجد عملية تفاوض على الشبكة في NEP-20.

يحافظ التصميم على المصادقة الجديدة: // مخطط الشبكة، مع التعامل مع اختيار الشبكة في طبقة NEP-20.

كيف يعمل NEP-33

يقوم التطبيق بإنشاء عنوان URI للطلب باستخدام مخطط neoauth://، مع تضمين حمولة تحدي NEP-20 المشفرة بعنوان URL ومعرف dApp. يقوم نظام التشغيل بتوجيه ذلك إلى تطبيق محفظة مسجل، والذي يمكن أن يكون هدفًا عامًا (تفويض اختيار المحفظة لنظام التشغيل أو المستخدم) أو تطبيق محفظة محدد.

تقوم المحفظة بفك تشفير الحمولة والتحقق من صحتها، وتعرض تفاصيل المصادقة (بما في ذلك المجال المطلوب) للمستخدم، وتتطلب موافقة صريحة. إذا وافق المستخدم، تقوم المحفظة بإنشاء حمولة استجابة NEP-20 وإعادتها عبر عنوان URI لرد الاتصال باستخدام مخطط dapp://. إذا رفض المستخدم الطلب أو حدث خطأ، تقوم المحفظة بإرجاع استجابة خطأ منظم من خلال نفس آلية رد الاتصال.

تتبع جميع عمليات التحقق من المصادقة قواعد التشفير الخاصة بـ NEP-20، مما يعني أن التطبيق الطالب يجب أن يتحقق من التوقيع الذي تم إرجاعه بدلاً من الوثوق بمعرف URI الخاص برد الاتصال نفسه كدليل على المصادقة.

لا يعيد NEP-33 تعريف ماهية المصادقة أو كيفية عملها، بل إنه يجلب هذه الإمكانية إلى تدفق التفاعل بين التطبيقات اللامركزية والمحافظ.

نموذج الأمن

نظرًا لأن أنظمة URI المخصصة لا تضمن السرية أو هوية التطبيق، فإن أمان NEP-33 يعتمد بالكامل على التحقق من توقيع NEP-20.

يتطلب المعيار من المحافظ عرض النطاق المطلوب بوضوح للحماية من التصيد الاحتيالي، ويفرض أرقامًا فريدة للاستخدام مرة واحدة مع انتهاء صلاحية موصى بها مدتها خمس دقائق لمنع هجمات إعادة التشغيل، ويفرض موافقة صريحة من المستخدم قبل إنتاج أي توقيع.

تم تصميم NEP-33 حصريًا لتدفقات المصادقة لمرة واحدة. ولا ينبغي استخدامه لتوقيع المعاملات، أو نقل الأصول، أو استدعاء العقد الذكي، أو التفويض المستند إلى الجلسة.

يمكن العثور على الإعلان الكامل على الرابط أدناه: https://x.com/erikzhang/status/2042931327943741471