---
title: "फुसाका 🦓"
metaTitle: फुलू-ओसाका (फुसाका)
description: फुसाका प्रोटोकॉल अपग्रेडबद्दल जाणून घ्या
lang: mr
template: upgrade
authors: ["निक्सो", "मारिओ हॅवेल"]
---
**इथेरियमचे अत्यंत अपेक्षित फुसाका अपग्रेड 3 डिसेंबर 2025 रोजी लाइव्ह झाले**
फुसाका नेटवर्क अपग्रेड [पेक्ट्रा](/roadmap/pectra/) नंतर येते आणि प्रत्येक [इथेरियम](/) वापरकर्ता आणि विकासकासाठी अधिक नवीन वैशिष्ट्ये आणते आणि अनुभव सुधारते. या नावात अंमलबजावणी स्तर अपग्रेड ओसाका आणि फुलू ताऱ्याच्या नावावरून ठेवलेली सहमती स्तर आवृत्ती यांचा समावेश आहे. इथेरियमच्या दोन्ही भागांना एक अपग्रेड मिळते जे इथेरियम स्केलिंग, सुरक्षा आणि वापरकर्ता अनुभवाला भविष्याकडे ढकलते.
फुसाका अपग्रेड हे इथेरियमच्या दीर्घकालीन विकास उद्दिष्टांमधील केवळ एक पाऊल आहे. [प्रोटोकॉल रोडमॅप](/roadmap/) आणि [मागील अपग्रेड्स](/ethereum-forks/) बद्दल अधिक जाणून घ्या.
## फुसाकामधील सुधारणा {#improvements-in-fusaka}
### ब्लॉब्स स्केल करणे {#scale-blobs}
#### PeerDAS {#peerdas}
हे फुसाका फोर्कचे _प्रमुख आकर्षण_ आहे, या अपग्रेडमध्ये जोडलेले मुख्य वैशिष्ट्य. स्तर २ (l2) सध्या त्यांचा डेटा इथेरियमवर ब्लॉब्समध्ये पोस्ट करतात, जो विशेषतः स्तर २ (l2) साठी तयार केलेला अल्पकालिक डेटा प्रकार आहे. फुसाका-पूर्व, डेटा अस्तित्वात असल्याची खात्री करण्यासाठी प्रत्येक पूर्ण नोडला प्रत्येक ब्लॉब संग्रहित करावा लागतो. ब्लॉब प्रक्रिया क्षमता वाढत असताना, हा सर्व डेटा डाउनलोड करणे संसाधनांच्या दृष्टीने अत्यंत कठीण होते.
[डेटा उपलब्धता सॅम्पलिंग (DAS)](https://notes.ethereum.org/@fradamt/das-fork-choice) सह, सर्व ब्लॉब डेटा संग्रहित करण्याऐवजी, प्रत्येक नोड ब्लॉब डेटाच्या उपसंचासाठी जबाबदार असेल. नेटवर्कमधील नोड्सवर ब्लॉब्स समान रीतीने यादृच्छिकपणे वितरीत केले जातात आणि प्रत्येक पूर्ण नोडकडे डेटाचा केवळ 1/8 भाग असतो, ज्यामुळे सैद्धांतिकदृष्ट्या 8x पर्यंत स्केल करणे शक्य होते. डेटाची उपलब्धता सुनिश्चित करण्यासाठी, डेटाचा कोणताही भाग संपूर्ण डेटाच्या कोणत्याही विद्यमान 50% वरून अशा पद्धतींनी पुनर्रचित केला जाऊ शकतो ज्यामुळे चुकीच्या किंवा गहाळ डेटाची संभाव्यता क्रिप्टोग्राफिकदृष्ट्या नगण्य पातळीवर (~1020 पैकी एक ते 1024 पैकी एक) कमी होते.
हे नोड्ससाठी हार्डवेअर आणि बँडविड्थ आवश्यकता योग्य ठेवते आणि ब्लॉब स्केलिंग सक्षम करते ज्यामुळे स्तर २ (l2) साठी कमी शुल्कासह अधिक स्केल मिळते.
[PeerDAS बद्दल अधिक जाणून घ्या](/roadmap/fusaka/peerdas/)
**संसाधने**:
- [EIP-7594 तांत्रिक तपशील](https://eips.ethereum.org/EIPS/eip-7594)
- [PeerDAS वर DappLion: आज इथेरियम स्केल करणे | ETHSofia 2024](https://youtu.be/bONWd1x2TjQ?t=328)
- [शैक्षणिक: इथेरियमच्या PeerDAS चे दस्तऐवजीकरण (PDF)](https://eprint.iacr.org/2024/1362.pdf)
#### केवळ-ब्लॉब-पॅरामीटर फोर्क्स {#blob-parameter-only-forks}
स्तर २ (l2) इथेरियम स्केल करतात - जसे त्यांचे नेटवर्क वाढते, त्यांना इथेरियमवर अधिक डेटा पोस्ट करण्याची आवश्यकता असते. याचा अर्थ असा की जसजसा वेळ जाईल तसतसे इथेरियमला त्यांच्यासाठी उपलब्ध असलेल्या ब्लॉब्सची संख्या वाढवावी लागेल. जरी PeerDAS ब्लॉब डेटा स्केल करण्यास सक्षम करत असले तरी, ते हळूहळू आणि सुरक्षितपणे करणे आवश्यक आहे.
कारण इथेरियम हा हजारो स्वतंत्र नोड्सवर चालणारा कोड आहे ज्यांना समान नियमांवर एकमत आवश्यक आहे, आपण वेबसाइट अपडेट प्रस्थापित करण्यासारखे ब्लॉब संख्या वाढवण्यासारखे बदल सहजपणे करू शकत नाही. कोणताही नियम बदल हा एक समन्वित अपग्रेड असणे आवश्यक आहे जिथे प्रत्येक नोड, क्लायंट आणि प्रमाणक सॉफ्टवेअर एकाच पूर्वनिर्धारित ब्लॉकच्या आधी अपग्रेड होते.
या समन्वित अपग्रेड्समध्ये साधारणपणे बरेच बदल समाविष्ट असतात, त्यांना बऱ्याच चाचण्यांची आवश्यकता असते आणि त्यासाठी वेळ लागतो. बदलत्या स्तर २ (l2) ब्लॉब गरजांशी जलद जुळवून घेण्यासाठी, केवळ ब्लॉब पॅरामीटर फोर्क्स त्या अपग्रेड वेळापत्रकाची वाट न पाहता ब्लॉब्स वाढवण्याची यंत्रणा सादर करतात.
केवळ ब्लॉब पॅरामीटर फोर्क्स क्लायंट्सद्वारे सेट केले जाऊ शकतात, जसे की गॅस मर्यादा सारख्या इतर कॉन्फिगरेशनप्रमाणे. प्रमुख इथेरियम अपग्रेड्सच्या दरम्यान, क्लायंट्स `target` आणि `max` ब्लॉब्स उदा. 9 आणि 12 पर्यंत वाढवण्यास सहमत होऊ शकतात आणि नंतर नोड ऑपरेटर त्या लहान फोर्कमध्ये भाग घेण्यासाठी अपडेट करतील. हे केवळ ब्लॉब पॅरामीटर फोर्क्स कधीही कॉन्फिगर केले जाऊ शकतात.
जेव्हा डेंकुन अपग्रेडमध्ये नेटवर्कमध्ये पहिल्यांदा ब्लॉब्स जोडले गेले, तेव्हा लक्ष्य 3 होते. ते पेक्ट्रामध्ये 6 पर्यंत वाढवले गेले आणि, फुसाकानंतर, आता ते या प्रमुख नेटवर्क अपग्रेड्सपासून स्वतंत्रपणे शाश्वत दराने वाढवले जाऊ शकते.
आलेख स्रोत: [इथेरियम ब्लॉब्स - @hildobby, Dune Analytics](https://dune.com/hildobby/blobs)
**संसाधने**: [EIP-7892 तांत्रिक तपशील](https://eips.ethereum.org/EIPS/eip-7892)
#### अंमलबजावणी खर्चाद्वारे मर्यादित ब्लॉब पायाभूत शुल्क {#blob-base-fee-bounded-by-execution-costs}
स्तर २ (l2) जेव्हा डेटा पोस्ट करतात तेव्हा दोन बिले भरतात: ब्लॉब शुल्क आणि ते ब्लॉब्स सत्यापित करण्यासाठी आवश्यक असलेला अंमलबजावणी गॅस. जर अंमलबजावणी गॅसचे वर्चस्व असेल, तर ब्लॉब शुल्क लिलाव 1 Wei पर्यंत खाली येऊ शकतो आणि किंमत संकेत असणे थांबवू शकतो.
EIP-7918 प्रत्येक ब्लॉबखाली एक प्रमाणबद्ध राखीव किंमत निश्चित करते. जेव्हा राखीव किंमत नाममात्र ब्लॉब पायाभूत शुल्कापेक्षा जास्त असते, तेव्हा शुल्क समायोजन अल्गोरिदम ब्लॉकला लक्ष्यापेक्षा जास्त मानतो आणि शुल्क खाली ढकलणे थांबवतो आणि ते सामान्यपणे वाढू देतो. परिणामी:
- ब्लॉब शुल्क बाजार नेहमी गर्दीला प्रतिसाद देतो
- स्तर २ (l2) नोड्सवर लादलेल्या संगणनाचा किमान एक अर्थपूर्ण भाग भरतात
- अंमलबजावणी स्तरावरील (EL) पायाभूत शुल्क वाढीमुळे ब्लॉब शुल्क यापुढे 1 Wei वर अडकून राहू शकत नाही
**संसाधने**:
- [EIP-7918 तांत्रिक तपशील](https://eips.ethereum.org/EIPS/eip-7918)
- [स्टोरीबुक स्पष्टीकरण](https://notes.ethereum.org/@anderselowsson/AIG)
### स्तर १ (l1) स्केल करणे {#scale-l1}
#### इतिहास समाप्ती आणि सोप्या पावत्या {#history-expiry}
जुलै 2025 मध्ये, इथेरियम अंमलबजावणी क्लायंट्सनी [आंशिक इतिहास समाप्तीला समर्थन देण्यास सुरुवात केली](https://blog.ethereum.org/2025/07/08/partial-history-exp). इथेरियम वाढत असताना नोड ऑपरेटर्सना आवश्यक असलेली डिस्क स्पेस कमी करण्यासाठी याने [द मर्ज](https://ethereum.org/roadmap/merge/) पेक्षा जुना इतिहास वगळला.
हे EIP "कोअर EIPs" व्यतिरिक्त एका विभागात आहे कारण फोर्क प्रत्यक्षात कोणतेही बदल लागू करत नाही - ही एक सूचना आहे की क्लायंट टीम्सनी फुसाका अपग्रेडपर्यंत इतिहास समाप्तीला समर्थन दिले पाहिजे. व्यावहारिकदृष्ट्या, क्लायंट हे कधीही लागू करू शकतात परंतु ते अपग्रेडमध्ये जोडल्याने ते त्यांच्या करण्याच्या कामांच्या यादीत ठोसपणे आले आणि त्यांना या वैशिष्ट्यासह फुसाका बदलांची चाचणी घेण्यास सक्षम केले.
**संसाधने**: [EIP-7642 तांत्रिक तपशील](https://eips.ethereum.org/EIPS/eip-7642)
#### MODEXP साठी उच्च मर्यादा सेट करणे {#set-upper-bounds-for-modexp}
आतापर्यंत, MODEXP प्रीकंपाइलने अक्षरशः कोणत्याही आकाराचे क्रमांक स्वीकारले. त्यामुळे त्याची चाचणी करणे कठीण, गैरवापर करणे सोपे आणि क्लायंट स्थिरतेसाठी धोकादायक बनले. EIP-7823 एक स्पष्ट मर्यादा घालते: प्रत्येक इनपुट क्रमांक जास्तीत जास्त 8192 बिट्स (1024 बाइट्स) लांब असू शकतो. यापेक्षा मोठे काहीही नाकारले जाते, व्यवहाराचा गॅस जळतो आणि कोणतेही स्थिती बदल होत नाहीत. गॅस मर्यादा नियोजन आणि सुरक्षा पुनरावलोकने गुंतागुंतीची करणारी अत्यंत प्रकरणे काढून टाकताना ते वास्तविक जगाच्या गरजा अतिशय आरामात पूर्ण करते. हा बदल वापरकर्ता किंवा विकासक अनुभवावर परिणाम न करता अधिक सुरक्षा आणि DoS संरक्षण प्रदान करतो.
**संसाधने**: [EIP-7823 तांत्रिक तपशील](https://eips.ethereum.org/EIPS/eip-7823)
#### व्यवहार गॅस मर्यादा कॅप {#transaction-gas-limit-cap}
EIP-[7825](https://eips.ethereum.org/EIPS/eip-7825) प्रति व्यवहार 16,777,216 (2^24) गॅसची मर्यादा जोडते. आम्ही ब्लॉक गॅस मर्यादा वाढवत असताना कोणत्याही एका व्यवहाराच्या सर्वात वाईट परिस्थितीतील खर्चाला मर्यादित करून हे सक्रिय DoS कठीणीकरण आहे. गॅस मर्यादा वाढवून स्केलिंग हाताळण्यासाठी हे प्रमाणीकरण आणि प्रसार मॉडेल करणे सोपे करते.
नेमके 2^24 गॅस का? हे आजच्या गॅस मर्यादेपेक्षा आरामात लहान आहे, वास्तविक कॉन्ट्रॅक्ट प्रस्थापित करण्यासाठी आणि जड प्रीकंपाइल्ससाठी पुरेसे मोठे आहे आणि 2 ची घातांक असल्याने क्लायंट्समध्ये लागू करणे सोपे होते. हा नवीन कमाल व्यवहार आकार पेक्ट्रा-पूर्व सरासरी ब्लॉक आकारासारखाच आहे, ज्यामुळे तो इथेरियमवरील कोणत्याही ऑपरेशनसाठी एक वाजवी मर्यादा बनतो.
**संसाधने**: [EIP-7825 तांत्रिक तपशील](https://eips.ethereum.org/EIPS/eip-7825)
#### `MODEXP` गॅस खर्चात वाढ {#modexp-gas-cost-increase}
MODEXP हे एक प्रीकंपाइल अंगभूत कार्य आहे जे मॉड्यूलर घातांक मोजते, जो RSA स्वाक्षरी पडताळणी आणि पुरावा प्रणालींमध्ये वापरला जाणारा मोठ्या-संख्येच्या गणिताचा एक प्रकार आहे. हे कॉन्ट्रॅक्ट्सना स्वतः लागू न करता ही गणना थेट चालविण्यास अनुमती देते.
विकासक आणि क्लायंट टीम्सनी ब्लॉक गॅस मर्यादा वाढवण्यात MODEXP ला एक मोठा अडथळा म्हणून ओळखले कारण सध्याची गॅस किंमत अनेकदा विशिष्ट इनपुट्सना किती संगणकीय शक्ती आवश्यक आहे याचा कमी अंदाज लावते. याचा अर्थ MODEXP वापरणारा एक व्यवहार संपूर्ण ब्लॉकवर प्रक्रिया करण्यासाठी आवश्यक असलेला बहुतांश वेळ घेऊ शकतो, ज्यामुळे नेटवर्क धीमे होते.
हे EIP वास्तविक संगणकीय खर्चाशी जुळण्यासाठी किंमतीत बदल करते:
- किमान शुल्क 200 वरून 500 गॅसपर्यंत वाढवणे आणि सामान्य खर्च गणनेवरील EIP-2565 मधील एक-तृतीयांश सवलत काढून टाकणे
- जेव्हा घातांक इनपुट खूप लांब असतो तेव्हा खर्च अधिक वेगाने वाढवणे. जर घातांक (तुम्ही दुसरा युक्तिवाद म्हणून पास केलेला "पॉवर" क्रमांक) 32 बाइट्स / 256 बिट्सपेक्षा लांब असेल, तर प्रत्येक अतिरिक्त बाइटसाठी गॅस शुल्क खूप वेगाने वाढते
- मोठा बेस किंवा मॉड्युलससाठी अतिरिक्त शुल्क आकारणे. इतर दोन क्रमांक (बेस आणि मॉड्युलस) किमान 32 बाइट्स असल्याचे गृहीत धरले जाते - जर यापैकी एक मोठा असेल, तर त्याच्या आकाराच्या प्रमाणात खर्च वाढतो
खर्चाला वास्तविक प्रक्रियेच्या वेळेशी अधिक चांगल्या प्रकारे जुळवून, MODEXP यापुढे ब्लॉक प्रमाणित करण्यासाठी खूप वेळ घेण्यास कारणीभूत ठरू शकत नाही. भविष्यात इथेरियमची ब्लॉक गॅस मर्यादा वाढवणे सुरक्षित करण्याच्या उद्देशाने केलेल्या अनेक बदलांपैकी हा एक बदल आहे.
**संसाधने**: [EIP-7883 तांत्रिक तपशील](https://eips.ethereum.org/EIPS/eip-7883)
#### RLP अंमलबजावणी ब्लॉक आकार मर्यादा {#rlp-execution-block-size-limit}
हे ब्लॉक किती मोठा असू शकतो यावर एक मर्यादा तयार करते - ही नेटवर्कवर काय _पाठवले_ जाते यावरील मर्यादा आहे आणि ती गॅस मर्यादेपेक्षा वेगळी आहे, जी ब्लॉकमधील _काम_ मर्यादित करते. ब्लॉक आकाराची मर्यादा 10 MiB आहे, ज्यामध्ये सहमती डेटासाठी एक लहान मंजुरी (2 MiB) राखीव आहे जेणेकरून सर्वकाही व्यवस्थित बसेल आणि प्रसारित होईल. जर एखादा ब्लॉक त्यापेक्षा मोठा दिसला, तर क्लायंट्स तो नाकारतात.
याची आवश्यकता आहे कारण खूप मोठ्या ब्लॉक्सना नेटवर्कवर पसरण्यासाठी आणि सत्यापित करण्यासाठी जास्त वेळ लागतो आणि ते एकमत समस्या निर्माण करू शकतात किंवा DoS वेक्टर म्हणून गैरवापर केले जाऊ शकतात. तसेच, सहमती स्तराचे गॉसिप आधीच ~10 MiB पेक्षा मोठे ब्लॉक्स पुढे पाठवत नाही, त्यामुळे अंमलबजावणी स्तराला त्या मर्यादेशी संरेखित केल्याने "काहींनी पाहिले, इतरांनी वगळले" अशा विचित्र परिस्थिती टाळता येतात.
तपशील: ही [RLP](/developers/docs/data-structures-and-encoding/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 तांत्रिक तपशील](https://eips.ethereum.org/EIPS/eip-7934)
#### डीफॉल्ट गॅस मर्यादा 60 दशलक्ष वर सेट करणे {#set-default-gas-limit-to-60-million}
फेब्रुवारी 2025 मध्ये गॅस मर्यादा 30M वरून 36M (आणि त्यानंतर 45M) पर्यंत वाढवण्यापूर्वी, हे मूल्य द मर्ज (सप्टेंबर 2022) पासून बदलले नव्हते. हे EIP सातत्यपूर्ण स्केलिंगला प्राधान्य देण्याचे उद्दिष्ट ठेवते.
EIP-7935 फुसाकासाठी आजच्या 45M च्या वर डीफॉल्ट गॅस-मर्यादा वाढवण्यासाठी EL क्लायंट टीम्सशी समन्वय साधते. हे एक माहितीपूर्ण EIP आहे, परंतु ते स्पष्टपणे क्लायंट्सना डेव्हनेटवर उच्च मर्यादांची चाचणी घेण्यास, सुरक्षित मूल्यावर एकत्र येण्यास आणि त्यांच्या फुसाका रिलीझमध्ये तो क्रमांक पाठविण्यास सांगते.
डेव्हनेट नियोजन ~60M ताण (सिंथेटिक लोडसह पूर्ण ब्लॉक्स) आणि पुनरावृत्ती वाढीचे लक्ष्य ठेवते; संशोधन सांगते की सर्वात वाईट परिस्थितीतील ब्लॉक-आकार पॅथॉलॉजीज ~150M च्या खाली बांधल्या जाऊ नयेत. रोलआउट व्यवहार गॅस-मर्यादा कॅप (EIP-7825) सह जोडले जावे जेणेकरून मर्यादा वाढल्यामुळे कोणताही एक व्यवहार वर्चस्व गाजवू शकणार नाही.
**संसाधने**: [EIP-7935 तांत्रिक तपशील](https://eips.ethereum.org/EIPS/eip-7935)
### UX सुधारा {#improve-ux}
#### पूर्वनिर्धारित प्रस्तावक लुकअहेड {#deterministic-proposer-lookahead}
EIP-7917 सह, बीकन साखळी पुढील पर्वासाठी आगामी ब्लॉक प्रस्तावकांबद्दल जागरूक होईल. कोणते प्रमाणक भविष्यातील ब्लॉक्स प्रस्तावित करतील यावर पूर्वनिर्धारित दृष्टिकोन असण्यामुळे [पूर्वपुष्टीकरणे (preconfirmations)](https://ethresear.ch/t/based-preconfirmations/17353) सक्षम होऊ शकतात - आगामी प्रस्तावकासोबतची एक बांधिलकी जी हमी देते की वापरकर्त्याचा व्यवहार वास्तविक ब्लॉकची वाट न पाहता त्यांच्या ब्लॉकमध्ये समाविष्ट केला जाईल.
या वैशिष्ट्याचा क्लायंट अंमलबजावणी आणि नेटवर्कच्या सुरक्षिततेला फायदा होतो कारण ते अशा अत्यंत परिस्थितींना प्रतिबंधित करते जिथे प्रमाणक प्रस्तावक वेळापत्रकात फेरफार करू शकतात. लुकअहेड अंमलबजावणीची गुंतागुंत कमी करण्यास देखील अनुमती देते.
**संसाधने**: [EIP-7917 तांत्रिक तपशील](https://eips.ethereum.org/EIPS/eip-7917)
#### काउंट लीडिंग झिरोज (CLZ) ऑपकोड {#count-leading-zeros-opcode}
हे वैशिष्ट्य एक लहान EVM सूचना जोडते, **काउंट लीडिंग झिरोज (CLZ)**. EVM मधील जवळजवळ सर्वकाही 256-बिट मूल्य म्हणून दर्शविले जाते—हा नवीन ऑपकोड समोर किती शून्य बिट्स आहेत हे परत करतो. हे अनेक सूचना संच आर्किटेक्चरमधील एक सामान्य वैशिष्ट्य आहे कारण ते अधिक कार्यक्षम अंकगणितीय ऑपरेशन्स सक्षम करते. व्यवहारात हे आजच्या हाताने-रोल केलेल्या बिट स्कॅन्सना एका चरणात संकुचित करते, त्यामुळे पहिला सेट बिट शोधणे, बाइट्स स्कॅन करणे किंवा बिटफील्ड्स पार्स करणे सोपे आणि स्वस्त होते. ऑपकोड कमी, निश्चित-खर्चाचा आहे आणि मूलभूत जोडणीच्या बरोबरीने बेंचमार्क केला गेला आहे, जो बाइटकोड कमी करतो आणि त्याच कामासाठी गॅस वाचवतो.
**संसाधने**: [EIP-7939 तांत्रिक तपशील](https://eips.ethereum.org/EIPS/eip-7939)
#### secp256r1 Curve समर्थनासाठी प्रीकंपाइल {#secp256r1-precompile}
निश्चित पत्ता `0x100` वर अंगभूत, पासकी-शैलीतील secp256r1 (P-256) स्वाक्षरी तपासक सादर करते, जे अनेक स्तर २ (l2) द्वारे आधीच स्वीकारलेले समान कॉल स्वरूप वापरते आणि अत्यंत प्रकरणे निश्चित करते, जेणेकरून त्या वातावरणासाठी लिहिलेले कॉन्ट्रॅक्ट्स बदलांशिवाय स्तर १ (l1) वर कार्य करतात.
UX अपग्रेड! वापरकर्त्यांसाठी, हे डिव्हाइस-नेटिव्ह स्वाक्षरी करणे आणि पासकी अनलॉक करते. वॉलेट्स थेट Apple Secure Enclave, Android कीस्टोअर, हार्डवेअर सुरक्षा मॉड्यूल्स (HSMs), आणि FIDO2/WebAuthn मध्ये टॅप करू शकतात - कोणतेही बीज वाक्य नाही, अधिक सुलभ ऑनबोर्डिंग, आणि आधुनिक ॲप्ससारखे वाटणारे मल्टी-फॅक्टर प्रवाह. याचा परिणाम चांगला UX, सोपी पुनर्प्राप्ती आणि अब्जावधी उपकरणे आधीच जे करतात त्याच्याशी जुळणाऱ्या खाते अमूर्तीकरण पॅटर्नमध्ये होतो.
विकासकांसाठी, हे 160-बाइट इनपुट घेते आणि 32-बाइट आउटपुट परत करते, ज्यामुळे विद्यमान लायब्ररी आणि स्तर २ (l2) कॉन्ट्रॅक्ट्स पोर्ट करणे सोपे होते. तांत्रिकदृष्ट्या, वैध कॉलर्सना न मोडता अवघड अत्यंत प्रकरणे दूर करण्यासाठी यात पॉइंट-ॲट-इन्फिनिटी आणि मॉड्यूलर-तुलना तपासण्या समाविष्ट आहेत.
**संसाधने**:
- [EIP-7951 तांत्रिक तपशील](https://eips.ethereum.org/EIPS/eip-7951)
- [RIP-7212 बद्दल अधिक](https://www.alchemy.com/blog/what-is-rip-7212) _(लक्षात घ्या की EIP-7951 ने RIP-7212 ची जागा घेतली आहे)_
### मेटा {#meta}
#### `eth_config` जेसॉन-आरपीसी पद्धत {#eth-config}
हा एक जेसॉन-आरपीसी कॉल आहे जो तुम्हाला तुमच्या नोडला विचारण्याची परवानगी देतो की तुम्ही कोणती फोर्क सेटिंग्ज चालवत आहात. हे तीन स्नॅपशॉट्स परत करते: `current`, `next`, आणि `last` जेणेकरून प्रमाणक आणि मॉनिटरिंग टूल्स सत्यापित करू शकतील की क्लायंट्स आगामी फोर्कसाठी तयार आहेत.
व्यावहारिकदृष्ट्या बोलायचे झाल्यास, 2025 च्या सुरुवातीला होल्स्की टेस्टनेटवर पेक्ट्रा फोर्क किरकोळ चुकीच्या कॉन्फिगरेशनसह लाइव्ह झाला तेव्हा आढळलेल्या त्रुटीचे निराकरण करण्यासाठी हे आहे, ज्यामुळे नॉन-फायनलायझिंग स्थिती निर्माण झाली होती. हे चाचणी टीम्स आणि विकासकांना हे सुनिश्चित करण्यात मदत करते की डेव्हनेटवरून टेस्टनेटवर आणि टेस्टनेटवरून मुख्यनेटवर जाताना प्रमुख फोर्क्स अपेक्षेप्रमाणे वागतील.
स्नॅपशॉट्समध्ये समाविष्ट आहे: `chainId`, `forkId`, नियोजित फोर्क सक्रियकरण वेळ, कोणते प्रीकंपाइल्स सक्रिय आहेत, प्रीकंपाइल पत्ते, सिस्टम कॉन्ट्रॅक्ट अवलंबित्व आणि फोर्कचे ब्लॉब वेळापत्रक.
हे EIP "कोअर EIPs" व्यतिरिक्त एका विभागात आहे कारण फोर्क प्रत्यक्षात कोणतेही बदल लागू करत नाही - ही एक सूचना आहे की क्लायंट टीम्सनी फुसाका अपग्रेडपर्यंत ही जेसॉन-आरपीसी पद्धत लागू केली पाहिजे.
**संसाधने**: [EIP-7910 तांत्रिक तपशील](https://eips.ethereum.org/EIPS/eip-7910)
## वारंवार विचारले जाणारे प्रश्न (FAQ) {#faq}
### या अपग्रेडचा सर्व इथेरियम नोड्स आणि प्रमाणकांवर परिणाम होतो का? {#does-this-upgrade-affect-all-ethereum-nodes-and-validators}
होय, फुसाका अपग्रेडसाठी [अंमलबजावणी क्लायंट्स आणि सहमती क्लायंट्स](/developers/docs/nodes-and-clients/) दोन्हीमध्ये अपडेट्स आवश्यक आहेत. सर्व मुख्य इथेरियम क्लायंट्स उच्च प्राधान्य म्हणून चिन्हांकित हार्ड फोर्कला समर्थन देणाऱ्या आवृत्त्या जारी करतील. हे रिलीझ कधी उपलब्ध होतील याची माहिती तुम्ही क्लायंट GitHub रिपॉझिटरीज, त्यांचे [डिस्कॉर्ड् चॅनेल्स](https://ethstaker.org/support), [EthStaker डिस्कॉर्ड्](https://dsc.gg/ethstaker) मध्ये किंवा प्रोटोकॉल अपडेट्ससाठी इथेरियम ब्लॉगची सदस्यता घेऊन मिळवू शकता. अपग्रेडनंतर इथेरियम नेटवर्कसह सिंक्रोनायझेशन राखण्यासाठी, नोड ऑपरेटर्सनी हे सुनिश्चित केले पाहिजे की ते समर्थित क्लायंट आवृत्ती चालवत आहेत. लक्षात घ्या की क्लायंट रिलीझबद्दलची माहिती वेळ-संवेदनशील आहे आणि वापरकर्त्यांनी सर्वात वर्तमान तपशीलांसाठी नवीनतम अपडेट्सचा संदर्भ घ्यावा.
### हार्ड फोर्कनंतर ETH कसे रूपांतरित केले जाऊ शकते? {#how-can-eth-be-converted-after-the-hardfork}
- **तुमच्या ETH साठी कोणतीही कृती आवश्यक नाही**: इथेरियम फुसाका अपग्रेडनंतर, तुमचे ETH रूपांतरित किंवा अपग्रेड करण्याची आवश्यकता नाही. तुमच्या खात्यातील शिल्लक समान राहील आणि तुम्ही सध्या धारण केलेले ETH हार्ड फोर्कनंतर त्याच्या विद्यमान स्वरूपात प्रवेशयोग्य राहील.
- **घोटाळ्यांपासून सावध रहा!** **तुम्हाला तुमचे ETH "अपग्रेड" करण्याची सूचना देणारी कोणतीही व्यक्ती तुमची फसवणूक करण्याचा प्रयत्न करत आहे.** या अपग्रेडच्या संदर्भात तुम्हाला काहीही करण्याची आवश्यकता नाही. तुमची मालमत्ता पूर्णपणे अप्रभावित राहील. लक्षात ठेवा, माहितीपूर्ण राहणे हा घोटाळ्यांविरूद्ध सर्वोत्तम बचाव आहे.
[घोटाळे ओळखणे आणि टाळणे याबद्दल अधिक](/security/)
### झेब्राचे काय? {#whats-with-the-zebras}
झेब्रा हा फुसाकाचा विकासकांनी निवडलेला "शुभंकर" आहे कारण त्याचे पट्टे PeerDAS च्या कॉलम-आधारित डेटा-उपलब्धता सॅम्पलिंग (DAS) प्रतिबिंबित करतात, जिथे नोड्स विशिष्ट कॉलम सबनेट्सची कस्टडी घेतात आणि ब्लॉब डेटा उपलब्ध आहे हे तपासण्यासाठी प्रत्येक पीअर्स स्लॉटमधून काही इतर कॉलम्सचे नमुने घेतात.
2022 मधील द मर्जने अंमलबजावणी आणि सहमती स्तरांच्या जोडणीचे संकेत देण्यासाठी [पांडाचा वापर](https://x.com/hwwonx/status/1431970802040127498) शुभंकर म्हणून केला होता. तेव्हापासून, प्रत्येक फोर्कसाठी अनौपचारिकपणे शुभंकर निवडले गेले आहेत आणि अपग्रेडच्या वेळी क्लायंट लॉगमध्ये ASCII कला म्हणून दिसतात. हा साजरा करण्याचा फक्त एक मजेदार मार्ग आहे.
### स्तर २ (l2) स्केलिंगसाठी कोणत्या सुधारणा समाविष्ट आहेत? {#what-improvements-are-included-for-l2-scaling}
[PeerDAS](/roadmap/fusaka/peerdas) हे फोर्कचे मुख्य वैशिष्ट्य आहे. हे डेटा उपलब्धता सॅम्पलिंग (DAS) लागू करते जे रोलअप्ससाठी अधिक स्केलेबिलिटी अनलॉक करते, सैद्धांतिकदृष्ट्या ब्लॉब स्पेस सध्याच्या आकाराच्या 8 पट वाढवते. गर्दीला कार्यक्षमतेने प्रतिसाद देण्यासाठी आणि ब्लॉब्स नोड्सवर लादत असलेल्या संगणन आणि जागेसाठी स्तर २ (l2) अर्थपूर्ण शुल्क भरतील याची हमी देण्यासाठी ब्लॉब शुल्क बाजार देखील सुधारला जाईल.
### BPO फोर्क्स कसे वेगळे आहेत? {#how-are-bpo-forks-different}
केवळ ब्लॉब पॅरामीटर (BPO) फोर्क्स PeerDAS सक्रिय झाल्यानंतर, पूर्ण समन्वित अपग्रेडची वाट न पाहता ब्लॉब संख्या (लक्ष्य आणि कमाल दोन्ही) सतत वाढवण्याची यंत्रणा प्रदान करतात. प्रत्येक वाढ फुसाकाला समर्थन देणाऱ्या क्लायंट रिलीझमध्ये पूर्व-कॉन्फिगर करण्यासाठी हार्डकोड केलेली असते.
वापरकर्ता किंवा प्रमाणक म्हणून, तुम्हाला प्रत्येक BPO साठी तुमचे क्लायंट्स अपडेट करण्याची आवश्यकता नाही आणि फक्त फुसाका सारख्या प्रमुख हार्ड फोर्क्सचे अनुसरण करण्याची खात्री करा. ही पूर्वीसारखीच प्रथा आहे, यासाठी कोणत्याही विशेष कृतींची आवश्यकता नाही. तरीही अपग्रेड्स आणि BPOs च्या आसपास तुमच्या क्लायंट्सचे निरीक्षण करण्याची आणि प्रमुख रिलीझच्या दरम्यानही त्यांना अपडेट ठेवण्याची शिफारस केली जाते कारण हार्ड फोर्कनंतर निराकरणे किंवा ऑप्टिमायझेशन्स येऊ शकतात.
### BPO वेळापत्रक काय आहे? {#what-is-the-bpo-schedule}
BPO अपडेट्सचे अचूक वेळापत्रक फुसाका रिलीझसह निश्चित केले जाईल. [प्रोटोकॉल घोषणा](https://blog.ethereum.org/category/protocol) आणि तुमच्या क्लायंट्सच्या रिलीझ नोट्सचे अनुसरण करा.
ते कसे दिसू शकते याचे उदाहरण:
- फुसाकापूर्वी: लक्ष्य 6, कमाल 9
- फुसाका सक्रियकरणावर: लक्ष्य 6, कमाल 9
- BPO1, फुसाका सक्रियकरणानंतर काही आठवड्यांनी: लक्ष्य 10, कमाल 15, दोन तृतीयांशने वाढ
- BPO2, BPO1 नंतर काही आठवड्यांनी: लक्ष्य 14, कमाल 21
### यामुळे इथेरियम (स्तर १ (l1)) वरील शुल्क कमी होईल का? {#will-this-lower-gas}
हे अपग्रेड स्तर १ (l1) वरील गॅस शुल्क कमी करत नाही, किमान थेट तरी नाही. मुख्य लक्ष रोलअप डेटासाठी अधिक ब्लॉब स्पेसवर आहे, त्यामुळे स्तर २ (l2) वरील शुल्क कमी होते. याचे स्तर १ (l1) शुल्क बाजारावर काही दुष्परिणाम होऊ शकतात परंतु कोणताही महत्त्वपूर्ण बदल अपेक्षित नाही.
### स्टेकर म्हणून, मला अपग्रेडसाठी काय करावे लागेल? {#as-a-staker-what-do-i-need-to-do-for-the-upgrade}
प्रत्येक नेटवर्क अपग्रेडप्रमाणे, तुमचे क्लायंट्स फुसाका समर्थनासह चिन्हांकित केलेल्या नवीनतम आवृत्त्यांमध्ये अपडेट करण्याची खात्री करा. रिलीझबद्दल माहिती मिळवण्यासाठी मेलिंग लिस्ट आणि [EF ब्लॉगवरील प्रोटोकॉल घोषणांमधील](https://blog.ethereum.org/category/protocol) अपडेट्सचे अनुसरण करा.
मुख्यनेटवर फुसाका सक्रिय होण्यापूर्वी तुमचे सेटअप प्रमाणित करण्यासाठी, तुम्ही टेस्टनेटवर प्रमाणक चालवू शकता. फुसाका [टेस्टनेटवर लवकर सक्रिय केले जाते](https://blog.ethereum.org/2025/09/26/fusaka-testnet-announcement) ज्यामुळे तुम्हाला सर्वकाही कार्य करत असल्याची खात्री करण्यासाठी आणि बग्स नोंदवण्यासाठी अधिक जागा मिळते. टेस्टनेट फोर्क्सची घोषणा देखील मेलिंग लिस्ट आणि ब्लॉगमध्ये केली जाते.
### "पूर्वनिर्धारित प्रस्तावक लुकअहेड" (EIP-7917) चा प्रमाणकांवर परिणाम होतो का? {#does-7917-affect-validators}
हा बदल तुमचा प्रमाणक क्लायंट कसा कार्य करतो हे बदलत नाही, तथापि, तो तुमच्या प्रमाणक कर्तव्यांच्या भविष्याबद्दल अधिक अंतर्दृष्टी प्रदान करेल. नवीन वैशिष्ट्यांसह अद्ययावत राहण्यासाठी तुमचे मॉनिटरिंग टूलिंग अपडेट करण्याची खात्री करा.
### फुसाकाचा नोड्स आणि प्रमाणकांसाठी बँडविड्थ आवश्यकतांवर कसा परिणाम होतो? {#how-does-fusaka-affect-bandwidth-requirements-for-nodes-and-validators}
नोड्स ब्लॉब डेटा कसा प्रसारित करतात यामध्ये PeerDAS महत्त्वपूर्ण बदल करते. सर्व डेटा 128 सबनेट्समध्ये कॉलम्स नावाच्या तुकड्यांमध्ये विभागलेला असतो आणि नोड्स त्यापैकी फक्त काहींची सदस्यता घेतात. नोड्सना किती सबनेट कॉलम्सची कस्टडी घ्यावी लागते हे त्यांच्या कॉन्फिगरेशनवर आणि कनेक्ट केलेल्या प्रमाणकांच्या संख्येवर अवलंबून असते. वास्तविक बँडविड्थ आवश्यकता नेटवर्कमध्ये अनुमत ब्लॉब्सचे प्रमाण आणि नोडच्या प्रकारावर अवलंबून असेल. फुसाका सक्रियकरणाच्या क्षणी ब्लॉब लक्ष्य पूर्वीसारखेच राहते, परंतु PeerDAS सह, नोड ऑपरेटर्स त्यांच्या ब्लॉब्सच्या डिस्क वापरात आणि नेटवर्क ट्रॅफिकमध्ये घट पाहू शकतात. जसे BPOs नेटवर्कमध्ये जास्त संख्येने ब्लॉब्स कॉन्फिगर करतात, तसतशी आवश्यक बँडविड्थ प्रत्येक BPO सह वाढेल.
फुसाका BPOs नंतरही नोड्सच्या आवश्यकता [शिफारस केलेल्या मर्यादेत](https://eips.ethereum.org/EIPS/eip-7870) आहेत.
#### पूर्ण नोड्स {#full-nodes}
कोणत्याही प्रमाणकांशिवाय नियमित नोड्स फक्त 4 सबनेट्सची सदस्यता घेतील, मूळ डेटाच्या 1/8 भागासाठी कस्टडी प्रदान करतील. याचा अर्थ असा की समान प्रमाणात ब्लॉब डेटासह, त्यांना डाउनलोड करण्याची नोड बँडविड्थ आठ (8) पटीने लहान असेल. सामान्य पूर्ण नोडसाठी ब्लॉब्सचा डिस्क वापर आणि डाउनलोड बँडविड्थ सुमारे 80% ने कमी होऊन फक्त काही Mb पर्यंत येऊ शकते.
#### सोलो स्टेकर्स {#solo-stakers}
जर नोड प्रमाणक क्लायंटसाठी वापरला जात असेल, तर त्याला अधिक कॉलम्सची कस्टडी घ्यावी लागते आणि त्यामुळे अधिक डेटावर प्रक्रिया करावी लागते. प्रमाणक जोडल्यास, नोड किमान 8 कॉलम सबनेट्सची सदस्यता घेतो आणि त्यामुळे नियमित नोडच्या दुप्पट डेटावर प्रक्रिया करतो परंतु तरीही फुसाकापूर्वीपेक्षा कमी. जर प्रमाणक शिल्लक 287 ETH च्या वर असेल, तर अधिकाधिक सबनेट्सची सदस्यता घेतली जाईल.
सोलो स्टेकरसाठी, याचा अर्थ त्यांचा डिस्क वापर आणि डाउनलोड बँडविड्थ सुमारे 50% ने कमी होईल. तथापि स्थानिक पातळीवर ब्लॉक्स तयार करण्यासाठी आणि सर्व ब्लॉब्स नेटवर्कवर अपलोड करण्यासाठी, अधिक अपलोड बँडविड्थ आवश्यक आहे. स्थानिक बिल्डर्सना फुसाकाच्या वेळी पूर्वीपेक्षा 2-3 पट जास्त अपलोड बँडविड्थची आवश्यकता असेल आणि 15/21 ब्लॉब्सच्या BPO2 लक्ष्यासह, अंतिम आवश्यक अपलोड बँडविड्थ सुमारे 5 पट जास्त, 100Mpbs वर असावी लागेल.
#### मोठे प्रमाणक {#large-validators}
नोडमध्ये अधिक शिल्लक आणि प्रमाणक जोडल्यामुळे सदस्यता घेतलेल्या सबनेट्सची संख्या वाढते. उदाहरणार्थ, सुमारे 800 ETH शिल्लक असताना, नोड 25 कॉलम्सची कस्टडी घेतो आणि त्याला पूर्वीपेक्षा सुमारे 30% अधिक डाउनलोड बँडविड्थची आवश्यकता असेल. आवश्यक अपलोड नियमित नोड्सप्रमाणेच वाढतो आणि किमान 100Mbps आवश्यक आहे.
4096 ETH वर, 2 कमाल शिल्लक प्रमाणकांसह, नोड 'सुपरनोड' बनतो जो सर्व कॉलम्सची कस्टडी घेतो, त्यामुळे सर्वकाही डाउनलोड आणि संग्रहित करतो. हे नोड्स गहाळ डेटा परत योगदान देऊन नेटवर्कला सक्रियपणे बरे करतात परंतु त्यांना खूप जास्त बँडविड्थ आणि स्टोरेजची देखील आवश्यकता असते. अंतिम ब्लॉब लक्ष्य पूर्वीपेक्षा 6 पट जास्त असल्याने, सुपर नोड्सना सुमारे 600GB अतिरिक्त ब्लॉब डेटा संग्रहित करावा लागेल आणि सुमारे 20Mbps वर वेगवान शाश्वत डाउनलोड बँडविड्थ असावी लागेल.
[अपेक्षित आवश्यकतांबद्दल अधिक तपशील वाचा.](https://ethpandaops.io/posts/fusaka-bandwidth-estimation/#theoretical-requirements)
### कोणते EVM बदल लागू केले आहेत? {#what-evm-changes-are-implemented}
फुसाका नवीन किरकोळ बदल आणि वैशिष्ट्यांसह EVM ला मजबूत करते.
- स्केलिंग करताना सुरक्षिततेसाठी, एका व्यवहाराचा कमाल आकार 16.7 दशलक्ष गॅस युनिट्सपर्यंत [मर्यादित केला जाईल](https://eips.ethereum.org/EIPS/eip-7825).
- [नवीन ऑपकोड काउंट लीडिंग झिरोज (CLZ)](https://eips.ethereum.org/EIPS/eip-7939) EVM मध्ये जोडला गेला आहे आणि स्मार्ट कॉन्ट्रॅक्ट भाषांना विशिष्ट ऑपरेशन्स अधिक कार्यक्षमतेने करण्यास सक्षम करेल.
- [`ModExp` प्रीकंपाइलचा खर्च वाढवला जाईल](https://eips.ethereum.org/EIPS/eip-7883)—ते वापरणारे कॉन्ट्रॅक्ट्स अंमलबजावणीसाठी अधिक गॅस आकारतील.
### नवीन 16M गॅस मर्यादेचा कॉन्ट्रॅक्ट विकासकांवर कसा परिणाम होतो? {#how-does-new-16m-gas-limit-affects-contract-developers}
फुसाका [एका व्यवहाराच्या कमाल आकारावर 16.7 दशलक्ष](https://eips.ethereum.org/EIPS/eip-7825) (2^24) गॅस युनिट्सची मर्यादा सादर करते. हा साधारणपणे सरासरी ब्लॉकचा मागील आकार आहे ज्यामुळे तो संपूर्ण ब्लॉक वापरणाऱ्या जटिल व्यवहारांना सामावून घेण्याइतका मोठा बनतो. ही मर्यादा क्लायंट्ससाठी संरक्षण तयार करते, भविष्यात उच्च ब्लॉक गॅस मर्यादेसह संभाव्य DoS हल्ल्यांना प्रतिबंधित करते. स्केलिंगचे ध्येय हे आहे की कोणत्याही एका व्यवहाराने संपूर्ण ब्लॉक न वापरता अधिक व्यवहारांना ब्लॉकचेनमध्ये प्रवेश करण्यास सक्षम करणे.
नियमित वापरकर्ता व्यवहार या मर्यादेपर्यंत पोहोचण्यापासून खूप दूर आहेत. मोठी आणि जटिल विकेंद्रित वित्त (DeFi) ऑपरेशन्स, मोठी स्मार्ट कॉन्ट्रॅक्ट प्रस्थापने किंवा एकाधिक कॉन्ट्रॅक्ट्सना लक्ष्य करणारे बॅच व्यवहार यांसारख्या विशिष्ट अत्यंत प्रकरणांवर या बदलाचा परिणाम होऊ शकतो. हे व्यवहार लहान व्यवहारांमध्ये विभागले जावे लागतील किंवा दुसऱ्या मार्गाने ऑप्टिमाइझ करावे लागतील. संभाव्यतः मर्यादेपर्यंत पोहोचणारे व्यवहार सबमिट करण्यापूर्वी सिम्युलेशन वापरा.
RPC पद्धत `eth_call` मर्यादित नाही आणि वास्तविक ब्लॉकचेन मर्यादेपेक्षा मोठ्या व्यवहारांच्या सिम्युलेशनला अनुमती देईल. गैरवापर टाळण्यासाठी RPC पद्धतींची वास्तविक मर्यादा क्लायंट ऑपरेटरद्वारे कॉन्फिगर केली जाऊ शकते.
### विकासकांसाठी CLZ चा अर्थ काय आहे? {#what-clz-means-for-developers}
Solidity सारखे EVM कंपायलर्स तांत्रिकदृष्ट्या शून्य मोजण्यासाठी नवीन कार्य लागू करतील आणि वापरतील. जर नवीन कॉन्ट्रॅक्ट्स या प्रकारच्या ऑपरेशनवर अवलंबून असतील तर त्यांना गॅस बचतीचा फायदा होऊ शकतो. संभाव्य बचतीवरील दस्तऐवजीकरणासाठी स्मार्ट कॉन्ट्रॅक्ट भाषेच्या रिलीझ आणि वैशिष्ट्य घोषणांचे अनुसरण करा.
### माझ्या विद्यमान स्मार्ट कॉन्ट्रॅक्ट्ससाठी काही बदल आहेत का? {#what-clz-means-for-developers-2}
फुसाकाचा कोणताही थेट परिणाम नाही जो कोणतेही विद्यमान कॉन्ट्रॅक्ट्स मोडेल किंवा त्यांचे वर्तन बदलेल. अंमलबजावणी स्तरावर सादर केलेले बदल बॅकवर्ड सुसंगततेसह केले जातात, तथापि, अत्यंत प्रकरणे आणि संभाव्य प्रभावावर नेहमी लक्ष ठेवा.
[`ModExp` प्रीकंपाइलच्या वाढलेल्या खर्चासह](https://eips.ethereum.org/EIPS/eip-7883), त्यावर अवलंबून असलेले कॉन्ट्रॅक्ट्स अंमलबजावणीसाठी अधिक गॅस वापरतील. जर तुमचे कॉन्ट्रॅक्ट यावर खूप अवलंबून असेल आणि वापरकर्त्यांसाठी अधिक महाग होत असेल, तर त्याचा कसा वापर केला जातो याचा पुनर्विचार करा.
जर तुमचे कॉन्ट्रॅक्ट्स अंमलात आणणारे व्यवहार समान आकारापर्यंत पोहोचत असतील तर [नवीन 16.7 दशलक्ष मर्यादेचा](https://eips.ethereum.org/EIPS/eip-7825) विचार करा.
## पुढील वाचन {#further-reading}
- [इथेरियम रोडमॅप](/roadmap/)
- [फोर्ककास्ट: फुसाका](https://forkcast.org/upgrade/fusaka)
- [फुसाका मेटा EIP](https://eips.ethereum.org/EIPS/eip-7607)
- [फुसाका टेस्टनेट ब्लॉग घोषणा](https://blog.ethereum.org/2025/09/26/fusaka-testnet-announcement)
- [Bankless: फुसाका आणि पेक्ट्रा इथेरियमसाठी काय आणतील](https://www.bankless.com/read/what-fusaka-pectra-will-bring-ethereum)
- [Bankless: इथेरियमचे पुढील अपग्रेड्स: प्रेस्टन व्हॅन लून सोबत फुसाका, ग्लॅमस्टरडॅम आणि त्यापलीकडे](https://x.com/BanklessHQ/status/1956017743289020633?t=502)
- [द फुसाका फाइल्स](https://www.youtube.com/playlist?list=PL4cwHXAawZxpz-erUbKKUnnGoQNdF8s7Z)
- [PEEPanEIPs स्पष्ट केले](https://www.youtube.com/playlist?list=PL4cwHXAawZxoIenfk7OJry4rxcqX-eqBt)