Tokyo Hardfork (Japan Open Chain v2)

Japan Open Chain จะดำเนินการอัปเกรดเครือข่ายที่เรียกว่า Tokyo Hardfork ฮาร์ดฟอร์กครั้งนี้จะเปลี่ยนกลไกฉันทามติจาก Clique PoA เดิมไปเป็น PoSA (Proof of Staked Authority / PoA v2)

กำหนดการ

เครือข่าย	วันที่ดำเนินการ	สถานะ
Testnet	7 กันยายน 2026	เสร็จสิ้นแล้ว
Mainnet (เริ่มเดินระบบ beacon chain)	18 กันยายน 2026	เสร็จสิ้นแล้ว
Mainnet (Phase 1 / The Merge)	ยังไม่กำหนด (จะตัดสินในการประชุม Validator)	อยู่ระหว่างการเตรียมการ

สำหรับผู้ดูแลโหนด

หากท่านดูแลโหนดบน Testnet กรุณาดำเนินการเปลี่ยนแปลงการตั้งค่าโหนดให้เสร็จสิ้น ก่อนวันที่ 7 กันยายน 2026 การอัปเกรดเวอร์ชันของ Geth เพียงอย่างเดียวไม่เพียงพอ กรุณาดูรายละเอียดได้ที่ขั้นตอนด้านล่าง

เกี่ยวกับ beacon chain ของ Mainnet

การอัปเกรด Mainnet จะดำเนินการเป็นสองขั้นตอนดังนี้

1. การเริ่มเดินระบบ beacon chain (18 กันยายน 2026 — เสร็จสิ้นแล้ว)
   Consensus Layer ได้เริ่มทำงานล่วงหน้าแยกจาก Execution Layer แล้ว การสร้างบล็อกยังคงดำเนินการโดย Clique PoA ต่อไป ดังนั้น ณ ขณะนี้จึงไม่มีผลกระทบต่อผู้ใช้ทั่วไปหรือผู้ดูแลโหนด
2. Phase 1 — ฮาร์ดฟอร์ก (The Merge) (ยังไม่กำหนด)
   Execution Layer จะเริ่มทำงานตามคำสั่งจาก beacon chain องค์กรที่ดูแลโหนดของตนเองจะต้องเปลี่ยนแปลงการตั้งค่าในช่วงเวลานี้ วันที่ดำเนินการจะประกาศในหน้านี้ทันทีที่มีการตัดสินในการประชุม Validator

ไฟล์การตั้งค่าสำหรับ Mainnet (config.yaml, genesis.ssz, ข้อมูล deposit contract และรายการ bootnode / boot ENR) เผยแพร่อยู่ในไดเรกทอรี metadata/ ของ repository japan-open-chain/mainnet สำหรับขั้นตอนการสร้างโหนดโดยละเอียด กรุณาอ้างอิงคู่มือการเชื่อมต่อโหนด Mainnet

สิ่งที่ต้องดำเนินการในขั้นตอนนี้

กลุ่มเป้าหมาย	การดำเนินการที่จำเป็น
ผู้ถือ JOC ผู้ใช้ทั่วไป และผู้ใช้ RPC Endpoint ของ JOC	ไม่จำเป็นต้องดำเนินการใด ๆ
องค์กรที่ดูแลโหนดของตนเองบน Mainnet	สามารถคงการตั้งค่าปัจจุบันที่มีเพียง Execution Client (Geth) ไว้ได้ แต่เราขอแนะนำให้สร้าง Consensus Client (แนะนำ: Lighthouse) ไว้ตั้งแต่ตอนนี้ตามขั้นตอนในคู่มือการเชื่อมต่อโหนด Mainnet เพื่อเตรียมพร้อมสำหรับฮาร์ดฟอร์กครั้งถัดไป (The Merge)

สำหรับผู้ดูแลโหนดบน Mainnet

ก่อนการดำเนินการฮาร์ดฟอร์ก Geth v1.14.0 ขึ้นไปจะไม่สามารถซิงค์กับเชนได้ กรุณาใช้เวอร์ชันตระกูล v1.13 ต่อไป

การดำเนินการตามกลุ่มเป้าหมาย

กลุ่มเป้าหมาย	การดำเนินการที่จำเป็น
ผู้ถือ JOC และผู้ใช้ทั่วไป	ไม่จำเป็นต้องดำเนินการใด ๆ
ผู้ใช้ RPC Endpoint ของ JOC	ไม่จำเป็นต้องดำเนินการใด ๆ
นักพัฒนา dApp	Chain ID จะไม่เปลี่ยนแปลง จำเป็นต้องดำเนินการเฉพาะกรณีที่ดูแลโหนดของตนเองเท่านั้น
องค์กรที่ดูแลโหนดของตนเอง	จำเป็นต้องดำเนินการ (ในช่วงฮาร์ดฟอร์ก) กรุณาเปลี่ยนแปลงการตั้งค่าโหนดตามขั้นตอนด้านล่าง
Validator	จำเป็นต้องดำเนินการ กรุณาปฏิบัติตามขั้นตอนที่จะแจ้งให้ทราบแยกต่างหาก

