( आईएफएमएसए के लेनन वॉल सौजन्य की छवि )

जब ये नोट लिखे जा रहे थे, यूक्रेन में पुतिन के संवेदनहीन युद्ध ने किसी को भी अछूता नहीं छोड़ा और स्थिति कोई अपवाद नहीं है: हमारे यूक्रेनी योगदानकर्ताओं को उनके परिवारों के साथ बम आश्रयों में मजबूर किया गया है क्योंकि क्रूरताएं बढ़ती हैं: यहां कई हैं ऐसे तरीके जिनसे आप मदद कर सकते हैं: https://hrf.org/how-to-support-ukrainians/

इसके अलावा, रूस और यूक्रेन में नागरिकों की बढ़ती संख्या संचार करने, समाचारों तक पहुंचने और सेंसरशिप से निपटने के लिए टोर परियोजना का उपयोग कर रही है। आप टोर ब्रिज स्थापित करके उनकी मदद कर सकते हैं: https://community.torproject.org/relay/setup/bridge/

दो हफ्ते पहले हमने Nimbus को प्रकाशित किया था , जो हमारे सर्वसम्मति परत क्लाइंट के लिए v1.7.0विशेष रूप से फीचर-पैक रिलीज है।

यदि आपने पहले से ऐसा नहीं किया है, तो हम आपको सभी रक्तरंजित विवरणों के लिए पूर्ण रिलीज़ नोट देखने के लिए प्रोत्साहित करते हैं।

हालांकि, कुछ ऐसे महत्वपूर्ण विषय हैं, जिन्हें नोट्स में शामिल नहीं किया गया था, जो हमें लगता है कि लंबे रूप में तलाशने लायक हैं।

विशेष रूप से, हम चेकपॉइंट सिंक की सुरक्षा में सुधार करने के तरीके पर एक चर्चा खोलना चाहते हैं , और दूसरा ईआईपी -4444 दुनिया में ऐतिहासिक डेटा क्वेरी लाने के बारे में कैसे जाना है।

इंसिकुरा नेटवर्क (या चेकपॉइंट सिंक का फायदा उठाने का तरीका)

प्रूफ-ऑफ-स्टेक पर कुख्यात हमलों में से एक तथाकथित लंबी दूरी का हमला है, जहां समझौता की गई चाबियों का उपयोग एक नया इतिहास बनाने के लिए किया जाता है जो ईमानदार नोड्स (जो पर्याप्त समय के लिए ऑफ़लाइन हैं) स्वीकार करते हैं मान्य के रूप में।

व्यवहार में ऐसा कैसे हो सकता है? इसका लंबा और छोटा यह है कि बीकन श्रृंखला में एक जीवंतता तंत्र है जो निष्क्रिय सत्यापनकर्ताओं से बाहर निकलता है। एक अल्पसंख्यक खिलाड़ी के लिए एक इतिहास बनाने के लिए इस तंत्र का दुरुपयोग करना संभव है जिसमें अपने स्वयं के अलावा सभी सत्यापनकर्ताओं को बाहर निकलने के लिए मजबूर किया जाता है, जिससे उनके अल्पसंख्यक बहुमत में बदल जाते हैं (उनके कांटे पर)।

एक बार ऐसा कांटा मौजूद हो जाने पर, विचार यह है कि एक हमलावर कमजोर व्यक्तिपरकता का फायदा उठाने की कोशिश कर सकता है ताकि अन्य नोड्स इसे प्रामाणिक के रूप में स्वीकार कर सकें।

सौभाग्य से, कमजोर व्यक्तिपरकता, जैसा कि मूल रूप से सोचा गया था, इस तरह के हमले के लिए काफी प्रतिरोधी है। जब तक कांटा के समय 1/3 से कम चाबियों से समझौता किया जाता है, ईमानदार नोड्स हमलावर की तुलना में बहुत अधिक प्रशंसनीय इतिहास प्रदान करते हैं: क्योंकि हमलावर की श्रृंखला के विपरीत जिसमें गैर-अंतिमता की लंबी अवधि होती है ईमानदार सत्यापनकर्ता अपनी हिस्सेदारी को लीक होते देख रहे हैं, ईमानदार नोड्स के पास एक अंतिम श्रृंखला है।

भले ही एक हमलावर सभी चाबियों के 2/3 से अधिक को नियंत्रित करता है जो शत्रुतापूर्ण कांटे के बिंदु पर सक्रिय थे, यह स्पष्ट नहीं है कि वे नेटवर्क को यह समझाने में सफल होंगे कि उनका वैकल्पिक इतिहास सही है। विशेष रूप से, यदि एक ईमानदार नोड को ग्रहण नहीं किया जा रहा है , तो यह अभी भी विहित श्रृंखला को केवल इसलिए चुनेगा क्योंकि इसकी सेवा करने वाले अधिक साथी हैं।

