नेटवर्किंग स्तर

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

क्लायंट सॉफ्टवेअरचे दोन भाग आहेत (एक्झिक्युशन क्लायंट आणि कन्सेन्सस क्लायंट), प्रत्येकाचा स्वतःचा वेगळा नेटवर्किंग स्टॅक आहे. इतर Ethereum नोड्सशी संवाद साधण्याव्यतिरिक्त, एक्झिक्युशन आणि कन्सेन्सस क्लायंटना एकमेकांशी संवाद साधावा लागतो. हे पृष्ठ या संवादास सक्षम करणाऱ्या प्रोटोकॉलचे प्रास्ताविक स्पष्टीकरण देते.

एक्झिक्युशन क्लायंट एक्झिक्युशन-लेयर पियर-टू-पियर नेटवर्कवर व्यवहारांची गॉसिपिंग करतात. यासाठी प्रमाणित पियर्समध्ये एनक्रिप्टेड संवादाची आवश्यकता असते. जेव्हा ब्लॉक प्रस्तावित करण्यासाठी व्हॅलिडेटर निवडला जातो, तेव्हा नोडच्या स्थानिक ट्रान्झॅक्शन पूलमधून व्यवहार स्थानिक RPC कनेक्शनद्वारे कन्सेन्सस क्लायंटकडे पाठवले जातात, जे बीकन ब्लॉक्समध्ये पॅकेज केले जातील. त्यानंतर कन्सेन्सस क्लायंट त्यांच्या p2p नेटवर्कवर बीकन ब्लॉक्सची गॉसिपिंग करतील. यासाठी दोन स्वतंत्र p2p नेटवर्क आवश्यक आहेत: एक ट्रान्झॅक्शन गॉसिपसाठी एक्झिक्युशन क्लायंट्सना जोडणारे आणि दुसरे ब्लॉक गॉसिपसाठी कन्सेन्सस क्लायंट्सना जोडणारे.

पूर्वतयारी

हे पृष्ठ समजून घेण्यासाठी Ethereum नोड्स आणि क्लायंट यांचे काही ज्ञान उपयुक्त ठरेल.

एक्झिक्युशन लेयर

एक्झिक्युशन लेयरचे नेटवर्किंग प्रोटोकॉल दोन स्टॅक्समध्ये विभागलेले आहेत:

• डिस्कव्हरी स्टॅक: UDP वर तयार केलेला आहे आणि नवीन नोडला कनेक्ट करण्यासाठी पियर्स शोधण्याची परवानगी देतो

• DevP2P स्टॅक: TCP वर आधारित आहे आणि नोड्सना माहितीची देवाणघेवाण करण्यास सक्षम करतो

दोन्ही स्टॅक समांतरपणे कार्य करतात. डिस्कव्हरी स्टॅक नेटवर्कमध्ये नवीन नेटवर्क सहभागींना आणतो, आणि DevP2P स्टॅक त्यांच्या परस्परसंवादांना सक्षम करतो.

डिस्कव्हरी

डिस्कव्हरी म्हणजे नेटवर्कमधील इतर नोड्स शोधण्याची प्रक्रिया. हे बूटनोड्सच्या (नोड्स ज्यांचे पत्ते क्लायंटमध्ये हार्डकोड केलेले (opens in a new tab) असतात जेणेकरून ते त्वरित शोधता येतील आणि क्लायंटला पियर्सशी कनेक्ट करता येईल) एका छोट्या सेटचा वापर करून बूटस्ट्रॅप केले जाते. हे बूटनोड्स फक्त एका नवीन नोडला पियर्सच्या सेटशी ओळख करून देण्यासाठी अस्तित्वात आहेत - हाच त्यांचा एकमेव उद्देश आहे, ते चेन सिंक करण्यासारख्या सामान्य क्लायंट कार्यांमध्ये सहभागी होत नाहीत, आणि ते फक्त क्लायंट पहिल्यांदा सुरू झाल्यावरच वापरले जातात.

