Pectra 7702

सारांश

EIP 7702 हे EOA मध्ये कोड जोडण्यासाठी एक यंत्रणा परिभाषित करते. हा प्रस्ताव EOAs, म्हणजेच लेगसी Ethereum खात्यांना, अल्पकालीन कार्यक्षमता सुधारणा प्राप्त करण्यास अनुमती देतो, ज्यामुळे ॲप्लिकेशन्सची उपयोगिता वाढते. हे नवीन ट्रान्झॅक्शन प्रकार: 4 वापरून आधीच तैनात केलेल्या कोडवर एक पॉइंटर सेट करून केले जाते.

हा नवीन ट्रान्झॅक्शन प्रकार एक ऑथोरायझेशन सूची सादर करतो. सूचीमधील प्रत्येक ऑथोरायझेशन टपल खालीलप्रमाणे परिभाषित केले आहे

[ 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])) म्हणून परिभाषित केले आहे, ज्यावर ऑथोरायझेशन लागू होते (याला अथॉरिटी असेही म्हणतात)

नल ॲड्रेसवर डेलिगेट करून डेलिगेशन रीसेट केले जाऊ शकते.

डेलिगेशननंतर EOA ची प्रायव्हेट की खात्यावर पूर्ण नियंत्रण ठेवते. उदाहरणार्थ, Safe वर डेलिगेट केल्याने खाते multisig बनत नाही कारण अजूनही एक सिंगल की आहे जी कोणत्याही स्वाक्षरी धोरणाला बायपास करू शकते. पुढे जाऊन, डेव्हलपर्सनी या गृहितकासह डिझाइन केले पाहिजे की सिस्टममधील कोणताही सहभागी एक स्मार्ट कॉन्ट्रॅक्ट असू शकतो. स्मार्ट कॉन्ट्रॅक्ट डेव्हलपर्ससाठी, tx.origin हे EOA ला संदर्भित करते असे गृहित धरणे आता सुरक्षित नाही.

सर्वोत्तम पद्धती

खाते ॲब्स्ट्रॅक्शन: कम्पॅटिबिलिटी जास्तीत जास्त वाढवण्यासाठी डेलिगेशन कॉन्ट्रॅक्ट Ethereum च्या व्यापक खाते ॲब्स्ट्रॅक्शन (AA) मानकांशी सुसंगत असावा. विशेषतः, ते आदर्शपणे ERC-4337 अनुरूप किंवा सुसंगत असावे.

परवानगी-रहित आणि सेन्सॉरशिप-प्रतिरोधक डिझाइन: Ethereum परवानगी-रहित सहभागाला महत्त्व देते. डेलिगेशन कॉन्ट्रॅक्टने कोणत्याही एका 'विश्वसनीय' रिलेयर किंवा सेवेवर हार्ड-कोड किंवा अवलंबून राहू नये. जर रिलेयर ऑफलाइन गेला तर यामुळे खाते बंद पडेल. बॅचिंगसारखी वैशिष्ट्ये (उदा., approve+transferFrom) EOA स्वतः रिलेयरशिवाय वापरू शकते. 7702 द्वारे सक्षम केलेल्या प्रगत वैशिष्ट्यांचा (गॅस ॲब्स्ट्रॅक्शन, प्रायव्हसी-प्रिझर्विंग विथड्रॉवल्स) वापर करू इच्छिणाऱ्या ॲप्लिकेशन डेव्हलपर्ससाठी, तुम्हाला रिलेयरची आवश्यकता असेल. जरी विविध रिलेयर आर्किटेक्चर्स असले तरी, आमची शिफारस 4337 बंडलर्स (opens in a new tab) वापरण्याची आहे जे किमान एंट्री पॉइंट 0.8 (opens in a new tab) कडे निर्देशित करतात, कारण:

• ते रिलेयिंगसाठी प्रमाणित इंटरफेस प्रदान करतात
• अंगभूत पेमास्टर सिस्टीम समाविष्ट करतात
• फॉरवर्ड कम्पॅटिबिलिटी सुनिश्चित करतात
• पब्लिक मेमपूल (opens in a new tab) द्वारे सेन्सॉरशिप प्रतिरोधास समर्थन देऊ शकतात
• init फंक्शन फक्त एंट्रीपॉइंट (opens in a new tab) वरून कॉल केले जावे अशी आवश्यकता ठेवू शकतात

