---
title: "طبقة الشبكات"
description: "مقدمة عن طبقة الشبكات في إيثيريوم."
lang: ar
sidebarDepth: 2
---

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

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

يقوم عملاء التنفيذ بنميمة المعاملات عبر شبكة نظير إلى نظير الخاصة بطبقة التنفيذ. يتطلب هذا اتصالًا مشفرًا بين النظراء المصادق عليهم. عندما يتم اختيار مُدَقِّق لاقتراح كتلة، سيتم تمرير المعاملات من مجمع المعاملات المحلي للعقدة إلى عملاء الإجماع عبر اتصال <span dir="ltr">RPC</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) لمشاركة قوائم العقد. تمتلك كل عقدة إصدارًا من هذا الجدول يحتوي على المعلومات المطلوبة للاتصال بأقرب نظرائها. هذا "القرب" ليس جغرافيًا - يتم تحديد المسافة من خلال تشابه معرف العقدة. يتم تحديث جدول كل عقدة بانتظام كميزة أمان. على سبيل المثال، في [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-PONG</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">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>، وبروتوكول السلك (wire protocol)، والعديد من البروتوكولات الفرعية. [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) هو البروتوكول الذي يحكم بدء الجلسات والمصادقة عليها والحفاظ عليها بين العقد. يقوم <span dir="ltr">RLPx</span> بتشفير الرسائل باستخدام <span dir="ltr">RLP</span> (بادئة الطول العودية) وهي طريقة فعالة جدًا من حيث المساحة لتشفير البيانات في بنية بسيطة لإرسالها بين العقد.

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

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

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

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

إلى جانب رسائل الترحيب، يمكن لبروتوكول السلك أيضًا إرسال رسالة "قطع الاتصال" (disconnect) التي تعطي تحذيرًا للنظير بأنه سيتم إغلاق الاتصال. يتضمن بروتوكول السلك أيضًا رسائل <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). العملاء الذين يدعمون هذه البروتوكولات الفرعية يعرضونها عبر [JSON-RPC](/developers/docs/apis/json-rpc/).

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

