Pectra 7702

خلاصہ

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

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

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

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

ڈیلیگیشن کو null ایڈریس پر ڈیلیگیٹ کر کے ری سیٹ کیا جا سکتا ہے۔

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

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

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

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

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

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

والیٹ انٹرفیسز کے ذریعے 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

معلوم نفاذ

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

ہارڈویئر والیٹ کی گائیڈ لائنز

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

ساتھی ایپس (companion apps) کے لیے انضمام کے منظرنامے

سست (Lazy)

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

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

باخبر (Aware)

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

عام ڈیلیگیشن

ہارڈویئر فراہم کنندہ معلوم ڈیلیگیشن کنٹریکٹس کو وائٹ لسٹ کرتا ہے اور سافٹ ویئر ساتھی (software companion) میں ان کی سپورٹ کو نافذ کرتا ہے۔ مکمل 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

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