प्रमुख मजकुराकडे जा

पृष्ठ अखेरचे अद्यतनित: २३ फेब्रुवारी, २०२६

फुसाका

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

फुसाका नेटवर्क अपग्रेड पेक्ट्रा नंतर येतो आणि प्रत्येक इथेरियम वापरकर्ता आणि डेव्हलपरसाठी अधिक नवीन वैशिष्ट्ये आणतो आणि अनुभव सुधारतो. या नावामध्ये एक्झिक्यूशन लेअर अपग्रेड ओसाका आणि फुलू ताऱ्याच्या नावावरून ठेवलेल्या कन्सेन्सस लेअर आवृत्तीचा समावेश आहे. इथेरियमच्या दोन्ही भागांना एक अपग्रेड मिळतो जो इथेरियम स्केलिंग, सुरक्षा आणि वापरकर्ता अनुभव भविष्यात पुढे नेतो.

फुसाकामधील सुधारणा

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

PeerDAS

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

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

हे नोड्ससाठी हार्डवेअर आणि बँडविड्थ आवश्यकता टिकवून ठेवते, तसेच ब्लॉब स्केलिंग सक्षम करते, ज्यामुळे लेअर 2s साठी कमी शुल्कासह अधिक स्केल मिळतो.

PeerDAS बद्दल अधिक जाणून घ्या

संसाधने:

ब्लॉब-पॅरामीटर-ओन्ली फोर्क्स

लेअर 2s इथेरियमला स्केल करतात - जसजसे त्यांचे नेटवर्क वाढतात, तसतसे त्यांना इथेरियमवर अधिक डेटा पोस्ट करावा लागतो. याचा अर्थ असा आहे की इथेरियमला ​​वेळेनुसार त्यांच्यासाठी उपलब्ध असलेल्या ब्लॉब्सची संख्या वाढवावी लागेल. जरी PeerDAS ब्लॉब डेटा स्केलिंग सक्षम करते, तरी ते हळूहळू आणि सुरक्षितपणे करणे आवश्यक आहे.

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

या समन्वित अपग्रेडमध्ये सामान्यतः बरेच बदल समाविष्ट असतात, भरपूर चाचणी आवश्यक असते आणि त्यासाठी वेळ लागतो. बदलत्या लेअर 2 ब्लॉब गरजांशी जलद जुळवून घेण्यासाठी, ब्लॉब पॅरामीटर ओन्ली फोर्क्स त्या अपग्रेड शेड्यूलची वाट न पाहता ब्लॉब्स वाढवण्यासाठी एक यंत्रणा सादर करतात.

ब्लॉब पॅरामीटर ओन्ली फोर्क्स क्लायंटद्वारे सेट केले जाऊ शकतात, जसे की गॅस लिमिटसारख्या इतर कॉन्फिगरेशनप्रमाणे. मोठ्या इथेरियम अपग्रेड्सदरम्यान, क्लायंट target आणि max ब्लॉब्स उदाहरणार्थ 9 आणि 12 पर्यंत वाढवण्यास सहमत होऊ शकतात आणि नंतर नोड ऑपरेटर त्या लहान फोर्कमध्ये भाग घेण्यासाठी अपडेट करतील. हे ब्लॉब पॅरामीटर ओन्ली फोर्क्स कधीही कॉन्फिगर केले जाऊ शकतात.

जेव्हा डेंकुन अपग्रेडमध्ये नेटवर्कमध्ये प्रथम ब्लॉब्स जोडले गेले, तेव्हा लक्ष्य 3 होते. पेक्ट्रामध्ये ते 6 पर्यंत वाढवले ​​गेले आणि फुसाका नंतर, आता या मोठ्या नेटवर्क अपग्रेडपासून स्वतंत्रपणे टिकाऊ दराने वाढवता येईल.

प्रत्येक ब्लॉकमधील सरासरी ब्लॉब संख्या दर्शवणारा आणि अपग्रेडसह लक्ष्य वाढवणारा चार्ट

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

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

