پیکٹرا 7702

خلاصہ

EIP 7702 ایک EOA میں کوڈ شامل کرنے کے طریقہ کار کی وضاحت کرتا ہے۔ یہ تجویز EOAs، جو کہ روایتی ایتھیریم اکاؤنٹس ہیں، کو قلیل مدتی فعالیت میں بہتری حاصل کرنے کی اجازت دیتی ہے، جس سے ایپلی کیشنز کی افادیت بڑھ جاتی ہے۔ یہ ایک نئی ٹرانزیکشن قسم: 4 کا استعمال کرتے ہوئے پہلے سے تعینات کردہ کوڈ کی طرف ایک پوائنٹر سیٹ کر کے کیا جاتا ہے۔

یہ نئی ٹرانزیکشن قسم ایک اجازت نامے کی فہرست (authorization list) متعارف کراتی ہے۔ فہرست میں ہر اجازت نامے کا ٹوپل (tuple) اس طرح بیان کیا گیا ہے

[ chain_id, address, nonce, y_parity, r, s ]

address تفویض ہے (پہلے سے تعینات کردہ بائٹ کوڈ جو EOA کے ذریعے استعمال کیا جائے گا) chain_id اجازت نامے کو ایک مخصوص چین تک محدود کرتا ہے (یا تمام چینز کے لیے 0) nonce اجازت نامے کو ایک مخصوص اکاؤنٹ نانس تک محدود کرتا ہے (y_parity, r, s) اجازت نامے کے ٹوپل کے دستخط ہیں، جسے EOA کی نجی کلید کے ذریعے keccak(0x05 || rlp ([chain_id ,address, nonce])) کے طور پر بیان کیا گیا ہے جس پر اجازت نامہ لاگو ہوتا ہے (جسے اتھارٹی بھی کہا جاتا ہے)

کسی تفویض کو null پتہ پر تفویض کر کے ری سیٹ کیا جا سکتا ہے۔

تفویض کے بعد EOA کی نجی کلید کا اکاؤنٹ پر مکمل کنٹرول برقرار رہتا ہے۔ مثال کے طور پر کسی Safe کو تفویض کرنے سے اکاؤنٹ ملٹی سگ نہیں بن جاتا کیونکہ اب بھی ایک ہی کلید موجود ہوتی ہے جو کسی بھی دستخط کرنے کی پالیسی کو نظر انداز کر سکتی ہے۔ مستقبل میں، ڈیولپرز کو اس مفروضے کے ساتھ ڈیزائن کرنا چاہیے کہ سسٹم میں کوئی بھی شریک سمارٹ کنٹریکٹ ہو سکتا ہے۔ سمارٹ کنٹریکٹ ڈیولپرز کے لیے، اب یہ فرض کرنا محفوظ نہیں ہے کہ tx.origin کسی EOA کی طرف اشارہ کرتا ہے۔

بہترین طرز عمل

اکاؤنٹ کی تجرید: مطابقت کو زیادہ سے زیادہ کرنے کے لیے ایک تفویض کنٹریکٹ کو ایتھیریم کے وسیع تر اکاؤنٹ کی تجرید (AA) کے معیارات کے ساتھ ہم آہنگ ہونا چاہیے۔ خاص طور پر، اسے مثالی طور پر ERC-4337 کے مطابق یا ہم آہنگ ہونا چاہیے۔

