نیٹ ورکنگ لیئر

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

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

ایگزیکیوشن کلائنٹس ایگزیکیوشن لیئر پیئر ٹو پیئر نیٹ ورک پر ٹرانزیکشنز کی گپ شپ کرتے ہیں۔ اس کے لیے تصدیق شدہ پیئرز کے درمیان انکرپٹڈ مواصلات کی ضرورت ہوتی ہے۔ جب کسی ویلیڈیٹر کو بلاک تجویز کرنے کے لیے منتخب کیا جاتا ہے، تو نوڈ کے مقامی ٹرانزیکشن پول سے ٹرانزیکشنز کو مقامی RPC کنکشن کے ذریعے کنسینسس کلائنٹس تک پہنچایا جائے گا، جنہیں بیکن (Beacon) بلاکس میں پیک کیا جائے گا۔ کنسینسس کلائنٹس پھر اپنے p2p نیٹ ورک پر بیکن بلاکس کی گپ شپ کریں گے۔ اس کے لیے دو الگ الگ p2p نیٹ ورکس کی ضرورت ہوتی ہے: ایک ٹرانزیکشن گپ شپ کے لیے ایگزیکیوشن کلائنٹس کو جوڑنے والا اور ایک بلاک گپ شپ کے لیے کنسینسس کلائنٹس کو جوڑنے والا۔

پیشگی شرائط

اس صفحے کو سمجھنے کے لیے ایتھیریم نوڈز اور کلائنٹس کا کچھ علم مددگار ثابت ہوگا۔

ایگزیکیوشن لیئر

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

• ڈسکوری اسٹیک: UDP کے اوپر بنایا گیا ہے اور ایک نئے نوڈ کو جڑنے کے لیے پیئرز تلاش کرنے کی اجازت دیتا ہے

• DevP2P اسٹیک: TCP کے اوپر بیٹھتا ہے اور نوڈز کو معلومات کا تبادلہ کرنے کے قابل بناتا ہے

دونوں اسٹیکس متوازی طور پر کام کرتے ہیں۔ ڈسکوری اسٹیک نیٹ ورک کے نئے شرکاء کو نیٹ ورک میں شامل کرتا ہے، اور DevP2P اسٹیک ان کے تعاملات کو ممکن بناتا ہے۔

ڈسکوری

ڈسکوری نیٹ ورک میں دوسرے نوڈز کو تلاش کرنے کا عمل ہے۔ اسے بوٹ نوڈز (bootnodes) کے ایک چھوٹے سیٹ کا استعمال کرتے ہوئے بوٹ اسٹریپ کیا جاتا ہے (وہ نوڈز جن کے پتے کلائنٹ میں ہارڈ کوڈڈ (opens in a new tab) ہوتے ہیں تاکہ انہیں فوری طور پر تلاش کیا جا سکے اور کلائنٹ کو پیئرز سے جوڑا جا سکے)۔ یہ بوٹ نوڈز صرف ایک نئے نوڈ کو پیئرز کے ایک سیٹ سے متعارف کرانے کے لیے موجود ہوتے ہیں - یہ ان کا واحد مقصد ہے، وہ چین کو سنک (sync) کرنے جیسے عام کلائنٹ کے کاموں میں حصہ نہیں لیتے ہیں، اور وہ صرف اس وقت استعمال ہوتے ہیں جب کلائنٹ کو پہلی بار شروع کیا جاتا ہے۔

نوڈ-بوٹ نوڈ تعاملات کے لیے استعمال ہونے والا پروٹوکول Kademlia (opens in a new tab) کی ایک ترمیم شدہ شکل ہے جو نوڈز کی فہرستوں کا اشتراک کرنے کے لیے ایک ڈسٹریبیوٹڈ ہیش ٹیبل (opens in a new tab) کا استعمال کرتا ہے۔ ہر نوڈ کے پاس اس ٹیبل کا ایک ورژن ہوتا ہے جس میں اس کے قریبی پیئرز سے جڑنے کے لیے درکار معلومات ہوتی ہیں۔ یہ 'قربت' جغرافیائی نہیں ہے - فاصلے کی تعریف نوڈ کی ID کی مماثلت سے کی جاتی ہے۔ حفاظتی خصوصیت کے طور پر ہر نوڈ کا ٹیبل باقاعدگی سے ریفریش کیا جاتا ہے۔ مثال کے طور پر، Discv5 (opens in a new tab) میں، ڈسکوری پروٹوکول نوڈز 'اشتہارات' بھیجنے کے بھی قابل ہوتے ہیں جو کلائنٹ کے تعاون یافتہ ذیلی پروٹوکولز کو ظاہر کرتے ہیں، جس سے پیئرز ان پروٹوکولز کے بارے میں بات چیت کر سکتے ہیں جنہیں وہ دونوں مواصلات کے لیے استعمال کر سکتے ہیں۔

