Estado de prova de fraude em ETH L2

Dou muita importância a isto. A partir do próximo ano, só mencionarei publicamente, em blogs, discursos e outros eventos, os projetos L2 que tenham atingido o estágio 1 ou superior, talvez com um breve período de tolerância para projetos novos e interessantes.

Independentemente de eu investir ou não, ou de tu seres ou não o meu fren, é necessário atingir a fase um, caso contrário não será considerado.

"Fase" do sistema Rollup é um framework para avaliar aproximadamente o nível de segurança, desde a Fase 0 até a Fase 2. Atualmente, apenas Arbitrum e Optimism alcançaram a Fase 1 nos principais Rollup, a maioria dos outros Optimistic Rollup ainda está na Fase 0.

Nesta situação, surgiram alguns problemas:

Desde que o Optimistic Rollup foi lançado, já se passaram três anos. Por que ainda nenhum projeto alcançou o estágio 2 mais alto?
Quando podemos esperar que o Optimistic Rollup atinja a Fase 2?

Este artigo tem como objetivo responder a essas perguntas através da análise da prova de fraude e do mecanismo de desafio do Optimistic Rollup, e discutir como cada projeto está se esforçando para alcançar a Fase 2. Além disso, este artigo também irá explorar o futuro desenvolvimento do Optimistic Rollup e do sistema de prova de fraude.

1.2. Comparação entre Optimistic Rollup e ZK Rollup

Como é amplamente conhecido, a Ethereum tem uma velocidade lenta e Lavagem de dinheiro alta. Pesquisadores e desenvolvedores da comunidade Ethereum têm trabalhado arduamente para resolver esse problema. Após explorar soluções como Fragmentação e plasma, a comunidade finalmente decidiu que a Rollup é a principal abordagem para alcançar escalabilidade. Como resultado, projetos como Arbitrum, Optimism e zkSync têm surgido. De acordo com dados da L2Beat, atualmente há cerca de 40 Rollups em operação, além de outras soluções como Validium e Optimium que adotaram a abordagem alt-DA para alcançar maior escalabilidade, totalizando cerca de 41. Além disso, espera-se que cerca de 80 novas Rollup chains sejam lançadas.

（Situação atual do L2 | Fonte:L2Beat）

O conceito central do Rollup é executar transações fora da cadeia, enviando apenas dados de transações e um estado raiz para a cadeia Ethereum, a fim de alcançar escalabilidade. Os usuários podem depositar fundos em um contrato de ponte específico na cadeia Ethereum e transferir fundos para o Rollup para realizar transações internas. Como os dados de transação são enviados para a cadeia Ethereum e uma vez confirmados não podem ser alterados sem comprometer a segurança da cadeia Ethereum, o Rollup é considerado "herdando a segurança da cadeia Ethereum".

Mas será verdade? E se o proponente do Rollup que processa as transações for malicioso? O proponente malicioso pode alterar o saldo da Alice, transferindo-o para a sua conta e retirando-o para o Ethereum, efetivamente roubando os fundos da Alice.

Para evitar esta situação, é necessário um mecanismo de segurança adicional ao retirar fundos do Rollup para a cadeia ETH. Através da apresentação de prova ao contrato de ponte ETH, que comprova que a transação de retirada foi processada corretamente e incluída na cadeia L2, a transação de retirada pode ser concluída.

A maneira mais simples, também adotada por cada Rollup, é comparar o valor de hash da transação de saque com a raiz de estado do Rollup para provar que a transação de saque foi corretamente incluída no estado do Rollup. Isso requer enviar a transação de saque e a raiz de estado para o contrato de ponte na Ethereum. Os usuários enviam suas transações de saque e os validadores calculam e enviam a raiz de estado.

No entanto, se os validadores da raiz de estado submetida forem maliciosos e submeterem uma raiz de estado incorreta, a segurança dos fundos dos utilizadores poderá ser comprometida. Para mitigar este tipo de risco, foram propostos dois mecanismos principais, o que diferencia o Optimistic Rollup do ZK Rollup.

**ZK Rollup **O ZK Rollup não apenas exige que os validadores enviem a raiz do estado, mas também forneçam uma prova ZK para verificar a correção do cálculo da raiz do estado. Se os validadores enviarem uma raiz de estado incorreta, a prova ZK não passará na verificação do contrato de validação L1, impedindo o envio de raízes de estado maliciosas.
**Optimistic Rollup Optimistic Rollup permite que validadores designados submetam uma raiz de estado sem garantias adicionais, com base na premissa de que a submissão é honesta. No entanto, se a raiz de estado submetida estiver incorreta, qualquer pessoa pode questioná-la e impedir o seu uso no processo de levantamento. O questionador deve apresentar evidências à rede Ethereum para provar que a raiz de estado está errada, o que é chamado de prova de fraude (Fraud Proof).

Para garantir a segurança na resolução de questões como ataques de revisão L1, o tempo de retirada do Optimistic Rollup geralmente é de cerca de uma semana.

1.3. Por que precisamos de prova de fraude?

Ao contrário do ZK Rollup, os validadores do Optimistic Rollup podem submeter uma raiz de estado errada e tentar manipular transações de levantamento. A prova de fraude previne eficazmente isso, garantindo a segurança dos fundos no contrato ponte.

Sem um forte mecanismo de prova de fraude, os Rollups Otimistas não podem herdar totalmente a segurança do Ethereum. Por exemplo, no sistema de validadores permissivos da Arbitrum, se todos os validadores conluio, eles poderiam roubar todos os fundos do contrato de ponte. Da mesma forma, em rollups baseados em OP Stack, como o Base, um único validador malicioso pode roubar fundos porque um mecanismo de prova de falha sem permissão ainda não foi implementado no principal da Rede.

Portanto, prova de fraude desempenha um papel crucial na segurança do Optimistic Rollup, e qualquer sistema que careça de um mecanismo de prova de fraude completo representa um risco para os ativos dos usuários.

Este artigo avaliará os riscos enfrentados por várias soluções de Optimistic Rollup e examinará a implementação de seus mecanismos de prova de fraude, bem como suas vantagens e desvantagens.

1.4. Rumo à Fase 2: "Remover as rodinhas de apoio"

O sistema prova de fraude desempenha um papel fundamental ao ajudar o Optimistic Rollup a realizar a fase 2. O framework de fases proposto por Vitalik, atualmente operado pela L2Beat, é usado para avaliar o nível de segurança do Rollup.

No ecossistema Ethereum, esta fase de estrutura é frequentemente comparada a aprender a andar de bicicleta. O Rollup da Fase 0 depende de suposições de confiança máxima, sendo comparado a uma bicicleta com rodinhas de apoio, enquanto o Rollup da Fase 2, que herda totalmente a segurança do Ethereum, é comparado a uma bicicleta de duas rodas sem rodinhas de apoio.

Aqui estão os padrões detalhados para cada uma das fases de 0 a 2:

Como mencionado anteriormente, é crucial implementar um mecanismo adequado de prova de fraude e desafio para que o Optimistic Rollup atinja a Fase 1 ou Fase 2. Com base nesses critérios, o sistema de prova de fraude que atenda aos requisitos da Fase 2 deve ter as seguintes características:

O sistema funciona bem, sem falhas conhecidas e tem a característica "1-de-N".
Este é um sistema não licenciado, qualquer pessoa pode enviar uma prova.
Se houver falhas no sistema de prova, deve ser possível provar na cadeia.

Na segunda metade deste artigo, vamos explorar como vários protocolos tentam implementar esses recursos.

2. prova de fraude - Conceito e Mal-entendidos

2.1. Como é implementada a prova de fraude?

A prova de fraude fornece evidências verificáveis na cadeia de que a raiz de estado enviada não está correta, o que significa que uma função de transição de estado específica em L2 foi executada incorretamente. Uma maneira simples é gerar uma prova para todos os Blocos L2 desde a raiz de estado confirmada anteriormente até a raiz de estado atual, a fim de provar que a raiz de estado está incorreta. No entanto, esse método é caro e demorado.

Portanto, ao gerar uma prova de fraude válida, é necessário primeiro reduzi-la a uma transição específica de estado incorreto e depois gerar a prova para essa parte. A maioria dos protocolos de prova de fraude segue este método.

prova de fraude和质疑protocolo通常包括以下步骤：

Os validadores (proponentes) enviam regularmente para a rede Ethereum (ETH) as saídas (ou declarações) contendo a raiz do estado L2.
Se os validadores (questionadores) não concordarem com a saída, eles irão questionar.
O proponente e o questionador identificam as partes divergentes por meio de um processo chamado de bipartição ou dissecting, refinando-as para o nível de instrução ou nível de Bloco (ZK Rollup).
O questionador apresenta uma prova de fraude na cadeia, demonstrando a parte incorreta. Protocolos como o Arbitrum e o Optimism geralmente executam instruções suspeitas na cadeia para verificação.
Se a prova de fraude for verificada, as saídas incorretas serão removidas ou substituídas. Com base na dúvida do protocolo, o apresentador pode ser punido, enquanto o questionador será recompensado.

2.2. 常见误解：prova de fraude与质疑不会Reversão链

É importante notar que mesmo em caso de prova de fraude e questionamento, o blockchain não será revertido. A prova de fraude garante que os fundos no contrato da ponte não sejam retirados maliciosamente, não envolvendo a reversão de estados incorretos.

A principal razão para não Reversão é que não é necessário. Quando ocorre uma transição de estado incorreta em um Rollup, o problema central é que um ator mal-intencionado pode roubar fundos dos usuários da ponte. Para evitar isso, basta garantir que a raiz de estado submetida ao L1 esteja correta. Esse processo não tem relação com a Reversão da cadeia, desde que haja mecanismos adequados de prova de fraude e questionamento para evitar a confirmação final de uma raiz de estado mal-intencionada.

Além disso, se o proponente do estado raiz e o ordenador de blocos da cadeia L2 forem entidades diferentes, não há necessidade de realizar o mecanismo de Reversão.

Portanto, mesmo que as dúvidas sejam resolvidas com sucesso, a cadeia L2 não será revertida; apenas o estado raiz submetido ao L1 (saída ou declaração) será excluído ou substituído. Se a prova de fraude e o mecanismo de dúvida estiverem a funcionar corretamente, a segurança dos fundos da ponte dos utilizadores pode ser garantida.

2.3. Caso Real: Questionamento da Kroma em abril de 2024

Através de exemplos reais de questionamento, pode-se ver que toda a cadeia Rollup não será revertida, apenas a raiz de saída será substituída ou eliminada. Até agora, o único exemplo conhecido de questionamento bem-sucedido na Rede principal ocorreu em abril de 2024, com o Kroma, que é um Rollup híbrido baseado na pilha OP, usando provas de falha ZK.

Kroma é um Rollup baseado em OP Stack, com seu próprio sistema de validação ZK e validadores sem permissão. Em 1º de abril de 2024, houve um problema na origem L1 do classificador Kroma, o que resultou na geração de um Bloco incorreto. Além disso, validadores que observaram essa situação enviaram uma raiz de saída incorreta. Pouco depois da submissão da raiz de saída, 12 questionadores levantaram objeções à saída.

Um dos questionadores conseguiu chamar com êxito a função proveFault e remover a saída incorreta.

O questionador executou com sucesso a função proveFault | Fonte:etherscan

Este é o primeiro caso bem-sucedido de desafio na história da Rede principal Ethereum Rollup. Também é o primeiro caso em que a validação e o desafio de falhas de prova foram bem-sucedidos em um ambiente de Rede principal, desde o lançamento do primeiro Optimistic Rollup (Arbitrum) em maio de 2021, cerca de três anos atrás. Para uma descrição detalhada deste desafio, consulte o artigo escrito por Kroma. Neste caso, a cadeia Kroma não foi revertida, apenas foram removidas as raízes de saída incorretas.

免责声明：prova de fraude还是故障证明？

