डेटा उपलब्धता

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

डेटा उपलब्धता म्हणजे ब्लॉक सत्यापित करण्यासाठी आवश्यक असलेला डेटा नेटवर्कमधील सर्व सहभागींना खरोखर उपलब्ध आहे यावर वापरकर्त्याचा विश्वास. Ethereum लेयर 1 वरील फुल नोड्ससाठी हे तुलनेने सोपे आहे; फुल नोड प्रत्येक ब्लॉकमधील सर्व डेटाची एक प्रत डाउनलोड करतो - डाउनलोड करणे शक्य होण्यासाठी डेटा उपलब्ध असलाच पाहिजे. गहाळ डेटा असलेला ब्लॉक ब्लॉकचेनमध्ये जोडण्याऐवजी टाकून दिला जातो. ही "ऑनचेन डेटा उपलब्धता" आहे आणि हे मोनोलिथिक ब्लॉकचेन्सचे वैशिष्ट्य आहे. फुल नोड्सना अवैध व्यवहार स्वीकारण्यासाठी फसवले जाऊ शकत नाही कारण ते प्रत्येक व्यवहार स्वतःसाठी डाउनलोड करतात आणि कार्यान्वित करतात. तथापि, मॉड्यूलर ब्लॉकचेन, लेयर 2 रोलअप आणि लाईट क्लायंटसाठी, डेटा उपलब्धतेचे परिदृश्य अधिक गुंतागुंतीचे आहे, ज्यासाठी काही अधिक अत्याधुनिक सत्यापन प्रक्रियांची आवश्यकता आहे.

पूर्वतयारी

तुम्हाला ब्लॉकचेनची मूलभूत तत्त्वे, विशेषतः सहमती यंत्रणा यांची चांगली समज असली पाहिजे. हे पृष्ठ असेही गृहीत धरते की वाचक ब्लॉक्स, व्यवहार, नोड्स, स्केलिंग सोल्यूशन्स, आणि इतर संबंधित विषयांबद्दल परिचित आहेत.

डेटा उपलब्धता समस्या

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

लाईट नोड्स आणि लेयर 2 रोलअप्स ही नेटवर्कमधील अशा सहभागींची महत्त्वाची उदाहरणे आहेत ज्यांना डेटा उपलब्धतेची मजबूत हमी आवश्यक आहे परंतु ते स्वतःसाठी व्यवहार डेटा डाउनलोड आणि त्यावर प्रक्रिया करू शकत नाहीत. व्यवहार डेटा डाउनलोड करणे टाळल्यामुळेच लाईट नोड्स 'लाईट' (हलके) बनतात आणि रोलअप्सना प्रभावी स्केलिंग सोल्यूशन्स बनण्यास मदत होते.

भविष्यातील "स्टेटलेस" Ethereum क्लायंटसाठी डेटा उपलब्धता ही एक गंभीर चिंतेची बाब आहे, ज्यांना ब्लॉक्सची पडताळणी करण्यासाठी स्टेट डेटा डाउनलोड आणि संग्रहित करण्याची आवश्यकता नाही. स्टेटलेस क्लायंट्सना अजूनही खात्री असणे आवश्यक आहे की डेटा कुठेतरी उपलब्ध आहे आणि त्यावर योग्यरित्या प्रक्रिया केली गेली आहे.

डेटा उपलब्धता उपाय

डेटा उपलब्धता सॅम्पलिंग (DAS)

डेटा उपलब्धता सॅम्पलिंग (DAS) हा नेटवर्कसाठी कोणत्याही एका नोडवर जास्त ताण न टाकता डेटा उपलब्ध आहे की नाही हे तपासण्याचा एक मार्ग आहे. प्रत्येक नोड (नॉन-स्टेकिंग नोड्ससह) एकूण डेटाचा एक छोटा, यादृच्छिकपणे निवडलेला उपसंच डाउनलोड करतो. नमुने यशस्वीरित्या डाउनलोड केल्याने सर्व डेटा उपलब्ध असल्याची उच्च आत्मविश्वासाने पुष्टी होते. हे डेटा इरेजर कोडिंगवर अवलंबून आहे, जे रिडंडंट माहितीसह दिलेल्या डेटासेटचा विस्तार करते (हे करण्याचा मार्ग म्हणजे डेटावर पॉलीनोमियल म्हणून ओळखले जाणारे फंक्शन फिट करणे आणि अतिरिक्त पॉईंट्सवर त्या पॉलीनोमियलचे मूल्यांकन करणे). हे आवश्यकतेनुसार रिडंडंट डेटामधून मूळ डेटा पुनर्प्राप्त करण्यास अनुमती देते. या डेटा निर्मितीचा परिणाम असा आहे की जर मूळ डेटाचा कोणताही भाग अनुपलब्ध असेल, तर विस्तारित डेटाचा अर्धा भाग गहाळ होईल! प्रत्येक नोडद्वारे डाउनलोड केलेल्या डेटा नमुन्यांचे प्रमाण अशा प्रकारे ट्यून केले जाऊ शकते की जर अर्ध्यापेक्षा कमी डेटा खरोखर उपलब्ध असेल, तर प्रत्येक क्लायंटद्वारे नमुना घेतलेल्या डेटाच्या तुकड्यांपैकी किमान एक तुकडा गहाळ असण्याची अत्यंत शक्यता असते.

