EIP-8141: क्यों ईथेरियम के हेगोटा अपग्रेड में नेटिव अकाउंट एब्स्ट्रैक्शन एक हेडलाइन फीचर नहीं है

लेखक: imToken

पिछले हफ्ते, ईथरियम कोर डेवलपर्स मीटिंग में EIP-8141 को Hegota अपग्रेड में शामिल करने की आधिकारिक चर्चा की गई, और परिणाम अप्रत्याशित रहा—विटालिक द्वारा सीधे समर्थित इस प्रस्ताव को Hegota का "मुख्य फीचर" नहीं, बल्कि "विचार के लिए" (CFI) स्थिति प्राप्त हुई।

और इस सप्ताह, Google क्वांटम AI टीम ने एक नवीनतम शोध पत्र जारी किया, जिसमें उन्होंने अपने दिए गए हार्डवेयर अनुमानों के तहत, ECDLP-256 को तोड़ने के लिए आवश्यक भौतिक क्वांटम बिट्स का अनुमान पहले की तुलना में 20 गुना कम बताया है। हालाँकि, इसका मतलब यह नहीं है कि क्वांटम हमला आसपास है, लेकिन यह हमें वास्तविक रूप से सचेत करता है कि यदि भविष्य में खाता प्रणाली लचीले ढंग से प्रमाणीकरण तर्क को बदलने में सक्षम नहीं होगी, तो आज कई वॉलेट अनुभव पर चर्चाएँ अंततः सुरक्षा समस्याओं में बदल सकती हैं।

हालांकि, प्रोटोकॉल अग्रगामी के वास्तविक पहलू के आधार पर, EIP-8141 अभी भी बहुत भारी है, विशेष रूप से क्लाइंट लागूकरण, ट्रांजेक्शन पूल सुरक्षा और प्रमाणीकरण जटिलता पर, जिस पर पर्याप्त मजबूत सहमति अभी नहीं बनी है।

लेकिन वर्तमान समय बिंदु पर, EIP-8141 के बारे में चर्चा करने और गंभीरता से जांचने के लिए ऐसे मुद्दे लगते हैं जो लगातार बढ़ रहे हैं।

EIP-8141 को Vitalik Buterin और timbeiko जैसे मुख्य योगदानकर्ताओं द्वारा आगे बढ़ाया गया है, जिसका औपचारिक नाम Frame Transactions (फ्रेम ट्रांजेक्शन) है।

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

इसका अर्थ यह भी है कि मल्टी-सिग्नेचर, गैस स्पॉन्सरशिप, की रोटेशन, सोशल रिकवरी, और भविष्य में क्वांटम-प्रतिरोधी सिग्नेचर समाधानों का समावेश, अब केवल वॉलेट के बाहर एक अतिरिक्त सुविधा नहीं रहा, बल्कि इथेरियम अकाउंट सिस्टम के 'मूल सदस्य' बनने का अवसर प्राप्त होगा।

अगर सतही रूप से देखा जाए, तो EIP-8141 एक बहुत ही विशिष्ट क्षमताओं की चर्चा करता है: स्थिर मुद्रा के माध्यम से गैस का भुगतान, कई चरणों वाले कार्यों को एक ही लेनदेन में संयोजित करना, अधिक लचीले हस्ताक्षर तरीकों का समर्थन, और भविष्य के क्वांटम-प्रतिरोधी हस्ताक्षरों के लिए स्थान छोड़ना। कहा जा सकता है कि ERC-4337 से लेकर EIP-7702 तक, वॉलेट अनुभव के चारों ओर कई सुधारों का मूल उद्देश्य यह रहा है कि खाता केवल एक निजी कुंजी न होकर, एक कस्टमाइज़ेबल नियमों वाला प्रवेश बिंदु बन जाए।

समस्या यह है कि ये सुधार वास्तव में वॉलेट को बहुत अधिक स्मार्ट अकाउंट की तरह बना रहे हैं, लेकिन एथेरियम के सबसे निचले स्तर के डिफ़ॉल्ट अकाउंट मॉडल को वास्तव में स्पर्श नहीं किया गया है।

ज्ञात है कि वर्तमान प्रणाली में, ईथरियम खाते मुख्य रूप से दो प्रकार के होते हैं। एक बाह्य स्वामित्व खाता है, जिसे लोग सबसे अधिक परिचित EOA के रूप में जानते हैं, जिसे निजी कुंजी द्वारा नियंत्रित किया जाता है और यह सक्रिय रूप से लेन-देन शुरू कर सकता है, लेकिन इसमें प्रोग्रामेबलता की क्षमता नहीं होती है; दूसरा कॉन्ट्रैक्ट खाता है, जो स्मार्ट कॉन्ट्रैक्ट स्वयं है, जो जटिल तर्क को निष्पादित कर सकता है, लेकिन स्वयं सक्रिय रूप से लेन-देन शुरू नहीं कर सकता।

