EIP-8141: کیوں نیٹیو اکاؤنٹ ایبستراکشن ایتھریم کے ہیگوٹا اپگریڈ میں ایک ہیڈلائن فیچر نہیں ہے

لکھنے والہ: imToken

گزشتہ هفتے، ایتھریم کور ڈویلپرز میٹنگ میں EIP-8141 کو ہیگوٹا اپگریڈ میں شمولیت کے لیے باقاعدگی سے پیش کیا گیا، اور نتیجہ حیران کن تھا — وٹالک کے ذاتی سہارے والے اس پراپوزل کو ہیگوٹا کا "ہیڈ لائن فیچر" نہیں بلکہ "تفکر کے لیے مدنظر رکھا جا رہا ہے" (CFI) کا درجہ دیا گیا۔

اس ہفتے، گوگل کوانتم AI ٹیم نے ایک نئی وائٹ پیپر جاری کی جس میں کہا گیا کہ ان کے دیے گئے ہارڈویئر کے فرض کے تحت، ECDLP-256 کو توڑنے کے لیے درکار فزیکل کیوبٹس کا تخمینہ پہلے کے مقابلے میں 20 گنا کم ہو گیا ہے۔ یہ اس بات کا مطلب نہیں کہ کوانتم حملہ قریب ہے، لیکن یہ ہمیں واضح طور پر یاد دلاتا ہے کہ اگر اکاؤنٹ سسٹم مستقبل میں تصدیق منطق کو لچکدار طور پر تبدیل نہیں کر سکتا، تو آج بہت سے والٹ ایکسپیرینس کے بحثوں کا اختتام نہایت ممکنہ طور پر سیکورٹی مسائل میں ہو جائے گا۔

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

لیکن اب کے نقطہ نظر سے، EIP-8141 کے بارے میں بحث اور تفصیلی جائزہ لینے کی ضرورت لگاتار بڑھ رہی ہے۔

EIP-8141 کو ویتالیک بیوٹیرن اور تیمبیکو جیسے مرکزی کنٹریبیوٹرز نے آگے بڑھایا ہے، جس کا اصل نام فریم ٹرینزیکشنز ہے۔

اگر اسے ایک آسان الفاظ میں سمجھا جائے، تو اس کا مقصد صرف کسی ایک والٹ کی خصوصیت بڑھانا نہیں، بلکہ پروٹوکول کے لیول پر کسی بھی اکاؤنٹ کو ایک منفرد ECDSA سائنچر پاتھ سے آزاد کرنا ہے، تاکہ وہ زیادہ لچکدار تصدیق اور انجام کے منطق کو حاصل کر سکے۔

اس کا مطلب یہ بھی ہے کہ متعدد دستخط، گیس سپانسرشپ، کلید کا تبدیل کرنا، سوشل ریکوری، اور مستقبل میں کووانٹم مزاحمتی دستخط کے اقدامات تک، صرف والٹ کے باہر ایک اضافی صلاحیت نہیں رہیں گے، بلکہ ایتھریم اکاؤنٹ سسٹم کے "اصل ممبر" بننے کا موقع حاصل کر سکتے ہیں۔

اگر صرف سطحی طور پر دیکھا جائے تو، EIP-8141 میں بحث کی جانے والی چیزیں بہت مخصوص صلاحیتیں لگتی ہیں: اسٹیبل کرنسی کے ذریعے گیس ادا کرنا، متعدد مراحل کے عمل کو ایک ہی ٹرانزیکشن میں ملنا، زیادہ لچکدار دستخط کے طریقے کی حمایت، اور مستقبل کے کوئنٹم مزاحمتی دستخط کے لیے جگہ چھوڑنا۔ کہا جا سکتا ہے کہ ERC-4337 سے لے کر EIP-7702 تک، والٹ کے تجربے کے حوالے سے بہت سے بہتریاں، بنیادی طور پر اس بات کو یقینی بنانے کے لیے ہیں کہ اکاؤنٹ صرف ایک پرائیوٹ کلید نہ ہو بلکہ ایک کسٹمائز قواعد والا دروازہ بن جائے۔

