28264

• A Reth incorporou a correção da raiz de estado pelo pull request #28264 em 3 de novembro às 21:00 UTC.
• A Reth lançou a correção na versão v2.10.0, classificada como de alta prioridade para nós que criam blocos com payload e para os que não criam.
• A Base lançou a versão v1.5.3 do nó, eliminando o risco de os validadores pararem devido a uma raiz de estado inválida.
Reth v2.10.0 inclui correção de alta prioridade
A Reth lançou uma correção de alta prioridade para um bug que, em alguns casos, poderia deixar um nó da blockchain com a raiz de estado incorreta — o hash único que resume todo o estado de uma cadeia —, e a Base disponibilizou sua própria versão corrigida do nó para os operadores até quinta-feira. A raiz de estado é como uma cadeia no estilo Ethereum comprova seus registros: se um cliente a calcula incorretamente, ele diverge dos demais, e um validador que o execute pode propor ou atestar blocos que o restante da rede rejeita. Os clientes de execução são a camada de software que processa transações e acompanha saldos, por isso um cálculo incorreto nessa camada afeta a base de toda a pilha. A correção foi incluída na versão v2.10.0, e os mantenedores classificaram a atualização como de alta prioridade para todos, abrangendo nós que criam blocos e nós que apenas os validam; portanto, nenhuma categoria de operador foi orientada a esperar pela próxima janela de atualização de rotina. A alteração foi incorporada por meio do pull request #28264, mesclado em 3 de novembro às 21:00 UTC; os horários dessa mesclagem e do aviso de status da Base indicam que transcorreram cerca de 43 horas entre a correção e o alerta público. A Base descobriu o bug em 4 de novembro e corrigiu, no mesmo dia, todos os seus produtores de blocos, as máquinas que montam novos blocos. Em seguida, orientou os operadores a instalar sua própria versão do nó, v1.5.3, que elimina a possibilidade de os validadores da Base pararem devido a uma raiz de estado inválida, e informou que não é necessário ressincronizar para aplicá-la. A Base é executada na OP Stack e depende da op-reth, a versão da Reth desenvolvida para a OP Stack, onde o incidente relatado veio à tona. As duas partes dessa orientação são importantes: a atualização elimina a falha, enquanto a dispensa da ressincronização mantém o custo de aplicá-la praticamente nulo para operadores ocupados.