Roteiro do Interop "acelera": após a atualização Fusaka, interoperabilidade do Ethereum pode dar um salto crucial

Chainfeeds Guia de Leitura:

Sem ZK em tempo real, é difícil ter uma verdadeira experiência de usuário Interop utilizável.

Fonte do artigo:

Autor do artigo:

imToken Labs

Opinião:

imToken Labs: No dia 4 de dezembro, a atualização Fusaka do Ethereum foi oficialmente ativada na mainnet, mas não teve o mesmo destaque que a atualização Dencun na época. Os holofotes do mercado também se concentraram mais na expansão do Blob e no PeerDAS, com discussões animadas sobre a redução adicional dos custos de dados do L2. No entanto, além desse burburinho, existe uma proposta discreta, a EIP-7825, que removeu o maior obstáculo para a implementação do L1 zkEVM e provas em tempo real no Ethereum, podendo até ser considerada como o início silencioso do caminho para o Interop final. Nesta atualização Fusaka, o foco de todos esteve quase exclusivamente na escalabilidade: a capacidade do Blob foi expandida em 8 vezes, e, juntamente com a verificação de amostragem aleatória do PeerDAS, a narrativa de custos da pista DA (disponibilidade de dados) tornou-se definitivamente coisa do passado. De fato, L2s mais baratos são uma coisa boa, mas para o roteiro de longo prazo do ZK no Ethereum, a EIP-7825 é o verdadeiro game changer, pois estabelece um limite de Gas para cada transação individual (cerca de 16,78 milhões de Gas). Como é sabido, este ano o Gas Limit do bloco do Ethereum já foi aumentado para 60 milhões, mas mesmo com o aumento do limite, teoricamente, se alguém estiver disposto a pagar um preço de Gas extremamente alto, ainda poderá enviar uma “Mega-Transação” super complexa, ocupando toda a capacidade de 60 milhões de Gas do bloco e bloqueando todo o bloco. Então, por que limitar o tamanho de cada transação? Na verdade, essa mudança não afeta em nada as transferências dos usuários comuns, mas para o ZK Prover (gerador de provas), é uma questão de vida ou morte, e isso está intimamente relacionado à forma como os sistemas ZK geram provas. Por exemplo, antes da EIP-7825, se um bloco contivesse uma “Mega-Transação” que consumisse 60 milhões de Gas, o ZK Prover teria que processar essa transação extremamente complexa em sequência, sem possibilidade de divisão ou paralelização, como se fosse uma estrada de mão única com um caminhão gigante andando devagar na frente, obrigando todos os carros menores (outras transações) a esperar até que ele termine. Isso, sem dúvida, decretava a sentença de morte das “provas em tempo real” — pois o tempo de geração da prova se tornava totalmente imprevisível, podendo levar dezenas de minutos ou até mais. Após a EIP-7825, mesmo que no futuro a capacidade do bloco aumente para 100 milhões de Gas, como cada transação é obrigatoriamente limitada a 16,78 milhões de Gas, cada bloco é dividido em “pequenas unidades de tarefa” previsíveis, delimitadas e processáveis em paralelo. Isso significa que a geração de provas do Ethereum passa de um “problema lógico” complicado para um “problema puramente de poder computacional (Money Problem)”: desde que se invista poder computacional paralelo suficiente, é possível processar essas pequenas tarefas simultaneamente em um tempo muito curto, gerando provas ZK para blocos enormes. No entanto, embora a EIP-7825, ao limitar o tamanho das transações individuais, tenha pavimentado o caminho físico (paralelização) para provas em tempo real, isso é apenas um lado da moeda; o outro lado é como a própria mainnet do Ethereum pode utilizar essa capacidade. Isso envolve a narrativa mais hardcore do roteiro do Ethereum — o L1 zkEVM. Por muito tempo, o zkEVM tem sido visto como o “Santo Graal” da escalabilidade do Ethereum, não apenas porque resolve o gargalo de desempenho, mas também porque redefine o mecanismo de confiança do blockchain. Sua ideia central é permitir que a mainnet do Ethereum tenha a capacidade de gerar e verificar provas ZK. Em outras palavras, no futuro, após a execução de cada bloco do Ethereum, será possível emitir uma prova matemática verificável, permitindo que outros nós (especialmente nós leves e L2s) confirmem a correção dos resultados sem precisar recalcular — se a capacidade de gerar provas ZK for incorporada diretamente na camada de protocolo do Ethereum (L1), o proponente (Proposer) empacota cada bloco e gera uma prova ZK, e os nós validadores não precisarão mais reexecutar as transações, bastando verificar essa pequena prova matemática.