مسئلہ یہ ہے کہ ان بہتریوں نے بالفعل کریپٹو والٹ کو اسٹارٹ اکاؤنٹس جیسا بنادیا ہے، لیکن ایتھریم کے سب سے بنیادی ڈیفالٹ اکاؤنٹ ماڈل تک کبھی حقیقی طور پر نہیں پہنچا۔

معلوم ہے کہ موجودہ نظام کے تحت، ایتھریم اکاؤنٹس عام طور پر دو قسموں میں تقسیم ہوتے ہیں۔ ایک باہری ملکیت اکاؤنٹ ہے، جسے ہم EOA کہتے ہیں، جو نجی کلید کے ذریعے کنٹرول ہوتا ہے اور ٹرانزیکشنز شروع کر سکتا ہے، لیکن اس میں پروگرامی قابلیت نہیں ہوتی؛ دوسرا کنٹریکٹ اکاؤنٹ ہے، جو خود سمارٹ کنٹریکٹ ہوتا ہے، جو پیچیدہ منطق کو انجام دے سکتا ہے، لیکن خود بخود ٹرانزیکشنز شروع نہیں کر سکتا۔

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

اگر آپ نے imToken یا کوئی دوسری ویب 3 والٹ استعمال کی ہے، تو آپ نے شاید ان مسائل کا تجربہ کیا ہوگا، جیسے والٹ میں کئی USDC ہیں لیکن ETH نہ ہونے کی وجہ سے ٹرانزیکشن نہیں بھیج سکتے (کیونکہ گیس صرف ETH سے ادا کیا جا سکتا ہے)؛ اگر آپ نے مینمونک فریز کھو دیا تو آپ کا پیسہ ہمیشہ کے لیے ضائع ہو جاتا ہے اور اسے واپس نہیں لایا جا سکتا؛ ایک "اختیار + تبادلہ" آپریشن کے لیے دو بار دستخط اور دو بار تصدیق کرنی پڑتی ہے وغیرہ۔

یہ مسائل، والٹ پروڈکٹ کے "کافی اچھے نہ ہونے" کی وجہ سے نہیں ہیں، بلکہ ایتھریم اکاؤنٹ ماڈل کے اپنے ڈیزائن کا نتیجہ ہیں۔

اس منظر سے، پچھلے دو سالوں کی ترقی بہت واضح ہو چکی ہے، ERC-4337 نے پروٹوکول میں تبدیلی کیے بغیر اکاؤنٹ ایبسٹرکشن کو ایپلیکیشن لیول پر شروع کر دیا؛ EIP-7702 نے مزید ثابت کیا کہ EOA بالکل بھی وسعت نہیں دی جا سکتی، کم از کم وہ عارضی طور پر اسمارٹ اکاؤنٹ کے قریب کچھ صلاحیتیں حاصل کر سکتی ہے۔

یعنی ایتھریم صرف اکاؤنٹ ایبسٹرکشن نہیں کرنا چاہتا، بلکہ یہ لگاتار زیادہ معتدل اور محتاط انداز میں اس کی طرف قدم بڑھا رہا ہے۔ EIP-8141 کے ظہور سے یہ راستہ ایک نئے نقطے تک پہنچ گیا ہے۔ یہ صرف موجودہ نظام کے باہر ایک اضافی اسمارٹ اکاؤنٹ کی صلاحیت نہیں جوڑنا چاhta، بلکہ یہ اکاؤنٹ ایبسٹرکشن کو براہ راست ٹرانزیکشن ماڈل میں ڈالنے کی کوشش کر رہا ہے، تاکہ اکاؤنٹ پروٹوکول لیول سے ہی قابل پروگرام ویریفیکیشن اور ایکزیکشن منطق رکھے۔

یہی وجہ ہے کہ EIP-8141 آج دوبارہ زندہ ہو گیا۔ ایک طرف، اوپری والٹ تجربہ اب نیٹو اکاؤنٹ ایبسٹرکشن کے قریب تر ہوتا جا رہا ہے، اور پروٹوکول لیول کو جلد ہی اس کے ساتھ مطابقت رکھنی ہوگی؛ دوسری طرف، کوانٹم کمپیوٹنگ کے طویل مدتی دباؤ کی وجہ سے، "کیا اکاؤنٹ کے سائنچر طریقے کو لچکدار طور پر تبدیل کیا جا سکتا ہے" ایک دور کا ٹیکنیکل سوال نہیں رہا، بلکہ اب اسے ایک فوری اور جدید مسئلہ کے طور پر سنجیدگی سے سوچنا ضروری ہو گیا ہے۔