ڈسکوری PING-PONG کے کھیل سے شروع ہوتی ہے۔ ایک کامیاب PING-PONG نئے نوڈ کو بوٹ نوڈ کے ساتھ "بونڈ" (bond) کرتا ہے۔ ابتدائی پیغام جو بوٹ نوڈ کو نیٹ ورک میں داخل ہونے والے نئے نوڈ کے وجود سے آگاہ کرتا ہے وہ ایک PING ہے۔ اس PING میں نئے نوڈ، بوٹ نوڈ اور میعاد ختم ہونے کے ٹائم اسٹیمپ کے بارے میں ہیش شدہ معلومات شامل ہوتی ہیں۔ بوٹ نوڈ PING وصول کرتا ہے اور PING ہیش پر مشتمل ایک PONG واپس کرتا ہے۔ اگر PING اور PONG ہیشز مماثل ہوں تو نئے نوڈ اور بوٹ نوڈ کے درمیان کنکشن کی تصدیق ہو جاتی ہے اور کہا جاتا ہے کہ وہ "بونڈ" ہو گئے ہیں۔

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

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

1start client --> connect to bootnode --> bond to bootnode --> find neighbours --> bond to neighbours

ایگزیکیوشن کلائنٹس فی الحال Discv4 (opens in a new tab) ڈسکوری پروٹوکول استعمال کر رہے ہیں اور Discv5 (opens in a new tab) پروٹوکول پر منتقل ہونے کی ایک فعال کوشش جاری ہے۔

ENR: ایتھیریم نوڈ ریکارڈز

ایتھیریم نوڈ ریکارڈ (ENR) ایک آبجیکٹ ہے جس میں تین بنیادی عناصر شامل ہیں: ایک دستخط (کسی متفقہ شناختی اسکیم کے مطابق بنائے گئے ریکارڈ کے مواد کا ہیش)، ایک ترتیب نمبر جو ریکارڈ میں ہونے والی تبدیلیوں کو ٹریک کرتا ہے، اور key:value جوڑوں کی ایک صوابدیدی فہرست۔ یہ ایک مستقبل کا ثبوت (future-proof) فارمیٹ ہے جو نئے پیئرز کے درمیان شناختی معلومات کے آسان تبادلے کی اجازت دیتا ہے اور ایتھیریم نوڈز کے لیے ترجیحی نیٹ ورک ایڈریس فارمیٹ ہے۔

ڈسکوری UDP پر کیوں بنائی گئی ہے؟

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

DevP2P

DevP2P بذات خود پروٹوکولز کا ایک پورا اسٹیک ہے جسے ایتھیریم پیئر ٹو پیئر نیٹ ورک قائم کرنے اور برقرار رکھنے کے لیے نافذ کرتا ہے۔ نئے نوڈز کے نیٹ ورک میں داخل ہونے کے بعد، ان کے تعاملات DevP2P (opens in a new tab) اسٹیک میں موجود پروٹوکولز کے ذریعے کنٹرول کیے جاتے ہیں۔ یہ سب TCP کے اوپر بیٹھتے ہیں اور ان میں RLPx ٹرانسپورٹ پروٹوکول، وائر پروٹوکول اور کئی ذیلی پروٹوکول شامل ہیں۔ RLPx (opens in a new tab) وہ پروٹوکول ہے جو نوڈز کے درمیان سیشنز شروع کرنے، تصدیق کرنے اور برقرار رکھنے کو کنٹرول کرتا ہے۔ RLPx پیغامات کو RLP (Recursive Length Prefix) کا استعمال کرتے ہوئے انکوڈ کرتا ہے جو نوڈز کے درمیان بھیجنے کے لیے کم سے کم ڈھانچے میں ڈیٹا کو انکوڈ کرنے کا ایک بہت ہی جگہ بچانے والا طریقہ ہے۔

