पेक्ट्रा 7702

सार

EIP-7702 एक EOA में कोड जोड़ने के लिए एक तंत्र को परिभाषित करता है। यह प्रस्ताव EOAs, जो कि पुराने इथेरियम खाते हैं, को अल्पकालिक कार्यक्षमता सुधार प्राप्त करने की अनुमति देता है, जिससे एप्लिकेशनों की उपयोगिता बढ़ती है। यह एक नए लेन-देन प्रकार: 4 का उपयोग करके पहले से तैनात (deployed) कोड के लिए एक पॉइंटर सेट करके किया जाता है।

यह नया लेन-देन प्रकार एक प्राधिकरण सूची (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 address) पर प्रत्यायोजित करके प्रत्यायोजन को रीसेट किया जा सकता है।

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

सर्वोत्तम प्रथाएँ

खाता अमूर्तन: अनुकूलता को अधिकतम करने के लिए एक प्रत्यायोजन अनुबंध को इथेरियम के व्यापक खाता अमूर्तन (AA) मानकों के साथ संरेखित होना चाहिए। विशेष रूप से, इसे आदर्श रूप से ERC-4337 के अनुरूप या संगत होना चाहिए।

अनुमति-रहित और सेंसरशिप-प्रतिरोधी डिज़ाइन: इथेरियम अनुमति-रहित भागीदारी को महत्व देता है। एक प्रत्यायोजन अनुबंध को किसी एक "विश्वसनीय" रिलेयर या सेवा को हार्ड-कोड या उस पर निर्भर नहीं होना चाहिए। यदि रिलेयर ऑफ़लाइन हो जाता है तो यह खाते को बेकार (brick) कर देगा। बैचिंग (जैसे, approve+transferFrom) जैसी सुविधाओं का उपयोग EOA द्वारा स्वयं बिना किसी रिलेयर के किया जा सकता है। एप्लिकेशन डेवलपर्स जो 7702 (गैस एब्स्ट्रैक्शन, गोपनीयता-संरक्षण निकासी) द्वारा सक्षम उन्नत सुविधाओं का उपयोग करना चाहते हैं, उन्हें एक रिलेयर की आवश्यकता होगी। हालांकि विभिन्न रिलेयर आर्किटेक्चर हैं, हमारी सिफारिश 4337 बंडलर (opens in a new tab) का उपयोग करने की है जो कम से कम एंट्री पॉइंट 0.8 (opens in a new tab) को इंगित करते हैं क्योंकि:

• वे रिलेइंग के लिए मानकीकृत इंटरफेस प्रदान करते हैं
• इनमें अंतर्निहित पेमास्टर सिस्टम शामिल हैं
• भविष्य की अनुकूलता (forward compatibility) सुनिश्चित करते हैं
• एक सार्वजनिक मेमपूल (opens in a new tab) के माध्यम से सेंसरशिप प्रतिरोध का समर्थन कर सकते हैं
• यह आवश्यकता हो सकती है कि init फ़ंक्शन को केवल EntryPoint (opens in a new tab) से ही कॉल किया जाए

दूसरे शब्दों में, कोई भी लेन-देन प्रायोजक/रिलेयर के रूप में कार्य करने में सक्षम होना चाहिए जब तक कि वे खाते से आवश्यक वैध हस्ताक्षर या उपयोगकर्ता संचालन (UserOperation) प्रदान करते हैं। यह सेंसरशिप प्रतिरोध सुनिश्चित करता है: यदि किसी कस्टम बुनियादी ढांचे की आवश्यकता नहीं है, तो उपयोगकर्ता के लेन-देन को गेटकीपिंग रिले द्वारा मनमाने ढंग से अवरुद्ध नहीं किया जा सकता है। उदाहरण के लिए, मेटामास्क का प्रत्यायोजन टूलकिट (opens in a new tab) स्पष्ट रूप से किसी भी चेन पर किसी भी ERC-4337 बंडलर या पेमास्टर के साथ काम करता है, न कि मेटामास्क-विशिष्ट सर्वर की आवश्यकता होती है।

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