بالآخر، EIP-8141 نے ایک نئے قسم کا ٹرانزیکشن — فریم ٹرانزیکشن — متعارف کرایا ہے، جس کا ٹرانزیکشن قسم نمبر 0x06 ہے۔

اگر روایتی ایتھریم ٹرانزیکشن کی بنیادی منطق یہ ہے کہ ایک ٹرانزیکشن ایک کال کے مطابق ہوتی ہے، تو EIP-8141 کا مقصد ایک ٹرانزیکشن کو ایک سیٹ میں تقسیم کرنا ہے جس میں قواعد کے مطابق ترتیب سے نفاذ کیے جانے والے "فریمز" ہوتے ہیں، جس سے اصل میں جڑے ہوئے تصدیق، ادائیگی اور نفاذ کے تین کاموں کو الگ الگ سنبھالا جا سکے۔

ہر «فریم» کے تین اجراء ماڈل ہیں:

• VERIFY (تصدیق فریم): یہ ٹریکشن کی قانونیت کی تصدیق کرتا ہے، یہ اکاؤنٹ کے مخصوص تصدیق منطق کو چلاتا ہے، اگر کامیاب ہو جائے تو اسے نئے متعارف کرائے گئے APPROVE آپریکوڈ کو بلایا جاتا ہے تاکہ اجراء کی اجازت دی جائے اور گیس لِمٹ مقرر کیا جائے۔
• ارسال کنندہ (فریم بھیجنا): انتقال، معاہدہ کال وغیرہ جیسے عمل کو انجام دیتا ہے۔ کال کرنے والے کا پتہ وہی ہوتا ہے جو ٹرانزیکشن بھیج رہا ہے۔
• ڈیفالٹ (اینٹری فریم): ڈیپلویمنٹ کنٹریکٹ، پے ماسٹر کی تصدیق وغیرہ کے لیے سسٹم اینٹری ایڈریس کو کالر کے طور پر استعمال کریں؛

اس مکینزم کا مقصد یہ نہیں کہ ٹریڈنگ کو زیادہ پیچیدہ بنایا جائے، بلکہ یہ پہلی بار ہے کہ "تصدیق، ادائیگی، اور انجام دہی" کو اکاؤنٹ ایکشن سے الگ کر دیا گیا ہے اور اسے پروٹوکول کے اصلی شیڈولر کے ذریعے منتقل کر دیا گیا ہے۔

کیونکہ گزشتہ زمانے میں، ٹرانزیکشن کی تصدیق کون کرے گا، گیس کی ادائیگی کون کرے گا، اور حقیقی عمل کون انجام دے گا، یہ سب بنیادی طور پر ایک ہی اکاؤنٹ کے ایکٹشن سے منسلک تھا، لیکن EIP-8141 کے ڈیزائن کے تحت، یہ تینوں چیزیں الگ الگ فریمز میں تقسیم کی جا سکتی ہیں، جنہیں پروٹوکول واضح ترتیب سے ترتیب سے انجام دے گا، اور اسی وجہ سے، اکاؤنٹ صرف ایک منفرد نجی کلید کے ذریعے "مکمل دستخط" کرنے پر مзал نہیں رہا، بلکہ اب یہ زیادہ قابل پروگرام کردہ اجراء کے کردار کے قریب ہو گئے ہیں۔

ایک مخصوص مثال کے طور پر، فرض کریں کہ آپ ایک سوپ کو مکمل کرنے کے لیے گیس کی ادائیگی کے لیے USDC استعمال کرنا چاہتے ہیں، EIP-8141 کے فریم ورک کے تحت، یہ عمل نظریہ طور پر ایک مکمل فریم پروسیجر کے طور پر منظم کیا جا سکتا ہے: پہلے اکاؤنٹ کی سائنیچر اور ایکسیکیشن اجازت کی تصدیق کی جائے، پھر ادائیگی کرنے والے یا پے ماسٹر کی تصدیق کی جائے کہ وہ خود ادائیگی کے شرائط قبول کرتے ہیں، اس کے بعد متعلقہ اثاثوں کی ادائیگی مکمل ہو جائے، اور آخر میں اصل سوپ آپریشن انجام دیا جائے۔

