> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# تشغيل عقدة Ethereum: عميل التنفيذ وعميل الإجماع
- URL: https://arabroot.io/articles/تشغيل-عقدة-ethereum-عميل-التنفيذ-وعميل-الاجماع/
- Published: 2026-10-28T06:31:30.000Z
- Updated: 2026-10-28T07:37:41.000Z
- Description: نشغل عميل تنفيذ حقيقي على جهازنا ونرسل إليه معاملة، ونفهم لماذا صارت العقدة برنامجين، ومتى تشغل عقدتك بدل مزود خارجي.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, البلوكتشين والعملات الرقمية

طوال المقالات الأربعة الماضية كان فريق منصة العمل الحر يتكلم مع شبكة Ethereum عبر عقدة واحدة شغلها بأداة Anvil، ويرسل المعاملات بالأمر `cast` ويقرأ الحالة بالأمر `eth_call`. وفي كل مرة كان يفترض أن العقدة تقول له الحقيقة: هذا رصيدك، هذه الكتلة الأخيرة، نجحت معاملتك. ثم جاء سؤال من مطور الفريق قلب الصورة: عندما نطلق المنصة على الشبكة الرئيسية، من أين نقرأ الحالة فعلاً؟ هل نثق بخدمة خارجية ترسل لنا الأرقام، أم نشغل عقدتنا بأنفسنا؟ وما الفرق؟ ولماذا يقول الناس إن تشغيل عقدة Ethereum صار يحتاج برنامجين لا واحداً؟ وهذه الأسئلة هي بالضبط ما يجب أن يفهمه أي فريق قبل أن يبني على Ethereum، لأن الجواب يحدد هل يتحقق النظام من البيانات بنفسه أم يثق بغيره، وهذا فرق في جوهر الأمان لا في التفاصيل.

ولتوضيح أهمية السؤال، تخيل أن المنصة بنت كل منطقها على قراءة الحالة من خدمة واحدة ترسل لها الأرقام، ثم في يوم ما أعطتها الخدمة رصيداً خاطئاً لعقد ضمان، أو أخفت عنها حدث صرف، أو تأخرت لحظة. المنصة لا تملك وسيلة لتكتشف الخطأ، لأنها لا ترى إلا ما ترسله الخدمة، تماماً كما لا ترى عميل البنك إلا ما يعرضه له البنك، وهو ما بدأنا به مقال البلوكتشين للمبتدئين. وفكرة Ethereum الأصلية أنك لا تضطر إلى هذه الثقة: تستطيع أن تشغل عقدة تتحقق بنفسها من كل كتلة، فلا تصدق رقماً إلا بعد أن يثبت بقواعد الشبكة. وهذا ما تلخصه ethereum.org بعبارة «لا تثق، تحقق» Don't Trust, Verify، وهي العبارة التي سوف تتكرر في هذا المقال لأنها الخيط الذي يربط كل قراراته.

