मुख्य सामग्री पर जाएं

फुसाका 🦓

इथेरियम का बहुप्रतीक्षित फुसाका अपग्रेड 3 दिसंबर, 2025 को लाइव हो गया

फुसाका नेटवर्क अपग्रेड पेक्ट्रा के बाद आता है और हर इथेरियम उपयोगकर्ता और डेवलपर के लिए अधिक नई सुविधाएँ लाता है और अनुभव को बेहतर बनाता है। इस नाम में निष्पादन परत अपग्रेड ओसाका (Osaka) और सर्वसम्मति परत संस्करण शामिल है जिसका नाम फुलु (Fulu) तारे के नाम पर रखा गया है। इथेरियम के दोनों हिस्सों को एक अपग्रेड प्राप्त होता है जो इथेरियम स्केलिंग, सुरक्षा और उपयोगकर्ता अनुभव को भविष्य की ओर धकेलता है।

फुसाका अपग्रेड इथेरियम के दीर्घकालिक विकास लक्ष्यों में केवल एक कदम है। प्रोटोकॉल रोडमैप और पिछले अपग्रेड के बारे में अधिक जानें।

Ethereum's latest upgrade: Fusaka

A short overview of Ethereum's Fusaka upgrade featuring Ethereum Foundation contributors and ecosystem builders.

ट्रांसक्रिप्ट के साथ देखें 

फुसाका में सुधार

ब्लॉब को स्केल करना

PeerDAS

यह फुसाका फ़ोर्क की मुख्य विशेषता (headliner) है, जो इस अपग्रेड में जोड़ी गई मुख्य सुविधा है। लेयर 2 (l2) वर्तमान में अपना डेटा इथेरियम पर ब्लॉब में पोस्ट करते हैं, जो विशेष रूप से लेयर 2 (l2) के लिए बनाया गया अल्पकालिक डेटा प्रकार है। फुसाका से पहले, हर पूर्ण नोड को यह सुनिश्चित करने के लिए हर ब्लॉब को स्टोर करना पड़ता था कि डेटा मौजूद है। जैसे-जैसे ब्लॉब थ्रूपुट बढ़ता है, इस सभी डेटा को डाउनलोड करना संसाधनों के लिहाज से बहुत अधिक खर्चीला हो जाता है।

डेटा उपलब्धता सैंपलिंग (data availability sampling) (एक नए टैब में खुलता है) के साथ, सभी ब्लॉब डेटा को स्टोर करने के बजाय, प्रत्येक नोड ब्लॉब डेटा के एक सबसेट के लिए जिम्मेदार होगा। नेटवर्क में नोड्स के बीच ब्लॉब को समान रूप से यादृच्छिक रूप से वितरित किया जाता है, जिसमें प्रत्येक पूर्ण नोड डेटा का केवल 1/8 हिस्सा रखता है, जिससे सैद्धांतिक रूप से 8 गुना तक स्केल करना संभव हो जाता है। डेटा की उपलब्धता सुनिश्चित करने के लिए, डेटा के किसी भी हिस्से को पूरे के किसी भी मौजूदा 50% से उन तरीकों से फिर से बनाया जा सकता है जो गलत या गायब डेटा की संभावना को क्रिप्टोग्राफ़िक रूप से नगण्य स्तर (~1020 में एक से 1024 में एक) तक कम कर देते हैं।

यह नोड्स के लिए हार्डवेयर और बैंडविड्थ आवश्यकताओं को बनाए रखने योग्य रखता है, जबकि ब्लॉब स्केलिंग को सक्षम करता है, जिसके परिणामस्वरूप लेयर 2 (l2) के लिए कम शुल्क के साथ अधिक स्केल मिलता है।

PeerDAS के बारे में अधिक जानें

संसाधन:

केवल-ब्लॉब-पैरामीटर (Blob-Parameter-Only) फ़ोर्क

लेयर 2 (l2) इथेरियम को स्केल करते हैं - जैसे-जैसे उनके नेटवर्क बढ़ते हैं, उन्हें इथेरियम पर अधिक डेटा पोस्ट करने की आवश्यकता होती है। इसका मतलब है कि समय के साथ इथेरियम को उनके लिए उपलब्ध ब्लॉब की संख्या बढ़ानी होगी। हालाँकि PeerDAS ब्लॉब डेटा को स्केल करने में सक्षम बनाता है, लेकिन इसे धीरे-धीरे और सुरक्षित रूप से करने की आवश्यकता है।

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

इन समन्वित अपग्रेड में आम तौर पर बहुत सारे बदलाव शामिल होते हैं, बहुत अधिक परीक्षण की आवश्यकता होती है, और इसमें समय लगता है। बदलती लेयर 2 (l2) ब्लॉब आवश्यकताओं के अनुकूल तेजी से ढलने के लिए, केवल-ब्लॉब-पैरामीटर फ़ोर्क उस अपग्रेड शेड्यूल की प्रतीक्षा किए बिना ब्लॉब बढ़ाने के लिए एक तंत्र पेश करते हैं।

