---
title: "⁦نیٹ ورکنگ کی تہہ⁩"
description: "⁦ایتھیریم کی نیٹ ورکنگ کی تہہ کا تعارف۔⁩"
lang: ur
sidebarDepth: 2
---

[ایتھیریم](/) ایک پیئر ٹو پیئر نیٹ ورک ہے جس میں ہزاروں نوڈز ہیں جنہیں معیاری پروٹوکولز کا استعمال کرتے ہوئے ایک دوسرے کے ساتھ بات چیت کرنے کے قابل ہونا چاہیے۔ "نیٹ ورکنگ کی تہہ" پروٹوکولز کا وہ مجموعہ ہے جو ان نوڈز کو ایک دوسرے کو تلاش کرنے اور معلومات کا تبادلہ کرنے کی اجازت دیتا ہے۔ اس میں نیٹ ورک پر معلومات کی "گاسپنگ" (ایک سے کئی تک مواصلات) کے ساتھ ساتھ مخصوص نوڈز کے درمیان درخواستوں اور جوابات کا تبادلہ (ایک سے ایک مواصلات) شامل ہے۔ ہر نوڈ کو مخصوص نیٹ ورکنگ قواعد کی پابندی کرنی چاہیے تاکہ یہ یقینی بنایا جا سکے کہ وہ درست معلومات بھیج اور وصول کر رہے ہیں۔

کلائنٹ سافٹ ویئر کے دو حصے ہیں (ایگزیکیوشن کلائنٹس اور اتفاقِ رائے کے کلائنٹس)، ہر ایک کا اپنا الگ نیٹ ورکنگ اسٹیک ہے۔ دیگر ایتھیریم نوڈز کے ساتھ بات چیت کرنے کے علاوہ، ایگزیکیوشن اور اتفاقِ رائے کے کلائنٹس کو ایک دوسرے کے ساتھ بھی بات چیت کرنی ہوتی ہے۔ یہ صفحہ ان پروٹوکولز کی تعارفی وضاحت فراہم کرتا ہے جو اس مواصلات کو ممکن بناتے ہیں۔

ایگزیکیوشن کلائنٹس عمل درآمد کی تہہ کے پیئر ٹو پیئر نیٹ ورک پر ٹرانزیکشنز کو گاسپ کرتے ہیں۔ اس کے لیے تصدیق شدہ پیئرز کے درمیان انکرپٹڈ مواصلات کی ضرورت ہوتی ہے۔ جب کسی توثیق کار کو بلاک تجویز کرنے کے لیے منتخب کیا جاتا ہے، تو نوڈ کے مقامی ٹرانزیکشن پول سے ٹرانزیکشنز کو مقامی <span dir="ltr">RPC</span> کنکشن کے ذریعے اتفاقِ رائے کے کلائنٹس کو منتقل کیا جائے گا، جنہیں بیکن بلاکس میں پیک کیا جائے گا۔ اتفاقِ رائے کے کلائنٹس پھر اپنے <span dir="ltr">p2p</span> نیٹ ورک پر بیکن بلاکس کو گاسپ کریں گے۔ اس کے لیے دو الگ الگ <span dir="ltr">p2p</span> نیٹ ورکس کی ضرورت ہوتی ہے: ایک ٹرانزیکشن گاسپ کے لیے ایگزیکیوشن کلائنٹس کو جوڑتا ہے اور دوسرا بلاک گاسپ کے لیے اتفاقِ رائے کے کلائنٹس کو جوڑتا ہے۔

## شرائط {#prerequisites}

اس صفحے کو سمجھنے کے لیے ایتھیریم [نوڈز اور کلائنٹس](/developers/docs/nodes-and-clients/) کا کچھ علم مددگار ثابت ہوگا۔

## عمل درآمد کی تہہ {#execution-layer}

عمل درآمد کی تہہ کے نیٹ ورکنگ پروٹوکولز کو دو اسٹیکس میں تقسیم کیا گیا ہے:

- دریافت کا اسٹیک: <span dir="ltr">UDP</span> کے اوپر بنایا گیا ہے اور ایک نئے نوڈ کو جڑنے کے لیے پیئرز تلاش کرنے کی اجازت دیتا ہے

- <span dir="ltr">devp2p</span> اسٹیک: <span dir="ltr">TCP</span> کے اوپر بیٹھتا ہے اور نوڈز کو معلومات کا تبادلہ کرنے کے قابل بناتا ہے

دونوں اسٹیکس متوازی طور پر کام کرتے ہیں۔ دریافت کا اسٹیک نئے نیٹ ورک کے شرکاء کو نیٹ ورک میں شامل کرتا ہے، اور <span dir="ltr">devp2p</span> اسٹیک ان کے تعاملات کو ممکن بناتا ہے۔

### دریافت {#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) کا استعمال کرتا ہے۔ ہر نوڈ کے پاس اس ٹیبل کا ایک ورژن ہوتا ہے جس میں اس کے قریبی پیئرز سے جڑنے کے لیے درکار معلومات ہوتی ہیں۔ یہ 'قربت' جغرافیائی نہیں ہے - فاصلے کی تعریف نوڈ کی <span dir="ltr">ID</span> کی مماثلت سے کی جاتی ہے۔ ہر نوڈ کا ٹیبل حفاظتی خصوصیت کے طور پر باقاعدگی سے ریفریش کیا جاتا ہے۔ مثال کے طور پر، [discv5](https://github.com/ethereum/devp2p/tree/master/discv5) میں، دریافت پروٹوکول نوڈز 'اشتہارات' بھیجنے کے بھی قابل ہوتے ہیں جو ان ذیلی پروٹوکولز کو ظاہر کرتے ہیں جن کی کلائنٹ حمایت کرتا ہے، جس سے پیئرز ان پروٹوکولز کے بارے میں بات چیت کر سکتے ہیں جنہیں وہ دونوں مواصلات کے لیے استعمال کر سکتے ہیں۔

دریافت کا آغاز <span dir="ltr">PING-PONG</span> کے کھیل سے ہوتا ہے۔ ایک کامیاب <span dir="ltr">PING-PONG</span> نئے نوڈ کو بوٹ نوڈ کے ساتھ "باندھ" دیتا ہے۔ ابتدائی پیغام جو بوٹ نوڈ کو نیٹ ورک میں داخل ہونے والے نئے نوڈ کے وجود سے آگاہ کرتا ہے وہ ایک `PING` ہے۔ اس `PING` میں نئے نوڈ، بوٹ نوڈ اور میعاد ختم ہونے کے ٹائم اسٹیمپ کے بارے میں ہیش شدہ معلومات شامل ہوتی ہیں۔ بوٹ نوڈ `PING` وصول کرتا ہے اور ایک `PONG` واپس کرتا ہے جس میں `PING` ہیش ہوتا ہے۔ اگر `PING` اور `PONG` ہیشز آپس میں ملتے ہیں تو نئے نوڈ اور بوٹ نوڈ کے درمیان کنکشن کی تصدیق ہو جاتی ہے اور کہا جاتا ہے کہ وہ "بندھ" گئے ہیں۔

ایک بار بندھ جانے کے بعد، نیا نوڈ بوٹ نوڈ کو ایک `FIND-NEIGHBOURS` درخواست بھیج سکتا ہے۔ بوٹ نوڈ کے ذریعے واپس کیے گئے ڈیٹا میں ان پیئرز کی فہرست شامل ہوتی ہے جن سے نیا نوڈ جڑ سکتا ہے۔ اگر نوڈز بندھے ہوئے نہیں ہیں، تو `FIND-NEIGHBOURS` درخواست ناکام ہو جائے گی، لہذا نیا نوڈ نیٹ ورک میں داخل نہیں ہو سکے گا۔

