एथेरियम चाहता है कि घरेलू वैलिडेटर प्रूफ्स को वेरिफाई करें लेकिन 12 GPU की वास्तविकता एक नया खतरा खड़ा करती है
Ethereum शोधकर्ता ladislaus.eth ने पिछले सप्ताह एक वॉकथ्रू प्रकाशित किया जिसमें बताया गया कि Ethereum हर लेनदेन को पुनः निष्पादित करने से zero-knowledge प्रूफ की सत्यापन की ओर कैसे बढ़ने की योजना बना रहा है।
पोस्ट इसे "शांत लेकिन मौलिक परिवर्तन" के रूप में प्रस्तुत करती है, और यह प्रस्तुति सटीक है। इसलिए नहीं कि काम गुप्त है, बल्कि इसलिए कि इसके प्रभाव Ethereum की पूरी संरचना में इस तरह फैलते हैं जो तब तक स्पष्ट नहीं होंगे जब तक टुकड़े जुड़ते नहीं हैं।
यह Ethereum द्वारा एक फीचर के रूप में "ZK जोड़ना" नहीं है। Ethereum एक वैकल्पिक सत्यापन पथ का प्रोटोटाइप बना रहा है जिसमें कुछ वैलिडेटर हर लेनदेन को फिर से चलाने के बजाय कॉम्पैक्ट निष्पादन प्रूफ की सत्यापन करके ब्लॉक्स को प्रमाणित कर सकते हैं।
यदि यह काम करता है, तो Ethereum की layer-1 भूमिका "rollups के लिए सेटलमेंट और डेटा उपलब्धता" से "उच्च-थ्रूपुट निष्पादन जिसका सत्यापन होम वैलिडेटर्स के लिए पर्याप्त सस्ता रहता है" की ओर स्थानांतरित हो जाती है।
वास्तव में क्या बनाया जा रहा है
EIP-8025, जिसका शीर्षक "Optional Execution Proofs" है, ड्राफ्ट रूप में आया और मैकेनिक्स को निर्दिष्ट करता है।
Execution प्रूफ एक समर्पित विषय के माध्यम से consensus-layer peer-to-peer नेटवर्क पर साझा किए जाते हैं। वैलिडेटर दो नए मोड में काम कर सकते हैं: प्रूफ-जेनरेटिंग या स्टेटलेस वैलिडेशन।
प्रस्ताव स्पष्ट रूप से बताता है कि इसके लिए "हार्डफोर्क की आवश्यकता नहीं है" और यह बैकवर्ड कम्पैटिबल रहता है, जबकि नोड्स अभी भी आज की तरह पुनः निष्पादित कर सकते हैं।
Ethereum Foundation की zkEVM टीम ने 26 जनवरी को 2026 के लिए एक ठोस रोडमैप प्रकाशित किया, जिसमें छह उप-विषयों की रूपरेखा दी गई: execution witness और guest program मानकीकरण, zkVM-guest API मानकीकरण, consensus layer एकीकरण, prover इंफ्रास्ट्रक्चर, बेंचमार्किंग और मेट्रिक्स, और formal verification के साथ सुरक्षा।
पहला L1-zkEVM breakout कॉल 11 फरवरी को 15:00 UTC पर निर्धारित है।
एंड-टू-एंड पाइपलाइन इस तरह काम करती है: एक execution-layer क्लाइंट एक ExecutionWitness उत्पन्न करता है, एक स्व-निहित पैकेज जिसमें पूर्ण स्थिति रखे बिना ब्लॉक को मान्य करने के लिए आवश्यक सभी डेटा होता है।
एक मानकीकृत guest प्रोग्राम उस witness का उपभोग करता है और state transition को मान्य करता है। एक zkVM इस प्रोग्राम को निष्पादित करता है, और एक prover सही निष्पादन का प्रूफ उत्पन्न करता है। फिर consensus layer क्लाइंट execution layer क्लाइंट को पुनः निष्पादित करने के लिए कॉल करने के बजाय उस प्रूफ को सत्यापित करता है।
मुख्य निर्भरता ePBS (Enshrined Proposer-Builder Separation) है, जो आगामी Glamsterdam हार्डफोर्क के लिए लक्षित है। ePBS के बिना, proving विंडो लगभग एक से दो सेकंड है, जो रियल-टाइम proving के लिए बहुत तंग है। ePBS द्वारा ब्लॉक पाइपलाइनिंग प्रदान करने के साथ, विंडो छह से नौ सेकंड तक बढ़ जाती है।
चार्ट दिखाता है कि ePBS Ethereum की proving विंडो को 1-2 सेकंड से 6-9 सेकंड तक बढ़ाता है, जो 12 GPUs की आवश्यकता वाले वर्तमान सात-सेकंड औसत proving समय की तुलना में रियल-टाइम प्रूफ जनरेशन को संभव बनाता है।
विकेंद्रीकरण का ट्रेड-ऑफ
यदि वैकल्पिक प्रूफ और witness फॉर्मेट परिपक्व होते हैं, तो अधिक होम वैलिडेटर पूर्ण execution layer स्थिति बनाए रखे बिना भाग ले सकते हैं।
गैस सीमा बढ़ाना राजनीतिक और आर्थिक रूप से आसान हो जाता है क्योंकि सत्यापन लागत निष्पादन जटिलता से अलग हो जाती है। सत्यापन कार्य अब ऑन-चेन गतिविधि के साथ रैखिक रूप से स्केल नहीं होता है।
हालांकि, proofing केंद्रीकरण का अपना जोखिम रखता है। 2 फरवरी की Ethereum Research पोस्ट रिपोर्ट करती है कि एक पूर्ण Ethereum ब्लॉक को prove करने के लिए वर्तमान में लगभग 12 GPUs की आवश्यकता होती है और औसतन 7 सेकंड लगते हैं।
लेखक केंद्रीकरण के बारे में चिंताओं को चिह्नित करता है और नोट करता है कि सीमाओं की भविष्यवाणी करना मुश्किल रहता है। यदि proving GPU-भारी रहता है और builder या prover नेटवर्क में केंद्रित होता है, तो Ethereum "सभी पुनः निष्पादित करते हैं" को "कुछ prove करते हैं, कई सत्यापित करते हैं" के लिए व्यापार कर सकता है।
डिज़ाइन का उद्देश्य proving परत पर क्लाइंट विविधता को पेश करके इसे संबोधित करना है। EIP-8025 की कार्य धारणा तीन-में-से-पांच थ्रेशोल्ड है, जिसका अर्थ है कि एक attester एक ब्लॉक के निष्पादन को मान्य के रूप में स्वीकार करता है जब उसने विभिन्न execution-layer क्लाइंट कार्यान्वयन से पांच स्वतंत्र प्रूफ में से तीन को सत्यापित किया हो।
यह प्रोटोकॉल स्तर पर क्लाइंट विविधता को संरक्षित करता है लेकिन हार्डवेयर एक्सेस समस्या को हल नहीं करता है।
सबसे ईमानदार प्रस्तुति यह है कि Ethereum विकेंद्रीकरण युद्धक्षेत्र को स्थानांतरित कर रहा है। आज की बाधा है "क्या आप एक execution layer क्लाइंट चलाने का खर्च उठा सकते हैं?" कल की हो सकती है "क्या आप GPU क्लस्टर या prover नेटवर्क तक पहुंच सकते हैं?"
दांव यह है कि प्रूफ सत्यापन को state स्टोरेज और पुनः निष्पादन की तुलना में commoditize करना आसान है, लेकिन हार्डवेयर प्रश्न खुला रहता है।
L1 स्केलिंग अनलॉक
Ethereum का रोडमैप, जिसे अंतिम बार 5 फरवरी को अपडेट किया गया था, "Statelessness" को एक प्रमुख अपग्रेड थीम के रूप में सूचीबद्ध करता है: बड़ी स्थिति संग्रहीत किए बिना ब्लॉक सत्यापित करना।
वैकल्पिक execution प्रूफ और witnesses ठोस तंत्र हैं जो stateless सत्यापन को व्यावहारिक बनाते हैं। एक stateless नोड को केवल एक consensus क्लाइंट की आवश्यकता होती है और payload प्रोसेसिंग के दौरान प्रूफ को सत्यापित करता है।
Syncing अंतिम finalization checkpoint के बाद से हाल के ब्लॉक के लिए प्रूफ डाउनलोड करने तक कम हो जाता है।
यह गैस सीमा के लिए महत्वपूर्ण है। आज, गैस सीमा में हर वृद्धि एक नोड चलाना कठिन बनाती है। यदि वैलिडेटर पुनः निष्पादित करने के बजाय प्रूफ को सत्यापित कर सकते हैं, तो सत्यापन लागत अब गैस सीमा के साथ स्केल नहीं होती है। निष्पादन जटिलता और सत्यापन लागत अलग हो जाती है।
2026 रोडमैप में बेंचमार्किंग और रीप्राइसिंग वर्कस्ट्रीम स्पष्ट रूप से उन मेट्रिक्स को लक्षित करता है जो गैस उपभोग को proving साइकल और proving समय से मैप करते हैं।
यदि वे मेट्रिक्स स्थिर होते हैं, तो Ethereum एक लीवर प्राप्त करता है जो इसके पास पहले नहीं था: एक वैलिडेटर चलाने की लागत को आनुपातिक रूप से बढ़ाए बिना थ्रूपुट बढ़ाने की क्षमता।
layer-2 ब्लॉकचेन के लिए इसका क्या अर्थ है
Vitalik Buterin द्वारा हाल की एक पोस्ट तर्क देती है कि layer-2 ब्लॉकचेन को स्केलिंग से परे अंतर करना चाहिए और स्पष्ट रूप से "native rollup precompile" के मूल्य को enshrined zkEVM प्रूफ की आवश्यकता से जोड़ती है जो Ethereum को layer-1 को स्केल करने के लिए पहले से ही चाहिए।
तर्क सीधा है: यदि सभी वैलिडेटर execution प्रूफ को सत्यापित करते हैं, तो वही प्रूफ native rollups के लिए EXECUTE precompile द्वारा भी उपयोग किए जा सकते हैं। Layer-1 proving इंफ्रास्ट्रक्चर साझा इंफ्रास्ट्रक्चर बन जाता है।
यह layer-2 मूल्य प्रस्ताव को स्थानांतरित करता है। यदि layer-1 सत्यापन लागत को कम रखते हुए उच्च थ्रूपुट तक स्केल कर सकता है, तो rollups "Ethereum लोड संभाल नहीं सकता" के आधार पर खुद को justify नहीं कर सकते।
नए विभेदन अक्ष विशेष वर्चुअल मशीनें, अल्ट्रा-लो लेटेंसी, preconfirmations, और composability मॉडल हैं जैसे rollups जो फास्ट-proving डिज़ाइन पर झुकते हैं।
वह परिदृश्य जहां layer-2s प्रासंगिक रहते हैं वह है जिसमें विशेषज्ञता और interoperability के बीच भूमिकाएं विभाजित होती हैं।
Layer-1 उच्च-थ्रूपुट, कम-सत्यापन-लागत निष्पादन और सेटलमेंट परत बन जाता है। Layer-2s फीचर लैब, लेटेंसी ऑप्टिमाइज़र, और composability ब्रिज बन जाते हैं।
हालांकि, इसके लिए layer-2 टीमों को नए मूल्य प्रस्तावों को व्यक्त करने और Ethereum को proof-verification रोडमैप पर deliver करने की आवश्यकता है।
आगे के तीन रास्ते
भविष्य में तीन संभावित परिदृश्य हैं।
पहला परिदृश्य proof-first सत्यापन के सामान्य होने से बना है। यदि वैकल्पिक प्रूफ और witness फॉर्मेट परिपक्व होते हैं और क्लाइंट कार्यान्वयन मानकीकृत इंटरफेस के आसपास स्थिर होते हैं, तो अधिक होम वैलिडेटर पूर्ण execution layer स्थिति चलाए बिना भाग ले सकते हैं।
गैस सीमा बढ़ती है क्योंकि सत्यापन लागत अब निष्पादन जटिलता के साथ संरेखित नहीं होती है। यह पथ ExecutionWitness और guest program मानकीकरण वर्कस्ट्रीम पर निर्भर करता है जो पोर्टेबल फॉर्मेट पर converge होते हैं।
परिदृश्य दो वह है जहां prover केंद्रीकरण नया choke पॉइंट बन जाता है। यदि proving GPU-भारी रहता है और builder या prover नेटवर्क में केंद्रित होता है, तो Ethereum विकेंद्रीकरण युद्धक्षेत्र को वैलिडेटर के हार्डवेयर से prover बाजार संरचना में स्थानांतरित करता है।
प्रोटोकॉल अभी भी काम करता है, क्योंकि कहीं भी एक ईमानदार prover चेन को लाइव रखता है, लेकिन सुरक्षा मॉडल बदल जाता है।
तीसरा परिदृश्य layer-1 proof सत्यापन का एक साझा इंफ्रास्ट्रक्चर बनना है। यदि consensus layer एकीकरण कठोर होता है और ePBS विस्तारित proving विंडो प्रदान करता है, तो Layer 2s का मूल्य प्रस्ताव विशेष VMs, अल्ट्रा-लो लेटेंसी, और नए composability मॉडल की ओर झुक जाता है न कि केवल "Ethereum को स्केल करना"।
इस पथ के लिए ePBS को Glamsterdam के लिए समय पर ship करने की आवश्यकता है।
| परिदृश्य | क्या सत्य होना चाहिए (तकनीकी पूर्व शर्तें) | क्या टूटता है / मुख्य जोखिम | क्या सुधरता है (विकेंद्रीकरण, गैस सीमा, sync समय) | L1 भूमिका परिणाम (निष्पादन थ्रूपुट बनाम सत्यापन लागत) | L2 निहितार्थ (नया विभेदन अक्ष) | "क्या देखना है" संकेत |
|---|---|---|---|---|---|---|
| Proof-first सत्यापन सामान्य हो जाता है | Execution Witness + guest program मानक converge होते हैं; zkVM/guest API मानकीकृत होता है; CL proof सत्यापन पथ स्थिर है; प्रूफ P2P पर विश्वसनीय रूप से प्रचारित होते हैं; स्वीकार्य multi-proof threshold semantics (जैसे 3-of-5) | Proof उपलब्धता / लेटेंसी एक नई निर्भरता बन जाती है; सत्यापन बग consensus sensitive हो जाते हैं यदि/जब इस पर भरोसा किया जाता है; क्लाइंट/provers में बेमेल | होम वैलिडेटर EL स्थिति के बिना attest कर सकते हैं; sync समय कम होता है (finalization checkpoint के बाद से प्रूफ); गैस-सीमा वृद्धि आसान हो जाती है क्योंकि सत्यापन लागत निष्पादन जटिलता से अलग हो जाती है | L1 कई वैलिडेटर के लिए निरंतर-ish सत्यापन लागत के साथ उच्च-थ्रूपुट निष्पादन की ओर स्थानांतरित होता है | L2s को "L1 स्केल नहीं कर सकता" से परे खुद को justify करना होगा: विशेष VMs, app-specific निष्पादन, custom fee मॉडल, privacy, आदि। | Spec/test-vector hardening; क्लाइंट में witness/guest portability; स्थिर proof gossip + failure handling; बेंचमार्क curves (gas → proving cycles/time) |
| Prover केंद्रीकरण choke पॉइंट बन जाता है | Proof generation GPU-भारी रहता है; proving बाजार consolidate होता है (builders / prover नेटवर्क); सीमित "garage-scale" proving; liveness परिष्कृत provers के एक छोटे सेट पर निर्भर करता है | "कुछ prove करते हैं, कई सत्यापित करते हैं" शक्ति को केंद्रित करता है; censorship / MEV गतिशीलता तेज होती है; prover outages liveness/finality तनाव पैदा करते हैं; भौगोलिक / नियामक एकाग्रता जोखिम | वैलिडेटर अभी भी सस्ते में सत्यापित कर सकते हैं, लेकिन विकेंद्रीकृत स्थानांतरण: आसान attesting, कठिन proving; कुछ गैस-सीमा headroom, लेकिन prover अर्थशास्त्र द्वारा सीमित | L1 निष्पादन scalable सिद्धांत में बन जाता है, लेकिन व्यावहारिक रूप से prover क्षमता और बाजार संरचना द्वारा सीमित | L2s based / pre-confirmed डिज़ाइन, वैकल्पिक proving सिस्टम, या लेटेंसी गारंटी में झुक सकते हैं—संभावित रूप से विशेषाधिकार प्राप्त actors पर निर्भरता बढ़ा रहे हैं | Proving लागत रुझान (हार्डवेयर आवश्यकताएं, प्रति ब्लॉक समय); prover विविधता मेट्रिक्स; वितरित proving के लिए प्रोत्साहन; failure-mode drills (जब प्रूफ गायब होते हैं तो क्या होता है?) |
| L1 proof सत्यापन साझा इंफ्रास्ट्रक्चर बन जाता है | CL एकीकरण "hardens"; प्रूफ व्यापक रूप से उत्पादित / उपभोग किए जाते हैं; ePBS ship होता है और एक workable proving विंडो प्रदान करता है; इंटरफेस पुनः उपयोग की अनुमति देते हैं (जैसे EXECUTE-style precompile / native rollup hooks) | Cross-domain coupling जोखिम: यदि L1 proving infra तनावग्रस्त है, तो rollup सत्यापन पथ भी पीड़ित हो सकते हैं; जटिलता / attack surface विस्तारित होती है | साझा infra डुप्लिकेटेड proving प्रयास को कम करता है; interoperability में सुधार करता है; अधिक अनुमानित सत्यापन लागत; वैलिडेटर को कीमत से बाहर किए बिना उच्च L1 थ्रूपुट के लिए स्पष्ट पथ | L1 एक proof-verified निष्पादन + सेटलमेंट परत में विकसित होता है जो rollups को natively सत्यापित भी कर सकता है | L2s लेटेंसी (preconfs), विशेष निष्पादन वातावरण, और composable मॉडल (जैसे fast-proving / synchronous-ish डिज़ाइन) की ओर pivot करते हैं न कि "scale-only" | ePBS / Glamsterdam प्रगति; end-to-end पाइपलाइन demos (witness → proof → CL verify); बेंचमार्क + संभावित गैस repricing; न्यूनतम viable proof distribution semantics और monitoring का rollout |
बड़ी तस्वीर
Consensus-specs एकीकरण परिपक्वता संकेत देगी कि "वैकल्पिक प्रूफ" ज्यादातर TODOs से hardened test vectors की ओर बढ़ते हैं या नहीं।
ExecutionWitness और guest program को मानकीकृत करना क्लाइंट में stateless सत्यापन portability के लिए keystone है। बेंचमार्क जो गैस उपभोग को proving साइकल और proving समय से मैप करते हैं, यह निर्धारित करेंगे कि ZK-friendliness के लिए गैस repricing संभव है या नहीं।
ePBS और Glamsterdam प्रगति संकेत देगी कि छह-से-नौ-सेकंड proving विंडो वास्तविकता बनती है या नहीं। Breakout कॉल outputs प्रकट करेंगे कि कार्य समूह इंटरफेस और न्यूनतम viable proof distribution semantics पर converge होते हैं या नहीं।
Ethereum जल्द proof-based सत्यापन पर स्विच नहीं कर रहा है। EIP-8025 स्पष्ट रूप से बताता है कि यह "अभी तक इस पर अपग्रेड आधारित नहीं कर सकता," और वैकल्पिक framing जानबूझकर है। परिणामस्वरूप, यह एक आसन्न सक्रियण के बजाय एक परीक्षण योग्य पथ है।
फिर भी, तथ्य यह है कि Ethereum Foundation ने 2026 कार्यान्वयन रोडमैप ship किया, परियोजना मालिकों के साथ एक breakout कॉल निर्धारित किया, और ठोस peer-to-peer gossip mechanics के साथ एक EIP का मसौदा तैयार किया, इसका मतलब है कि यह कार्य अनुसंधान प्रशंसनीयता से delivery प्रोग्राम में चला गया है।
परिवर्तन शांत है क्योंकि इसमें नाटकीय टोकन अर्थशास्त्र परिवर्तन या उपयोगकर्ता-सामना करने वाली सुविधाएं शामिल नहीं हैं। लेकिन यह मौलिक है क्योंकि यह निष्पादन जटिलता और सत्यापन लागत के बीच संबंध को फिर से लिखता है।
यदि Ethereum दोनों को अलग कर सकता है, तो layer-1 अब वह bottleneck नहीं रहेगा जो सब कुछ दिलचस्प को layer-2 पर मजबूर करता है।
और यदि layer-1 proof सत्यापन साझा इंफ्रास्ट्रक्चर बन जाता है, तो पूरे layer-2 इकोसिस्टम को एक कठिन प्रश्न का उत्तर देने की आवश्यकता है: आप क्या बना रहे हैं जो layer-1 नहीं कर सकता?
पोस्ट Ethereum wants home validators to verify proofs but a 12 GPU reality raises a new threat पहली बार CryptoSlate पर दिखाई दी।
आपको यह भी पसंद आ सकता है
Onyxcoin की महीनेभर की प्राइस क्रैश और 40% होल्डर ऑउटफ्लो से बढ़ेगी मुश्किलें
Solana दो साल के निचले स्तर पर, इतिहास इंडीकेट करता है $100 की ओर बाउंस संभावित
