Secure AltDA Integration for Ethereum L2s: An End-to-End Validation Framework
यह शोध पत्र एथेरियम L2s में सुरक्षित अल्टरनेटिव डेटा अवेलेबिलिटी (AltDA) एकीकरण के लिए एक मानक सत्यापन ढांचे को प्रस्तुत करता है, जो सेलेस्टिया-ब्लोबस्ट्रीम (Celestia-Blobstream) और आइगनडीए (EigenDA) जैसी विविध आर्किटेक्चर के बीच यह सुनिश्चित करके कि प्रत्येक प्रतिकूल इनपुट एक अद्वितीय, सुपरिभाषित परिणाम उत्पन्न करे, सर्वसम्मति विफलताओं और ब्रिज हमलों को रोकने के लिए एक नियतात्मक अनुवाद मॉडल को परिभाषित करता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
इथेरियम (Ethereum) की कल्पना एक विशाल, व्यस्त शहर के रूप में करें जहाँ हर कोई सड़क के नियमों पर सहमत है। इसे तेज़ बनाने के लिए, लोगों ने "लेयर 2" (L2) पड़ोस बनाए। ये पड़ोस अपने स्वयं के ट्रैफ़िक (लेनदेन) को संभालते हैं, लेकिन विवादों को सुलझाने और आधिकारिक रिकॉर्ड रखने के लिए मुख्य शहर (इथेरियम) पर निर्भर रहते हैं।
सामान्यतः, ये पड़ोस अपने ट्रैफ़िक लॉग सीधे मुख्य शहर के बुलेटिन बोर्ड पर पोस्ट करते हैं। लेकिन बुलेटिन बोर्ड की एक आकार सीमा है। यदि बहुत से पड़ोस एक साथ पोस्ट करने की कोशिश करते हैं, तो यह जाम हो जाता है, और ट्रैफ़िक धीमा हो जाता है।
समाधान: "AltDA" कूरियर सेवा
इस समस्या को हल करने के लिए, कुछ पड़ोसों ने वैकल्पिक डेटा उपलब्धता (Alternative Data Availability - AltDA) सिस्टम का उपयोग करना शुरू कर दिया। पूरे लॉग को मुख्य शहर में पोस्ट करने के बजाय, वे शहर में एक छोटा सा "रसीद" (प्रतिबद्धता/commitment) पोस्ट करते हैं और वास्तविक भारी लॉग को एक विशेष, उच्च-गति वाली कूरियर सेवा (जैसे Celestia, EigenDA, या Avail) के पास स्टोर करते हैं।
समस्या: "रसीद" का जाल
यह शोध पत्र तर्क देता है कि केवल एक रसीद होना ही पर्याप्त नहीं है। यह एक रेस्तरां द्वारा आपको उस भोजन के लिए रसीद देने जैसा है जिसे आपने वास्तव में ऑर्डर नहीं किया था, या ऐसी रसीद जो कहती है "पिज्जा", लेकिन रसोई ने वास्तव में "विषाक्त कचरा" परोसा है।
यदि पड़ोस के पास इन रसीदों की जाँच करने के लिए एक सख्त, एंड-टू-एंड नियम पुस्तिका नहीं है, तो बुरे तत्व (bad actors) सिस्टम को धोखा दे सकते हैं। वे ऐसा कर सकते हैं:
- एक वैध रसीद ऐसी लॉग के लिए पोस्ट करना जो अब मौजूद ही नहीं है (कूरियर ने उसे फेंक दिया)।
- एक ऐसी रसीद पोस्ट करना जो लॉग से मेल खाती है, लेकिन लॉग में ऐसे निर्देश हैं जो पड़ोस के नियमों को तोड़ते हैं।
- एक ऐसी रसीद पोस्ट करना जो वैध दिखती है लेकिन अलग-अलग लोगों द्वारा पढ़े जाने पर दो अलग-अलग परिणाम देती है।
यदि पड़ोस की निपटान प्रणाली (न्यायाधीश) पूरी कस्टडी (chain of custody) की जाँच किए बिना इन खराब रसीदों को स्वीकार कर लेती है, तो पड़ोस फ्रीज हो सकता है, या पड़ोसों को जोड़ने वाले ब्रिज के माध्यम से लोग पैसा चुरा सकते हैं।
शोध पत्र का समाधान: "टोटल वैलिडेशन" ढांचा
लेखक एक सख्त, चरण-दर-चरण चेकलिस्ट (एक "कैनोनिकल वैलिडेशन फ्रेमवर्क") प्रस्तावित करते हैं जिसका पालन प्रत्येक पड़ोस को यह सुनिश्चित करने के लिए करना चाहिए कि वे सुरक्षित हैं। वे इस प्रक्रिया की तुलना एक चार-चरणीय सुरक्षा सुरंग से करते हैं:
- इनबॉक्स (मेलबॉक्स): मुख्य शहर पड़ोस के मेलबॉक्स में कागज का एक टुकड़ा (बाइट्स) डालता है। यह कुछ भी हो सकता है—एक वैध रसीद, एक टेढ़ी-मेढ़ी लकीर, या एक खाली पन्ना।
- रसीद की जाँच (कूरियर की सील): पड़ोस यह जाँचता है कि क्या वह कागज कूरियर सेवा से एक वैध रसीद है। क्या हस्ताक्षर असली हैं? क्या रसीद ताज़ा है (एक्सपायर नहीं हुई है)?
- पैकेज का मिलान (बाइंडिंग): पड़ोस वास्तविक लॉग प्राप्त करने के लिए कूरियर के पास जाता है। उन्हें यह साबित करना होगा कि उन्होंने जो लॉग उठाया है वह उनकी रसीद से बिल्कुल मेल खाता है। कोई अदला-बदली नहीं चलेगी।
- अनुवाद (पेलोड): अंत में, उन्हें लॉग को पड़ोस के लिए एक स्पष्ट निर्देश में अनुवादित करना होगा। यदि लॉग निरर्थक है, या यदि दो अलग-अलग लोग इसे अलग तरह से अनुवादित करेंगे, तो सिस्टम को इसे तुरंत अस्वीकार कर देना चाहिए।
स्वर्ण नियम: "हर चीज़ का एक उत्तर होना चाहिए"
पेपर का सबसे महत्वपूर्ण विचार टोटल वैलिडेशन (Total Validation) है।
- यदि इनपुट अच्छा है, तो सिस्टम कहता है: "यहाँ एक वैध निर्देश है।"
- यदि इनपुट खराब है (नकली रसीद, एक्सपायर्ड, गलत पैकेज), तो सिस्टम को कहना चाहिए: "इसे अस्वीकार करें।"
- यदि इनपुट अस्थायी रूप से अनुपलब्ध है (कूरियर ब्रेक पर है), तो सिस्टम को कहना चाहिए: "रुको, लेकिन क्रैश मत हो।"
सिस्टम को यह कहने की अनुमति नहीं है कि, "मुझे नहीं पता कि इसके साथ क्या करना है," और फिर फ्रीज या पैनिक हो जाना। इसके पास हमेशा एक स्पष्ट, नियत (deterministic) उत्तर होना चाहिए।
उन्होंने क्या पाया
लेखकों ने वास्तविक दुनिया के उदाहरणों (जैसे Celestia, EigenDA, और Avвail का उपयोग करने वाले सिस्टम) को देखा और इस चेकलिस्ट को लागू किया। उन्होंने पाया कि:
- कुछ सिस्टम रसीद की जाँच करने में बहुत अच्छे थे (DA Verifier)।
- लेकिन कई सिस्टम बीच के चरणों में कमी रखते थे, जैसे यह जाँचने में कि क्या रसीद बहुत पुरानी थी (Recency) या यह सुनिश्चित करने में कि लॉग रसीद से पूरी तरह मेल खाता है (Binding)।
- उन्होंने दिखाया कि यदि आप इनमें से एक भी चरण छोड़ देते हैं, तो बुरे तत्व "अंडर-कंस्ट्रेंड" (Under-constrained) स्थितियाँ पैदा कर सकते हैं जहाँ वे एक ऐसे स्टेट परिवर्तन का दावा कर सकते हैं जिसे सिस्टम स्वीकार करता है, भले ही डेटा वास्तव में उसका समर्थन न करता हो। इससे ब्रिज हैक हो सकते हैं या पूरा नेटवर्क फ्रीज हो सकता है।
मुख्य निष्कर्ष
सुरक्षा केवल कूरियर सेवा के ईमानदार होने के बारे में नहीं है। यह पड़ोस के भीतर की पूरी प्रक्रिया के बारे में है। आपके पास दुनिया का सबसे अच्छा कूरियर हो सकता है, लेकिन यदि आपके पड़ोस के रसीदों की जाँच करने के आंतरिक नियम ढीले हैं, तो पूरा सिस्टम असुरक्षित है। यह शोध पत्र उन आंतरिक नियमों को बनाने के लिए एक ब्लूप्रिंट प्रदान करता है ताकि डेटा का हर एक हिस्सा, आधिकारिक इतिहास का हिस्सा बनने से पहले, सही ढंग से जांचा, सत्यापित और अनुवादित किया जा सके।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।