पेक्ट्रा 7702

सारांश

EIP-7702 हे बाह्य मालकीचे खाते (EOA) मध्ये कोड जोडण्यासाठी एक यंत्रणा परिभाषित करते. हा प्रस्ताव EOAs, जे पारंपारिक इथेरियम खाती आहेत, त्यांना अल्प-मुदतीच्या कार्यक्षमतेत सुधारणा प्राप्त करण्यास अनुमती देतो, ज्यामुळे ॲप्लिकेशन्सची उपयोगिता वाढते. हे एका नवीन व्यवहार प्रकाराचा वापर करून आधीच प्रस्थापित केलेल्या कोडकडे पॉइंटर सेट करून केले जाते: 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])) म्हणून परिभाषित केली जाते ज्याला अधिकृतता लागू होते (ज्याला ऑथॉरिटी देखील म्हटले जाते)

शून्य (null) पत्त्यावर अधिकारप्रदान करून अधिकारप्रदान रीसेट केले जाऊ शकते.

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

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

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

परवानगीमुक्त आणि सेन्सॉरशिप-प्रतिरोधक डिझाइन: इथेरियम परवानगीमुक्त सहभागाला महत्त्व देते. अधिकारप्रदान कॉन्ट्रॅक्टने कोणत्याही एका "विश्वसनीय" रिलेअर किंवा सेवेवर हार्ड-कोड किंवा अवलंबून राहू नये. जर रिलेअर ऑफलाइन गेला तर यामुळे खाते निकामी होईल. बॅचिंग (उदा., approve+transferFrom) सारखी वैशिष्ट्ये रिलेअरशिवाय बाह्य मालकीचे खाते (EOA) द्वारे स्वतः वापरली जाऊ शकतात. ॲप्लिकेशन डेव्हलपर्स ज्यांना EIP-7702 (गॅस अमूर्तीकरण, गोपनीयता-जतन करणारे पैसे काढणे) द्वारे सक्षम केलेली प्रगत वैशिष्ट्ये वापरायची आहेत, त्यांच्यासाठी तुम्हाला रिलेअरची आवश्यकता असेल. जरी भिन्न रिलेअर आर्किटेक्चर्स असले तरी, आमची शिफारस किमान entry point 0.8 (नवीन टॅबमध्ये उघडते) कडे निर्देश करणारे ERC-4337 बंडलर (नवीन टॅबमध्ये उघडते) वापरण्याची आहे कारण:

• ते रिलेइंगसाठी प्रमाणित इंटरफेस प्रदान करतात
• अंगभूत पेमास्टर सिस्टीम समाविष्ट करतात
• फॉरवर्ड सुसंगतता सुनिश्चित करतात
• सार्वजनिक मेमपूल (नवीन टॅबमध्ये उघडते) द्वारे सेन्सॉरशिप प्रतिकारास समर्थन देऊ शकतात
• init फंक्शन केवळ EntryPoint (नवीन टॅबमध्ये उघडते) मधूनच कॉल करणे आवश्यक करू शकतात

दुसऱ्या शब्दांत, जोपर्यंत ते खात्यातून आवश्यक वैध स्वाक्षरी किंवा वापरकर्ता कार्य (UserOperation) प्रदान करतात तोपर्यंत कोणीही व्यवहार प्रायोजक/रिलेअर म्हणून कार्य करण्यास सक्षम असावे. हे सेन्सॉरशिप प्रतिकार सुनिश्चित करते: जर कोणत्याही सानुकूल पायाभूत सुविधांची आवश्यकता नसेल, तर वापरकर्त्याचे व्यवहार गेटकीपिंग रिलेद्वारे अनियंत्रितपणे अवरोधित केले जाऊ शकत नाहीत. उदाहरणार्थ, मेटामास्कचे डेलिगेशन टूलकिट (नवीन टॅबमध्ये उघडते) मेटामास्क-विशिष्ट सर्व्हरची आवश्यकता असण्याऐवजी कोणत्याही चेनवरील कोणत्याही ERC-4337 बंडलर किंवा पेमास्टरसह स्पष्टपणे कार्य करते.

वॉलेट इंटरफेसद्वारे विकेंद्रित ॲप्लिकेशन (dapp) एकत्रीकरण:

वॉलेट्स EIP-7702 साठी विशिष्ट अधिकारप्रदान कॉन्ट्रॅक्ट्सना व्हाइटलिस्ट करतील हे लक्षात घेता, विकेंद्रित ॲप्लिकेशन्स (dapps) ने थेट EIP-7702 अधिकृततेची विनंती करण्याची अपेक्षा करू नये. त्याऐवजी, प्रमाणित वॉलेट इंटरफेसद्वारे एकत्रीकरण झाले पाहिजे:

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

