Tokyo Hardfork (Japan Open Chain v2)

ستُجري Japan Open Chain ترقيةً للشبكة تُسمّى Tokyo Hardfork. وبموجب هذا الانقسام الصلب (Hardfork)، ستنتقل آلية الإجماع من Clique PoA إلى PoSA (Proof of Staked Authority / PoA v2).

الجدول الزمني

الشبكة	التاريخ	الحالة
Testnet	7 سبتمبر 2026	مكتمل
Mainnet (إطلاق سلسلة المنارة)	18 سبتمبر 2026	مكتمل
Mainnet (Phase 1 / The Merge)	لم يُحدَّد بعد (سيُقرَّر في اجتماع الـ Validator)	قيد التحضير

إلى مشغّلي العُقد

إذا كنتم تشغّلون عقدةً على Testnet، فيُرجى إكمال تغيير الإعدادات قبل 7 سبتمبر 2026. لا تكفي ترقية Geth وحدها. للاطلاع على التفاصيل، يُرجى الرجوع إلى الخطوات أدناه.

حول سلسلة المنارة على Mainnet

تتم ترقية Mainnet على مرحلتين.

1. إطلاق سلسلة المنارة (18 سبتمبر 2026 — مكتمل)
   بدأت Consensus Layer (طبقة الإجماع) العمل قبل Execution Layer (طبقة التنفيذ). ولا تزال الكتل تُنتَج بواسطة Clique PoA، لذا لا يوجد في الوقت الحالي أي تأثير على المستخدمين العامّين أو مشغّلي العُقد.
2. Phase 1 — الانقسام الصلب (The Merge) (لم يُحدَّد بعد)
   ستبدأ Execution Layer العمل وفقًا لتعليمات سلسلة المنارة. وسيتعيّن على المؤسسات التي تشغّل عقدها الخاصة تغيير إعداداتها في هذه المرحلة. وسيُعلَن عن التاريخ في هذه الصفحة فور تحديده في اجتماع الـ Validator.

تُنشَر ملفات إعدادات Mainnet (config.yaml وgenesis.ssz ومعلومات Deposit Contract وقوائم bootnode / boot ENR) ضمن الدليل metadata/ في مستودع japan-open-chain/mainnet. وللاطلاع على الخطوات التفصيلية لإعداد العقدة، يُرجى الرجوع إلى دليل الاتصال بعقدة Mainnet.

الإجراءات المطلوبة في هذه المرحلة

الفئة	الإجراء المطلوب
حاملو JOC والمستخدمون العامّون ومستخدمو JOC RPC Endpoint	لا يلزم أي إجراء
المؤسسات التي تشغّل عقدها الخاصة على Mainnet	يمكنكم الإبقاء على إعدادكم الحالي المقتصر على Execution Client (Geth)، لكننا نوصي بإعداد Consensus Client (الموصى به: Lighthouse) من الآن استعدادًا للانقسام الصلب التالي (The Merge)، وذلك باتباع دليل الاتصال بعقدة Mainnet

إلى مشغّلي العُقد على Mainnet

قبل الانقسام الصلب، لا يمكن لإصدار Geth v1.14.0 أو أحدث مزامنة السلسلة. يُرجى الاستمرار في استخدام سلسلة الإصدارات v1.13.

الإجراءات المطلوبة

الفئة	الإجراء المطلوب
حاملو JOC والمستخدمون العامّون	لا يلزم أي إجراء
مستخدمو JOC RPC Endpoint	لا يلزم أي إجراء
مطوّرو dApp	لن يتغيّر Chain ID. يلزم اتخاذ إجراء فقط إذا كنتم تشغّلون عقدتكم الخاصة
المؤسسات التي تشغّل عقدها الخاصة	يلزم اتخاذ إجراء عند الانقسام الصلب. يُرجى اتباع الخطوات أدناه لتغيير إعدادات العقدة
Validator	يلزم اتخاذ إجراء. ستُقدَّم تعليمات منفصلة

---

خطوات مشغّلي العُقد على Testnet

الفئة المعنيّة: المؤسسات التي تقوم بالمزامنة مباشرةً من عُقد الإقلاع (boot nodes) الخاصة بـ JOC Testnet وتشغّل عقدها الخاصة. إذا كنتم تستخدمون JOC RPC Endpoint، فلا يلزم أي إجراء.

لا تكفي ترقية Geth وحدها

في ظل PoA، كان Execution Client (Geth) يتحقّق من الكتل ويزامنها بمفرده. أما بعد الانتقال إلى PoSA، فإن صلاحية الكتل تحدّدها Consensus Layer (سلسلة المنارة). ويتولّى Geth التنفيذ فقط، ويتلقّى تعليمات fork choice من Consensus Client.

لذلك، فإن العمل المطلوب هو تغيير في الإعدادات، وليس ترقيةً للإصدار.

[Current]                    [After the Tokyo Hardfork]

 Geth (standalone)            Geth ── Engine API ── Lighthouse
   │                            │                      │
 P2P to                     execution only     consensus / fork choice
 boot nodes                                              │
                                                  to CL boot nodes

1. ما يجب إكماله قبل الانقسام الصلب

Step 1 — الحصول على ملفات الإعدادات

