Tokyo Hardfork (Japan Open Chain v2)

Japan Open Chain Tokyo Hardfork नामक एक नेटवर्क अपग्रेड करने जा रहा है। इस हार्डफ़ोर्क के माध्यम से, सहमति तंत्र (consensus mechanism) 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 सूचियाँ) japan-open-chain/mainnet रिपॉज़िटरी की metadata/ डायरेक्टरी में प्रकाशित हैं। नोड सेटअप के विस्तृत चरणों के लिए, कृपया Mainnet नोड कनेक्शन गाइड देखें।

इस चरण में आवश्यक कार्रवाई

आप कौन हैं	आवश्यक कार्रवाई
JOC धारक, सामान्य उपयोगकर्ता, और JOC RPC Endpoint के उपयोगकर्ता	किसी कार्रवाई की आवश्यकता नहीं है
Mainnet पर अपना स्वयं का नोड संचालित करने वाले संगठन	अपना वर्तमान केवल Execution Client (Geth) वाला सेटअप बनाए रखना ठीक है, परंतु अगले हार्डफ़ोर्क (The Merge) की तैयारी के लिए हम अनुशंसा करते हैं कि आप Mainnet नोड कनेक्शन गाइड का पालन करते हुए अभी से एक Consensus Client (अनुशंसित: Lighthouse) सेट अप कर लें

Mainnet नोड संचालकों के लिए

हार्डफ़ोर्क से पहले, Geth v1.14.0 या उसके बाद के संस्करण चेन को सिंक नहीं कर सकते। कृपया v1.13 श्रृंखला का उपयोग जारी रखें।

आपको क्या करना होगा

आप कौन हैं	आवश्यक कार्रवाई
JOC धारक और सामान्य उपयोगकर्ता	किसी कार्रवाई की आवश्यकता नहीं है
JOC RPC Endpoint के उपयोगकर्ता	किसी कार्रवाई की आवश्यकता नहीं है
dApp डेवलपर	Chain ID नहीं बदलेगा। केवल तभी कार्रवाई आवश्यक है जब आप अपना स्वयं का नोड संचालित करते हैं
अपना स्वयं का नोड संचालित करने वाले संगठन	हार्डफ़ोर्क के समय कार्रवाई आवश्यक है। अपने नोड का कॉन्फ़िगरेशन बदलने के लिए कृपया नीचे दिए गए चरणों का पालन करें
Validator	कार्रवाई आवश्यक है। अलग से निर्देश प्रदान किए जाएंगे

---

Testnet नोड संचालकों के लिए चरण

यह किन पर लागू होता है: वे संगठन जो JOC Testnet के बूट नोड्स से सीधे सिंक करते हैं और अपना स्वयं का नोड संचालित करते हैं। यदि आप JOC RPC Endpoint का उपयोग करते हैं, तो किसी कार्रवाई की आवश्यकता नहीं है।

केवल Geth को अपग्रेड करना पर्याप्त नहीं है

PoA के अंतर्गत, Execution Client (Geth) स्वयं ही ब्लॉकों का सत्यापन और सिंक करता था। PoSA में स्थानांतरण के बाद, ब्लॉक की वैधता Consensus Layer (बीकन चेन) द्वारा निर्धारित की जाएगी। Geth केवल निष्पादन का कार्य करेगा, और Consensus Client से fork choice निर्देश प्राप्त करेगा।

इसलिए आवश्यक कार्य संस्करण अपग्रेड नहीं, बल्कि कॉन्फ़िगरेशन परिवर्तन है।

[वर्तमान]                    [Tokyo Hardfork के बाद]

 Geth (स्वतंत्र)              Geth ── Engine API ── Lighthouse
   │                            │                      │
 P2P द्वारा                  केवल निष्पादन      सहमति / fork choice
 बूट नोड्स से                                            │
                                                  CL बूट नोड्स से

1. हार्डफ़ोर्क से पहले पूरा करें

Step 1 — कॉन्फ़िगरेशन फ़ाइलें प्राप्त करें