• ERC-6900: विकेंद्रित ॲप्लिकेशन्सना (dapps) वॉलेट-व्यवस्थापित मॉड्यूल्सद्वारे मॉड्यूलर स्मार्ट खाते क्षमतांचा लाभ घेण्यास अनुमती देते, जसे की सेशन की आणि खाते पुनर्प्राप्ती.

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

टीप: विकेंद्रित ॲप्लिकेशन्सना (dapps) थेट EIP-7702 अधिकृतता स्वाक्षऱ्यांची विनंती करण्यासाठी कोणतीही प्रमाणित पद्धत नाही. EIP-7702 वैशिष्ट्यांचा लाभ घेण्यासाठी विकेंद्रित ॲप्लिकेशन्सना (dapps) ERC-6900 सारख्या विशिष्ट वॉलेट इंटरफेसवर अवलंबून राहावे लागते.

अधिक माहितीसाठी:

• ERC-5792 तपशील (नवीन टॅबमध्ये उघडते)
• ERC-6900 तपशील (नवीन टॅबमध्ये उघडते)

व्हेंडर लॉक-इन टाळणे: वरील गोष्टींच्या अनुषंगाने, एक चांगली अंमलबजावणी व्हेंडर-तटस्थ आणि आंतरकार्यक्षम असते. याचा अर्थ अनेकदा स्मार्ट खात्यांसाठी उदयोन्मुख मानकांचे पालन करणे असा होतो. उदाहरणार्थ, Alchemy चे मॉड्यूलर खाते (नवीन टॅबमध्ये उघडते) मॉड्यूलर स्मार्ट खात्यांसाठी ERC-6900 मानकाचा वापर करते आणि "परवानगीमुक्त आंतरकार्यक्षम वापर" लक्षात घेऊन डिझाइन केलेले आहे.

गोपनीयता जतन करणे: ऑनचेन गोपनीयता मर्यादित असली तरी, अधिकारप्रदान कॉन्ट्रॅक्टने डेटा एक्सपोजर आणि लिंकॅबिलिटी कमी करण्याचा प्रयत्न केला पाहिजे. हे 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 (नवीन टॅबमध्ये उघडते) हे EIP-7702-सुसंगत खात्यांमध्ये अधिकारप्रदान सुरक्षितपणे इनिशिएलाइज आणि व्यवस्थापित करण्यासाठी प्रॉक्सीचा कसा वापर केला जाऊ शकतो हे दर्शविते.

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

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

सुरक्षा विचार

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

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

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

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

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

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

इनिशिएलायझेशन असुरक्षा कमी करण्यासाठी उपाय

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

• ERC-4337 च्या EntryPoint चा वापर करा
  इनिशिएलायझेशन फंक्शन केवळ ERC-4337 EntryPoint कॉन्ट्रॅक्टमधूनच कॉल करणे आवश्यक करा. ही पद्धत ERC-4337 द्वारे प्रदान केलेल्या प्रमाणित प्रमाणीकरण आणि अंमलबजावणी फ्रेमवर्कचा लाभ घेते, इनिशिएलायझेशन प्रक्रियेत सुरक्षिततेचा अतिरिक्त स्तर जोडते.
  (पहा: Safe दस्तऐवज (नवीन टॅबमध्ये उघडते))

या उपायांचा अवलंब करून, डेव्हलपर्स EIP-7702 अधिकारप्रदान कॉन्ट्रॅक्ट्सची सुरक्षा वाढवू शकतात, इनिशिएलायझेशन टप्प्यात संभाव्य फ्रंटरनिंग हल्ल्यांपासून संरक्षण करू शकतात.

स्टोरेज कोलिजन्स कोडचे अधिकारप्रदान केल्याने विद्यमान स्टोरेज साफ होत नाही. एका अधिकारप्रदान कॉन्ट्रॅक्टमधून दुसऱ्यामध्ये स्थलांतरित होताना, मागील कॉन्ट्रॅक्टमधील उर्वरित डेटा तसाच राहतो. जर नवीन कॉन्ट्रॅक्ट समान स्टोरेज स्लॉट्स वापरत असेल परंतु त्यांचा वेगळ्या प्रकारे अर्थ लावत असेल, तर यामुळे अनपेक्षित वर्तन होऊ शकते. उदाहरणार्थ, जर सुरुवातीचे अधिकारप्रदान अशा कॉन्ट्रॅक्टला केले असेल जिथे स्टोरेज स्लॉट bool दर्शवतो, आणि त्यानंतरचे अधिकारप्रदान अशा कॉन्ट्रॅक्टला केले असेल जिथे तोच स्लॉट uint दर्शवतो, तर या विसंगतीमुळे अप्रत्याशित परिणाम होऊ शकतात.

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

