Analisando uma grande atualização para Arbitrum: verificação sem permissão com BOLD

Autor: @francescoweb3; tradução: Huohuo/vernacular blockchain

**Arbitrum está se tornando mais descentralizado: usando BOLD para verificação sem permissão. **Embora esta não seja uma semana com um nome como BALD, esta é uma grande atualização no design do Arbitrum.

BOLD significa Bounded Liquidity Delay e, como o nome sugere, é um "protocolo de disputa" que fornece à Arbitrum recursos de verificação sem permissão.

** 1. Por que você precisa de BOLD? **

Em termos simples, todos os Rollups otimistas estabelecem seu estado no Ethereum. **Como eles garantem que a transação é válida? Através do chamado sistema à prova de fraude. **

Na prática, isso acontece por meio de um conjunto de entidades chamadas de validadores. Esses validadores emitem declarações sobre o estado de L2 e confirmam por meio de contratos inteligentes que essas declarações são verdadeiras.

Em seguida, há um período de contestação de 7 dias (ou período de espera) durante o qual outros validadores podem realmente contestar essas reivindicações e, se houver discrepância, o processo de resolução de disputas é iniciado.

Se uma reivindicação for confirmada, o estado L2 é considerado correto e a liquidação é concluída no Ethereum.

É o processo de verificação através da prova de fraude que causa um atraso de aproximadamente 7 dias para a ponte local entre Arbitrum e Ethereum.

O protocolo de disputa envolve as partes que enviam provas de fraude ao Ethereum para determinar o resultado válido de uma transação L2.

**Qual é o problema? Atualmente, a verificação por meio de provas de fraude é necessária com permissão no Arbitrum One e no Nova. **

A razão para isso é proteger o protocolo de disputa de ataques de negação de serviço. Se um validador mal-intencionado continuar gastando fundos para impedir que as reivindicações sejam confirmadas, as retiradas L2 para Ethereum serão bloqueadas e, embora tenham fundos suficientes, esse processo pode continuar por quase um longo tempo.

Isso é chamado de ataque de atraso e tenta interromper o progresso do protocolo Rollup "tentando impedir ou atrasar a confirmação de quaisquer resultados". Este ataque é projetado para impedir que os validadores enviem provas fraudulentas, de modo que o estado L2 não possa ser confirmado e liquidado para Ethereum.

De fato, mudar para a verificação sem permissão requer um protocolo resistente a ataques de atraso, como o BOLD.

BOLD é um novo método de verificação L2 sem permissão.

Ele permite que a Arbitrum:

Garantir a segurança e vivacidade da cadeia

Minimize a latência na liquidação do estado

Evite que partes desonestas aumentem os custos para partes honestas.

Na verdade, o BOLD pode ajudar a descentralizar a cadeia de Arbitrum, fornecendo uma "confirmação atrasada adicional fixa de 7 dias" que é imune a ataques de atraso.

Ele consegue isso permitindo "disputas de todos para todos" eficientes, onde até mesmo um único validador honesto pode vencer uma disputa com qualquer número de reivindicações maliciosas.

Portanto, a BOLD pode resolver com eficiência disputas entre várias partes em um processo sem depender de contestações individuais anteriores.

A BOLD pede a todas as partes que apoiam uma determinada declaração que lutem juntas "como uma equipe".

Portanto, quaisquer disputas em BOLD estão relacionadas à execução "determinística" do estado L2, não a um stakeholder ou entidade específica.

Isso significa que qualquer pessoa que concorde com um estado pode justificá-lo antes de encontrar um único ponto de inconsistência.

Portanto, como as disputas na BOLD são conduzidas como parte de toda a equipe, qualquer ação acordada em nome da equipe é apoiada por todos os membros honestos da equipe.

A natureza determinística de um estado L2 correto significa que as partes honestas sempre vencerão se participarem, uma vez que as partes maliciosas não podem falsificar provas da execução da transação Esse design é mais eficiente porque cada parte pode "confiar discretamente nos outros para representar sua posição sem se preocupar se a parte falhará deliberadamente no desafio".

Compreensão profunda do BOLD

Ao invés de ser visto como um protocolo de desafio entre diferentes partes, o protocolo BOLD deve ser entendido como uma competição entre "bordas", onde o objetivo dos participantes é selecionar a borda correta como vencedora.

Como esse processo funciona em segundo plano?

1. "Edge" é a principal estrutura de dados no protocolo de desafio.
2. O objetivo do BOLD é confirmar as arestas correspondentes aos cálculos corretos e evitar que arestas incorretas sejam confirmadas.
3. BOLD rastreia o estado de uma aresta, mas não vincula uma aresta a nenhuma parte específica.
4. As bordas são classificadas de acordo com sua relação com a execução correta.
5. O protocolo não sabe a qual categoria a borda pertence, mas os participantes honestos podem dizer.
6. Uma borda tem um "compromisso de histórico inicial" e um "compromisso de histórico final".
7. Uma aresta é demonstrável se tanto o início quanto o fim forem verdadeiros, é desviante se apenas o início for verdadeiro e é irrelevante se ambos forem falsos.
8. Para justificar o protocolo: 8.1 Teorema de Segurança: Nenhum desvio de qualquer margem pode ser identificado. 8.2 Teorema do Tempo de Conclusão: Arestas honestas podem ser confirmadas antes de algum prazo.

Infraestrutura BOLD

2. Conclusão

O BOLD atinge uma latência ótima vinculada à confirmação de resultados e também limita linearmente o trabalho exigido por partes honestas em termos dos benefícios confiscados pela parte adversária.