بلا اجازت اور سنسرشپ کے خلاف مزاحم ڈیزائن: ایتھیریم بلا اجازت شرکت کی قدر کرتا ہے۔ ایک تفویض کنٹریکٹ کو کسی ایک "قابل اعتماد" ریلے (relayer) یا سروس کو ہارڈ کوڈ یا اس پر انحصار نہیں کرنا چاہیے۔ اگر ریلے آف لائن ہو جاتا ہے تو یہ اکاؤنٹ کو ناکارہ بنا دے گا۔ بیچنگ جیسی خصوصیات (جیسے، approve+transferFrom) کو EOA خود کسی ریلے کے بغیر استعمال کر سکتا ہے۔ ایپلی کیشن ڈیولپرز کے لیے جو 7702 کے ذریعے فعال کردہ جدید خصوصیات (گیس کی تجرید، رازداری کو برقرار رکھنے والی رقوم کی واپسی) استعمال کرنا چاہتے ہیں، آپ کو ایک ریلے کی ضرورت ہوگی۔ اگرچہ مختلف ریلے آرکیٹیکچرز موجود ہیں، ہماری سفارش ہے کہ 4337 بنڈلرز (opens in a new tab) کا استعمال کریں جو کم از کم انٹری پوائنٹ 0.8 (opens in a new tab) کی طرف اشارہ کرتے ہوں کیونکہ:

• وہ ریلے کرنے کے لیے معیاری انٹرفیس فراہم کرتے ہیں
• ان میں بلٹ ان پے ماسٹر سسٹمز شامل ہیں
• مستقبل کی مطابقت کو یقینی بناتے ہیں
• ایک عوامی میم پول (opens in a new tab) کے ذریعے سنسرشپ کے خلاف مزاحمت کی حمایت کر سکتے ہیں
• یہ تقاضا کر سکتے ہیں کہ init فنکشن کو صرف EntryPoint (opens in a new tab) سے کال کیا جائے

دوسرے الفاظ میں، کوئی بھی شخص ٹرانزیکشن اسپانسر/ریلے کے طور پر کام کرنے کے قابل ہونا چاہیے جب تک کہ وہ اکاؤنٹ سے مطلوبہ درست دستخط یا صارف کا عمل (UserOperation) فراہم کرے۔ یہ سنسرشپ کے خلاف مزاحمت کو یقینی بناتا ہے: اگر کسی کسٹم انفراسٹرکچر کی ضرورت نہیں ہے، تو صارف کی ٹرانزیکشنز کو کسی گیٹ کیپنگ ریلے کے ذریعے من مانی طور پر بلاک نہیں کیا جا سکتا۔ مثال کے طور پر، میٹاماسک کی ڈیلیگیشن ٹول کٹ (opens in a new tab) واضح طور پر کسی بھی چین پر کسی بھی ERC-4337 بنڈلر یا پے ماسٹر کے ساتھ کام کرتی ہے، بجائے اس کے کہ اسے میٹاماسک کے مخصوص سرور کی ضرورت ہو۔

والیٹ انٹرفیسز کے ذریعے dApps کا انضمام:

یہ دیکھتے ہوئے کہ والیٹس EIP-7702 کے لیے مخصوص تفویض کنٹریکٹس کو وائٹ لسٹ کریں گے، dApps کو براہ راست 7702 اجازت ناموں کی درخواست کرنے کی توقع نہیں کرنی چاہیے۔ اس کے بجائے، انضمام معیاری والیٹ انٹرفیسز کے ذریعے ہونا چاہیے:

• ERC-5792 (wallet_sendCalls): dApps کو والیٹس سے بیچڈ کالز (batched calls) پر عمل کرنے کی درخواست کرنے کے قابل بناتا ہے، جس سے ٹرانزیکشن بیچنگ اور گیس کی تجرید جیسی خصوصیات میں سہولت ملتی ہے۔

• ERC-6900: dApps کو والیٹ کے زیر انتظام ماڈیولز کے ذریعے ماڈیولر اسمارٹ اکاؤنٹ کی صلاحیتوں، جیسے سیشن کیز اور اکاؤنٹ کی بحالی، سے فائدہ اٹھانے کی اجازت دیتا ہے۔

ان انٹرفیسز کا استعمال کرتے ہوئے، dApps براہ راست تفویض کا انتظام کیے بغیر EIP-7702 کے ذریعے فراہم کردہ اسمارٹ اکاؤنٹ کی خصوصیات تک رسائی حاصل کر سکتی ہیں، جس سے مختلف والیٹ کے نفاذ میں مطابقت اور سیکیورٹی کو یقینی بنایا جا سکتا ہے۔

