طبقة الشبكات

إيثيريوم هي شبكة نظير إلى نظير تضم آلاف العقد التي يجب أن تكون قادرة على التواصل مع بعضها البعض باستخدام بروتوكولات موحدة. "طبقة الشبكات" هي حزمة البروتوكولات التي تسمح لهذه العقد بالعثور على بعضها البعض وتبادل المعلومات. يتضمن ذلك "النميمة" بالمعلومات (اتصال من واحد إلى متعدد) عبر الشبكة بالإضافة إلى تبادل الطلبات والاستجابات بين عقد محددة (اتصال من واحد إلى واحد). يجب أن تلتزم كل عقدة بقواعد شبكات محددة لضمان إرسال واستقبال المعلومات الصحيحة.

هناك جزءان لبرنامج العميل (عملاء التنفيذ وعملاء الإجماع)، ولكل منهما حزمة شبكات مميزة خاصة به. بالإضافة إلى التواصل مع عقد إيثيريوم الأخرى، يجب أن يتواصل عملاء التنفيذ والإجماع مع بعضهم البعض. تقدم هذه الصفحة شرحًا تمهيديًا للبروتوكولات التي تتيح هذا الاتصال.

يقوم عملاء التنفيذ بنميمة المعاملات عبر شبكة نظير إلى نظير الخاصة بطبقة التنفيذ. يتطلب هذا اتصالًا مشفرًا بين النظراء المصادق عليهم. عندما يتم اختيار مُدَقِّق لاقتراح كتلة، سيتم تمرير المعاملات من مجمع المعاملات المحلي للعقدة إلى عملاء الإجماع عبر اتصال RPC محلي، والتي سيتم تجميعها في كتل المنارة. سيقوم عملاء الإجماع بعد ذلك بنميمة كتل المنارة عبر شبكة نظير إلى نظير الخاصة بهم. يتطلب هذا شبكتي نظير إلى نظير منفصلتين: واحدة تربط عملاء التنفيذ لنميمة المعاملات والأخرى تربط عملاء الإجماع لنميمة الكتل.

المتطلبات الأساسية

سيكون بعض المعرفة بـ عقد وعملاء إيثيريوم مفيدًا لفهم هذه الصفحة.

طبقة التنفيذ

تنقسم بروتوكولات الشبكات الخاصة بطبقة التنفيذ إلى حزمتين:

• حزمة الاكتشاف: مبنية فوق UDP وتسمح لعقدة جديدة بالعثور على نظراء للاتصال بهم

• حزمة DevP2P: تقع فوق TCP وتمكن العقد من تبادل المعلومات

تعمل كلتا الحزمتين بالتوازي. تقوم حزمة الاكتشاف بتغذية المشاركين الجدد في الشبكة، وتمكن حزمة DevP2P تفاعلاتهم.

الاكتشاف

الاكتشاف هو عملية العثور على عقد أخرى في الشبكة. يتم تمهيد هذا باستخدام مجموعة صغيرة من عقد التمهيد (العقد التي تكون عناوينها مضمنة (opens in a new tab) في العميل بحيث يمكن العثور عليها على الفور وربط العميل بالنظراء). توجد عقد التمهيد هذه فقط لتقديم عقدة جديدة إلى مجموعة من النظراء - هذا هو غرضها الوحيد، فهي لا تشارك في مهام العميل العادية مثل مزامنة السلسلة، ويتم استخدامها فقط في المرة الأولى التي يتم فيها تشغيل العميل.

البروتوكول المستخدم لتفاعلات العقدة وعقدة التمهيد هو شكل معدل من Kademlia (opens in a new tab) والذي يستخدم جدول تجزئة موزع (opens in a new tab) لمشاركة قوائم العقد. تمتلك كل عقدة إصدارًا من هذا الجدول يحتوي على المعلومات المطلوبة للاتصال بأقرب نظرائها. هذا "القرب" ليس جغرافيًا - يتم تحديد المسافة من خلال تشابه معرف العقدة. يتم تحديث جدول كل عقدة بانتظام كميزة أمان. على سبيل المثال، في Discv5 (opens in a new tab)، تكون عقد بروتوكول الاكتشاف قادرة أيضًا على إرسال "إعلانات" تعرض البروتوكولات الفرعية التي يدعمها العميل، مما يسمح للنظراء بالتفاوض حول البروتوكولات التي يمكن لكليهما استخدامها للتواصل.