وهذا المقال تعليمي تقني فقط، وكل التجارب فيه تعمل على جهازك: سوف نشغل عميل تنفيذ حقيقي، وهو برنامج Geth، في وضع تطوير محلي ينتج كتلة كل اثنتي عشرة ثانية، ونرى بأعيننا ما يقدمه، ولن نزامن الشبكة الرئيسية إطلاقاً لأنها تحتاج قرصاً كبيراً ووقتاً طويلاً ولا لزوم لها للفهم. وهو المقال السادس في مرحلة Ethereum، ويبني على ما شرحناه في [مقال كيف يعمل Ethereum](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D9%8A%D8%B9%D9%85%D9%84-ethereum-%D8%A7%D9%84%D8%AD%D8%B3%D8%A7%D8%A8%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%BA%D8%A7%D8%B2-%D9%88%D8%A7%D9%84%D8%A9-evm/) و[مقال الإجماع](https://arabroot.io/articles/%D8%A7%D9%84%D8%A7%D8%AC%D9%85%D8%A7%D8%B9-%D9%81%D9%8A-%D8%A7%D9%84%D8%A8%D9%84%D9%88%D9%83%D8%AA%D8%B4%D9%8A%D9%86-%D8%A7%D8%AB%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%B9%D9%85%D9%84-%D9%88%D8%A7%D8%AB%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%AD%D8%B5%D8%A9/).

وسوف نناقش في هذا المقال ما يلي:

- لماذا صارت العقدة الكاملة برنامجين: عميل التنفيذ وعميل الإجماع، وما يربطهما.
- تجربة: نشغل عميل تنفيذ حقيقي محلي، ونسأله عن نفسه، ونرسل إليه معاملة نراها تدخل كتلة.
- الواجهة العامة JSON-RPC وواجهة المحرك Engine API، ولماذا تحمي الثانية بسر JWT.
- أنواع العقد: الكاملة والأرشيفية والخفيفة، وما يحفظه كل نوع وما يكلفه.
- كيف تبدأ العقدة من الصفر: المزامنة السريعة ومن نقطة تفتيش، ولماذا كلها تعود إلى «لا تثق تحقق».
- عقدتك أم مزود خارجي؟ المفاضلة، وقائمة تحقق للفريق.

## لماذا صارت العقدة برنامجين؟

قبل حدث The Merge يوم 15 سبتمبر 2022، كان تشغيل عقدة Ethereum يحتاج برنامجاً واحداً يفعل كل شيء: يحفظ الحالة، وينفذ المعاملات، ويشارك في الإجماع بإثبات العمل. ولم يحدث التحول فجأة، وإنما عملت طبقة الإجماع الجديدة، أي سلسلة البيكون Beacon Chain، على التوازي قرابة سنتين قبل أن تندمج: أطلقت في ديسمبر 2020 وجمعت المدققين وأموالهم المحجوزة دون أن تتحكم في المعاملات، حتى إذا نضجت جاء The Merge فربطها بطبقة التنفيذ القديمة وأوقف إثبات العمل. ولكن The Merge نقل Ethereum إلى إثبات الحصة كما شرحنا في مقال الإجماع، وفصل العمل إلى طبقتين لكل منها برنامج، كما يصف [توثيق العقد والعملاء](https://ethereum.org/en/developers/docs/nodes-and-clients/?ref=arabroot.io):

- **عميل التنفيذ Execution Client**: هو الذي رأيناه في كل المقالات، يشغل آلة EVM، ويحفظ الحالة State وقاعدة البيانات، ويستقبل المعاملات ويحفظها في طابور Mempool، ويقدم واجهة JSON-RPC التي تسألها المحافظ والتطبيقات. وأشهر عملاء التنفيذ Geth وReth وNethermind وBesu، وقد ذكرنا رخصها في مقال البلوكتشين للمبتدئين.
- **عميل الإجماع Consensus Client**: برنامج آخر يشغل منطق إثبات الحصة، أي الخانات والحقب والنهائية التي شرحناها في مقال الإجماع، ويتابع من يقترح الكتلة وأيها أصبحت نهائية. وأشهره Lighthouse وPrysm وTeku وNimbus. وإذا أراد صاحب العقدة أن يصبح مدققاً يحجز 32 ETH ويساعد في تأمين الشبكة، أضاف إلى عميل الإجماع برنامج مدقق Validator.

والبرنامجان يعملان على نفس الجهاز ويتكلمان معاً، كما يقول [توثيق بنية العقدة](https://ethereum.org/en/developers/docs/nodes-and-clients/node-architecture/?ref=arabroot.io)، إذ يقود عميل الإجماع عميل التنفيذ عبر اتصال محلي بواجهة اسمها Engine API: يخبره بالكتلة الجديدة التي اقترحتها الشبكة ليتحقق منها وينفذها، وأي الكتل أصبحت نهائية. ولفهم تقسيم العمل بينهما، تخيل أن معاملة جديدة وصلت: عميل التنفيذ هو الذي يعرف ما تعنيه، فيشغلها في آلة EVM ويحسب الحالة الجديدة، لأنه وحده يحمل الحالة والكود. أما ترتيب الكتل وأيها تأتي أولاً وأيها أصبحت نهائية لا تلغى، فهذا قرار الإجماع الذي يحسبه عميل الإجماع من تصويت المدققين. فالأول يجيب عن «ماذا يحدث داخل الكتلة؟» والثاني عن «أي الكتل هي السلسلة الصحيحة؟»، ولا يستطيع أحدهما أن يعمل دون الآخر: عميل التنفيذ بلا إجماع لا يعرف أي كتلة يبني عليها، وعميل الإجماع بلا تنفيذ لا يعرف ما بداخل الكتل. والصورة التالية تبين البرنامجين وما بينهما:

![مخطط من جزأين: على اليمين عميل التنفيذ Execution Client مثل Geth وReth وNethermind وBesu، يشغل آلة EVM ويحفظ الحالة وقاعدة البيانات وطابور Mempool، ويقدم المنفذ العام 8545 بواجهة JSON-RPC للمحافظ بلا مصادقة مع أمثلة eth_blockNumber وeth_call، وعلى اليسار عميل الإجماع Consensus Client مثل Lighthouse وPrysm وTeku وNimbus يشغل منطق إثبات الحصة ويقود عميل التنفيذ بعلمي execution-endpoint وexecution-jwt، وبينهما صندوق أسود Engine API على المنفذ 8551، وصندوق أصفر للسر المشترك JWT في ملف jwt.hex، وملاحظة أنه قبل The Merge كان برنامج واحد يكفي](https://arabroot.io/content/images/2026/10/ethereum-node-01-two-clients.webp)

العقدة الكاملة برنامجان: التنفيذ والإجماع، يربطهما Engine API محمي بسر مشترك

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

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

## تجربة: نشغل عميل تنفيذ حقيقي

سوف نشغل Geth، وهو أقدم عملاء التنفيذ وأشهرها، في وضع التطوير Dev Mode الذي يشرحه [توثيقه](https://geth.ethereum.org/docs/getting-started/dev-mode?ref=arabroot.io): ينشئ سلسلة محلية خاصة، ويحفظ حساباً ممولاً، وينتج الكتل على فترة نحددها، دون أن يتصل بأي شبكة ولا يزامن أي شيء. وقبل تشغيله نولد سر JWT الذي سوف نشرحه بعد قليل، وننشئ مجلد بيانات:

```bash
mkdir -p lab/data
openssl rand -hex 32 > lab/data/jwt.hex
```

ثم نشغل Geth، وننشر منه منفذ JSON-RPC فقط على العنوان المحلي:

```bash
docker run -d --name lab-geth -p 127.0.0.1:8545:8545 -v "$PWD/lab/data:/data" \
  ethereum/client-go:v1.17.10 \
  --dev --dev.period 12 --datadir /data/geth \
  --http --http.addr 0.0.0.0 --http.api eth,net,web3,txpool
```

في الإعداد أعلاه لاحظ التالي:

- `--dev` يشغل وضع التطوير، و`--dev.period 12` يجعله ينتج كتلة كل اثنتي عشرة ثانية مثل إيقاع الشبكة الحقيقية، بدل أن ينتجها فور وصول معاملة.
- `--http` يفتح واجهة JSON-RPC، و`--http.api` يحدد مجموعات الدوال المتاحة عليها، وقد سمحنا بـ `eth` و`net` و`web3` و`txpool`.
- المنفذ منشور على `127.0.0.1` فقط، لأن واجهة JSON-RPC بلا مصادقة، ومن يصل إليها يستطيع أن يقرأ كل شيء ويرسل المعاملات باسم الحسابات المفتوحة.

الآن نسأل العقدة عن نفسها بالسكربت `lab/01-query.sh`، وكل استعلام طلب JSON-RPC بسيط عبر `curl`:

```bash
R=http://127.0.0.1:8545
rpc() { curl -s -X POST -H 'Content-Type: application/json' \
  --data "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"$1\",\"params\":$2}" $R; echo; }
echo "== client version"; rpc web3_clientVersion '[]'
echo "== chain id, block number, syncing, peers"
rpc eth_chainId '[]'
rpc eth_blockNumber '[]'
rpc eth_syncing '[]'
rpc net_peerCount '[]'
```

والمخرج سوف يكون كما يلي:

```text
== client version
{"jsonrpc":"2.0","id":1,"result":"Geth/v1.17.10-stable-1df30b18/linux-amd64/go1.27.3"}
== chain id, block number, syncing, peers
{"jsonrpc":"2.0","id":1,"result":"0x539"}
{"jsonrpc":"2.0","id":1,"result":"0x1"}
{"jsonrpc":"2.0","id":1,"result":false}
{"jsonrpc":"2.0","id":1,"result":"0x0"}
```

في المخرج أعلاه لاحظ التالي:

- `web3_clientVersion` يقول إن العقدة Geth الإصدار 1.17.10، وهذا أول ما تسأل عنه أي عقدة لتعرف أي برنامج تتكلم معه.
- رقم الشبكة `0x539`، أي 1337، وهو رقم شبكة التطوير في Geth، يختلف عن رقم Anvil الذي كان 31337، ويختلف عن الشبكة الرئيسية التي رقمها 1.
- `eth_syncing` يعيد `false`، أي أن العقدة ليست في مرحلة مزامنة، وهذا متوقع لأنها شبكة محلية تبدأ من كتلة تكوينها الخاصة. وعلى الشبكة الرئيسية يعيد هذا الاستعلام كائناً فيه رقم الكتلة الحالية والهدف ما دامت العقدة تزامن، وهو أول ما تفحصه لتعرف هل عقدتك جاهزة.
- `net_peerCount` صفر، لأن عقدة التطوير معزولة لا تتصل بأحد، أما العقدة الحقيقية فتتصل بعشرات العقد عبر شبكة نظير لنظير P2P لتتبادل معها الكتل والمعاملات.

### نرسل معاملة ونراها تدخل كتلة

عقدة التطوير تحفظ حساباً ممولاً، فنرسل منه معاملة حقيقية، ونراها تمر بالطابور ثم تدخل كتلة. والسكربت `lab/05-tx.sh`:

```bash
R=http://127.0.0.1:8545
rpc() { curl -s -X POST -H 'Content-Type: application/json' \
  --data "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"$1\",\"params\":$2}" $R; echo; }
DEV=$(rpc eth_accounts '[]' | python -c 'import sys,json;print(json.load(sys.stdin)["result"][0])')
echo "dev account: $DEV"
rpc eth_sendTransaction "[{\"from\":\"$DEV\",\"to\":\"0x000000000000000000000000000000000c0ffEE0\",\"value\":\"0xde0b6b3a7640000\"}]"
curl -s -X POST -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"txpool_status","params":[]}' $R; echo
sleep 13
rpc eth_blockNumber '[]'
rpc eth_getBlockByNumber '["latest", false]' \
  | python -c 'import sys,json;b=json.load(sys.stdin)["result"];print("block",int(b["number"],16),"txs",len(b["transactions"]),"gasUsed",int(b["gasUsed"],16))'
rpc eth_getBalance '["0x000000000000000000000000000000000c0ffEE0","latest"]'
```

والمخرج سوف يكون كما يلي:

```text
dev account: 0x71562b71999873db5b286df957af199ec94617f7
{"jsonrpc":"2.0","id":1,"result":"0x4246ff70d942f323433f64681523692f512d6280fff4d6354a9be8c8ba443264"}
{"jsonrpc":"2.0","id":1,"result":{"pending":"0x1","queued":"0x0"}}
{"jsonrpc":"2.0","id":1,"result":"0x9"}
block 9 txs 1 gasUsed 21000
{"jsonrpc":"2.0","id":1,"result":"0xde0b6b3a7640000"}
```

في المخرج أعلاه لاحظ التالي:

- العقدة قبلت المعاملة وأعادت هاشها، ثم أظهر `txpool_status` معاملة واحدة معلقة `pending`، وهي في طابور Mempool الذي يحفظه عميل التنفيذ ذاته، وقد شرحنا دور الطابور في مقال كيف يعمل Ethereum.
- بعد اثنتي عشرة ثانية دخلت المعاملة الكتلة رقم 9، وفيها معاملة واحدة استهلكت 21000 وحدة غاز، وهي الكلفة الثابتة للتحويل البسيط، ووصل إلى العنوان المستقبل 1 ETH بالضبط، أي `0xde0b6b3a7640000` بوحدة Wei.
- كل هذا جرى على عقدة تشغلها أنت، فأنت من حفظ المعاملة ونفذها وتحقق من نتيجتها، لا خدمة خارجية أخبرتك بها. وهذا هو الفرق الذي بدأنا به المقال.

وقد يتساءل البعض: كيف أرسلت العقدة معاملة دون أن أوقعها بمفتاح خاص كما كنا نفعل في المقالات السابقة؟ والإجابة أن وضع التطوير في Geth يفتح الحساب الممول في العقدة نفسها، فيوقع بالنيابة عنك عندما تستدعي `eth_sendTransaction`. وهذا مريح للتجارب، ولكنه بالضبط ما يجب ألا يحدث على عقدة حقيقية: لو كان حساب مفتوح في عقدة ومنفذها متاح، لاستطاع أي من يصل إلى المنفذ أن يرسل معاملات باسم ذلك الحساب ويفرغه. ولهذا على الشبكة الحقيقية لا تفتح الحسابات في العقدة، وإنما توقع المعاملات في المحفظة على جهازك ثم ترسل المعاملة الموقعة جاهزة بالدالة `eth_sendRawTransaction`، كما شرحنا التوقيع في مقال كيف يعمل Ethereum. فالعقدة تنقل المعاملة وتنفذها، ولكنها لا تملك مفتاحك.

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

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

![مخطط من جزأين: على اليمين ما شغلناه فعلاً، عميل تنفيذ Geth حقيقي في وضع التطوير بمخرجات web3_clientVersion يعيد Geth 1.17.10 وeth_chainId يعيد 0x539 وeth_syncing يعيد false وnet_peerCount صفر ومجلد بيانات 2 ميجابايت ومعاملة دخلت الكتلة 9 بغاز 21000 ووصل المستقبل 1 ETH، وعلى اليسار ما تضيفه العقدة على الشبكة الرئيسية، عميل إجماع حقيقي مربوط بـ Engine API وJWT مع مخرج lighthouse v8.3.2 وعلمي execution-endpoint وexecution-jwt واتصال P2P وقرص بمئات الجيجابايتات، وفي الأسفل سبب عدم مزامنة الشبكة الرئيسية](https://arabroot.io/content/images/2026/10/ethereum-node-04-lab.webp)

عميل التنفيذ شغلناه حقيقياً، والعقدة الكاملة تضيف عميل إجماع واتصالاً بالشبكة وقرصاً كبيراً

### نقرأ رأس كتلة كاملاً من العقدة

قبل أن ننتقل، نقرأ رأس كتلة كاملاً لنرى أن ما تعلمناه في مقال كيف يعمل Ethereum موجود هنا بنفسه. نسأل عن آخر كتلة بالدالة `eth_getBlockByNumber`:

```bash
curl -s -X POST -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["latest", false]}' \
  http://127.0.0.1:8545 | python -m json.tool | grep -E '"(number|hash|parentHash|stateRoot|gasLimit|gasUsed|baseFeePerGas|timestamp)"'
```

والمخرج سوف يكون كما يلي:

```text
"number": "0x3",
"parentHash": "0x16ffb8cb8098925ccfebf40593af261a991d746257542976f84230e7da2c9fa3",
"stateRoot": "0x7aecf80234ae10f74243ff41fb5d4639db774dc8b180719bd72abd8b6827c763",
"hash": "0x5d2e8147e089227a4458fdd6ebfcce5cdf7df9ae302824d3733455d20f5225ca",
"gasLimit": "0xaffd98",
"gasUsed": "0x0",
"baseFeePerGas": "0x27ee3253",
"timestamp": "0x6ae159a0"
```

هذه هي نفس الحقول التي شرحناها في مقال كيف يعمل Ethereum: رقم الكتلة، وهاش الكتلة السابقة `parentHash` الذي يربطها بما قبلها، وجذر الحالة `stateRoot` الذي يلخص كل الحسابات، وحد الغاز والمستهلك، والرسوم الأساسية. والفرق أن هذه القيم جاءت من عقدة تشغلها أنت وتثق بها لأنك ترى كودها وبياناتها، لا من رقم أرسله لك طرف آخر. وهذا هو جوهر «لا تثق، تحقق»: ليس أن تحفظ البيانات، بل أن تكون قادراً على التحقق منها بنفسك متى شئت. فالعقدة التي تشغلها لا تخزن الأرقام لتعرضها فقط، وإنما تعيد حساب كل كتلة بقواعد الشبكة قبل أن تقبلها، فإذا أرسل لها جار كتلة مخالفة للقواعد رفضتها، ولو اتفق عليها غيرها. وهذا ما لا يستطيع المزود أن يعطيك إياه: المزود يحسب لنفسه، ويرسل لك النتيجة، وأنت تصدقها.

## واجهتان: JSON-RPC العامة وEngine API المحمية

لاحظت في التجربة أننا نتكلم مع العقدة على المنفذ 8545 دون أي كلمة سر، فأي من يصل إلى هذا المنفذ يقرأ الحالة ويرسل المعاملات. وهذه هي الواجهة العامة JSON-RPC، وهي مصممة للمحافظ والتطبيقات، ولذلك لا نفتحها على الإنترنت أبداً، وإنما على العنوان المحلي أو خلف طبقة حماية، لأن فتحها للعالم يعني أن يستنزف أحد مواردك باستعلامات ثقيلة، أو يحاول أن يرسل معاملات إن كانت هناك حسابات مفتوحة.

ولكن هناك واجهة ثانية لا تظهر في تجربتنا لأن وضع التطوير لا يحتاجها: واجهة المحرك Engine API على المنفذ 8551\. وهذه هي القناة التي يقود بها عميل الإجماع عميل التنفيذ، ولأن من يتحكم بها يتحكم بالعقدة كلها، فهي محمية بسر مشترك JWT: ملف فيه سلسلة عشوائية، هو نفسه الذي ولدناه بالأمر `openssl rand`، يحمله البرنامجان، فلا يقبل عميل التنفيذ أمراً على المنفذ 8551 إلا إذا جاء موقعاً بهذا السر. ولذلك عندما يشغل أحد عقدة كاملة يولد هذا الملف مرة، ويشير إليه كلا البرنامجين. ولم نستطع أن نجرب هذه الواجهة على عقدة التطوير لأنها تولد كتلها بنفسها دون عميل إجماع، ولكن تستطيع أن ترى أين يحتاجها عميل الإجماع في مخرج برنامجه، كما سوف نرى.

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

## أنواع العقد: الكاملة والأرشيفية والخفيفة

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

- **العقدة الكاملة Full Node**: تتحقق من كل كتلة وكل معاملة بنفسها، ولكنها تحفظ الحالة الحالية فقط، وتقلم Prune البيانات القديمة وتعيد توليدها عند الحاجة، فحجمها مئات الجيجابايتات. وهي ما يحتاجه أغلب الناس ليتحققوا بأنفسهم، وهي التي تجيبك عن رصيدك الآن، ولكنها لا تعرف رصيداً عند كتلة قديمة.
- **العقدة الأرشيفية Archive Node**: عقدة كاملة تتحقق من كتلة التكوين ولا تحذف شيئاً، فتحفظ كل الحالات التاريخية، وحجمها تيرابايتات. ويذكر التوثيق أن عميل Erigon يستطيع أن ينجز مزامنة أرشيفية كاملة في قرابة 2 تيرابايت وأقل من ثلاثة أيام. وهي ما يحتاجه مستكشفو الكتل وأدوات التحليل التي تسأل عن رصيد عنوان عند كتلة ماضية، لا الأفراد.
- **العقدة الخفيفة Light Node**: تحمل رؤوس الكتل Headers فقط، وتتحقق من البيانات مقابل جذور الحالة فيها، وتطلب أي شيء آخر من العقد الكاملة، فحجمها صغير جداً. وهي بالضبط فكرة الإثبات `eth_getProof` التي شرحناها في مقال كيف يعمل Ethereum. ولكنها لا تستطيع أن تكون مدققاً، وما زال دعمها محدوداً في إثبات الحصة.

والصورة التالية تجمع الأنواع الثلاثة:

![مخطط بثلاثة أعمدة: العقدة الكاملة Full Node تتحقق من كل كتلة وتحفظ الحالة الحالية وتقلم القديمة بحجم مئات الجيجابايتات على قرص SSD بسعة 2 تيرابايت موصى بها و4 إلى 8 جيجابايت ذاكرة، والعقدة الأرشيفية Archive Node تحفظ كل الحالات التاريخية بحجم تيرابايتات ويصل Erigon أرشيفاً في 2 تيرابايت وأقل من ثلاثة أيام وتجيب عن رصيد أي عنوان عند أي كتلة، والعقدة الخفيفة Light Node تحمل رؤوس الكتل فقط بحجم صغير جداً وتناسب الأجهزة المحدودة ولا تستطيع أن تكون مدققاً، وفي الأسفل أن المفاضلة واحدة: كلما حفظت تاريخاً أكثر زاد القرص وزاد ما تجيب عنه بنفسك](https://arabroot.io/content/images/2026/10/ethereum-node-02-node-types.webp)

كلما حفظت العقدة تاريخاً أكثر، زاد قرصها وزاد ما تستطيع أن تجيب عنه دون أن تسأل غيرها

وأي نوع يحتاجه فريق المنصة؟ أغلب التطبيقات تحتاج عقدة كاملة، لأنها تريد أن تعرف الحالة الحالية وتتحقق منها بنفسها، وتقرأ الأحداث الأخيرة. والعقدة الأرشيفية لا تحتاجها إلا إذا كنت تبني أداة تحليل تسأل عن الماضي البعيد، وهي مكلفة. والعقدة الخفيفة مناسبة للأجهزة المحدودة ولكنها ليست بديلاً كاملاً اليوم. ومتطلبات الجهاز للعقدة الكاملة، كما تذكر [صفحة تشغيل العقدة](https://ethereum.org/en/run-a-node/?ref=arabroot.io)، قرص SSD بسعة 2 تيرابايت ضروري لسرعة الكتابة، وذاكرة من 4 إلى 8 جيجابايت لغير المدققين، وأكثر لمن يشغل مدققاً.

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

ولاحظ كلمة التقليم Pruning في وصف العقدة الكاملة، فهي مفتاح لفهم الفرق عن الأرشيفية. العقدة الكاملة تتحقق من كل كتلة في تاريخ الشبكة عندما تزامن، أي أنها رأت كل شيء وتأكدت منه، ولكنها لا تحفظ كل الحالات الوسيطة، وإنما تحتفظ بالحالة الحالية وتقلم القديمة، فإذا احتاجت حالة قديمة أعادت توليدها بتنفيذ المعاملات من نقطة قريبة. فالعقدة الكاملة إذن تحققت من الماضي كله ولكنها لا تتذكر تفاصيله، أما الأرشيفية فتتذكر كل لحظة من تاريخ الشبكة جاهزة، ولهذا تكلف تيرابايتات. والفرق المهم للفريق: إذا سأل نظامك «كم كان رصيد هذا العقد قبل شهر عند تلك الكتلة؟» فلن تجيبك عقدة كاملة، وتحتاج أرشيفية أو مزوداً يشغل واحدة، وهذا سؤال شائع في أدوات المحاسبة والتدقيق.

## كيف تبدأ العقدة من الصفر؟

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

- **المزامنة السريعة Snap Sync**: الافتراضية على الشبكة الرئيسية، تبدأ من نقطة حديثة موثوقة وتحمل الحالة الحالية مباشرة بدل أن تنفذ كل المعاملات، فتوفر القرص والوقت.
- **المزامنة الكاملة Full Sync**: تحمل كل الكتل وتعيد تنفيذها من كتلة التكوين، ويذكر التوثيق أنها قد تستغرق أياماً إلى أسابيع، وهي أقصى درجات التحقق لأنها لا تثق بأي نقطة بداية.

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

![مخطط من جزأين: على اليمين عميل التنفيذ والمزامنة السريعة Snap Sync الافتراضية على الشبكة الرئيسية التي تبدأ من نقطة حديثة وتحمل الحالة مباشرة، مقابل المزامنة الكاملة Full Sync التي تحمل كل الكتل وتعيد تنفيذها من التكوين وقد تستغرق أياماً إلى أسابيع، وعلى اليسار عميل الإجماع والمزامنة من نقطة تفتيش Checkpoint Sync بالعلم checkpoint-sync-url الذي يبدأ من نقطة نهائية حديثة وتنتهي المزامنة في دقائق مع التنبيه أن الطرف موثوق، وفي الأسفل القاعدة: تبدأ من نقطة حديثة تثق بها مرة ثم تتحقق بنفسك فتعود إلى لا تثق تحقق، وأننا في التجربة لم نزامن الشبكة الرئيسية](https://arabroot.io/content/images/2026/10/ethereum-node-03-sync.webp)

كل طرق المزامنة تبدأ من نقطة موثوقة لتوفر الوقت، ثم تتحقق بنفسها من كل كتلة بعدها

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

وقد يقلق البعض من فكرة البدء من نقطة تفتيش يعطيها طرف موثوق: أليست هذه ثغرة في فكرة «لا تثق، تحقق»؟ والإجابة دقيقة: نقطة التفتيش ليست رقماً تصدقه وتمضي، وإنما حالة كاملة للشبكة في لحظة قريبة، تستطيع أن تتحقق منها من عدة مصادر مستقلة فإذا اتفقت كلها اطمأننت إليها، ثم تبني عليها وتتحقق بنفسك من كل كتلة بعدها. والافتراض الذي تقوم عليه، ويسميه التوثيق الذاتية الضعيفة Weak Subjectivity، هو أن الكتل النهائية في إثبات الحصة لا يمكن إلغاؤها إلا بحرق ثلث المال المحجوز كما شرحنا في مقال الإجماع، فنقطة تفتيش من ماض قريب نهائي آمنة عملياً. فالثقة هنا محدودة في نقطة بداية يمكن التحقق منها، لا ثقة دائمة في طرف يرسل لك الأرقام، وهذا فرق جوهري عن الثقة بمزود يعطيك الحالة الحالية كل ثانية.

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

## عميل الإجماع: البرنامج الثاني

لم نشغل عميل إجماع كاملاً لأنه يحتاج مزامنة مع الشبكة الحقيقية، ولكن نستطيع أن نرى برنامجه ونعرف كيف يرتبط بعميل التنفيذ. نشغل Lighthouse لنرى إصداره والأعلام التي تربطه، في السكربت `lab/04-cl.sh`:

```bash
docker run --rm sigp/lighthouse:v8.3.2 lighthouse --version | head -2
docker run --rm sigp/lighthouse:v8.3.2 lighthouse bn --help 2>&1 \
  | grep -A2 -E '^\s+--execution-endpoint|^\s+--execution-jwt |^\s+--checkpoint-sync-url'
```

والمخرج سوف يكون كما يلي، وقد اختصرناه:

```text
Lighthouse v8.3.2
BLS library: blst-portable

  --checkpoint-sync-url <BEACON_NODE>
  Set the remote beacon node HTTP endpoint to use for checkpoint sync.
  --execution-endpoint <EXECUTION-ENDPOINT>
  Server endpoint for an execution layer JWT-authenticated HTTP JSON-RPC
  connection. Uses the same endpoint to populate the deposit cache.
  --execution-jwt <EXECUTION-JWT>
  File path which contains the hex-encoded JWT secret for the execution
  endpoint provided in the --execution-endpoint flag.
```

في المخرج أعلاه لاحظ التالي:

- Lighthouse برنامج مستقل تماماً عن Geth، بإصداره الخاص، ويشغله الأمر `lighthouse bn` أي Beacon Node.
- العلم `--execution-endpoint` هو عنوان عميل التنفيذ على المنفذ المحمي 8551، ووصفه يقول صراحة إنه اتصال JSON-RPC مصادق بـ JWT، وهذا هو Engine API الذي شرحناه.
- العلم `--execution-jwt` هو مسار ملف السر، نفس الملف `jwt.hex` الذي ولدناه، فالبرنامجان يشيران إلى نفس الملف.
- العلم `--checkpoint-sync-url` هو نقطة التفتيش التي يبدأ منها، وهي التي تنهي المزامنة في دقائق بدل أيام.

فلو أردنا عقدة كاملة على الشبكة الرئيسية لشغلنا Geth بنفس الطريقة ولكن بلا `--dev` ومع فتح المنفذ 8551 والإشارة إلى ملف JWT، ثم شغلنا Lighthouse بالأعلام الثلاثة أعلاه، فيبدأ كل منهما بالمزامنة، ويقود Lighthouse عميل التنفيذ عبر Engine API. وكل القواعد والواجهات التي تعلمناها على الشبكة المحلية تعمل هناك بنفسها، فما اختبرته على `cast` و`eth_call` لا يتغير، وإنما يتغير المصدر والحجم والاتصال.

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

## تشغيل العقدة ليس حدثاً واحداً

قبل أن نقرر عقدة أم مزود، يجب أن يعرف الفريق أن تشغيل عقدة ليس أمراً تكتبه مرة وتنساه، وإنما خدمة تراقبها وتصونها مثل أي سيرفر إنتاج، كما شرحنا في مقالات الاستضافة والمراقبة. فالعقدة تحتاج أن تبقى مزامنة، أي أن `eth_syncing` يبقى `false` وأن رقم الكتلة عندها يقارب رقم الكتلة في الشبكة، وأن تبقى متصلة بعدد كاف من العقد، أي أن `net_peerCount` لا ينخفض إلى الصفر، وأن قرصها لا يمتلئ، لأن الحالة تنمو مع الوقت. وإذا تعطلت العقدة أو تأخرت مزامنتها، فإن نظام المنصة الذي يقرأ منها سوف يرى بيانات قديمة دون أن يعرف أنها قديمة، وهذا أخطر من أن تتوقف تماماً، لأن الخطأ الصامت لا يلاحظ.

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

## عقدتك أم مزود خارجي؟

نصل الآن إلى سؤال فريق المنصة الأصلي. أغلب التطبيقات تبدأ بقراءة الحالة من مزود خارجي، مثل Infura أو Alchemy، وهي خدمات تشغل العقد نيابة عنك وتعطيك واجهة JSON-RPC جاهزة، فتوفر عليك الجهاز والمزامنة والصيانة. وهذا خيار معقول لكثير من الحالات، ولكن له ثمناً يجب أن تعرفه، كما تشرح صفحة تشغيل العقدة. والصورة التالية تجمع المفاضلة:

![جدول مقارنة بين عقدتك أنت ومزود مثل Infura أو Alchemy: من يتحقق من صحة البيانات، أنت بقواعد الشبكة لا تثق تحقق مقابل تثق بما يرسله المزود، ومن يرى عناوينك واستعلاماتك، لا أحد مقابل المزود يرى عنوان IP والعناوين، وهل يمكن أن تحجب معاملاتك، لا مقابل نظرياً يمكن لمزود أن يرفض، والتكلفة والجهد، جهاز وقرص 2 تيرابايت وصيانة مقابل مجاني حتى حد ثم اشتراك بلا جهاز، وأي فرع تختار الشبكة في تفرع، أنت مقابل المزود يختار عنك، والمناسب لكل منهما، وفي الأسفل القاعدة من ethereum.org لا تثق تحقق](https://arabroot.io/content/images/2026/10/ethereum-node-05-provider.webp)

عقدتك تحقق بنفسها، والمزود يطلب منك أن تثق به، وهذا هو الفرق كله

والفروق التي تذكرها صفحة تشغيل العقدة أربعة:

- **التحقق**: عقدتك تتحقق من كل كتلة ومعاملة بقواعد الشبكة بنفسها، وهذا هو شعار «لا تثق، تحقق» Don't Trust, Verify. أما المزود فأنت تثق بما يرسله، فإذا أعطاك رصيداً خاطئاً لا تملك وسيلة لتكتشفه إلا بسؤال مصدر آخر.
- **الخصوصية**: عندما تقرأ من عقدتك لا يرى أحد عناوينك ولا استعلاماتك، فكلها على جهازك. أما المزود فيرى عنوان IP والعناوين التي تسأل عنها، وهذا ما تسميه الصفحة تسريباً للخصوصية.
- **مقاومة الحجب**: عقدتك ترسل معاملاتك إلى الشبكة مباشرة، أما المزود فيستطيع نظرياً أن يرفض معاملة من عنوان معين، كما تذكر الصفحة.
- **السيادة والاختيار**: عقدتك تفرض القواعد التي تختارها، فإذا حدث تفرع في الشبكة اخترت أنت أي فرع تتبع، أما مع المزود فهو يختار عنك.

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

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

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

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

## أخطاء شائعة وكيف تلاحظها

- **فتح JSON-RPC على الإنترنت**: تلاحظه عندما يكون المنفذ 8545 مفتوحاً على عنوان عام، والخطر استنزاف الموارد أو إرسال معاملات إن وجدت حسابات مفتوحة، والحل العنوان المحلي أو طبقة حماية.
- **الاعتماد على مصدر واحد في قرار مالي**: تلاحظه عندما يبني النظام قراراً على رقم من مزود واحد دون تأكيد، والحل تأكيد القراءات الحساسة من أكثر من مصدر أو من عقدتك.
- **اعتبار العقدة جاهزة قبل انتهاء المزامنة**: تلاحظه عندما يعيد `eth_syncing` كائناً وليس `false`، فالعقدة ما زالت تلحق بالحاضر وأرقامها ناقصة.
- **اختيار النوع الخطأ**: تلاحظه عندما تطلب رصيداً عند كتلة قديمة من عقدة كاملة فتفشل، لأن ذلك يحتاج عقدة أرشيفية، أو عندما تشغل أرشيفية بلا داع فتدفع تيرابايتات بلا سبب.
- **سر JWT خطأ أو مشترك خطأ**: تلاحظه عندما لا يتصل عميل الإجماع بعميل التنفيذ، والسبب أن الملفين مختلفان، والحل أن يشير البرنامجان إلى نفس الملف.
- **قرص غير مناسب**: تلاحظه في بطء شديد أو فشل مزامنة على قرص بطيء، والحل قرص SSD بسرعة كتابة كافية كما توصي الصفحة.

## قائمة تحقق قبل تشغيل عقدة أو اختيار مزود

| القرار       | السؤال                                | الخيار                                                      |
| ------------ | ------------------------------------- | ----------------------------------------------------------- |
| عقدة أم مزود | كم تحتاج التحقق بنفسك والخصوصية؟      | مزود للبداية والحمل الخفيف، عقدتك للسيادة والقراءات الحساسة |
| نوع العقدة   | هل تحتاج الماضي البعيد أم الحاضر فقط؟ | كاملة لأغلب الحالات، أرشيفية للتحليل التاريخي فقط           |
| العميلان     | هل تريد عقدة تؤمن الشبكة؟             | عميل تنفيذ وعميل إجماع، ومدقق فقط إن حجزت 32 ETH            |
| تنوع العملاء | هل تتبع العميل الأكثر انتشاراً؟       | اختر من عملاء الأقلية أحياناً لصحة الشبكة                   |
| المزامنة     | كم تثق في نقطة البداية؟               | سريعة ومن نقطة تفتيش للسرعة، كاملة لأقصى تحقق               |
| الأمان       | أين المنفذان 8545 و8551؟              | 8545 محلي أو محمي، 8551 بسر JWT مشترك واحد                  |
| العتاد       | هل القرص SSD بسعة وسرعة كافية؟        | 2 تيرابايت SSD وذاكرة كافية بحسب الدور                      |

## تدريب عملي

1. أرسل إلى عقدة التطوير معاملتين من الحساب الممول، ثم اقرأ الكتلة بالدالة `eth_getBlockByNumber` مع المعامل `true` ليعرض المعاملات كاملة، واقرأ إيصال كل معاملة بالدالة `eth_getTransactionReceipt`، وقارن بما رأيناه بالأمر `cast` في المقالات السابقة.
2. اقرأ قائمة أعلام Geth بالأمر `docker run --rm ethereum/client-go:v1.17.10 --help`، وابحث عن الأعلام الخاصة بالمزامنة `--syncmode` وبالأرشيف `--gcmode`، وافهم ما يفعله كل منها من وصفه.

## حذف التجربة

```bash
docker rm -f lab-geth
docker image rm ethereum/client-go:v1.17.10 sigp/lighthouse:v8.3.2
rm -rf lab/data
```

## الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

- العقدة الكاملة بعد The Merge برنامجان: عميل تنفيذ يشغل آلة EVM ويحفظ الحالة، وعميل إجماع يشغل إثبات الحصة، يربطهما Engine API محمي بسر JWT مشترك.
- شغلنا عميل تنفيذ حقيقي محلياً، وسألناه عن نفسه، وأرسلنا معاملة رأيناها تمر بالطابور ثم تدخل الكتلة 9 بغاز 21000، وتحققنا بأنفسنا لا بخدمة خارجية.
- الواجهة العامة JSON-RPC على 8545 بلا مصادقة فلا تفتح على الإنترنت، وواجهة المحرك على 8551 محمية بـ JWT لأن من يتحكم بها يتحكم بالعقدة.
- أنواع العقد ثلاثة: كاملة بمئات الجيجابايتات لأغلب الناس، وأرشيفية بتيرابايتات للتحليل التاريخي، وخفيفة صغيرة محدودة الدعم.
- كل طرق المزامنة تبدأ من نقطة حديثة موثوقة لتوفر الوقت، ثم تتحقق بنفسها، فتعود إلى «لا تثق، تحقق».
- عقدتك تتحقق بنفسها وتحفظ خصوصيتك وتفرض اختيارك، والمزود أسرع وأرخص ولكنك تثق به، والقرار نقطة على طريق بين السهولة والسيادة.

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

[![](https://arabroot.io/content/images/2026/10/ethereum-how-it-works-cover-cover.webp)دليلكيف يعمل Ethereum؟ الحسابات والغاز وآلة EVMماذا يحدث داخل Ethereum عندما ترسل معاملة، ولماذا تدفع الرسوم حتى لو فشلت، ولماذا تختلف تكلفة نفس الدالة من مرة لأخرى.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D9%8A%D8%B9%D9%85%D9%84-ethereum-%D8%A7%D9%84%D8%AD%D8%B3%D8%A7%D8%A8%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%BA%D8%A7%D8%B2-%D9%88%D8%A7%D9%84%D8%A9-evm/)[![](https://arabroot.io/content/images/2026/10/consensus-cover-cover.webp)دليلكيف تتفق شبكة البلوكتشين؟ إثبات العمل وإثبات الحصةكيف تتفق آلاف العقد التي لا يثق بعضها ببعض على سجل واحد، ولماذا يكلف الغش كهرباء في شبكة ومالاً محجوزاً في أخرى.](https://arabroot.io/articles/%D8%A7%D9%84%D8%A7%D8%AC%D9%85%D8%A7%D8%B9-%D9%81%D9%8A-%D8%A7%D9%84%D8%A8%D9%84%D9%88%D9%83%D8%AA%D8%B4%D9%8A%D9%86-%D8%A7%D8%AB%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%B9%D9%85%D9%84-%D9%88%D8%A7%D8%AB%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%AD%D8%B5%D8%A9/)[![](https://arabroot.io/content/images/2026/10/crypto-exchanges-cover-cover.webp)دليلكيف تعمل منصات تداول العملات الرقمية؟ دفتر الأوامر والمطابقةنشغل محرك مطابقة بسيطاً لنرى لماذا لا يوجد سعر واحد، وكيف يرفع الأمر الكبير السعر، وماذا يحدث داخل المنصة فعلاً.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%B9%D9%85%D9%84-%D9%85%D9%86%D8%B5%D8%A7%D8%AA-%D8%AA%D8%AF%D8%A7%D9%88%D9%84-%D8%A7%D9%84%D8%B9%D9%85%D9%84%D8%A7%D8%AA-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A%D8%A9-%D8%AF%D9%81%D8%AA%D8%B1-%D8%A7%D9%84%D8%A7%D9%88%D8%A7%D9%85%D8%B1-%D9%88%D8%A7%D9%84%D9%85%D8%B7%D8%A7%D8%A8%D9%82%D8%A9/)[![](https://arabroot.io/content/images/2026/10/smart-contracts-cover-cover.webp)دليلما هي العقود الذكية Smart Contracts وما مخاطرها؟نكتب عقد ضمان لمنصة عمل حر ونجربه على شبكة محلية، لنرى أين يفي العقد الذكي بوعده وأين ينقل الثقة إلى مفتاح أو أوراكل.](https://arabroot.io/articles/%D8%A7%D9%84%D8%B9%D9%82%D9%88%D8%AF-%D8%A7%D9%84%D8%B0%D9%83%D9%8A%D8%A9-smart-contracts-%D9%85%D8%A7-%D9%87%D9%8A-%D9%88%D9%85%D8%A7-%D9%85%D8%AE%D8%A7%D8%B7%D8%B1%D9%87%D8%A7/)[![](https://arabroot.io/content/images/2026/10/bitcoin-node-cover-cover.webp)دليلتشغيل عقدة Bitcoin كاملة على سيرفرك مع Bitcoin Coreلماذا تشغل عقدة Bitcoin كاملة، وكيف تثبتها بـ Docker Compose وتؤمن واجهة RPC، وماذا يحدث في المزامنة الأولى والتقليم.](https://arabroot.io/articles/%D8%AA%D8%B4%D8%BA%D9%8A%D9%84-%D8%B9%D9%82%D8%AF%D8%A9-bitcoin-%D9%83%D8%A7%D9%85%D9%84%D8%A9-%D8%B9%D9%84%D9%89-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D9%83-%D9%85%D8%B9-bitcoin-core/)[![](https://arabroot.io/content/images/2026/10/blockchain-basics-cover-cover.webp)دليلكيف يعمل البلوكتشين Blockchain ومتى لا تحتاجهما المشكلة التي يحلها البلوكتشين أصلاً وكيف يعمل من الداخل، ومتى تكون قاعدة البيانات العادية هي الحل الأصح.](https://arabroot.io/articles/%D8%A7%D9%84%D8%A8%D9%84%D9%88%D9%83%D8%AA%D8%B4%D9%8A%D9%86-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-%D9%83%D9%8A%D9%81-%D9%8A%D8%B9%D9%85%D9%84-%D9%88%D9%85%D8%AA%D9%89-%D9%84%D8%A7-%D8%AA%D8%AD%D8%AA%D8%A7%D8%AC%D9%87/)

## سجل التحديثات

- أكتوبر 2026: كتابة المقال، وتشغيل عميل التنفيذ Geth v1.17.10 في وضع التطوير على Docker Engine 29.8.0، وعرض عميل الإجماع Lighthouse v8.3.2 وأعلامه، على شبكة تطوير محلية دون مزامنة الشبكة الرئيسية.