हालांकि, यह पता चला है कि चेकपॉइंट सिंक चीजों को काफी हद तक बदल देता है । विशेष रूप से, यह स्पष्ट नहीं है कि उपरोक्त तर्क अभी भी कायम है या नहीं। यह काफी प्रति-सहज है। आखिरकार, हैश के बजाय URL में पास होने से नेटवर्क की सुरक्षा मान्यताओं पर इतना फर्क क्यों पड़ता है?

जैसा कि अक्सर सुरक्षा मान्यताओं के मामले में होता है, शैतान विवरण में निहित है। यह निम्नलिखित के लिए उबलता है: हमने अपेक्षित व्यवहार को "एक दोस्त से ब्लॉक हैश प्राप्त करना" (जैसा कि कमजोर विषय पर विटालिक की मूल पोस्ट में व्यक्त किया गया है) से "मुट्ठी भर केंद्रीकृत में से एक यूआरएल पर भरोसा करना" में स्थानांतरित कर दिया है। संस्थाएं"। इसके महत्वपूर्ण परिणाम हैं।

जेसेक को यहां व्याख्या करने के लिए, चेकपॉइंट सिंक उपयोगकर्ताओं को एक केंद्रीकृत इकाई (इंफुरा या इथरस्कैन के बारे में सोचें) से बीकन नोड में एक यूआरएल पास करना सिखाता है ।

यदि इस URL से छेड़छाड़ की गई है (केंद्रीकृत इकाई में सुरक्षा उल्लंघन के बारे में सोचें), तो एक हमलावर ग्राहक को अपनी इच्छानुसार किसी भी राज्य को खिला सकता है , और जब तक यह कुछ बुनियादी विवेक जांच पास करता है, तब तक ग्राहक उस पर "विश्वास" करेगा। विशेष रूप से, हमलावर उपयोगकर्ता को एक ऐसी स्थिति में पारित कर सकता है जिसने एक वैकल्पिक इतिहास को अंतिम रूप दिया है (दूसरे शब्दों में, एक अलग बिंदु जहां से विहित सत्यापनकर्ता हैं)।

यदि कोई नोड इस समझौता राज्य से समन्वयित करना शुरू कर देता है, तो यह किसी भी कनेक्शन को अस्वीकार कर देगा, और ईमानदार और सही साथियों से अवरुद्ध हो जाएगा। यह केवल समझौता किए गए या बेईमान साथियों को स्वीकार करने में सक्षम होगा, क्योंकि हमलावर की श्रृंखला को एक ऐसे बिंदु पर अंतिम रूप दिया जाता है जिसे विहित के साथ समेटा नहीं जा सकता है।

सौभाग्य से, जेसेक बताते हैं कि जिस तरह से यह विशेष समस्या उत्पन्न होती है, उसका कई तरीकों से पता लगाया जा सकता है। विशेष रूप से, इस तरह का हमला हमें रास्ते में कई लाल झंडे प्रदान करता है ( पूर्ण अभिव्यक्ति के लिए इस पोस्ट का अंत देखें)।

डैनी रयान ने कुछ और विचार पोस्ट किए हैं कि हम इस समस्या को कैसे हल कर सकते हैं। आगे के दो सबसे दिलचस्प रास्तों में शामिल हैं:

  • एन प्रतिभागी चेकपॉइंट डाउनलोड : एक केंद्रीकृत इकाई की विश्वसनीयता पर भरोसा करने के बजाय, एन संस्थाओं से पूछताछ करें और एकमत की जांच करें
  • बूटनोड्स के लिए उनके प्रकाशित ईएनआर में चौकियों को शामिल करने के लिए एक तरीका डिज़ाइन करेंwsr - उदाहरण के लिए एक वैकल्पिक (कमजोर-व्यक्तिपरकता-रूट) फ़ील्ड जोड़कर । ध्यान दें कि हम केवल बूटनोड्स को क्वेरी करने पर भरोसा नहीं कर सकते क्योंकि वे लगभग हमेशा अपनी सहकर्मी सीमा पर होते हैं। दूसरे शब्दों में, हम यह नहीं मान सकते हैं कि सभी क्लाइंट बूटनोड से कनेक्शन बनाए रखने में सक्षम होंगे।

हमें लगता है कि इस चर्चा को आगे बढ़ाने का समय आ गया है।

यदि आप यहां मातम में जाना चाहते हैं, तो जेसेक के विस्तृत लेखन की जांच करना सुनिश्चित करें । उसने वास्तव में पाइरमोंट पर इस हमले को अंजाम दिया है, और पोस्ट आपको बताता है कि यह कैसे किया गया था।

युग फ़ाइलें (ऐतिहासिक डेटा प्रश्नों का एक प्रस्तावित समाधान)