ब्लॉब बेस-फी एक्झिक्यूशन खर्चाने मर्यादित

जेव्हा लेअर 2s डेटा पोस्ट करतात तेव्हा ते दोन बिल भरतात: ब्लॉब फी आणि ते ब्लॉब सत्यापित करण्यासाठी आवश्यक असलेले एक्झिक्यूशन गॅस. जर एक्झिक्यूशन गॅसचे वर्चस्व असेल, तर ब्लॉब फी लिलाव 1 wei पर्यंत खाली येऊ शकतो आणि किंमत संकेत देण्याचे थांबवू शकतो.

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

  • ब्लॉब फी मार्केट नेहमी गर्दीवर प्रतिक्रिया देते
  • लेअर 2s नोड्सवर जबरदस्तीने केलेल्या कंप्यूटचा किमान एक अर्थपूर्ण भाग देतात
  • 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, Android Keystore, हार्डवेअर सिक्युरिटी मॉड्यूल्स (HSMs), आणि FIDO2/WebAuthn थेट वापरू शकतात - कोणताही सीड फ्रेज नाही, सोपे ऑनबोर्डिंग आणि आधुनिक ॲप्ससारखे वाटणारे मल्टी-फॅक्टर फ्लो. यामुळे चांगला UX, सोपी रिकव्हरी, आणि अब्जावधी उपकरणे आधीच करत असलेल्या गोष्टींशी जुळणारे खाते अमूर्ततेचे नमुने मिळतात.

डेव्हलपर्ससाठी, हे 160-बाइट इनपुट घेते आणि 32-बाइट आउटपुट देते, ज्यामुळे विद्यमान लायब्ररी आणि L2 कॉन्ट्रॅक्ट्स पोर्ट करणे सोपे होते. अंतर्गत, यात वैध कॉलर्सना न मोडता अवघड एज केसेस काढून टाकण्यासाठी पॉइंट-ॲट-इन्फिनिटी आणि मॉड्युलर-कम्पेरिझन तपासण्या समाविष्ट आहेत.

संसाधने:

मेटा

eth_config JSON-RPC पद्धत

हा एक JSON-RPC कॉल आहे जो तुम्हाला तुमच्या नोडला विचारण्याची परवानगी देतो की तुम्ही कोणती फोर्क सेटिंग्ज चालवत आहात. हे तीन स्नॅपशॉट परत करते: current, next, आणि last जेणेकरून व्हॅलिडेटर्स आणि मॉनिटरिंग टूल्स आगामी फोर्कसाठी क्लायंट्स रांगेत आहेत की नाही हे सत्यापित करू शकतील.

व्यावहारिकदृष्ट्या सांगायचे झाल्यास, 2025 च्या सुरुवातीला Holesky टेस्टनेटवर Pectra फोर्क लाइव्ह झाल्यावर किरकोळ चुकीच्या कॉन्फिगरेशनमुळे शोधलेली एक कमतरता दूर करण्यासाठी हे आहे, ज्यामुळे एक नॉन-फायनलायझिंग स्थिती निर्माण झाली. हे टेस्टिंग टीम्स आणि डेव्हलपर्सना खात्री करण्यास मदत करते की डेव्हनेटवरून टेस्टनेटवर आणि टेस्टनेटवरून मेननेटवर जाताना मोठे फोर्क्स अपेक्षेप्रमाणे वागतील.

स्नॅपशॉटमध्ये समाविष्ट आहे: chainId, forkId, नियोजित फोर्क सक्रिय करण्याची वेळ, कोणते प्रीकॉम्पाइल सक्रिय आहेत, प्रीकॉम्पाइल पत्ते, सिस्टम कॉन्ट्रॅक्ट अवलंबित्व आणि फोर्कचे ब्लॉब शेड्यूल.