دو نوڈز کے درمیان ایک RLPx سیشن ابتدائی کرپٹوگرافک ہینڈ شیک سے شروع ہوتا ہے۔ اس میں نوڈ ایک auth پیغام بھیجتا ہے جس کی پھر پیئر کے ذریعے تصدیق کی جاتی ہے۔ کامیاب تصدیق پر، پیئر شروع کرنے والے نوڈ کو واپس کرنے کے لیے ایک auth-acknowledgement پیغام تیار کرتا ہے۔ یہ ایک کلیدی تبادلے (key-exchange) کا عمل ہے جو نوڈز کو نجی اور محفوظ طریقے سے بات چیت کرنے کے قابل بناتا ہے۔ ایک کامیاب کرپٹوگرافک ہینڈ شیک پھر دونوں نوڈز کو "وائر پر" (on the wire) ایک دوسرے کو "ہیلو" پیغام بھیجنے کے لیے متحرک کرتا ہے۔ وائر پروٹوکول ہیلو پیغامات کے کامیاب تبادلے سے شروع ہوتا ہے۔

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

• پروٹوکول ورژن
• کلائنٹ ID
• پورٹ
• نوڈ ID
• تعاون یافتہ ذیلی پروٹوکولز کی فہرست

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

ہیلو پیغامات کے ساتھ، وائر پروٹوکول ایک "منقطع" (disconnect) پیغام بھی بھیج سکتا ہے جو کسی پیئر کو متنبہ کرتا ہے کہ کنکشن بند کر دیا جائے گا۔ وائر پروٹوکول میں PING اور PONG پیغامات بھی شامل ہیں جو سیشن کو کھلا رکھنے کے لیے وقتاً فوقتاً بھیجے جاتے ہیں۔ لہذا RLPx اور وائر پروٹوکول کے تبادلے نوڈز کے درمیان مواصلات کی بنیادیں قائم کرتے ہیں، جو ایک مخصوص ذیلی پروٹوکول کے مطابق مفید معلومات کے تبادلے کے لیے اسکیفولڈنگ (scaffolding) فراہم کرتے ہیں۔

ذیلی پروٹوکولز

وائر پروٹوکول

ایک بار جب پیئرز جڑ جاتے ہیں، اور ایک RLPx سیشن شروع ہو جاتا ہے، تو وائر پروٹوکول اس بات کی وضاحت کرتا ہے کہ پیئرز کیسے بات چیت کرتے ہیں۔ ابتدائی طور پر، وائر پروٹوکول نے تین اہم کاموں کی وضاحت کی: چین سنکرونائزیشن، بلاک پروپیگیشن اور ٹرانزیکشن کا تبادلہ۔ تاہم، ایک بار جب ایتھیریم پروف آف اسٹیک (proof-of-stake) پر منتقل ہو گیا، تو بلاک پروپیگیشن اور چین سنکرونائزیشن کنسینسس لیئر کا حصہ بن گئے۔ ٹرانزیکشن کا تبادلہ اب بھی ایگزیکیوشن کلائنٹس کے دائرہ کار میں ہے۔ ٹرانزیکشن کے تبادلے سے مراد نوڈز کے درمیان زیر التواء ٹرانزیکشنز کا تبادلہ کرنا ہے تاکہ بلاک بنانے والے اگلے بلاک میں شمولیت کے لیے ان میں سے کچھ کو منتخب کر سکیں۔ ان کاموں کے بارے میں تفصیلی معلومات یہاں (opens in a new tab) دستیاب ہے۔ وہ کلائنٹس جو ان ذیلی پروٹوکولز کی حمایت کرتے ہیں وہ انہیں JSON-RPC کے ذریعے ظاہر کرتے ہیں۔

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