फुल डँकशार्डिंग लागू झाल्यानंतर रोलअप ऑपरेटर आपला व्यवहार डेटा उपलब्ध करतात याची खात्री करण्यासाठी DAS चा वापर केला जाईल. सर्व डेटा अस्तित्वात आहे याची खात्री करण्यासाठी Ethereum नोड्स वर स्पष्ट केलेल्या रिडंडंसी स्कीमचा वापर करून ब्लॉब्समध्ये प्रदान केलेल्या व्यवहार डेटाचे यादृच्छिकपणे सॅम्पल घेतील. ब्लॉक प्रोड्युसर्स लाईट क्लायंट्सना सुरक्षित ठेवण्यासाठी आपला सर्व डेटा उपलब्ध करून देत आहेत याची खात्री करण्यासाठी हीच पद्धत वापरली जाऊ शकते. त्याचप्रमाणे, प्रस्तावक-निर्माता पृथक्करण (proposer-builder separation) अंतर्गत, केवळ ब्लॉक बिल्डरलाच संपूर्ण ब्लॉकवर प्रक्रिया करणे आवश्यक असेल - इतर व्हॅलिडेटर्स डेटा उपलब्धता सॅम्पलिंग वापरून पडताळणी करतील.

डेटा उपलब्धता समित्या

डेटा उपलब्धता समित्या (DACs) या विश्वसनीय पक्ष आहेत जे डेटा उपलब्धतेची हमी देतात किंवा त्याची साक्ष देतात. DACs चा वापर DAS च्या ऐवजी किंवा त्याच्या संयोगानेopens in a new tab केला जाऊ शकतो. समित्यांसोबत येणारी सुरक्षा हमी विशिष्ट सेटअपवर अवलंबून असते. उदाहरणार्थ, लाईट नोड्ससाठी डेटा उपलब्धतेची साक्ष देण्यासाठी Ethereum व्हॅलिडेटर्सच्या यादृच्छिकपणे निवडलेल्या उपसंचांचा वापर करते.

काही व्हॅलिडियम्सद्वारे DACs चा वापर केला जातो. DAC हा नोड्सचा एक विश्वसनीय संच आहे जो डेटाच्या प्रती ऑफलाइन संग्रहित करतो. विवादाच्या प्रसंगी डेटा उपलब्ध करून देणे DAC ला आवश्यक आहे. DAC चे सदस्य ऑनचेन साक्षांकन देखील प्रकाशित करतात हे सिद्ध करण्यासाठी की सदर डेटा खरोखर उपलब्ध आहे. काही व्हॅलिडियम्स DACs च्या जागी प्रूफ-ऑफ-स्टेक (PoS) व्हॅलिडेटर प्रणाली वापरतात. येथे, कोणीही व्हॅलिडेटर बनू शकतो आणि डेटा ऑफचेन संग्रहित करू शकतो. तथापि, त्यांना एक "बॉन्ड" प्रदान करणे आवश्यक आहे, जो स्मार्ट कॉन्ट्रॅक्टमध्ये जमा केला जातो. दुर्भावनापूर्ण वर्तनाच्या प्रसंगी, जसे की व्हॅलिडेटरने डेटा रोखून ठेवल्यास, बॉन्ड स्लॅश केला जाऊ शकतो. प्रूफ-ऑफ-स्टेक डेटा उपलब्धता समित्या नियमित DACs पेक्षा अधिक सुरक्षित आहेत कारण त्या प्रामाणिक वर्तनाला थेट प्रोत्साहन देतात.

डेटा उपलब्धता आणि लाईट नोड्स

लाईट नोड्सना ब्लॉक डेटा डाउनलोड न करता त्यांना मिळणाऱ्या ब्लॉक हेडर्सची अचूकता सत्यापित करणे आवश्यक आहे. या हलकेपणाची किंमत म्हणजे फुल नोड्स ज्या प्रकारे स्थानिक पातळीवर व्यवहार पुन्हा कार्यान्वित करून ब्लॉक हेडर्सची स्वतंत्रपणे पडताळणी करू शकतात, तसे न करू शकणे.