नोड-बूटनोड परस्परसंवादासाठी वापरला जाणारा प्रोटोकॉल काडेम्लिया (opens in a new tab) चे सुधारित रूप आहे जे नोड्सच्या याद्या शेअर करण्यासाठी डिस्ट्रिब्युटेड हॅश टेबल (opens in a new tab) वापरते. प्रत्येक नोडकडे या टेबलची एक आवृत्ती असते ज्यात त्याच्या सर्वात जवळच्या पियर्सशी कनेक्ट करण्यासाठी आवश्यक माहिती असते. ही 'जवळीक' भौगोलिक नाही - अंतर नोडच्या ID च्या समानतेनुसार परिभाषित केले जाते. प्रत्येक नोडची टेबल सुरक्षा वैशिष्ट्य म्हणून नियमितपणे रिफ्रेश केली जाते. उदाहरणार्थ, Discv5 (opens in a new tab) डिस्कव्हरी प्रोटोकॉलमध्ये नोड्स 'जाहिराती' देखील पाठवू शकतात, जे क्लायंटद्वारे समर्थित सब-प्रोटोकॉल दर्शवतात, ज्यामुळे पियर्स संवाद साधण्यासाठी वापरल्या जाऊ शकणाऱ्या प्रोटोकॉलबद्दल वाटाघाटी करू शकतात.

डिस्कव्हरी पिंग-पॉन्गच्या खेळाने सुरू होते. एक यशस्वी पिंग-पॉन्ग नवीन नोडला बूटनोडशी "बॉण्ड" करतो. नेटवर्कमध्ये प्रवेश करणाऱ्या नवीन नोडच्या अस्तित्वाची बूटनोडला सूचना देणारा प्रारंभिक संदेश म्हणजे PING. या PING मध्ये नवीन नोड, बूटनोड आणि एक एक्स्पायरी टाइम-स्टॅम्पबद्दल हॅश केलेली माहिती असते. बूटनोड PING प्राप्त करतो आणि PING हॅश असलेला PONG परत करतो. जर PING आणि PONG हॅश जुळले तर नवीन नोड आणि बूटनोडमधील कनेक्शनची पडताळणी केली जाते आणि ते "बॉन्डेड" झाले आहेत असे म्हटले जाते.

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

एकदा नवीन नोडला बूटनोडकडून शेजाऱ्यांची यादी मिळाल्यावर, तो त्या प्रत्येकाशी पिंग-पॉन्ग एक्सचेंज सुरू करतो. यशस्वी पिंग-पॉन्ग नवीन नोडला त्याच्या शेजाऱ्यांशी बॉण्ड करतात, ज्यामुळे संदेशांची देवाणघेवाण शक्य होते.

1क्लायंट सुरू करा --> बूटनोडला कनेक्ट करा --> बूटनोडशी बॉण्ड करा --> शेजारी शोधा --> शेजाऱ्यांशी बॉण्ड करा

एक्झिक्युशन क्लायंट सध्या Discv4 (opens in a new tab) डिस्कव्हरी प्रोटोकॉल वापरत आहेत आणि Discv5 (opens in a new tab) प्रोटोकॉलमध्ये स्थलांतरित होण्यासाठी सक्रिय प्रयत्न सुरू आहेत.

ENR: Ethereum नोड रेकॉर्ड्स

Ethereum नोड रेकॉर्ड (ENR) एक ऑब्जेक्ट आहे ज्यामध्ये तीन मूलभूत घटक आहेत: एक स्वाक्षरी (काही मान्य ओळख योजनेनुसार बनवलेल्या रेकॉर्ड सामग्रीचा हॅश), रेकॉर्डमधील बदलांचा मागोवा घेणारा एक क्रम क्रमांक, आणि की:व्हॅल्यू जोड्यांची एक अनियंत्रित यादी. हे एक भविष्यासाठी सुरक्षित स्वरूप आहे जे नवीन पियर्समध्ये ओळखणारी माहितीची सुलभ देवाणघेवाण करण्यास अनुमती देते आणि Ethereum नोड्ससाठी प्राधान्य दिलेले नेटवर्क अॅड्रेस स्वरूप आहे.

डिस्कव्हरी UDP वर का तयार केली आहे?