केवल-ब्लॉब-पैरामीटर फ़ोर्क क्लाइंट्स द्वारा सेट किए जा सकते हैं, ठीक उसी तरह जैसे गैस सीमा जैसे अन्य कॉन्फ़िगरेशन। प्रमुख इथेरियम अपग्रेड के बीच, क्लाइंट target और max ब्लॉब को उदाहरण के लिए 9 और 12 तक बढ़ाने के लिए सहमत हो सकते हैं और फिर नोड ऑपरेटर उस छोटे फ़ोर्क में भाग लेने के लिए अपडेट करेंगे। इन केवल-ब्लॉब-पैरामीटर फ़ोर्क को किसी भी समय कॉन्फ़िगर किया जा सकता है।

जब डेंकन अपग्रेड में पहली बार नेटवर्क में ब्लॉब जोड़े गए थे, तो लक्ष्य 3 था। पेक्ट्रा में इसे बढ़ाकर 6 कर दिया गया था और, फुसाका के बाद, अब इसे इन प्रमुख नेटवर्क अपग्रेड से स्वतंत्र रूप से एक स्थायी दर पर बढ़ाया जा सकता है।

Chart showing average blob count per block and increasing targets with upgrades

ग्राफ़ स्रोत: Ethereum Blobs - @hildobby, Dune Analytics (एक नए टैब में खुलता है)

संसाधन: EIP-7892 तकनीकी विशिष्टता (एक नए टैब में खुलता है)

निष्पादन लागतों से बंधी ब्लॉब आधार शुल्क

लेयर 2 (l2) जब डेटा पोस्ट करते हैं तो दो बिलों का भुगतान करते हैं: ब्लॉब शुल्क और उन ब्लॉब को सत्यापित करने के लिए आवश्यक निष्पादन गैस। यदि निष्पादन गैस हावी हो जाती है, तो ब्लॉब शुल्क नीलामी 1 Wei तक गिर सकती है और मूल्य संकेत होना बंद कर सकती है।

EIP-7918 हर ब्लॉब के तहत एक आनुपातिक आरक्षित मूल्य (reserve price) तय करता है। जब आरक्षित मूल्य नाममात्र ब्लॉब आधार शुल्क से अधिक होता है, तो शुल्क समायोजन एल्गोरिदम ब्लॉक को लक्ष्य से अधिक मानता है और शुल्क को नीचे धकेलना बंद कर देता है और इसे सामान्य रूप से बढ़ने देता है। परिणामस्वरूप:

  • ब्लॉब शुल्क बाज़ार हमेशा भीड़भाड़ (congestion) पर प्रतिक्रिया करता है
  • लेयर 2 (l2) कम से कम उस कंप्यूट का एक सार्थक हिस्सा चुकाते हैं जो वे नोड्स पर डालते हैं
  • निष्पादन परत (EL) पर आधार शुल्क में उछाल अब ब्लॉब शुल्क को 1 Wei पर नहीं फंसा सकता

संसाधन:

लेयर 1 (l1) को स्केल करना

इतिहास समाप्ति और सरल रसीदें

जुलाई 2025 में, इथेरियम निष्पादन क्लाइंट्स ने आंशिक इतिहास समाप्ति का समर्थन करना शुरू कर दिया (एक नए टैब में खुलता है)। इसने द मर्ज (एक नए टैब में खुलता है) से पुराने इतिहास को हटा दिया ताकि इथेरियम के बढ़ने के साथ नोड ऑपरेटरों द्वारा आवश्यक डिस्क स्थान को कम किया जा सके।

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

संसाधन: EIP-7642 तकनीकी विशिष्टता (एक नए टैब में खुलता है)

MODEXP के लिए ऊपरी सीमाएँ निर्धारित करना

अब तक, MODEXP प्रीकंपाइल लगभग किसी भी आकार के नंबर स्वीकार करता था। इससे परीक्षण करना कठिन हो गया, दुरुपयोग करना आसान हो गया, और क्लाइंट स्थिरता के लिए जोखिम भरा हो गया। EIP-7823 एक स्पष्ट सीमा निर्धारित करता है: प्रत्येक इनपुट नंबर अधिकतम 8192 बिट्स (1024 बाइट्स) लंबा हो सकता है। इससे बड़ा कुछ भी अस्वीकार कर दिया जाता है, लेन-देन की गैस जल जाती है, और कोई स्थिति परिवर्तन नहीं होता है। यह गैस सीमा योजना और सुरक्षा समीक्षाओं को जटिल बनाने वाले चरम मामलों को हटाते हुए वास्तविक दुनिया की जरूरतों को बहुत आराम से कवर करता है। यह परिवर्तन उपयोगकर्ता या डेवलपर अनुभव को प्रभावित किए बिना अधिक सुरक्षा और DoS सुरक्षा प्रदान करता है।