اس طرح، گیس ادائیگی اور بنیادی ٹریڈ ایک ہی اٹومک پروسیس میں شامل ہو جاتے ہیں، جو یا تو پورا کامیاب ہوتا ہے یا پورا منسوخ ہو جاتا ہے۔

صارف کے لیے سب سے زیادہ واضح تبدیلی یہ ہے کہ جو کام پہلے دو یا تین اسٹیپس میں تقسیم کیے جاتے تھے اور ان کے درمیان ناکامی کا خطرہ تھا، وہ مستقبل میں ایک مکمل ایکشن کی طرح ہو جائیں گے، اس لیے یہ ایٹومکٹی EIP-8141 کا ایک اہم پہلو ہے جو صارف کے تجربے کو ٹکڑوں میں تقسیم ہونے کے مسئلے کو حل کرنا چاہتا ہے۔

یہ ویلٹ صارفین کے لیے کیا سمجھنا چاہیے؟ نتائج کے مطابق، سب سے واضح تبدیلیاں کم از کم چار سطحوں پر ہیں:

• گیس ادائیگی کو تجرد کر دیا گیا ہے: اگر آپ کے والٹ میں اسٹیبل کرنسی ہے، تو اس کا مطلب یہ نہیں کہ آپ کو گیس کے لیے مزید ETH کی ضرورت ہوگی؛ مستقبل میں DApp، Paymaster یا دوسرے سپانسرز کی طرف سے گیس کی ادائیگی زیادہ قدرتی طریقے سے ہوگی؛
• کئی مرحلہ کارروائیاں کو ایک ساتھ ملا دیا گیا ہے: جیسے "اطلاع دینا + سوپ" یا "اطلاع دینا + زمانت" جیسے عمل جو اب عام طور پر کئی بار دستخط کی ضرورت رکھتے ہیں، انہیں ایک مکمل تر کارروائی کے طور پر پیک کیا جا سکتا ہے؛
• اکاؤنٹ سیکیورٹی قواعد فعال ہو گئے ہیں: ملٹی سگنیچر، سوشل ریکوری، روزانہ کی حد، ٹائم لॉک، اور کلید کا تبدیل کرنا، اب صرف کسی واٹلیٹ پروڈکٹ کی اضافی اعلیٰ خصوصیات نہیں رہ گئے، بلکہ اب یہ زیادہ بنیادی اکاؤنٹ منطق پر بننے کا موقع پیدا ہو رہا ہے؛
• دستخط کے منصوبے اب ECDSA کے صرف ایک راستے پر مجبور نہیں ہیں: اس سے اکاؤنٹس کے مستقبل میں مختلف کرپٹوگرافک سسٹمز، جن میں پوسٹ-کوانتم دستخط کے منصوبے بھی شامل ہیں، پر منتقل ہونے کا پروٹوکول لیول پر پہلی بار ممکن ہو جاتا ہے؛

ایک بہت آسانی سے نظرانداز کیا جانے والا لیکن والٹ صارفین کے لیے بہت اہم نقطہ یہ ہے کہ اگرچہ EIP-8141 آخرکار لاگو ہو جائے، تو موجودہ اکاؤنٹ سسٹم اس کی وجہ سے مکمل طور پر ختم نہیں ہو جائے گا۔

اگرچہ آپ اب imToken جیسے موجودہ ویب3 والٹ کا استعمال کر رہے ہیں، تو آپ کو منتقلی کی ضرورت نہیں ہے، کیونکہ یہ پیچھے کی طرف مطابقت رکھتا ہے، اور موجودہ EOA پتے جاری رہیں گے، صرف مناسب وقت پر اپنے اکاؤنٹ کی تصدیق منطق کو "اپ گریڈ" کرنے کا انتخاب کریں۔

لیکن اس کے برعکس، اس کی گہرائی کی وجہ سے ہی اسے نئی ترین بحث میں ہیگوٹا کا سب سے اہم فیچر نہیں بنایا گیا۔ تاہم، 2026 کے EIP چیمپئن پروسیجر کے مطابق، CFI (Considered for Inclusion) کا مطلب یہ نہیں کہ اسے مسترد کر دیا گیا ہے، بلکہ اس کا مطلب ہے کہ اسے جدید طور پر غور کیا جا رہا ہے، لیکن ابھی اسے بالآخر منظور کر کے لائو کرنے کا مرحلہ نہیں آیا ہے۔