UDP कोणतीही त्रुटी तपासणी, अयशस्वी पॅकेट पुन्हा पाठवणे, किंवा कनेक्शन डायनॅमिकपणे उघडणे आणि बंद करणे याला समर्थन देत नाही - त्याऐवजी ते लक्ष्यावर माहितीचा सतत प्रवाह पाठवते, मग ती यशस्वीरित्या प्राप्त झाली आहे की नाही याची पर्वा न करता. ही किमान कार्यक्षमता किमान ओव्हरहेडमध्ये रूपांतरित होते, ज्यामुळे अशा प्रकारचे कनेक्शन खूप वेगवान होते. डिस्कव्हरीसाठी, जिथे नोडला फक्त त्याचे अस्तित्व ज्ञात करायचे असते जेणेकरून नंतर पियरशी औपचारिक कनेक्शन स्थापित करता येईल, तिथे UDP पुरेसे आहे. तथापि, उर्वरित नेटवर्किंग स्टॅकसाठी, UDP उद्देशासाठी योग्य नाही. नोड्समधील माहितीची देवाणघेवाण खूपच गुंतागुंतीची आहे आणि म्हणून पुन्हा पाठवणे, त्रुटी तपासणी इत्यादींना समर्थन देऊ शकणाऱ्या अधिक पूर्ण वैशिष्ट्यीकृत प्रोटोकॉलची आवश्यकता आहे. TCP शी संबंधित अतिरिक्त ओव्हरहेड अतिरिक्त कार्यक्षमतेसाठी योग्य आहे. म्हणून, P2P स्टॅकचा बहुतांश भाग TCP वर कार्य करतो.

DevP2P

DevP2P स्वतःच प्रोटोकॉलचा एक संपूर्ण स्टॅक आहे जो Ethereum पियर-टू-पियर नेटवर्क स्थापित करण्यासाठी आणि राखण्यासाठी लागू करतो. नवीन नोड्स नेटवर्कमध्ये प्रवेश केल्यानंतर, त्यांचे परस्परसंवाद DevP2P (opens in a new tab) स्टॅकमधील प्रोटोकॉलद्वारे नियंत्रित केले जातात. हे सर्व TCP वर आधारित आहेत आणि त्यात RLPx ट्रान्सपोर्ट प्रोटोकॉल, वायर प्रोटोकॉल आणि अनेक सब-प्रोटोकॉल समाविष्ट आहेत. RLPx (opens in a new tab) हा नोड्समधील सत्रे सुरू करणे, प्रमाणित करणे आणि राखणे नियंत्रित करणारा प्रोटोकॉल आहे. RLPx संदेश एन्कोड करण्यासाठी RLP (रिकर्सिव्ह लेंथ प्रीफिक्स) वापरतो जी नोड्समध्ये पाठवण्यासाठी डेटाला किमान संरचनेत एन्कोड करण्याची एक अत्यंत जागा-कार्यक्षम पद्धत आहे.

दोन नोड्समधील RLPx सत्र प्रारंभिक क्रिप्टोग्राफिक हँडशेकने सुरू होते. यामध्ये नोड एक ऑथ मेसेज पाठवतो जो नंतर पियरद्वारे सत्यापित केला जातो. यशस्वी पडताळणीवर, पियर प्रारंभकर्ता नोडला परत करण्यासाठी एक ऑथ-अॅकनॉलेजमेंट संदेश तयार करतो. ही एक की-एक्सचेंज प्रक्रिया आहे जी नोड्सना खाजगी आणि सुरक्षितपणे संवाद साधण्यास सक्षम करते. एक यशस्वी क्रिप्टोग्राफिक हँडशेक नंतर दोन्ही नोड्सना एकमेकांना "ऑन द वायर" एक "हॅलो" संदेश पाठवण्यासाठी ट्रिगर करतो. वायर प्रोटोकॉल हॅलो संदेशांच्या यशस्वी देवाणघेवाणीने सुरू होतो.

हॅलो संदेशांमध्ये खालील गोष्टी असतात:

• प्रोटोकॉल आवृत्ती
• क्लायंट आयडी
• पोर्ट
• नोड आयडी
• समर्थित सब-प्रोटोकॉलची यादी

यशस्वी परस्परसंवादासाठी ही आवश्यक माहिती आहे कारण ती दोन्ही नोड्समध्ये कोणती क्षमता सामायिक केली आहे हे परिभाषित करते आणि संवाद कॉन्फिगर करते. सब-प्रोटोकॉल वाटाघाटीची एक प्रक्रिया आहे जिथे प्रत्येक नोडद्वारे समर्थित सब-प्रोटोकॉलच्या याद्यांची तुलना केली जाते आणि जे दोन्ही नोड्ससाठी सामान्य आहेत ते सत्रात वापरले जाऊ शकतात.

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