इससे लेनदेन शुरू करने की क्षमता एकल निजी कुंजी हस्ताक्षर से लंबे समय तक जुड़ी रहती है; जब तक यह पूर्वधारणा अपरिवर्तित रहती है, बहुत से उपयोगकर्ताओं को आज जो क्षमताएँ स्वाभाविक लगती हैं—जैसे हस्ताक्षर नियमों को लचीलापन से बदलना, किसी और को गैस भुगतान करने की अनुमति देना, निजी कुंजी खोने के बाद खाते के नियंत्रण को पुनः प्राप्त करना, या भविष्य में नए क्रिप्टोग्राफिक प्रणाली में आसानी से स्थानांतरित होना—वे सभी खाते की डिफ़ॉल्ट क्षमताएँ बनने में कठिनाई का सामना करती हैं।

अगर आपने imToken या कोई अन्य Web3 वॉलेट इस्तेमाल किया है, तो आपने शायद इन समस्याओं का सामना किया होगा, जैसे कि आपके वॉलेट में कई USDC हैं, लेकिन ETH नहीं है, इसलिए आप ट्रांजैक्शन नहीं भेज सकते (क्योंकि Gas केवल ETH से भुगतान किया जा सकता है); अगर आपका मैनेमोनिक फ्रेज खो गया, तो आपका पैसा हमेशा के लिए खो गया, और इसे वापस नहीं किया जा सकता; एक «अधिकार + विनिमय» ऑपरेशन के लिए दो बार साइन करना पड़ता है, दो बार पुष्टि करनी पड़ती है, आदि।

ये समस्याएँ पॉर्टफोलियो उत्पाद के "अपर्याप्त अच्छे" होने के कारण नहीं हैं, बल्कि ईथरियम खाता मॉडल के मूल डिज़ाइन के परिणाम हैं।

इस दृष्टिकोण से, पिछले दो वर्षों का विकास वास्तव में बहुत स्पष्ट हो चुका है; ERC-4337 ने प्रोटोकॉल में कोई परिवर्तन किए बिना, खाता अमूर्तीकरण को पहले एप्लिकेशन स्तर पर लागू किया; EIP-7702 ने आगे साबित किया कि EOA पूरी तरह से विस्तारयोग्य नहीं हैं, कम से कम अस्थायी रूप से स्मार्ट खाते के कुछ समान क्षमताएँ प्राप्त की जा सकती हैं।

इसका मतलब है कि ईथरियम खाता अमूर्तीकरण करना नहीं चाहता, बल्कि यह लगातार अधिक सुसंगठित और सावधानी से इस बात की ओर धीरे-धीरे बढ़ रहा है। EIP-8141 के आने से इस मार्ग का एक नया मोड़ आया है। यह केवल मौजूदा प्रणाली के बाहर एक बुद्धिमान खाता क्षमता को ओवरले करने से संतुष्ट नहीं है, बल्कि यह खाता अमूर्तीकरण को सीधे लेन-देन मॉडल में एम्बेड करने का प्रयास करता है, ताकि खाते प्रोटोकॉल स्तर से ही प्रोग्रामेबल प्रमाणीकरण और निष्पादन तर्क के साथ आएं।

इसीलिए आज EIP-8141 फिर से चर्चा में आया है। एक ओर, उच्च स्तरीय वॉलेट अनुभव पहले से ही मूल खाता अमूर्तीकरण के करीब पहुँच गया है, और प्रोटोकॉल स्तर को जल्द ही इसके साथ समायोजित होना होगा; दूसरी ओर, क्वांटम कंप्यूटिंग के कारण लंबे समय तक का दबाव, 'खाते की साइनेचर विधि को लचीलापन से बदला जा सकता है' यह दूर की तकनीकी बात को, एक ऐसी वास्तविक समस्या में बदल रहा है, जिसे अब गंभीरता से विचार किया जाना चाहिए।

अंततः, EIP-8141 एक नया लेनदेन प्रकार — फ्रेम लेनदेन (Frame Transaction), जिसका लेनदेन प्रकार संख्या 0x06 है, पेश करता है।

यदि पारंपरिक ईथरियम लेनदेन की मूल तर्क यह है कि एक लेनदेन एक ही कॉल के बराबर होता है, तो EIP-8141 का उद्देश्य एक लेनदेन को नियमों के अनुसार क्रमबद्ध तरीके से निष्पादित किए जा सकने वाले «फ्रेम» के समूह में विभाजित करना है, जिससे मूल रूप से बंडल किए गए सत्यापन, भुगतान और निष्पादन को अलग-अलग संसाधित किया जा सके।