نوٹ: dApps کے لیے براہ راست 7702 اجازت نامے کے دستخط کی درخواست کرنے کا کوئی معیاری طریقہ نہیں ہے۔ EIP-7702 کی خصوصیات سے فائدہ اٹھانے کے لیے dApps کو ERC-6900 جیسے مخصوص والیٹ انٹرفیسز پر انحصار کرنا چاہیے۔

مزید معلومات کے لیے:

• ERC-5792 کی تفصیلات (opens in a new tab)
• ERC-6900 کی تفصیلات (opens in a new tab)

وینڈر لاک ان سے گریز: مندرجہ بالا کے مطابق، ایک اچھا نفاذ وینڈر نیوٹرل اور قابلِ باہمی عمل ہوتا ہے۔ اس کا مطلب اکثر اسمارٹ اکاؤنٹس کے ابھرتے ہوئے معیارات پر عمل کرنا ہوتا ہے۔ مثال کے طور پر، Alchemy کا ماڈیولر اکاؤنٹ (opens in a new tab) ماڈیولر اسمارٹ اکاؤنٹس کے لیے ERC-6900 معیار کا استعمال کرتا ہے اور اسے "بلا اجازت قابلِ باہمی عمل استعمال" کو ذہن میں رکھ کر ڈیزائن کیا گیا ہے۔

رازداری کا تحفظ: اگرچہ آن چین رازداری محدود ہے، ایک تفویض کنٹریکٹ کو ڈیٹا کے افشاء اور ربط (linkability) کو کم سے کم کرنے کی کوشش کرنی چاہیے۔ یہ ERC-20 ٹوکنز میں گیس کی ادائیگی (تاکہ صارفین کو عوامی ETH بیلنس برقرار رکھنے کی ضرورت نہ پڑے، جو رازداری اور UX کو بہتر بناتا ہے) اور ون ٹائم سیشن کیز (جو ایک طویل مدتی کلید پر انحصار کم کرتی ہیں) جیسی خصوصیات کی حمایت کر کے حاصل کیا جا سکتا ہے۔ مثال کے طور پر، EIP-7702 اسپانسر شدہ ٹرانزیکشنز کے ذریعے ٹوکنز میں گیس ادا کرنے کے قابل بناتا ہے، اور ایک اچھا نفاذ ضرورت سے زیادہ معلومات لیک کیے بغیر ایسے پے ماسٹرز کو مربوط کرنا آسان بنا دے گا۔ مزید برآں، کچھ منظوریوں کی آف چین تفویض (ایسے دستخطوں کا استعمال کرتے ہوئے جن کی آن چین تصدیق کی جاتی ہے) کا مطلب صارف کی بنیادی کلید کے ساتھ کم آن چین ٹرانزیکشنز ہیں، جو رازداری میں مدد کرتی ہیں۔ ایسے اکاؤنٹس جن کے لیے ریلے استعمال کرنے کا تقاضا ہوتا ہے، صارفین کو اپنے IP پتے ظاہر کرنے پر مجبور کرتے ہیں۔ عوامی میم پولز (PublicMempools) اس میں بہتری لاتے ہیں، جب کوئی ٹرانزیکشن/UserOp میم پول کے ذریعے پھیلتی ہے تو آپ یہ نہیں بتا سکتے کہ آیا یہ اس IP سے شروع ہوئی جس نے اسے بھیجا تھا، یا صرف p2p پروٹوکول کے ذریعے اس سے ریلے کی گئی تھی۔