दुसऱ्या शब्दांत, जोपर्यंत ते खात्यातून आवश्यक वैध स्वाक्षरी किंवा UserOperation प्रदान करतात, तोपर्यंत कोणीही ट्रान्झॅक्शन प्रायोजक/रिलेयर म्हणून काम करू शकले पाहिजे. हे सेन्सॉरशिप प्रतिरोध सुनिश्चित करते: जर कोणत्याही कस्टम इन्फ्रास्ट्रक्चरची आवश्यकता नसेल, तर वापरकर्त्याचे व्यवहार गेटकीपिंग रिलेद्वारे मनमानीपणे ब्लॉक केले जाऊ शकत नाहीत. उदाहरणार्थ, MetaMask’s Delegation Toolkit (opens in a new tab) कोणत्याही चेनवरील कोणत्याही ERC-4337 बंडलर किंवा पेमास्टरसोबत स्पष्टपणे काम करते, MetaMask-विशिष्ट सर्व्हरची आवश्यकता ठेवण्याऐवजी.

वॉलेट इंटरफेसद्वारे dApps एकत्रीकरण:

वॉलेट्स EIP-7702 साठी विशिष्ट डेलिगेशन कॉन्ट्रॅक्ट्सना व्हाइटलिस्ट करतील हे पाहता, dApps नी थेट 7702 ऑथोरायझेशनची विनंती करण्याची अपेक्षा करू नये. त्याऐवजी, एकत्रीकरण प्रमाणित वॉलेट इंटरफेसद्वारे झाले पाहिजे:

• ERC-5792 (wallet_sendCalls): dApps ना बॅच केलेल्या कॉल्स कार्यान्वित करण्यासाठी वॉलेट्सना विनंती करण्यास सक्षम करते, ज्यामुळे ट्रान्झॅक्शन बॅचिंग आणि गॅस ॲब्स्ट्रॅक्शनसारख्या कार्यक्षमता सुलभ होतात.

• 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’s Modular Account (opens in a new tab) मॉड्युलर स्मार्ट खात्यांसाठी ERC-6900 मानक वापरते आणि 'परवानगी-रहित इंटरऑपरेबल वापर' लक्षात घेऊन डिझाइन केलेले आहे.

गोपनीयतेचे संरक्षण: ऑनचेन गोपनीयता मर्यादित असली तरी, एका डेलिगेशन कॉन्ट्रॅक्टने डेटा एक्सपोजर आणि लिंकेबिलिटी कमी करण्याचा प्रयत्न केला पाहिजे. हे ERC-20 टोकन्समध्ये गॅस पेमेंट (जेणेकरून वापरकर्त्यांना सार्वजनिक ETH शिल्लक ठेवण्याची गरज नाही, ज्यामुळे गोपनीयता आणि UX सुधारते) आणि वन-टाइम सेशन की (जे एकाच दीर्घकालीन की वरील अवलंबित्व कमी करतात) यासारख्या वैशिष्ट्यांना समर्थन देऊन साध्य केले जाऊ शकते. उदाहरणार्थ, EIP-7702 प्रायोजित व्यवहारांद्वारे टोकन्समध्ये गॅस भरण्यास सक्षम करते, आणि एक चांगली अंमलबजावणी आवश्यकतेपेक्षा जास्त माहिती लीक न करता अशा पेमास्टर्सना समाकलित करणे सोपे करेल. याव्यतिरिक्त, विशिष्ट मंजुरींचे ऑफ-चेन डेलिगेशन (ऑनचेन सत्यापित होणाऱ्या स्वाक्षऱ्या वापरून) म्हणजे वापरकर्त्याच्या प्राथमिक की सह कमी ऑनचेन व्यवहार होतात, ज्यामुळे गोपनीयतेस मदत होते. ज्या खात्यांना रिलेयर वापरण्याची आवश्यकता असते, ती वापरकर्त्यांना त्यांचे IP ॲड्रेस उघड करण्यास भाग पाडतात. पब्लिक मेमपूल्स यात सुधारणा करतात, जेव्हा एखादे ट्रान्झॅक्शन/UserOp मेमपूलमधून प्रसारित होते, तेव्हा ते पाठवणाऱ्या IP मधून आले आहे की फक्त p2p प्रोटोकॉलद्वारे रिले झाले आहे हे सांगता येत नाही.