Ethereum लाईट नोड्स 512 व्हॅलिडेटर्सच्या यादृच्छिक संचांवर विश्वास ठेवतात ज्यांना _सिंक समिती_मध्ये नेमले गेले आहे. सिंक समिती एका DAC प्रमाणे कार्य करते जी लाईट क्लायंट्सना क्रिप्टोग्राफिक स्वाक्षरी वापरून सूचित करते की हेडरमधील डेटा योग्य आहे. दररोज, सिंक समिती रिफ्रेश होते. प्रत्येक ब्लॉक हेडर लाईट नोड्सना सावध करतो की कोणत्या व्हॅलिडेटर्सकडून पुढील ब्लॉकवर स्वाक्षरीची अपेक्षा करावी, त्यामुळे त्यांना खऱ्या सिंक-समितीचे ढोंग करणाऱ्या दुर्भावनापूर्ण गटावर विश्वास ठेवण्यासाठी फसवले जाऊ शकत नाही.

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

हे फ्रॉड प्रूफ्स ज्या प्रकारे काम करतात ते असे आहे की, नेटवर्कमध्ये अवैध स्टेट ट्रांझिशन पसरताना पाहून एक फुल नोड त्वरीत डेटाचा एक छोटा तुकडा तयार करू शकतो, जो हे दर्शवतो की प्रस्तावित स्टेट ट्रांझिशन दिलेल्या व्यवहारांच्या संचामधून शक्य नाही, आणि तो डेटा पिअर्सना प्रसारित करू शकतो. लाईट नोड्स ते फ्रॉड-प्रूफ्स घेऊ शकतात आणि खराब ब्लॉक हेडर्स टाकून देण्यासाठी त्यांचा वापर करू शकतात, ज्यामुळे ते फुल नोड्सप्रमाणेच प्रामाणिक चेनवर राहतील याची खात्री होते.

हे फुल नोड्सना पूर्ण व्यवहार डेटाचा ऍक्सेस असण्यावर अवलंबून आहे. एक आक्रमणकर्ता जो एक खराब ब्लॉक हेडर प्रसारित करतो आणि व्यवहार डेटा उपलब्ध करून देण्यात अपयशी ठरतो, तो फुल नोड्सना फ्रॉड प्रूफ्स तयार करण्यापासून रोखू शकतो. फुल नोड्स कदाचित एका खराब ब्लॉकबद्दल चेतावणी देऊ शकतील, परंतु ते त्यांच्या चेतावणीला पुराव्यासह दुजोरा देऊ शकणार नाहीत, कारण पुरावा तयार करण्यासाठी डेटा उपलब्ध करून दिला गेला नव्हता!

या डेटा उपलब्धता समस्येवर उपाय म्हणजे DAS. लाईट नोड्स संपूर्ण स्टेट डेटाचे खूप लहान यादृच्छिक तुकडे डाउनलोड करतात आणि संपूर्ण डेटा संच उपलब्ध असल्याची पडताळणी करण्यासाठी त्या नमुन्यांचा वापर करतात. N यादृच्छिक चंक्स डाउनलोड केल्यानंतर पूर्ण डेटा उपलब्ध आहे असे चुकीने गृहीत धरण्याची वास्तविक शक्यता मोजली जाऊ शकते (100 चंक्ससाठी ही शक्यता 10^-30 आहेopens in a new tab, म्हणजे, अविश्वसनीयपणे अशक्य).

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

टीप: प्रूफ-ऑफ-स्टेक Ethereum लाईट क्लायंटसाठी DAS आणि फ्रॉड प्रूफ्स अद्याप लागू केलेले नाहीत, परंतु ते रोडमॅपवर आहेत, आणि बहुधा ZK-SNARK आधारित प्रूफ्सच्या स्वरूपात असतील. आजचे लाईट क्लायंट DAC च्या एका प्रकारावर अवलंबून आहेत: ते सिंक-समितीच्या ओळखीची पडताळणी करतात आणि नंतर त्यांना मिळालेल्या स्वाक्षरी केलेल्या ब्लॉक हेडर्सवर विश्वास ठेवतात.

डेटा उपलब्धता आणि लेयर 2 रोलअप्स

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

तथापि, Ethereum वर पोस्ट केलेल्या 'सारांश' व्यवहारांवर तेव्हाच विश्वास ठेवणे शक्य आहे जेव्हा प्रस्तावित स्टेट बदलाची स्वतंत्रपणे पडताळणी केली जाऊ शकते आणि सर्व वैयक्तिक ऑफचेन व्यवहार लागू केल्याचा तो परिणाम असल्याची पुष्टी केली जाऊ शकते. जर रोलअप ऑपरेटर्सनी या पडताळणीसाठी व्यवहार डेटा उपलब्ध करून दिला नाही, तर ते Ethereum ला चुकीचा डेटा पाठवू शकतात.

