Tokyo Hardfork (Japan Open Chain v2)
A Japan Open Chain realizará uma atualização da rede denominada Tokyo Hardfork. Com este hardfork, o mecanismo de consenso migra do Clique PoA para o PoSA (Proof of Staked Authority / PoA v2).
Cronograma
| Rede | Data | Status |
|---|---|---|
| Testnet | 7 de setembro de 2026 | Concluído |
| Mainnet (lançamento da beacon chain) | 18 de setembro de 2026 | Concluído |
| Mainnet (Phase 1 / The Merge) | A definir (será decidido na reunião de validadores) | Em preparação |
Se você opera um nó na Testnet, solicitamos que conclua a alteração de configuração antes de 7 de setembro de 2026. Apenas atualizar o Geth não é suficiente. Consulte as etapas abaixo para mais detalhes.
Sobre a beacon chain da Mainnet
A atualização da Mainnet ocorre em duas etapas.
- Lançamento da beacon chain (18 de setembro de 2026 — concluído)
A Consensus Layer começou a operar antes da Execution Layer. Os blocos continuam sendo produzidos pelo Clique PoA, portanto, no momento, não há impacto para os usuários em geral nem para os operadores de nós. - Phase 1 — Hardfork (The Merge) (a definir)
A Execution Layer passará a operar de acordo com as instruções da beacon chain. As organizações que operam seu próprio nó precisarão alterar a configuração nesse momento. A data será anunciada nesta página assim que for decidida na reunião de validadores.
Os arquivos de configuração da Mainnet (config.yaml, genesis.ssz, as informações do deposit contract e as listas de bootnodes / boot ENR) estão publicados no diretório metadata/ do repositório japan-open-chain/mainnet. Para as etapas detalhadas de configuração do nó, consulte o guia de conexão de nós à Mainnet.
O que fazer nesta etapa
| Perfil | Ação necessária |
|---|---|
| Detentores de JOC, usuários em geral e usuários dos RPC Endpoints da JOC | Nenhuma ação necessária |
| Organizações que operam seu próprio nó na Mainnet | É possível manter a configuração atual apenas com o Execution Client (Geth), mas recomendamos configurar desde já um Consensus Client (recomendado: Lighthouse), antes do próximo hardfork (The Merge), seguindo o guia de conexão de nós à Mainnet |
Antes do hardfork, o Geth v1.14.0 ou posterior não consegue sincronizar a cadeia. Solicitamos que continue utilizando a série v1.13.
O que fazer
| Perfil | Ação necessária |
|---|---|
| Detentores de JOC e usuários em geral | Nenhuma ação necessária |
| Usuários dos RPC Endpoints da JOC | Nenhuma ação necessária |
| Desenvolvedores de dApps | O Chain ID não muda. Uma ação só é necessária se você operar seu próprio nó |
| Organizações que operam seu próprio nó | Ação necessária no momento do hardfork. Siga as etapas abaixo para alterar a configuração do seu nó |
| Validadores | Ação necessária. Instruções específicas serão fornecidas separadamente |
Etapas para operadores de nós na Testnet
A quem se aplica: organizações que sincronizam diretamente a partir dos boot nodes da Testnet da JOC e operam seu próprio nó. Se você utiliza os RPC Endpoints da JOC, nenhuma ação é necessária.
Apenas atualizar o Geth não é suficiente
No PoA, o Execution Client (Geth) verificava e sincronizava os blocos por conta própria. Após a migração para o PoSA, a validade dos blocos passa a ser determinada pela Consensus Layer (a beacon chain). O Geth fica responsável apenas pela execução e recebe as instruções de fork choice do Consensus Client.
Portanto, o trabalho necessário é uma alteração de configuração, e não uma atualização de versão.
[Atual] [Após o Tokyo Hardfork]
Geth (autônomo) Geth ── Engine API ── Lighthouse
│ │ │
P2P para apenas execução consenso / fork choice
boot nodes │
para boot nodes da CL
1. O que concluir antes do hardfork
Step 1 — Obter os arquivos de configuração
| Arquivo | Finalidade | Observações |
|---|---|---|
genesis.json (atualizado) | Para o Execution Client. Contém o TTD e o horário de cada fork | Diferente da versão publicada atualmente |
config.yaml | Especificação da cadeia para o Consensus Client | Define os fork epochs e o network ID |
deposit_contract_block.txt | Número do bloco do Deposit Contract | |
genesis.ssz | Estado gênese da beacon chain | Aprox. 5,5 MB |
Esses arquivos são distribuídos no diretório metadata/ do repositório da Testnet.
Step 2 — Manter o Geth na série v1.13
Continue utilizando o Geth v1.13.5, a versão verificada neste site. Atualmente, o Geth v1.14.0 e posteriores não conseguem sincronizar a cadeia.
Uma versão mais recente do Geth será necessária para as fases Shapella, Dencun e Pectra. Anunciaremos a versão compatível nesta página assim que o cronograma for confirmado.
Step 3 — Configurar um Consensus Client
- Recomendado: Lighthouse v7.0.1 (imagem Docker
sigp/lighthouse:v7.0.1) - O Lighthouse foi testado e funciona de forma estável; outros clientes não foram verificados
- Pode ser executado no mesmo host do seu Geth existente
- É necessário configurar os boot nodes (ENR) da Consensus Layer (serão anunciados assim que confirmados)
- Recomendamos o uso de checkpoint sync para a sincronização inicial (o endpoint será anunciado assim que confirmado)
Step 4 — Conectar o Geth e o Consensus Client via Engine API
Os dois se comunicam por meio da Engine API autenticada (porta padrão 8551). Gere um segredo JWT compartilhado e configure-o em ambos os lados.
# Example: generating the JWT secret
openssl rand -hex 32 | tr -d "\n" > /data/jwt.hex
Opções de inicialização a serem adicionadas no Geth:
--authrpc.addr=127.0.0.1
--authrpc.port=8551
--authrpc.jwtsecret=/data/jwt.hex
--authrpc.vhosts=localhost
Step 5 — Verificar a sincronização e a conectividade
- O Consensus Client alcançou a beacon chain
- O log do Geth registra atualizações de fork choice via Engine API
- Mantenha ambos os clientes em execução no dia do hardfork. The Merge é acionado automaticamente quando o TTD configurado é atingido
2. Trabalho necessário em cada fase após o hardfork
Nas fases Shapella, Dencun e Pectra, será necessário atualizar a configuração e reiniciar após o nosso anúncio.
| Fase | Execution Client | Consensus Client |
|---|---|---|
| Phase 2 — Shapella | Definir shanghaiTime | CAPELLA_FORK_VERSION / CAPELLA_FORK_EPOCH |
| Phase 3 — Dencun | Definir cancunTime | DENEB_FORK_VERSION / DENEB_FORK_EPOCH |
| Phase 4 — Pectra | Definir pragueTime | ELECTRA_FORK_VERSION / ELECTRA_FORK_EPOCH |
Não atualize a configuração nem reinicie por conta própria antes do nosso anúncio.
3. Caso as ações não sejam realizadas
- Após o hardfork, o nó deixará de receber novos blocos e não conseguirá acompanhar o topo da cadeia
- Aplicações e wallets conectadas a esse nó via RPC não conseguirão obter os blocos e as transações mais recentes
- Um nó que permanecer na cadeia antiga poderá continuar retornando dados da cadeia descontinuada
- Observe que nós comuns nunca sofrem Slashing (apenas validadores estão sujeitos a Slashing)
4. Perguntas frequentes
P. É necessário registrar-se como validador ou depositar 32 JOC?
Não. Nós comuns que não produzem blocos não exigem registro no Launchpad nem deposit data. Apenas a alteração de configuração descrita acima é necessária.
P. É necessário excluir os dados de cadeia existentes e sincronizar novamente?
Não. Todos os dados de cadeia existentes e o histórico de transações são preservados.
P. O Chain ID muda?
Não.
P. É necessário um servidor adicional?
O Consensus Client pode ser executado no seu host existente, desde que haja folga suficiente de disco e memória.
Contato
Em caso de dúvidas sobre este hardfork, entre em contato conosco pelo formulário de contato.