يبدأ الاكتشاف بلعبة PING-PONG. تؤدي لعبة PING-PONG الناجحة إلى "ربط" العقدة الجديدة بعقدة التمهيد. الرسالة الأولية التي تنبه عقدة التمهيد بوجود عقدة جديدة تدخل الشبكة هي PING. يتضمن هذا الـ PING معلومات مجزأة حول العقدة الجديدة وعقدة التمهيد وطابع زمني لانتهاء الصلاحية. تتلقى عقدة التمهيد الـ PING وتعيد PONG يحتوي على تجزئة PING. إذا تطابقت تجزئات PING و PONG، فسيتم التحقق من الاتصال بين العقدة الجديدة وعقدة التمهيد ويقال إنهما قد "ارتبطا".

بمجرد الارتباط، يمكن للعقدة الجديدة إرسال طلب FIND-NEIGHBOURS إلى عقدة التمهيد. تتضمن البيانات التي تعيدها عقدة التمهيد قائمة بالنظراء الذين يمكن للعقدة الجديدة الاتصال بهم. إذا لم تكن العقد مرتبطة، فسيفشل طلب FIND-NEIGHBOURS، وبالتالي لن تتمكن العقدة الجديدة من دخول الشبكة.

بمجرد أن تتلقى العقدة الجديدة قائمة بالجيران من عقدة التمهيد، فإنها تبدأ تبادل PING-PONG مع كل منهم. تؤدي عمليات PING-PONG الناجحة إلى ربط العقدة الجديدة بجيرانها، مما يتيح تبادل الرسائل.

بدء العميل --> الاتصال بعقدة التمهيد --> الارتباط بعقدة التمهيد --> العثور على الجيران --> الارتباط بالجيران

يستخدم عملاء التنفيذ حاليًا بروتوكول الاكتشاف Discv4 (opens in a new tab) وهناك جهد نشط للانتقال إلى بروتوكول Discv5 (opens in a new tab).

ENR: سجلات عقدة إيثيريوم

سجل عقدة إيثيريوم (ENR) هو كائن يحتوي على ثلاثة عناصر أساسية: توقيع (تجزئة لمحتويات السجل تم إجراؤها وفقًا لمخطط هوية متفق عليه)، ورقم تسلسلي يتتبع التغييرات في السجل، وقائمة عشوائية من أزواج المفتاح:القيمة. هذا تنسيق مقاوم للمستقبل يسمح بتبادل أسهل لمعلومات التعريف بين النظراء الجدد وهو التنسيق المفضل لـ عنوان الشبكة لعقد إيثيريوم.

لماذا تم بناء الاكتشاف على UDP؟

لا يدعم UDP أي فحص للأخطاء، أو إعادة إرسال الحزم الفاشلة، أو فتح وإغلاق الاتصالات ديناميكيًا - بدلاً من ذلك، فإنه يطلق ببساطة دفقًا مستمرًا من المعلومات نحو هدف، بغض النظر عما إذا تم استلامه بنجاح أم لا. تُترجم هذه الوظيفة البسيطة أيضًا إلى الحد الأدنى من النفقات العامة، مما يجعل هذا النوع من الاتصال سريعًا جدًا. بالنسبة للاكتشاف، حيث تريد العقدة ببساطة الإعلان عن وجودها من أجل إنشاء اتصال رسمي مع نظير لاحقًا، فإن UDP كافٍ. ومع ذلك، بالنسبة لبقية حزمة الشبكات، فإن UDP غير مناسب للغرض. التبادل المعلوماتي بين العقد معقد للغاية وبالتالي يحتاج إلى بروتوكول كامل الميزات يمكنه دعم إعادة الإرسال، وفحص الأخطاء، وما إلى ذلك. النفقات العامة الإضافية المرتبطة بـ TCP تستحق الوظائف الإضافية. لذلك، تعمل غالبية حزمة نظير إلى نظير عبر TCP.

DevP2P

