Autor: MegaETH Fonte: @megaeth_labs Tradução: Shan Opa, Jin Se Cai Jin
No cerne de todos os Optimistic Rollups, existe uma suposição chave: as propostas de estado submetidas são consideradas válidas por padrão até que sejam provadas como erradas. No entanto, essa suposição só se mantém se o Rollup tiver um mecanismo forte de prova de fraude. Cadeias que carecem deste mecanismo tornam-se imediatamente inseguras se um estado inválido não for questionado ou se o processo de liquidação for bloqueado devido a um desafio malicioso.
O peso da prova de fraude
Para sustentar a hipótese acima, o L2 do Optimistic deve suportar um mecanismo de prova de fraude (também conhecido como protocolo de resolução de disputas), que permite que validadores (desafiadores) desafiem propostas de estado potencialmente erradas apresentadas pelo ordenante (proponente). Este mecanismo deve garantir duas características-chave:
Todas as propostas de estado erradas podem ser identificadas,
Desafios errados nunca terão sucesso.
Do ponto de vista técnico, este mecanismo contém dois componentes principais:
Subprotocólo de Desafio: lidar com disputas sobre propostas de estado individuais.
Mecanismo de Torneio: Quando um mesmo bloco apresenta várias propostas de estado concorrentes, é utilizado para filtrar a única proposta correta.
Cada proposta de estado é uma declaração sobre os resultados da execução de um conjunto de transações, geralmente contendo três partes:
Estado inicial: O último estado L2 confirmado no Ethereum recentemente;
Carga de Transação: Uma série de transações L2 que ocorreram desde esse estado;
Estado Final: O proponente afirma o resultado obtido após a execução dessas transações.
Portanto, uma proposta completa está essencialmente a dizer:
"Suponha que o estado inicial atual seja A, executando a seguinte lista de transações (payload), eu acho que o estado final deve ser X."
Podemos visualizar esta estrutura na forma da imagem abaixo:
Neste momento, a função do subprotocolo de desafio é validar se a alegação está correta. Se estiver errada, o desafio deve ser bem-sucedido e a proposta deve ser rejeitada.
Prova de Falhas Interativa (Jogo de Desafio Binário)
Na maioria dos sistemas de Optimistic Rollup atualmente em voga, é adotado um protocolo interativo: um desafio entre o desafiante e o proponente.
Uma vez que uma disputa é levantada, as partes irão dividir os resultados intermediários do processo de cálculo (os resultados de cada passo de execução alegados pelo proponente) e gradualmente reduzir a área onde o erro pode ter ocorrido. Este processo será repetido recursivamente até que ambas as partes localizem o único passo de cálculo com erro (por exemplo, uma transação que foi executada incorretamente).
Após determinar o erro específico, esta etapa será executada novamente na rede principal do Ethereum para verificar se realmente existe comportamento fraudulento.
Mas este mecanismo apresenta vários problemas:
Alta latência: Cada interação precisa iniciar uma transação na cadeia do Ethereum. Um processo completo de resolução de disputas pode levar horas ou até dias, especialmente em caso de congestionamento da rede ou quando está sob censura;
Exigências elevadas para o proponente: mesmo que o proponente seja honesto e o desafio seja infundado, ele ainda deve participar de todo o processo de controvérsia, incorrendo em custos significativos de cálculo e interações na cadeia;
Fácil de ser explorado maliciosamente: Desafiantes maliciosos podem continuamente apresentar desafios infundados, forçando proponentes honestos a desperdiçar repetidamente tempo e custos de gas para defender o estado correto.
Na realidade, a prova de fraude interativa é cara, vulnerável sob alta carga e fácil de ser abusada.
Prova de fraude não interativa (Modelo de desafio ZK)
MegaETH adotou um caminho completamente diferente: ele exige que o desafiador apenas gere uma prova de conhecimento nulo (ZKP) concisa, provando que o estado final declarado pelo proponente é inválido.
Especificamente, esta prova ZK demonstra que executar a sequência de transações a partir do estado inicial não resultará no estado final reivindicado pelo proponente. Este mecanismo será construído sobre o zkVM da RISC Zero e se inspirará na arquitetura híbrida de prova de fraude não interativa do OP Kailua para sua implementação.
A prova é submetida a Ethereum através de uma única transação, e o contrato dos validadores na cadeia confirmará sua validade. O proponente da prova não precisa participar de nenhum trabalho, não pode interferir em todo o processo e também não participa de disputas.
Claro, gerar uma prova ZK assim não é tarefa fácil - requer a execução completa do processo de cálculo em disputa na máquina virtual zk, o que deve consumir cerca de 100 bilhões de ciclos de cálculo, com custos que podem chegar a 100 dólares no pior cenário. No entanto, esse custo só ocorre quando a fraude é provada, e, conforme projetado, é arcado pela parte desonesta. Este modelo alivia enormemente a pressão de capital sobre os desafiantes honestos e elimina fundamentalmente o risco de sabotagem maliciosa na mecânica de divisão.
ZK utilizado para prova de fraude, e não para validade de estado
No campo das criptomoedas, "zero conhecimento (ZK)" é frequentemente simplificado como sinônimo de ZK Rollup — ou seja, um sistema que utiliza provas ZK para validar a transição de estado fora da cadeia e, em seguida, publica isso na cadeia. No entanto, essa compreensão abrange apenas metade do potencial do ZK.
MegaETH usa provas de zero conhecimento não para verificar a correção do estado, mas para provar fraudes. Isso nos permite, enquanto mantemos a eficiência e escalabilidade do Optimistic Rollup, adicionar um mecanismo sem confiança e não interativo para detectar e contestar transições de estado inválidas.
Chamamos a este método híbrido de prova de fraude ZK, que traz um modelo de confiança essencialmente diferente.
A janela de detecção permanece a mesma, o tempo de conclusão é significativamente reduzido
Por razões de segurança e prudência, o MegaETH ainda manterá a janela de contestação de 7 dias típica das chains Optimistic, o que significa que qualquer participante tem uma semana inteira para contestar um determinado estado da raiz. No entanto, a verdadeira diferença ocorre após a contestação ser apresentada, no modelo interativo, se a contestação for levantada no 7º dia, pode ser necessário mais alguns dias para resolver a disputa. Durante este período, a finalização na mainnet do Ethereum será congelada, o progresso do protocolo será interrompido e a atividade da chain também será afetada.
E no caso de utilização de provas de fraude ZK, todo o processo de disputa será concluído em cerca de 1 hora. O desafiador gera a prova ZK, submete-a à rede principal do Ethereum, e após a verificação, entra em vigor imediatamente, com o estado da cadeia a obter rapidamente a finalização. Isso efetivamente protege contra um vetor de ataque crítico: desafiadores maliciosos que iniciam repetidamente disputas falsas para atrasar a finalização da cadeia.
Garantia de disponibilidade de dados fornecida pela EigenDA
Para garantir a integridade do processo de prova de fraude, o desafiador deve ser capaz de acessar facilmente e de forma confiável os dados do bloco original, a fim de reproduzir o processo de cálculo questionado.
Esta é precisamente a razão pela qual utilizamos o modelo de fraude ZK em conjunto com EigenDA (uma camada de disponibilidade de dados descentralizada e de alto rendimento).
Através desta estrutura, todo o processo é simplificado para a forma mais segura e eficiente.
O ordenado publica dados de bloco no EigenDA, enquanto apenas submete um pequeno resumo dos dados ao Ethereum. As garantias criptográficas fornecidas pelo EigenDA asseguram que, a qualquer momento, é possível gerar provas de fraude, e que o ordenado não pode "ocultar" dados para escapar da fiscalização;
Qualquer observador pode recuperar dados de bloco do EigenDA, reconstruir blocos completos e executá-los no zkVM;
Uma vez detectada a fraude, o observador poderá gerar prova de fraude ZK concisa, submeter ao contrato de verificação na Ethereum; o ordenante será penalizado e sua proposta inválida será rejeitada.
Um modelo de confiança escalável com garantias de criptografia
MegaETH substituiu o complicado jogo de fraudes interativas por provas de fraude ZK não interativas e simples. Esta abordagem elimina o risco de ataques de assédio, reduz significativamente o tempo de confirmação final e garante que as disputas possam ser resolvidas de maneira eficiente e escalável.
Com a capacidade de computação verificável fornecida pela RiscZero e o suporte ao acesso a dados originais garantido pela @eigen_da, cada proposta de estado possui:
Reconstructibilidade, verificabilidade e possibilidade de ser desafiado por qualquer pessoa —— independentemente da escala.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
A Batalha Final: Como protegemos a segurança do MegaETH com a tecnologia ZK
Autor: MegaETH Fonte: @megaeth_labs Tradução: Shan Opa, Jin Se Cai Jin
No cerne de todos os Optimistic Rollups, existe uma suposição chave: as propostas de estado submetidas são consideradas válidas por padrão até que sejam provadas como erradas. No entanto, essa suposição só se mantém se o Rollup tiver um mecanismo forte de prova de fraude. Cadeias que carecem deste mecanismo tornam-se imediatamente inseguras se um estado inválido não for questionado ou se o processo de liquidação for bloqueado devido a um desafio malicioso.
O peso da prova de fraude
Para sustentar a hipótese acima, o L2 do Optimistic deve suportar um mecanismo de prova de fraude (também conhecido como protocolo de resolução de disputas), que permite que validadores (desafiadores) desafiem propostas de estado potencialmente erradas apresentadas pelo ordenante (proponente). Este mecanismo deve garantir duas características-chave:
Do ponto de vista técnico, este mecanismo contém dois componentes principais:
Cada proposta de estado é uma declaração sobre os resultados da execução de um conjunto de transações, geralmente contendo três partes:
Portanto, uma proposta completa está essencialmente a dizer:
"Suponha que o estado inicial atual seja A, executando a seguinte lista de transações (payload), eu acho que o estado final deve ser X."
Podemos visualizar esta estrutura na forma da imagem abaixo:
Neste momento, a função do subprotocolo de desafio é validar se a alegação está correta. Se estiver errada, o desafio deve ser bem-sucedido e a proposta deve ser rejeitada.
Prova de Falhas Interativa (Jogo de Desafio Binário)
Na maioria dos sistemas de Optimistic Rollup atualmente em voga, é adotado um protocolo interativo: um desafio entre o desafiante e o proponente.
Uma vez que uma disputa é levantada, as partes irão dividir os resultados intermediários do processo de cálculo (os resultados de cada passo de execução alegados pelo proponente) e gradualmente reduzir a área onde o erro pode ter ocorrido. Este processo será repetido recursivamente até que ambas as partes localizem o único passo de cálculo com erro (por exemplo, uma transação que foi executada incorretamente).
Após determinar o erro específico, esta etapa será executada novamente na rede principal do Ethereum para verificar se realmente existe comportamento fraudulento.
Mas este mecanismo apresenta vários problemas:
Na realidade, a prova de fraude interativa é cara, vulnerável sob alta carga e fácil de ser abusada.
Prova de fraude não interativa (Modelo de desafio ZK)
MegaETH adotou um caminho completamente diferente: ele exige que o desafiador apenas gere uma prova de conhecimento nulo (ZKP) concisa, provando que o estado final declarado pelo proponente é inválido.
Especificamente, esta prova ZK demonstra que executar a sequência de transações a partir do estado inicial não resultará no estado final reivindicado pelo proponente. Este mecanismo será construído sobre o zkVM da RISC Zero e se inspirará na arquitetura híbrida de prova de fraude não interativa do OP Kailua para sua implementação.
A prova é submetida a Ethereum através de uma única transação, e o contrato dos validadores na cadeia confirmará sua validade. O proponente da prova não precisa participar de nenhum trabalho, não pode interferir em todo o processo e também não participa de disputas.
Claro, gerar uma prova ZK assim não é tarefa fácil - requer a execução completa do processo de cálculo em disputa na máquina virtual zk, o que deve consumir cerca de 100 bilhões de ciclos de cálculo, com custos que podem chegar a 100 dólares no pior cenário. No entanto, esse custo só ocorre quando a fraude é provada, e, conforme projetado, é arcado pela parte desonesta. Este modelo alivia enormemente a pressão de capital sobre os desafiantes honestos e elimina fundamentalmente o risco de sabotagem maliciosa na mecânica de divisão.
ZK utilizado para prova de fraude, e não para validade de estado
No campo das criptomoedas, "zero conhecimento (ZK)" é frequentemente simplificado como sinônimo de ZK Rollup — ou seja, um sistema que utiliza provas ZK para validar a transição de estado fora da cadeia e, em seguida, publica isso na cadeia. No entanto, essa compreensão abrange apenas metade do potencial do ZK.
MegaETH usa provas de zero conhecimento não para verificar a correção do estado, mas para provar fraudes. Isso nos permite, enquanto mantemos a eficiência e escalabilidade do Optimistic Rollup, adicionar um mecanismo sem confiança e não interativo para detectar e contestar transições de estado inválidas.
Chamamos a este método híbrido de prova de fraude ZK, que traz um modelo de confiança essencialmente diferente.
A janela de detecção permanece a mesma, o tempo de conclusão é significativamente reduzido
Por razões de segurança e prudência, o MegaETH ainda manterá a janela de contestação de 7 dias típica das chains Optimistic, o que significa que qualquer participante tem uma semana inteira para contestar um determinado estado da raiz. No entanto, a verdadeira diferença ocorre após a contestação ser apresentada, no modelo interativo, se a contestação for levantada no 7º dia, pode ser necessário mais alguns dias para resolver a disputa. Durante este período, a finalização na mainnet do Ethereum será congelada, o progresso do protocolo será interrompido e a atividade da chain também será afetada.
E no caso de utilização de provas de fraude ZK, todo o processo de disputa será concluído em cerca de 1 hora. O desafiador gera a prova ZK, submete-a à rede principal do Ethereum, e após a verificação, entra em vigor imediatamente, com o estado da cadeia a obter rapidamente a finalização. Isso efetivamente protege contra um vetor de ataque crítico: desafiadores maliciosos que iniciam repetidamente disputas falsas para atrasar a finalização da cadeia.
Garantia de disponibilidade de dados fornecida pela EigenDA
Para garantir a integridade do processo de prova de fraude, o desafiador deve ser capaz de acessar facilmente e de forma confiável os dados do bloco original, a fim de reproduzir o processo de cálculo questionado.
Esta é precisamente a razão pela qual utilizamos o modelo de fraude ZK em conjunto com EigenDA (uma camada de disponibilidade de dados descentralizada e de alto rendimento).
Através desta estrutura, todo o processo é simplificado para a forma mais segura e eficiente.
Um modelo de confiança escalável com garantias de criptografia
MegaETH substituiu o complicado jogo de fraudes interativas por provas de fraude ZK não interativas e simples. Esta abordagem elimina o risco de ataques de assédio, reduz significativamente o tempo de confirmação final e garante que as disputas possam ser resolvidas de maneira eficiente e escalável.
Com a capacidade de computação verificável fornecida pela RiscZero e o suporte ao acesso a dados originais garantido pela @eigen_da, cada proposta de estado possui:
Reconstructibilidade, verificabilidade e possibilidade de ser desafiado por qualquer pessoa —— independentemente da escala.