Tokyo Hardfork (Japan Open Chain v2)
Japan Open Chain akan melaksanakan peningkatan jaringan yang disebut Tokyo Hardfork. Melalui hardfork ini, mekanisme konsensus akan bermigrasi dari Clique PoA ke PoSA (Proof of Staked Authority / PoA v2).
Jadwal
| Jaringan | Tanggal Pelaksanaan | Status |
|---|---|---|
| Testnet | 7 September 2026 | Selesai |
| Mainnet (peluncuran beacon chain) | 18 September 2026 | Selesai |
| Mainnet (Phase 1 / The Merge) | Belum ditentukan (diputuskan dalam rapat Validator) | Dalam persiapan |
Jika Anda mengoperasikan node di Testnet, harap selesaikan perubahan konfigurasi node sebelum 7 September 2026. Meningkatkan versi Geth saja tidak cukup. Silakan lihat langkah-langkah di bawah untuk detailnya.
Tentang beacon chain Mainnet
Peningkatan Mainnet dilaksanakan dalam dua tahap berikut.
- Peluncuran beacon chain (18 September 2026 — selesai)
Consensus Layer telah mulai beroperasi lebih dahulu, terpisah dari Execution Layer. Pembuatan blok masih dilakukan oleh Clique PoA, sehingga saat ini tidak ada dampak bagi pengguna umum maupun operator node. - Phase 1 — Hardfork (The Merge) (belum ditentukan)
Execution Layer akan mulai beroperasi berdasarkan instruksi dari beacon chain. Organisasi yang mengoperasikan node sendiri perlu mengubah konfigurasinya pada saat ini. Tanggal pelaksanaan akan diumumkan di halaman ini segera setelah diputuskan dalam rapat Validator.
File konfigurasi untuk Mainnet (config.yaml, genesis.ssz, informasi deposit contract, serta daftar bootnode / boot ENR) dipublikasikan di direktori metadata/ pada repository japan-open-chain/mainnet. Untuk langkah-langkah pembangunan node secara rinci, silakan merujuk ke Panduan koneksi node Mainnet.
Tindakan yang diperlukan pada tahap ini
| Pihak | Tindakan yang diperlukan |
|---|---|
| Pemegang JOC, pengguna umum, dan pengguna RPC Endpoint JOC | Tidak diperlukan tindakan apa pun |
| Organisasi yang mengoperasikan node sendiri di Mainnet | Konfigurasi saat ini yang hanya terdiri dari Execution Client (Geth) dapat dipertahankan, namun kami menyarankan Anda untuk menyiapkan Consensus Client (rekomendasi: Lighthouse) mulai sekarang dengan mengikuti Panduan koneksi node Mainnet, sebagai persiapan untuk hardfork berikutnya (The Merge) |
Sebelum hardfork dilaksanakan, Geth v1.14.0 atau yang lebih baru tidak dapat melakukan sinkronisasi dengan chain. Harap tetap menggunakan seri v1.13.
Tindakan berdasarkan pihak
| Pihak | Tindakan yang diperlukan |
|---|---|
| Pemegang JOC dan pengguna umum | Tidak diperlukan tindakan apa pun |
| Pengguna RPC Endpoint JOC | Tidak diperlukan tindakan apa pun |
| Pengembang dApp | Chain ID tidak berubah. Tindakan hanya diperlukan jika Anda mengoperasikan node sendiri |
| Organisasi yang mengoperasikan node sendiri | Tindakan diperlukan (pada saat hardfork). Harap ubah konfigurasi node Anda dengan mengikuti langkah-langkah di bawah |
| Validator | Tindakan diperlukan. Harap ikuti instruksi yang akan disampaikan secara terpisah |
Langkah-langkah untuk operator node Testnet
Pihak yang dituju: organisasi yang melakukan sinkronisasi langsung dari boot node JOC Testnet dan mengoperasikan node sendiri. Jika Anda menggunakan RPC Endpoint JOC, tidak diperlukan tindakan apa pun.
Meningkatkan versi Geth saja tidak cukup
Pada PoA, Execution Client (Geth) melakukan verifikasi dan sinkronisasi blok secara mandiri. Setelah migrasi ke PoSA, validitas blok ditentukan oleh Consensus Layer (beacon chain). Geth hanya menangani eksekusi, dan beroperasi berdasarkan instruksi fork choice yang diterima dari Consensus Client.
Oleh karena itu, pekerjaan yang diperlukan adalah perubahan konfigurasi, bukan peningkatan versi.
[Saat ini] [Setelah Tokyo Hardfork]
Geth (mandiri) Geth ── Engine API ── Lighthouse
│ │ │
P2P ke hanya eksekusi konsensus / fork choice
boot node │
ke boot node CL
1. Hal yang harus diselesaikan sebelum hardfork
Step 1 — Mendapatkan seluruh file konfigurasi
| File | Kegunaan | Catatan |
|---|---|---|
genesis.json (versi terbaru) | Untuk Execution Client. Berisi TTD dan waktu setiap fork | Berbeda dari versi yang saat ini dipublikasikan |
config.yaml | Spesifikasi chain untuk Consensus Client | Mendefinisikan fork epoch dan network ID |
deposit_contract_block.txt | Nomor blok Deposit Contract | |
genesis.ssz | Genesis state beacon chain | Sekitar 5.5 MB |
File-file di atas didistribusikan di direktori metadata/ pada repository untuk Testnet.
Step 2 — Tetap menggunakan Geth seri v1.13
Harap tetap menggunakan Geth v1.13.5, versi yang telah diverifikasi berfungsi di situs ini. Saat ini, Geth v1.14.0 atau yang lebih baru tidak dapat melakukan sinkronisasi dengan chain.
Pada fase Shapella, Dencun, dan Pectra, diperlukan versi Geth yang lebih baru. Kami akan mengumumkan versi yang didukung di halaman ini segera setelah jadwalnya dipastikan.
Step 3 — Menyiapkan Consensus Client baru
- Rekomendasi: Lighthouse v7.0.1 (Docker image
sigp/lighthouse:v7.0.1) - Lighthouse telah diuji dan berjalan stabil; klien lain belum diverifikasi
- Dapat dijalankan pada host yang sama dengan Geth yang sudah ada
- Boot node (ENR) untuk Consensus Layer perlu dikonfigurasi (akan diumumkan segera setelah dipastikan)
- Kami merekomendasikan penggunaan checkpoint sync untuk sinkronisasi awal (endpoint akan diumumkan segera setelah dipastikan)
Step 4 — Menghubungkan Geth dan Consensus Client melalui Engine API
Keduanya berkomunikasi melalui Engine API yang terautentikasi (port default 8551). Harap buat JWT secret bersama dan konfigurasikan di kedua sisi.
# Example: generating the JWT secret
openssl rand -hex 32 | tr -d "\n" > /data/jwt.hex
Opsi startup yang perlu ditambahkan di sisi Geth:
--authrpc.addr=127.0.0.1
--authrpc.port=8551
--authrpc.jwtsecret=/data/jwt.hex
--authrpc.vhosts=localhost
Step 5 — Memverifikasi sinkronisasi dan koneksi
- Consensus Client telah mengejar ketertinggalan dengan beacon chain
- Log Geth mencatat pembaruan fork choice melalui Engine API
- Pada hari pelaksanaan hardfork, harap biarkan kedua client tetap berjalan. The Merge akan terpicu secara otomatis saat TTD yang dikonfigurasi tercapai
2. Pekerjaan yang diperlukan pada setiap fase setelah hardfork
Pada fase Shapella, Dencun, dan Pectra, Anda perlu memperbarui konfigurasi dan melakukan restart setelah ada pengumuman dari kami.
| Fase | Execution Client | Consensus Client |
|---|---|---|
| Phase 2 — Shapella | Atur shanghaiTime | CAPELLA_FORK_VERSION / CAPELLA_FORK_EPOCH |
| Phase 3 — Dencun | Atur cancunTime | DENEB_FORK_VERSION / DENEB_FORK_EPOCH |
| Phase 4 — Pectra | Atur pragueTime | ELECTRA_FORK_VERSION / ELECTRA_FORK_EPOCH |
Harap jangan memperbarui konfigurasi atau melakukan restart atas inisiatif sendiri sebelum ada pengumuman dari kami.
3. Jika Anda tidak melakukan tindakan
- Setelah hardfork, node tersebut tidak akan dapat menerima blok baru dan tidak akan dapat mengikuti ujung (head) chain
- Aplikasi dan wallet yang terhubung melalui RPC ke node tersebut tidak akan dapat mengambil informasi blok atau transaksi terbaru
- Node yang tertinggal di chain lama dapat terus mengembalikan data dari chain yang telah dihentikan
- Perlu diketahui bahwa node biasa tidak akan pernah terkena slash (hanya Validator yang menjadi sasaran Slashing)
4. Pertanyaan yang sering diajukan
Q. Apakah saya perlu mendaftar sebagai Validator atau melakukan deposit 32 JOC?
Tidak perlu. Node biasa yang tidak memproduksi blok tidak memerlukan pendaftaran di Launchpad maupun pengajuan deposit data. Yang diperlukan hanyalah perubahan konfigurasi yang dijelaskan di atas.
Q. Apakah saya perlu menghapus data chain yang ada dan melakukan sinkronisasi ulang?
Tidak. Seluruh data chain dan riwayat transaksi yang ada akan tetap dipertahankan.
Q. Apakah Chain ID berubah?
Tidak berubah.
Q. Apakah saya perlu menambah server?
Consensus Client dapat dijalankan pada host yang sudah ada, dengan syarat tersedia ruang disk dan memori yang memadai.
Kontak
Untuk pertanyaan mengenai hardfork ini, silakan hubungi kami melalui formulir kontak.