हे EIP "कोअर EIPs" पासून वेगळ्या विभागात आहे कारण फोर्क प्रत्यक्षात कोणतेही बदल लागू करत नाही - ही एक सूचना आहे की क्लायंट टीम्सने फुसाका अपग्रेडद्वारे ही JSON-RPC पद्धत लागू केली पाहिजे.

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

FAQ

हे अपग्रेड सर्व इथेरियम नोड्स आणि व्हॅलिडेटर्सवर परिणाम करते का?

होय, फुसाका अपग्रेडसाठी एक्झिक्यूशन क्लायंट आणि कन्सेन्सस क्लायंट दोन्हीमध्ये अपडेट्स आवश्यक आहेत. सर्व प्रमुख इथेरियम क्लायंट उच्च प्राधान्य म्हणून चिन्हांकित हार्ड फोर्कला समर्थन देणाऱ्या आवृत्त्या रिलीज करतील. हे प्रकाशन क्लायंट GitHub रेपॉजिटरीज, त्यांचे डिस्कॉर्ड चॅनेल्स (opens in a new tab), EthStaker डिस्कॉर्ड (opens in a new tab) मध्ये कधी उपलब्ध होतील याची माहिती तुम्ही ठेवू शकता, किंवा प्रोटोकॉल अपडेट्ससाठी इथेरियम ब्लॉगची सदस्यता घेऊ शकता. अपग्रेडनंतर इथेरियम नेटवर्कसोबत सिंक्रोनाइझेशन राखण्यासाठी, नोड ऑपरेटरने ते समर्थित क्लायंट आवृत्ती चालवत असल्याची खात्री करणे आवश्यक आहे. लक्षात घ्या की क्लायंट रिलीजची माहिती वेळेनुसार बदलणारी आहे आणि वापरकर्त्यांनी सर्वात सध्याच्या तपशिलांसाठी नवीनतम अपडेट्सचा संदर्भ घ्यावा.

हार्ड फोर्कनंतर ETH चे रूपांतर कसे केले जाऊ शकते?

  • तुमच्या ETH साठी कोणतीही कृती आवश्यक नाही: इथेरियम फुसाका अपग्रेडनंतर, तुमचा ETH रूपांतरित किंवा अपग्रेड करण्याची आवश्यकता नाही. तुमच्या खात्यातील शिल्लक तशीच राहील आणि तुमच्याकडे सध्या असलेला ETH हार्ड फोर्कनंतर त्याच्या सध्याच्या स्वरूपात उपलब्ध राहील.
  • घोटाळ्यांपासून सावध राहा!  जो कोणी तुम्हाला तुमचा ETH "अपग्रेड" करण्यास सांगत आहे तो तुमची फसवणूक करण्याचा प्रयत्न करत आहे. या अपग्रेडसंदर्भात तुम्हाला काहीही करण्याची गरज नाही. तुमच्या मालमत्तेवर कोणताही परिणाम होणार नाही. लक्षात ठेवा, माहिती ठेवणे हे घोटाळ्यांविरुद्ध सर्वोत्तम संरक्षण आहे.

घोटाळे ओळखणे आणि टाळण्याबद्दल अधिक जाणून घ्या

झेब्रांचे काय आहे?

झेब्रा हा फुसाकाचा डेव्हलपर-निवडलेला "मस्कॉट" आहे कारण त्याचे पट्टे PeerDAS च्या स्तंभ-आधारित डेटा-उपलब्धता सॅम्पलिंगचे प्रतिबिंब आहेत, जिथे नोड्स विशिष्ट स्तंभ सबनेटची कस्टडी घेतात आणि ब्लॉब डेटा उपलब्ध आहे की नाही हे तपासण्यासाठी प्रत्येक पीअर्स स्लॉटमधून काही इतर स्तंभ नमुना म्हणून घेतात.