प्रत्येक «फ्रेम» के तीन निष्पादन मोड होते हैं:

• VERIFY (प्रमाणीकरण फ्रेम): यह लेनदेन की वैधता की जांच करता है, यह खाते के अनुकूलित प्रमाणीकरण तर्क को चलाता है, यदि सफल होता है, तो यह नवीनतम जोड़े गए APPROVE ऑपकोड को कॉल करके निष्पादन को अनुमति देता है और गैस सीमा निर्दिष्ट करता है।
• SENDER (फ्रेम भेजना): ट्रांसफर, कॉन्ट्रैक्ट कॉल आदि जैसे वास्तविक कार्रवाइयों को निष्पादित करता है। कॉलर पता वास्तविक ट्रांजेक्शन भेजने वाला होता है।
• DEFAULT (इनपुट फ्रेम): कॉन्ट्रैक्ट डिप्लॉय करने, Paymaster की पुष्टि करने आदि परिदृश्यों के लिए सिस्टम इनपुट पते को कॉलर के रूप में उपयोग करें;

इस तंत्र का अर्थ यह नहीं है कि लेनदेन अधिक जटिल हो जाएं, बल्कि पहली बार 'प्रमाणीकरण, भुगतान, निष्पादन' तीनों कार्यों को खाता क्रियाओं से अलग किया गया है और इन्हें प्रोटोकॉल के मूल स्केड्यूलर द्वारा संभाला गया है।

पिछले समय में, ट्रांजैक्शन की पुष्टि कौन करता है, गैस का भुगतान कौन करता है, और वास्तविक ऑपरेशन कौन निष्पादित करता है, ये सभी आमतौर पर एक ही खाते की क्रिया में बंधे होते थे, लेकिन EIP-8141 के डिज़ाइन के तहत, ये तीनों कार्य अलग-अलग फ्रेम में विभाजित किए जा सकते हैं, जिन्हें प्रोटोकॉल द्वारा स्पष्ट क्रम में क्रमिक रूप से निष्पादित किया जाता है, और इसी कारण, खाते अब केवल एकल निजी कुंजी पर निर्भर नहीं रहते हैं जो "समग्र हस्ताक्षर" करती है, बल्कि वे अब अधिक प्रोग्रामेबल निष्पादन इकाई के समान आकार धारण करने लगे हैं।

एक विशिष्ट उदाहरण के रूप में, मान लीजिए कि आप EIP-8141 के ढांचे के तहत एक Swap पूरा करने के लिए USDC का उपयोग Gas के रूप में करना चाहते हैं; इसे एक पूर्ण फ्रेम प्रक्रिया के रूप में संगठित किया जा सकता है: पहले खाता साइनेचर और निष्पादन अधिकार की पुष्टि करता है, फिर भुगतानकर्ता या Paymaster अपने द्वारा शुल्क वहन करने की शर्तों की पुष्टि करता है, इसके बाद संबंधित संपत्ति के लिए शुल्क का भुगतान किया जाता है, और अंत में वास्तविक Swap ऑपरेशन निष्पादित किया जाता है।

इस तरह, गैस भुगतान और मुख्य लेनदेन को एक ही परमाणु प्रक्रिया में शामिल किया जा सकता है, जिसमें या तो सब कुछ सफल होता है या सब कुछ रद्द हो जाता है।

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

यह वॉलेट उपयोगकर्ताओं के लिए क्या अर्थ रखता है? परिणाम के अनुसार, सबसे सीधा परिवर्तन कम से कम चार स्तरों में है:

• गैस भुगतान को अमूर्त कर दिया गया है: एक वॉलेट में स्थिर मुद्रा होना अब इस बात का अर्थ नहीं है कि आपको अतिरिक्त ETH भी तैयार रखना होगा ताकि आप कार्रवाई कर सकें; भविष्य में, dapp, पेमास्टर या अन्य प्रायोजक द्वारा गैस का भुगतान किया जाएगा, जो अधिक मूल बन जाएगा;
• एक से अधिक चरणों को एकीकृत किया गया है: जैसे 'अधिकृत करें + स्वैप' या 'अधिकृत करें + स्टेकिंग' जैसी प्रक्रियाएँ, जिनमें अक्सर कई बार हस्ताक्षर की आवश्यकता होती है, अब एक अधिक समग्र ऑपरेशन के रूप में पैक किए जाने का अवसर है;
• अकाउंट सुरक्षा नियम सक्षम हैं: मल्टी-सिग्नेचर, सोशल रिकवरी, दैनिक सीमा, टाइम लॉक, और की रोटेशन—ये अब केवल किसी वॉलेट उत्पाद की अतिरिक्त उन्नत सुविधाएँ नहीं हैं, बल्कि अधिक मूल अकाउंट लॉजिक पर बनाए जाने का अवसर शुरू हो रहा है;
• साइनेचर स्कीम अब ECDSA एकल पथ पर बंद नहीं है: इससे खातों के भविष्य में विभिन्न क्रिप्टोग्राफिक सिस्टम, जिसमें पोस्ट-क्वांटम साइनेचर स्कीम शामिल हैं, में स्थानांतरण की पहली बार प्रोटोकॉल स्तर पर संभावना प्राप्त होती है;

