Tokyo Hardfork (Japan Open Chain v2)
Japan Open Chain, Tokyo Hardfork adlı bir ağ yükseltmesi gerçekleştirecektir. Bu hardfork ile konsensüs mekanizması Clique PoA'dan PoSA'ya (Proof of Staked Authority / PoA v2) geçecektir.
Takvim
| Ağ | Tarih | Durum |
|---|---|---|
| Testnet | 7 Eylül 2026 | Tamamlandı |
| Mainnet (beacon chain'in başlatılması) | 18 Eylül 2026 | Tamamlandı |
| Mainnet (Phase 1 / The Merge) | Henüz belirlenmedi (Validator toplantısında kararlaştırılacaktır) | Hazırlanıyor |
Testnet üzerinde bir düğüm işletiyorsanız, lütfen yapılandırma değişikliğini 7 Eylül 2026'dan önce tamamlayın. Yalnızca Geth'i yükseltmek yeterli değildir. Ayrıntılar için lütfen aşağıdaki adımlara bakın.
Mainnet beacon chain hakkında
Mainnet yükseltmesi iki aşamada gerçekleştirilecektir.
- Beacon chain'in başlatılması (18 Eylül 2026 — tamamlandı)
Consensus Layer (konsensüs katmanı), Execution Layer'dan (yürütme katmanı) önce çalışmaya başlamıştır. Bloklar hâlâ Clique PoA tarafından üretildiğinden, şu an için genel kullanıcılar veya düğüm operatörleri üzerinde herhangi bir etkisi yoktur. - Phase 1 — Hardfork (The Merge) (henüz belirlenmedi)
Execution Layer, beacon chain'den gelen talimatlara göre çalışmaya başlayacaktır. Kendi düğümünü işleten kuruluşların bu noktada yapılandırmalarını değiştirmeleri gerekecektir. Tarih, Validator toplantısında kararlaştırılır kararlaştırılmaz bu sayfada duyurulacaktır.
Mainnet yapılandırma dosyaları (config.yaml, genesis.ssz, Deposit Contract bilgileri ve bootnode / boot ENR listeleri), japan-open-chain/mainnet deposunun metadata/ dizininde yayımlanmaktadır. Ayrıntılı düğüm kurulum adımları için lütfen Mainnet düğüm bağlantı kılavuzuna bakın.
Bu aşamada yapmanız gerekenler
| Kimsiniz | Gerekli işlem |
|---|---|
| JOC sahipleri, genel kullanıcılar ve JOC RPC Endpoint kullanıcıları | Herhangi bir işlem gerekmez |
| Mainnet üzerinde kendi düğümünü işleten kuruluşlar | Mevcut, yalnızca Execution Client (Geth) içeren kurulumunuzu korumanızda sakınca yoktur; ancak bir sonraki hardfork'a (The Merge) hazırlık olarak, Mainnet düğüm bağlantı kılavuzunu izleyerek şimdiden bir Consensus Client (önerilen: Lighthouse) kurmanızı öneririz |
Hardfork'tan önce Geth v1.14.0 ve sonraki sürümler zinciri senkronize edemez. Lütfen v1.13 serisini kullanmaya devam edin.
Yapmanız gerekenler
| Kimsiniz | Gerekli işlem |
|---|---|
| JOC sahipleri ve genel kullanıcılar | Herhangi bir işlem gerekmez |
| JOC RPC Endpoint kullanıcıları | Herhangi bir işlem gerekmez |
| dApp geliştiricileri | Chain ID değişmez. Yalnızca kendi düğümünüzü işletiyorsanız işlem yapmanız gerekir |
| Kendi düğümünü işleten kuruluşlar | Hardfork sırasında işlem gereklidir. Düğüm yapılandırmanızı değiştirmek için lütfen aşağıdaki adımları izleyin |
| Validator'lar | İşlem gereklidir. Ayrıca talimat verilecektir |
Testnet düğüm operatörleri için adımlar
Kimleri kapsar: Doğrudan JOC Testnet boot node'larından senkronize olan ve kendi düğümünü işleten kuruluşlar. JOC RPC Endpoint'lerini kullanıyorsanız herhangi bir işlem gerekmez.
Yalnızca Geth'i yükseltmek yeterli değildir
PoA altında Execution Client (Geth), blokları kendi başına doğruluyor ve senkronize ediyordu. PoSA'ya geçişten sonra blok geçerliliği Consensus Layer (beacon chain) tarafından belirlenecektir. Geth yalnızca yürütmeden sorumlu olacak ve fork choice talimatlarını Consensus Client'tan alacaktır.
Bu nedenle gereken iş bir sürüm yükseltmesi değil, bir yapılandırma değişikliğidir.
[Mevcut] [Tokyo Hardfork sonrası]
Geth (tek başına) Geth ── Engine API ── Lighthouse
│ │ │
P2P ile yalnızca yürütme konsensüs / fork choice
boot node'lara │
CL boot node'larına
1. Hardfork'tan önce tamamlanması gerekenler
Step 1 — Yapılandırma dosyalarını edinin
| Dosya | Amaç | Notlar |
|---|---|---|
genesis.json (güncellenmiş) | Execution Client için. TTD'yi ve her fork'un zamanını içerir | Şu anda yayımlanan sürümden farklıdır |
config.yaml | Consensus Client için zincir spesifikasyonu | Fork epoch'larını ve network ID'yi tanımlar |
deposit_contract_block.txt | Deposit Contract'ın blok numarası | |
genesis.ssz | Beacon chain genesis state | Yaklaşık 5.5 MB |
Bu dosyalar Testnet deposunun metadata/ dizininde dağıtılmaktadır.
Step 2 — Geth'i v1.13 serisinde tutun
Lütfen bu sitede doğrulanmış sürüm olan Geth v1.13.5'i kullanmaya devam edin. Geth v1.14.0 ve sonraki sürümler şu anda zinciri senkronize edememektedir.
Shapella, Dencun ve Pectra aşamaları için Geth'in daha yeni bir sürümü gerekecektir. Takvim kesinleştiğinde desteklenen sürümü bu sayfada duyuracağız.
Step 3 — Bir Consensus Client kurun
- Önerilen: Lighthouse v7.0.1 (Docker imajı
sigp/lighthouse:v7.0.1) - Lighthouse test edilmiş ve kararlı şekilde çalışmaktadır; diğer istemciler doğrulanmamıştır
- Mevcut Geth'inizle aynı sunucuda çalıştırılabilir
- Consensus Layer için boot node'ların (ENR) yapılandırılması gerekir (kesinleştiğinde duyurulacaktır)
- İlk senkronizasyon için checkpoint sync kullanmanızı öneririz (endpoint kesinleştiğinde duyurulacaktır)
Step 4 — Geth ile Consensus Client'ı Engine API üzerinden bağlayın
İkisi, kimlik doğrulamalı Engine API (varsayılan port 8551) üzerinden iletişim kurar. Ortak bir JWT secret oluşturun ve her iki tarafta da yapılandırın.
# Example: generating the JWT secret
openssl rand -hex 32 | tr -d "\n" > /data/jwt.hex
Geth tarafına eklenmesi gereken başlatma seçenekleri:
--authrpc.addr=127.0.0.1
--authrpc.port=8551
--authrpc.jwtsecret=/data/jwt.hex
--authrpc.vhosts=localhost
Step 5 — Senkronizasyonu ve bağlantıyı doğrulayın
- Consensus Client'ın beacon chain'e yetişmiş olması
- Geth günlüğünde Engine API üzerinden yapılan fork choice güncellemelerinin kaydedilmesi
- Hardfork günü her iki istemciyi de çalışır durumda tutun. Yapılandırılan TTD'ye ulaşıldığında The Merge otomatik olarak tetiklenir
2. Hardfork sonrasında her aşamada yapılması gerekenler
Shapella, Dencun ve Pectra aşamalarında, duyurumuzun ardından yapılandırmanızı güncellemeniz ve yeniden başlatmanız gerekecektir.
| Aşama | Execution Client | Consensus Client |
|---|---|---|
| Phase 2 — Shapella | shanghaiTime ayarlayın | CAPELLA_FORK_VERSION / CAPELLA_FORK_EPOCH |
| Phase 3 — Dencun | cancunTime ayarlayın | DENEB_FORK_VERSION / DENEB_FORK_EPOCH |
| Phase 4 — Pectra | pragueTime ayarlayın | ELECTRA_FORK_VERSION / ELECTRA_FORK_EPOCH |
Duyurumuzdan önce kendi takdirinize göre yapılandırmanızı güncellemeyin veya yeniden başlatmayın.
3. İşlem yapmazsanız
- Hardfork'tan sonra düğüm yeni bloklar alamayacak ve zincirin ucunu (head) takip edemeyecektir
- Bu düğüme RPC üzerinden bağlı uygulamalar ve cüzdanlar en son blokları veya işlemleri alamayacaktır
- Eski zincirde geride kalan bir düğüm, kullanımdan kaldırılmış zincirin verilerini döndürmeye devam edebilir
- Sıradan düğümlerin hiçbir zaman Slashing'e maruz kalmadığını unutmayın (Slashing yalnızca Validator'lar için geçerlidir)
4. Sıkça sorulan sorular
S. Validator olarak kaydolmam veya 32 JOC yatırmam gerekiyor mu?
Hayır. Blok üretmeyen sıradan düğümler için ne Launchpad kaydı ne de deposit data gerekir. Yalnızca yukarıda açıklanan yapılandırma değişikliği gereklidir.
S. Mevcut zincir verilerimi silip yeniden senkronize etmem gerekiyor mu?
Hayır. Mevcut tüm zincir verileri ve işlem geçmişi korunur.
S. Chain ID değişiyor mu?
Hayır.
S. Ek bir sunucuya ihtiyacım var mı?
Consensus Client, yeterli disk ve bellek kapasitesine sahip olması koşuluyla mevcut sunucunuzda çalıştırılabilir.
İletişim
Bu hardfork ile ilgili sorularınız için lütfen iletişim formu aracılığıyla bize ulaşın.