O hard fork Fusaka da Ethereum deve ocorrer no terceiro ou quarto trimestre deste ano, segundo um representante da Fundação Ethereum.
Em uma publicação no X em 28 de abril, Tomasz Kajetan Stańczak, codiretor executivo da Fundação Ethereum, afirmou que a organização pretende implementar a atualização de rede Fusaka no terceiro ou quarto trimestre de 2025. No entanto, o cronograma exato de lançamento ainda não foi definido.
As declarações surgem em meio a controvérsias sobre a futura implementação da atualização do Formato de Objetos da EVM (EOF) para a Ethereum Virtual Machine (EVM). Como destacou Stańczak, o EOF deve ser integrado à atualização de rede Fusaka.
A EVM é o software que executa os contratos inteligentes da Ethereum. O EOF implementaria uma série de mudanças no protocolo, conhecidas como propostas de melhoria da Ethereum (EIPs), com implicações profundas em seu funcionamento. O EOF introduz um formato de contêiner extensível e com controle de versão para o bytecode dos contratos inteligentes, que é verificado uma única vez no momento da implantação, separando código e dados para ganhos de eficiência.
Empacotar, carimbar uma vez, enviar
O bytecode é um conjunto de instruções de baixo nível e compactas. Contratos inteligentes escritos em Solidity precisam ser compilados em bytecode antes que a EVM possa executá-los.
O EOF define um módulo contêiner para o bytecode dos contratos inteligentes, substituindo os blobs de bytecode livres atuais por uma estrutura melhor definida. Esses objetos seriam compostos por:
Um cabeçalho começando com o valor hexadecimal 0xEF00, seguido por um byte de versão para garantir atualizações futuras.
Uma tabela de seções, fornecendo metadados sobre o conteúdo do contêiner. Cada entrada inclui um byte para o tipo da seção e dois bytes para o tamanho da entrada.
Seções com o conteúdo propriamente dito, contendo ao menos uma seção de código e quaisquer seções de dados necessárias — novos tipos de seções podem ser adicionados em futuras EIPs.
Essa estrutura visa otimizar a operação da EVM, permitindo maior eficiência e menor sobrecarga de processamento. A atualização resultaria em um ambiente de desenvolvimento mais limpo e contratos inteligentes implantados mais fáceis de entender.
Não dê JUMP, use RJUMP!
A EIP-4200, uma das propostas dentro do EOF, propõe uma alternativa às instruções JUMP e JUMPI, que permitem que o programa mude a execução para qualquer deslocamento arbitrário de bytes. Esse tipo de execução leva a bugs difíceis de detectar (por exemplo, valores de JUMP incorretos) e facilita a ocultação de malware em blobs de dados, direcionando o ponteiro de execução para lá.
Essa prática é conhecida como salto dinâmico, e a EIP-4750 (em revisão) propõe proibir saltos dinâmicos JUMP/JUMPI dentro de contratos inteligentes EOF, rejeitando-os totalmente em uma fase posterior da implementação. Na forma atual, essa EIP substitui essas instruções por chamadas de função (CALLF) e retornos de função (RETF). Essas novas instruções garantiriam que os destinos sejam codificados diretamente no bytecode, sem afetar os contratos antigos pré-EOF.
Desenvolvedores que optarem por usar JUMP ou JUMPI após a atualização terão seus bytecodes validados no momento da implantação, para garantir que nunca saltem para dados ou para o meio de outra instrução. Essa verificação seria feita por meio das regras de validação da EIP-3670 e da tabela de saltos (EIP-3690), verificando todos os destinos.
Como alternativa, o EOF implementa RJUMP e RJUMPI, que exigem que o destino esteja codificado no bytecode. Mesmo assim, nem todos apoiam a implementação do EOF.
EOF tem seus críticos
O EOF é a implementação de 12 EIPs com grandes impactos na forma como os desenvolvedores de contratos inteligentes trabalham. Seus defensores afirmam que o formato é mais eficiente, elegante e facilita atualizações futuras.
Por outro lado, os críticos argumentam que ele é excessivamente complexo e traz mais camadas de complicação a um sistema já sofisticado como a Ethereum. O desenvolvedor Pascal Caversaccio lamentou em uma publicação no Ethereum Magicians, em 13 de março, que “o EOF é extremamente complexo”, já que adiciona duas novas semânticas e remove ou adiciona mais de uma dúzia de opcodes. Além disso, ele argumentou que o upgrade não seria necessário.
Segundo ele, todos os benefícios poderiam ser alcançados com “atualizações mais pontuais e menos invasivas”. Ele acrescentou que a EVM antiga também precisaria ser mantida, “provavelmente indefinidamente”.
Caversaccio também alertou que o EOF exigiria atualizações nas ferramentas de desenvolvimento, o que poderia introduzir novas vulnerabilidades devido à ampla superfície de ataque. Além disso, ele apontou que “os contratos da EVM ficariam muito mais complicados devido aos cabeçalhos”, enquanto contratos vazios atualmente ocupam apenas 15 bytes. Outro desenvolvedor destacou no mesmo tópico:
“Talvez como uma observação geral, parece haver uma discordância sobre se mudanças importantes na EVM são desejáveis. Uma máquina virtual estável, sobre a qual se pode investir no desenvolvimento de ferramentas e aplicativos com confiança, é muito mais valiosa.”
Caversaccio parece não estar sozinho em sua oposição ao EOF. Uma pesquisa na plataforma de votação ETHPulse mostrou que 39 eleitores, que detêm quase 17.745 Ether (ETH) no total, são contra a atualização. Apenas sete detentores, somando menos de 300 ETH, votaram a favor.