संसाधन: EIP-7823 तकनीकी विशिष्टता (एक नए टैब में खुलता है)

लेन-देन गैस सीमा कैप

EIP-7825 (एक नए टैब में खुलता है) प्रति लेन-देन 16,777,216 (2^24) गैस की सीमा (cap) जोड़ता है। जैसे-जैसे हम ब्लॉक गैस सीमा बढ़ाते हैं, यह किसी भी एकल लेन-देन की सबसे खराब स्थिति की लागत को सीमित करके सक्रिय DoS सुरक्षा है। यह गैस सीमा बढ़ाकर स्केलिंग से निपटने की अनुमति देने के लिए सत्यापन और प्रसार को मॉडल करना आसान बनाता है।

ठीक 2^24 गैस ही क्यों? यह आज की गैस सीमा से काफी छोटा है, वास्तविक अनुबंध परिनियोजन और भारी प्रीकंपाइल के लिए काफी बड़ा है, और 2 की घात होने के कारण इसे क्लाइंट्स में लागू करना आसान हो जाता है। यह नया अधिकतम लेन-देन आकार पेक्ट्रा-पूर्व औसत ब्लॉक आकार के समान है, जो इसे इथेरियम पर किसी भी ऑपरेशन के लिए एक उचित सीमा बनाता है।

संसाधन: EIP-7825 तकनीकी विशिष्टता (एक नए टैब में खुलता है)

MODEXP गैस लागत में वृद्धि

MODEXP एक प्रीकंपाइल अंतर्निहित फ़ंक्शन है जो मॉड्यूलर घातांक (modular exponentiation) की गणना करता है, जो RSA हस्ताक्षर सत्यापन और प्रमाण प्रणालियों में उपयोग किया जाने वाला एक प्रकार का बड़ी-संख्या वाला गणित है। यह अनुबंधों को स्वयं लागू किए बिना इन गणनाओं को सीधे चलाने की अनुमति देता है।

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

यह EIP वास्तविक कम्प्यूटेशनल लागतों से मेल खाने के लिए मूल्य निर्धारण को बदलता है:

  • न्यूनतम शुल्क को 200 से बढ़ाकर 500 गैस करना और सामान्य लागत गणना पर EIP-2565 से एक-तिहाई छूट को हटाना
  • घातांक (exponent) इनपुट बहुत लंबा होने पर लागत को अधिक तेजी से बढ़ाना। यदि घातांक (वह "पावर" संख्या जिसे आप दूसरे तर्क के रूप में पास करते हैं) 32 बाइट्स / 256 बिट्स से अधिक लंबा है, तो प्रत्येक अतिरिक्त बाइट के लिए गैस शुल्क बहुत तेजी से बढ़ता है
  • बड़े आधार (base) या मापांक (modulus) के लिए भी अतिरिक्त शुल्क लेना। अन्य दो संख्याओं (आधार और मापांक) को कम से कम 32 बाइट्स माना जाता है - यदि कोई भी बड़ा है, तो लागत उसके आकार के अनुपात में बढ़ जाती है

लागतों को वास्तविक प्रसंस्करण समय से बेहतर ढंग से मिला कर, MODEXP अब किसी ब्लॉक को सत्यापित करने में बहुत अधिक समय नहीं लगा सकता है। यह परिवर्तन भविष्य में इथेरियम की ब्लॉक गैस सीमा को बढ़ाना सुरक्षित बनाने के उद्देश्य से किए गए कई परिवर्तनों में से एक है।

संसाधन: EIP-7883 तकनीकी विशिष्टता (एक नए टैब में खुलता है)

RLP निष्पादन ब्लॉक आकार सीमा

यह इस बात पर एक सीमा (ceiling) बनाता है कि एक ब्लॉक को कितना बड़ा होने की अनुमति है - यह नेटवर्क पर भेजे जाने वाले डेटा की सीमा है और गैस सीमा से अलग है, जो ब्लॉक के अंदर काम को सीमित करती है। ब्लॉक आकार की सीमा 10 MiB है, जिसमें सर्वसम्मति डेटा के लिए एक छोटी सी छूट (2 MiB) आरक्षित है ताकि सब कुछ फिट हो जाए और सफाई से प्रसारित हो सके। यदि कोई ब्लॉक इससे बड़ा दिखाई देता है, तो क्लाइंट उसे अस्वीकार कर देते हैं। इसकी आवश्यकता इसलिए है क्योंकि बहुत बड़े ब्लॉकों को नेटवर्क में फैलने और सत्यापित होने में अधिक समय लगता है और वे सर्वसम्मति के मुद्दे पैदा कर सकते हैं या DoS वेक्टर के रूप में दुरुपयोग किए जा सकते हैं। इसके अलावा, सर्वसम्मति परत का गॉसिप (gossip) पहले से ही ~10 MiB से अधिक के ब्लॉकों को आगे नहीं बढ़ाता है, इसलिए निष्पादन परत को उस सीमा के साथ संरेखित करने से "कुछ द्वारा देखा गया, दूसरों द्वारा छोड़ दिया गया" जैसी अजीब स्थितियों से बचा जा सकता है।