इथेरियम क्लाइंट वर्तमान में 275 जीबी ऐतिहासिक डेटा संग्रहीत करते हैं। लेकिन इस डेटा को वास्तव में श्रृंखला को मान्य करने की आवश्यकता नहीं है।

यह प्रति वर्ष लगभग 140 जीबी की दर से बढ़ रहा है, और विलय के बाद की दुनिया में तेजी लाने के लिए तैयार है। EIP-4444 एक प्रस्ताव है जो ग्राहकों को 1 वर्ष से अधिक पुराने डेटा की छंटाई करके इस डेटा ब्लोट को संबोधित करने का प्रयास करता है।

हालांकि, समुदाय द्वारा कुछ वैध चिंताओं को आवाज दी गई है। विशेष रूप से, यह स्पष्ट नहीं है कि पी2पी परत (कुछ ईआईपी-4444 स्पष्ट रूप से अनिवार्य है) पर ऐतिहासिक डेटा की सेवा करने से नोड्स को रोकने से कितना नुकसान होता है।

इन चिंताओं के आलोक में, जेसेक के हालिया एरा फाइल प्रस्ताव (यहां एक मसौदा पीआर देखें ) को एक मध्य मैदान के रूप में देखा जा सकता है।

एक युग फ़ाइल वास्तव में क्या है? जेसेक के शब्दों को उधार लेने के लिए, एक युग फ़ाइल केवल ब्लॉक का एक दिन है जिसके बाद उस बिंदु पर सर्वसम्मति को फिर से बनाने के लिए आवश्यक डेटा होता है: यदि आपके पास एक समन्वयित नोड है जो वर्तमान बीकन श्रृंखला सिर को जानता है, तो युग फ़ाइलों में डेटा को फिर से बनाने के लिए उपयोग किया जा सकता है उस समय सीमा के लिए पूरी तरह से सत्यापित ऐतिहासिक स्थिति।

युग फ़ाइलें, एक बार बनाई गई, आसानी से पहचाने जाने योग्य, अपरिवर्तनीय और बेकार हैं: पूरी तरह से समन्वयित नोड वाला कोई भी व्यक्ति एक बना सकता है और/या सत्यापित कर सकता है, और उन्हें किसी भी नई सुरक्षा समस्या को पेश किए बिना अविश्वसनीय तृतीय-पक्ष द्वारा साझा किया जा सकता है।

महत्वपूर्ण रूप से, एक युग फ़ाइल भविष्य में डेटाबेस सुरक्षा उद्देश्यों के लिए सत्य के स्रोत के रूप में रहता है - यह नवीनतम सिंक किए गए हेड रूट को संग्रहीत करता है जो बदले में यह निर्धारित करता है कि एक नोड अपनी आम सहमति भागीदारी को "शुरू" करता है। युग निर्देशिका हालांकि बिना किसी (महत्वपूर्ण) सुरक्षा निहितार्थ के नोड्स / लोगों के बीच स्वतंत्र रूप से साझा की जा सकती है, यह मानते हुए कि युग फाइलें सुसंगत हैं (अर्थात टूटी नहीं)।

यह इंगित करना महत्वपूर्ण है कि, अभी के लिए, युग की फाइलें केवल आम सहमति को कवर करती हैं - दूसरे शब्दों में, पूर्ण एथेरियम राज्य नहीं।

विलय के बाद, वे ब्लॉक डेटा को कवर करना शुरू कर देंगे, लेकिन फिर भी एथेरियम राज्य को कवर नहीं करेंगे। संपूर्ण ईआईपी 4444 विश्व का समर्थन करना एक खुला शोध विषय है। लेकिन आम सहमति पर ध्यान केंद्रित करने से समस्या का एक महत्वपूर्ण हिस्सा हल हो जाता है: यानी यह जानना कि कौन सा राज्य प्रासंगिक है; यह व्यापक समस्या को एक ट्रैक्टेबल में बदल देता है।

भविष्य में सुधार के लिए विचारों में आरईएसटी के माध्यम से युग फाइलों की सेवा शामिल है: वर्तमान कार्यान्वयन के विपरीत जो ब्लॉक द्वारा ब्लॉक डाउनलोड करता है, एक समय में एक युग डाउनलोड करने से अनुरोध ओवरहेड लगभग पूरी तरह से कट जाएगा।

एक स्वाभाविक सवाल यह है कि युग फाइलें नोड्स के लिए डिस्क भंडारण आवश्यकताओं को कैसे प्रभावित करती हैं?

यह बदल जाता है कि उत्तर आपके द्वारा चलाए जा रहे नोड के प्रकार पर निर्भर करता है, साथ ही साथ प्रासंगिक मेटापैरमीटर कैसे चुने जाते हैं।

