⁦نیٹ ورکنگ کی تہہ⁩

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

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

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

شرائط

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

عمل درآمد کی تہہ

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

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

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

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

دریافت

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

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

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

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

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

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

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

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

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

دریافت 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 سیشن ابتدائی کرپٹوگرافک ہینڈ شیک سے شروع ہوتا ہے۔ اس میں نوڈ ایک تصدیقی پیغام بھیجتا ہے جس کی پھر پیئر کے ذریعے تصدیق کی جاتی ہے۔ کامیاب تصدیق پر، پیئر شروع کرنے والے نوڈ کو واپس کرنے کے لیے ایک تصدیقی-اعترافی پیغام تیار کرتا ہے۔ یہ ایک کلید کے تبادلے کا عمل ہے جو نوڈز کو نجی اور محفوظ طریقے سے بات چیت کرنے کے قابل بناتا ہے۔ ایک کامیاب کرپٹوگرافک ہینڈ شیک پھر دونوں نوڈز کو ایک دوسرے کو "وائر پر" "ہیلو" پیغام بھیجنے کے لیے متحرک کرتا ہے۔ وائر پروٹوکول ہیلو پیغامات کے کامیاب تبادلے سے شروع ہوتا ہے۔

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

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

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

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

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

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

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

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

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

اسنیپ (Snap)

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

Wit (گواہ پروٹوکول)

گواہ پروٹوکول (opens in a new tab) ایک اختیاری توسیع ہے جو پیئرز کے درمیان حالت کے گواہوں کے تبادلے کو قابل بناتی ہے، جس سے کلائنٹس کو چین کی ٹپ کے ساتھ ہم آہنگی میں مدد ملتی ہے۔

وسپر (Whisper)

وسپر ایک پروٹوکول تھا جس کا مقصد بلاک چین پر کوئی معلومات لکھے بغیر پیئرز کے درمیان محفوظ پیغام رسانی فراہم کرنا تھا۔ یہ 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 کلید میں اس بارے میں معلومات ہوتی ہیں کہ نوڈ کون سا ایتھیریم فورک ورژن استعمال کر رہا ہے، جس سے یہ یقینی بنتا ہے کہ پیئرز صحیح ایتھیریم سے جڑ رہے ہیں۔

libp2p

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

گاسپ (Gossip)

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

درخواست-جواب

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

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

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

ایگزیکیوشن اور اتفاقِ رائے کے کلائنٹس کو جوڑنا

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

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

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

• اتفاقِ رائے کا کلائنٹ بلاک گاسپ پروٹوکول (اتفاق رائے 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 سے discv5 تک (opens in a new tab) kademlia پیپر (opens in a new tab) ایتھیریم p2p کا تعارف (opens in a new tab) ایتھ ۱/ایتھ ۲ کا رشتہ (opens in a new tab) انضمام اور ایتھ ۲ کلائنٹ کی تفصیلات کی ویڈیو (opens in a new tab)