یہ لائٹ کلائنٹس کو سنک کرنے کے لیے ایک کم سے کم پروٹوکول ہے۔ روایتی طور پر یہ پروٹوکول شاذ و نادر ہی استعمال کیا گیا ہے کیونکہ فل نوڈز کو بغیر کسی ترغیب کے لائٹ کلائنٹس کو ڈیٹا فراہم کرنے کی ضرورت ہوتی ہے۔ ایگزیکیوشن کلائنٹس کا ڈیفالٹ رویہ les پر لائٹ کلائنٹ ڈیٹا فراہم کرنا نہیں ہے۔ مزید معلومات les اسپیک (spec) (opens in a new tab) میں دستیاب ہے۔

Snap

اسنیپ پروٹوکول (snap protocol) (opens in a new tab) ایک اختیاری توسیع ہے جو پیئرز کو حالیہ اسٹیٹس (states) کے اسنیپ شاٹس کا تبادلہ کرنے کی اجازت دیتی ہے، جس سے پیئرز درمیانی مرکل ٹرائی (Merkle trie) نوڈز کو ڈاؤن لوڈ کیے بغیر اکاؤنٹ اور اسٹوریج ڈیٹا کی تصدیق کر سکتے ہیں۔

Wit (وٹنیس پروٹوکول)

وٹنیس پروٹوکول (witness protocol) (opens in a new tab) ایک اختیاری توسیع ہے جو پیئرز کے درمیان اسٹیٹ وٹنیسز (state witnesses) کے تبادلے کو قابل بناتی ہے، جس سے کلائنٹس کو چین کے سرے (tip) تک سنک کرنے میں مدد ملتی ہے۔

Whisper

وسپر (Whisper) ایک پروٹوکول تھا جس کا مقصد بلاک چین پر کوئی معلومات لکھے بغیر پیئرز کے درمیان محفوظ پیغام رسانی فراہم کرنا تھا۔ یہ DevP2P وائر پروٹوکول کا حصہ تھا لیکن اب اسے متروک (deprecated) کر دیا گیا ہے۔ اسی طرح کے مقاصد کے ساتھ دیگر متعلقہ پروجیکٹس (opens in a new tab) موجود ہیں۔

کنسینسس لیئر

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

ڈسکوری

ایگزیکیوشن کلائنٹس کی طرح، کنسینسس کلائنٹس پیئرز کو تلاش کرنے کے لیے UDP پر discv5 (opens in a new tab) کا استعمال کرتے ہیں۔ discv5 کا کنسینسس لیئر کا نفاذ ایگزیکیوشن کلائنٹس سے صرف اس لحاظ سے مختلف ہے کہ اس میں ایک اڈاپٹر شامل ہے جو discv5 کو libP2P (opens in a new tab) اسٹیک سے جوڑتا ہے، اور DevP2P کو متروک کرتا ہے۔ ایگزیکیوشن لیئر کے RLPx سیشنز کو libP2P کے noise secure channel ہینڈ شیک کے حق میں متروک کر دیا گیا ہے۔

ENRs

کنسینسس نوڈز کے لیے ENR میں نوڈ کی پبلک کی (public key)، IP ایڈریس، UDP اور TCP پورٹس اور دو کنسینسس کے لیے مخصوص فیلڈز شامل ہیں: attestation subnet bitfield اور eth2 کی۔ اول الذکر نوڈز کے لیے مخصوص تصدیقی گپ شپ ذیلی نیٹ ورکس میں حصہ لینے والے پیئرز کو تلاش کرنا آسان بناتا ہے۔ eth2 کی (key) میں اس بارے میں معلومات ہوتی ہیں کہ نوڈ کون سا ایتھیریم فورک ورژن استعمال کر رہا ہے، جس سے یہ یقینی بنتا ہے کہ پیئرز صحیح ایتھیریم سے جڑ رہے ہیں۔

libP2P

libP2P اسٹیک ڈسکوری کے بعد تمام مواصلات کی حمایت کرتا ہے۔ کلائنٹس اپنے ENR میں بیان کردہ کے مطابق IPv4 اور/یا IPv6 پر ڈائل کر سکتے ہیں اور سن سکتے ہیں۔ libP2P لیئر پر موجود پروٹوکولز کو گپ شپ (gossip) اور req/resp ڈومینز میں ذیلی تقسیم کیا جا سکتا ہے۔