विस्तारक्षमता आणि मॉड्युलर सुरक्षा: खाते अंमलबजावणी विस्तारक्षम असावी जेणेकरून ती नवीन वैशिष्ट्ये आणि सुरक्षा सुधारणांसह विकसित होऊ शकतील. EIP-7702 सह अपग्रेडेबिलिटी मूळतः शक्य आहे (कारण EOA भविष्यात त्याचे लॉजिक अपग्रेड करण्यासाठी नेहमी नवीन कॉन्ट्रॅक्टला डेलिगेट करू शकते). अपग्रेडेबिलिटीच्या पलीकडे, एक चांगले डिझाइन मॉड्युलॅरिटीला परवानगी देते – उदा., वेगवेगळ्या स्वाक्षरी योजना किंवा खर्च धोरणांसाठी प्लग-इन मॉड्यूल्स – पूर्णपणे पुन्हा तैनात करण्याची आवश्यकता न ठेवता. Alchemy’s Account Kit हे याचे उत्तम उदाहरण आहे, जे डेव्हलपर्सना व्हॅलिडेशन मॉड्यूल्स (ECDSA, BLS, इत्यादी विविध स्वाक्षरी प्रकारांसाठी) स्थापित करण्याची परवानगी देते. आणि कस्टम लॉजिकसाठी एक्झिक्युशन मॉड्यूल्स. EIP-7702-सक्षम खात्यांमध्ये अधिक लवचिकता आणि सुरक्षा मिळवण्यासाठी, डेव्हलपर्सना थेट विशिष्ट अंमलबजावणीवर डेलिगेट करण्याऐवजी प्रॉक्सी कॉन्ट्रॅक्टला डेलिगेट करण्यास प्रोत्साहित केले जाते. हा दृष्टिकोन प्रत्येक बदलासाठी अतिरिक्त EIP-7702 ऑथोरायझेशनची आवश्यकता न ठेवता अखंड अपग्रेड आणि मॉड्युलॅरिटीला परवानगी देतो.

प्रॉक्सी पॅटर्नचे फायदे:

• अपग्रेडेबिलिटी: प्रॉक्सीला नवीन अंमलबजावणी कॉन्ट्रॅक्टकडे निर्देशित करून कॉन्ट्रॅक्ट लॉजिक अपडेट करा.

• कस्टम इनिशियलायझेशन लॉजिक: आवश्यक स्टेट व्हेरिएबल्स सुरक्षितपणे सेट करण्यासाठी प्रॉक्सीमध्ये इनिशियलायझेशन फंक्शन्स समाविष्ट करा.

उदाहरणार्थ, SafeEIP7702Proxy (opens in a new tab) दाखवते की EIP-7702-सुसंगत खात्यांमध्ये डेलिगेशन्स सुरक्षितपणे सुरू करण्यासाठी आणि व्यवस्थापित करण्यासाठी प्रॉक्सीचा कसा वापर केला जाऊ शकतो.

प्रॉक्सी पॅटर्नचे तोटे:

• बाह्य घटकांवर अवलंबित्व: असुरक्षित कॉन्ट्रॅक्टवर अपग्रेड न करण्यासाठी तुम्हाला बाह्य टीमवर अवलंबून राहावे लागेल.

सुरक्षिततेच्या बाबी

रीएन्ट्रन्सी गार्ड: EIP-7702 डेलिगेशनच्या परिचयाने, वापरकर्त्याचे खाते एका एक्सटर्नली ओन्ड अकाउंट (EOA) आणि स्मार्ट कॉन्ट्रॅक्ट (SC) मध्ये गतिमानपणे बदलू शकते. ही लवचिकता खात्याला व्यवहार सुरू करण्यासाठी आणि कॉल्सचे लक्ष्य बनण्यासाठी दोन्हीसाठी सक्षम करते. परिणामी, ज्या परिस्थितीत खाते स्वतःला कॉल करते आणि बाह्य कॉल करते, तेथे msg.sender हे tx.origin च्या बरोबर असेल, जे पूर्वी tx.origin नेहमी EOA असण्यावर अवलंबून असलेल्या काही सुरक्षा गृहितकांना कमकुवत करते.

स्मार्ट कॉन्ट्रॅक्ट डेव्हलपर्ससाठी, tx.origin हे EOA ला संदर्भित करते असे गृहित धरणे आता सुरक्षित नाही. त्याचप्रमाणे, रीएन्ट्रन्सी हल्ल्यांपासून संरक्षणासाठी msg.sender == tx.origin चा वापर करणे आता एक विश्वसनीय धोरण नाही.

पुढे जाऊन, डेव्हलपर्सनी या गृहितकासह डिझाइन केले पाहिजे की सिस्टममधील कोणताही सहभागी एक स्मार्ट कॉन्ट्रॅक्ट असू शकतो. पर्यायाने, ते nonReentrant मॉडिफायर पॅटर्नसह रीएन्ट्रन्सी गार्ड्स वापरून स्पष्ट रीएन्ट्रन्सी संरक्षण लागू करू शकतात. आम्ही ऑडिट केलेल्या मॉडिफायरचे अनुसरण करण्याची शिफारस करतो, उदा. Open Zeppelin's Reentrancy Guard (opens in a new tab). ते ट्रान्झिएंट स्टोरेज व्हेरिएबल (opens in a new tab) चा वापर देखील करू शकतात.