توسیع پذیری اور ماڈیولر سیکیورٹی: اکاؤنٹ کے نفاذ کو قابل توسیع ہونا چاہیے تاکہ وہ نئی خصوصیات اور سیکیورٹی میں بہتری کے ساتھ تیار ہو سکیں۔ EIP-7702 کے ساتھ اپ گریڈ کرنے کی صلاحیت فطری طور پر ممکن ہے (کیونکہ ایک EOA مستقبل میں اپنی منطق کو اپ گریڈ کرنے کے لیے ہمیشہ ایک نئے کنٹریکٹ کو تفویض کر سکتا ہے)۔ اپ گریڈ کرنے کی صلاحیت کے علاوہ، ایک اچھا ڈیزائن ماڈیولرٹی کی اجازت دیتا ہے – مثلاً، مختلف دستخطی اسکیموں یا اخراجات کی پالیسیوں کے لیے پلگ ان ماڈیولز – مکمل طور پر دوبارہ تعینات کرنے کی ضرورت کے بغیر۔ Alchemy کی اکاؤنٹ کٹ ایک بہترین مثال ہے، جو ڈیولپرز کو توثیقی ماڈیولز (مختلف دستخطی اقسام جیسے ECDSA، BLS وغیرہ کے لیے) اور کسٹم منطق کے لیے ایگزیکیوشن ماڈیولز انسٹال کرنے کی اجازت دیتی ہے۔ EIP-7702 سے چلنے والے اکاؤنٹس میں زیادہ لچک اور سیکیورٹی حاصل کرنے کے لیے، ڈیولپرز کی حوصلہ افزائی کی جاتی ہے کہ وہ براہ راست کسی مخصوص نفاذ کے بجائے پراکسی کنٹریکٹ کو تفویض کریں۔ یہ نقطہ نظر ہر تبدیلی کے لیے اضافی EIP-7702 اجازت ناموں کی ضرورت کے بغیر ہموار اپ گریڈ اور ماڈیولرٹی کی اجازت دیتا ہے۔

پراکسی پیٹرن کے فوائد:

• اپ گریڈ کرنے کی صلاحیت: پراکسی کو ایک نئے نفاذ کے کنٹریکٹ کی طرف اشارہ کر کے کنٹریکٹ کی منطق کو اپ ڈیٹ کریں۔

• کسٹم انیشلائزیشن منطق: ضروری حالت (state) کے متغیرات کو محفوظ طریقے سے ترتیب دینے کے لیے پراکسی کے اندر انیشلائزیشن فنکشنز کو شامل کریں۔

مثال کے طور پر، SafeEIP7702Proxy (opens in a new tab) یہ ظاہر کرتا ہے کہ EIP-7702 کے ساتھ ہم آہنگ اکاؤنٹس میں تفویض کو محفوظ طریقے سے شروع کرنے اور ان کا انتظام کرنے کے لیے پراکسی کا استعمال کیسے کیا جا سکتا ہے۔

پراکسی پیٹرن کے نقصانات:

• بیرونی عناصر پر انحصار: آپ کو کسی بیرونی ٹیم پر انحصار کرنا پڑتا ہے کہ وہ کسی غیر محفوظ کنٹریکٹ میں اپ گریڈ نہ کرے۔

سیکیورٹی کے تحفظات

ری اینٹرنسی گارڈ: EIP-7702 تفویض کے متعارف ہونے کے ساتھ، صارف کا اکاؤنٹ متحرک طور پر ایک بیرونی ملکیت والے اکاؤنٹ (EOA) اور ایک سمارٹ کنٹریکٹ (SC) کے درمیان سوئچ کر سکتا ہے۔ یہ لچک اکاؤنٹ کو ٹرانزیکشنز شروع کرنے اور کالز کا ہدف بننے دونوں کے قابل بناتی ہے۔ نتیجے کے طور پر، ایسے منظرنامے جہاں ایک اکاؤنٹ خود کو کال کرتا ہے اور بیرونی کالز کرتا ہے، ان میں msg.sender tx.origin کے برابر ہوگا، جو کچھ سیکیورٹی مفروضوں کو کمزور کرتا ہے جو پہلے اس بات پر انحصار کرتے تھے کہ tx.origin ہمیشہ ایک EOA ہوتا ہے۔