A Prova de Fraude também é conhecida como Prova de Reprovação. Em particular, nas cadeias Optimism e OP Stack, o termo "prova de falha" é usado, enquanto em projetos como Arbitrum, Cartesi, L2Beat, etc., o termo usado é "prova de fraude".

Dadas as dúvidas acima mencionadas sobre o caso Kroma, pode-se inferir que as dúvidas geralmente surgem de 'erros' e não de uma tentativa maliciosa de manipulação de saques. No caso acima mencionado, a principal causa foi a observação de uma anomalia no cliente L1 pelos validadores Kroma. Em outras palavras, às vezes as dúvidas surgem apenas de erros ou patches inadequados dos validadores. Nesse caso, o termo 'proof of failure' pode ser mais adequado.

No entanto, o termo que melhor reflete o seu propósito é "prova de fraude". Todos os mecanismos introduzidos até agora, bem como os que serão introduzidos no futuro, destinam-se a verificar as "atividades fraudulentas" que tentam roubar fundos da ponte de forma maliciosa.

O ponto chave é que, embora o objetivo seja prevenir a fraude, na prática, as dúvidas podem surgir de erros. Neste texto, vou utilizar o termo "prova de fraude", que é mais amplamente utilizado no ecossistema.

3. Hacker攻击！ - 利用prova de fraude机制

3.1. 设计经济争议protocolo

Cada Optimistic Rollup implementa o seu próprio prova de fraude e mecanismo de questionamento para proteger os fundos dos utilizadores. O objetivo comum destes mecanismos é "manter a segurança do protocolo desde que haja pelo menos um participante honesto". A prova de fraude é uma prova de que a função de transição de estado previamente acordada foi executada corretamente, e o processo de verificação resultará na vitória do participante honesto.

No entanto, isso nem sempre é verdade. Na verdade, mesmo com participantes honestos, pode haver situações perigosas para o protocolo. Por exemplo, devido à complexidade da prova de fraude, podem surgir vulnerabilidades inesperadas, e os participantes mal-intencionados podem obter vantagens econômicas em detrimento dos participantes honestos devido a desalinhamento de incentivos, resultando em grandes atrasos na retirada de fundos ou roubo de fundos dos usuários.

Portanto, projetar prova de fraude e um mecanismo de questionamento é uma tarefa muito difícil. Especialmente, para se tornar um Rollup da fase 2, o mecanismo de questionamento deve ser perfeito e ter contramedidas para várias Vetor de Ataque e vulnerabilidades.

Em outras palavras, cada prova de fraude e mecanismo de questionamento precisa considerar como lidar com Vetor de Ataque. Sem entender cada Vetor de Ataque, não é possível entender por que o protocolo deve ser projetado dessa maneira.

Portanto, nesta seção, vamos primeiro examinar os seguintes Vetor de Ataque e explorar como vários protocolos lidam com esses ataques:

Ataques desencadeados por falhas no jogo controverso;
ataques de latência, prolongando o tempo de retirada do usuário para além de 7 dias;
Ataque de Sybil que consome os fundos e recursos do participante honesto;
Ataque desencadeado pela revisão de validadores L1;
Ataques lançados aproveitando as vulnerabilidades na Máquina virtual prova de fraude.

Atenção: os Vetores de Ataque discutidos abaixo são conhecidos publicamente e não afetam a segurança da Rede principal.

Os próximos capítulos irão analisar os vários protocolos e as suas características individuais, como se segue: 01928374656574839201

3.2. Vetor de Ataque #1：利用经济争议游戏

A maioria dos Rollup otimistas com prova de fraude implementada requer uma busca binária para encontrar o primeiro ponto de inconsistência. É muito importante que o protocolo forneça incentivos para encorajar os participantes a agirem de forma honesta.

Uma das maneiras mais simples de alcançar esse objetivo é fazer com que os participantes depositem uma certa quantia de dinheiro (Margem) ao tomar medidas, e se eles forem considerados comportamento malicioso, serão corteMargem.

Do ponto de vista da teoria dos jogos, protocolo deve garantir que os participantes mal-intencionados gastem mais dinheiro em ataques do que os participantes honestos gastam em defesa. No entanto, isso é extremamente difícil de alcançar.

A chave aqui é que, em um ambiente de jogo, antes de questionar, não é possível saber de antemão quem são os participantes maliciosos. Em outras palavras, o afirmador que envia a saída pode ser malicioso, e o questionador que duvida da saída também pode ser malicioso. Portanto, o protocolo deve ser projetado com a suposição de que qualquer uma das partes pode ser maliciosa. Além disso, devido à possibilidade de vários Vetor de Ataque, o design do protocolo se torna extremamente complexo.

Devido a cada protocolo adotar mecanismos diferentes, é necessário definir o Vetor de Ataque e o modelo de incentivo do atacante correspondentes a cada método. Além disso, é necessário projetar um modelo de segurança econômica para garantir a segurança mesmo quando esses modelos são combinados.

Este tópico ainda está em discussão contínua. Nesta seção, analisaremos Vetor de Ataque que pode ocorrer comumente, bem como os incentivos dos participantes nesses cenários. Além disso, discutiremos como cada protocolo lida com esses ataques e até que ponto eles limitam esses incentivos.

3.2.1. Vetor de Ataque #1-1：latência攻击

Um ataque de latência refere-se a uma entidade maliciosa que não tem como objetivo roubar fundos Rollup, mas sim impedir ou atrasar a confirmação de saídas no L1. Esse tipo de ataque pode ocorrer na maioria dos Rollups otimistas atuais, adicionando latência adicional às retiradas, fazendo com que os usuários levem mais de uma semana para sacar do L1.

Isso difere ligeiramente dos ataques causados pela revisão de validadores L1, que serão discutidos posteriormente. A revisão impede que participantes honestos ajam na cadeia ETH, permitindo assim que a raiz de estado malicioso seja finalmente confirmada. Por outro lado, o ataque de latência pode confirmar a raiz de estado mesmo quando os participantes honestos estão ativos, resultando em latência na confirmação final do estado. Nesse caso, os saques dos usuários não apenas podem sofrer latência, mas se o atacante tiver mais fundos do que o defensor, a raiz de estado maliciosa pode ser finalmente confirmada, levando ao roubo dos fundos do usuário.

Uma das formas mais simples de evitar ataques de latência é exigir que os participantes do sistema questionado depositem uma certa quantia de fundos ou Margem, que pode ser cortada se forem considerados responsáveis pela latência.

No entanto, há alguns fatores a serem considerados. E se o atacante ainda tentar um ataque de latência, mesmo que não se importe em ter seus fundos cortados?

Este Vetor de Ataque é bastante desafiador. É também por isso que o sistema de prova de fraude do Arbitrum está atualmente em execução em uma estrutura de permissão.

O mecanismo de prova de fraude aplicado ao Arbitrum One e ao Arbitrum Classic adota um modelo de forquilha. Em vez de simplesmente permitir que os participantes questionem declarações incorretas, cada participante pode submeter as declarações que consideram corretas, acompanhadas de uma certa quantia de fundos, que serão considerados como 'forquilha' da cadeia. As declarações também podem ser consideradas como checkpoints no estado da cadeia.

O modelo de ramificação do Arbitrum

No Arbitrum Classic, os participantes apresentam as declarações e ramificações da cadeia que consideram corretas, eliminando gradualmente as ramificações incorretas por meio de questionamentos, até que a declaração correta seja confirmada.

No entanto, uma única contestação não pode determinar quem está correto. Dois participantes mal-intencionados podem usar o método de bifurcação de forma errada, definindo pontos irrelevantes como pontos de discordância, excluindo assim declarações corretas. Portanto, o Arbitrum garante que as contestações continuem até que nenhum participante aposte fundos em uma declaração específica, garantindo assim que, se houver pelo menos um participante honesto, a contestação possa ser resolvida com sucesso.

Isso pode ser explorado maliciosamente para realizar ataques de latência. Suponha que haja um participante honesto e N-1 participantes maliciosos que apostam fundos na declaração correta, enquanto um participante malicioso aposta fundos na declaração errada. Se os atacantes puderem sempre enviar suas transações antes dos participantes honestos, eles podem iniciar primeiro um desafio. No pior caso, se eles dividirem incorretamente suas partes concordantes em vez de suas partes discordantes, eles podem apresentar uma prova de fraude na parte errada. Naturalmente, isso será aprovado, resultando na falha do lado que apostou nos fundos na declaração correta.

Devido a cada questionamento poder levar até 7 dias, um atacante pode prolongar a latência do protocolo para 7 * (N-1) dias.

Ataque de latência do Arbitrum Classic | Fonte: L2Beat Medium

O problema deste mecanismo é que o custo do ataque de latência é linear com o tempo de protocolo de latência. Se os atacantes descobrirem que este tipo de ataque é lucrativo, irão querer aumentar ao máximo o tempo de latência do protocolo, e o tempo total de latência estará diretamente relacionado com o montante total de fundos do atacante, o que pode resultar em tempos de latência muito longos para levantamentos dos utilizadores.

Em suma, um protocolo de prova de fraude que pode efetivamente se defender contra ataques de latência deve ser projetado de forma a limitar o tempo máximo de latência dentro de uma determinada faixa, ou implementar um mecanismo em que o custo de execução de latência aumente exponencialmente ao longo do tempo, de modo que o custo de executar um ataque seja maior do que o incentivo para o ataque.

3.2.2. Vetor de Ataque #1-2：Sybil 攻击（资源耗尽攻击）

Outro Vetor de Ataque é o ataque Sybil (ataque de esgotamento de recursos, ataque de Baleia). Isso ocorre quando os recursos financeiros ou de computação do atacante superam os do defensor. O atacante pode enviar continuamente raízes de saída incorretas ou criar questionamentos sem sentido, esgotando os recursos financeiros ou de computação do defensor. Em algum momento, o defensor ficará sem recursos financeiros ou de computação disponíveis para se defender, e o atacante acabará por determinar a raiz de saída incorreta e roubar os fundos.

Normalmente, o Vetor de Ataque acima pode ocorrer em sistemas não autorizados de duas maneiras:

Continuar a apresentar saídas incorretas. Suponha que o atacante Bob tenha mais fundos do que o total dos participantes honestos (defensores) Alice, Charlie e David. Nesse caso, Bob continuamente apresenta raízes de árvores incorretas. Os participantes honestos Alice, Charlie e David lidam com isso pagando taxas de gás e depósito e, em algum limiar, os fundos dos participantes honestos se esgotam antes dos de Bob. Nesse ponto, Bob apresenta outra saída incorreta e, como não há mais participantes honestos com fundos restantes na rede, essa saída será finalmente confirmada sem questionamento. Dessa forma, Bob pode roubar fundos do otimista rollup.
Submit multiple challenges to honest outputs. Conversely, malicious participants can attack honest participants by submitting multiple challenges. Similarly, the attack will continue until honest participants run out of funds for gas fees and deposits, and then malicious attackers will submit incorrect outputs and steal user funds from ponte.

Para evitar esse tipo de ataque, é necessário projetar adequadamente a vantagem do defensor sobre o atacante. Em todas as circunstâncias, o defensor deve ter uma vantagem suficiente sobre o atacante. Uma maneira de alcançar isso é projetar cuidadosamente o depósito de garantia; uma vez que o ataque Sybil está relacionado ao montante total de fundos disponíveis para cada participante, se o depósito de garantia for bem projetado, deve ser possível determinar que “o sistema está seguro desde que o total de fundos do atacante não exceda N vezes o total de fundos do defensor”.

Outro método conhecido para evitar ataques Sybil é a implementação do controverso protocolo de resistência Sybil. No próximo capítulo, vamos apresentar mais detalhes sobre o Cartesi Dave.

Vamos ver como cada protocolo lida com essas latências e ataques Sybil através de seus respectivos designs.

3.3. Solução #1: Jogo de disputa econômica saudável

1） Arbitrum BoLD

BoLD, com base no modelo de ramificação do Arbitrum Classic, introduziu os seguintes três elementos para evitar ataques de latência:

All against all challenging mechanism. In BoLD, challenging is no longer pairwise, but a concurrent all-against-all system where all participants can stake funds on the branch they agree with. This prevents the latênciaVetor de Ataque previously generated by one-on-one challenges and ensures that multiple independent challenges cannot occur for the same dispute.
Prova do cálculo de estado correto para prevenir bifurcações maliciosas (compromisso histórico). O problema no Arbitrum Classic é que os participantes maliciosos podem bifurcar de forma incorreta, causando latência e marcando partes não contestadas como pontos contestados. Para isso, o BoLD exige a apresentação de prova, juntamente com a raiz de estado, para verificar se a raiz de estado foi calculada corretamente no processo de bifurcação, garantindo que não ocorram bifurcações maliciosas.

Em BoLD, os participantes devem submeter provas e raízes de estado durante o processo de bifurcação. Essas provas verificam se a raiz de estado atual foi calculada corretamente com base nas raízes de estado submetidas anteriormente. Se um participante malicioso tentar submeter qualquer raiz que não esteja relacionada às raízes de estado previamente submetidas durante o processo de bifurcação, a verificação da prova falhará, resultando na falha da transação de bifurcação. Isso efetivamente garante que cada declaração só possa ocorrer em um tipo de bifurcação.

Portanto, se um atacante quiser bifurcar várias vezes uma declaração honesta no BoLD, ele terá que submeter várias declarações.

No entanto, a geração desta prova requer que os validadores usem uma quantidade considerável de recursos computacionais. Internamente, a geração desta prova requer a geração de hashes para todos os estados na bissecção, geralmente estimando cerca de 270 hashes no Arbitrum (cerca de 1.18 x 10²¹). Para resolver este problema, o BoLD divide a contestação em três níveis, reduzindo o número de hashes a calcular para 226 (aproximadamente 6.71 x 10⁷).

(Este gráfico pressupõe um total de 269 instruções, os dados reais podem variar)

Limitar o tempo de stake através do mecanismo de relógio de xadrez.

No Arbitrum Classic anterior, a duração das dúvidas não tinha restrição de tempo, permitindo que participantes maliciosos atrasassemprotocolo indefinidamente, desde que tivessem fundos suficientes. O BoLD introduziu um mecanismo de relógio de xadrez para limitar efetivamente a duração das dúvidas.

Suponha que dois participantes tenham feito declarações diferentes. Cada participante tem um cronômetro (relógio de xadrez) definido para 6.4 dias. Quando é a vez de um participante fazer uma declaração binária ou de prova, o cronômetro começa a contagem decrescente e para quando o participante completa a tarefa.

Devido a cada participante ter 6.4 dias, o tempo máximo que um único participante pode latência o processo é de 6.4 dias. Assim, no BoLD, o período mais longo de questionamento é de 12.8 dias (em alguns casos, quando o comitê de segurança intervém, é adicionado um extra de 2 dias).

Através destes mecanismos, o Arbitrum BoLD limita eficazmente a latência causada pela controvérsia. O período máximo de controvérsia é de duas semanas, com uma latência adicional máxima de cerca de uma semana para os utilizadores.

No entanto, isso pode ser explorado para realizar um ataque de latência. Os participantes mal-intencionados podem criar uma contestação e conspirar com os validadores L1 para revisar os honestos validadores do Arbitrum, resultando em atrasos de até uma semana para os saques dos usuários do Arbitrum. Nesse caso, os usuários que solicitarem saques durante esse período podem enfrentar custos de oportunidade devido aos fundos bloqueados. Embora este não seja um ataque em que o agressor se beneficia diretamente dos fundos, ainda deve ser prevenido devido aos custos de oportunidade para os usuários. O Arbitrum BoLD está lidando com esse problema ao estabelecer um depósito suficientemente alto necessário para criar uma contestação, a fim de dissuadir esse tipo de ataque.

Arbitrum calculou esse valor no documento econômico em negrito. A principal razão para a latência do protocolo são as revisões dos validadores do L1. No caso de um ataque de latência, a situação se desdobrará da seguinte forma:

O atacante submete uma declaração N' inconsistente com a declaração existente N antes de confirmar em Arbitrum.
O defensor tentou enviar uma transação de divisão, mas essa operação falhou porque os validadores L1 estão revisando a transação de questionamento do defensor.
Devido à suposição de revisão BoLD não pode durar mais de 7 dias, isso pode levar a uma confirmação final de N declaração com uma latência de até uma semana.

Os lucros do atacante vêm do custo de oportunidade gerado ao usuário que questiona a saída da solicitação de saque. No pior cenário, todos os fundos em Arbitrum estão sendo retirados em uma única saída, e o custo de oportunidade suportado pelo usuário é calculado da seguinte forma, supondo que o TVL do Arbitrum One é de 154 bilhões de dólares e o APY é de 5%:

Custo de oportunidade = 15.400.000 x (1,051/52 - 1) = $14.722.400

Devido ao alto custo de oportunidade associado a declarações incorretas, os submisssores de declarações no BoLD são solicitados a depositar uma quantidade semelhante de garantia. Atualmente, o depósito necessário para a submissão de declarações no BoLD é de 3600 ETH, aproximadamente 9,4 milhões de dólares.

Isto é feito para prevenir que os atacantes causem grandes prejuízos ao sistema através da latência. Como os atacantes perderão a sua garantia no caso de questionamento, podem causar um custo de oportunidade de até 1470 milhões de dólares, mas perderão cerca de 940 milhões de dólares. Portanto, o BoLD suprime os ataques de latência exigindo uma garantia que seja proporcional ao custo de oportunidade no pior cenário.

No entanto, o depósito de 3600 ETH não é definido apenas para prevenir ataques de latência. Para defender-se contra ataques de Sybil, o Arbitrum BoLD pode garantir que o sistema permaneça seguro até que o capital total do atacante seja 6,5 vezes o capital total do defensor, daí a base para a determinação do depósito de 3600 ETH.

Do ponto de vista de um ataque de Sybil, as seguintes situações de ataque podem ocorrer no Arbitrum BoLD. O sistema de questionamento do BoLD é composto por três níveis, em que os usuários devem bloquear fundos para submeter as declarações que consideram corretas.

Supondo que o participante honesto Alice envie uma declaração válida no valor de X ETH. O participante mal-intencionado Bob, que possui 3600 ETH, pode criar várias declarações mal-intencionadas. Nesse caso, Alice precisará bloquear Y ETH para cada declaração de Bob em um nível inferior.

No modelo de ramificação do Arbitrum, bloquear fundos significa concordar com o estado da cadeia do genesis para a alegação. Essa característica permite que os participantes movam os fundos que eles apostaram da alegação A para suas sub-alegações A' e A''. Portanto, Alice transfere seus X ETH inicialmente apostados para a camada inferior e bloqueia Y ETH para cada alegação maliciosa de Bob.

O que acontece se Bob tiver claramente mais fundos do que Alice? Bob pode gerar inúmeras declarações maliciosas até que os fundos de Alice se esgotem e ela não possa mais continuar bloqueando. Nesse ponto, Alice não pode mais continuar a bifurcação, permitindo que Bob confirme declarações incorretas.

No fundo, a questão resume-se ao grau em que o defensor deve ser mais vantajoso do que o atacante no jogo.

Arbitrum chama esse indicador de proporção de recursos. Isso mostra a vantagem dos participantes honestos sobre os participantes maliciosos. Essa proporção é representada pela relação entre a taxa de gás (G) e o montante de depósito (S) que cada participante deve pagar, como mostrado abaixo:

O sistema de contestação da BoLD é dividido em três níveis, garantindo que o defensor tenha uma vantagem de N vezes sobre o atacante em todo o sistema, mantendo essa proporção em cada nível. Arbitrum calculou a quantidade de depósito necessária no nível superior com base nessa proporção de recursos e traçou um gráfico.

(Custo de colateral disputado de camada superior em relação à proporção de recursos do Arbitrum BoLD | Fonte:Desmos）

De acordo com o gráfico, quando a relação de recursos é 100 vezes, o depósito exigido para o nível superior é superior a 1 milhão de ETH (mais de 4 trilhões de dólares). Embora uma relação de recursos mais alta torne o sistema mais seguro contra ataques Sybil, o valor do depósito se torna tão alto que quase ninguém pode participar do sistema, tornando-o indistinguível de um sistema centralizado com apenas um validador apresentando declarações.

Portanto, no BoLD, a proporção de recursos é definida como 6,5 vezes, o que faz com que o depósito de garantia de nível superior seja de 3600 ETH, e o depósito de garantia de primeiro e segundo nível seja definido como 555 ETH e 79 ETH, respectivamente.

Em suma, o BoLD calcula a proporção de recursos e define a quantidade de garantia para garantir que o defensor tenha uma vantagem 6.5 vezes maior do que o atacante, a fim de evitar ataques Sybil.

2) Cartesi Dave

Dave da Cartesi propôs pela primeira vez em dezembro de 2022, em um artigo intitulado "Torneio de Avaliação Não-Permissiva", antes do primeiro White Paper do BoLD. O objetivo é manter a vantagem dos participantes honestos em recursos computacionais e financeiros em relação aos atacantes. A estrutura de Dave é semelhante à do BoLD e possui duas características-chave:

Evita a bifurcação mal-intencionada através do cálculo correto do estado de prova (compromisso histórico).

Semelhante ao BoLD, Dave exige que os participantes gerem uma prova durante o processo de divisão binária para mostrar que eles realizaram os cálculos corretamente e, assim, impedir formas maliciosas de divisão. Portanto, o sistema de questionamento de Dave é dividido em vários níveis para economizar recursos dos validadores.

A estrutura do torneio adota um mecanismo de questionamento um a um.

O questionamento de Dave não foi feito de uma só vez, mas sim em forma de torneio, como mostrado na imagem abaixo.

O diagrama acima mostra como as dúvidas são tratadas quando um atacante mal-intencionado apresenta sete declarações incorretas questionando a rede. Devido à natureza dos compromissos históricos, os participantes honestos que apoiam as declarações corretas (indicadas em verde) são agrupados em equipes. No caso de Dave, eles são organizados em um formato de torneio e dispostos conforme mostrado no diagrama, com cada participante se enfrentando em um confronto direto. Os questionamentos da mesma fase são realizados em paralelo e, após uma semana, quando os questionamentos forem concluídos, os vencedores avançam para a próxima fase. No diagrama, a equipe de participantes honestos deve passar por três rodadas de questionamentos para vencer o torneio.

Esta característica é extremamente eficaz na prevenção de ataques Sybil. Em primeiro lugar, o atacante deve criar várias declarações para realizar um ataque Sybil, cada declaração irá consumir significativamente os recursos computacionais e financeiros do atacante.

O documento da Cartesi prova que, em qualquer circunstância, o defensor mantém sempre uma vantagem exponencial sobre o atacante. Em outras palavras, Dave garante que pode se defender de um ataque Sybil usando recursos logarítmicos em relação ao número de atacantes. Isso torna extremamente difícil executar um ataque Sybil em Dave, portanto, o valor de aposta em Dave é definido como um mínimo de 1 ETH, muito abaixo do valor em BoLD.

No entanto, Dave é facilmente atacado pela latência. Cada estágio do torneio consome um tempo de questionamento (uma semana), portanto, quanto mais declarações maliciosas, maior a latência do protocolo. O tempo necessário para resolver completamente uma questão em Dave pode ser expresso pela seguinte fórmula:

Td = 7 x log2(1 + NA)(dias)

Onde NAN_ANA representa a quantidade de declarações maliciosas. No entanto, as dúvidas de Dave podem ser compostas por vários níveis para gerar compromissos históricos efetivos. Aqui, os participantes maliciosos podem gerar NAN_ANA declarações maliciosas em cada nível de dúvida, o que aumentará o tempo total de latência, conforme mostrado abaixo:

Td = 7 x [log2(1 + NA)]L(天数)