बारीकियां: यह RLP-एन्कोडेड निष्पादन ब्लॉक आकार पर एक सीमा है। कुल 10 MiB, जिसमें बीकन-ब्लॉक फ़्रेमिंग के लिए 2 MiB सुरक्षा मार्जिन आरक्षित है। व्यावहारिक रूप से, क्लाइंट परिभाषित करते हैं

MAX_BLOCK_SIZE = 10,485,760 बाइट्स और

SAFETY_MARGIN = 2,097,152 बाइट्स,

और किसी भी निष्पादन ब्लॉक को अस्वीकार कर देते हैं जिसका RLP पेलोड इससे अधिक हो

MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE − SAFETY_MARGIN

लक्ष्य सबसे खराब स्थिति वाले प्रसार/सत्यापन समय को सीमित करना और सर्वसम्मति परत गॉसिप व्यवहार के साथ संरेखित करना है, जिससे गैस अकाउंटिंग को बदले बिना पुनर्गठन/DoS जोखिम कम हो सके।

संसाधन: EIP-7934 तकनीकी विशिष्टता (एक नए टैब में खुलता है)

डिफ़ॉल्ट गैस सीमा 60 मिलियन पर सेट करना

फरवरी 2025 में गैस सीमा को 30M से बढ़ाकर 36M (और बाद में 45M) करने से पहले, यह मान द मर्ज (सितंबर 2022) के बाद से नहीं बदला था। इस EIP का उद्देश्य लगातार स्केलिंग को प्राथमिकता बनाना है।

EIP-7935 निष्पादन परत (EL) क्लाइंट टीमों को फुसाका के लिए डिफ़ॉल्ट गैस-सीमा को आज के 45M से ऊपर बढ़ाने के लिए समन्वयित करता है। यह एक सूचनात्मक EIP है, लेकिन यह स्पष्ट रूप से क्लाइंट्स को डेवनेट पर उच्च सीमाओं का परीक्षण करने, एक सुरक्षित मूल्य पर अभिसरण (converge) करने और उस संख्या को अपने फुसाका रिलीज़ में शिप करने के लिए कहता है।

डेवनेट योजना ~60M तनाव (सिंथेटिक लोड के साथ पूर्ण ब्लॉक) और पुनरावृत्त वृद्धि को लक्षित करती है; शोध कहता है कि सबसे खराब स्थिति वाले ब्लॉक-आकार की विकृतियां ~150M से नीचे नहीं आनी चाहिए। रोलआउट को लेन-देन गैस-सीमा कैप (EIP-7825) के साथ जोड़ा जाना चाहिए ताकि सीमा बढ़ने पर कोई भी एकल लेन-देन हावी न हो सके।

संसाधन: EIP-7935 तकनीकी विशिष्टता (एक नए टैब में खुलता है)

UX में सुधार

नियतात्मक प्रस्तावक लुकअहेड (Deterministic proposer lookahead)

EIP-7917 के साथ, बीकन चेन अगले एपॉक के लिए आगामी ब्लॉक प्रस्तावकों के बारे में जागरूक हो जाएगी। कौन से सत्यापक भविष्य के ब्लॉक प्रस्तावित करेंगे, इस पर एक नियतात्मक दृष्टिकोण होने से पूर्व-पुष्टिकरण (preconfirmations) (एक नए टैब में खुलता है) सक्षम हो सकता है - आगामी प्रस्तावक के साथ एक प्रतिबद्धता जो गारंटी देती है कि उपयोगकर्ता का लेन-देन वास्तविक ब्लॉक की प्रतीक्षा किए बिना उनके ब्लॉक में शामिल किया जाएगा।

यह सुविधा क्लाइंट कार्यान्वयन और नेटवर्क की सुरक्षा को लाभ पहुंचाती है क्योंकि यह उन चरम मामलों को रोकती है जहां सत्यापक प्रस्तावक अनुसूची में हेरफेर कर सकते हैं। लुकअहेड कार्यान्वयन की कम जटिलता की भी अनुमति देता है।

संसाधन: EIP-7917 तकनीकी विशिष्टता (एक नए टैब में खुलता है)

काउंट लीडिंग ज़ीरोज़ (CLZ) ऑपकोड

