Quando “a implementação do zkEVM realiza validação em tempo real, reduzindo o atraso da prova de 16 minutos para 16 segundos” é frequentemente mencionada, é muitas vezes entendida como uma mera melhoria de desempenho. Mas no sistema zk, o tempo não é um indicador neutro.
A mudança de ordem de magnitude da prova determina diretamente se o zkEVM pode entrar na trajetória crítica de tempo do sistema, alterando assim seu papel na arquitetura.
16 segundos não são apenas “mais rápidos”, mas sim a primeira vez que as provas zk são trazidas para uma escala de tempo próxima ao slot de bloco. Este passo tem um impacto essencialmente diferente no L2 zkEVM e no L1 zkEVM.
Sobre L2 zkEVM: de “finalidade pós-evento” a um estado confiável a nível de slot
Na L2 zkEVM, a função da prova zk é demonstrar a validade de uma transição de estado L2 para o Ethereum L1.
O atraso de prova de aproximadamente 16 minutos implica uma restrição real:
Embora o L2 possua, em teoria, uma finalização imediata, na prática, a sua confirmação de segurança está sempre atrasada por vários ciclos de bloco.
Isto levou a que os blocos L2 permanecessem em um estado de “confirmação suave” por um longo período:
Para os utilizadores, a experiência é imediata.
Ainda é necessário esperar pelo L1 e sistemas externos.
Quando a prova de atraso caiu para cerca de 16 segundos, essa estrutura passou por uma mudança qualitativa.
Primeiro, a prova zk pode ser gerada de forma a rolar por slot, em vez de ser feita uma compensação em massa através de muitos blocos históricos.
Isto significa que os blocos L2 agora têm um significado de segurança temporal próximo ao L1, e não são mais apenas estados intermediários à espera de confirmação final.
Em segundo lugar, isso afeta diretamente o modelo de confiança dos sistemas interdomínios.
As pontes entre cadeias, recargas em CEX e sistemas de liquidação podem depender dos resultados de verificação zk no L1 em segundos, em vez de definir uma janela de espera extra ou controle de risco manual.
Mais importante ainda, o zkEVM iguala-se pela primeira vez à experiência do utilizador do Optimistic Rollup. A abordagem zk já não é apenas uma “camada de liquidação segura, mas lenta”, mas começa a tornar-se um ambiente de execução capaz de suportar aplicações em tempo real.
Para L1 zkEVM: zk aproxima-se pela primeira vez da escala de tempo de consenso
L1 zkEVM não é uma Rollup, mas sim uma potencial reestruturação do método de validação de execução do L1.
A hipótese de consenso atual do Ethereum é: cada validador precisa reexecutar o EVM, verificando pessoalmente se as transições de estado no bloco estão corretas. A capacidade de execução, portanto, torna-se parte da segurança do consenso e também uma restrição rígida para a escalabilidade do sistema.
A proposta do L1 zkEVM é mudar isso: não é mais necessário que os validadores executem o EVM, apenas que validem uma prova zk.
A validade do bloco passou de “Eu calculei” para “Eu verifiquei um fato criptográfico.”
Mas esse design tem uma condição prévia: as provas zk devem ser rápidas o suficiente para entrar no caminho crítico do consenso.
Se a geração de provas levar minutos, só poderá ser usada como verificação posterior; apenas quando o atraso da prova se aproxima do tempo do slot, é que o zk poderá ter a possibilidade de participar na avaliação em tempo real de “se o bloco é válido”.
Portanto, o significado de 16 segundos não reside em “já é rápido o suficiente”, mas sim em: o zkEVM pela primeira vez não está mais excluído do design de consenso em termos de escala temporal.
Esta é também a razão pela qual a discussão sobre o L1 zkEVM está altamente focada na segurança de 128 bits, teoria da prova e suposições criptográficas de longo prazo. Assim que o zk entra no caminho de consenso, seu nível de segurança torna-se equivalente ao de funções hash e algoritmos de assinatura.
De uma perspectiva mais macro, isso é um ponto na mesma linha lógica das direções que o Ethereum está promovendo, como snarkification e Beam Chain.
A camada de consenso busca ser simples, estável e formalmente verificável; a camada de execução pode ser complexa, paralela e terceirizada; enquanto a correção é comprimida e provada pelo zk.
Resumo
Portanto, “a prova de atraso caiu de 16 minutos para 16 segundos” não é um simples avanço de desempenho; isso marca a transição do zkEVM de uma “ferramenta de segurança de prova pós-evento” para uma “infraestrutura que pode participar da definição de finalidades em tempo real”.
E uma vez que a escala de tempo do zk se aproxima do slot, quais componentes do sistema são essenciais e quais são apenas acessórios, muitas vezes também serão reescritos.
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
De prova em minutos a segurança a nível de slot: o que significa a validação em tempo real da zkEVM?
Escrito por: Tia, Techub News
Quando “a implementação do zkEVM realiza validação em tempo real, reduzindo o atraso da prova de 16 minutos para 16 segundos” é frequentemente mencionada, é muitas vezes entendida como uma mera melhoria de desempenho. Mas no sistema zk, o tempo não é um indicador neutro.
A mudança de ordem de magnitude da prova determina diretamente se o zkEVM pode entrar na trajetória crítica de tempo do sistema, alterando assim seu papel na arquitetura.
16 segundos não são apenas “mais rápidos”, mas sim a primeira vez que as provas zk são trazidas para uma escala de tempo próxima ao slot de bloco. Este passo tem um impacto essencialmente diferente no L2 zkEVM e no L1 zkEVM.
Sobre L2 zkEVM: de “finalidade pós-evento” a um estado confiável a nível de slot
Na L2 zkEVM, a função da prova zk é demonstrar a validade de uma transição de estado L2 para o Ethereum L1.
O atraso de prova de aproximadamente 16 minutos implica uma restrição real:
Embora o L2 possua, em teoria, uma finalização imediata, na prática, a sua confirmação de segurança está sempre atrasada por vários ciclos de bloco.
Isto levou a que os blocos L2 permanecessem em um estado de “confirmação suave” por um longo período:
Para os utilizadores, a experiência é imediata.
Ainda é necessário esperar pelo L1 e sistemas externos.
Quando a prova de atraso caiu para cerca de 16 segundos, essa estrutura passou por uma mudança qualitativa.
Primeiro, a prova zk pode ser gerada de forma a rolar por slot, em vez de ser feita uma compensação em massa através de muitos blocos históricos.
Isto significa que os blocos L2 agora têm um significado de segurança temporal próximo ao L1, e não são mais apenas estados intermediários à espera de confirmação final.
Em segundo lugar, isso afeta diretamente o modelo de confiança dos sistemas interdomínios.
As pontes entre cadeias, recargas em CEX e sistemas de liquidação podem depender dos resultados de verificação zk no L1 em segundos, em vez de definir uma janela de espera extra ou controle de risco manual.
Mais importante ainda, o zkEVM iguala-se pela primeira vez à experiência do utilizador do Optimistic Rollup. A abordagem zk já não é apenas uma “camada de liquidação segura, mas lenta”, mas começa a tornar-se um ambiente de execução capaz de suportar aplicações em tempo real.
Para L1 zkEVM: zk aproxima-se pela primeira vez da escala de tempo de consenso
L1 zkEVM não é uma Rollup, mas sim uma potencial reestruturação do método de validação de execução do L1.
A hipótese de consenso atual do Ethereum é: cada validador precisa reexecutar o EVM, verificando pessoalmente se as transições de estado no bloco estão corretas. A capacidade de execução, portanto, torna-se parte da segurança do consenso e também uma restrição rígida para a escalabilidade do sistema.
A proposta do L1 zkEVM é mudar isso: não é mais necessário que os validadores executem o EVM, apenas que validem uma prova zk.
A validade do bloco passou de “Eu calculei” para “Eu verifiquei um fato criptográfico.”
Mas esse design tem uma condição prévia: as provas zk devem ser rápidas o suficiente para entrar no caminho crítico do consenso.
Se a geração de provas levar minutos, só poderá ser usada como verificação posterior; apenas quando o atraso da prova se aproxima do tempo do slot, é que o zk poderá ter a possibilidade de participar na avaliação em tempo real de “se o bloco é válido”.
Portanto, o significado de 16 segundos não reside em “já é rápido o suficiente”, mas sim em: o zkEVM pela primeira vez não está mais excluído do design de consenso em termos de escala temporal.
Esta é também a razão pela qual a discussão sobre o L1 zkEVM está altamente focada na segurança de 128 bits, teoria da prova e suposições criptográficas de longo prazo. Assim que o zk entra no caminho de consenso, seu nível de segurança torna-se equivalente ao de funções hash e algoritmos de assinatura.
De uma perspectiva mais macro, isso é um ponto na mesma linha lógica das direções que o Ethereum está promovendo, como snarkification e Beam Chain.
A camada de consenso busca ser simples, estável e formalmente verificável; a camada de execução pode ser complexa, paralela e terceirizada; enquanto a correção é comprimida e provada pelo zk.
Resumo
Portanto, “a prova de atraso caiu de 16 minutos para 16 segundos” não é um simples avanço de desempenho; isso marca a transição do zkEVM de uma “ferramenta de segurança de prova pós-evento” para uma “infraestrutura que pode participar da definição de finalidades em tempo real”.
E uma vez que a escala de tempo do zk se aproxima do slot, quais componentes do sistema são essenciais e quais são apenas acessórios, muitas vezes também serão reescritos.