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

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

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

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

पूर्वतयारी

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

अंमलबजावणी स्तर

अंमलबजावणी स्तराचे नेटवर्किंग प्रोटोकॉल दोन स्टॅकमध्ये विभागलेले आहेत:

शोध स्टॅक: UDP वर तयार केलेला आणि नवीन नोडला कनेक्ट करण्यासाठी पीअर्स शोधण्याची परवानगी देतो
DevP2P स्टॅक: TCP वर बसतो आणि नोड्सना माहितीची देवाणघेवाण करण्यास सक्षम करतो

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

शोध

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

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

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

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

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

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

अंमलबजावणी क्लायंट सध्या Discv4 (नवीन टॅबमध्ये उघडते) शोध प्रोटोकॉल वापरत आहेत आणि discv5 (नवीन टॅबमध्ये उघडते) प्रोटोकॉलवर स्थलांतरित करण्याचा सक्रिय प्रयत्न सुरू आहे.

ENR: इथेरियम नोड रेकॉर्ड्स

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

शोध UDP वर का तयार केला आहे?

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

DevP2P

DevP2P हा स्वतःच प्रोटोकॉलचा एक संपूर्ण स्टॅक आहे जो इथेरियम पीअर-टू-पीअर नेटवर्क स्थापित करण्यासाठी आणि राखण्यासाठी लागू करतो. नवीन नोड्स नेटवर्कमध्ये प्रवेश केल्यानंतर, त्यांचे संवाद DevP2P (नवीन टॅबमध्ये उघडते) स्टॅकमधील प्रोटोकॉलद्वारे नियंत्रित केले जातात. हे सर्व TCP वर बसतात आणि त्यामध्ये RLPx ट्रान्सपोर्ट प्रोटोकॉल, वायर प्रोटोकॉल आणि अनेक उप-प्रोटोकॉल समाविष्ट असतात. RLPx (नवीन टॅबमध्ये उघडते) हा नोड्स दरम्यान सत्रे सुरू करणे, प्रमाणित करणे आणि राखणे नियंत्रित करणारा प्रोटोकॉल आहे. RLPx RLP (Recursive Length Prefix) वापरून संदेश एन्कोड करतो जी नोड्स दरम्यान पाठवण्यासाठी डेटाला किमान संरचनेत एन्कोड करण्याची एक अतिशय जागा-कार्यक्षम पद्धत आहे.

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

हॅलो संदेशांमध्ये हे समाविष्ट असते:

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

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

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

उप-प्रोटोकॉल

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

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

les (लाइट इथेरियम उपप्रोटोकॉल)

लाइट क्लायंट समक्रमण करण्यासाठी हा एक किमान प्रोटोकॉल आहे. पारंपारिकरित्या हा प्रोटोकॉल क्वचितच वापरला गेला आहे कारण पूर्ण नोड्सना प्रोत्साहन न देता लाइट क्लायंटला डेटा सर्व्ह करणे आवश्यक असते. अंमलबजावणी क्लायंटचे डीफॉल्ट वर्तन les वर लाइट क्लायंट डेटा सर्व्ह न करणे हे आहे. अधिक माहिती les स्पेक (नवीन टॅबमध्ये उघडते) मध्ये उपलब्ध आहे.

स्नॅप (Snap)

स्नॅप प्रोटोकॉल (नवीन टॅबमध्ये उघडते) हा एक पर्यायी विस्तार आहे जो पीअर्सना अलीकडील स्थितींचे स्नॅपशॉट्स देवाणघेवाण करण्यास अनुमती देतो, ज्यामुळे पीअर्सना मध्यवर्ती मर्कल ट्री (Merkle trie) नोड्स डाउनलोड न करता खाते आणि स्टोरेज डेटा सत्यापित करण्याची परवानगी मिळते.

विट (साक्ष प्रोटोकॉल)

साक्ष प्रोटोकॉल (नवीन टॅबमध्ये उघडते) हा एक पर्यायी विस्तार आहे जो पीअर्स दरम्यान स्थिती साक्षांची देवाणघेवाण सक्षम करतो, ज्यामुळे क्लायंटला चेनच्या टिपवर समक्रमण करण्यास मदत होते.

विस्पर (Whisper)

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

सहमती स्तर

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

शोध

अंमलबजावणी क्लायंटप्रमाणेच, सहमती क्लायंट पीअर्स शोधण्यासाठी UDP वर discv5 (नवीन टॅबमध्ये उघडते) वापरतात. discv5 ची सहमती स्तर अंमलबजावणी अंमलबजावणी क्लायंटपेक्षा केवळ या अर्थाने वेगळी आहे की त्यात discv5 ला libp2p (नवीन टॅबमध्ये उघडते) स्टॅकमध्ये जोडणारा अडॅप्टर समाविष्ट आहे, जो DevP2P ला नाकारतो. अंमलबजावणी स्तराची RLPx सत्रे libp2p च्या नॉईज सुरक्षित चॅनेल हँडशेकच्या बाजूने नाकारली गेली आहेत.

ENRs

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

libp2p

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

गॉसिप

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

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

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

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

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

अंमलबजावणी आणि सहमती क्लायंट्सना जोडणे

सहमती आणि अंमलबजावणी दोन्ही क्लायंट समांतर चालतात. त्यांना जोडणे आवश्यक आहे जेणेकरून सहमती क्लायंट अंमलबजावणी क्लायंटला सूचना देऊ शकेल आणि अंमलबजावणी क्लायंट बीकन ब्लॉकमध्ये समाविष्ट करण्यासाठी व्यवहारांचे बंडल सहमती क्लायंटकडे पाठवू शकेल. दोन क्लायंटमधील संवाद स्थानिक RPC कनेक्शन वापरून साध्य केला जाऊ शकतो. 'Engine-API' (नवीन टॅबमध्ये उघडते) म्हणून ओळखले जाणारे API दोन क्लायंट दरम्यान पाठवलेल्या सूचना परिभाषित करते. दोन्ही क्लायंट एकाच नेटवर्क ओळखीच्या मागे बसत असल्याने, ते एक ENR (इथेरियम नोड रेकॉर्ड) सामायिक करतात ज्यामध्ये प्रत्येक क्लायंटसाठी स्वतंत्र की (ईथ१ की आणि ईथ२ की) असते.

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

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

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

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

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

एकदा पुरेशा प्रमाणकांद्वारे ब्लॉकचे साक्षांकन झाल्यानंतर तो चेनच्या हेडमध्ये जोडला जातो, प्रमाणित (justified) केला जातो आणि शेवटी अंतिम झालेला (finalized) मानला जातो.

सहमती आणि अंमलबजावणी क्लायंट्ससाठी नेटवर्क स्तर योजनाबद्ध आकृती, ethresear.ch (नवीन टॅबमध्ये उघडते) वरून

अधिक वाचन