Vitalik Buterin अब Ethereum स्केलिंग पर चर्चा को Layer 2 (L2) से हटाकर प्रोटोकॉल के कोर की ओर मोड़ रहे हैं।
Russo-Canadian इनोवेटर का मानना है कि Ethereum की सबसे बड़ी लॉन्ग-टर्म सीमाएं रोलअप्स या ब्लॉब कैपेसिटी नहीं, बल्कि नेटवर्क के स्टेट ट्री और वर्चुअल मशीन के अंदर की गहरी आर्किटेक्चरल दिक्कतें हैं।
Vitalik Buterin ने Ethereum के लिए बड़ा बदलाव सुझाया, State Tree और Virtual Machine की दिक्कतें होंगी दूर
Buterin के मुताबिक, नेटवर्क के दो कंपोनेंट्स — स्टेट ट्री और वर्चुअल मशीन — 80% से ज्यादा प्रूविंग लागत के लिए जिम्मेदार हैं। वे कहते हैं कि यह एक महत्वपूर्ण मुद्दा है क्योंकि Zero-Knowledge (ZK) टेक्नोलॉजी अब Ethereum के रोडमैप में सेंट्रल बन चुकी है।
“आज मैं दो बड़ी चीजों पर फोकस करूंगा: स्टेट ट्री बदलाव, और VM बदलाव,” Buterin ने लिखा, और जोड़ा कि दोनों ही “वो बड़ी बाधाएं हैं जिन्हें हमें एड्रेस करना है अगर हम एफिशिएंट प्रूविंग चाहते हैं।”
Binary Tree में बड़ा बदलाव
यह प्रपोजल EIP-7864 के इर्द-गिर्द घूमता है, जिसमें Ethereum के मौजूदा hexary Merkle Patricia tree को बाइनरी ट्री डिजाइन से रिप्लेस करने की बात है।
शायद बदलाव छोटा लगे, लेकिन इसके प्रभाव बड़े होंगे। बाइनरी ट्री से Merkle proofs आज की तुलना में 4 गुना छोटे बनेंगे, जिससे वेरिफिकेशन के लिए कम बैंडविड्थ चाहिए होगी।
इससे हल्के clients और privacy-preserving एप्लिकेशंस सस्ते और ज्यादा प्रैक्टिकल बन जाएंगे।
नई संरचना में स्टोरेज स्लॉट्स को “पेजेस” में ग्रुप किया जाएगा, जिससे रिलेटेड डेटा लोड करने वाले ऐप्स के लिए यह और आसान होगा।
कई decentralized applications (dApps) बार-बार पास-पास के स्टोरेज स्लॉट्स को एक्सेस करती हैं। इसका मतलब है कि यह अपग्रेड कुछ मामलों में हर ट्रांजेक्शन में 10,000 से ज्यादा गैस बचा सकता है।
Buterin ने यह भी सुझाया कि ट्री में बदलाव के साथ-साथ ज्यादा एफिशिएंट हैश फंक्शन्स का यूज़ किया जाए, जिससे प्रूफ जनरेशन स्पीड में और सुधार हो सके।
सबसे अहम, यह रीडिज़ाइन Ethereum के बेस लेयर को ज्यादा “prover-friendly” बना देगा, जिससे ZK ऐप्स डायरेक्टली Ethereum की स्टेट के साथ इंटिग्रेट हो पाएंगी, बिना कोई अलग सिस्टम बनाए।
अगर आप बड़े स्तर पर देखें, तो बाइनरी ट्री प्रस्ताव का मकसद है स्टेट मैनेजमेंट के दस साल के अनुभव को एक बेहतर, भविष्य-प्रूफ संरचना में लाना।
EVM के आगे का फ्यूचर?
Buterin का Ethereum के execution engine के लिए लॉन्ग-टर्म विजन और भी महत्वाकांक्षी है। उन्होंने सुझाव दिया कि भविष्य में Ethereum Virtual Machine (EVM) से आगे बढ़कर RISC-V–आधारित आर्किटेक्चर पर शिफ्ट हो सकते हैं।
RISC-V एक ओपन इंस्ट्रक्शन सेट है जो ज्यादा एफिशिएंसी और सिंप्लिसिटी दे सकता है।
Buterin का कहना है कि Ethereum की बढ़ती स्पेशल-केस प्रीकंपाइल्स पर निर्भरता, खुद EVM के प्रति गहरे असंतोष को दर्शाती है।
अगर Ethereum का मुख्य वादा जनरल-पर्पस प्रोग्रामेबिलिटी है, तो उनका मानना है कि VM को इस विज़न को बिना ज़्यादा वर्कअराउंड्स के पूरा सपोर्ट करना चाहिए। RISC-V आधारित VM से ये सम्भव हो सकता है:
- जटिलता को कम करना
- रॉ एक्जीक्यूशन एफिशिएंसी बेहतर बनाना, और
- मॉडर्न ज़ीरो-नॉलेज प्रूविंग सिस्टम्स के साथ बेहतर अलाइनमेंट, क्योंकि इनमें से बहुत से सिस्टम पहले से ही RISC-V एनवायरनमेंट का उपयोग करते हैं।
निकट भविष्य में, Buterin ने “वेक्टराइज्ड मैथ प्रीकंपाइल” का प्रस्ताव रखा है, जिसे “EVM के लिए GPU” कहा जा रहा है। इससे क्रिप्टोग्राफ़िक ऑपरेशंस काफी तेज़ हो सकते हैं।
लॉन्ग-टर्म में, उन्होंने एक फेज्ड ट्रांजिशन का रोडमैप बताया, जिसमें सबसे पहले RISC-V प्रीकंपाइल्स को पावर करेगा, फिर यूज़र द्वारा डिप्लॉय किए गए कॉन्ट्रैक्ट्स को सपोर्ट करेगा, और अंत में EVM को एक कंपैटिबिलिटी लेयर के रूप में एब्ज़ॉर्ब कर लेगा।
Complexity को लेकर Debate
हालांकि, हर कोई Ethereum में इतनी गहरी लेयर चेंजेस से सहमत नहीं है। एनालिस्ट DBCrypto ने Ethereum रोडमैप पर बढ़ती abstraction की आलोचना की है, जिसमें रोलअप फ्रैगमेंटेशन को सुलझाने के लिए नए फ्रेमवर्क भी शामिल हैं।
उनका कहना है कि हर नई लेयर, जटिलता बढ़ाती है, ट्रस्ट की नई ज़रूरतें लाती है, और पॉसिबल अटैक सर्फेस भी बढ़ा देती है।
यह टेंशन एक बड़ी बहस को दर्शाती है – क्या Ethereum को अपनी मौजूदा डिजाइन पर लेयर्स बनाते रहना चाहिए या इसकी फाउंडेशन को फिर से डिजाइन करना चाहिए?
लेकिन Vitalik Buterin के मुताबिक, Ethereum की आर्किटेक्चर को उस समय के साथ आगे बढ़ना और अडॉप्ट करना ही होगा, जब ज़ीरो-नॉलेज प्रूफ्स एक निच से ज़रूरत बन जाएँगे।
उनका मानना है कि स्केलिंग का अगला फेज लेयर 2 पर नहीं, बल्कि Ethereum की कोर में गहराई में आ सकता है।