DevP2P بحد ذاته عبارة عن حزمة كاملة من البروتوكولات التي تنفذها إيثيريوم لإنشاء شبكة نظير إلى نظير والحفاظ عليها. بعد دخول العقد الجديدة إلى الشبكة، تُحكم تفاعلاتها بواسطة بروتوكولات في حزمة DevP2P (opens in a new tab). تقع جميعها فوق TCP وتتضمن بروتوكول النقل RLPx، وبروتوكول السلك (wire protocol)، والعديد من البروتوكولات الفرعية. RLPx (opens in a new tab) هو البروتوكول الذي يحكم بدء الجلسات والمصادقة عليها والحفاظ عليها بين العقد. يقوم RLPx بتشفير الرسائل باستخدام RLP (بادئة الطول العودية) وهي طريقة فعالة جدًا من حيث المساحة لتشفير البيانات في بنية بسيطة لإرسالها بين العقد.

تبدأ جلسة RLPx بين عقدتين بمصافحة تشفيرية أولية. يتضمن ذلك إرسال العقدة لرسالة مصادقة يتم التحقق منها بعد ذلك بواسطة النظير. عند التحقق الناجح، يقوم النظير بإنشاء رسالة إقرار بالمصادقة للعودة إلى العقدة البادئة. هذه عملية تبادل مفاتيح تمكن العقد من التواصل بشكل خاص وآمن. تؤدي المصافحة التشفيرية الناجحة بعد ذلك إلى قيام كلتا العقدتين بإرسال رسالة "مرحبًا" (hello) إلى بعضهما البعض "على السلك". يتم بدء بروتوكول السلك من خلال تبادل ناجح لرسائل الترحيب.

تحتوي رسائل الترحيب على:

• إصدار البروتوكول
• معرف العميل
• المنفذ
• معرف العقدة
• قائمة بالبروتوكولات الفرعية المدعومة

هذه هي المعلومات المطلوبة لتفاعل ناجح لأنها تحدد الإمكانات المشتركة بين كلتا العقدتين وتكوّن الاتصال. هناك عملية تفاوض على البروتوكول الفرعي حيث تتم مقارنة قوائم البروتوكولات الفرعية التي تدعمها كل عقدة ويمكن استخدام تلك المشتركة بين كلتا العقدتين في الجلسة.

إلى جانب رسائل الترحيب، يمكن لبروتوكول السلك أيضًا إرسال رسالة "قطع الاتصال" (disconnect) التي تعطي تحذيرًا للنظير بأنه سيتم إغلاق الاتصال. يتضمن بروتوكول السلك أيضًا رسائل PING و PONG التي يتم إرسالها بشكل دوري لإبقاء الجلسة مفتوحة. وبالتالي، فإن تبادلات RLPx وبروتوكول السلك ترسي أسس الاتصال بين العقد، مما يوفر السقالات لتبادل المعلومات المفيدة وفقًا لبروتوكول فرعي محدد.

البروتوكولات الفرعية

بروتوكول السلك

بمجرد اتصال النظراء، وبدء جلسة RLPx، يحدد بروتوكول السلك كيفية تواصل النظراء. في البداية، حدد بروتوكول السلك ثلاث مهام رئيسية: مزامنة السلسلة، وانتشار الكتلة، وتبادل المعاملات. ومع ذلك، بمجرد انتقال إيثيريوم إلى إثبات الحصة (PoS)، أصبح انتشار الكتلة ومزامنة السلسلة جزءًا من طبقة الإجماع. لا يزال تبادل المعاملات من اختصاص عملاء التنفيذ. يشير تبادل المعاملات إلى تبادل المعاملات المعلقة بين العقد بحيث يمكن لمنشئي الكتل اختيار بعضها لإدراجها في الكتلة التالية. تتوفر معلومات مفصلة حول هذه المهام هنا (opens in a new tab). العملاء الذين يدعمون هذه البروتوكولات الفرعية يعرضونها عبر JSON-RPC.

les (بروتوكول إيثيريوم الفرعي الخفيف)

هذا بروتوكول بسيط لمزامنة العملاء الخفيفين. تقليديًا، نادرًا ما تم استخدام هذا البروتوكول لأن العقد الكاملة مطلوبة لتقديم البيانات للعملاء الخفيفين دون أن يتم تحفيزها. السلوك الافتراضي لعملاء التنفيذ هو عدم تقديم بيانات العميل الخفيف عبر les. يتوفر المزيد من المعلومات في مواصفات (opens in a new tab) les.

Snap

بروتوكول snap (opens in a new tab) هو امتداد اختياري يسمح للنظراء بتبادل لقطات للحالات الحديثة، مما يسمح للنظراء بالتحقق من بيانات الحساب والتخزين دون الحاجة إلى تنزيل عقد شجرة ميركل (Merkle trie) الوسيطة.

