ایرک ژانگ نے NEP-33 کے ساتھ نو تصدیقی تینوں کو مکمل کیا۔

Neo کے شریک بانی ایرک ژانگ نے NEP-33 شائع کیا ہے، یہ تیسرا Neo Enhancement تجویز جو انہوں نے دو ہفتوں میں پیش کیا ہے۔ معیار URI پر مبنی ٹرانسپورٹ میکانزم کی وضاحت کرتا ہے جو مقامی ایپلی کیشنز کو تصدیق کے لیے والیٹ ایپلی کیشنز کو طلب کرنے کی اجازت دیتا ہے، تین پرتوں کے اسٹیک کو مکمل کرتا ہے جو اس بات کو معیاری بناتا ہے کہ صارفین اپنے Neo والیٹ کے ساتھ کیسے سائن ان کرتے ہیں۔

NEP-33 NEP-20 کی پیروی کرتا ہے، جس نے کرپٹوگرافک توثیق کے اصول قائم کیے، اور NEP-21، جس نے والٹ فراہم کرنے والوں کے ساتھ بات چیت کرنے کے لیے dApps کے لیے ایک متحد انٹرفیس کی وضاحت کی۔ جہاں وہ دو معیار تصدیقی منطق اور بٹوے کی صلاحیتوں کو سنبھالتے ہیں، NEP-33 انٹری پوائنٹ کو ایڈریس کرتا ہے: کس طرح ایک ایپلیکیشن پرس کو تصدیق کی درخواست دے کر نتیجہ وصول کرتی ہے۔

یہ کیا قابل بناتا ہے۔

NEP-33 سے پہلے، موبائل یا ڈیسک ٹاپ ایپلیکیشن کے لیے تصدیق کے لیے Neo والیٹ کو طلب کرنے کا کوئی معیاری طریقہ نہیں تھا۔

ہر بٹوے اور ایپلیکیشن نے اپنی درخواست اور کال بیک فارمیٹ کو نافذ کیا، جس سے ٹکڑے ٹکڑے ہو گئے۔ NEP-33 متعارف کراتا ہے neoauth://، ایک حسب ضرورت URI اسکیم جو مقامی ایپلیکیشنز کو ایک عالمگیر "Sign in with Neo" انٹری پوائنٹ فراہم کرتی ہے۔ آپریٹنگ سسٹم درخواست کو ایک مطابقت پذیر والیٹ تک پہنچاتا ہے، جو کال بیک URI کے ذریعے نتیجہ واپس کرتا ہے۔

Neo پر تعمیر کرنے والے ڈویلپرز اب ہر فراہم کنندہ کے لیے والیٹ کے لیے مخصوص کوڈ لکھے بغیر والیٹ کی تصدیق کو ضم کر سکتے ہیں۔

مزید برآں، NEP-33 کو آگے کی مطابقت کو ذہن میں رکھتے ہوئے ڈیزائن کیا گیا ہے۔ تجویز کی گٹ ہب پل کی درخواست پر ایک تبصرے میں، ژانگ نے اس بارے میں ایک سوال کا جواب دیا کہ آیا مختلف نیو نیٹ ورک ورژنز کے لیے علیحدہ URI اسکیمیں موجود ہونی چاہئیں:

چونکہ N3 اور N4 کے ایڈریس فارمیٹس ایک جیسے ہیں، ان میں فرق کرنے کی ضرورت نہیں ہے۔ اور یہ صرف ایک ٹرانسپورٹ لیئر پروٹوکول ہے۔ NEP-20 میں نیٹ ورک گفت و شنید کا عمل ہے۔

ڈیزائن neoauth:// اسکیم نیٹ ورک-اگنوسٹک کو رکھتا ہے، نیٹ ورک کے انتخاب کو NEP-20 پرت پر سنبھالا جاتا ہے۔

NEP-33 کیسے کام کرتا ہے۔

ایک ایپلیکیشن neoauth:// اسکیم کا استعمال کرتے ہوئے ایک درخواست URI بناتی ہے، جس میں URL انکوڈ شدہ NEP-20 چیلنج پے لوڈ اور ایک dApp شناخت کنندہ شامل ہوتا ہے۔ آپریٹنگ سسٹم اسے ایک رجسٹرڈ والیٹ ایپلیکیشن کی طرف لے جاتا ہے، جو ایک عام ہدف (OS یا صارف کو والیٹ کا انتخاب سونپنا) یا ایک مخصوص والیٹ کا نفاذ ہو سکتا ہے۔

پرس پے لوڈ کو ڈی کوڈ اور توثیق کرتا ہے، صارف کو توثیق کی تفصیلات (درخواست کرنے والے ڈومین سمیت) دکھاتا ہے، اور اس کے لیے واضح منظوری درکار ہوتی ہے۔ اگر صارف منظور کرتا ہے، تو والیٹ NEP-20 رسپانس پے لوڈ تیار کرتا ہے اور اسے dapp:// اسکیم کا استعمال کرتے ہوئے کال بیک URI کے ذریعے واپس کرتا ہے۔ اگر صارف درخواست کو مسترد کرتا ہے یا کوئی غلطی پیش آتی ہے، تو والیٹ اسی کال بیک میکانزم کے ذریعے ایک ساختی غلطی کا جواب دیتا ہے۔

تمام تصدیقی توثیق NEP-20 کے کرپٹوگرافک قواعد کی پیروی کرتی ہے، یعنی درخواست کرنے والی درخواست کو تصدیق کے ثبوت کے طور پر کال بیک URI پر اعتماد کرنے کے بجائے واپس کیے گئے دستخط کی تصدیق کرنی چاہیے۔

NEP-33 اس بات کی دوبارہ وضاحت نہیں کر رہا ہے کہ تصدیق کیا ہے یا یہ کیسے کام کرتی ہے، بلکہ یہ اس صلاحیت کو dApps اور بٹوے کے درمیان تعامل کے بہاؤ میں لاتا ہے۔

سیکیورٹی ماڈل

چونکہ حسب ضرورت URI اسکیمیں رازداری یا درخواست کی شناخت کی ضمانت نہیں دیتی ہیں، اس لیے NEP-33 کی سیکیورٹی مکمل طور پر NEP-20 دستخطی تصدیق پر منحصر ہے۔

معیاری فریب کاری سے بچانے کے لیے درخواست کرنے والے ڈومین کو واضح طور پر ظاہر کرنے کے لیے والٹس کا تقاضہ کرتا ہے، ری پلے حملوں کو روکنے کے لیے تجویز کردہ پانچ منٹ کی میعاد کے ساتھ منفرد سنگل یوز نونسز کو نافذ کرتا ہے، اور کسی بھی دستخط کی تیاری سے پہلے صارف کی واضح منظوری کو لازمی قرار دیتا ہے۔

NEP-33 کو خصوصی طور پر ایک بار کی تصدیق کے بہاؤ کے لیے ڈیزائن کیا گیا ہے۔ اسے لین دین پر دستخط کرنے، اثاثوں کی منتقلی، سمارٹ کنٹریکٹ کی درخواست، یا سیشن پر مبنی اجازت کے لیے استعمال نہیں کیا جانا چاہیے۔

مکمل اعلان نیچے دیے گئے لنک پر پایا جا سکتا ہے: https://x.com/erikzhang/status/2042931327943741471