इनिशियलायझेशन सुरक्षा विचार

EIP-7702 डेलिगेशन कॉन्ट्रॅक्ट्सची अंमलबजावणी विशिष्ट सुरक्षा आव्हाने निर्माण करते, विशेषतः इनिशियलायझेशन प्रक्रियेबद्दल. जेव्हा इनिशियलायझेशन फंक्शन (init) डेलिगेशन प्रक्रियेशी आण्विकपणे जोडले जाते तेव्हा एक गंभीर धोका निर्माण होतो. अशा प्रकरणांमध्ये, एक फ्रंटरनर डेलिगेशन स्वाक्षरीला अडवू शकतो आणि बदललेल्या पॅरामीटर्ससह init फंक्शन कार्यान्वित करू शकतो, ज्यामुळे संभाव्यतः खात्यावर नियंत्रण मिळवले जाऊ शकते.

जेव्हा त्यांच्या इनिशियलायझेशन यंत्रणेत बदल न करता EIP-7702 सह विद्यमान स्मार्ट कॉन्ट्रॅक्ट अकाउंट (SCA) अंमलबजावणी वापरण्याचा प्रयत्न केला जातो, तेव्हा हा धोका विशेषतः संबंधित आहे.

इनिशियलायझेशन धोके कमी करण्यासाठी उपाय

• initWithSig लागू करा मानक init फंक्शनला initWithSig फंक्शनने बदला ज्यासाठी वापरकर्त्याला इनिशियलायझेशन पॅरामीटर्सवर स्वाक्षरी करणे आवश्यक आहे. हा दृष्टिकोन सुनिश्चित करतो की इनिशियलायझेशन केवळ वापरकर्त्याच्या स्पष्ट संमतीनेच पुढे जाऊ शकते, ज्यामुळे अनधिकृत इनिशियलायझेशनचे धोके कमी होतात.

• ERC-4337 च्या एंट्रीपॉइंटचा वापर करा इनिशियलायझेशन फंक्शन केवळ ERC-4337 एंट्रीपॉइंट कॉन्ट्रॅक्टमधूनच कॉल केले जावे अशी आवश्यकता ठेवा. ही पद्धत ERC-4337 द्वारे प्रदान केलेल्या प्रमाणित प्रमाणीकरण आणि अंमलबजावणी फ्रेमवर्कचा फायदा घेते, ज्यामुळे इनिशियलायझेशन प्रक्रियेत सुरक्षेचा अतिरिक्त स्तर जोडला जातो.
  (पहा: Safe Docs (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 च्या स्वरूपामुळे, वापरकर्त्यांना 3ऱ्या पक्षाच्या कॉन्ट्रॅक्टला डेलिगेट करण्यास मदत करताना वॉलेट्सनी सावधगिरी बाळगण्याची शिफारस केली जाते. खाली ऑडिट केलेल्या ज्ञात अंमलबजावणीचा संग्रह दिला आहे:

हार्डवेअर वॉलेट मार्गदर्शक तत्त्वे

हार्डवेअर वॉलेट्सनी मनमानी डेलिगेशन उघड करू नये. हार्डवेअर वॉलेट क्षेत्रात विश्वासार्ह डेलिगेटर कॉन्ट्रॅक्ट्सची सूची वापरण्यावर एकमत आहे. आम्ही वर सूचीबद्ध केलेल्या ज्ञात अंमलबजावणींना परवानगी देण्याची आणि इतरांचा विचार प्रकरण-दर-प्रकरण आधारावर करण्याची सूचना देतो. तुमचे EOA एका कॉन्ट्रॅक्टला डेलिगेट केल्याने सर्व मालमत्तेवर नियंत्रण मिळत असल्याने, हार्डवेअर वॉलेट्सनी 7702 ची अंमलबजावणी करण्याच्या पद्धतीबद्दल सावधगिरी बाळगली पाहिजे.

कम्पेनियन ॲप्ससाठी एकत्रीकरण परिस्थिती

निष्क्रिय

EOA अजूनही नेहमीप्रमाणेच काम करत असल्याने, काहीही करण्याची गरज नाही.

टीप : काही मालमत्ता, जसे की ERC 1155 NFTs, डेलिगेशन कोडद्वारे आपोआप नाकारल्या जाऊ शकतात आणि सपोर्ट टीमला याची जाणीव असली पाहिजे.

जागरूक

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

योगदानकर्ता पहा