O LLL representa o número de níveis em cada contestação. Se, como mostrado acima, houver sete declarações maliciosas e L=2, a resolução completa da contestação pode levar até 9 semanas, e os utilizadores enfrentarão uma latência de levantamento adicional de 2 meses. Se o número de níveis ou o número de declarações maliciosas aumentar, a latência pode estender-se para vários meses.

Cartesi visa resolver esse problema usando a Prova de Conhecimento Zero (ZK), detalhes serão discutidos na seção 4 "Melhorias Viáveis".

3) Prova de falha de otimismo (OPFP)

OPFP é um protocolo de questionamento não autorizado, atualmente em aplicação na Rede principal OP, com as seguintes características:

Usar o mecanismo de questionamento de todos para todos da árvore de jogos

OPFP permite que qualquer pessoa envie saídas (declarações raiz) a qualquer momento. Os validadores que não concordam com as saídas apresentadas podem contestá-las iniciando um processo de bifurcação.

OPFP Estrutura de árvore de jogos e processo de divisão para otimismo | Fonte: Arquivo de otimismo

O processo de divisão ocorre simultaneamente na árvore de jogo mostrada na figura acima. As folhas da árvore representam o estado L2, e cada Nó na árvore corresponde a um estado em L2, com a folha mais à direita representando o estado mais recente de L2. Por exemplo, fazer uma declaração no Nó 1 é equivalente a fazer um estado no Nó 31.

Esta estrutura permite representar a bifurcação. Por exemplo, se um validadores não concorda com a declaração raiz (Nó 1), eles irão submeter a declaração em Nó 2, que corresponde ao Nó 23 na árvore, pois é o ponto médio entre Nó 16 e Nó 31. O remetente de Nó 1 então verifica o estado L2 de Nó 23 e, se concordar, submeterá Nó 6 (Nó 27); se não concordar, submeterá Nó 4 (Nó 19), continuando esse processo até encontrar uma divergência.

Mesmo que haja várias direções binárias em um jogo, elas podem ser realizadas simultaneamente e qualquer pessoa pode participar do processo binário, não apenas o remetente de saída.

A arquitetura completa da árvore de jogos OPFP | Fonte: Arquivo Optimism

A árvore de jogos usada em OPFP é uma estrutura aninhada, onde a árvore de nível superior lida com a divisão binária de bloco, enquanto as subárvores de nível inferior lidam com a divisão binária de instruções.

Ao contrário do BoLD ou Dave, o OPFP não força a execução correta de bifurcações através de compromissos históricos, uma vez que o custo de gerar e submeter tais compromissos fora da cadeia/na cadeia é elevado.

Baseado em um jogo de controvérsia personalizável modular Atualmente, a Rede principal OP só lançou dois tipos de jogos de disputa (não licenciados/licenciados). A Optimism tem como objetivo final introduzir vários tipos de jogos de disputa e já implementou uma interface mínima que suporta esse objetivo. É possível criar jogos de disputa personalizados seguindo os nomes e parâmetros de função especificados.
Restringir o tempo de questionamento através do relógio de xadrez

No OPFP, quando surgem dúvidas, tanto o proponente como o questionador recebem um relógio, que é usado para alocar tempo para bifurcações. Cada vez que uma declaração é feita, o relógio começa a contar para o outro. O Optimism chama isso de "herdar o relógio do avô".

Curiosamente, cada participante tem permissão para ter 3,5 dias em vez de 7 dias, o que significa que se ninguém questionar a saída, ela será finalizada em 3,5 dias.

No entanto, não é permitido fazer retiradas imediatas. Após a saída final ser determinada, há um período de guarda de 3,5 dias para OPFP, durante o qual o comitê de segurança pode intervir e invalidar as saídas incorretas, se necessário.

O processo de saque do usuário no 'Caminho Feliz' | Fonte: OP Labs Blog

Com base nesses mecanismos, OPFP e outros rollups otimistas garantem que os usuários possam sacar pelo menos 7 dias após a submissão. No entanto, em caso de contestação, os usuários podem precisar de mais de 7 dias para sacar através desse output. O modelo de relógio de xadrez do OPFP limita o tempo que cada participante pode gastar no processo de bifurcação, mas não impõe um limite estrito para o tempo total até que a contestação seja resolvida.

Isto levanta uma questão: se houver uma contestação na OPFP, é possível que os levantamentos dos utilizadores sofram uma latência de mais de uma semana, semelhante ao caso do BoLD? A resposta é "sim". Ao contrário do BoLD ou do Dave, a Optimism oferece aos utilizadores a opção de lidar com situações de contestação, com base nas características únicas do protocolo.

OPFP operates on the assumption that "participants who submit incorrect statements will lose their margin". However, there is a corner case in OPFP that breaks this assumption, known as the "free-rider declaration". This situation may occur in the following scenarios:

Alice fez uma declaração de raiz de estado correta.
Bob submitted a counter-declaration, while Alice took action to defend her original statement.
Bob esperou até que seu relógio estivesse quase esgotado (3.5 dias) antes de questionar sua própria declaração.

Neste momento, Alice deveria responder e reivindicar a Margem de Bob, mas ela herdou o tempo restante no relógio de Bob, o que pode não ser suficiente para refutar a afirmação dele. Portanto, Bob pode evitar perder a sua Margem ao apresentar uma 'reivindicação de carona'.

Declaração de Carona no Optimismo à Prova de Falhas | Fonte:L2Beat

Embora isso não impeça que as dúvidas sejam resolvidas corretamente, representa de fato uma situação em que "uma declaração incorreta foi submetida e não foi corteMargem", do ponto de vista do incentivo, essa situação deve ser evitada.

Assim, se o tempo restante do proponente ou do questionador for inferior a 3 horas, o OPFP resolverá o problema redefinindo o relógio para 3 horas. Isso garante tempo suficiente para refutar a declaração de carona. No entanto, se nenhuma ação for tomada durante o próximo período de dois dias e meio, a objeção será encerrada.

Podemos imaginar uma cena, onde este mecanismo é utilizado para realizar um ataque de latência. Suponha que o participante honesto Alice submeta uma saída correta, a contagem de tempo do questionador começa a partir do momento em que Alice submete. O participante malicioso Bob espera até 1 segundo antes do final do tempo do questionador para submeter uma saída incorreta. Neste momento, as regras do OPFP prolongam o tempo de Bob para 3 horas. Alice irá responder, enquanto Bob continuará a aproveitar as 3 horas adicionais fornecidas a cada vez que houver uma divisão.

Isso pode questionar a latência da solução. Bob pode atrasar por um máximo de 3,5 dias + 3 horas × o número máximo de iterações binárias. MAX_GAME_DEPTH para OPFP é 73, o que significa que Bob pode atrasar o processo em 3,5 dias + 3 horas × 36 = 8 dias. Se Alice também adotar medidas semelhantes para atrasar a dúvida, o processo de divisão pode levar 16 dias.

Isto significa que os utilizadores não podem levantar fundos em 16 dias? Na realidade, isso não é verdade, pois a lógica de levantamento da Optimism torna esta situação inviável. Ao contrário do Arbitrum, que exige que os levantamentos sejam comprovados como incluídos num Bloco L2 específico, o OP Stack utiliza um mecanismo de prova de armazenamento, onde os pedidos de levantamento são registados no contrato L2ToL1MessagePasser do L2. Isto significa que mesmo que a contestação de um output específico seja demorada, os utilizadores ainda podem esperar pelo próximo output e efetuar o levantamento com base na raiz de armazenamento do contrato contida nesse output. Assim, mesmo que o Bloco de levantamento solicitado seja contestado, os utilizadores não precisam de passar por longas latências, pois podem utilizar o próximo output.

No entanto, tudo isso só acontece se o usuário agir rapidamente. Na maioria dos casos, os usuários ainda podem experimentar vários dias de latência. Isso pode ser atribuído ao processo de saque na pilha OP, que envolve principalmente os seguintes três passos:

Iniciar o levantamento na L2 (initiateWithdrawal).
Prove a retirada na camada L1 (proveWithdrawalTransaction), incluindo a prova das saídas da retirada.
Aguarde uma semana para que a prova de latência amadureça e, em seguida, finalize a transação de saque (finalizeWithdrawalTransaction).

O ponto chave é que, desde a prova de retirada até a conclusão final da retirada, o usuário deve esperar uma semana. Se Alice provar sua retirada na saída B e houver questionamentos, ela pode enviar outra prova para a saída C e concluir a retirada uma semana depois. Nesse caso, Alice só experimentará latência entre as saídas B e C.

Portanto, os usuários que não perceberem a criação ou responderem tarde às perguntas podem enfrentar até 9 dias adicionais de latência na retirada.

Além disso, no OPFP há também uma latênciaVetor de Ataque adicional, ou seja, cada saída é continuamente questionada. Nesse cenário, os usuários não podem contornar a latência ao provar na próxima saída, resultando em toda a protocolo sendo afetada pela latência. O OPFP lida com isso exigindo que os participantes enfrentem a stakeMargem em cada nível binário, com o valor da Margem aumentando exponencialmente, como mostrado na figura abaixo.

OPFP Margem Montante | Fonte: Optimism Documento

Em outras palavras, quanto mais tempo o atacante tentar questionar a latência no OPFP, maior será o custo de Margem necessário, uma vez que o requisito de Margem é subir exponencialmente, o que reduz o incentivo para realizar ataques de latência ao longo do tempo. Além disso, como as saídas no OPFP podem ser enviadas a qualquer momento, é difícil para o atacante estimar os recursos necessários para realizar um ataque de latência. A Margem inicial é definida como 0.08 ETH, enquanto a Margem total a ser submetida em caso de questionamento abrangente é de cerca de ~700 ETH.

Em resumo, o OPFP deixa a decisão sobre a duração da latência para o usuário em caso de questionamento único e usa requisitos de Margem exponencial para compensar os ataques de latência causados por questionamentos contínuos. No entanto, o OPFP é facilmente suscetível a ataques de Sybil. No OPFP, se o atacante tiver mais fundos do que o defensor, um ataque de Sybil pode ocorrer.

No OPFP, podem existir os seguintes Vetor de Ataque Sybil, todos os quais podem resultar no roubo dos fundos do utilizador:

O atacante cria várias dúvidas, levando o defensor a usar todos os fundos para Margem e taxas de gás.
Os atacantes continuamente enviam saídas incorretas, forçando os defensores a responder até esgotarem seus fundos em Margem e taxas de Gas.

Isso é possível no OPFP, porque durante todo o processo de questionamento, a quantidade total de margem necessária tanto para o atacante quanto para o defensor é praticamente a mesma, e os recursos utilizados pelo defensor (como taxas de gás ou poder de computação) não são significativamente menores do que os do atacante.

No entanto, isso não significa que os fundos dos usuários na Rede Principal OP estejam em risco. O OPFP ainda está na fase 1 e o Comitê de Segurança tem o poder de corrigir qualquer resultado inadequado. Portanto, mesmo em caso de ataques desse tipo, o Comitê de Segurança pode intervir para proteger os fundos dos usuários na ponte da Rede Principal OP.

No entanto, para mover o OPFP para a fase 2, a Optimism deve modificar seu mecanismo para garantir que os defensores tenham uma vantagem maior em relação aos atacantes. A Optimism está preparando o jogo de disputa V2 para resolver esse problema e mais detalhes serão apresentados na seção 4 'Melhorias viáveis'.

4) Prova de falha do Kroma ZK (Kroma ZKFP)

Kroma é uma L2 baseada em OP Stack, que lançou um sistema de prova de falha ZK não licenciado em sua Rede principal em setembro de 2023, antes da introdução do OPFP. O Kroma ZKFP possui características semelhantes ao OPFP, mas se destaca pelo uso de provas ZK para geração de blocos e pelo uso de decomposição em vez de divisão, reduzindo significativamente o número de interações necessárias no processo de desafio. As principais características do Kroma ZKFP podem ser resumidas da seguinte forma:

Reduza o número de interações através de ZK e decomposição.

Kroma ZKFP permite aos participantes encontrar pontos de divergência em quatro interações. Ao questionar, o Kroma ZKFP lida com as dúvidas em 1.800 Blocos, desde as saídas anteriores até as atuais. Ao contrário do método de divisão em dois, em que o intervalo é dividido ao meio, no método de decomposição, o proponente e o questionador dividem o intervalo em N partes. O processo é o seguinte:

Após cada participante enviar duas transações, eles determinarão o Bloco onde há divergências. Os questionadores podem gerar uma prova de falha ZK para demonstrar que a alegação do proponente está errada. No Kroma ZKFP, o timeout de divisão é definido como 1 hora, enquanto o timeout para geração de prova ZK é de 8 horas.

A Descentralização dos validadores é alcançada por meio de um mecanismo de incentivo

BoLD e OPFP incentivam os vencedores das contestações, mas não oferecem incentivos específicos para os submisssores de outputs. Na realidade, qualquer pessoa que queira retirar fundos pode submeter outputs e tornar-se validadores. No entanto, para os utilizadores que desejam retirar fundos, não é prático operar o cliente validador por si próprios e alguém deve submeter regularmente outputs para manter a atividade. Devido a ser uma tarefa intensiva em recursos, é necessário pagar taxas de gás para submeter outputs e operar o cliente validador, portanto, sem incentivos apropriados, apenas algumas pessoas podem participar como validadores, o que pode levar à centralização e à falta de resposta em cenários de falha.

Para isso, a Kroma modificou o OP Stack, distribuindo metade das taxas de gás geradas na cadeia para os validadores de saída. Além disso, a Kroma planeia transitar este mecanismo de recompensa para o seu token nativo KRO após o TGE e pretende introduzir um sistema de validadores semelhante ao DPoS, permitindo que os utilizadores comuns contribuam para a segurança e atividade da cadeia sem executar os seus próprios clientes.

O valor de Margem na Kroma está atualmente definido como 0,2 ETH para garantir que seja superior ao custo de geração de provas de conhecimento zero (ZK) e divisão em metades. Essa Margem será convertida em stake de KRO no futuro sistema de validadores.

Sistema de Desafio 1 contra 1 simultâneo

Para garantir uma distribuição justa e consistente de incentivos, o Kroma fixa o intervalo de submissão de saída em 1 hora e seleciona aleatoriamente validadores da coleção pré-registada de validadores como proponentes. Isso evita o desperdício de taxas de gás devido à competição excessiva e impede que os construtores de blocos que possuem o direito de ordenar transações monopolizem as recompensas.

Devido a esse mecanismo, o Kroma ZKFP opera um sistema de questionamento de 1 para 1 em paralelo. Qualquer pessoa pode questionar quando os validadores selecionados aleatoriamente submetem uma saída, e o questionamento ocorre apenas entre o submissor da saída e o questionador. Vários questionamentos podem ocorrer simultaneamente, e o questionador que primeiro submeter uma prova ZK válida vencerá o questionamento.

O timeout rigoroso significa que mesmo os maliciosos questionadores que tentem realizar um ataque de latência devem completar todas as divisões binárias e geração de prova dentro de 10 horas. Além disso, é impossível realizar um ataque de latência geral no Kroma, pois os questionadores são obrigados a concluir todas as operações em 6 dias (excluindo o período de guarda de 1 dia).

No entanto, se o financiamento do atacante exceder o do defensor, o Kroma ZKFP ainda será vulnerável a ataques Sybil, semelhante ao OPFP. No Kroma ZKFP, a situação de um ataque Sybil pode ser como se segue:

Os atacantes continuam a questionar as saídas válidas até que o financiamento do remetente esteja esgotado, momento em que apresentam uma prova de conhecimento zero (ZK) para ganhar a contestação.

À semelhança do OPFP, o Kroma ZKFP elimina as saídas correspondentes após um desafio bem-sucedido. Portanto, se ocorrer esse tipo de ataque, as saídas podem ser eliminadas, resultando numa latência de levantamento de fundos de 1 hora. Se o ataque continuar, todos os validadores honestos podem ficar sem fundos, levando à confirmação final de saídas incorretas e permitindo assim que o atacante roube os fundos dos utilizadores.

Além disso, o Kroma ZKFP ainda está na fase 0 e o sistema de prova não está perfeito, devido às seguintes razões:

O ponto de partida da bifurcação é baseado na saída da última submissão, não na saída confirmada por último.

No OPFP, o ponto de partida para a bifurcação é geralmente a saída de confirmação mais recente de cerca de uma semana atrás. No entanto, no Kroma ZKFP, o ponto de partida é a saída mais recentemente submetida, que foi submetida cerca de 1 hora atrás, e o processo de bifurcação é realizado em 1.800 Blocos.

Isso pode permitir que os questionadores ganhem a disputa em caso de exclusão de saída anterior devido a questionamentos. Nesse caso, a divisão será baseada nas informações de saída anteriores enviadas pelo questionador e, se eles manipularem maliciosamente essas informações, poderão ganhar a disputa.

Não foi verificado se cada validador questionou com base nos dados corretos do lote.

Embora o Kroma ZKFP use ZK para garantir que, se o circuito ZK não tiver falhas, não seja possível confirmar uma transição de estado errada, o Kroma ZKFP não verifica se a prova ZK gerada é baseada nos dados em lote corretos. Isso significa que, mesmo que algumas transações sejam excluídas ou transações incorretas sejam incluídas no lote, a prova ZK ainda pode ser validada.

Por conseguinte, é possível vencer a controvérsia usando provas de conhecimento zero baseadas em dados errados e, se as transações de levantamento dos utilizadores forem excluídas do lote, os seus levantamentos podem ser latência.

No entanto, na prática, o comitê de segurança pode intervir para retirar os resultados de questionamentos errôneos ou excluir saídas inválidas, portanto, esses Vetor de Ataque não afetarão os fundos dos usuários da Rede principal Kroma. No entanto, para alcançar a Fase 2, o Kroma ZKFP deve implementar mecanismos de defesa contra essas vulnerabilidades. O Kroma propôs melhorias para esses problemas, que serão detalhadas na seção 4, 'Melhorias viáveis'.

3.4 Vetor de Ataque #2：L1 审查

Anteriormente mencionamos que o Rollup herda a segurança do Ethereum. Isso significa que se a segurança do Ethereum for comprometida, o Rollup também será afetado.

Existem duas situações em que a situação do Ethereum pode afetar a segurança do Rollup:

Verificação dos validadores da ETH para transações Rollup de prova de fraude **Se os validadores ou construtores do ETH fizerem conluio, submetendo raízes de saída maliciosas no Optimistic Rollup e revisarem todas as transações relacionadas à prova de fraude, o que acontecerá? As dúvidas podem não ser resolvidas dentro do prazo especificado, as saídas serão confirmadas e os fundos dos usuários podem estar em risco. Isso é chamado de verificação fraca. No caso do Optimistic Rollup, se essa verificação continuar por mais tempo do que o tempo definido (geralmente 7 dias), os fundos do usuário podem estar em risco.
**以太坊遭受 51% 攻击，导致所有prova de fraude交易被审查 **Esta situação envolve duas possíveis vias de ataque:

Primeiro, uma entidade pode obter mais de 2/3 do total staking do Ethereum, o que lhes permitirá confirmar os Blocos à vontade. Neste caso, um atacante pode rever as transações de prova de fraude e até mesmo gerar essas transações à vontade.
O segundo método envolve um atacante com mais de 1/3 de stake total do Éter Bloco realizando um ataque "silencioso". Isso é descrito na pesquisa sobre "Ataques de censura não atribuíveis baseados em prova de fraude em protocolo L2". Neste cenário, um atacante com 1/3 de stake do Éter Bloco pode impedir a confirmação de qualquer Bloco que não gostem. Se o atacante continuar a votar em Bloco normais, enquanto permanece em silêncio sobre Bloco que contenha prova de fraude, eles podem confirmar uma raiz de saída maliciosa, roubando fundos do Optimistic Rollup. Isso é conhecido como um ataque de censura não atribuível contra protocolo L2 baseado em prova de fraude, sendo mais difícil de detectar do que simplesmente obter mais de 2/3 de stake e controlar todos os Blocos do Éter.

Estes ataques baseados em revisão são difíceis de lidar no nível do Rollup, pois ocorrem no nível do protocolo Ethereum, requerendo melhorias no próprio Ethereum. No entanto, durante este período, o Rollup pode adotar algumas estratégias.

3.5 Solução #2: Recuperação de Retirada em 7 Dias de latência e Ataques de 51% Semiautomatizados

Para lidar com esses Vetor de Ataque, o Optimistic Rollup atualmente implementou uma latência de retirada de 7 dias. Este período de 7 dias foi inicialmente proposto por Vitalik, com base na ideia de que 7 dias são "suficientes" para lidar com ataques de revisão.

Vamos analisar se o período de 7 dias de questionamento do Optimistic Rollup é suficiente para resistir a ataques de censura, considerando dois tipos de censura: ataque de censura fraco e forte.

Para o primeiro tipo de auditoria fraca, podemos usar cálculos de probabilidade para verificar se 7 dias de tempo concedem à Optimistic Rollup a capacidade de resistir a ataques de auditoria. Isso envolve o cálculo da probabilidade de sucesso de questionar a fraude quando alguns validadores questionam transações de Rollup.

Aqui, é necessário considerar dois fatores:

Para contestar com sucesso dentro de 7 dias, várias transações devem ser bem-sucedidas.

Na maioria dos protocolos, se apenas uma transação de um participante honesto for incluída nesta semana, a contestação não terá sucesso. Portanto, precisamos calcular a probabilidade de todas as transações necessárias para submeter a prova de fraude serem incluídas em 7 dias.
É necessário fazer suposições razoáveis sobre a proporção de validadores envolvidos na auditoria. Atualmente, a maioria dos construtores de blocos de zona ETH (conhecidos por serem centralizados) não foram validados, considerando a proporção de validadores individuais na zona ETH, a chance de conspiração da maioria esmagadora (por exemplo, 99,9%) para validação é praticamente zero.

Revisão dos principais construtores de Bloco ETH | Fonte: Tweet de Justin Drake

Tendo em conta estes dois pontos, se assumirmos que 99,5% dos validadores (ainda assim, uma suposição demasiado extrema) participam na revisão e calculamos a probabilidade de os participantes honestos com sucesso enviarem 30 a 40 trocas de exchange necessárias para questionar o protocolo (como BoLD ou OPFP), então, em todas as situações, a probabilidade de sucesso é quase 100%. Além disso, com o surgimento de soluções futuras (como a inclusão de listas ou múltiplos proponentes simultâneos, como BRAID, APS + FOCIL), a capacidade de resistir à revisão pode ser ainda mais reforçada, reduzindo assim o risco de o Gota Optimistic Rollup perder fundos dos utilizadores devido a revisões fracas.

Então, em um ambiente de forte censura, 7 dias são suficientes? O ataque de 51% mencionado anteriormente só pode ser resolvido por meio de forks sociais. Ataques de censura não atribuíveis são especialmente difíceis de detectar e não podem ser evitados por soluções projetadas para censura fraca (como a inclusão em listas).

Uma proposta é desenvolver uma ferramenta de recuperação de ataque de 51% semi-automática no software do cliente, que se baseia na estrutura proposta por Vitalik. Os pesquisadores do Ethereum desenvolveram ainda mais essa solução de detecção e revisão, que é dividida em dois passos:

O cliente ligeiro monitoriza a mempool, verificando se algum tempo de transação não incluída no Bloco é demasiado longo.
Se uma transação específica permanecer na pool de memória por um dia e não for incluída num Bloco, será acionado o botão 'Você concorda com a bifurcação social?' para permitir que a comunidade inicie uma bifurcação rígida com base nesse consenso.