हम इस स्तर पर कुछ विचारशील प्रतिक्रिया सुनना पसंद करेंगे। क्या यह एक अच्छा विचार है या नहीं? इसे कहाँ सुधारा जा सकता है? इसमें क्या कमी है?

इसके अतिरिक्त, हम मानते हैं कि निष्पादन (eth1) स्तर पर युग फ़ाइलों (या कुछ समान) की भूमिका होती है। इन (टोरेंटेड) फाइलों का उपयोग पोर्टल नेटवर्क को सीड करने के लिए किया जा सकता है । वास्तव में, पोर्टल नेटवर्क ने हाल ही में प्राथमिकता को स्थानांतरित कर दिया है, राज्य नेटवर्क पर काम करने से लेकर श्रृंखला इतिहास तक, ज्यादातर EIP-4444 के कारण। सामान्य अपडेट के लिए यहां देखें ।

लाइट क्लाइंट सिंक के लिए एक libp2p प्रोटोकॉल

हमने लाइट क्लाइंट सिंक के लिए हमारे प्रस्तावित (सर्वर साइड) libp2p प्रोटोकॉल का एक मसौदा कार्यान्वयन प्रकाशित किया है।

लाइट क्लाइंट को अतिरिक्त डेटा प्रदान करने के लिए पूर्ण नोड्स की आवश्यकता होती है ताकि वे नेटवर्क के साथ सिंक में रह सकें। इस मसौदे में एक नया लॉन्च विकल्प शामिल है --serve-light-client-dataजो एक पूर्ण नोड को प्रासंगिक डेटा एकत्र करने और प्रकाश ग्राहकों को प्रसारित करने की अनुमति देता है।

यह सर्वसम्मति के चश्मे में हमारे हालिया योगदान का कार्यान्वयन है ।

कुछ संदर्भों के लिए, अल्टेयर स्पेक्स को अद्यतन करने की आवश्यकता थी, क्योंकि जब उन्होंने हल्के क्लाइंट विकास में सहायता के लिए संरचनाओं को परिभाषित किया, तो वे नेटवर्क प्रोटोकॉल परिभाषा को याद कर रहे थे।

इस अंतर को भरने के लिए, Etan ने एक libp2p आधारित प्रोटोकॉल पेश कियाBeaconBlockHeader , ताकि लाइट क्लाइंट्स को नवीनतम के साथ एक भरोसेमंद और विकेन्द्रीकृत तरीके से सिंक करने की अनुमति मिल सके । यह ह्सियाओ-वेई वांग और जिन हुआंग दोनों के पूर्व कार्य के शीर्ष पर निर्मित होता है । आप यहाँ Etan के PR पर नज़र रख सकते हैं ।

उपयोगी संदर्भ: पिछले साल के अंत में, हमने लिखा था कि विलय के बाद एथेरियम के लिए लाइट क्लाइंट कितने महत्वपूर्ण हैं । एक अलग पोस्ट में हमने यह भी बताया कि आगे बढ़ने के लिए यह हमारे लिए फोकस का क्षेत्र कैसे होगा ।

वाउच समर्थन

अंतिम, लेकिन कम से कम, अब हम वाउचर के साथ पूरी तरह से संगत हैं! जिम के लिए एक बड़ा चिल्लाहट जो हमारे आरईएसटी एपीआई कार्यान्वयन की संगतता का परीक्षण, तनाव और सत्यापन करने में अथक रूप से हमारी सहायता कर रहा है।

चूंकि वाउचर प्रदाताओं के लिए एक प्रकार का मानक बनता जा रहा है, यह क्लाइंट विविधता के लिए बहुत अच्छी खबर है: यह अब उन प्रदाताओं के लिए निर्बाध है जो वैकल्पिक क्लाइंट के रूप में निंबस को जोड़ने के लिए वाउच का उपयोग करते हैं।

वाउच अन्य सत्यापनकर्ता ग्राहकों को उनके बीकन नोड के रूप में निंबस के साथ चलने की अनुमति देता है। उदाहरण के लिए, लाइटहाउस ने अपने वीसी को निंबस बीएन के साथ सफलतापूर्वक चलाया है ।

हम वर्तमान में कई प्रदाताओं के साथ बात कर रहे हैं कि वे अपने बेड़े में निंबस को जोड़ने के लिए क्या कर सकते हैं। यदि आप एक प्रदाता हैं, और निंबस को अपने साथ जोड़ने पर विचार कर रहे हैं, तो कृपया हमारे साथ nimbus@status.im पर संपर्क करें , या वैकल्पिक रूप से हमारे विवाद पर हमसे संपर्क करें । हमें आपके किसी भी प्रश्न का उत्तर देने में बहुत खुशी हो रही है और आपको किसी भी मार्गदर्शन और सहायता की आवश्यकता हो सकती है।

❤️