---
title: "नेटवर्किंग परत"
description: "इथेरियम की नेटवर्किंग परत का परिचय।"
lang: hi
sidebarDepth: 2
---

[इथेरियम](/) एक पीयर-टू-पीयर नेटवर्क है जिसमें हजारों नोड होते हैं जिन्हें मानकीकृत प्रोटोकॉल का उपयोग करके एक-दूसरे के साथ संवाद करने में सक्षम होना चाहिए। "नेटवर्किंग परत" प्रोटोकॉल का वह स्टैक है जो उन नोड्स को एक-दूसरे को खोजने और जानकारी का आदान-प्रदान करने की अनुमति देता है। इसमें नेटवर्क पर जानकारी की "गॉसिपिंग" (एक-से-अनेक संचार) के साथ-साथ विशिष्ट नोड्स (एक-से-एक संचार) के बीच अनुरोधों और प्रतिक्रियाओं की अदला-बदली शामिल है। प्रत्येक नोड को यह सुनिश्चित करने के लिए विशिष्ट नेटवर्किंग नियमों का पालन करना चाहिए कि वे सही जानकारी भेज और प्राप्त कर रहे हैं।

क्लाइंट सॉफ़्टवेयर के दो भाग होते हैं (निष्पादन क्लाइंट और सर्वसम्मति क्लाइंट), जिनमें से प्रत्येक का अपना अलग नेटवर्किंग स्टैक होता है। अन्य इथेरियम नोड्स के साथ संवाद करने के अलावा, निष्पादन और सर्वसम्मति क्लाइंट्स को एक-दूसरे के साथ भी संवाद करना होता है। यह पृष्ठ उन प्रोटोकॉल का परिचयात्मक स्पष्टीकरण देता है जो इस संचार को सक्षम करते हैं।

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

## पूर्वापेक्षाएँ {#prerequisites}

इस पृष्ठ को समझने के लिए इथेरियम [नोड्स और क्लाइंट्स](/developers/docs/nodes-and-clients/) का कुछ ज्ञान सहायक होगा।

## निष्पादन परत {#execution-layer}

निष्पादन परत के नेटवर्किंग प्रोटोकॉल को दो स्टैक में विभाजित किया गया है:

- खोज स्टैक: UDP के ऊपर बनाया गया है और एक नए नोड को कनेक्ट करने के लिए पीयर्स खोजने की अनुमति देता है

- DevP2P स्टैक: TCP के ऊपर बैठता है और नोड्स को जानकारी का आदान-प्रदान करने में सक्षम बनाता है

दोनों स्टैक समानांतर में काम करते हैं। खोज स्टैक नए नेटवर्क प्रतिभागियों को नेटवर्क में फीड करता है, और DevP2P स्टैक उनके इंटरैक्शन को सक्षम बनाता है।

### खोज {#discovery}

खोज नेटवर्क में अन्य नोड्स को खोजने की प्रक्रिया है। इसे बूटनोड्स के एक छोटे सेट का उपयोग करके बूटस्ट्रैप किया जाता है (वे नोड्स जिनके पते क्लाइंट में [हार्डकोड](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) किए गए हैं ताकि उन्हें तुरंत पाया जा सके और क्लाइंट को पीयर्स से जोड़ा जा सके)। ये बूटनोड केवल एक नए नोड को पीयर्स के एक सेट से परिचित कराने के लिए मौजूद हैं - यह उनका एकमात्र उद्देश्य है, वे चेन को सिंकिंग करने जैसे सामान्य क्लाइंट कार्यों में भाग नहीं लेते हैं, और उनका उपयोग केवल पहली बार क्लाइंट को चालू करने पर किया जाता है।