फ़ाइल	उद्देश्य	टिप्पणी
genesis.json (अपडेटेड)	Execution Client के लिए। इसमें TTD और प्रत्येक फ़ोर्क का समय शामिल है	वर्तमान में प्रकाशित संस्करण से भिन्न
config.yaml	Consensus Client के लिए चेन विनिर्देश	fork epoch और network ID को परिभाषित करता है
deposit_contract_block.txt	Deposit Contract का ब्लॉक नंबर
genesis.ssz	बीकन चेन की genesis state	लगभग 5.5 MB

ये फ़ाइलें Testnet रिपॉज़िटरी की metadata/ डायरेक्टरी में वितरित की जाती हैं।

• japan-open-chain/testnet

Step 2 — Geth को v1.13 श्रृंखला पर ही रखें

कृपया Geth v1.13.5 का उपयोग जारी रखें, जो इस साइट पर सत्यापित संस्करण है। Geth v1.14.0 और उसके बाद के संस्करण वर्तमान में चेन को सिंक नहीं कर सकते।

नोट

Shapella, Dencun और Pectra चरणों के लिए Geth के नए संस्करण की आवश्यकता होगी। समय-सारणी की पुष्टि होते ही हम इस पृष्ठ पर समर्थित संस्करण की घोषणा करेंगे।

Step 3 — Consensus Client सेट अप करें

• अनुशंसित: Lighthouse v7.0.1 (Docker इमेज sigp/lighthouse:v7.0.1)
• Lighthouse का परीक्षण किया गया है और यह स्थिर रूप से चलता है; अन्य क्लाइंट सत्यापित नहीं किए गए हैं
• इसे आपके मौजूदा Geth वाले होस्ट पर ही चलाया जा सकता है
• Consensus Layer के लिए बूट नोड्स (ENR) कॉन्फ़िगर करना आवश्यक है (पुष्टि होते ही घोषणा की जाएगी)
• प्रारंभिक सिंक के लिए हम checkpoint sync की अनुशंसा करते हैं (endpoint की घोषणा पुष्टि होते ही की जाएगी)

Step 4 — Engine API के माध्यम से Geth और Consensus Client को जोड़ें

दोनों प्रमाणीकृत 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 के लॉग में Engine API के माध्यम से fork choice अपडेट दर्ज हो रहे हैं
• हार्डफ़ोर्क के दिन दोनों क्लाइंट चालू रखें। कॉन्फ़िगर किए गए TTD तक पहुँचने पर The Merge स्वचालित रूप से सक्रिय हो जाएगा

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. यदि आप कार्रवाई नहीं करते हैं

• हार्डफ़ोर्क के बाद, नोड को नए ब्लॉक प्राप्त नहीं होंगे और वह चेन के शीर्ष (head) का अनुसरण नहीं कर पाएगा
• RPC के माध्यम से उस नोड से जुड़े एप्लिकेशन और वॉलेट नवीनतम ब्लॉक या ट्रांज़ैक्शन प्राप्त नहीं कर पाएंगे
• पुरानी चेन पर छूट गया नोड बंद की गई चेन का डेटा लौटाता रह सकता है
• ध्यान दें कि सामान्य नोड्स पर कभी Slashing नहीं होती (Slashing केवल Validator पर लागू होती है)

4. अक्सर पूछे जाने वाले प्रश्न

प्र. क्या मुझे Validator के रूप में पंजीकरण करना होगा या 32 JOC जमा करने होंगे?

नहीं। ब्लॉक उत्पन्न न करने वाले सामान्य नोड्स के लिए न तो Launchpad पर पंजीकरण आवश्यक है और न ही deposit data। केवल ऊपर बताया गया कॉन्फ़िगरेशन परिवर्तन आवश्यक है।

प्र. क्या मुझे अपना मौजूदा चेन डेटा हटाकर पुनः सिंक करना होगा?

नहीं। सभी मौजूदा चेन डेटा और ट्रांज़ैक्शन इतिहास सुरक्षित रहते हैं।

प्र. क्या Chain ID बदलेगा?

नहीं।

प्र. क्या मुझे अतिरिक्त सर्वर की आवश्यकता होगी?

Consensus Client को आपके मौजूदा होस्ट पर चलाया जा सकता है, बशर्ते उसमें पर्याप्त डिस्क और मेमोरी की गुंजाइश हो।

संपर्क

इस हार्डफ़ोर्क से संबंधित प्रश्नों के लिए, कृपया संपर्क फ़ॉर्म के माध्यम से हमसे संपर्क करें।