यह सुविधा एक छोटा EVM निर्देश जोड़ती है, काउंट लीडिंग ज़ीरोज़ (CLZ)। EVM में लगभग सब कुछ 256-बिट मान के रूप में दर्शाया जाता है—यह नया ऑपकोड यह लौटाता है कि सामने कितने शून्य बिट्स हैं। यह कई निर्देश सेट आर्किटेक्चर में एक सामान्य विशेषता है क्योंकि यह अधिक कुशल अंकगणितीय संचालन को सक्षम बनाता है। व्यवहार में यह आज के हाथ से किए गए बिट स्कैन को एक चरण में समेट देता है, इसलिए पहला सेट बिट खोजना, बाइट्स को स्कैन करना, या बिटफ़ील्ड को पार्स करना सरल और सस्ता हो जाता है। ऑपकोड कम, निश्चित-लागत वाला है और इसे एक बुनियादी जोड़ (add) के बराबर बेंचमार्क किया गया है, जो बाइटकोड को ट्रिम करता है और उसी काम के लिए गैस बचाता है।

संसाधन: EIP-7939 तकनीकी विशिष्टता (एक नए टैब में खुलता है)

secp256r1 Curve समर्थन के लिए प्रीकंपाइल

निश्चित पते 0x100 पर एक अंतर्निहित, पासकी-शैली secp256r1 (P-256) हस्ताक्षर चेकर पेश करता है, जो उसी कॉल प्रारूप का उपयोग करता है जिसे पहले से ही कई लेयर 2 (l2) द्वारा अपनाया गया है और चरम मामलों को ठीक करता है, ताकि उन वातावरणों के लिए लिखे गए अनुबंध बिना किसी बदलाव के लेयर 1 (l1) पर काम करें।

UX अपग्रेड! उपयोगकर्ताओं के लिए, यह डिवाइस-नेटिव हस्ताक्षर करना और पासकी को अनलॉक करता है। वॉलेट सीधे Apple Secure Enclave, Android कीस्टोर, हार्डवेयर सुरक्षा मॉड्यूल (HSMs), और FIDO2/WebAuthn का उपयोग कर सकते हैं - कोई बीज वाक्यांश नहीं, आसान ऑनबोर्डिंग, और मल्टी-फैक्टर प्रवाह जो आधुनिक ऐप्स की तरह महसूस होते हैं। इसके परिणामस्वरूप बेहतर UX, आसान रिकवरी, और खाता अमूर्तन पैटर्न मिलते हैं जो अरबों डिवाइस पहले से ही करते हैं।

डेवलपर्स के लिए, यह 160-बाइट इनपुट लेता है और 32-बाइट आउटपुट देता है, जिससे मौजूदा लाइब्रेरी और लेयर 2 (l2) अनुबंधों को पोर्ट करना आसान हो जाता है। आंतरिक रूप से (under the hood), इसमें वैध कॉलर्स को तोड़े बिना मुश्किल चरम मामलों को खत्म करने के लिए पॉइंट-एट-इन्फिनिटी और मॉड्यूलर-तुलना जांच शामिल हैं।

संसाधन:

मेटा

eth_config जेसन-आरपीसी विधि

यह एक जेसन-आरपीसी कॉल है जो आपको अपने नोड से यह पूछने की अनुमति देता है कि आप कौन सी फ़ोर्क सेटिंग्स चला रहे हैं। यह तीन स्नैपशॉट लौटाता है: current, next, और last ताकि सत्यापक और निगरानी उपकरण यह सत्यापित कर सकें कि क्लाइंट आगामी फ़ोर्क के लिए तैयार हैं।

व्यावहारिक रूप से कहें तो, यह उस कमी को दूर करने के लिए है जो तब खोजी गई थी जब पेक्ट्रा फ़ोर्क 2025 की शुरुआत में होलेस्की टेस्टनेट पर मामूली गलत कॉन्फ़िगरेशन के साथ लाइव हुआ था, जिसके परिणामस्वरूप एक गैर-अंतिम स्थिति (non-finalizing state) उत्पन्न हुई थी। यह परीक्षण टीमों और डेवलपर्स को यह सुनिश्चित करने में मदद करता है कि डेवनेट से टेस्टनेट और टेस्टनेट से मेननेट में जाते समय प्रमुख फ़ोर्क उम्मीद के मुताबिक व्यवहार करेंगे।

स्नैपशॉट में शामिल हैं: chainId, forkId, नियोजित फ़ोर्क सक्रियण समय, कौन से प्रीकंपाइल सक्रिय हैं, प्रीकंपाइल पते, सिस्टम अनुबंध निर्भरताएँ, और फ़ोर्क का ब्लॉब शेड्यूल।

यह EIP "कोर EIPs" से अलग एक अनुभाग में है क्योंकि फ़ोर्क वास्तव में कोई बदलाव लागू नहीं करता है - यह एक नोटिस है कि क्लाइंट टीमों को फुसाका अपग्रेड तक इस जेसन-आरपीसी विधि को लागू करना चाहिए।

संसाधन: EIP-7910 तकनीकी विशिष्टता (एक नए टैब में खुलता है)

सामान्य प्रश्न (FAQ)