---

ขั้นตอนสำหรับผู้ดูแลโหนดบน Testnet

กลุ่มเป้าหมาย: องค์กรที่ซิงค์โดยตรงจาก boot node ของ JOC Testnet และดูแลโหนดของตนเอง หากท่านใช้งานผ่าน RPC Endpoint ของ JOC ไม่จำเป็นต้องดำเนินการใด ๆ

การอัปเกรดเวอร์ชันของ Geth เพียงอย่างเดียวไม่เพียงพอ

ภายใต้ PoA นั้น Execution Client (Geth) จะตรวจสอบและซิงค์บล็อกด้วยตัวเองเพียงลำพัง หลังจากเปลี่ยนไปใช้ PoSA ความถูกต้องของบล็อกจะถูกกำหนดโดย Consensus Layer (beacon chain) Geth จะรับผิดชอบเฉพาะการประมวลผล (execution) และทำงานตามคำสั่ง fork choice ที่ได้รับจาก Consensus Client

ดังนั้น งานที่จำเป็นต้องทำคือการเปลี่ยนแปลงการตั้งค่า ไม่ใช่การอัปเกรดเวอร์ชัน

[ปัจจุบัน]                     [หลัง Tokyo Hardfork]

 Geth (เดี่ยว)                 Geth ── Engine API ── Lighthouse
   │                            │                      │
 P2P ไปยัง                   ประมวลผลเท่านั้น     ฉันทามติ / fork choice
 boot node                                               │
                                                  ไปยัง boot node ของ 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 ของ beacon chain	ประมาณ 5.5 MB

ไฟล์ข้างต้นแจกจ่ายอยู่ในไดเรกทอรี metadata/ ของ repository สำหรับ Testnet

• 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 image sigp/lighthouse:v7.0.1)
• Lighthouse ผ่านการทดสอบและทำงานได้อย่างเสถียร ส่วนไคลเอนต์อื่นยังไม่ได้รับการตรวจสอบ
• สามารถรันบนโฮสต์เดียวกับ Geth ที่มีอยู่ได้
• จำเป็นต้องตั้งค่า boot node (ENR) สำหรับ Consensus Layer (จะแจ้งให้ทราบทันทีที่ได้รับการยืนยัน)
• เราแนะนำให้ใช้ checkpoint sync สำหรับการซิงค์ครั้งแรก (endpoint จะแจ้งให้ทราบทันทีที่ได้รับการยืนยัน)

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 ซิงค์ทัน beacon chain แล้ว
• log ของ 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. กรณีที่ไม่ได้ดำเนินการ

• หลังฮาร์ดฟอร์ก โหนดดังกล่าวจะไม่สามารถรับบล็อกใหม่ได้ และจะไม่สามารถติดตามส่วนปลาย (head) ของเชนได้
• แอปพลิเคชันและวอลเล็ตที่เชื่อมต่อ RPC กับโหนดนั้นจะไม่สามารถดึงข้อมูลบล็อกหรือธุรกรรมล่าสุดได้
• โหนดที่ค้างอยู่บนเชนเก่าอาจส่งคืนข้อมูลของเชนที่ถูกยกเลิกไปแล้วต่อไป
• ทั้งนี้ โหนดทั่วไปจะไม่ถูก slash (เฉพาะ Validator เท่านั้นที่อยู่ภายใต้ Slashing)

4. คำถามที่พบบ่อย

Q. จำเป็นต้องลงทะเบียนเป็น Validator หรือฝาก 32 JOC หรือไม่

ไม่จำเป็น โหนดทั่วไปที่ไม่ได้สร้างบล็อกไม่จำเป็นต้องลงทะเบียนบน Launchpad หรือส่ง deposit data สิ่งที่จำเป็นมีเพียงการเปลี่ยนแปลงการตั้งค่าตามที่ระบุไว้ข้างต้นเท่านั้น

Q. จำเป็นต้องลบข้อมูลเชนที่มีอยู่และซิงค์ใหม่หรือไม่

ไม่จำเป็น ข้อมูลเชนและประวัติธุรกรรมที่มีอยู่ทั้งหมดจะยังคงอยู่

Q. Chain ID จะเปลี่ยนแปลงหรือไม่

ไม่เปลี่ยนแปลง

Q. จำเป็นต้องเพิ่มเซิร์ฟเวอร์หรือไม่

Consensus Client สามารถรันบนโฮสต์ที่มีอยู่ได้ โดยมีเงื่อนไขว่าต้องมีพื้นที่ดิสก์และหน่วยความจำเพียงพอ

ติดต่อสอบถาม

หากมีข้อสงสัยเกี่ยวกับฮาร์ดฟอร์กครั้งนี้ กรุณาติดต่อเราผ่านแบบฟอร์มติดต่อ