सब-प्रोटोकॉल्स

वायर प्रोटोकॉल

एकदा पियर्स कनेक्ट झाल्यावर, आणि RLPx सत्र सुरू झाल्यावर, वायर प्रोटोकॉल पियर्स कसे संवाद साधतील हे परिभाषित करतो. सुरुवातीला, वायर प्रोटोकॉलने तीन मुख्य कार्ये परिभाषित केली: चेन सिंक्रोनाइझेशन, ब्लॉक प्रोपगेशन आणि ट्रान्झॅक्शन एक्सचेंज. तथापि, एकदा Ethereum प्रूफ-ऑफ-स्टेकवर स्विच झाल्यावर, ब्लॉक प्रोपगेशन आणि चेन सिंक्रोनाइझेशन कन्सेन्सस लेयरचा भाग बनले. ट्रान्झॅक्शन एक्सचेंज अजूनही एक्झिक्युशन क्लायंटच्या अखत्यारित आहे. ट्रान्झॅक्शन एक्सचेंज म्हणजे नोड्समध्ये प्रलंबित व्यवहारांची देवाणघेवाण करणे जेणेकरून ब्लॉक बिल्डर्स त्यापैकी काही पुढील ब्लॉकमध्ये समाविष्ट करण्यासाठी निवडू शकतील. या कार्यांविषयी तपशीलवार माहिती येथे (opens in a new tab) उपलब्ध आहे. या सब-प्रोटोकॉलला समर्थन देणारे क्लायंट त्यांना JSON-RPC द्वारे उघड करतात.

les (लाइट Ethereum सबप्रोटोकॉल)

हा लाईट क्लायंट सिंक करण्यासाठी एक किमान प्रोटोकॉल आहे. पारंपारिकपणे हा प्रोटोकॉल क्वचितच वापरला जातो कारण पूर्ण नोड्सना लाईट क्लायंटना डेटा देण्यासाठी प्रोत्साहन न देता आवश्यक असते. एक्झिक्युशन क्लायंटचे डीफॉल्ट वर्तन हे les वर लाईट क्लायंट डेटा सर्व्ह करणे नाही. अधिक माहिती les spec (opens in a new tab) मध्ये उपलब्ध आहे.

स्नॅप

स्नॅप प्रोटोकॉल (opens in a new tab) एक वैकल्पिक विस्तार आहे जो पियर्सना अलीकडील स्टेट्सचे स्नॅपशॉट एक्सचेंज करण्याची परवानगी देतो, ज्यामुळे पियर्सना इंटरमीडिएट मर्केल ट्राय नोड्स डाउनलोड न करता अकाउंट आणि स्टोरेज डेटाची पडताळणी करता येते.

विट (विटनेस प्रोटोकॉल)

विटनेस प्रोटोकॉल (opens in a new tab) एक वैकल्पिक विस्तार आहे जो पियर्समध्ये स्टेट विटनेसची देवाणघेवाण सक्षम करतो, ज्यामुळे क्लायंटला चेनच्या टोकापर्यंत सिंक करण्यास मदत होते.

व्हिस्पर

व्हिस्पर हा एक प्रोटोकॉल होता ज्याचा उद्देश ब्लॉकचेनवर कोणतीही माहिती न लिहिता पियर्समध्ये सुरक्षित मेसेजिंग वितरित करणे हा होता. हा DevP2P वायर प्रोटोकॉलचा भाग होता परंतु आता तो नापसंत आहे. समान उद्देशांसह इतर संबंधित प्रकल्प (opens in a new tab) अस्तित्वात आहेत.

कन्सेन्सस लेयर

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

डिस्कव्हरी

एक्झिक्युशन क्लायंट्सप्रमाणेच, कन्सेन्सस क्लायंट्स पियर्स शोधण्यासाठी UDP वर discv5 (opens in a new tab) वापरतात. discv5 ची कन्सेन्सस लेयर अंमलबजावणी एक्झिक्युशन क्लायंट्सपेक्षा फक्त एवढ्याच बाबतीत वेगळी आहे की त्यात discv5 ला libP2P (opens in a new tab) स्टॅकमध्ये जोडणारा अडॅप्टर समाविष्ट आहे, ज्यामुळे DevP2P नापसंत होते. एक्झिक्युशन लेयरचे RLPx सत्र libP2P च्या नॉइज सिक्युर चॅनल हँडशेकच्या बाजूने नापसंत केले आहेत.