سمارٹ کنٹریکٹ ڈیولپرز کے لیے، اب یہ فرض کرنا محفوظ نہیں ہے کہ tx.origin کسی EOA کی طرف اشارہ کرتا ہے۔ اسی طرح، مکرر داخلہ (reentrancy) کے حملوں سے بچاؤ کے طور پر msg.sender == tx.origin کا استعمال اب کوئی قابل اعتماد حکمت عملی نہیں ہے۔

مستقبل میں، ڈیولپرز کو اس مفروضے کے ساتھ ڈیزائن کرنا چاہیے کہ سسٹم میں کوئی بھی شریک سمارٹ کنٹریکٹ ہو سکتا ہے۔ متبادل کے طور پر وہ nonReentrant موڈیفائر پیٹرنز کے ساتھ ری اینٹرنسی گارڈز کا استعمال کرتے ہوئے واضح مکرر داخلہ کے تحفظ کو نافذ کر سکتے ہیں۔ ہم ایک آڈٹ شدہ موڈیفائر کی پیروی کرنے کی تجویز کرتے ہیں مثلاً Open Zeppelin کا ری اینٹرنسی گارڈ (opens in a new tab)۔ وہ ایک عارضی اسٹوریج متغیر (transient storage variable) (opens in a new tab) بھی استعمال کر سکتے ہیں۔

انیشلائزیشن سیکیورٹی کے تحفظات

EIP-7702 تفویض کنٹریکٹس کو نافذ کرنا مخصوص سیکیورٹی چیلنجز متعارف کراتا ہے، خاص طور پر انیشلائزیشن کے عمل کے حوالے سے۔ ایک اہم کمزوری اس وقت پیدا ہوتی ہے جب انیشلائزیشن فنکشن (init) کو تفویض کے عمل کے ساتھ ایٹمی طور پر (atomically) جوڑا جاتا ہے۔ ایسے معاملات میں، ایک فرنٹ رنر تفویض کے دستخط کو روک سکتا ہے اور تبدیل شدہ پیرامیٹرز کے ساتھ init فنکشن کو چلا سکتا ہے، جس سے ممکنہ طور پر اکاؤنٹ کا کنٹرول حاصل کیا جا سکتا ہے۔

یہ خطرہ خاص طور پر اس وقت متعلقہ ہوتا ہے جب موجودہ اسمارٹ کنٹریکٹ اکاؤنٹ (SCA) کے نفاذ کو ان کے انیشلائزیشن میکانزم میں ترمیم کیے بغیر EIP-7702 کے ساتھ استعمال کرنے کی کوشش کی جائے۔

انیشلائزیشن کی کمزوریوں کو کم کرنے کے حل

• initWithSig کو نافذ کریں
  معیاری init فنکشن کو ایک initWithSig فنکشن سے تبدیل کریں جو صارف سے انیشلائزیشن پیرامیٹرز پر دستخط کرنے کا تقاضا کرتا ہے۔ یہ نقطہ نظر اس بات کو یقینی بناتا ہے کہ انیشلائزیشن صرف صارف کی واضح رضامندی کے ساتھ ہی آگے بڑھ سکتی ہے، اس طرح غیر مجاز انیشلائزیشن کے خطرات کو کم کیا جا سکتا ہے۔

• ERC-4337 کے EntryPoint کا استعمال کریں
  یہ تقاضا کریں کہ انیشلائزیشن فنکشن کو خصوصی طور پر ERC-4337 EntryPoint کنٹریکٹ سے کال کیا جائے۔ یہ طریقہ ERC-4337 کے ذریعے فراہم کردہ معیاری توثیق اور ایگزیکیوشن فریم ورک کا فائدہ اٹھاتا ہے، جس سے انیشلائزیشن کے عمل میں سیکیورٹی کی ایک اضافی تہہ شامل ہوتی ہے۔
  (دیکھیں: Safe کی دستاویزات (opens in a new tab))