Supondo que a ferramenta detecta um ataque de 51%, o próximo passo seria transferir para uma nova cadeia na cadeia através de uma forquilha social, tornando assim os fundos do atacante inválidos.

Neste caso, os fundos afetados por um ataque de 51% devem permanecer bloqueados até que a forquilha social seja concluída. Durante o Hard Fork do DAO, uma situação semelhante ocorreu, com os fundos do Hacker bloqueados na sub-DAO por 27 dias, até que pudessem ser retirados. Nesse período, a comunidade Ethereum realizou com sucesso o Hard Fork, impedindo o Hacker de retirar os fundos (para mais detalhes, consulte o post de Vitalik no Reddit).

Em outras palavras, mesmo em caso de ataque de 51%, os fundos precisam permanecer bloqueados até que ocorra a forquilha social. Neste cenário, o período de retirada de 7 dias do Optimistic Rollup atua como um buffer. Se a forquilha social não ocorrer durante esta semana, os fundos dos usuários no Optimistic Rollup podem ser roubados, retirados para uma exchange centralizada, ou misturados através do Tornado Cash, resultando em uma quase impossibilidade de devolução dos fundos aos usuários após a forquilha social.

Em resumo, embora o período de retirada de 7 dias no Optimistic Rollup tenha sido originalmente concebido para lidar com a fraca revisão, na realidade, a probabilidade de uma revisão fraca é baixa, e esse período de 7 dias atua como um período de buffer em caso de necessidade de forquilha social sob revisão forte.

Sob essa perspectiva, alguns criticaram o OPFP por reduzir o prazo para 3,5 dias, tornando-o mais suscetível a ataques de revisão rigorosa. No entanto, essa crítica não tem fundamento. Como o Optimism ainda está na fase 1, os guardiões têm um período de buffer suficiente para verificar a correção da raiz de estado, e os saques só podem ser feitos após o término do período adicional de 3,5 dias. Portanto, mesmo em caso de ataque de revisão rigorosa, os atacantes ainda precisariam esperar 7 dias para sacar. Além disso, os atacantes também teriam que revisar todas as transações relacionadas à dúvida durante uma semana inteira para ter sucesso, já que os guardiões também precisam ser revisados para evitar que interrompam a confirmação de saídas maliciosas.

No entanto, a chave é que o Ethereum deve garantir que possa processar uma forquilha social em 7 dias. Isso significa que as ferramentas de detecção de ataques de 51% devem estar prontas e é necessário realizar pesquisas e simulações completas para determinar se a forquilha social pode ser implementada em 7 dias. Somente nesse caso, a latência de saque de 7 dias no Optimistic Rollup pode ser considerada uma garantia efetiva.

3.6 Vetor de Ataque #3：利用prova de fraude系统中的漏洞

A maioria dos protocolos questiona, fazendo com que os participantes encontrem um ponto específico (instrução ou bloco) onde suas opiniões divergem e, em seguida, gerem uma prova de que a afirmação de outro participante está errada. A Máquina Virtual usada para gerar essa prova é chamada de Máquina Virtual de prova de fraude, enquanto o software usado nessa Máquina Virtual para gerar a prova é chamado de programa. Cada protocolo usa uma Máquina Virtual de prova de fraude e um programa diferentes, conforme mostrado abaixo:

Cada sistema de prova de fraude é projetado para provar que um resultado de execução específico na EVM está correto na cadeia. No entanto, o que acontece se houver uma vulnerabilidade no sistema (seja na máquina virtual ou no programa)?

Esta questão pode ser discutida através do Vetor de Ataque descoberto por Yoav Weiss no OVM. Devido a uma falha na funcionalidade de Reversão do OVM, os ataques tornam-se possíveis, mas é crucial criar transações fraudulentas para executar o ataque. As transações fraudulentas são transações executadas normalmente no Rollup, mas que produzem resultados diferentes quando questionadas usando a Máquina virtual prova de fraude. Uma vez que o sistema prova de fraude deve produzir os mesmos resultados que o EVM, a capacidade de criar transações fraudulentas indica uma falha no sistema prova de fraude.

Yoav descobriu várias vulnerabilidades no sistema de prova de fraude da OVM e foi capaz de simular o ataque gerando transações fraudulentas. Um exemplo simples de ataque que ele descobriu é: no StateManager da OVM, o custo de gás para SSTORE e SLOAD (usado para armazenar e ler o estado) foi registrado incorretamente. Isso significa que qualquer transação que armazene ou leia valores no contrato (quase todas as transações, exceto transferências ETH simples) será identificada como uma transação fraudulenta durante o processo de questionamento, mesmo que seja executada corretamente no Rollup.

Em resumo, se houver vulnerabilidades no sistema, a mudança de estado correta pode ser incorretamente marcada como inválida durante o período de questionamento, resultando em saídas enviadas por participantes honestos sendo marcadas como incorretas.

Esta é também uma das razões pelas quais a OP Mainnet recentemente mudou seu sistema de prova de falhas de um modo sem permissão para um modo em que apenas os participantes autorizados podem entrar. Após a aplicação do OPFP na Rede principal, uma auditoria de segurança revelou várias falhas no sistema de prova de fraude (Cannon e op-program) e em desafios de jogos controversos no protocolo. Para evitar a exploração do sistema, a Optimism anunciou em 17 de agosto a transição para um sistema de permissões.

Claro, o uso de vulnerabilidades de Máquina virtual em Rollups em fase 0 ou fase 1 pode não ter um impacto significativo, pois o Security Council pode intervir a qualquer momento para corrigir os resultados questionáveis. Esta é uma visão anteriormente proposta pela OP Labs. Na verdade, a OP Labs compartilhou seu framework de auditoria no fórum do Optimism, que esboça os critérios para quando uma auditoria externa é necessária, Optimism Forum.

(Estrutura de Auditoria da OP Labs | Fonte: Fórum Optimism)

No âmbito deste quadro, as circunstâncias mais recentes pertencem ao quarto quadrante: 'Prova de falha na fase auxiliar'. Embora essas circunstâncias estejam relacionadas à segurança da cadeia, elas não afetam diretamente os fundos dos usuários e, portanto, não estão incluídas no escopo da auditoria. Isso significa que mesmo que uma vulnerabilidade seja explorada, o Comitê de Segurança ainda pode corrigir o resultado.

No entanto, uma vez que as falhas foram identificadas, é necessário resolver esses problemas. O Optimism corrigiu esses problemas durante a atualização da sua rede Granite, permitindo que a OP Mainnet volte à fase 1.

Por outro lado, as falhas no sistema podem ser fatais no Rollup da Fase 2. Na Fase 2, o comité de segurança só pode intervir em caso de falhas que possam ser comprovadas na cadeia. Como é praticamente impossível provar 'o resultado da contestação é errado devido a uma falha no sistema' na cadeia, os fundos dos utilizadores podem estar em risco se ocorrer uma falha no Rollup da Fase 2.

3.7 Solução #3: Prova múltipla

Para evitar tais problemas, é crucial realizar uma auditoria completa antes de colocar o código em produção. No entanto, prova de fraude, Máquina virtual e programas são sistemas de software complexos e quanto mais complexo o sistema, maior é a possibilidade de falhas. Portanto, mesmo após uma auditoria rigorosa, as falhas ainda podem ocorrer. Precisamos explorar estratégias adicionais além da auditoria.

Uma forma é usar vários sistemas de prova no mesmo sistema. Durante a contestação, o sistema não gera apenas uma prova de fraude usando um único sistema, mas pode gerar várias provas de fraude ao mesmo tempo usando diferentes Máquinas virtuais e programas, e depois comparar os resultados. Isso criará um sistema seguro, mesmo em caso de falha.

Por exemplo, imagine um sistema de prova múltipla usando simultaneamente o Cannon da Optimism e a Máquina virtual de prova de falha ZK asterisc (usando Risc-V). Em caso de questionamento, as seguintes situações ocorrerão:

Se um erro for detectado na saída, o questionador gera uma objeção e inicia um processo de divisão em duas partes.
Assim que um Bloco de divergência for encontrado usando o método de divisão, dois sub-jogos serão desencadeados ao mesmo tempo:

Subjogo de Cannon que utiliza o método tradicional OPFP. Gere subgames de prova de falha ZK usando asteriscos.

Após a conclusão de dois jogos diferentes, serão verificadas duas provas diferentes de fraude.

Se ambas as provas forem validadas, o questionador vence; se ambas as provas falharem, o questionador perde. No entanto, se uma for validada e a outra não, isso indica uma falha inesperada em uma máquina virtual ou programa durante o processo de geração de provas.

Nesse caso, entidades como o Comitê de Segurança irão intervir para ajustar os resultados questionáveis. Isso garante que o sistema possa permanecer sem falhas, ao mesmo tempo em que não viola a condição de que o Comitê de Segurança só pode intervir em casos de falhas que possam ser comprovadas na cadeia.

Este é um dos esforços contínuos para levar o Optimism à Fase 2. Para apoiar isso, o jogo de controvérsia OPFP envolve a criação de sistemas modulares que permitem a implementação de vários sistemas de prova de fraude e definem uma interface mínima para suportar esse objetivo.

4. Melhorias Viáveis

Nas secções anteriores, explorámos o design do protocolo Optimistic Rollup e as possíveis vulnerabilidades durante a sua contestação e processo de verificação de fraude. Esta secção irá discutir os problemas e soluções de cada protocolo, bem como o sistema de verificação de fraude e o futuro do Optimistic Rollup.

4.1 Espaço de melhoria de cada protocolo

1) Arbitrum BoLD

BoLD tem um protocolo de economia sólida, pois limita a latência máxima do protocolo a uma semana e garante proteção eficaz contra ataques Sybil antes que os fundos do atacante excedam 6,5 vezes os do defensor. No entanto, o BoLD possui dois problemas significativos:

6.5 vezes a vantagem dos defensores é muito pequena.
O depósito de garantia para a declaração raiz é de 3.600 ETH, o que é um valor muito alto.

O primeiro problema pode ser resolvido usando a tecnologia ZK. O BoLD divide as questões em vários níveis para reduzir os recursos necessários para o cálculo de compromissos históricos. Com o uso do ZK, isso pode ser reduzido a um único nível.

Este conceito é semelhante à proposta BoLD++ apresentada por Gabriel da Cartesi. Quando as dúvidas são divididas em vários níveis, aumentar a proporção de recursos resultará em um aumento exponencial do tamanho do depósito no nível mais alto. No entanto, ao usar um único nível, é mais fácil aumentar a proporção de recursos, tornando o protocolo mais resistente a ataques de Sybil.

A segunda questão, que é a necessidade de um depósito de 3.600 ETH, é ainda mais difícil de resolver. O tamanho do depósito do BoLD não é apenas para lidar com o ataque Sybil, mas também para dissuadir ataques de latência. O tamanho do depósito é uma função do TVL (valor total bloqueado), e mesmo com o uso de ZK, não é possível reduzir significativamente a latência. Para resolver este problema, o BoLD está implementando um mecanismo de depósito pool, permitindo que vários participantes compartilhem o depósito.

2) Cartesi Dave

Dave, através da sua estrutura de torneios, lidou eficazmente com ataques Sybil, mas, como mencionado anteriormente, é suscetível a ataques de latência. O tempo máximo de latência é uma função do número de declarações maliciosas NA e do nível de stake L, cuja fórmula de cálculo é: Td = 7 x [log2(1 + NA)]L(天数)

Se NA = 7 e L = 3, o protocolo pode enfrentar uma latência de até quatro meses, o que traz inconvenientes e perdas significativas aos usuários, pois a retirada estará sujeita a latência.

ZK pode ajudar a mitigar esse problema. Ao fixar o nível L como 1 (como na linha BoLD++), o tempo máximo de latência pode ser reduzido para: Td = 7 x log2(1 + NA)(dias)