क्या यह अपग्रेड सभी इथेरियम नोड्स और सत्यापकों को प्रभावित करता है?

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

हार्ड फ़ोर्क के बाद ETH को कैसे परिवर्तित किया जा सकता है?

  • आपके ETH के लिए किसी कार्रवाई की आवश्यकता नहीं है: इथेरियम फुसाका अपग्रेड के बाद, आपके ETH को परिवर्तित या अपग्रेड करने की कोई आवश्यकता नहीं है। आपके खाते का बैलेंस वही रहेगा, और जो ETH आप वर्तमान में रखते हैं वह हार्ड फ़ोर्क के बाद अपने मौजूदा रूप में सुलभ रहेगा।
  • घोटालों से सावधान रहें! कोई भी जो आपको अपना ETH "अपग्रेड" करने का निर्देश दे रहा है, वह आपको धोखा देने की कोशिश कर रहा है। इस अपग्रेड के संबंध में आपको कुछ भी करने की आवश्यकता नहीं है। आपकी संपत्तियां पूरी तरह से अप्रभावित रहेंगी। याद रखें, सूचित रहना घोटालों के खिलाफ सबसे अच्छा बचाव है।

घोटालों को पहचानने और उनसे बचने के बारे में अधिक जानकारी

ज़ेबरा का क्या मतलब है?

ज़ेबरा फुसाका का डेवलपर-चुना हुआ "शुभंकर (mascot)" है क्योंकि इसकी धारियां PeerDAS के कॉलम-आधारित डेटा-उपलब्धता सैंपलिंग को दर्शाती हैं, जहां नोड्स कुछ कॉलम सबनेट को कस्टडी में रखते हैं और यह जांचने के लिए प्रत्येक पीयर स्लॉट से कुछ अन्य कॉलम का नमूना लेते हैं कि ब्लॉब डेटा उपलब्ध है।

2022 में द मर्ज ने निष्पादन और सर्वसम्मति परतों के जुड़ने का संकेत देने के लिए पांडा का उपयोग (एक नए टैब में खुलता है) अपने शुभंकर के रूप में किया था। तब से, प्रत्येक फ़ोर्क के लिए अनौपचारिक रूप से शुभंकर चुने गए हैं और अपग्रेड के समय क्लाइंट लॉग में ASCII कला के रूप में दिखाई देते हैं। यह जश्न मनाने का एक मजेदार तरीका है।

लेयर 2 (l2) स्केलिंग के लिए कौन से सुधार शामिल हैं?

PeerDAS फ़ोर्क की मुख्य विशेषता है। यह डेटा उपलब्धता सैंपलिंग (DAS) लागू करता है जो रोलअप्स के लिए अधिक स्केलेबिलिटी को अनलॉक करता है, सैद्धांतिक रूप से ब्लॉब स्पेस को वर्तमान आकार के 8 गुना तक स्केल करता है। ब्लॉब शुल्क बाज़ार में भी सुधार किया जाएगा ताकि भीड़भाड़ पर कुशलता से प्रतिक्रिया की जा सके और यह गारंटी दी जा सके कि लेयर 2 (l2) उस कंप्यूट और स्पेस के लिए एक सार्थक शुल्क का भुगतान करें जो ब्लॉब नोड्स पर थोपते हैं।

BPO फ़ोर्क कैसे भिन्न हैं?

केवल-ब्लॉब-पैरामीटर (BPO) फ़ोर्क PeerDAS सक्रिय होने के बाद ब्लॉब की संख्या (लक्ष्य और अधिकतम दोनों) को लगातार बढ़ाने के लिए एक तंत्र प्रदान करते हैं, बिना पूर्ण समन्वित अपग्रेड की प्रतीक्षा किए। प्रत्येक वृद्धि को फुसाका का समर्थन करने वाले क्लाइंट रिलीज़ में पूर्व-कॉन्फ़िगर करने के लिए हार्डकोड किया गया है।

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

BPO शेड्यूल क्या है?

BPO अपडेट का सटीक शेड्यूल फुसाका रिलीज़ के साथ निर्धारित किया जाएगा। प्रोटोकॉल घोषणाओं (एक नए टैब में खुलता है) और अपने क्लाइंट्स के रिलीज़ नोट्स का पालन करें।

यह कैसा दिख सकता है इसका उदाहरण:

  • फुसाका से पहले: लक्ष्य 6, अधिकतम 9
  • फुसाका सक्रियण पर: लक्ष्य 6, अधिकतम 9
  • BPO1, फुसाका सक्रियण के कुछ सप्ताह बाद: लक्ष्य 10, अधिकतम 15, दो-तिहाई की वृद्धि
  • BPO2, BPO1 के कुछ सप्ताह बाद: लक्ष्य 14, अधिकतम 21

क्या इससे इथेरियम (लेयर 1 (l1)) पर शुल्क कम होगा?