ENRs

कन्सेन्सस नोड्ससाठी ENR मध्ये नोडची सार्वजनिक की, IP पत्ता, UDP आणि TCP पोर्ट आणि दोन कन्सेन्सस-विशिष्ट फील्ड्स समाविष्ट आहेत: अटेस्टेशन सबनेट बिटफील्ड आणि eth2 की. पहिल्यामुळे नोड्सना विशिष्ट अटेस्टेशन गॉसिप सब-नेटवर्कमध्ये सहभागी होणारे पियर्स शोधणे सोपे होते. eth2 की मध्ये नोड कोणत्या Ethereum फोर्क आवृत्तीचा वापर करत आहे याबद्दल माहिती असते, ज्यामुळे पियर्स योग्य Ethereum शी कनेक्ट होत आहेत याची खात्री होते.

libP2P

libP2P स्टॅक डिस्कव्हरीनंतरच्या सर्व संवादांना समर्थन देतो. क्लायंट त्यांच्या ENR मध्ये परिभाषित केल्यानुसार IPv4 आणि/किंवा IPv6 वर डायल आणि ऐकू शकतात. libP2P लेयरवरील प्रोटोकॉल गॉसिप आणि req/resp डोमेनमध्ये विभागले जाऊ शकतात.

गॉसिप

गॉसिप डोमेनमध्ये अशी सर्व माहिती समाविष्ट आहे जी संपूर्ण नेटवर्कमध्ये वेगाने पसरणे आवश्यक आहे. यामध्ये बीकन ब्लॉक, प्रूफ, अटेस्टेशन्स, एक्झिट्स आणि स्लॅशिंग्स यांचा समावेश आहे. हे libP2P gossipsub v1 वापरून प्रसारित केले जाते आणि प्रत्येक नोडवर स्थानिकरित्या संग्रहित केलेल्या विविध मेटाडेटावर अवलंबून असते, ज्यात गॉसिप पेलोड प्राप्त करण्यासाठी आणि प्रसारित करण्यासाठी कमाल आकाराचा समावेश आहे. गॉसिप डोमेनबद्दल तपशीलवार माहिती येथे (opens in a new tab) उपलब्ध आहे.

विनंती-प्रतिसाद

विनंती-प्रतिसाद डोमेनमध्ये त्यांच्या पियर्सकडून विशिष्ट माहितीची विनंती करणाऱ्या क्लायंटसाठी प्रोटोकॉल आहेत. उदाहरणांमध्ये विशिष्ट रूट हॅशशी जुळणारे किंवा स्लॉटच्या मर्यादेतील विशिष्ट बीकन ब्लॉकची विनंती करणे समाविष्ट आहे. प्रतिसाद नेहमी स्नॅपी-कॉम्प्रेस्ड SSZ एन्कोडेड बाइट्स म्हणून परत केले जातात.

कन्सेन्सस क्लायंट RLP पेक्षा SSZ ला प्राधान्य का देतो?

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

एक्झिक्युशन आणि कन्सेन्सस क्लायंट कनेक्ट करणे

कन्सेन्सस आणि एक्झिक्युशन दोन्ही क्लायंट समांतर चालतात. त्यांना कनेक्ट करणे आवश्यक आहे जेणेकरून कन्सेन्सस क्लायंट एक्झिक्युशन क्लायंटला सूचना देऊ शकेल, आणि एक्झिक्युशन क्लायंट बीकन ब्लॉक्समध्ये समाविष्ट करण्यासाठी कन्सेन्सस क्लायंटला व्यवहारांचे बंडल पाठवू शकेल. दोन क्लायंटमधील संवाद स्थानिक RPC कनेक्शन वापरून साधला जाऊ शकतो. 'इंजिन-एपीआय' (opens in a new tab) म्हणून ओळखले जाणारे API दोन क्लायंटमध्ये पाठवलेल्या सूचना परिभाषित करते. दोन्ही क्लायंट एकाच नेटवर्क ओळखीच्या मागे बसल्यामुळे, ते एक ENR (Ethereum नोड रेकॉर्ड) शेअर करतात ज्यात प्रत्येक क्लायंटसाठी एक स्वतंत्र की असते (eth1 की आणि eth2 की).