जेव्हा वापरकर्ते अधिकारप्रदान केलेल्या स्वाक्षऱ्या करतात, तेव्हा फिशिंगचे धोके कमी करण्यात मदत करण्यासाठी अधिकारप्रदान प्राप्त करणारे लक्ष्य कॉन्ट्रॅक्ट स्पष्टपणे आणि ठळकपणे प्रदर्शित केले जावे.

किमान विश्वसनीय पृष्ठभाग आणि सुरक्षा: लवचिकता प्रदान करताना, अधिकारप्रदान कॉन्ट्रॅक्टने त्याचे मुख्य लॉजिक किमान आणि ऑडिट करण्यायोग्य ठेवले पाहिजे. कॉन्ट्रॅक्ट प्रभावीपणे वापरकर्त्याच्या EOA चा विस्तार आहे, त्यामुळे कोणतीही त्रुटी विनाशकारी असू शकते. अंमलबजावणीने स्मार्ट कॉन्ट्रॅक्ट सुरक्षा समुदायाच्या सर्वोत्तम पद्धतींचे पालन केले पाहिजे. उदाहरणार्थ, कन्स्ट्रक्टर किंवा इनिशिएलायझर फंक्शन्स काळजीपूर्वक सुरक्षित करणे आवश्यक आहे – जसे Alchemy ने हायलाइट केले आहे, जर 7702 अंतर्गत प्रॉक्सी पॅटर्न वापरत असाल, तर असुरक्षित इनिशिएलायझर हल्लेखोराला खात्यावर ताबा मिळवू देऊ शकतो. टीम्सनी ऑनचेन कोड सोपा ठेवण्याचे उद्दिष्ट ठेवले पाहिजे: Ambire चे 7702 कॉन्ट्रॅक्ट केवळ ~200 ओळींचे Solidity आहे, जे बग्स कमी करण्यासाठी जाणीवपूर्वक गुंतागुंत कमी करते. वैशिष्ट्यपूर्ण लॉजिक आणि ऑडिटिंग सुलभ करणारी साधेपणा यांच्यात समतोल साधला पाहिजे.

ज्ञात अंमलबजावणी

EIP-7702 च्या स्वरूपामुळे, वापरकर्त्यांना तृतीय पक्ष कॉन्ट्रॅक्टला अधिकारप्रदान करण्यात मदत करताना वॉलेट्सनी सावधगिरी बाळगण्याची शिफारस केली जाते. खाली ऑडिट केलेल्या ज्ञात अंमलबजावणींचा संग्रह सूचीबद्ध केला आहे:

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

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

सहचर ॲप्ससाठी (companion apps) एकत्रीकरण परिस्थिती

लेझी (Lazy)

EOA अद्याप नेहमीप्रमाणे कार्य करत असल्याने, करण्यासारखे काहीही नाही.

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

जागरूक (Aware)

EOA चा कोड तपासून त्याच्यासाठी अधिकारप्रदान लागू असल्याचे वापरकर्त्याला सूचित करा आणि वैकल्पिकरित्या अधिकारप्रदान काढून टाकण्याची ऑफर द्या.

सामान्य अधिकारप्रदान

हार्डवेअर प्रदाता ज्ञात अधिकारप्रदान कॉन्ट्रॅक्ट्सना व्हाइटलिस्ट करतो आणि सॉफ्टवेअर सहचरमध्ये त्यांच्या समर्थनाची अंमलबजावणी करतो. पूर्ण ERC-4337 समर्थन असलेले कॉन्ट्रॅक्ट निवडण्याची शिफारस केली जाते.

वेगळ्या कॉन्ट्रॅक्टला अधिकारप्रदान केलेली बाह्य मालकीची खाती (EOAs) मानक EOAs म्हणून हाताळली जातील.

सानुकूल अधिकारप्रदान

हार्डवेअर प्रदाता स्वतःच्या अधिकारप्रदान कॉन्ट्रॅक्टची अंमलबजावणी करतो आणि ते सूचीमध्ये जोडतो, तसेच सॉफ्टवेअर सहचरमध्ये त्याच्या समर्थनाची अंमलबजावणी करतो. पूर्ण ERC-4337 समर्थन असलेले कॉन्ट्रॅक्ट तयार करण्याची शिफारस केली जाते.

वेगळ्या कॉन्ट्रॅक्टला अधिकारप्रदान केलेली बाह्य मालकीची खाती (EOAs) मानक EOAs म्हणून हाताळली जातील.