यह देखते हुए कि वॉलेट EIP-7702 के लिए विशिष्ट प्रत्यायोजन अनुबंधों को श्वेतसूची (whitelist) में डालेंगे, dapps को सीधे 7702 प्राधिकरणों का अनुरोध करने की उम्मीद नहीं करनी चाहिए। इसके बजाय, एकीकरण मानकीकृत वॉलेट इंटरफेस के माध्यम से होना चाहिए:

• ERC-5792 (wallet_sendCalls): dapps को वॉलेट से बैच किए गए कॉल निष्पादित करने का अनुरोध करने में सक्षम बनाता है, जिससे लेन-देन बैचिंग और गैस एब्स्ट्रैक्शन जैसी कार्यक्षमताएं सुविधाजनक होती हैं।

• ERC-6900: dapps को वॉलेट-प्रबंधित मॉड्यूल के माध्यम से मॉड्यूलर स्मार्ट खाता क्षमताओं, जैसे कि सत्र कुंजी (session keys) और खाता पुनर्प्राप्ति (account recovery) का लाभ उठाने की अनुमति देता है।

इन इंटरफेस का उपयोग करके, 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 मानक का उपयोग करता है और इसे "अनुमति-रहित अंतरप्रचालनीय उपयोग" को ध्यान में रखकर डिज़ाइन किया गया है।

गोपनीयता संरक्षण: हालांकि ऑनचेन गोपनीयता सीमित है, एक प्रत्यायोजन अनुबंध को डेटा एक्सपोज़र और लिंकेबिलिटी को कम करने का प्रयास करना चाहिए। इसे 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 को संदर्भित करता है। इसी तरह, पुन:प्रवेश हमलों के खिलाफ सुरक्षा उपाय के रूप में msg.sender == tx.origin का उपयोग करना अब एक विश्वसनीय रणनीति नहीं है।

आगे बढ़ते हुए, डेवलपर्स को इस धारणा के साथ डिज़ाइन करना चाहिए कि सिस्टम में कोई भी भागीदार एक स्मार्ट अनुबंध हो सकता है। वैकल्पिक रूप से वे nonReentrant संशोधक (modifier) पैटर्न के साथ पुनःप्रवेश रक्षक का उपयोग करके स्पष्ट पुन:प्रवेश सुरक्षा लागू कर सकते हैं। हम एक ऑडिट किए गए संशोधक का पालन करने की सलाह देते हैं, उदाहरण के लिए 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 Docs (opens in a new tab))

इन समाधानों को अपनाकर, डेवलपर्स EIP-7702 प्रत्यायोजन अनुबंधों की सुरक्षा बढ़ा सकते हैं, जिससे इनिशियलाइज़ेशन चरण के दौरान संभावित फ्रंटरनिंग हमलों से बचाव हो सकता है।

स्टोरेज टकराव (Storage Collisions) कोड प्रत्यायोजित करने से मौजूदा स्टोरेज साफ़ नहीं होता है। एक प्रत्यायोजन अनुबंध से दूसरे में माइग्रेट करते समय, पिछले अनुबंध का अवशिष्ट डेटा बना रहता है। यदि नया अनुबंध समान स्टोरेज स्लॉटों का उपयोग करता है लेकिन उनकी अलग तरह से व्याख्या करता है, तो यह अनपेक्षित व्यवहार का कारण बन सकता है। उदाहरण के लिए, यदि प्रारंभिक प्रत्यायोजन एक ऐसे अनुबंध के लिए था जहां एक स्टोरेज स्लॉट bool का प्रतिनिधित्व करता है, और बाद का प्रत्यायोजन एक ऐसे अनुबंध के लिए है जहां वही स्लॉट uint का प्रतिनिधित्व करता है, तो बेमेल अप्रत्याशित परिणामों को जन्म दे सकता है।