कंट्रोल फ्लोचा सारांश खाली दर्शविला आहे, संबंधित नेटवर्किंग स्टॅक कंसात आहे.

जेव्हा कन्सेन्सस क्लायंट ब्लॉक निर्माता नसतो:

• कन्सेन्सस क्लायंटला ब्लॉक गॉसिप प्रोटोकॉलद्वारे एक ब्लॉक मिळतो (कन्सेन्सस p2p)
• कन्सेन्सस क्लायंट ब्लॉकची पूर्व-पडताळणी करतो, म्हणजे, तो योग्य पाठवणाऱ्याकडून योग्य मेटाडेटसह आला आहे याची खात्री करतो
• ब्लॉकमधील व्यवहार एक्झिक्युशन पेलोड म्हणून एक्झिक्युशन लेयरकडे पाठवले जातात (स्थानिक RPC कनेक्शन)
• एक्झिक्युशन लेयर व्यवहार कार्यान्वित करतो आणि ब्लॉक हेडरमधील स्टेटची पडताळणी करतो (म्हणजे, हॅश जुळतात की नाही हे तपासतो)
• एक्झिक्युशन लेयर व्हॅलिडेशन डेटा परत कन्सेन्सस लेयरकडे पाठवतो, आता ब्लॉक व्हॅलिडेटेड मानला जातो (स्थानिक RPC कनेक्शन)
• कन्सेन्सस लेयर ब्लॉकला स्वतःच्या ब्लॉकचेनच्या हेडमध्ये जोडतो आणि त्याची अटेस्टेशन करतो, नेटवर्कवर अटेस्टेशन प्रसारित करतो (कन्सेन्सस p2p)

जेव्हा कन्सेन्सस क्लायंट ब्लॉक निर्माता असतो:

• कन्सेन्सस क्लायंटला सूचना मिळते की तो पुढील ब्लॉक निर्माता आहे (कन्सेन्सस p2p)
• कन्सेन्सस लेयर एक्झिक्युशन क्लायंटमध्ये create block पद्धत कॉल करतो (स्थानिक RPC)
• एक्झिक्युशन लेयर ट्रान्झॅक्शन मेमपूलमध्ये प्रवेश करतो जो ट्रान्झॅक्शन गॉसिप प्रोटोकॉलद्वारे पॉप्युलेट केला गेला आहे (एक्झिक्युशन p2p)
• एक्झिक्युशन क्लायंट व्यवहारांना एका ब्लॉकमध्ये बंडल करतो, व्यवहार कार्यान्वित करतो आणि एक ब्लॉक हॅश तयार करतो
• कन्सेन्सस क्लायंट एक्झिक्युशन क्लायंटकडून व्यवहार आणि ब्लॉक हॅश घेतो आणि त्यांना बीकन ब्लॉकमध्ये जोडतो (स्थानिक RPC)
• कन्सेन्सस क्लायंट ब्लॉक गॉसिप प्रोटोकॉलवर ब्लॉक प्रसारित करतो (कन्सेन्सस p2p)
• इतर क्लायंट प्रस्तावित ब्लॉक ब्लॉक गॉसिप प्रोटोकॉलद्वारे प्राप्त करतात आणि वर वर्णन केल्याप्रमाणे व्हॅलिडेट करतात (कन्सेन्सस p2p)

एकदा पुरेसे व्हॅलिडेटर्सद्वारे ब्लॉक अटेस्टेड झाल्यावर, तो चेनच्या हेडमध्ये जोडला जातो, जस्टिफाय केला जातो आणि शेवटी फायनलाइज केला जातो.

कन्सेन्सस आणि एक्झिक्युशन क्लायंटसाठी नेटवर्क लेयर स्किमॅटिक, ethresear.ch (opens in a new tab) वरून

अधिक वाचन

DevP2P (opens in a new tab) LibP2p (opens in a new tab) कन्सेन्सस लेयर नेटवर्क स्पेक्स (opens in a new tab) kademlia to discv5 (opens in a new tab) kademlia पेपर (opens in a new tab) Ethereum p2p चा परिचय (opens in a new tab) eth1/eth2 संबंध (opens in a new tab) मर्ज आणि eth2 क्लायंट तपशील व्हिडिओ (opens in a new tab)