الملف	الغرض	ملاحظات
genesis.json (النسخة المحدَّثة)	خاص بـ Execution Client. يتضمّن TTD وتوقيت كل انقسام (fork)	يختلف عن النسخة المنشورة حاليًا
config.yaml	مواصفات السلسلة الخاصة بـ Consensus Client	يحدّد fork epoch وnetwork ID
deposit_contract_block.txt	رقم كتلة Deposit Contract
genesis.ssz	حالة genesis لسلسلة المنارة	حوالي 5.5 MB

تُوزَّع هذه الملفات في الدليل metadata/ ضمن مستودع Testnet.

• japan-open-chain/testnet

Step 2 — الإبقاء على Geth ضمن سلسلة الإصدارات v1.13

يُرجى الاستمرار في استخدام Geth v1.13.5، وهو الإصدار الذي تم التحقّق منه على هذا الموقع. لا يمكن حاليًا لإصدار Geth v1.14.0 أو أحدث مزامنة السلسلة.

ملاحظة

ستكون هناك حاجة إلى إصدار أحدث من Geth في مراحل Shapella وDencun وPectra. وسنُعلن عن الإصدار المدعوم في هذه الصفحة فور تأكيد الجدول الزمني.

Step 3 — إعداد Consensus Client

• الموصى به: Lighthouse v7.0.1 (صورة Docker sigp/lighthouse:v7.0.1)
• تم اختبار Lighthouse ويعمل بشكل مستقر؛ ولم يتم التحقق من العملاء الآخرين
• يمكن تشغيله على الخادم نفسه الذي يعمل عليه Geth الحالي
• يجب إعداد عُقد الإقلاع (ENR) الخاصة بـ Consensus Layer (سيُعلَن عنها فور تأكيدها)
• نوصي باستخدام checkpoint sync للمزامنة الأولية (سيُعلَن عن نقطة النهاية فور تأكيدها)

Step 4 — ربط Geth بـ Consensus Client عبر Engine API

يتواصل الطرفان عبر Engine API المُصادَق عليه (المنفذ الافتراضي 8551). يُرجى إنشاء JWT secret مشترك وتهيئته على كلا الطرفين.

# Example: generating the JWT secret
openssl rand -hex 32 | tr -d "\n" > /data/jwt.hex

خيارات بدء التشغيل التي يجب إضافتها على جانب Geth:

--authrpc.addr=127.0.0.1
--authrpc.port=8551
--authrpc.jwtsecret=/data/jwt.hex
--authrpc.vhosts=localhost

Step 5 — التحقّق من المزامنة والاتصال

• أن يكون Consensus Client قد لحق بسلسلة المنارة
• أن يسجّل سجلّ Geth تحديثات fork choice عبر Engine API
• يُرجى إبقاء كلا العميلين قيد التشغيل في يوم الانقسام الصلب. سيتم تفعيل The Merge تلقائيًا عند بلوغ قيمة TTD المُهيَّأة

2. العمل المطلوب في كل مرحلة بعد الانقسام الصلب

في مراحل Shapella وDencun وPectra، سيتعيّن عليكم تحديث إعداداتكم وإعادة التشغيل بعد صدور إعلاننا.

المرحلة	Execution Client	Consensus Client
Phase 2 — Shapella	ضبط shanghaiTime	CAPELLA_FORK_VERSION / CAPELLA_FORK_EPOCH
Phase 3 — Dencun	ضبط cancunTime	DENEB_FORK_VERSION / DENEB_FORK_EPOCH
Phase 4 — Pectra	ضبط pragueTime	ELECTRA_FORK_VERSION / ELECTRA_FORK_EPOCH

warning

يُرجى عدم تحديث الإعدادات أو إعادة التشغيل بناءً على تقديركم الخاص قبل صدور إعلاننا.

3. في حال عدم اتخاذ الإجراء

• بعد الانقسام الصلب، لن تتلقّى العقدة كتلًا جديدة ولن تتمكّن من مواكبة رأس السلسلة
• لن تتمكّن التطبيقات والمحافظ المتصلة بتلك العقدة عبر RPC من استرداد أحدث الكتل أو المعاملات
• قد تستمر العقدة التي تخلّفت على السلسلة القديمة في إرجاع بيانات من السلسلة المتوقّفة
• يُرجى ملاحظة أن العُقد العادية لا تخضع أبدًا لـ Slashing (يقتصر Slashing على الـ Validator فقط)

4. الأسئلة الشائعة

س. هل أحتاج إلى التسجيل بصفة Validator أو إيداع 32 JOC؟

لا. العُقد العادية التي لا تُنتج كتلًا لا تحتاج إلى التسجيل في Launchpad ولا إلى تقديم deposit data. كل ما يلزم هو تغيير الإعدادات الموضّح أعلاه.

س. هل أحتاج إلى حذف بيانات السلسلة الحالية وإعادة المزامنة؟

لا. يتم الاحتفاظ بجميع بيانات السلسلة الحالية وسجلّ المعاملات.

س. هل سيتغيّر Chain ID؟

لا.

س. هل أحتاج إلى خادم إضافي؟

يمكن تشغيل Consensus Client على خادمكم الحالي، شريطة توفّر مساحة كافية في القرص والذاكرة.

التواصل

للاستفسارات المتعلّقة بهذا الانقسام الصلب، يُرجى التواصل معنا عبر نموذج الاتصال.