دوسرے الفاظ میں، کور ڈویلپرز EIP-8141 کی سمت کو نہیں مسترد کر رہے، بلکہ اس کی قدر کو تسلیم کرتے ہوئے، اسے اب بھی بہت "بھاری" سمجھ رہے ہیں۔

کیونکہ نیٹو اکاؤنٹ ایبسٹرکشن ERC-4337 کی طرح کچھ والٹس، بنیادی ڈھانچے اور ایپلیکیشنز کے ذریعے تدریجی طور پر آگے بڑھانے کے قابل نہیں ہے؛ اس کا مطلب ہے کہ جب یہ پروٹوکول لیول پر داخل ہوتا ہے، تو تمام ایکزیکوشن لیول کلائنٹس کو اسے حقیقی طور پر لاگو، ٹیسٹ اور کوآرڈینیٹ کرنا ہوگا، جس سے آگے بڑھنے کی رکاوٹ خود بخود بڑھ جاتی ہے اور مرکزی ڈویلپرز کو فورک منصوبہ بندی میں زیادہ محتاط رہنے کی ترغیب دی جاتی ہے۔

اس کے بعد کیا ہوگا؟ اسے دو لائنوں میں تقسیم کیا جا سکتا ہے:

• چونکہ EIP-8141 CFI حیثیت میں ہے، اس لیے اس کا جائزہ لیا جارہا ہے اور پیشکش کنندہان تجارتی پول کی سلامتی، تصدیق کے قواعد اور کلائنٹ ایمپلیمینٹیشن کے اہم پہلوؤں کو مزید تفصیل سے مکمل کرتے رہیں گے، اور بعد میں ACD میٹنگ بھی دوبارہ جانچے گی کہ کیا اسے آگے بڑھانے کے لیے مناسب شرائط موجود ہیں؛
• اگر ان عدم یقینیتوں کو مستقل طور پر کم کیا جا سکے، تو اس کے بعد کے اپ گریڈ میں زیادہ عملی شمولیت کا موقع ہو سکتا ہے؛ اگر نہیں، تو اسے مزید دیر تک ملتوی بھی کر دیا جا سکتا ہے؛

سچائی کے ساتھ کہنا تو یہ ہے کہ EIP-8141 صرف ایک منفرد اصل اکاؤنٹ ایبسترکشن پیشکش نہیں ہے، اور نہ ہی یہ کوئی تیار بعد-کوانٹم دستخط اسکیم ہے جو کوانٹم کمپوٹنگ کے مسئلے کو براہ راست حل کر سکے، لیکن اس کا اہمیت یہ ہے کہ یہ پہلی بار اکاؤنٹس کو ECDSA کے واحد راستے سے نکالنے کے لیے پروٹوکول لیول پر ایک راستہ فراہم کرتا ہے۔

اس منظر سے، EIP-8141 کی حقیقی قیمت اس بات میں نہیں ہے کہ یہ واحد صحیح جواب ہے، بلکہ اس بات میں ہے کہ اس نے پہلی بار "اصلی اکاؤنٹ ایبسٹرکشن کا آخری شکل کیا ہونا چاہئے" کا سوال، ایتھریم پروٹوکول کی بحث کے میز پر بہت مکمل طور پر رکھ دیا۔

یہ واحد حل نہیں ہے، لیکن یہ اب تک کا سب سے زیادہ خواہش مند اور "مکمل نیٹو AA" کی تصوراتی حد تک سب سے قریب کا حل ہے۔

چاہے EIP-8141 حتمی طور پر Hegotá کے ساتھ کبھی پہنچ پائے یا نہ پائے، یہ بحث کم از کم ایک بات کو واضح کر چکی ہے:

ایتھریم مسائل کے بڑھنے کا انتظار نہیں کر رہا، بلکہ اگلی نسل کے اکاؤنٹ سسٹم کے لیے روزانہ چھوٹی چھوٹی ترقیات کے ذریعے پیش پیش ہو رہا ہے۔