2022 मधील द मर्जने एक्झिक्यूशन आणि कन्सेन्सस लेअर्सच्या एकत्रीकरणाचा संकेत देण्यासाठी एक पांडा (opens in a new tab) त्याचा मस्कॉट म्हणून वापरला. तेव्हापासून, प्रत्येक फोर्कसाठी अनौपचारिकपणे मस्कॉट निवडले गेले आहेत आणि अपग्रेडच्या वेळी क्लायंट लॉगमध्ये ASCII आर्ट म्हणून दिसतात. हा फक्त साजरा करण्याचा एक मजेदार मार्ग आहे.

L2 स्केलिंगसाठी कोणत्या सुधारणा समाविष्ट आहेत?

PeerDAS हे फोर्कचे मुख्य वैशिष्ट्य आहे. हे डेटा उपलब्धता सॅम्पलिंग (DAS) लागू करते जे रोलअपसाठी अधिक स्केलेबिलिटी अनलॉक करते, सैद्धांतिकरित्या ब्लॉब स्पेसला सध्याच्या आकाराच्या 8 पट पर्यंत स्केल करते. ब्लॉब फी मार्केटमध्ये गर्दीला कार्यक्षमतेने प्रतिसाद देण्यासाठी आणि L2s ब्लॉब्सने नोड्सवर लादलेल्या कंप्युट आणि जागेसाठी अर्थपूर्ण फी भरतील याची हमी देण्यासाठी सुधारणा केली जाईल.

BPO फोर्क्स कसे वेगळे आहेत?

ब्लॉब ओन्ली पॅरामीटर फोर्क्स PeerDAS सक्रिय झाल्यानंतर ब्लॉब संख्या (लक्ष्य आणि कमाल दोन्ही) सतत वाढवण्यासाठी एक यंत्रणा प्रदान करतात, पूर्ण समन्वित अपग्रेडची वाट न पाहता. प्रत्येक वाढ फुसाकाला समर्थन देणाऱ्या क्लायंट प्रकाशनांमध्ये पूर्व-कॉन्फिगर करण्यासाठी हार्डकोड केलेली आहे.

एक वापरकर्ता किंवा व्हॅलिडेटर म्हणून, तुम्हाला प्रत्येक 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) चा व्हॅलिडेटर्सवर परिणाम होतो का?

या बदलामुळे तुमचा व्हॅलिडेटर क्लायंट कसा कार्य करतो यात बदल होत नाही, तथापि, तो तुमच्या व्हॅलिडेटर कर्तव्यांच्या भविष्याबद्दल अधिक अंतर्दृष्टी देईल. नवीन वैशिष्ट्यांसह अद्ययावत राहण्यासाठी तुमची मॉनिटरिंग टूलिंग अपडेट केल्याची खात्री करा.

फुसाका नोड्स आणि व्हॅलिडेटर्ससाठी बँडविड्थ आवश्यकतांवर कसा परिणाम करतो?

PeerDAS नोड्स ब्लॉब डेटा कसा प्रसारित करतात यात एक महत्त्वपूर्ण बदल करते. सर्व डेटा 128 सबनेटमध्ये स्तंभ नावाच्या तुकड्यांमध्ये विभागलेला आहे आणि नोड्स त्यापैकी फक्त काहींची सदस्यता घेतात. नोड्सना किती सबनेट स्तंभांची कस्टडी घ्यावी लागेल हे त्यांच्या कॉन्फिगरेशन आणि कनेक्ट केलेल्या व्हॅलिडेटर्सच्या संख्येवर अवलंबून असते. वास्तविक बँडविड्थ आवश्यकता नेटवर्कमध्ये परवानगी असलेल्या ब्लॉब्सच्या संख्येवर आणि नोडच्या प्रकारावर अवलंबून असेल. फुसाका सक्रियतेच्या क्षणी ब्लॉब लक्ष्य पूर्वीसारखेच राहते, परंतु PeerDAS मुळे, नोड ऑपरेटर त्यांच्या ब्लॉब्सच्या डिस्क वापरात आणि नेटवर्क रहदारीत घट पाहू शकतात. BPOs नेटवर्कमध्ये ब्लॉब्सची उच्च संख्या कॉन्फिगर करत असताना, प्रत्येक 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 हल्ल्यांना प्रतिबंधित करते. स्केलिंगचे उद्दिष्ट हे आहे की एकही व्यवहार संपूर्ण ब्लॉक न वापरता अधिक व्यवहार ब्लॉकचेनमध्ये आणणे.