ان حلوں کو اپنا کر، ڈیولپرز EIP-7702 تفویض کنٹریکٹس کی سیکیورٹی کو بڑھا سکتے ہیں، اور انیشلائزیشن کے مرحلے کے دوران ممکنہ فرنٹ رننگ حملوں سے بچاؤ کر سکتے ہیں۔

اسٹوریج کا ٹکراؤ کوڈ تفویض کرنے سے موجودہ اسٹوریج صاف نہیں ہوتا ہے۔ ایک تفویض کنٹریکٹ سے دوسرے میں منتقل ہوتے وقت، پچھلے کنٹریکٹ کا بقیہ ڈیٹا باقی رہتا ہے۔ اگر نیا کنٹریکٹ انہی اسٹوریج سلاٹس کا استعمال کرتا ہے لیکن ان کی تشریح مختلف طریقے سے کرتا ہے، تو یہ غیر ارادی رویے کا سبب بن سکتا ہے۔ مثال کے طور پر، اگر ابتدائی تفویض ایک ایسے کنٹریکٹ کو کی گئی تھی جہاں ایک اسٹوریج سلاٹ bool کی نمائندگی کرتا ہے، اور بعد کی تفویض ایک ایسے کنٹریکٹ کو کی جاتی ہے جہاں وہی سلاٹ uint کی نمائندگی کرتا ہے، تو یہ عدم مطابقت غیر متوقع نتائج کا باعث بن سکتی ہے۔

فشنگ کے خطرات EIP-7702 تفویض کے نفاذ کے ساتھ، صارف کے اکاؤنٹ میں موجود اثاثے مکمل طور پر سمارٹ کنٹریکٹس کے کنٹرول میں ہو سکتے ہیں۔ اگر کوئی صارف نادانستہ طور پر اپنا اکاؤنٹ کسی بدنیتی پر مبنی کنٹریکٹ کو تفویض کر دیتا ہے، تو حملہ آور آسانی سے کنٹرول حاصل کر سکتا ہے اور فنڈز چرا سکتا ہے۔ جب chain_id=0 استعمال کیا جاتا ہے تو تفویض تمام چین آئی ڈیز پر لاگو ہوتی ہے۔ صرف ایک ناقابلِ تبدیلی کنٹریکٹ کو تفویض کریں (کبھی بھی پراکسی کو تفویض نہ کریں)، اور صرف ان کنٹریکٹس کو جو CREATE2 کا استعمال کرتے ہوئے تعینات کیے گئے تھے (معیاری initcode کے ساتھ - کوئی میٹامورفک کنٹریکٹس نہیں) تاکہ تعینات کرنے والا کہیں اور اسی پتے پر کچھ مختلف تعینات نہ کر سکے۔ بصورت دیگر آپ کی تفویض آپ کے اکاؤنٹ کو دیگر تمام EVM چینز پر خطرے میں ڈال دیتی ہے۔

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

کم از کم قابل اعتماد سطح اور سیکیورٹی: لچک پیش کرنے کے باوجود، ایک تفویض کنٹریکٹ کو اپنی بنیادی منطق کو کم سے کم اور قابل آڈٹ رکھنا چاہیے۔ یہ کنٹریکٹ مؤثر طریقے سے صارف کے EOA کی توسیع ہے، لہذا کوئی بھی خامی تباہ کن ہو سکتی ہے۔ نفاذ کو سمارٹ کنٹریکٹ سیکیورٹی کمیونٹی کے بہترین طرز عمل کی پیروی کرنی چاہیے۔ مثال کے طور پر، کنسٹرکٹر یا انیشلائزر فنکشنز کو احتیاط سے محفوظ کیا جانا چاہیے – جیسا کہ Alchemy نے روشنی ڈالی ہے، اگر 7702 کے تحت پراکسی پیٹرن استعمال کیا جا رہا ہے، تو ایک غیر محفوظ انیشلائزر حملہ آور کو اکاؤنٹ پر قبضہ کرنے دے سکتا ہے۔ ٹیموں کا مقصد آن چین کوڈ کو سادہ رکھنا ہونا چاہیے: Ambire کا 7702 کنٹریکٹ صرف ~200 لائنوں کا Solidity کوڈ ہے، جو بگز کو کم کرنے کے لیے جان بوجھ کر پیچیدگی کو کم کرتا ہے۔ خصوصیات سے بھرپور منطق اور سادگی کے درمیان توازن قائم کیا جانا چاہیے جو آڈیٹنگ کو آسان بناتا ہے۔