नोड-बूटनोड इंटरैक्शन के लिए उपयोग किया जाने वाला प्रोटोकॉल [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) का एक संशोधित रूप है जो नोड्स की सूचियों को साझा करने के लिए एक [वितरित हैश तालिका](https://en.wikipedia.org/wiki/Distributed_hash_table) का उपयोग करता है। प्रत्येक नोड के पास इस तालिका का एक संस्करण होता है जिसमें उसके निकटतम पीयर्स से जुड़ने के लिए आवश्यक जानकारी होती है। यह 'निकटता' भौगोलिक नहीं है - दूरी को नोड की ID की समानता द्वारा परिभाषित किया जाता है। सुरक्षा सुविधा के रूप में प्रत्येक नोड की तालिका को नियमित रूप से ताज़ा किया जाता है। उदाहरण के लिए, [discv5](https://github.com/ethereum/devp2p/tree/master/discv5) में, खोज प्रोटोकॉल नोड्स 'विज्ञापन' भेजने में भी सक्षम हैं जो क्लाइंट द्वारा समर्थित उप-प्रोटोकॉल प्रदर्शित करते हैं, जिससे पीयर्स उन प्रोटोकॉल के बारे में बातचीत कर सकते हैं जिनका उपयोग वे दोनों संचार करने के लिए कर सकते हैं।

खोज PING-PONG के खेल से शुरू होती है। एक सफल PING-PONG नए नोड को बूटनोड से "बॉन्ड" करता है। प्रारंभिक संदेश जो नेटवर्क में प्रवेश करने वाले नए नोड के अस्तित्व के बारे में बूटनोड को सचेत करता है, वह एक `PING` है। इस `PING` में नए नोड, बूटनोड और समाप्ति समय-टिकट के बारे में हैश की गई जानकारी शामिल है। बूटनोड `PING` प्राप्त करता है और `PING` हैश युक्त एक `PONG` लौटाता है। यदि `PING` और `PONG` हैश मेल खाते हैं तो नए नोड और बूटनोड के बीच कनेक्शन सत्यापित हो जाता है और उन्हें "बॉन्डेड" कहा जाता है।

एक बार बॉन्ड हो जाने के बाद, नया नोड बूटनोड को एक `FIND-NEIGHBOURS` अनुरोध भेज सकता है। बूटनोड द्वारा लौटाए गए डेटा में उन पीयर्स की सूची शामिल होती है जिनसे नया नोड जुड़ सकता है। यदि नोड्स बॉन्डेड नहीं हैं, तो `FIND-NEIGHBOURS` अनुरोध विफल हो जाएगा, इसलिए नया नोड नेटवर्क में प्रवेश नहीं कर पाएगा।

एक बार जब नए नोड को बूटनोड से पड़ोसियों की सूची मिल जाती है, तो वह उनमें से प्रत्येक के साथ PING-PONG का आदान-प्रदान शुरू कर देता है। सफल PING-PONG नए नोड को उसके पड़ोसियों के साथ बॉन्ड करते हैं, जिससे संदेश का आदान-प्रदान सक्षम होता है।

```
क्लाइंट शुरू करें --> बूटनोड से कनेक्ट करें --> बूटनोड से बॉन्ड करें --> पड़ोसियों को खोजें --> पड़ोसियों से बॉन्ड करें
```

निष्पादन क्लाइंट वर्तमान में [Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) खोज प्रोटोकॉल का उपयोग कर रहे हैं और [discv5](https://github.com/ethereum/devp2p/tree/master/discv5) प्रोटोकॉल में माइग्रेट करने का एक सक्रिय प्रयास चल रहा है।

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

[इथेरियम नोड रिकॉर्ड (ENR)](/developers/docs/networking-layer/network-addresses/) एक ऑब्जेक्ट है जिसमें तीन बुनियादी तत्व होते हैं: एक हस्ताक्षर (किसी सहमत पहचान योजना के अनुसार बनाए गए रिकॉर्ड सामग्री का हैश), एक अनुक्रम संख्या जो रिकॉर्ड में परिवर्तनों को ट्रैक करती है, और कुंजी:मूल्य (key:value) जोड़े की एक मनमानी सूची। यह एक भविष्य-प्रूफ प्रारूप है जो नए पीयर्स के बीच पहचान संबंधी जानकारी के आसान आदान-प्रदान की अनुमति देता है और इथेरियम नोड्स के लिए पसंदीदा [नेटवर्क पता](/developers/docs/networking-layer/network-addresses) प्रारूप है।

#### खोज UDP पर क्यों बनाई गई है? {#why-udp}

UDP किसी भी त्रुटि जाँच, विफल पैकेटों को फिर से भेजने, या गतिशील रूप से कनेक्शन खोलने और बंद करने का समर्थन नहीं करता है - इसके बजाय यह केवल एक लक्ष्य पर जानकारी की एक निरंतर धारा फायर करता है, भले ही वह सफलतापूर्वक प्राप्त हुई हो या नहीं। यह न्यूनतम कार्यक्षमता न्यूनतम ओवरहेड में भी तब्दील हो जाती है, जिससे इस प्रकार का कनेक्शन बहुत तेज़ हो जाता है। खोज के लिए, जहाँ एक नोड केवल अपनी उपस्थिति दर्ज कराना चाहता है ताकि बाद में एक पीयर के साथ औपचारिक कनेक्शन स्थापित किया जा सके, UDP पर्याप्त है। हालाँकि, बाकी नेटवर्किंग स्टैक के लिए, UDP उद्देश्य के लिए उपयुक्त नहीं है। नोड्स के बीच सूचनात्मक आदान-प्रदान काफी जटिल है और इसलिए एक अधिक पूर्ण विशेषताओं वाले प्रोटोकॉल की आवश्यकता है जो फिर से भेजने, त्रुटि जाँच आदि का समर्थन कर सके। TCP से जुड़ा अतिरिक्त ओवरहेड अतिरिक्त कार्यक्षमता के लायक है। इसलिए, अधिकांश P2P स्टैक TCP पर काम करता है।

### DevP2P {#devp2p}

DevP2P अपने आप में प्रोटोकॉल का एक पूरा स्टैक है जिसे इथेरियम पीयर-टू-पीयर नेटवर्क स्थापित करने और बनाए रखने के लिए लागू करता है। नए नोड्स के नेटवर्क में प्रवेश करने के बाद, उनके इंटरैक्शन [DevP2P](https://github.com/ethereum/devp2p) स्टैक में प्रोटोकॉल द्वारा नियंत्रित होते हैं। ये सभी TCP के ऊपर बैठते हैं और इनमें RLPx ट्रांसपोर्ट प्रोटोकॉल, वायर प्रोटोकॉल और कई उप-प्रोटोकॉल शामिल हैं। [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) वह प्रोटोकॉल है जो नोड्स के बीच सत्र शुरू करने, प्रमाणित करने और बनाए रखने को नियंत्रित करता है। RLPx RLP (रिकर्सिव लेंथ प्रीफिक्स) का उपयोग करके संदेशों को एन्कोड करता है जो नोड्स के बीच भेजने के लिए डेटा को न्यूनतम संरचना में एन्कोड करने का एक बहुत ही स्थान-कुशल तरीका है।

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

हैलो संदेशों में शामिल हैं:

- प्रोटोकॉल संस्करण
- क्लाइंट ID
- पोर्ट
- नोड ID
- समर्थित उप-प्रोटोकॉल की सूची

यह एक सफल इंटरैक्शन के लिए आवश्यक जानकारी है क्योंकि यह परिभाषित करता है कि दोनों नोड्स के बीच कौन सी क्षमताएं साझा की जाती हैं और संचार को कॉन्फ़िगर करता है। उप-प्रोटोकॉल बातचीत की एक प्रक्रिया है जहाँ प्रत्येक नोड द्वारा समर्थित उप-प्रोटोकॉल की सूचियों की तुलना की जाती है और जो दोनों नोड्स के लिए सामान्य हैं उनका उपयोग सत्र में किया जा सकता है।

हैलो संदेशों के साथ, वायर प्रोटोकॉल एक "डिस्कनेक्ट" संदेश भी भेज सकता है जो एक पीयर को चेतावनी देता है कि कनेक्शन बंद कर दिया जाएगा। वायर प्रोटोकॉल में PING और PONG संदेश भी शामिल हैं जो सत्र को खुला रखने के लिए समय-समय पर भेजे जाते हैं। इसलिए RLPx और वायर प्रोटोकॉल एक्सचेंज नोड्स के बीच संचार की नींव स्थापित करते हैं, जो एक विशिष्ट उप-प्रोटोकॉल के अनुसार उपयोगी जानकारी के आदान-प्रदान के लिए मचान प्रदान करते हैं।

### उप-प्रोटोकॉल {#sub-protocols}

#### वायर प्रोटोकॉल {#wire-protocol}

एक बार पीयर्स कनेक्ट हो जाने और RLPx सत्र शुरू हो जाने के बाद, वायर प्रोटोकॉल परिभाषित करता है कि पीयर्स कैसे संवाद करते हैं। प्रारंभ में, वायर प्रोटोकॉल ने तीन मुख्य कार्यों को परिभाषित किया: चेन सिंक्रोनाइज़ेशन, ब्लॉक प्रसार और लेन-देन विनिमय। हालाँकि, एक बार जब इथेरियम प्रूफ-ऑफ़-स्टेक (PoS) पर स्विच हो गया, तो ब्लॉक प्रसार और चेन सिंक्रोनाइज़ेशन सर्वसम्मति परत का हिस्सा बन गए। लेन-देन विनिमय अभी भी निष्पादन क्लाइंट्स के अधिकार क्षेत्र में है। लेन-देन विनिमय का तात्पर्य नोड्स के बीच लंबित लेन-देन के आदान-प्रदान से है ताकि ब्लॉक निर्माता अगले ब्लॉक में शामिल करने के लिए उनमें से कुछ का चयन कर सकें। इन कार्यों के बारे में विस्तृत जानकारी [यहाँ](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) उपलब्ध है। इन उप-प्रोटोकॉल का समर्थन करने वाले क्लाइंट उन्हें [जेसन-आरपीसी](/developers/docs/apis/json-rpc/) के माध्यम से उजागर करते हैं।

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

यह लाइट क्लाइंट्स को सिंकिंग करने के लिए एक न्यूनतम प्रोटोकॉल है। पारंपरिक रूप से इस प्रोटोकॉल का शायद ही कभी उपयोग किया गया है क्योंकि पूर्ण नोड्स को बिना किसी प्रोत्साहन के लाइट क्लाइंट्स को डेटा परोसने की आवश्यकता होती है। निष्पादन क्लाइंट्स का डिफ़ॉल्ट व्यवहार les पर लाइट क्लाइंट डेटा परोसना नहीं है। अधिक जानकारी les [स्पेक](https://github.com/ethereum/devp2p/blob/master/caps/les.md) में उपलब्ध है।

#### स्नैप (Snap) {#snap}

[स्नैप प्रोटोकॉल](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap) एक वैकल्पिक एक्सटेंशन है जो पीयर्स को हाल की स्थितियों के स्नैपशॉट का आदान-प्रदान करने की अनुमति देता है, जिससे पीयर्स मध्यवर्ती मर्कल ट्री नोड्स को डाउनलोड किए बिना खाता और स्टोरेज डेटा को सत्यापित कर सकते हैं।

#### विट (साक्षी प्रोटोकॉल) {#wit}

[साक्षी प्रोटोकॉल](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) एक वैकल्पिक एक्सटेंशन है जो पीयर्स के बीच स्थिति साक्षियों के आदान-प्रदान को सक्षम बनाता है, जिससे क्लाइंट्स को चेन के टिप तक सिंकिंग करने में मदद मिलती है।

#### व्हिस्पर (Whisper) {#whisper}

व्हिस्पर एक प्रोटोकॉल था जिसका उद्देश्य ब्लॉकचेन पर कोई भी जानकारी लिखे बिना पीयर्स के बीच सुरक्षित मैसेजिंग प्रदान करना था। यह DevP2P वायर प्रोटोकॉल का हिस्सा था लेकिन अब इसे हटा दिया गया है। समान उद्देश्यों वाली अन्य [संबंधित परियोजनाएं](https://wakunetwork.com/) मौजूद हैं।

## सर्वसम्मति परत {#consensus-layer}

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

### खोज {#consensus-discovery}

निष्पादन क्लाइंट्स के समान, सर्वसम्मति क्लाइंट पीयर्स को खोजने के लिए UDP पर [discv5](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) का उपयोग करते हैं। discv5 का सर्वसम्मति परत कार्यान्वयन निष्पादन क्लाइंट्स से केवल इस मायने में भिन्न है कि इसमें discv5 को [libp2p](https://libp2p.io/) स्टैक से जोड़ने वाला एक एडेप्टर शामिल है, जो DevP2P को हटा देता है। निष्पादन परत के RLPx सत्रों को libp2p के नॉइज़ सुरक्षित चैनल हैंडशेक के पक्ष में हटा दिया गया है।

### ENRs {#consensus-enr}

सर्वसम्मति नोड्स के लिए ENR में नोड की सार्वजनिक कुंजी, IP पता, UDP और TCP पोर्ट और दो सर्वसम्मति-विशिष्ट फ़ील्ड शामिल हैं: अनुप्रमाणन सबनेट बिटफ़ील्ड और `eth2` कुंजी। पूर्व नोड्स के लिए विशिष्ट अनुप्रमाणन गॉसिप उप-नेटवर्क में भाग लेने वाले पीयर्स को ढूंढना आसान बनाता है। `eth2` कुंजी में इस बारे में जानकारी होती है कि नोड किस इथेरियम फ़ोर्क संस्करण का उपयोग कर रहा है, यह सुनिश्चित करते हुए कि पीयर्स सही इथेरियम से जुड़ रहे हैं।

### libp2p {#libp2p}

libp2p स्टैक खोज के बाद सभी संचारों का समर्थन करता है। क्लाइंट अपने ENR में परिभाषित अनुसार IPv4 और/या IPv6 पर डायल कर सकते हैं और सुन सकते हैं। libp2p परत पर प्रोटोकॉल को गॉसिप और req/resp (अनुरोध/प्रतिक्रिया) डोमेन में उप-विभाजित किया जा सकता है।

### गॉसिप {#gossip}

गॉसिप डोमेन में वह सभी जानकारी शामिल होती है जिसे पूरे नेटवर्क में तेज़ी से फैलना होता है। इसमें बीकन ब्लॉक, प्रमाण, अनुप्रमाणन, निकास और स्लैशिंग शामिल हैं। यह libp2p गॉसिपसब v1 का उपयोग करके प्रेषित किया जाता है और प्रत्येक नोड पर स्थानीय रूप से संग्रहीत विभिन्न मेटाडेटा पर निर्भर करता है, जिसमें प्राप्त करने और प्रसारित करने के लिए गॉसिप पेलोड का अधिकतम आकार शामिल है। गॉसिप डोमेन के बारे में विस्तृत जानकारी [यहाँ](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub) उपलब्ध है।

### अनुरोध-प्रतिक्रिया {#request-response}

अनुरोध-प्रतिक्रिया डोमेन में क्लाइंट्स द्वारा अपने पीयर्स से विशिष्ट जानकारी का अनुरोध करने के लिए प्रोटोकॉल होते हैं। उदाहरणों में कुछ रूट हैश से मेल खाने वाले या स्लॉट की एक सीमा के भीतर विशिष्ट बीकन ब्लॉक का अनुरोध करना शामिल है। प्रतिक्रियाएं हमेशा स्नैपी-संपीड़ित SSZ एन्कोडेड बाइट्स के रूप में लौटाई जाती हैं।

## सर्वसम्मति क्लाइंट RLP की तुलना में SSZ को प्राथमिकता क्यों देता है? {#ssz-vs-rlp}

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

## निष्पादन और सर्वसम्मति क्लाइंट्स को जोड़ना {#connecting-clients}

सर्वसम्मति और निष्पादन क्लाइंट दोनों समानांतर में चलते हैं। उन्हें कनेक्ट करने की आवश्यकता है ताकि सर्वसम्मति क्लाइंट निष्पादन क्लाइंट को निर्देश प्रदान कर सके, और निष्पादन क्लाइंट बीकन ब्लॉक में शामिल करने के लिए सर्वसम्मति क्लाइंट को लेन-देन के बंडल पास कर सके। दोनों क्लाइंट्स के बीच संचार एक स्थानीय RPC कनेक्शन का उपयोग करके प्राप्त किया जा सकता है। ['इंजन-API'](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) के रूप में जाना जाने वाला एक API दोनों क्लाइंट्स के बीच भेजे गए निर्देशों को परिभाषित करता है। चूँकि दोनों क्लाइंट एक ही नेटवर्क पहचान के पीछे बैठते हैं, वे एक ENR (इथेरियम नोड रिकॉर्ड) साझा करते हैं जिसमें प्रत्येक क्लाइंट (ईटीएच1 कुंजी और ईटीएच2 कुंजी) के लिए एक अलग कुंजी होती है।

नियंत्रण प्रवाह का सारांश नीचे दिखाया गया है, जिसमें प्रासंगिक नेटवर्किंग स्टैक कोष्ठक में है।

### जब सर्वसम्मति क्लाइंट ब्लॉक निर्माता नहीं होता है: {#when-consensus-client-is-not-block-producer}

- सर्वसम्मति क्लाइंट ब्लॉक गॉसिप प्रोटोकॉल (सर्वसम्मति p2p) के माध्यम से एक ब्लॉक प्राप्त करता है
- सर्वसम्मति क्लाइंट ब्लॉक को पूर्व-सत्यापित करता है, यानी, यह सुनिश्चित करता है कि यह सही मेटाडेटा के साथ एक वैध प्रेषक से आया है
- ब्लॉक में लेन-देन निष्पादन परत को निष्पादन पेलोड (स्थानीय RPC कनेक्शन) के रूप में भेजे जाते हैं
- निष्पादन परत लेन-देन निष्पादित करती है और ब्लॉक हेडर में स्थिति को मान्य करती है (यानी, हैश मिलान की जाँच करती है)
- निष्पादन परत सत्यापन डेटा को वापस सर्वसम्मति परत में भेजती है, ब्लॉक को अब मान्य माना जाता है (स्थानीय RPC कनेक्शन)
- सर्वसम्मति परत ब्लॉक को अपने स्वयं के ब्लॉकचेन के शीर्ष पर जोड़ती है और इसे अनुप्रमाणित करती है, नेटवर्क पर अनुप्रमाणन प्रसारित करती है (सर्वसम्मति p2p)

### जब सर्वसम्मति क्लाइंट ब्लॉक निर्माता होता है: {#when-consensus-client-is-block-producer}

- सर्वसम्मति क्लाइंट को नोटिस मिलता है कि यह अगला ब्लॉक निर्माता है (सर्वसम्मति p2p)
- सर्वसम्मति परत निष्पादन क्लाइंट (स्थानीय RPC) में `create block` विधि को कॉल करती है
- निष्पादन परत लेन-देन मेमपूल तक पहुँचती है जिसे लेन-देन गॉसिप प्रोटोकॉल (निष्पादन p2p) द्वारा आबाद किया गया है
- निष्पादन क्लाइंट लेन-देन को एक ब्लॉक में बंडल करता है, लेन-देन निष्पादित करता है और एक ब्लॉक हैश उत्पन्न करता है
- सर्वसम्मति क्लाइंट निष्पादन क्लाइंट से लेन-देन और ब्लॉक हैश प्राप्त करता है और उन्हें बीकन ब्लॉक (स्थानीय RPC) में जोड़ता है
- सर्वसम्मति क्लाइंट ब्लॉक गॉसिप प्रोटोकॉल (सर्वसम्मति p2p) पर ब्लॉक प्रसारित करता है
- अन्य क्लाइंट ब्लॉक गॉसिप प्रोटोकॉल के माध्यम से प्रस्तावित ब्लॉक प्राप्त करते हैं और ऊपर वर्णित अनुसार मान्य करते हैं (सर्वसम्मति p2p)

एक बार जब पर्याप्त सत्यापकों द्वारा ब्लॉक को अनुप्रमाणित कर दिया जाता है, तो इसे चेन के शीर्ष पर जोड़ दिया जाता है, औचित्य-सिद्ध किया जाता है और अंततः अंतिम रूप दिया जाता है।

![Diagram of the Ethereum consensus client networking layer](cons_client_net_layer.png)
![Diagram of the Ethereum execution client networking layer](exe_client_net_layer.png)

सर्वसम्मति और निष्पादन क्लाइंट्स के लिए नेटवर्क परत योजनाबद्ध, [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248) से

## आगे की पढ़ाई {#further-reading}

[DevP2P](https://github.com/ethereum/devp2p)
[libp2p](https://github.com/libp2p/specs)
[सर्वसम्मति परत नेटवर्क विनिर्देश](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md#enr-structure)
[kademlia से discv5 तक](https://vac.dev/kademlia-to-discv5)
[kademlia पेपर](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf)
[इथेरियम p2p का परिचय](https://p2p.paris/en/talks/intro-ethereum-networking/)
[ईटीएच1/ईटीएच2 संबंध](https://ethresear.ch/t/eth1-eth2-client-relationship/7248)
[मर्ज और ईटीएच2 क्लाइंट विवरण वीडियो](https://www.youtube.com/watch?v=zNIrIninMgg)