फ़िशिंग जोखिम EIP-7702 प्रत्यायोजन के कार्यान्वयन के साथ, उपयोगकर्ता के खाते में संपत्ति पूरी तरह से स्मार्ट अनुबंधों द्वारा नियंत्रित की जा सकती है। यदि कोई उपयोगकर्ता अनजाने में अपने खाते को किसी दुर्भावनापूर्ण अनुबंध को प्रत्यायोजित करता है, तो हमलावर आसानी से नियंत्रण प्राप्त कर सकता है और धन चुरा सकता है। chain_id=0 का उपयोग करते समय प्रत्यायोजन सभी चेन आईडी पर लागू होता है। केवल एक अपरिवर्तनीय अनुबंध को प्रत्यायोजित करें (कभी भी प्रॉक्सी को प्रत्यायोजित न करें), और केवल उन अनुबंधों को जिन्हें CREATE2 (मानक initcode के साथ - कोई मेटामॉर्फिक अनुबंध नहीं) का उपयोग करके तैनात किया गया था ताकि परिनियोजक (deployer) कहीं और उसी पते पर कुछ अलग तैनात न कर सके। अन्यथा आपका प्रत्यायोजन आपके खाते को अन्य सभी EVM चेनों पर जोखिम में डालता है।

जब उपयोगकर्ता प्रत्यायोजित हस्ताक्षर करते हैं, तो फ़िशिंग जोखिमों को कम करने में मदद के लिए प्रत्यायोजन प्राप्त करने वाले लक्ष्य अनुबंध को स्पष्ट और प्रमुखता से प्रदर्शित किया जाना चाहिए।

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

ज्ञात कार्यान्वयन

EIP 7702 की प्रकृति के कारण, यह अनुशंसा की जाती है कि उपयोगकर्ताओं को किसी तीसरे पक्ष के अनुबंध को प्रत्यायोजित करने में मदद करते समय वॉलेट सावधानी बरतें। नीचे ज्ञात कार्यान्वयनों का एक संग्रह सूचीबद्ध है जिनका ऑडिट किया गया है:

हार्डवेयर वॉलेट दिशानिर्देश

हार्डवेयर वॉलेट को मनमाने प्रत्यायोजन को उजागर नहीं करना चाहिए। हार्डवेयर वॉलेट स्पेस में सर्वसम्मति विश्वसनीय डेलिगेटर अनुबंधों की सूची का उपयोग करने की है। हम ऊपर सूचीबद्ध ज्ञात कार्यान्वयनों को अनुमति देने और मामले-दर-मामले के आधार पर दूसरों पर विचार करने का सुझाव देते हैं। चूंकि आपके EOA को किसी अनुबंध को प्रत्यायोजित करने से सभी संपत्तियों पर नियंत्रण मिल जाता है, इसलिए हार्डवेयर वॉलेट को 7702 को लागू करने के तरीके के बारे में सतर्क रहना चाहिए।

सहयोगी ऐप्स (companion apps) के लिए एकीकरण परिदृश्य

लेज़ी (Lazy)

चूंकि EOA अभी भी हमेशा की तरह काम करता है, इसलिए करने के लिए कुछ नहीं है।

नोट: कुछ संपत्तियों को प्रत्यायोजन कोड द्वारा स्वचालित रूप से अस्वीकार किया जा सकता है, जैसे कि ERC-1155 NFTs, और सपोर्ट को इसके बारे में पता होना चाहिए।

जागरूक (Aware)

उपयोगकर्ता को सूचित करें कि इसके कोड की जांच करके EOA के लिए एक प्रत्यायोजन मौजूद है, और वैकल्पिक रूप से प्रत्यायोजन को हटाने की पेशकश करें।

सामान्य प्रत्यायोजन

हार्डवेयर प्रदाता ज्ञात प्रत्यायोजन अनुबंधों को श्वेतसूची में डालता है और सॉफ़्टवेयर सहयोगी में उनके समर्थन को लागू करता है। पूर्ण ERC-4337 समर्थन वाले अनुबंध को चुनने की अनुशंसा की जाती है।

किसी भिन्न को प्रत्यायोजित EOAs को मानक EOAs के रूप में नियंत्रित किया जाएगा।

कस्टम प्रत्यायोजन

हार्डवेयर प्रदाता अपना स्वयं का प्रत्यायोजन अनुबंध लागू करता है और इसे सूचियों में जोड़ता है, सॉफ़्टवेयर सहयोगी में इसके समर्थन को लागू करता है। पूर्ण ERC-4337 समर्थन के साथ एक अनुबंध बनाने की अनुशंसा की जाती है।

किसी भिन्न को प्रत्यायोजित EOAs को मानक EOAs के रूप में नियंत्रित किया जाएगा।