Segundo relatos, a Cartesi está a usar a tecnologia ZK do RISC Zero para esta melhoria. No entanto, persistem preocupações sobre se esta melhoria é suficiente para prevenir totalmente os ataques de latência. Se NA = 7, o protocolo pode ainda enfrentar uma latência adicional de até duas semanas, enquanto o custo para o atacante é apenas um depósito de 7 ETH, mais as taxas de gás e os custos de compromissos históricos fora da cadeia. Para cadeias de alto valor de Posição de bloqueio, esta penalização pode não ser suficiente para dissuadir os ataques de latência.

(Dave: mecanismo de questionamento de sub-provas com estilo BoLD | Fonte: L2Beat Medium)

Há uma sugestão para que o Dave adote um mecanismo de questionamento no estilo BoLD, com competições de 8 participantes por rodada, em vez de duelos 1 contra 1, semelhantes a torneios tradicionais. Nesse caso, a fórmula de cálculo para a latência é:

Td = 7 x log8(1 + NA)(dias)

Nessa estrutura, o atacante precisa fornecer pelo menos 64 ETH de margem para questionar a latência por mais de duas semanas, com uma exigência total de margem de 64 ETH e assumir custos significativos na cadeia e fora da cadeia.

No entanto, a desvantagem deste método é que enfraquece a vantagem do defensor ao enfrentar um ataque Sybil. Embora o BoLD forneça uma estrutura em que o defensor tem uma vantagem N vezes maior que o atacante, Dave criou uma vantagem exponencialmente maior para o defensor em relação ao atacante.

Em resumo, Dave pode limitar eficazmente o vetor de ataque de prova de fraude ZK para reduzir a latência. Embora a estrutura semelhante ao BoLD possa aumentar a capacidade de resistência ao ataque de latência, isso pode resultar em uma vantagem Gota para o defensor ao enfrentar um ataque Sybil.

3) Prova de falha de otimismo (OPFP)

A desvantagem do OPFP é que ele é facilmente atacado por Sybil, porque o custo do atacante e do defensor é o mesmo. O OP Labs propôs uma solução para este problema em Jogo V2 disputado.

Ao contrário do OPFP original, que exige que a Margem seja apresentada a cada divisão, o jogo de disputa V2 só exige que os participantes apresentem a Margem no início da divisão. Além disso, o jogo de disputa V2 introduz o método de divisão, permitindo que os participantes apresentem várias solicitações ao mesmo tempo no ponto de divisão, reduzindo assim o número de interações na maioria dos casos.

（Declaração de ramificação no Jogo de Controvérsia V2 | Fonte: Optimism Specs GitHub）

No OPFP anterior, os vetores de ataque Sybil incluem:

Criar uma grande quantidade de dúvidas para esgotar os fundos de Margem e taxas de Gas dos defensores.
Continuamente submeter saídas falsas, forçando o defensor a reagir e esgotar seus recursos.

A introdução de declarações de ramificação resolveu esses dois problemas de vetores. Em primeiro lugar, os participantes honestos não precisam fornecer margem adicional durante o processo de bifurcação, enquanto os questionadores maliciosos devem fornecer margem de garantia para cada nova pergunta que criam. Se o valor da margem for definido adequadamente, a criação em massa de questionamentos por parte de um atacante se torna insustentável.

Além disso, no jogo de disputa V2, o valor de Margem em um nível mais alto é maior, portanto, o custo de enviar constantemente saídas falsas é maior para o atacante do que para o defensor.

Portanto, o OPFP pode lidar efetivamente com ataques Sybil, introduzindo declarações de ramificação no V2 do jogo contestado.

4）Kroma ZK Fault Proof (Kroma ZKFP)

Kroma ZKFP enfrenta dois grandes desafios: a vulnerabilidade aos ataques Sybil e um sistema de prova incompleto. Para progredir para a fase 1, a Kroma ZKFP precisa resolver os seguintes dois problemas:

O ponto de partida do método de divisão é baseado na saída final submetida, não na saída final determinada.
validadores未验证质疑是否基于正确的批量数据。

O projeto Kroma planeia mudar do Halo2 zkEVM do Scroll para o zkVM Succinct SP1 para resolver esses dois problemas e avançar para a fase 1.

Kroma is expected to modify its dispute process to align with the dispute game interface of Optimism. This adjustment is detailed in Kroma's standards and will allow the starting point of the binary to move to the last confirmed output one week ago, thus addressing the first issue.

Para a segunda questão, o Kroma usará inferência sem confiança baseada em ZK. O processo específico é o seguinte:

(Derivação completa sem confiança para o jogo de disputa de conhecimento zero usando ZK | Fonte: Lightscale Notion)

Imagine, queremos provar que um Bloco T L2 específico está a ser executado corretamente. Antes de gerar a prova ZK, temos de verificar se os dados da transação Bloco T são construídos corretamente com base nos dados em lote L1.

Aqui, a Kroma pretende verificar por ZK se os dados em lote foram extraídos corretamente do L1. Se os dados forem obtidos apenas por um RPC confiável fora do programa ZK, não é possível confirmar se os dados em lote foram adulterados. A conectividade da prova ZK gerada por Blocohash pode ser usada para verificar se o programa acessou o Bloco correto e extraiu os dados em lote, desde Bloco O (fonte L1 do Bloco T L2) até Bloco C (Bloco L1 criado quando a disputa é apresentada). Se o questionador construir o Bloco T do L2 com dados em lote incorretos, o Blocohash do L1 referenciado pela extração dos dados em lote do questionador será diferente do Blocohash real que contém os dados em lote (incluindo T1) e também não está conectado ao Bloco C. Portanto, desde que não haja conflito de hash, a verificação ZK da conectividade do Bloco L1 pode provar que o questionador construiu o Bloco L2 com os dados em lote corretos.

Kroma planeia usar a verificação ZK para a precisão dos dados em lote, o que pode verificar a conectividade do hash Bloco L1 de L1 para C. Se os questionadores construírem o Bloco T L2 com base em dados em lote incorretos, o hash Bloco L1 que eles citam será diferente do Bloco L1 correto que contém os dados em lote e não se conectará ao Bloco C. Como não há conflito de hash, o processo de questionamento pode usar esse método para verificar os dados em lote corretos.

Através destas melhorias, o Kroma ZKFP será capaz de avançar para a fase 1. No entanto, para alcançar a fase 2, o Kroma precisa de soluções adicionais para evitar ataques Sybil, incluindo a mudança do protocolo de questionamento para Todos-contra-Todos (All-vs-All) e redesenhar o mecanismo de Margem.

4.2. Resumo

5. O futuro da prova de fraude

5.1. Fase 2 Rollup - Seu dinheiro está seguro

Como mencionado acima, o Optimistic Rollups está avançando para a Fase 2. A Arbitrum está trabalhando duro para implementar a Fase 2 com base no BoLD. O plano de implementação do BoLD já foi lançado no fórum de governança e recebeu grande apoio, atualmente implantado na rede de testes. Se não houver problemas de segurança significativos, a Arbitrum provavelmente implementará a Fase 2 através do BoLD até o final deste ano.

Optimism também está trabalhando para alcançar a Fase 2. Para que o OP Rede principal atinja a Fase 2, é necessário concluir o Disputa Game V2 e ter suporte para múltiplas provas. Embora os padrões ainda estejam sendo aprimorados, o Disputa Game V2 resolveu efetivamente as fraquezas do OPFP existente, oferecendo uma defesa robusta contra ataques Sybil, aproximando-se assim da Fase 2. Além disso, várias equipes, incluindo OP Labs, Succinct, Kroma e Kakarot, estão ativamente desenvolvendo múltiplas provas, investindo recursos significativos em pesquisa e desenvolvimento para criar uma variedade de métodos de prova para OP Stack. Portanto, a menos que ocorram problemas significativos, a Optimism também espera avançar para a Fase 2 no primeiro semestre do próximo ano.

A transição desses dois Rollups para a Fase 2 pode ter um impacto significativo no ecossistema Rollup. Arbitrum e Optimism têm suas próprias estruturas de Rollup, chamadas Arbitrum Orbit e OP Stack, respectivamente. A transição para a Fase 2 significa que todos os Rollups que utilizam essas estruturas também podem migrar para a Fase 2.

Portanto, do final deste ano até o próximo ano, os principais Rollups com uma base de usuários robusta, como Arbitrum, OP Rede principal e Base, deverão fazer a transição para a Fase 2, herdando a segurança completa do Ethereum. Isso provavelmente irá acalmar críticas como "Rollup é apenas multi-assinatura" ou "Rollup pode retirar seu dinheiro a qualquer momento".

5.2. ZK prova de fraude是未来

A maioria dos protocolos discutidos pode beneficiar da implementação de ZK prova de fraude. Por exemplo, aplicar ZK ao Arbitrum BoLD pode aumentar a taxa de recursos, tornando-a mais resistente a ataques de Sybil, enquanto o Cartesi Dave pode torná-la menos suscetível a ataques de latência. A OPFP também está a desenvolver o ZK para apoiar sistemas de prova múltipla, o que pode reduzir o montante de Margem e aumentar a segurança do protocolo.

É importante notar que o ZK prova de fraude não apenas significa redução da interação entre validadores. Menos interação significa uma significativa redução de recursos necessários pelos validadores, o que possibilita uma maior participação no protocolo. Além disso, isso também reduz a latência máxima possível e melhora a segurança geral do protocolo.

Desta forma, a prova de fraude ZK desempenha um papel fundamental na segurança e descentralização da Optimistic Rollup.

5.3. Como o ZK Rollup se comporta? A prova de fraude vai enfraquecer?

Neste momento, alguns leitores podem perguntar: Se a prova de fraude e o mecanismo de questionamento forem tão complexos, os Rollups ZK seriam uma escolha melhor? Até certo ponto, isso está correto. Nos rollups ZK, a fase 2 não requer consideração de fatores econômicos complexos, os fundos dos usuários não correm o risco de serem roubados durante os eventos de auditoria L1 e os usuários podem retirar seus fundos em algumas horas.

A transição dos Rollups Otimistas para os Rollups ZK pode ser mais rápida do que o esperado. Isso ocorre porque as principais desvantagens dos Rollups ZK - alto custo e tempo de geração de prova - estão melhorando rapidamente. Recentemente, a Succinct Labs lançou o OP Succinct, uma versão ZK baseada em OP Stack que oferece um framework fácil para iniciar os Rollups ZK.

OP Succinct Introduction | Source: Succinct Blog

No entanto, ainda existem alguns fatores a serem considerados. Primeiro, o custo. No OP Succinct, o custo de gerar um bloco de prova é de cerca de $0.005-$0.01, enquanto o custo estimado de operar um verificador é de $6,480 a $12,960 por mês. Se a taxa de processamento de transações (TPS) da cadeia for alta, esses custos podem aumentar ainda mais.

(Custo de prova de trabalho de cada rede | Fonte: blog Succinct)

Por exemplo, na rede Base do OP Succinct, o custo médio de geração de prova de cada Bloco é de cerca de $0.62. Com base nesse número, o custo mensal será de $803,520. Este é um custo adicional que os Optimistic Rollups não têm, mesmo que o custo do ZK seja Gota, os custos operacionais do ZK Rollups sempre serão mais altos do que os Optimistic Rollups.

A segunda consideração é o impacto na descentralização. Nos ZK Rollups, os validadores precisam executar um verificador de prova, o que é mais difícil e caro do que executar um programa de prova de fraude em Rollups otimistas. Além disso, devido à geração lenta de prova no sistema ZK, os usuários não podem verificar as transações em tempo real. Embora os requisitos de hardware mais altos possam melhorar a velocidade de geração de prova para corresponder à velocidade de execução de transação, isso significa que a execução do verificador de prova requer um ambiente de computação de alta qualidade. Idealmente, qualquer um deveria poder executar um Nó para garantir a segurança da cadeia, mas o ZK ainda não atingiu esse nível.

Finalmente, os Rollups ZK são baseados em matemática e criptografia altamente complexas, essa complexidade está além do alcance da prova de fraude e do protocolo de questionamento. Portanto, o sistema ZK precisa ser extensivamente testado antes de poder ser usado com segurança em produção.

