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

पृष्ठ अंतिम बार अपडेट किया गया: 23 फ़रवरी 2026

फ़ुसाका

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

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

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

स्केल ब्लॉब्स

पीयरडैस

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

डेटा उपलब्धता नमूनाकरण (opens in a new tab) के साथ, सभी ब्लॉब डेटा को स्टोर करने के बजाय, प्रत्येक नोड ब्लॉब डेटा के एक सबसेट के लिए जिम्मेदार होगा। ब्लॉब्स को नेटवर्क में नोड्स पर समान रूप से यादृच्छिक रूप से वितरित किया जाता है, जिसमें प्रत्येक पूर्ण नोड केवल 1/8 डेटा रखता है, इसलिए 8x तक सैद्धांतिक स्केल-अप को सक्षम करता है। डेटा की उपलब्धता सुनिश्चित करने के लिए, डेटा के किसी भी हिस्से को पूरे के किसी भी मौजूदा 50% से उन तरीकों से पुनर्निर्मित किया जा सकता है जो गलत या गुम डेटा की संभावना को क्रिप्टोग्राफिक रूप से नगण्य स्तर (~1020 में से एक से 1024 में से एक) तक कम कर देते हैं।

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

पीयरडैस के बारे में और जानें

संसाधन:

केवल-ब्लॉब-पैरामीटर फोर्क

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

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

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

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

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

चार्ट जो प्रति ब्लॉक औसत ब्लॉब संख्या और अपग्रेड के साथ बढ़ते लक्ष्यों को दिखाता है

ग्राफ़ स्रोत: एथेरियम Blobs - @hildobby, ड्यून एनालिटिक्स (opens in a new tab)

संसाधन: EIP-7892 तकनीकी विनिर्देश (opens in a new tab)

निष्पादन लागत से घिरा ब्लॉब बेस-फीस

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

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

  • ब्लॉब शुल्क बाजार हमेशा भीड़ पर प्रतिक्रिया करता है
  • लेयर 2 कम से कम उस गणना का एक सार्थक हिस्सा चुकाते हैं जो वे नोड्स पर मजबूर करते हैं
  • EL पर बेस-फीस स्पाइक्स अब ब्लॉब शुल्क को 1 wei पर नहीं छोड़ सकते

संसाधन:

स्केल L1

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

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

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

संसाधन: EIP-7642 तकनीकी विनिर्देश (opens in a new tab)

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

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

संसाधन: EIP-7823 तकनीकी विनिर्देश (opens in a new tab)

ट्रांज़ैक्शन गैस लिमिट कैप

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

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

संसाधन: EIP-7825 तकनीकी विनिर्देश (opens in a new tab)

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

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

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

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

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

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

संसाधन: EIP-7883 तकनीकी विनिर्देश (opens in a new tab)

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

यह एक ब्लॉक कितना बड़ा हो सकता है, इस पर एक सीमा बनाता है - यह नेटवर्क पर भेजे जाने वाले पर एक सीमा है और गैस लिमिट से अलग है, जो एक ब्लॉक के अंदर कार्य को सीमित करता है। ब्लॉक आकार की सीमा 10 MiB है, जिसमें कंसेंसस डेटा के लिए एक छोटी सी छूट (2 MiB) आरक्षित है ताकि सब कुछ फिट हो और सफाई से प्रसारित हो। यदि कोई ब्लॉक इससे बड़ा दिखाई देता है, तो क्लाइंट उसे अस्वीकार कर देते हैं। यह आवश्यक है क्योंकि बहुत बड़े ब्लॉक नेटवर्क में फैलने और सत्यापित होने में अधिक समय लेते हैं और कंसेंसस संबंधी समस्याएं पैदा कर सकते हैं या DoS वेक्टर के रूप में दुरुपयोग किए जा सकते हैं। इसके अलावा, कंसेंसस लेयर की गॉसिप पहले से ही ~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 तकनीकी विनिर्देश (opens in a new tab)

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

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

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

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

संसाधन: EIP-7935 तकनीकी विनिर्देश (opens in a new tab)

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

नियतात्मक प्रस्तावक लुकअहेड

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

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

संसाधन: EIP-7917 तकनीकी विनिर्देश (opens in a new tab)

लीडिंग ज़ीरो (CLZ) की गणना करें ऑपकोड

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

संसाधन: EIP-7939 तकनीकी विनिर्देश (opens in a new tab)

secp256r1 कर्व सपोर्ट के लिए प्रीकंपाइल

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

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

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

संसाधन:

मेटा

eth_config JSON-RPC विधि

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

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

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

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

संसाधन: EIP-7910 तकनीकी विनिर्देश (opens in a new tab)

अक्सर पूछे जाने वाले प्रश्न

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

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

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

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

धोखाधड़ी को पहचानने और इससे बचने पर अधिक जानकारी

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

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

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

L2 स्केलिंग के लिए कौन से सुधार शामिल हैं?

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

BPO फोर्क कैसे अलग हैं?

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

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

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

BPO अपडेट का सटीक शेड्यूल फुसाका रिलीज के साथ निर्धारित किया जाएगा। प्रोटोकॉल घोषणाओं (opens in a new tab) और अपने क्लाइंट के रिलीज़ नोटों का पालन करें।

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

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

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

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

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

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

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

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

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

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

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

पूर्ण नोड

बिना किसी वैलिडेटर वाले नियमित नोड केवल 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 पर तेज निरंतर डाउनलोड बैंडविड्थ रखनी होगी।

अपेक्षित आवश्यकताओं पर अधिक विवरण पढ़ें। (opens in a new tab)

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

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

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

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

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

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

डेवलपर्स के लिए CLZ का क्या मतलब है?

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

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

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

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

यदि आपके अनुबंधों को निष्पादित करने वाले ट्रांज़ैक्शन समान आकार तक पहुंच सकते हैं तो नई 16.7 मिलियन सीमा (opens in a new tab) पर विचार करें।

आगे की रीडिंग

पेज का अंतिम अपडेट: 23 फ़रवरी 2026

क्या यह लेख सहायक था?