Wit (بروتوكول الشاهد)

بروتوكول الشاهد (opens in a new tab) هو امتداد اختياري يتيح تبادل شواهد الحالة بين النظراء، مما يساعد على مزامنة العملاء مع قمة السلسلة.

Whisper

كان Whisper بروتوكولًا يهدف إلى تقديم رسائل آمنة بين النظراء دون كتابة أي معلومات على سلسلة الكتل. كان جزءًا من بروتوكول السلك DevP2P ولكنه الآن مهمل. توجد مشاريع أخرى ذات صلة (opens in a new tab) بأهداف مماثلة.

طبقة الإجماع

يشارك عملاء الإجماع في شبكة نظير إلى نظير منفصلة بمواصفات مختلفة. يحتاج عملاء الإجماع إلى المشاركة في نميمة الكتلة حتى يتمكنوا من تلقي كتل جديدة من النظراء وبثها عندما يحين دورهم ليكونوا مقترح الكتلة. على غرار طبقة التنفيذ، يتطلب هذا أولاً بروتوكول اكتشاف حتى تتمكن العقدة من العثور على نظراء وإنشاء جلسات آمنة لتبادل الكتل والتصديقات وما إلى ذلك.

الاكتشاف

على غرار عملاء التنفيذ، يستخدم عملاء الإجماع discv5 (opens in a new tab) عبر UDP للعثور على النظراء. يختلف تنفيذ طبقة الإجماع لـ discv5 عن تنفيذ عملاء التنفيذ فقط في أنه يتضمن محولًا يربط discv5 بحزمة libP2P (opens in a new tab)، مما يجعل DevP2P مهملًا. تم إهمال جلسات RLPx الخاصة بطبقة التنفيذ لصالح مصافحة القناة الآمنة (noise secure channel handshake) الخاصة بـ libP2P.

سجلات عقدة إيثيريوم (ENRs)

يتضمن سجل عقدة إيثيريوم (ENR) لعقد الإجماع المفتاح العام للعقدة، وعنوان IP، ومنافذ UDP و TCP، وحقلين خاصين بالإجماع: حقل بتات الشبكة الفرعية للتصديق ومفتاح eth2. يسهل الأول على العقد العثور على النظراء المشاركين في شبكات فرعية محددة لنميمة التصديق. يحتوي مفتاح eth2 على معلومات حول إصدار تفرع إيثيريوم الذي تستخدمه العقدة، مما يضمن اتصال النظراء بشبكة إيثيريوم الصحيحة.

libP2P

تدعم حزمة libP2P جميع الاتصالات بعد الاكتشاف. يمكن للعملاء الاتصال والاستماع على IPv4 و/أو IPv6 كما هو محدد في سجل عقدة إيثيريوم (ENR) الخاص بهم. يمكن تقسيم البروتوكولات الموجودة على طبقة libP2P إلى مجالات النميمة والطلب/الاستجابة (req/resp).

النميمة

يتضمن مجال النميمة جميع المعلومات التي يجب أن تنتشر بسرعة في جميع أنحاء الشبكة. يتضمن ذلك كتل المنارة، والإثباتات، والتصديقات، وعمليات الخروج، والاقتطاعات (slashings). يتم نقل هذا باستخدام libP2P gossipsub v1 ويعتمد على بيانات وصفية مختلفة يتم تخزينها محليًا في كل عقدة، بما في ذلك الحد الأقصى لحجم حمولات النميمة التي يمكن استقبالها وإرسالها. تتوفر معلومات مفصلة حول مجال النميمة هنا (opens in a new tab).

الطلب والاستجابة

يحتوي مجال الطلب والاستجابة على بروتوكولات للعملاء الذين يطلبون معلومات محددة من نظرائهم. تشمل الأمثلة طلب كتل منارة محددة تتطابق مع تجزئات جذر معينة أو ضمن نطاق من الفترات (slots). يتم إرجاع الاستجابات دائمًا كبايتات مشفرة بـ SSZ ومضغوطة بـ snappy.

لماذا يفضل عميل الإجماع SSZ على RLP؟