Arbitrum está a buscar um protocolo híbrido que combina os métodos ZK e Optimistic como seu objetivo final. Este protocolo opera principalmente como um Optimistic Rollup, gerando provas ZK apenas quando é necessário para saques rápidos. Isso é muito útil para cenários que exigem reequilíbrio rápido de fundos entre cadeias (como exchange ou pontes de cadeia cruzada) e também ajuda a alcançar a interoperabilidade entre cadeias.

Em suma, o método Optimistic Rollup parece ser eficaz no momento, ao mesmo tempo que adota o ZK como um híbrido. No entanto, à medida que o custo e a velocidade da geração de provas ZK continuam a melhorar, mais Optimistic Rollups podem considerar seriamente a transição para o ZK no futuro.

5.4. A prova de fraude só se aplica ao Rollup?

Já estudamos a tecnologia Optimistic Rollups do Ethereum e seu mecanismo de prova de fraude. Então, quais são os outros cenários de aplicação dessa prova de fraude?

再stakeprotocolo prova de fraude pode ser usada ativamente no protocolo de stake. Vamos tomar como exemplo o Eigenlayer, que é um serviço representativo de re-stake na rede ETH.

Eigenlayer é um serviço que permite garantir a segurança do Ethereum alugando ETH através de staking. No Eigenlayer, os operadores podem depositar ETH ou LST dos usuários com base nos contratos de delegação dentro do Eigenlayer e participar da validação selecionando vários AVS (serviços de verificação ativa). Com o Eigenlayer, os protocolos podem facilmente construir AVS e reduzir o custo inicial de introdução de validadores.

Como qualquer outra blockchain, o AVS recompensa os operadores que verificam com sucesso e deve puni-los se tiverem comportamento malicioso. É aqui que a prova de fraude pode ser usada no processo de corte.

Exemplo de corte AVS | Fonte: Eigenlayer GitHub

No exemplo do ponte AVS. A premissa do ponte AVS é a transferência correta dos fundos do usuário para a cadeia de destino, e qualquer operador que manipule maliciosamente as transações deve ser sujeito a corte. Em caso de tal manipulação, os questionadores que descobrirem comportamento inadequado podem criar uma disputa com prova de fraude no contrato de resolução de disputas, alegando que o operador agiu indevidamente na operação do ponte. Se a prova de fraude for considerada válida, o AVS pode invocar o contrato de corte no Eigenlayer para suspender quaisquer recompensas do operador.

Apesar de a funcionalidade XY ainda não ter sido implementada no Eigenlayer, eles recentemente anunciaram o modelo de segurança partilhado, planeando incluir a funcionalidade XY na próxima versão. Isso permitirá que a prova de fraude seja utilizada para XY.

Camada de Disponibilidade de Dados** prova de fraude também pode ser usada na camada de disponibilidade de dados (DA). Um exemplo representativo é o prova de fraude proposto e implementado pela Celestia. A Celestia tem uma tecnologia que permite que nós de luz verifiquem se os dados são armazenados corretamente com base na amostragem da disponibilidade de dados. Vamos entender cuidadosamente esse conceito.

Os clientes leves devem ser capazes de verificar se um bloco foi validado pela maioria (mais de 67%) dos validadores sem baixar todos os dados da cadeia de blocos. No entanto, é difícil para os clientes leves verificar todas as assinaturas dos validadores para cada bloco e isso se torna quase impossível com o aumento do número de validadores.

Nesse aspecto, Celestia apresentou um conceito interessante. No Celestia, mesmo que a maioria dos validadores sejam mal-intencionados, foi proposto um método que permite que um único nó completo honesto informe ao cliente leve a recusa de um bloco defeituoso. Esse único nó completo honesto pode garantir sua 'honestidade' por meio de prova de fraude.

Existem dois tipos de prova de fraude no Celestia:

Transição de estado prova de fraude

Em primeiro lugar, o trabalho prova de fraude dos dados funciona da seguinte forma: Celestia permite que nós leves verifiquem se os validadores possuem os dados corretos sem baixar diretamente todos os dados dentro do bloco. Para realizar isso, Celestia utiliza uma técnica chamada Amostragem de Disponibilidade de Dados (Data Availability Sampling, DAS).

Amostragem de disponibilidade de dados do Celestia | Fonte: Documento Celestia

Os validadores do Celestia estruturam os dados da transação em uma matriz k x k e, em seguida, os expandem para uma matriz 2k x 2k usando a técnica chamada codificação de Reed-Solomon 2D. Em seguida, eles calculam um total de 4k Raiz Merkle para cada linha e coluna, e incluem os resultados do hash dessas Raiz Merkle no cabeçalho do bloco e os propagam.

Apenas com as informações de Raiz Merkle no cabeçalho de bloco, um nó de luz pode verificar se os validadores da Celestia possuem os dados corretos. O nó de luz solicita dados de pontos aleatórios de uma matriz 2k x 2k, ao mesmo tempo em que obtém Raiz Merkle correspondentes às linhas e colunas dos validadores. Se esses dados puderem ser verificados com os valores no cabeçalho de bloco, então os validadores podem ser confiáveis para possuir os dados corretos.

No entanto, surgiu um fator importante a considerar: e se os validadores executarem maliciosamente a codificação de Reed-Solomon? Celestia resolve este problema implementando um mecanismo chamado "prova de fraude de codificação ruim". Se durante o processo de recuperação do Bloco, os nós completos da Celestia descobrirem que a codificação está incorreta, eles gerarão uma prova de fraude contendo a altura do Bloco, a parte da codificação incorreta e a prova de falha, e a transmitirão para os nós leves. Os nós leves verificam essa prova para confirmar que os dados estão realmente codificados de forma incorreta, interrompendo assim o uso de dados incorretos.

Além disso, o Celestia propôs um mecanismo de prova de fraude de transição de estado.

Arquitetura da Celestia Bloco | Fonte: Contribution DAO Blog

A estrutura do Bloco do Celestia inclui dados de rastreamento de transações em intervalos de tempo. Isso permite que todos os nós construam facilmente prova de fraude, enquanto os nós leves podem detectar transições de estado incorretas sem executar o Bloco inteiro. No entanto, devido a problemas de complexidade, esse mecanismo ainda não foi implementado na Rede principal do Celestia.

Em resumo, a prova de fraude na camada de disponibilidade de dados pode filtrar dados e transições de estado incorretos sem depender do consenso.

Aprendizado de Máquina Inteligência artificial e blockchain tornaram-se temas populares em 2024, e houve uma grande quantidade de pesquisa e desenvolvimento neste campo. Um dos aspectos mais notáveis é a combinação de blockchain e aprendizado de máquina.

A principal razão para aplicar a aprendizagem automática à blockchain é a seguinte:

Fiabilidade dos dados：A cadeia de blocos gere os dados de forma descentralizada, registando todas as transações de forma aberta e transparente. Se um modelo de aprendizagem automática aprender a partir dos dados da cadeia de blocos, a fiabilidade da origem dos dados é reduzida, diminuindo a possibilidade de adulteração.
Transparência e verificabilidade do modelo: Quando um modelo de aprendizado de máquina é executado em uma cadeia de blocos, as atualizações e os resultados do modelo são registrados na cadeia, tornando-os verificáveis. Isso evita a manipulação ou viés nos resultados que podem ocorrer em um ambiente centralizado.

O fator chave aqui é verificar se o modelo de aprendizado de máquina foi treinado corretamente. No entanto, o cálculo de aprendizado de máquina é altamente intensivo, o que torna quase impossível executar esses cálculos completamente no ambiente de cadeia de blocos. Portanto, surgiram estruturas como opML e zkML para validar efetivamente o treinamento de modelos de aprendizado de máquina no ambiente de cadeia de blocos. O opML adota uma abordagem otimista para treinar modelos, registrando os resultados na cadeia de blocos e corrigindo erros por meio de um mecanismo de questionamento.

Vamos dar uma olhada mais atenta no método proposto pela ORA, que é um projeto que oferece infraestrutura de inteligência artificial na blockchain. O processo de desafio do opML é muito semelhante ao processo de desafio do rollup e consiste em três componentes-chave:

prova de fraudeMáquina virtual（Fraud Proof VM）：该Máquina virtual执行机器学习推理，其功能类似于 Arbitrum 的 WAVM 或 Optimism 的 Cannon。
opML Contrato inteligente：该合约验证prova de fraude，作用类似于 Optimism 的 MIPS.sol 合约。
Jogo de validação: Os validadores que levantam questões interagem com o servidor por meio de um método de divisão binária para identificar o único passo incorreto na Máquina Virtual e gerar uma prova de fraude para esse passo. Em seguida, eles enviam a prova de fraude para o contrato OPML.

Jogo de verificação no ORA opML | Fonte: Documento ORA

Através deste mecanismo de prova de fraude, o opML utiliza a segurança e a confiabilidade da blockchain, ao mesmo tempo que fornece um ambiente economicamente eficiente para o treino e verificação de modelos de aprendizagem automática.

6. Conclusão

Optimistic Rollup está a concentrar-se em melhorar a prova de fraude e questionar o protocolo, a fim de herdar mais segurança do Ethereum e criar uma cadeia com menos confiança. Arbitrum espera atingir a Fase 2 até o final deste ano usando BoLD, enquanto o Optimism também se esforça em direção à Fase 2, dependendo do jogo de disputa V2 e de múltiplos mecanismos de prova. No próximo ano, os utilizadores do Optimistic Rollup poderão interagir com a rede com maior segurança, sem se preocupar com a possibilidade de que o Rollup possa retirar os seus fundos. Além disso, Vitalik mencionou em seu blog que o número de Rollups na Fase 1 e acima também deverá aumentar.

No entanto, cada protocolo ainda tem espaço para melhorias e muitos aspectos podem ser reforçados com a prova de fraude ZK. A Kroma já está avançando em seu protocolo com base nisso, enquanto outros protocolos como Arbitrum, Optimism e Cartesi também podem manter uma forma mais segura e descentralizada usando a prova de fraude ZK.

No campo da prova de fraude, não só o Rollup, mas também outros protocolos estão investindo muitos recursos de P&D. Com a premissa de "apenas um participante honesto", a combinação de prova de fraude e ZK pode ajudar a construir uma arquitetura de cadeia de blocos minimizada pela confiança, cujo impacto acabará se tornando uma realidade tangível.

7. Referências

(https://l2beat.com/scaling/summary)[L2Beat]

prova de fraude战争 | Luca Donnoh at L2Beat

Arquivo Arbitrum

Optimism 文件

Optimismo Especificações

无权限裁判的比赛 | Cartesi

Kroma 规格

BoLD: Resolução rápida e de baixo custo de disputas

Economia em Negrito

Por que o período de desafio do Rollup otimista é de 7 dias? | Kelvin Fichter em OP Labs

prova de fraude已崩溃 | Gabriel Coutinho de Paula at Cartesi

乐观时间旅行 | Yoav Weiss

Introdução ao primeiro desafio bem-sucedido na Rede principal Kroma

解读基线Descentralização的进展 | OP Labs

Ataque de censura não atribuível a protocolos Layer2 baseados em prova de fraude

OP Labs 审计框架

无信任的推导 | Kroma

Introdução ao OP Succinct: prova de validade completa no OP Stack | Succinct

Eigenlayer GitHub

Celestia 文件

Contribution DAO Blog

ORA 文件

Declaração:

Este artigo é reproduzido de [research.2077], todos os direitos autorais pertencem aos autores originais [sm-stack and BTC Penguin]. Se você tiver alguma objeção a esta reprodução, entre em contato com a equipe do Gate Learn, eles irão lidar com isso prontamente.
Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo representam apenas a opinião pessoal do autor e não constituem qualquer tipo de conselho de investimento.
A equipe Gate Learn traduzirá os artigos para outros idiomas. A menos que seja indicado o contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.