معلوم نفاذ

EIP 7702 کی نوعیت کی وجہ سے، یہ تجویز کیا جاتا ہے کہ صارفین کو کسی تیسرے فریق کے کنٹریکٹ کو تفویض کرنے میں مدد کرتے وقت والیٹس احتیاط برتیں۔ نیچے معلوم نفاذ کا ایک مجموعہ درج ہے جن کا آڈٹ کیا جا چکا ہے:

ہارڈویئر والیٹ کی ہدایات

ہارڈویئر والیٹس کو من مانی تفویض کو ظاہر نہیں کرنا چاہیے۔ ہارڈویئر والیٹ کی جگہ میں اتفاق رائے قابل اعتماد ڈیلیگیٹر کنٹریکٹس کی فہرست استعمال کرنے پر ہے۔ ہم تجویز کرتے ہیں کہ اوپر درج معلوم نفاذ کی اجازت دی جائے اور دوسروں پر انفرادی بنیادوں پر غور کیا جائے۔ چونکہ آپ کے EOA کو کسی کنٹریکٹ میں تفویض کرنے سے تمام اثاثوں پر کنٹرول مل جاتا ہے، اس لیے ہارڈویئر والیٹس کو 7702 کو نافذ کرنے کے طریقے میں محتاط رہنا چاہیے۔

ساتھی ایپس کے لیے انضمام کے منظرنامے

سست (Lazy)

چونکہ EOA اب بھی معمول کے مطابق کام کرتا ہے، اس لیے کرنے کو کچھ نہیں ہے۔

نوٹ: کچھ اثاثے تفویض کوڈ کے ذریعے خود بخود مسترد کیے جا سکتے ہیں، جیسے کہ ERC-1155 NFTs، اور سپورٹ کو اس سے آگاہ ہونا چاہیے۔

باخبر (Aware)

اس کا کوڈ چیک کر کے صارف کو مطلع کریں کہ EOA کے لیے ایک تفویض موجود ہے، اور اختیاری طور پر تفویض کو ہٹانے کی پیشکش کریں۔

عام تفویض

ہارڈویئر فراہم کنندہ معلوم تفویض کنٹریکٹس کو وائٹ لسٹ کرتا ہے اور سافٹ ویئر ساتھی میں ان کی سپورٹ کو نافذ کرتا ہے۔ مکمل ERC-4337 سپورٹ کے ساتھ کنٹریکٹ کا انتخاب کرنے کی سفارش کی جاتی ہے۔

کسی مختلف کو تفویض کردہ EOAs کو معیاری EOAs کے طور پر ہینڈل کیا جائے گا۔

کسٹم تفویض

ہارڈویئر فراہم کنندہ اپنا تفویض کنٹریکٹ نافذ کرتا ہے اور اسے فہرستوں میں شامل کرتا ہے، اور سافٹ ویئر ساتھی میں اس کی سپورٹ کو نافذ کرتا ہے۔ مکمل ERC-4337 سپورٹ کے ساتھ کنٹریکٹ بنانے کی سفارش کی جاتی ہے۔

کسی مختلف کو تفویض کردہ EOAs کو معیاری EOAs کے طور پر ہینڈل کیا جائے گا۔

صفحہ کی آخری اپ ڈیٹ: ۶ جون، ۲۰۲۶

p (opens in a new tab)

c (opens in a new tab)

j (opens in a new tab)

+6

تعاون کنندگان دیکھیں