گپ شپ (Gossip)

گپ شپ ڈومین میں وہ تمام معلومات شامل ہیں جنہیں پورے نیٹ ورک میں تیزی سے پھیلنا ہوتا ہے۔ اس میں بیکن بلاکس، ثبوت (proofs)، تصدیقات (attestations)، ایگزٹس (exits) اور سلیشنگز (slashings) شامل ہیں۔ یہ libP2P gossipsub v1 کا استعمال کرتے ہوئے منتقل کیا جاتا ہے اور ہر نوڈ پر مقامی طور پر محفوظ کیے جانے والے مختلف میٹا ڈیٹا پر انحصار کرتا ہے، جس میں وصول کرنے اور منتقل کرنے کے لیے گپ شپ پے لوڈز کا زیادہ سے زیادہ سائز شامل ہے۔ گپ شپ ڈومین کے بارے میں تفصیلی معلومات یہاں (opens in a new tab) دستیاب ہے۔

درخواست-جواب (Request-response)

درخواست-جواب ڈومین میں کلائنٹس کے لیے اپنے پیئرز سے مخصوص معلومات کی درخواست کرنے کے پروٹوکولز شامل ہیں۔ مثالوں میں مخصوص بیکن بلاکس کی درخواست کرنا شامل ہے جو مخصوص روٹ ہیشز سے مماثل ہوں یا سلاٹس کی ایک رینج کے اندر ہوں۔ جوابات ہمیشہ snappy-compressed SSZ انکوڈ شدہ بائٹس کے طور پر واپس کیے جاتے ہیں۔

کنسینسس کلائنٹ RLP پر SSZ کو کیوں ترجیح دیتا ہے؟

SSZ کا مطلب سادہ سیریلائزیشن (simple serialization) ہے۔ یہ فکسڈ آف سیٹس (fixed offsets) کا استعمال کرتا ہے جو پورے ڈھانچے کو ڈی کوڈ کیے بغیر انکوڈ شدہ پیغام کے انفرادی حصوں کو ڈی کوڈ کرنا آسان بناتا ہے، جو کنسینسس کلائنٹ کے لیے بہت مفید ہے کیونکہ یہ انکوڈ شدہ پیغامات سے مخصوص معلومات کو مؤثر طریقے سے حاصل کر سکتا ہے۔ اسے خاص طور پر مرکل (Merkle) پروٹوکولز کے ساتھ مربوط کرنے کے لیے بھی ڈیزائن کیا گیا ہے، جس میں مرکلائزیشن (Merkleization) کے لیے متعلقہ کارکردگی کے فوائد ہیں۔ چونکہ کنسینسس لیئر میں تمام ہیشز مرکل روٹس (Merkle roots) ہیں، اس سے ایک نمایاں بہتری آتی ہے۔ SSZ اقدار کی منفرد نمائندگی کی بھی ضمانت دیتا ہے۔

ایگزیکیوشن اور کنسینسس کلائنٹس کو جوڑنا

کنسینسس اور ایگزیکیوشن کلائنٹس دونوں متوازی طور پر چلتے ہیں۔ انہیں جوڑنے کی ضرورت ہے تاکہ کنسینسس کلائنٹ ایگزیکیوشن کلائنٹ کو ہدایات فراہم کر سکے، اور ایگزیکیوشن کلائنٹ بیکن بلاکس میں شامل کرنے کے لیے ٹرانزیکشنز کے بنڈل کنسینسس کلائنٹ کو بھیج سکے۔ دونوں کلائنٹس کے درمیان مواصلات مقامی RPC کنکشن کا استعمال کرتے ہوئے حاصل کی جا سکتی ہے۔ ایک API جسے 'Engine-API' (opens in a new tab) کے نام سے جانا جاتا ہے، دونوں کلائنٹس کے درمیان بھیجی جانے والی ہدایات کی وضاحت کرتا ہے۔ چونکہ دونوں کلائنٹس ایک ہی نیٹ ورک شناخت کے پیچھے بیٹھتے ہیں، اس لیے وہ ایک ENR (ایتھیریم نوڈ ریکارڈ) کا اشتراک کرتے ہیں جس میں ہر کلائنٹ کے لیے ایک الگ کی (key) ہوتی ہے (eth1 کی اور eth2 کی)۔

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