यह अपग्रेड लेयर 1 (l1) पर गैस शुल्क कम नहीं करता है, कम से कम सीधे तौर पर तो नहीं। मुख्य ध्यान रोलअप डेटा के लिए अधिक ब्लॉब स्पेस पर है, इसलिए लेयर 2 (l2) पर शुल्क कम करना है। इसका लेयर 1 (l1) शुल्क बाज़ार पर कुछ दुष्प्रभाव हो सकता है लेकिन किसी महत्वपूर्ण बदलाव की उम्मीद नहीं है।

एक स्टेकर के रूप में, मुझे अपग्रेड के लिए क्या करने की आवश्यकता है?

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

क्या "नियतात्मक प्रस्तावक लुकअहेड" (EIP-7917) सत्यापकों को प्रभावित करता है?

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

फुसाका नोड्स और सत्यापकों के लिए बैंडविड्थ आवश्यकताओं को कैसे प्रभावित करता है?

PeerDAS नोड्स द्वारा ब्लॉब डेटा संचारित करने के तरीके में एक महत्वपूर्ण बदलाव करता है। सभी डेटा को 128 सबनेट में कॉलम नामक टुकड़ों में विभाजित किया जाता है, जिसमें नोड्स केवल उनमें से कुछ की सदस्यता लेते हैं। नोड्स को जिन सबनेट कॉलम की कस्टडी रखनी होती है, उनकी मात्रा उनके कॉन्फ़िगरेशन और जुड़े सत्यापकों की संख्या पर निर्भर करती है। वास्तविक बैंडविड्थ आवश्यकताएं नेटवर्क में अनुमत ब्लॉब की मात्रा और नोड के प्रकार पर निर्भर करेंगी। फुसाका सक्रियण के समय ब्लॉब लक्ष्य पहले जैसा ही रहता है, लेकिन PeerDAS के साथ, नोड ऑपरेटर ब्लॉब के अपने डिस्क उपयोग और नेटवर्क ट्रैफ़िक में कमी देख सकते हैं। जैसे-जैसे BPO नेटवर्क में अधिक संख्या में ब्लॉब कॉन्फ़िगर करते हैं, प्रत्येक BPO के साथ आवश्यक बैंडविड्थ बढ़ेगी।

फुसाका BPO के बाद भी नोड्स की आवश्यकताएं अनुशंसित मार्जिन (एक नए टैब में खुलता है) के भीतर हैं।

पूर्ण नोड

बिना किसी सत्यापक वाले नियमित नोड केवल 4 सबनेट की सदस्यता लेंगे, जो मूल डेटा के 1/8 के लिए कस्टडी प्रदान करेंगे। इसका मतलब है कि समान मात्रा में ब्लॉब डेटा के साथ, उन्हें डाउनलोड करने की नोड बैंडविड्थ आठ (8) के कारक से छोटी होगी। एक सामान्य पूर्ण नोड के लिए ब्लॉब का डिस्क उपयोग और डाउनलोड बैंडविड्थ लगभग 80% कम होकर केवल कुछ Mb तक हो सकता है।

सोलो स्टेकर्स

यदि नोड का उपयोग सत्यापक क्लाइंट के लिए किया जाता है, तो उसे अधिक कॉलम की कस्टडी रखनी होती है और इसलिए अधिक डेटा संसाधित करना होता है। एक सत्यापक जोड़े जाने के साथ, नोड कम से कम 8 कॉलम सबनेट की सदस्यता लेता है और इसलिए नियमित नोड की तुलना में दोगुना डेटा संसाधित करता है लेकिन फिर भी फुसाका से कम। यदि सत्यापक बैलेंस 287 ETH से ऊपर है, तो अधिक से अधिक सबनेट की सदस्यता ली जाएगी।

एक सोलो स्टेकर के लिए, इसका मतलब है कि उनका डिस्क उपयोग और डाउनलोड बैंडविड्थ लगभग 50% कम हो जाएगा। हालाँकि स्थानीय रूप से ब्लॉक बनाने और नेटवर्क पर सभी ब्लॉब अपलोड करने के लिए, अधिक अपलोड बैंडविड्थ की आवश्यकता होती है। स्थानीय बिल्डरों को फुसाका के समय पहले की तुलना में 2-3 गुना अधिक अपलोड बैंडविड्थ की आवश्यकता होगी और 15/21 ब्लॉब के BPO2 लक्ष्य के साथ, अंतिम आवश्यक अपलोड बैंडविड्थ लगभग 5 गुना अधिक, 100Mpbs पर होनी चाहिए।

बड़े सत्यापक

नोड में अधिक बैलेंस और सत्यापक जोड़े जाने के साथ सब्सक्राइब किए गए सबनेट की संख्या बढ़ती है। उदाहरण के लिए, लगभग 800 ETH बैलेंस पर, नोड 25 कॉलम की कस्टडी रखता है और उसे पहले की तुलना में लगभग 30% अधिक डाउनलोड बैंडविड्थ की आवश्यकता होगी। आवश्यक अपलोड नियमित नोड्स के समान बढ़ता है और कम से कम 100Mbps आवश्यक है।