هذا بروتوكول بسيط لمزامنة العملاء الخفيفين. تقليديًا، نادرًا ما تم استخدام هذا البروتوكول لأن العقد الكاملة مطلوبة لتقديم البيانات للعملاء الخفيفين دون أن يتم تحفيزها. السلوك الافتراضي لعملاء التنفيذ هو عدم تقديم بيانات العميل الخفيف عبر <span dir="ltr">les</span>. يتوفر المزيد من المعلومات في [مواصفات](https://github.com/ethereum/devp2p/blob/master/caps/les.md) <span dir="ltr">les</span>.

#### Snap {#snap}

[بروتوكول snap](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap) هو امتداد اختياري يسمح للنظراء بتبادل لقطات للحالات الحديثة، مما يسمح للنظراء بالتحقق من بيانات الحساب والتخزين دون الحاجة إلى تنزيل عقد شجرة ميركل (Merkle trie) الوسيطة.

#### Wit (بروتوكول الشاهد) {#wit}

[بروتوكول الشاهد](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) هو امتداد اختياري يتيح تبادل شواهد الحالة بين النظراء، مما يساعد على مزامنة العملاء مع قمة السلسلة.

#### Whisper {#whisper}

كان <span dir="ltr">Whisper</span> بروتوكولًا يهدف إلى تقديم رسائل آمنة بين النظراء دون كتابة أي معلومات على سلسلة الكتل. كان جزءًا من بروتوكول السلك <span dir="ltr">DevP2P</span> ولكنه الآن مهمل. توجد [مشاريع أخرى ذات صلة](https://wakunetwork.com/) بأهداف مماثلة.

## طبقة الإجماع {#consensus-layer}

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

### الاكتشاف {#consensus-discovery}

على غرار عملاء التنفيذ، يستخدم عملاء الإجماع [discv5](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) عبر <span dir="ltr">UDP</span> للعثور على النظراء. يختلف تنفيذ طبقة الإجماع لـ <span dir="ltr">discv5</span> عن تنفيذ عملاء التنفيذ فقط في أنه يتضمن محولًا يربط <span dir="ltr">discv5</span> بحزمة [libP2P](https://libp2p.io/)، مما يجعل <span dir="ltr">DevP2P</span> مهملًا. تم إهمال جلسات <span dir="ltr">RLPx</span> الخاصة بطبقة التنفيذ لصالح مصافحة القناة الآمنة (noise secure channel handshake) الخاصة بـ <span dir="ltr">libP2P</span>.

### سجلات عقدة إيثيريوم (ENRs) {#consensus-enr}

يتضمن سجل عقدة إيثيريوم (ENR) لعقد الإجماع المفتاح العام للعقدة، وعنوان <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> كما هو محدد في سجل عقدة إيثيريوم (ENR) الخاص بهم. يمكن تقسيم البروتوكولات الموجودة على طبقة <span dir="ltr">libP2P</span> إلى مجالات النميمة والطلب/الاستجابة (req/resp).

### النميمة {#gossip}

يتضمن مجال النميمة جميع المعلومات التي يجب أن تنتشر بسرعة في جميع أنحاء الشبكة. يتضمن ذلك كتل المنارة، والإثباتات، والتصديقات، وعمليات الخروج، والاقتطاعات (slashings). يتم نقل هذا باستخدام <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}

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

## لماذا يفضل عميل الإجماع SSZ على RLP؟ {#ssz-vs-rlp}

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

## ربط عملاء التنفيذ والإجماع {#connecting-clients}

يعمل كل من عملاء الإجماع والتنفيذ بالتوازي. يجب أن يكونوا متصلين حتى يتمكن عميل الإجماع من تقديم تعليمات لعميل التنفيذ، ويمكن لعميل التنفيذ تمرير حزم من المعاملات إلى عميل الإجماع لإدراجها في كتل المنارة. يمكن تحقيق الاتصال بين العميلين باستخدام اتصال <span dir="ltr">RPC</span> محلي. تحدد واجهة برمجة التطبيقات (API) المعروفة باسم ['Engine-API'](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) التعليمات المرسلة بين العميلين. نظرًا لأن كلا العميلين يقعان خلف هوية شبكة واحدة، فإنهما يتشاركان في سجل عقدة إيثيريوم (ENR) الذي يحتوي على مفتاح منفصل لكل عميل (مفتاح إيث 1 ومفتاح إيث 2).

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

### عندما لا يكون عميل الإجماع هو منتج الكتلة: {#when-consensus-client-is-not-block-producer}

- يتلقى عميل الإجماع كتلة عبر بروتوكول نميمة الكتلة (نظير إلى نظير للإجماع)
- يقوم عميل الإجماع بالتحقق المسبق من الكتلة، أي يضمن وصولها من مرسل صالح ببيانات وصفية صحيحة
- يتم إرسال المعاملات الموجودة في الكتلة إلى طبقة التنفيذ كحمولة التنفيذ (اتصال <span dir="ltr">RPC</span> محلي)
- تقوم طبقة التنفيذ بتنفيذ المعاملات والتحقق من الحالة في رأس الكتلة (أي التحقق من تطابق التجزئات)
- تمرر طبقة التنفيذ بيانات التحقق مرة أخرى إلى طبقة الإجماع، وتعتبر الكتلة الآن قد تم التحقق منها (اتصال <span dir="ltr">RPC</span> محلي)
- تضيف طبقة الإجماع الكتلة إلى رأس سلسلة الكتل الخاصة بها وتصادق عليها، وتبث التصديق عبر الشبكة (نظير إلى نظير للإجماع)

### عندما يكون عميل الإجماع هو منتج الكتلة: {#when-consensus-client-is-block-producer}

- يتلقى عميل الإجماع إشعارًا بأنه منتج الكتلة التالي (نظير إلى نظير للإجماع)
- تستدعي طبقة الإجماع طريقة `create block` في عميل التنفيذ (اتصال <span dir="ltr">RPC</span> محلي)
- تصل طبقة التنفيذ إلى مجمع الذاكرة للمعاملات الذي تم ملؤه بواسطة بروتوكول نميمة المعاملات (نظير إلى نظير للتنفيذ)
- يقوم عميل التنفيذ بتجميع المعاملات في كتلة، وينفذ المعاملات ويولد تجزئة الكتلة
- يحصل عميل الإجماع على المعاملات وتجزئة الكتلة من عميل التنفيذ ويضيفها إلى كتلة المنارة (اتصال <span dir="ltr">RPC</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)
[مقدمة إلى شبكة نظير إلى نظير في إيثيريوم](https://p2p.paris/en/talks/intro-ethereum-networking/)
[العلاقة بين إيث 1 وإيث 2](https://ethresear.ch/t/eth1-eth2-client-relationship/7248)
[فيديو تفاصيل الدمج وعميل إيث 2](https://www.youtube.com/watch?v=zNIrIninMgg)