جب کنسینسس کلائنٹ بلاک پروڈیوسر نہیں ہوتا ہے:

• کنسینسس کلائنٹ بلاک گپ شپ پروٹوکول (consensus p2p) کے ذریعے ایک بلاک وصول کرتا ہے
• کنسینسس کلائنٹ بلاک کی پیشگی تصدیق کرتا ہے، یعنی یہ یقینی بناتا ہے کہ یہ درست میٹا ڈیٹا کے ساتھ ایک درست بھیجنے والے سے آیا ہے
• بلاک میں موجود ٹرانزیکشنز کو ایگزیکیوشن پے لوڈ (مقامی RPC کنکشن) کے طور پر ایگزیکیوشن لیئر میں بھیجا جاتا ہے
• ایگزیکیوشن لیئر ٹرانزیکشنز کو انجام دیتی ہے اور بلاک ہیڈر میں اسٹیٹ (state) کی تصدیق کرتی ہے (یعنی چیک کرتی ہے کہ ہیشز مماثل ہیں)
• ایگزیکیوشن لیئر توثیقی ڈیٹا واپس کنسینسس لیئر کو بھیجتی ہے، بلاک کو اب توثیق شدہ سمجھا جاتا ہے (مقامی RPC کنکشن)
• کنسینسس لیئر بلاک کو اپنی بلاک چین کے سرے (head) پر شامل کرتی ہے اور اس کی تصدیق کرتی ہے، نیٹ ورک پر تصدیق کو نشر کرتی ہے (consensus p2p)

جب کنسینسس کلائنٹ بلاک پروڈیوسر ہوتا ہے:

• کنسینسس کلائنٹ کو نوٹس ملتا ہے کہ وہ اگلا بلاک پروڈیوسر ہے (consensus p2p)
• کنسینسس لیئر ایگزیکیوشن کلائنٹ میں create block طریقہ کار کو کال کرتی ہے (مقامی RPC)
• ایگزیکیوشن لیئر ٹرانزیکشن میم پول (mempool) تک رسائی حاصل کرتی ہے جسے ٹرانزیکشن گپ شپ پروٹوکول (execution p2p) کے ذریعے آباد کیا گیا ہے
• ایگزیکیوشن کلائنٹ ٹرانزیکشنز کو ایک بلاک میں بنڈل کرتا ہے، ٹرانزیکشنز کو انجام دیتا ہے اور ایک بلاک ہیش تیار کرتا ہے
• کنسینسس کلائنٹ ایگزیکیوشن کلائنٹ سے ٹرانزیکشنز اور بلاک ہیش حاصل کرتا ہے اور انہیں بیکن بلاک میں شامل کرتا ہے (مقامی RPC)
• کنسینسس کلائنٹ بلاک گپ شپ پروٹوکول پر بلاک کو نشر کرتا ہے (consensus p2p)
• دوسرے کلائنٹس بلاک گپ شپ پروٹوکول کے ذریعے مجوزہ بلاک وصول کرتے ہیں اور اوپر بیان کردہ طریقے سے تصدیق کرتے ہیں (consensus p2p)

ایک بار جب کافی ویلیڈیٹرز کے ذریعے بلاک کی تصدیق ہو جاتی ہے تو اسے چین کے سرے پر شامل کر دیا جاتا ہے، جائز (justified) قرار دیا جاتا ہے اور بالآخر حتمی (finalized) شکل دی جاتی ہے۔

کنسینسس اور ایگزیکیوشن کلائنٹس کے لیے نیٹ ورک لیئر کی اسکیمیٹک، 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 سے discv5 تک (opens in a new tab) kademlia پیپر (opens in a new tab) ایتھیریم p2p کا تعارف (opens in a new tab) eth1/eth2 کا رشتہ (opens in a new tab) مرج اور eth2 کلائنٹ کی تفصیلات کی ویڈیو (opens in a new tab)