Muito obrigado a Vitalik (EF), Justin (EF), Kelvin (OP) e Gabriel (Cartesi) pelo feedback e discussão.
O objetivo deste post é iniciar uma discussão em torno de um período de desafio socialmente aceitável limite inferior para rollups otimistas e, por consequência, em torno das fortes garantias de resistência à censura do Ethereum.
Hoje, os rollups otimistas somam 91,9% do valor total garantido por todos os rollups. Nós (L2BEAT) começamos recentemente a impor um requisito de período de desafio ≥7d para ser classificado como Estágio 1, o que gerou um debate sobre a origem desse número e como podemos avaliar se ele é apropriado. Sentimos que é altura de formalizar melhor este valor e atualizá-lo ou ratificá-lo como padrão comunitário, uma vez que alguns projetos já começaram a argumentar que períodos de desafio mais baixos podem ser equivalentemente seguros.
O maior equívoco em torno dos períodos de desafio é a crença de que eles são definidos com base no tempo necessário para realizar a interação entre duas partes em um desafio de múltiplas rodadas. Se o número de interações for reduzido, no extremo para 1 com protocolos não interativos (exemplo), às vezes é sugerido que o período de desafio também pode ser significativamente reduzido.
A realidade é que o período do desafio foi originalmente definido para permitir uma resposta social em caso de ataque de consenso de 51% e evitar que fundos sejam roubados. É importante notar que, em L1, um forte ataque de censura não pode fazer com que os fundos de uma conta simples sejam roubados.
Tanto quanto sabemos, os detalhes dessa resposta social nunca foram discutidos com precisão.
Existem duas maneiras principais pelas quais os rollups otimistas controlam o tempo restante para participar de um desafio: ou com um temporizador globalou com um modelo de relógio de xadrez. O primeiro tipo é a forma mais simples e é empregado principalmente em protocolos de desafio de rodada única.
O segundo tipo é usado por protocolos multi-rodada como OPFP, BoLD ou Dave, para evitar que o atacante desperdice o tempo disponível dos jogadores honestos, não agindo quando for a sua vez. Na prática, para cada desafio são criados dois relógios, um para o afirmador e outro para o desafiante, e o tempo de um relógio é consumido apenas quando chega a hora de seu dono fazer um movimento, e deixa de ser consumido quando chega a vez do outro jogador. Se o tempo acabar, os outros jogadores ganham.
Os fundos podem ser comprometidos quando jogadores honestos não conseguem realizar suas jogadas devido a um forte ataque de censura, fazendo com que seus relógios expirem.
Neste post vamos nos concentrar no modelo do relógio de xadrez, pois ele representa a maioria dos projetos e porque o caso do modelo do cronômetro global pode ser deduzido trivialmente dele.
Para simplificar, vamos supor que a censura seja sustentada, ou seja, realizada sem interrupções. Além disso, assumimos que reversões de L1 e transições de estado inválidas específicas de rollup de L1 são uma resposta social altamente controversa e indesejável isso deve ser evitado sempre que possível.
Esboçamos a seguinte linha do tempo:
- (0h → 24h): é detectado um ataque de censura forte de 51%.
- (24h → 6d): um hard fork é coordenado, implementado e ativado para eliminar a censura dos validadores.
- 1d: o tempo restante no relógio dos jogadores honestos para jogar.
Esta resposta social evita com sucesso um ataque de “51%” a rollups otimistas sem reversões apenas se todas as seguintes afirmações forem verdadeiras: (1) somos capazes de detectar censura em 24h; (2) somos capazes de coordenar, implementar e ativar um hard fork em 5d; (3) protocolos de desafio são eficientes o suficiente para que possam ser jogados consumindo menos de 1d quando não há censura.
Porém, há uma advertência: o que foi dito acima é verdadeiro se considerarmos o valor “51%” literalmente, enquanto falha se o ataque for reiterado mesmo após o hard fork (… ataque de 76%?). Uma solução simples é permitir que os contratos consultem o carimbo de data/hora do hard fork mais recente e estendam os relógios, se necessário, mas isso requer uma atualização de protocolo.
Na prática, um invasor pode simplesmente atrasar as transações da parte honesta de modo que o tempo expire antes que o último movimento seja feito. Supondo que aproximadamente 70 etapas (como no BoLD da Arbitrum) sejam necessárias para chegar à etapa final, onde 35 seriam executadas pelas partes honestas, e relógios de 7 dias, o invasor pode atrasar cada movimento em aproximadamente 5 horas a cada aproximadamente 5 horas, consumindo seu próprio relógio e o relógio da parte honesta. Para que o cronograma acima seja válido, deveremos ser capazes de detectar esses ataques de censura também dentro de 1 dia.
Hoje, o Ethereum fornece cerca de US$ 100 bilhões em segurança econômica, o que representa cerca de 2x o valor total garantido por todos os L2s que se estabelecem no Ethereum. Poderíamos aceitar que ataques de censura fortes são extremamente improváveis e abandonar a ideia de que acumulações otimistas deveriam permanecer seguras em torno deles. Neste caso, o período de desafio só precisa ser longo o suficiente para proteger contra ataques de censura branda (ou seja, conduzidos pelo construtor) e fornecer tempo suficiente para calcular os movimentos necessários.
Digamos que desejamos que rollups otimistas sejam seguros em até 99% de ataques de censura suave, considerando uma probabilidade de inclusão de 99,99%: então precisaríamos fornecer pelo menos 3h para cada tx ser incluído em L1 e, considerando ~35 etapas necessárias por jogador para completar um desafio interativo, precisaríamos fornecer pelo menos ~4,5d. A ativação do FOCIL proporcionaria resultados muito mais significativos e reduziria potencialmente o período, sob este modelo de ameaça, para um valor seguro de apenas alguns dias.
Vitalik Buterin (2017): pontuações de suspeita
Calcule o maior período de tempo que o cliente viu que um voto poderia ter sido incluído na cadeia, mas não foi incluído, com um “fator de perdão” onde eventos antigos são descontados pela idade dividida por 16.
São propostas algumas modificações no Casper FFG para estender as épocas, caso não sejam finalizadas.
Vitalik Buterin (2019): respondendo a ataques de 51% em Casper FFG
Discute a censura do atestador e os soft forks automatizados em resposta.
Vitalik Buterin (2020): detectores de oportunidade
O objetivo explícito é detectar 51% dos ataques, identificar a cadeia “correta” e quais validadores “culpar”. Os mecanismos tentam identificar blocos que chegaram com atraso incomum, com um limite de sincronia acordado em comum. Envolve a introdução do conceito de um comitê de oportunidade para chegar a um acordo.
Sreeram Kannan (2023): Revere, um gadget de observabilidade para censura de atestadores em Ethereum
É muito mais fácil resolver a questão da censura do proponente porque mesmo uma pequena fração do proponente honesto pode oferecer resistência à censura. Muito mais difícil de proteger da censura do atestador. Solução: aumentar a observabilidade dos blocos tio. Como? Não é fácil distinguir blocos tio por causa de censura ou censura de rede. Adicionar regra: um proponente deve incluir transações de blocos tio. Use clientes leves que melhoram a observabilidade para todos, rastreando cabeçalhos.
Ed Felten (2023): oráculo de censura onchain
Detecção de censura onchain. O teste diz que ou não houve censura significativa, ou talvez tenha havido censura. Ideia: medir onchain o número de slots vazios (consenso). Com nível de confiança de p=10^-6, e assumindo 10% de proponentes honestos, você pode denunciar a censura se houver mais de 34 espaços vazios em 688. Problema: o adversário pode esperar para lançar o ataque até saber que os próximos 64 proponentes serão todos maliciosos. Mitigação: adicione 64 slots à duração do teste. Outro problema: se o teste falhar, você pode querer fazê-lo novamente nos n blocos seguintes, mas isso não é correto (p-hacking). Mitigação: se quisermos repetição então cada teste precisa ter mais confiança. Abandonado em 2024 devido a algum vetor de ataque.
Fontesethresear