4096 ETH, 2 अधिकतम बैलेंस सत्यापकों पर, नोड 'सुपरनोड' बन जाता है जो सभी कॉलम की कस्टडी रखता है, इसलिए सब कुछ डाउनलोड और स्टोर करता है। ये नोड गायब डेटा को वापस योगदान करके नेटवर्क को सक्रिय रूप से ठीक करते हैं लेकिन इसके लिए बहुत अधिक बैंडविड्थ और स्टोरेज की भी आवश्यकता होती है। अंतिम ब्लॉब लक्ष्य पहले की तुलना में 6 गुना अधिक होने के साथ, सुपर नोड्स को लगभग 600GB अतिरिक्त ब्लॉब डेटा स्टोर करना होगा और लगभग 20Mbps पर तेज़ निरंतर डाउनलोड बैंडविड्थ होनी चाहिए।

अपेक्षित आवश्यकताओं पर अधिक विवरण पढ़ें। (एक नए टैब में खुलता है)

कौन से EVM परिवर्तन लागू किए गए हैं?

फुसाका नए मामूली बदलावों और सुविधाओं के साथ EVM को मजबूत करता है।

नई 16M गैस सीमा अनुबंध डेवलपर्स को कैसे प्रभावित करती है?

फुसाका एकल लेन-देन के अधिकतम आकार को 16.7 मिलियन (एक नए टैब में खुलता है) (2^24) गैस इकाइयों तक सीमित करता है। यह मोटे तौर पर एक औसत ब्लॉक का पिछला आकार है जो इसे जटिल लेन-देन को समायोजित करने के लिए काफी बड़ा बनाता है जो पूरे ब्लॉक का उपभोग करेगा। यह सीमा क्लाइंट्स के लिए सुरक्षा बनाती है, भविष्य में उच्च ब्लॉक गैस सीमा के साथ संभावित DoS हमलों को रोकती है। स्केलिंग का लक्ष्य अधिक लेन-देन को ब्लॉकचेन में शामिल करने में सक्षम बनाना है, बिना किसी एक के पूरे ब्लॉक का उपभोग किए।

नियमित उपयोगकर्ता लेन-देन इस सीमा तक पहुंचने से बहुत दूर हैं। कुछ चरम मामले जैसे बड़े और जटिल DeFi संचालन, बड़े स्मार्ट अनुबंध परिनियोजन या कई अनुबंधों को लक्षित करने वाले बैच लेन-देन इस परिवर्तन से प्रभावित हो सकते हैं। इन लेन-देन को छोटे भागों में विभाजित करना होगा या किसी अन्य तरीके से अनुकूलित करना होगा। संभावित रूप से सीमा तक पहुंचने वाले लेन-देन सबमिट करने से पहले सिमुलेशन का उपयोग करें।

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

डेवलपर्स के लिए CLZ का क्या अर्थ है?

Solidity जैसे EVM कंपाइलर आंतरिक रूप से (under the hood) शून्य गिनने के लिए नए फ़ंक्शन को लागू और उपयोग करेंगे। यदि नए अनुबंध इस प्रकार के संचालन पर निर्भर करते हैं तो उन्हें गैस बचत से लाभ हो सकता है। संभावित बचत पर दस्तावेज़ीकरण के लिए स्मार्ट अनुबंध भाषा के रिलीज़ और फीचर घोषणाओं का पालन करें।

क्या मेरे मौजूदा स्मार्ट अनुबंधों के लिए कोई बदलाव हैं?

फुसाका का कोई सीधा प्रभाव नहीं है जो किसी मौजूदा अनुबंध को तोड़ दे या उनके व्यवहार को बदल दे। निष्पादन परत में पेश किए गए परिवर्तन बैकवर्ड संगतता (backward compatibility) के साथ किए गए हैं, हालांकि, हमेशा चरम मामलों और संभावित प्रभाव पर नज़र रखें।

ModExp प्रीकंपाइल की बढ़ी हुई लागत के साथ (एक नए टैब में खुलता है), जो अनुबंध इस पर निर्भर हैं वे निष्पादन के लिए अधिक गैस का उपभोग करेंगे। यदि आपका अनुबंध इस पर बहुत अधिक निर्भर करता है और उपयोगकर्ताओं के लिए अधिक महंगा हो जाता है, तो इस पर पुनर्विचार करें कि इसका उपयोग कैसे किया जाता है।

यदि आपके अनुबंधों को निष्पादित करने वाले लेन-देन समान आकार तक पहुंच रहे हैं, तो नई 16.7 मिलियन सीमा (एक नए टैब में खुलता है) पर विचार करें।

आगे की सामग्री