طبقة الشبكات

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

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

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

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

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

طبقة التنفيذ

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

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

• حزمة DevP2P: تعتمد على بروتوكول TCP وتُمكّن العقد من تبادل المعلومات

تعمل كلتا الحزمتين بالتوازي. تُدخل حزمة الاكتشاف المشاركين الجدد إلى الشبكة، وتُمكّن حزمة DevP2P تفاعلاتهم.

الاكتشاف

الاكتشاف هو عملية العثور على عقد أخرى في الشبكة. يتم بدء هذه العملية باستخدام مجموعة صغيرة من عقد التمهيد (bootnodes) (وهي عقد تم تضمين عناوينها برمجيًا (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 هذه معلومات مجزأة (hashed) حول العقدة الجديدة، وعقدة التمهيد، وطابع زمني لانتهاء الصلاحية. تتلقى عقدة التمهيد رسالة PING وتُرجع رسالة PONG تحتوي على تجزئة PING. إذا تطابقت تجزئات PING و PONG، يتم التحقق من الاتصال بين العقدة الجديدة وعقدة التمهيد ويُقال إنهما قد "ارتبطتا".

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

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

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). هذا تنسيق مقاوم للمستقبل يسمح بتبادل أسهل لمعلومات التعريف بين النظراء الجدد وهو التنسيق المُفضل لـ عنوان الشبكة لعقد إيثريوم.

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

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

DevP2P

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

تبدأ جلسة RLPx بين عقدتين بمصافحة تشفيرية أولية (cryptographic handshake). يتضمن ذلك إرسال العقدة لرسالة مصادقة (auth message) يتم التحقق منها بعد ذلك بواسطة النظير. عند التحقق الناجح، يُنشئ النظير رسالة إقرار بالمصادقة (auth-acknowledgement) لإعادتها إلى العقدة البادئة. هذه عملية تبادل مفاتيح تُمكّن العقد من التواصل بشكل خاص وآمن. تؤدي المصافحة التشفيرية الناجحة بعد ذلك إلى قيام كلتا العقدتين بإرسال رسالة "hello" إلى بعضهما البعض "على السلك" (on the wire). يتم بدء بروتوكول السلك من خلال التبادل الناجح لرسائل hello.

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

• إصدار البروتوكول
• مُعرّف العميل (client ID)
• المنفذ (port)
• مُعرّف العقدة (node ID)
• قائمة بالبروتوكولات الفرعية المدعومة

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

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

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

بروتوكول السلك (Wire protocol)

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

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

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

Snap

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

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

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

Whisper

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

طبقة الإجماع

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

الاكتشاف

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

سجلات ENR

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

libP2P

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

النشر (Gossip)

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

الطلب والاستجابة (Request-response)

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

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

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

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

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

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

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

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

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

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

بمجرد أن يتم الإقرار بالبلوك من قبل عدد كافٍ من المدقّقين، تتم إضافته إلى قمة السلسلة، ويتم تبريره (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) مقدمة عن شبكة نظير لنظير في إيثريوم (opens in a new tab) العلاقة بين eth1 و eth2 (opens in a new tab) فيديو تفاصيل الدمج وعميل eth2 (opens in a new tab)