ایک بار جب نیا نوڈ بوٹ نوڈ سے پڑوسیوں کی فہرست وصول کر لیتا ہے، تو وہ ان میں سے ہر ایک کے ساتھ <span dir="ltr">PING-PONG</span> کا تبادلہ شروع کر دیتا ہے۔ کامیاب <span dir="ltr">PING-PONGs</span> نئے نوڈ کو اس کے پڑوسیوں کے ساتھ باندھ دیتے ہیں، جس سے پیغام کا تبادلہ ممکن ہو جاتا ہے۔

```
کلائنٹ شروع کریں --> بوٹ نوڈ سے جڑیں --> بوٹ نوڈ سے بندھیں --> پڑوسیوں کو تلاش کریں --> پڑوسیوں سے بندھیں
```

ایگزیکیوشن کلائنٹس فی الحال [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/) ایک آبجیکٹ ہے جس میں تین بنیادی عناصر شامل ہیں: ایک دستخط (کسی متفقہ شناختی اسکیم کے مطابق بنائے گئے ریکارڈ کے مندرجات کا ہیش)، ایک ترتیب نمبر جو ریکارڈ میں ہونے والی تبدیلیوں کو ٹریک کرتا ہے، اور کلید:قدر کے جوڑوں کی ایک صوابدیدی فہرست۔ یہ ایک مستقبل کا ثبوت دینے والا فارمیٹ ہے جو نئے پیئرز کے درمیان شناختی معلومات کے آسان تبادلے کی اجازت دیتا ہے اور ایتھیریم نوڈز کے لیے ترجیحی [نیٹ ورک کا پتہ](/developers/docs/networking-layer/network-addresses) فارمیٹ ہے۔

#### دریافت UDP پر کیوں بنائی گئی ہے؟ {#why-udp}

<span dir="ltr">UDP</span> کسی بھی خرابی کی جانچ، ناکام پیکٹس کو دوبارہ بھیجنے، یا متحرک طور پر کنکشن کھولنے اور بند کرنے کی حمایت نہیں کرتا ہے - اس کے بجائے یہ صرف ایک ہدف پر معلومات کا ایک مسلسل سلسلہ فائر کرتا ہے، قطع نظر اس کے کہ یہ کامیابی سے موصول ہوا ہے یا نہیں۔ یہ کم سے کم فعالیت کم سے کم اوور ہیڈ میں بھی ترجمہ ہوتی ہے، جس سے اس قسم کا کنکشن بہت تیز ہو جاتا ہے۔ دریافت کے لیے، جہاں ایک نوڈ محض اپنی موجودگی کو ظاہر کرنا چاہتا ہے تاکہ پھر کسی پیئر کے ساتھ باقاعدہ کنکشن قائم کر سکے، <span dir="ltr">UDP</span> کافی ہے۔ تاہم، باقی نیٹ ورکنگ اسٹیک کے لیے، <span dir="ltr">UDP</span> مقصد کے لیے موزوں نہیں ہے۔ نوڈز کے درمیان معلوماتی تبادلہ کافی پیچیدہ ہے اور اس لیے اسے ایک زیادہ مکمل خصوصیات والے پروٹوکول کی ضرورت ہے جو دوبارہ بھیجنے، خرابی کی جانچ وغیرہ کی حمایت کر سکے۔ <span dir="ltr">TCP</span> سے وابستہ اضافی اوور ہیڈ اضافی فعالیت کے قابل ہے۔ لہذا، <span dir="ltr">P2P</span> اسٹیک کی اکثریت <span dir="ltr">TCP</span> پر کام کرتی ہے۔

### devp2p {#devp2p}