एक ऐसा बिंदु जिसे अक्सर नजरअंदाज किया जाता है, लेकिन वॉलेट उपयोगकर्ताओं के लिए बहुत महत्वपूर्ण है: भले ही EIP-8141 अंततः लागू हो जाए, मौजूदा खाता प्रणाली को इसके कारण पूरी तरह से बदला नहीं जाएगा।

यदि आप अभी imToken जैसे मौजूदा Web3 वॉलेट का उपयोग कर रहे हैं, तो आपको स्थानांतरित करने की आवश्यकता नहीं है, क्योंकि यह पिछले संस्करणों के साथ संगत है, और मौजूदा EOA पते जारी रखे जा सकते हैं, बस उचित समय पर अपने खाते की प्रमाणीकरण तर्क को "अपग्रेड" करें।

लेकिन इसके विपरीत, यही कारण है कि इसे नवीनतम चर्चा में सीधे हेगोटा की प्रमुख सुविधा नहीं बनाया गया। हालाँकि, 2026 के EIP चैम्पियन प्रक्रिया के अनुसार, CFI (Considered for Inclusion) का अर्थ अस्वीकृति नहीं है, बल्कि इसे गंभीरता से विचार किया जा रहा है, लेकिन अभी इसे अंतिम रूप से लागू करने का समय नहीं आया है।

दूसरे शब्दों में, कोर डेवलपर्स EIP-8141 की दिशा को अस्वीकार नहीं कर रहे हैं, बल्कि इसके मूल्य को स्वीकार करते हुए भी मानते हैं कि यह अभी भी बहुत 'भारी' है।

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

अब क्या होगा? इसे दो लाइनों में विभाजित किया जा सकता है:

• चूंकि EIP-8141 CFI स्थिति में है, इसलिए इसका मूल्यांकन अभी भी जारी है; प्रस्तावक लेनदेन पूल सुरक्षा, प्रमाणीकरण नियमों और क्लाइंट कार्यान्वयन के चारों ओर महत्वपूर्ण विवरणों को पूरा करते रहेंगे, और भविष्य की ACD मीटिंग में इसे आगे बढ़ाने की योग्यता की पुनः समीक्षा की जाएगी;
• यदि इन अनिश्चितताओं को लगातार संकुचित किया जा सकता है, तो इसके बाद के अपग्रेड में इसे अधिक वास्तविक शामिल करने का अवसर मिल सकता है; यदि नहीं, तो इसे बाद के अपग्रेड चक्र में स्थगित किया जा सकता है;

सच्चाई कहें तो, EIP-8141 एकमात्र मूल खाता अमूर्तीकरण प्रस्ताव नहीं है, और यह स्वयं कोई तैयार पोस्ट-क्वांटम हस्ताक्षर योजना भी नहीं है, जो क्वांटम कंप्यूटिंग की समस्या को सीधे हल कर सके, लेकिन इसका महत्व यह है कि यह पहली बार खातों को ECDSA के एकल मार्ग से मुक्त करने के लिए प्रोटोकॉल स्तर पर एक निकास प्रदान करता है।

इस दृष्टिकोण से, EIP-8141 का वास्तविक मूल्य इस बात में नहीं है कि क्या यह एकमात्र सही उत्तर है, बल्कि इस बात में है कि यह पहली बार 'मूल खाता अमूर्तीकरण का अंतिम रूप क्या होना चाहिए' इस प्रश्न को बहुत पूर्णता से ईथरियम प्रोटोकॉल चर्चा की मेज पर रखता है।

यह एकमात्र समाधान नहीं है, लेकिन यह वर्तमान में सबसे अधिक दावेदार और 'पूर्ण मूल AA' की कल्पना की सीमा के सबसे करीबी समाधानों में से एक है।

चाहे EIP-8141 अंततः Hegotá के साथ समाप्त हो पाए या नहीं, यह चर्चा कम से कम एक बात साबित कर चुकी है:

ईथरियम ने समस्याओं के बढ़ने का इंतजार नहीं किया, बल्कि अगली पीढ़ी के खाता प्रणाली के लिए धीरे-धीरे रास्ता तैयार किया है।