नियमित वापरकर्त्याचे व्यवहार ही मर्यादा गाठण्यापासून खूप दूर आहेत. मोठे आणि गुंतागुंतीचे DeFi ऑपरेशन्स, मोठे स्मार्ट कॉन्ट्रॅक्ट उपयोजन किंवा एकाधिक कॉन्ट्रॅक्ट्सना लक्ष्य करणारे बॅच व्यवहार यासारखे काही एज केसेस या बदलामुळे प्रभावित होऊ शकतात. हे व्यवहार लहान तुकड्यांमध्ये विभागले जावे लागतील किंवा दुसऱ्या मार्गाने ऑप्टिमाइझ करावे लागतील. मर्यादेपर्यंत पोहोचू शकणारे व्यवहार सबमिट करण्यापूर्वी सिम्युलेशन वापरा.

RPC पद्धत eth_call मर्यादित नाही आणि वास्तविक ब्लॉकचेन मर्यादेपेक्षा मोठ्या व्यवहारांचे सिम्युलेशन करण्यास अनुमती देईल. गैरवापर टाळण्यासाठी RPC पद्धतींसाठी वास्तविक मर्यादा क्लायंट ऑपरेटरद्वारे कॉन्फिगर केली जाऊ शकते.

डेव्हलपर्ससाठी CLZ चा अर्थ काय आहे?

सॉलिडिटीसारखे EVM कंपाइलर्स शून्यांची गणना करण्यासाठी नवीन फंक्शन अंतर्गत लागू करतील आणि वापरतील. जर नवीन कॉन्ट्रॅक्ट्स या प्रकारच्या ऑपरेशनवर अवलंबून असतील तर त्यांना गॅस बचतीचा फायदा होऊ शकतो. संभाव्य बचतीवरील दस्तऐवजीकरणासाठी स्मार्ट कॉन्ट्रॅक्ट भाषेची प्रकाशने आणि वैशिष्ट्य घोषणांचे अनुसरण करा.

माझ्या विद्यमान स्मार्ट कॉन्ट्रॅक्ट्ससाठी काही बदल आहेत का?

फुसाकाचा कोणताही थेट परिणाम नाही जो कोणत्याही विद्यमान कॉन्ट्रॅक्ट्सना तोडेल किंवा त्यांचे वर्तन बदलेल. एक्झिक्यूशन लेअरमध्ये सादर केलेले बदल बॅकवर्ड कंपॅटिबिलिटीसह केले जातात, तथापि, नेहमी एज केसेस आणि संभाव्य परिणामांवर लक्ष ठेवा.

ModExp प्रीकॉम्पाइलच्या वाढलेल्या खर्चासह (opens in a new tab), त्यावर अवलंबून असलेले कॉन्ट्रॅक्ट्स एक्झिक्यूशनसाठी अधिक गॅस वापरतील. जर तुमचा कॉन्ट्रॅक्ट यावर मोठ्या प्रमाणावर अवलंबून असेल आणि वापरकर्त्यांसाठी अधिक महाग होत असेल, तर तो कसा वापरला जातो याचा पुनर्विचार करा.

तुमचे कॉन्ट्रॅक्ट्स कार्यान्वित करणारे व्यवहार समान आकारापर्यंत पोहोचू शकत असल्यास नवीन 16.7 दशलक्ष मर्यादेचा (opens in a new tab) विचार करा.

पुढील वाचन

पृष्ठ अखेरचे अद्यतन: २३ फेब्रुवारी, २०२६

architr4a (opens in a new tab)
JoeChenJJ (opens in a new tab)
corwintinesc (opens in a new tab)
+5

हा लेख उपयुक्त होता का?