<span dir="ltr">devp2p</span> بذات خود پروٹوکولز کا ایک پورا اسٹیک ہے جسے ایتھیریم پیئر ٹو پیئر نیٹ ورک قائم کرنے اور برقرار رکھنے کے لیے نافذ کرتا ہے۔ نئے نوڈز کے نیٹ ورک میں داخل ہونے کے بعد، ان کے تعاملات [devp2p](https://github.com/ethereum/devp2p) اسٹیک میں پروٹوکولز کے ذریعے کنٹرول کیے جاتے ہیں۔ یہ سب <span dir="ltr">TCP</span> کے اوپر بیٹھتے ہیں اور ان میں <span dir="ltr">RLPx</span> ٹرانسپورٹ پروٹوکول، وائر پروٹوکول اور کئی ذیلی پروٹوکول شامل ہیں۔ [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) وہ پروٹوکول ہے جو نوڈز کے درمیان سیشنز شروع کرنے، تصدیق کرنے اور برقرار رکھنے کو کنٹرول کرتا ہے۔ <span dir="ltr">RLPx</span> پیغامات کو <span dir="ltr">RLP (Recursive Length Prefix)</span> کا استعمال کرتے ہوئے انکوڈ کرتا ہے جو نوڈز کے درمیان بھیجنے کے لیے ڈیٹا کو کم سے کم ڈھانچے میں انکوڈ کرنے کا ایک بہت ہی جگہ بچانے والا طریقہ ہے۔

دو نوڈز کے درمیان ایک <span dir="ltr">RLPx</span> سیشن ابتدائی کرپٹوگرافک ہینڈ شیک سے شروع ہوتا ہے۔ اس میں نوڈ ایک تصدیقی پیغام بھیجتا ہے جس کی پھر پیئر کے ذریعے تصدیق کی جاتی ہے۔ کامیاب تصدیق پر، پیئر شروع کرنے والے نوڈ کو واپس کرنے کے لیے ایک تصدیقی-اعترافی پیغام تیار کرتا ہے۔ یہ ایک کلید کے تبادلے کا عمل ہے جو نوڈز کو نجی اور محفوظ طریقے سے بات چیت کرنے کے قابل بناتا ہے۔ ایک کامیاب کرپٹوگرافک ہینڈ شیک پھر دونوں نوڈز کو ایک دوسرے کو "وائر پر" "ہیلو" پیغام بھیجنے کے لیے متحرک کرتا ہے۔ وائر پروٹوکول ہیلو پیغامات کے کامیاب تبادلے سے شروع ہوتا ہے۔

ہیلو پیغامات میں شامل ہیں:

- پروٹوکول کا ورژن
- کلائنٹ کی <span dir="ltr">ID</span>
- پورٹ
- نوڈ کی <span dir="ltr">ID</span>
- حمایت یافتہ ذیلی پروٹوکولز کی فہرست

یہ ایک کامیاب تعامل کے لیے درکار معلومات ہے کیونکہ یہ اس بات کی وضاحت کرتی ہے کہ دونوں نوڈز کے درمیان کون سی صلاحیتیں مشترک ہیں اور مواصلات کو ترتیب دیتی ہے۔ ذیلی پروٹوکول کی بات چیت کا ایک عمل ہوتا ہے جہاں ہر نوڈ کے ذریعے حمایت یافتہ ذیلی پروٹوکولز کی فہرستوں کا موازنہ کیا جاتا ہے اور جو دونوں نوڈز میں مشترک ہوتے ہیں انہیں سیشن میں استعمال کیا جا سکتا ہے۔

ہیلو پیغامات کے ساتھ، وائر پروٹوکول ایک "منقطع" پیغام بھی بھیج سکتا ہے جو پیئر کو متنبہ کرتا ہے کہ کنکشن بند کر دیا جائے گا۔ وائر پروٹوکول میں <span dir="ltr">PING</span> اور <span dir="ltr">PONG</span> پیغامات بھی شامل ہیں جو سیشن کو کھلا رکھنے کے لیے وقتاً فوقتاً بھیجے جاتے ہیں۔ لہذا <span dir="ltr">RLPx</span> اور وائر پروٹوکول کے تبادلے نوڈز کے درمیان مواصلات کی بنیادیں قائم کرتے ہیں، جو ایک مخصوص ذیلی پروٹوکول کے مطابق مفید معلومات کے تبادلے کے لیے ڈھانچہ فراہم کرتے ہیں۔

### ذیلی پروٹوکولز {#sub-protocols}

#### وائر پروٹوکول {#wire-protocol}

ایک بار جب پیئرز جڑ جاتے ہیں، اور ایک <span dir="ltr">RLPx</span> سیشن شروع ہو جاتا ہے، تو وائر پروٹوکول اس بات کی وضاحت کرتا ہے کہ پیئرز کیسے بات چیت کرتے ہیں۔ ابتدائی طور پر، وائر پروٹوکول نے تین اہم کاموں کی وضاحت کی: چین کی ہم آہنگی، بلاک کی ترسیل اور ٹرانزیکشن کا تبادلہ۔ تاہم، ایک بار جب ایتھیریم حصہ داری کا ثبوت (PoS) پر منتقل ہو گیا، تو بلاک کی ترسیل اور چین کی ہم آہنگی اتفاق رائے کی تہہ کا حصہ بن گئے۔ ٹرانزیکشن کا تبادلہ اب بھی ایگزیکیوشن کلائنٹس کے دائرہ کار میں ہے۔ ٹرانزیکشن کے تبادلے سے مراد نوڈز کے درمیان زیر التواء ٹرانزیکشنز کا تبادلہ کرنا ہے تاکہ بلاک بنانے والے اگلے بلاک میں شامل کرنے کے لیے ان میں سے کچھ کو منتخب کر سکیں۔ ان کاموں کے بارے میں تفصیلی معلومات [یہاں](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) دستیاب ہے۔ وہ کلائنٹس جو ان ذیلی پروٹوکولز کی حمایت کرتے ہیں وہ انہیں [جے سن آر پی سی](/developers/docs/apis/json-rpc/) کے ذریعے ظاہر کرتے ہیں۔

#### les (لائٹ ایتھیریم ذیلی پروٹوکول) {#les}

یہ لائٹ کلائنٹس کی ہم آہنگی کے لیے ایک کم سے کم پروٹوکول ہے۔ روایتی طور پر یہ پروٹوکول شاذ و نادر ہی استعمال کیا گیا ہے کیونکہ مکمل نوڈز کو بغیر کسی ترغیب کے لائٹ کلائنٹس کو ڈیٹا فراہم کرنے کی ضرورت ہوتی ہے۔ ایگزیکیوشن کلائنٹس کا پہلے سے طے شدہ رویہ <span dir="ltr">les</span> پر لائٹ کلائنٹ کا ڈیٹا فراہم کرنا نہیں ہے۔ مزید معلومات <span dir="ltr">les</span> کی [تفصیلات](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 (گواہ پروٹوکول) {#wit}

[گواہ پروٹوکول](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) ایک اختیاری توسیع ہے جو پیئرز کے درمیان حالت کے گواہوں کے تبادلے کو قابل بناتی ہے، جس سے کلائنٹس کو چین کی ٹپ کے ساتھ ہم آہنگی میں مدد ملتی ہے۔

#### وسپر (Whisper) {#whisper}

وسپر ایک پروٹوکول تھا جس کا مقصد بلاک چین پر کوئی معلومات لکھے بغیر پیئرز کے درمیان محفوظ پیغام رسانی فراہم کرنا تھا۔ یہ <span dir="ltr">devp2p</span> وائر پروٹوکول کا حصہ تھا لیکن اب اسے متروک کر دیا گیا ہے۔ اسی طرح کے مقاصد کے ساتھ دیگر [متعلقہ پروجیکٹس](https://wakunetwork.com/) موجود ہیں۔

## اتفاق رائے کی تہہ {#consensus-layer}

اتفاقِ رائے کے کلائنٹس ایک مختلف تصریح کے ساتھ ایک الگ پیئر ٹو پیئر نیٹ ورک میں حصہ لیتے ہیں۔ اتفاقِ رائے کے کلائنٹس کو بلاک گاسپ میں حصہ لینے کی ضرورت ہوتی ہے تاکہ وہ پیئرز سے نئے بلاکس وصول کر سکیں اور جب ان کی بلاک تجویز کنندہ بننے کی باری ہو تو انہیں نشر کر سکیں۔ عمل درآمد کی تہہ کی طرح، اس کے لیے پہلے ایک دریافت پروٹوکول کی ضرورت ہوتی ہے تاکہ ایک نوڈ پیئرز کو تلاش کر سکے اور بلاکس، تصدیقات وغیرہ کے تبادلے کے لیے محفوظ سیشن قائم کر سکے۔

### دریافت {#consensus-discovery}

ایگزیکیوشن کلائنٹس کی طرح، اتفاقِ رائے کے کلائنٹس پیئرز کو تلاش کرنے کے لیے <span dir="ltr">UDP</span> پر [discv5](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) کا استعمال کرتے ہیں۔ <span dir="ltr">discv5</span> کا اتفاق رائے کی تہہ کا نفاذ ایگزیکیوشن کلائنٹس سے صرف اس لحاظ سے مختلف ہے کہ اس میں ایک اڈاپٹر شامل ہے جو <span dir="ltr">discv5</span> کو [libp2p](https://libp2p.io/) اسٹیک سے جوڑتا ہے، جس سے <span dir="ltr">devp2p</span> متروک ہو جاتا ہے۔ عمل درآمد کی تہہ کے <span dir="ltr">RLPx</span> سیشنز کو <span dir="ltr">libp2p</span> کے نوائس سیکیور چینل ہینڈ شیک کے حق میں متروک کر دیا گیا ہے۔

### ENRs {#consensus-enr}

اتفاق رائے کے نوڈز کے لیے <span dir="ltr">ENR</span> میں نوڈ کی عوامی کلید، <span dir="ltr">IP</span> پتہ، <span dir="ltr">UDP</span> اور <span dir="ltr">TCP</span> پورٹس اور دو اتفاق رائے سے متعلق مخصوص فیلڈز شامل ہیں: تصدیق کا سب نیٹ بٹ فیلڈ اور `eth2` کلید۔ پہلا نوڈز کے لیے مخصوص تصدیقی گاسپ ذیلی نیٹ ورکس میں حصہ لینے والے پیئرز کو تلاش کرنا آسان بناتا ہے۔ `eth2` کلید میں اس بارے میں معلومات ہوتی ہیں کہ نوڈ کون سا ایتھیریم فورک ورژن استعمال کر رہا ہے، جس سے یہ یقینی بنتا ہے کہ پیئرز صحیح ایتھیریم سے جڑ رہے ہیں۔

### libp2p {#libp2p}

<span dir="ltr">libp2p</span> اسٹیک دریافت کے بعد تمام مواصلات کی حمایت کرتا ہے۔ کلائنٹس <span dir="ltr">IPv4</span> اور/یا <span dir="ltr">IPv6</span> پر ڈائل کر سکتے ہیں اور سن سکتے ہیں جیسا کہ ان کے <span dir="ltr">ENR</span> میں بیان کیا گیا ہے۔ <span dir="ltr">libp2p</span> تہہ پر موجود پروٹوکولز کو گاسپ اور درخواست/جواب (req/resp) ڈومینز میں ذیلی تقسیم کیا جا سکتا ہے۔

### گاسپ (Gossip) {#gossip}

گاسپ ڈومین میں وہ تمام معلومات شامل ہیں جنہیں پورے نیٹ ورک میں تیزی سے پھیلنا ہوتا ہے۔ اس میں بیکن بلاکس، ثبوت، تصدیقات، اخراج اور سلیشنگز شامل ہیں۔ یہ <span dir="ltr">libp2p gossipsub v1</span> کا استعمال کرتے ہوئے منتقل کیا جاتا ہے اور ہر نوڈ پر مقامی طور پر محفوظ کیے جانے والے مختلف میٹا ڈیٹا پر انحصار کرتا ہے، جس میں وصول کرنے اور منتقل کرنے کے لیے گاسپ پے لوڈز کا زیادہ سے زیادہ سائز شامل ہے۔ گاسپ ڈومین کے بارے میں تفصیلی معلومات [یہاں](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub) دستیاب ہے۔

### درخواست-جواب {#request-response}

درخواست-جواب ڈومین میں کلائنٹس کے لیے اپنے پیئرز سے مخصوص معلومات کی درخواست کرنے کے پروٹوکولز شامل ہیں۔ مثالوں میں مخصوص بیکن بلاکس کی درخواست کرنا شامل ہے جو مخصوص روٹ ہیشز سے ملتے ہیں یا سلاٹس کی ایک حد کے اندر ہوتے ہیں۔ جوابات ہمیشہ اسنیپی-کمپریسڈ <span dir="ltr">SSZ</span> انکوڈ شدہ بائٹس کے طور پر واپس کیے جاتے ہیں۔

## اتفاقِ رائے کا کلائنٹ RLP پر SSZ کو کیوں ترجیح دیتا ہے؟ {#ssz-vs-rlp}

<span dir="ltr">SSZ</span> کا مطلب سادہ سلسلہ بندی ہے۔ یہ فکسڈ آف سیٹس کا استعمال کرتا ہے جو پورے ڈھانچے کو ڈی کوڈ کیے بغیر انکوڈ شدہ پیغام کے انفرادی حصوں کو ڈی کوڈ کرنا آسان بناتا ہے، جو اتفاقِ رائے کے کلائنٹ کے لیے بہت مفید ہے کیونکہ یہ انکوڈ شدہ پیغامات سے مخصوص معلومات کو مؤثر طریقے سے حاصل کر سکتا ہے۔ اسے خاص طور پر مرکل پروٹوکولز کے ساتھ مربوط کرنے کے لیے بھی ڈیزائن کیا گیا ہے، جس میں مرکلائزیشن کے لیے متعلقہ کارکردگی کے فوائد ہیں۔ چونکہ اتفاق رائے کی تہہ میں تمام ہیشز مرکل روٹس ہیں، اس سے ایک نمایاں بہتری آتی ہے۔ <span dir="ltr">SSZ</span> اقدار کی منفرد نمائندگی کی بھی ضمانت دیتا ہے۔

## ایگزیکیوشن اور اتفاقِ رائے کے کلائنٹس کو جوڑنا {#connecting-clients}

اتفاقِ رائے اور ایگزیکیوشن کلائنٹس دونوں متوازی طور پر چلتے ہیں۔ انہیں جوڑنے کی ضرورت ہے تاکہ اتفاقِ رائے کا کلائنٹ ایگزیکیوشن کلائنٹ کو ہدایات فراہم کر سکے، اور ایگزیکیوشن کلائنٹ بیکن بلاکس میں شامل کرنے کے لیے ٹرانزیکشنز کے بنڈلز اتفاقِ رائے کے کلائنٹ کو منتقل کر سکے۔ دونوں کلائنٹس کے درمیان مواصلات ایک مقامی <span dir="ltr">RPC</span> کنکشن کا استعمال کرتے ہوئے حاصل کی جا سکتی ہے۔ ایک <span dir="ltr">API</span> جسے ['Engine-API'](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) کے نام سے جانا جاتا ہے، دونوں کلائنٹس کے درمیان بھیجی جانے والی ہدایات کی وضاحت کرتا ہے۔ چونکہ دونوں کلائنٹس ایک ہی نیٹ ورک شناخت کے پیچھے بیٹھتے ہیں، اس لیے وہ ایک <span dir="ltr">ENR</span> (ایتھیریم نوڈ ریکارڈ) کا اشتراک کرتے ہیں جس میں ہر کلائنٹ کے لیے ایک الگ کلید ہوتی ہے (ایتھ ۱ کلید اور ایتھ ۲ کلید)۔

کنٹرول فلو کا خلاصہ ذیل میں دکھایا گیا ہے، جس میں متعلقہ نیٹ ورکنگ اسٹیک بریکٹ میں ہے۔

### جب اتفاقِ رائے کا کلائنٹ بلاک پروڈیوسر نہیں ہوتا ہے: {#when-consensus-client-is-not-block-producer}

- اتفاقِ رائے کا کلائنٹ بلاک گاسپ پروٹوکول (اتفاق رائے <span dir="ltr">p2p</span>) کے ذریعے ایک بلاک وصول کرتا ہے
- اتفاقِ رائے کا کلائنٹ بلاک کی پہلے سے توثیق کرتا ہے، یعنی یہ یقینی بناتا ہے کہ یہ درست میٹا ڈیٹا کے ساتھ ایک درست بھیجنے والے سے آیا ہے
- بلاک میں موجود ٹرانزیکشنز کو عمل درآمد کی تہہ میں تعمیلی پے لوڈ کے طور پر بھیجا جاتا ہے (مقامی <span dir="ltr">RPC</span> کنکشن)
- عمل درآمد کی تہہ ٹرانزیکشنز پر عمل درآمد کرتی ہے اور بلاک ہیڈر میں حالت کی توثیق کرتی ہے (یعنی چیک کرتی ہے کہ ہیشز ملتے ہیں)
- عمل درآمد کی تہہ توثیق کا ڈیٹا واپس اتفاق رائے کی تہہ کو منتقل کرتی ہے، بلاک کو اب توثیق شدہ سمجھا جاتا ہے (مقامی <span dir="ltr">RPC</span> کنکشن)
- اتفاق رائے کی تہہ بلاک کو اپنی بلاک چین کے سرے پر شامل کرتی ہے اور اس کی تصدیق کرتی ہے، نیٹ ورک پر تصدیق کو نشر کرتی ہے (اتفاق رائے <span dir="ltr">p2p</span>)

### جب اتفاقِ رائے کا کلائنٹ بلاک پروڈیوسر ہوتا ہے: {#when-consensus-client-is-block-producer}

- اتفاقِ رائے کا کلائنٹ نوٹس وصول کرتا ہے کہ وہ اگلا بلاک پروڈیوسر ہے (اتفاق رائے <span dir="ltr">p2p</span>)
- اتفاق رائے کی تہہ ایگزیکیوشن کلائنٹ میں `create block` طریقہ کار کو کال کرتی ہے (مقامی <span dir="ltr">RPC</span>)
- عمل درآمد کی تہہ ٹرانزیکشن میم پول تک رسائی حاصل کرتی ہے جسے ٹرانزیکشن گاسپ پروٹوکول (ایگزیکیوشن <span dir="ltr">p2p</span>) کے ذریعے آباد کیا گیا ہے
- ایگزیکیوشن کلائنٹ ٹرانزیکشنز کو ایک بلاک میں بنڈل کرتا ہے، ٹرانزیکشنز پر عمل درآمد کرتا ہے اور ایک بلاک ہیش تیار کرتا ہے
- اتفاقِ رائے کا کلائنٹ ایگزیکیوشن کلائنٹ سے ٹرانزیکشنز اور بلاک ہیش حاصل کرتا ہے اور انہیں بیکن بلاک میں شامل کرتا ہے (مقامی <span dir="ltr">RPC</span>)
- اتفاقِ رائے کا کلائنٹ بلاک گاسپ پروٹوکول پر بلاک کو نشر کرتا ہے (اتفاق رائے <span dir="ltr">p2p</span>)
- دیگر کلائنٹس بلاک گاسپ پروٹوکول کے ذریعے مجوزہ بلاک وصول کرتے ہیں اور جیسا کہ اوپر بیان کیا گیا ہے توثیق کرتے ہیں (اتفاق رائے <span dir="ltr">p2p</span>)

ایک بار جب کافی توثیق کاروں کے ذریعے بلاک کی تصدیق ہو جاتی ہے تو اسے چین کے سرے پر شامل کر دیا جاتا ہے، جواز یافتہ اور بالآخر حتمی شکل دے دی جاتی ہے۔

![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/)
[ایتھ ۱/ایتھ ۲ کا رشتہ](https://ethresear.ch/t/eth1-eth2-client-relationship/7248)
[انضمام اور ایتھ ۲ کلائنٹ کی تفصیلات کی ویڈیو](https://www.youtube.com/watch?v=zNIrIninMgg)