ऑप्टिमिस्टिक रोलअप्स संकुचित व्यवहार डेटा Ethereum वर पोस्ट करतात आणि स्वतंत्र पडताळणीकर्त्यांना डेटा तपासण्याची परवानगी देण्यासाठी काही कालावधीसाठी (सामान्यतः 7 दिवस) प्रतीक्षा करतात. जर कोणाला समस्या आढळली, तर ते एक फ्रॉड-प्रूफ तयार करू शकतात आणि रोलअपला आव्हान देण्यासाठी त्याचा वापर करू शकतात. यामुळे चेन रोल बॅक होईल आणि अवैध ब्लॉक वगळला जाईल. हे केवळ डेटा उपलब्ध असल्यास शक्य आहे. सध्या, ऑप्टिमिस्टिक रोलअप्स L1 वर व्यवहार डेटा पोस्ट करण्याचे दोन मार्ग आहेत. काही रोलअप्स डेटा CALLDATA म्हणून कायमस्वरूपी उपलब्ध करून देतात जो ऑनचेन कायमस्वरूपी राहतो. EIP-4844 च्या अंमलबजावणीसह, काही रोलअप्स आपला व्यवहार डेटा त्याऐवजी स्वस्त ब्लॉब स्टोरेजवर पोस्ट करतात. हे कायमस्वरूपी स्टोरेज नाही. Ethereum लेयर-1 मधून डेटा हटवण्यापूर्वी स्वतंत्र पडताळणीकर्त्यांना ~18 दिवसांच्या आत ब्लॉब्सची क्वेरी करावी लागते आणि आपली आव्हाने मांडावी लागतात. त्या लहान निश्चित विंडोसाठी डेटाची उपलब्धता केवळ Ethereum प्रोटोकॉलद्वारे हमी दिली जाते. त्यानंतर, ती Ethereum परिसंस्थेतील इतर घटकांची जबाबदारी बनते. कोणताही नोड DAS वापरून डेटाची उपलब्धता सत्यापित करू शकतो, म्हणजेच, ब्लॉब डेटाचे छोटे, यादृच्छिक नमुने डाउनलोड करून.

झिरो-नॉलेज (ZK) रोलअप्सना व्यवहार डेटा पोस्ट करण्याची आवश्यकता नाही कारण स्टेट ट्रांझिशनच्या अचूकतेची हमी देतात. तथापि, डेटा उपलब्धता अजूनही एक समस्या आहे कारण आपण ZK-रोलअपच्या स्टेट डेटामध्ये प्रवेश केल्याशिवाय त्याच्या कार्यक्षमतेची हमी देऊ शकत नाही (किंवा त्याच्याशी संवाद साधू शकत नाही). उदाहरणार्थ, जर एखाद्या ऑपरेटरने रोलअपच्या स्टेटबद्दल तपशील रोखून ठेवला तर वापरकर्ते त्यांचे बॅलन्स जाणून घेऊ शकत नाहीत. तसेच, ते नव्याने जोडलेल्या ब्लॉकमध्ये असलेली माहिती वापरून स्टेट अपडेट्स करू शकत नाहीत.

डेटा उपलब्धता विरुद्ध डेटा पुनर्प्राप्ती

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

डेटा पुनर्प्राप्ती म्हणजे नोड्सची ब्लॉकचेनमधून ऐतिहासिक माहिती पुनर्प्राप्त करण्याची क्षमता. नवीन ब्लॉक्सची पडताळणी करण्यासाठी या ऐतिहासिक डेटाची आवश्यकता नाही, तो फक्त जेनेसिस ब्लॉकमधून फुल नोड्स सिंक करण्यासाठी किंवा विशिष्ट ऐतिहासिक विनंत्या पूर्ण करण्यासाठी आवश्यक आहे.

मूळ Ethereum प्रोटोकॉल प्रामुख्याने डेटा उपलब्धतेशी संबंधित आहे, डेटा पुनर्प्राप्तीशी नाही. डेटा पुनर्प्राप्ती तृतीय पक्षांद्वारे चालवल्या जाणाऱ्या अर्काइव्ह नोड्सच्या लहान लोकसंख्येद्वारे प्रदान केली जाऊ शकते, किंवा पोर्टल नेटवर्कopens in a new tab सारख्या विकेंद्रित फाइल स्टोरेजचा वापर करून नेटवर्कवर वितरित केली जाऊ शकते.