يرمز SSZ إلى التسلسل البسيط. يستخدم إزاحات ثابتة تجعل من السهل فك تشفير الأجزاء الفردية من رسالة مشفرة دون الحاجة إلى فك تشفير البنية بأكملها، وهو أمر مفيد جدًا لعميل الإجماع حيث يمكنه الحصول بكفاءة على أجزاء محددة من المعلومات من الرسائل المشفرة. تم تصميمه أيضًا خصيصًا للتكامل مع بروتوكولات ميركل (Merkle)، مع مكاسب الكفاءة ذات الصلة لعملية الميركلة (Merkleization). نظرًا لأن جميع التجزئات في طبقة الإجماع هي جذور ميركل، فإن هذا يضيف تحسنًا كبيرًا. يضمن SSZ أيضًا تمثيلات فريدة للقيم.

ربط عملاء التنفيذ والإجماع

يعمل كل من عملاء الإجماع والتنفيذ بالتوازي. يجب أن يكونوا متصلين حتى يتمكن عميل الإجماع من تقديم تعليمات لعميل التنفيذ، ويمكن لعميل التنفيذ تمرير حزم من المعاملات إلى عميل الإجماع لإدراجها في كتل المنارة. يمكن تحقيق الاتصال بين العميلين باستخدام اتصال RPC محلي. تحدد واجهة برمجة التطبيقات (API) المعروفة باسم 'Engine-API' (opens in a new tab) التعليمات المرسلة بين العميلين. نظرًا لأن كلا العميلين يقعان خلف هوية شبكة واحدة، فإنهما يتشاركان في سجل عقدة إيثيريوم (ENR) الذي يحتوي على مفتاح منفصل لكل عميل (مفتاح إيث 1 ومفتاح إيث 2).

يظهر ملخص لتدفق التحكم أدناه، مع حزمة الشبكات ذات الصلة بين قوسين.

عندما لا يكون عميل الإجماع هو منتج الكتلة:

• يتلقى عميل الإجماع كتلة عبر بروتوكول نميمة الكتلة (نظير إلى نظير للإجماع)
• يقوم عميل الإجماع بالتحقق المسبق من الكتلة، أي يضمن وصولها من مرسل صالح ببيانات وصفية صحيحة
• يتم إرسال المعاملات الموجودة في الكتلة إلى طبقة التنفيذ كحمولة التنفيذ (اتصال RPC محلي)
• تقوم طبقة التنفيذ بتنفيذ المعاملات والتحقق من الحالة في رأس الكتلة (أي التحقق من تطابق التجزئات)
• تمرر طبقة التنفيذ بيانات التحقق مرة أخرى إلى طبقة الإجماع، وتعتبر الكتلة الآن قد تم التحقق منها (اتصال RPC محلي)
• تضيف طبقة الإجماع الكتلة إلى رأس سلسلة الكتل الخاصة بها وتصادق عليها، وتبث التصديق عبر الشبكة (نظير إلى نظير للإجماع)

عندما يكون عميل الإجماع هو منتج الكتلة:

• يتلقى عميل الإجماع إشعارًا بأنه منتج الكتلة التالي (نظير إلى نظير للإجماع)
• تستدعي طبقة الإجماع طريقة create block في عميل التنفيذ (اتصال RPC محلي)
• تصل طبقة التنفيذ إلى مجمع الذاكرة للمعاملات الذي تم ملؤه بواسطة بروتوكول نميمة المعاملات (نظير إلى نظير للتنفيذ)
• يقوم عميل التنفيذ بتجميع المعاملات في كتلة، وينفذ المعاملات ويولد تجزئة الكتلة
• يحصل عميل الإجماع على المعاملات وتجزئة الكتلة من عميل التنفيذ ويضيفها إلى كتلة المنارة (اتصال RPC محلي)
• يبث عميل الإجماع الكتلة عبر بروتوكول نميمة الكتلة (نظير إلى نظير للإجماع)
• يتلقى العملاء الآخرون الكتلة المقترحة عبر بروتوكول نميمة الكتلة ويتحققون منها كما هو موضح أعلاه (نظير إلى نظير للإجماع)

بمجرد أن يتم التصديق على الكتلة من قبل عدد كافٍ من المُدَقِّقين، تتم إضافتها إلى رأس السلسلة، وتصبح مبررة وفي النهاية نهائية.

مخطط طبقة الشبكة لعملاء الإجماع والتنفيذ، من 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) مقدمة إلى شبكة نظير إلى نظير في إيثيريوم (opens in a new tab) العلاقة بين إيث 1 وإيث 2 (opens in a new tab) فيديو تفاصيل الدمج وعميل إيث 2 (opens in a new tab)