Ataque e defesa da Prova de Participação (PoS) do Ethereum

Ladrões e sabotadores estão constantemente buscando oportunidades para atacar o software de cliente do Ethereum. Esta página descreve os vetores de ataque conhecidos na camada de consenso do Ethereum e descreve como esses ataques podem ser defendidos. As informações nesta página foram adaptadas de uma versão mais longa (opens in a new tab).

Pré-requisitos

É exigido algum conhecimento básico sobre a Prova de Participação (PoS). Além disso, será útil ter um entendimento básico da camada de incentivos do Ethereum e do algoritmo de escolha de fork, o LMD-GHOST.

O que os invasores querem?

Um equívoco comum é que um invasor bem-sucedido pode gerar novos ether ou drenar ether de contas arbitrárias. Nenhuma dessas opções é possível porque todas as transações são executadas por todos os clientes de execução na rede. Elas devem satisfazer condições básicas de validade (por exemplo, as transações são assinadas pela chave privada do remetente, o remetente tem saldo suficiente, etc.) ou então elas simplesmente revertem. Existem três classes de resultados que um invasor pode realisticamente ter como alvo: reorgs, finalidade dupla ou atraso de finalidade.

Um "reorg" é um reordenamento de blocos em uma nova ordem, talvez com alguma adição ou subtração de blocos na cadeia canônica. Um reorg malicioso pode garantir que blocos específicos sejam incluídos ou excluídos, permitindo o gasto duplo ou a extração de valor por meio de transações de front-running e back-running (MEV). Reorgs também podem ser usados para evitar que certas transações sejam incluídas na cadeia canônica - uma forma de censura. A forma mais extrema de reorg é a "reversão de finalidade", que remove ou substitui blocos que foram finalizados anteriormente. Isso só é possível se mais de ⅓ do total de ether em stake for destruído pelo invasor - essa garantia é conhecida como "finalidade econômica" - mais sobre isso adiante.

A finalidade dupla é a condição improvável, mas grave, em que duas bifurcações conseguem ser finalizadas simultaneamente, criando um cisma permanente na cadeia. Isso é teoricamente possível para um invasor disposto a arriscar 34% do total de ether em stake. A comunidade seria forçada a coordenar offchain e chegar a um acordo sobre qual cadeia seguir, o que exigiria força na camada social.

Um ataque de atraso de finalidade impede que a rede alcance as condições necessárias para finalizar seções da cadeia. Sem finalidade, é difícil confiar em aplicativos financeiros construídos sobre o Ethereum. O objetivo de um ataque de atraso de finalidade provavelmente é apenas interromper o Ethereum em vez de lucrar diretamente, a menos que o invasor tenha alguma(s) posição(ões) vendida(s) estratégica(s).

Um ataque à camada social pode ter como objetivo minar a confiança pública no Ethereum, desvalorizar o ether, reduzir a adoção ou enfraquecer a comunidade Ethereum para tornar a coordenação fora de banda mais difícil.

Tendo estabelecido por que um adversário pode atacar o Ethereum, as seções a seguir examinam como eles podem fazer isso.

Métodos de Ataque

Ataques de Camada 0

Em primeiro lugar, indivíduos que não estão participando ativamente do Ethereum (executando software de cliente) podem atacar visando a camada social (Camada 0). A Camada 0 é a base sobre a qual o Ethereum é construído e, como tal, representa uma superfície potencial para ataques com consequências que se propagam pelo resto da pilha. Alguns exemplos podem incluir:

Uma campanha de desinformação pode corroer a confiança que a comunidade tem no roteiro do Ethereum, equipes de desenvolvedores, aplicativos, etc. Isso poderia então diminuir o número de indivíduos dispostos a participar da segurança da rede, degradando tanto a descentralização quanto a segurança criptoeconômica.
Ataques direcionados e/ou intimidação direcionados à comunidade de desenvolvedores. Isso pode levar à saída voluntária de desenvolvedores e retardar o progresso do Ethereum.
A regulamentação excessivamente zelosa também pode ser considerada um ataque à Camada 0, pois pode desincentivar rapidamente a participação e a adoção.
Infiltração de atores experientes, mas maliciosos, na comunidade de desenvolvedores, cujo objetivo é retardar o progresso por meio de discussões triviais, atrasando decisões importantes, criando spam, etc.
Subornos feitos a participantes importantes no ecossistema Ethereum para influenciar a tomada de decisões.

O que torna esses ataques especialmente perigosos é que, em muitos casos, é exigido muito pouco capital ou conhecimento técnico. Um ataque de Camada 0 pode ser um multiplicador em um ataque criptoeconômico. Por exemplo, se a censura ou a reversão de finalidade fossem alcançadas por um detentor de stake majoritário malicioso, minar a camada social poderia tornar mais difícil coordenar uma resposta da comunidade fora de banda.

A defesa contra ataques de Camada 0 provavelmente não é simples, mas alguns princípios básicos podem ser estabelecidos. Um deles é manter uma alta relação sinal-ruído geral para informações públicas sobre o Ethereum, criadas e propagadas por membros honestos da comunidade por meio de blogs, servidores do Discord, especificações anotadas, livros, podcasts e YouTube. Aqui no ethereum.org, nos esforçamos muito para manter informações precisas e traduzi-las para o maior número possível de idiomas. Inundar um espaço com informações e memes de alta qualidade é uma defesa eficaz contra a desinformação.

Outra fortificação importante contra ataques à camada social é uma declaração de missão clara e um protocolo de governança. O Ethereum se posicionou como o campeão de descentralização e segurança entre as blockchains de camada 1 (l1) de contratos inteligentes, ao mesmo tempo em que valoriza muito a escalabilidade e a sustentabilidade. Quaisquer que sejam as divergências que surjam na comunidade Ethereum, esses princípios fundamentais são minimamente comprometidos. Avaliar uma narrativa em relação a esses princípios fundamentais e examiná-los por meio de rodadas sucessivas de revisão no processo EIP (Proposta de Melhoria do Ethereum) pode ajudar a comunidade a distinguir os bons dos maus atores e limitar o escopo para que atores maliciosos influenciem a direção futura do Ethereum.

Por fim, é fundamental que a comunidade Ethereum permaneça aberta e acolhedora a todos os participantes. Uma comunidade com guardiões e exclusividade é especialmente vulnerável a ataques sociais porque é fácil construir narrativas de "nós e eles". O tribalismo e o maximalismo tóxico prejudicam a comunidade e corroem a segurança da Camada 0. Os Ethereans com interesse na segurança da rede devem ver sua conduta online e no mundo real como um contribuinte direto para a segurança da Camada 0 do Ethereum.

Atacando o protocolo

Qualquer pessoa pode executar o software de cliente do Ethereum. Para adicionar um validador a um cliente, é exigido que o usuário faça o stake de 32 ether no contrato de depósito. Um validador permite que um usuário participe ativamente da segurança da rede do Ethereum propondo e atestando novos blocos. O validador agora tem uma voz que pode usar para influenciar o conteúdo futuro da blockchain - ele pode fazer isso honestamente e aumentar seu estoque de ether por meio de recompensas ou pode tentar manipular o processo em benefício próprio, arriscando seu stake. Uma maneira de montar um ataque é acumular uma proporção maior do stake total e, em seguida, usá-lo para superar os votos dos validadores honestos. Quanto maior a proporção do stake controlada pelo invasor, maior será seu poder de voto, especialmente em certos marcos econômicos que exploraremos mais adiante. No entanto, a maioria dos invasores não conseguirá acumular ether suficiente para atacar dessa maneira, então, em vez disso, eles precisam usar técnicas sutis para manipular a maioria honesta a agir de uma determinada maneira.

Fundamentalmente, todos os ataques de pequeno stake são variações sutis de dois tipos de mau comportamento do validador: subatividade (falha em atestar/propor ou fazer isso tarde) ou superatividade (propor/atestar muitas vezes em um slot). Em suas formas mais básicas, essas ações são facilmente tratadas pelo algoritmo de escolha de fork e pela camada de incentivos, mas existem maneiras inteligentes de burlar o sistema em benefício de um invasor.

Ataques usando pequenas quantidades de ETH

reorgs

Vários artigos explicaram ataques ao Ethereum que alcançam reorgs ou atraso de finalidade com apenas uma pequena proporção do total de ether em stake. Esses ataques geralmente dependem de o invasor reter algumas informações de outros validadores e, em seguida, liberá-las de alguma forma sutil e/ou em algum momento oportuno. Eles geralmente visam deslocar algum(ns) bloco(s) honesto(s) da cadeia canônica. Neuder et al 2020 (opens in a new tab) mostraram como um validador invasor pode criar e atestar um bloco (B) para um slot específico n+1, mas abster-se de propagá-lo para outros nós na rede. Em vez disso, eles retêm esse bloco atestado até o próximo slot n+2. Um validador honesto propõe um bloco (C) para o slot n+2. Quase simultaneamente, o invasor pode liberar seu bloco retido (B) e suas atestações retidas para ele, e também atestar que B é a cabeça da cadeia com seus votos para o slot n+2, negando efetivamente a existência do bloco honesto C. Quando o bloco honesto D é liberado, o algoritmo de escolha de fork vê D sendo construído sobre B como sendo mais pesado do que D sendo construído sobre C. O invasor, portanto, conseguiu remover o bloco honesto C no slot n+2 da cadeia canônica usando um reorg ex ante de 1 bloco. Um invasor com 34% (opens in a new tab) do stake tem uma chance muito boa de ter sucesso neste ataque, conforme explicado nesta nota (opens in a new tab). Na teoria, no entanto, esse ataque poderia ser tentado com stakes menores. Neuder et al 2020 (opens in a new tab) descreveram esse ataque funcionando com um stake de 30%, mas mais tarde foi demonstrado que era viável com 2% do stake total (opens in a new tab) e, em seguida, novamente para um único validador (opens in a new tab) usando técnicas de balanceamento que examinaremos na próxima seção.

Um diagrama conceitual do ataque de reorg de um bloco descrito acima (adaptado de https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair (opens in a new tab))

Um ataque mais sofisticado pode dividir o conjunto de validadores honestos em grupos discretos que têm visões diferentes da cabeça da cadeia. Isso é conhecido como um ataque de balanceamento. O invasor espera por sua chance de propor um bloco e, quando ela chega, ele comete uma equivocação e propõe dois. Eles enviam um bloco para metade do conjunto de validadores honestos e o outro bloco para a outra metade. A equivocação seria detectada pelo algoritmo de escolha de fork e o propositor de bloco seria penalizado e ejetado da rede, mas os dois blocos ainda existiriam e teriam cerca de metade do conjunto de validadores atestando cada bifurcação. Enquanto isso, os validadores maliciosos restantes retêm suas atestações. Então, ao liberar seletivamente as atestações que favorecem uma ou outra bifurcação para apenas validadores suficientes no momento em que o algoritmo de escolha de fork é executado, eles inclinam o peso acumulado das atestações a favor de uma ou outra bifurcação. Isso pode continuar indefinidamente, com os validadores invasores mantendo uma divisão uniforme de validadores nas duas bifurcações. Como nenhuma das bifurcações pode atrair uma supermaioria de 2/3, a rede não seria finalizada.

Os ataques de salto (bouncing attacks) são semelhantes. Os votos são novamente retidos pelos validadores invasores. Em vez de liberar os votos para manter uma divisão uniforme entre duas bifurcações, eles usam seus votos em momentos oportunos para justificar pontos de verificação que alternam entre a bifurcação A e a bifurcação B. Essa alternância de justificação entre duas bifurcações impede que haja pares de pontos de verificação de origem e destino justificados que possam ser finalizados em qualquer uma das cadeias, interrompendo a finalidade.

The game of reorgs in proof of stake Ethereum

Caspar Schwarz-Schilling presents research on block reorganization attacks in proof of stake Ethereum, covering attack vectors, defense mechanisms, and the protocol-level mitigations in place.

Assistir com transcrição

Tanto os ataques de salto quanto os de balanceamento dependem de o invasor ter um controle muito preciso sobre o tempo das mensagens na rede, o que é improvável. No entanto, as defesas são incorporadas ao protocolo na forma de peso adicional dado a mensagens rápidas em comparação com as lentas. Isso é conhecido como aumento de peso do proponente (proposer-weight boosting) (opens in a new tab). Para se defender contra ataques de salto, o algoritmo de escolha de fork foi atualizado para que o último ponto de verificação justificado só possa mudar para o de uma cadeia alternativa durante o primeiro 1/3 dos slots em cada época (opens in a new tab). Essa condição impede que o invasor guarde votos para implantar mais tarde - o algoritmo de escolha de fork simplesmente permanece leal ao ponto de verificação que escolheu no primeiro 1/3 da época, durante o qual a maioria dos validadores honestos teria votado.

Combinadas, essas medidas criam um cenário no qual um propositor de bloco honesto emite seu bloco muito rapidamente após o início do slot, então há um período de ~1/3 de um slot (4 segundos) em que esse novo bloco pode fazer com que o algoritmo de escolha de fork mude para outra cadeia. Após esse mesmo prazo, as atestações que chegam de validadores lentos têm seu peso reduzido em comparação com as que chegaram antes. Isso favorece fortemente os proponentes e validadores rápidos na determinação da cabeça da cadeia e reduz substancialmente a probabilidade de um ataque de balanceamento ou salto bem-sucedido.

Vale a pena notar que o aumento do proponente por si só defende apenas contra "reorgs baratos", ou seja, aqueles tentados por um invasor com um pequeno stake. Na verdade, o próprio aumento do proponente pode ser burlado por detentores de stake maiores. Os autores desta postagem (opens in a new tab) descrevem como um invasor com 7% do stake pode implantar seus votos estrategicamente para enganar validadores honestos a construir em sua bifurcação, removendo um bloco honesto por meio de reorg. Esse ataque foi concebido assumindo condições ideais de latência que são muito improváveis. As chances ainda são muito remotas para o invasor, e o stake maior também significa mais capital em risco e um desincentivo econômico mais forte.

Um ataque de balanceamento visando especificamente a regra LMD (opens in a new tab) também foi proposto, o qual foi sugerido como viável apesar do aumento do proponente. Um invasor configura duas cadeias concorrentes cometendo uma equivocação em sua proposta de bloco e propagando cada bloco para cerca de metade da rede cada, estabelecendo um equilíbrio aproximado entre as bifurcações. Em seguida, os validadores em conluio cometem uma equivocação em seus votos, cronometrando-os para que metade da rede receba seus votos para a Bifurcação A primeiro e a outra metade receba seus votos para a Bifurcação B primeiro. Como a regra LMD descarta a segunda atestação e mantém apenas a primeira para cada validador, metade da rede vê votos para A e nenhum para B, a outra metade vê votos para B e nenhum para A. Os autores descrevem a regra LMD dando ao adversário um "poder notável" para montar um ataque de balanceamento.

Esse vetor de ataque LMD foi fechado atualizando o algoritmo de escolha de fork (opens in a new tab) para que ele descarte totalmente os validadores que cometem equivocação da consideração de escolha de fork. Os validadores que cometem equivocação também têm sua influência futura descontada pelo algoritmo de escolha de fork. Isso evita o ataque de balanceamento descrito acima, ao mesmo tempo em que mantém a resiliência contra ataques de avalanche.

Outra classe de ataque, chamada de ataques de avalanche (opens in a new tab), foi descrita em um artigo de março de 2022 (opens in a new tab). Para montar um ataque de avalanche, o invasor precisa controlar vários propositores de bloco consecutivos. Em cada um dos slots de proposta de bloco, o invasor retém seu bloco, coletando-os até que a cadeia honesta alcance um peso de subárvore igual com os blocos retidos. Em seguida, os blocos retidos são liberados para que cometam equivocação ao máximo. Os autores sugerem que o aumento do proponente - a principal defesa contra ataques de balanceamento e salto - não protege contra algumas variantes do ataque de avalanche. No entanto, os autores também demonstraram o ataque apenas em uma versão altamente idealizada do algoritmo de escolha de fork do Ethereum (eles usaram GHOST sem LMD).

O ataque de avalanche é mitigado pela parte LMD do algoritmo de escolha de fork LMD-GHOST. LMD significa "orientado pela última mensagem" (latest-message-driven) e refere-se a uma tabela mantida por cada validador contendo a última mensagem recebida de outros validadores. Esse campo só é atualizado se a nova mensagem for de um slot posterior ao que já está na tabela para um validador específico. Na prática, isso significa que em cada slot, a primeira mensagem recebida é a que é aceita e quaisquer mensagens adicionais são equivocações a serem ignoradas. Dito de outra forma, os clientes de consenso não contam as equivocações - eles usam a primeira mensagem que chega de cada validador e as equivocações são simplesmente descartadas, evitando ataques de avalanche.

Existem várias outras possíveis atualizações futuras para a regra de escolha de fork que poderiam aumentar a segurança fornecida pelo aumento do proponente. Uma delas é a mesclagem de visualização (view-merge) (opens in a new tab), onde os atestadores congelam sua visão da escolha de fork n segundos antes do início de um slot e o proponente então ajuda a sincronizar a visão da cadeia em toda a rede. Outra atualização potencial é a finalidade de slot único (single-slot finality) (opens in a new tab), que protege contra ataques baseados no tempo da mensagem finalizando a cadeia após apenas um slot.

Atraso de Finalidade

O mesmo artigo (opens in a new tab) que descreveu pela primeira vez o ataque de reorg de bloco único de baixo custo também descreveu um ataque de atraso de finalidade (também conhecido como "falha de vivacidade") que depende de o invasor ser o propositor de bloco para um bloco de limite de época. Isso é crítico porque esses blocos de limite de época se tornam os pontos de verificação que o Casper FFG usa para finalizar partes da cadeia. O invasor simplesmente retém seu bloco até que validadores honestos suficientes usem seus votos FFG a favor do bloco de limite de época anterior como o alvo de finalização atual. Em seguida, eles liberam seu bloco retido. Eles atestam seu bloco e os validadores honestos restantes também o fazem, criando bifurcações com diferentes pontos de verificação de destino. Se eles cronometrarem corretamente, eles impedirão a finalidade porque não haverá uma supermaioria de 2/3 atestando nenhuma das bifurcações. Quanto menor o stake, mais preciso o tempo precisa ser porque o invasor controla menos atestações diretamente, e menores as chances de o invasor controlar o validador propondo um determinado bloco de limite de época.

Ataques de longo alcance

Há também uma classe de ataque específica para blockchains de Prova de Participação (PoS) que envolve um validador que participou do bloco gênesis mantendo uma bifurcação separada da blockchain ao lado da honesta, eventualmente convencendo o conjunto de validadores honestos a mudar para ela em algum momento oportuno muito mais tarde. Esse tipo de ataque não é possível no Ethereum devido ao mecanismo de finalidade que garante que todos os validadores concordem com o estado da cadeia honesta em intervalos regulares ("pontos de verificação"). Esse mecanismo simples neutraliza invasores de longo alcance porque os clientes do Ethereum simplesmente não farão reorg de blocos finalizados. Novos nós que entram na rede fazem isso encontrando um hash de estado recente confiável (um ponto de verificação de "subjetividade fraca (opens in a new tab)") e usando-o como um pseudo-bloco gênesis para construir em cima. Isso cria um 'portal de confiança' para um novo nó que entra na rede antes que ele possa começar a verificar as informações por si mesmo.

Negação de Serviço

O mecanismo PoS do Ethereum escolhe um único validador do conjunto total de validadores para ser um propositor de bloco em cada slot. Isso pode ser calculado usando uma função publicamente conhecida e é possível que um adversário identifique o próximo propositor de bloco um pouco antes de sua proposta de bloco. Em seguida, o invasor pode enviar spam ao propositor de bloco para impedi-lo de trocar informações com seus pares. Para o resto da rede, pareceria que o propositor de bloco estava offline e o slot simplesmente ficaria vazio. Isso poderia ser uma forma de censura contra validadores específicos, impedindo-os de adicionar informações à blockchain. A implementação de eleições secretas de líder único (SSLE) ou eleições secretas de líder não único mitigará os riscos de DoS porque apenas o propositor de bloco sabe que foi selecionado e a seleção não é conhecida com antecedência. Isso ainda não foi implementado, mas é uma área ativa de pesquisa e desenvolvimento (opens in a new tab).

Tudo isso aponta para o fato de que é muito difícil atacar o Ethereum com sucesso com um pequeno stake. Os ataques viáveis que foram descritos aqui exigem um algoritmo de escolha de fork idealizado, condições de rede improváveis ou os vetores de ataque já foram fechados com patches relativamente pequenos no software de cliente. Isso, é claro, não descarta a possibilidade de existirem zero-days na prática, mas demonstra o nível extremamente alto de aptidão técnica, conhecimento da camada de consenso e sorte exigidos para que um invasor com stake minoritário seja eficaz. Da perspectiva de um invasor, sua melhor aposta pode ser acumular o máximo de ether possível e retornar armado com uma proporção maior do stake total.

Invasores usando >= 33% do stake total

Todos os ataques mencionados anteriormente neste artigo se tornam mais propensos a ter sucesso quando o invasor tem mais ether em stake para votar e mais validadores que podem ser escolhidos para propor blocos em cada slot. Um validador malicioso pode, portanto, ter como objetivo controlar o máximo de ether em stake possível.

33% do ether em stake é uma referência para um invasor porque, com qualquer valor maior que esse, ele tem a capacidade de impedir que a cadeia seja finalizada sem ter que controlar finamente as ações dos outros validadores. Eles podem simplesmente desaparecer todos juntos. Se 1/3 ou mais do ether em stake estiver atestando maliciosamente ou falhando em atestar, então uma supermaioria de 2/3 não pode existir e a cadeia não pode ser finalizada. A defesa contra isso é o vazamento por inatividade. O vazamento por inatividade identifica os validadores que estão falhando em atestar ou atestando de forma contrária à maioria. O ether em stake de propriedade desses validadores que não atestam é gradualmente drenado até que, eventualmente, eles representem coletivamente menos de 1/3 do total, para que a cadeia possa ser finalizada novamente.

O objetivo do vazamento por inatividade é fazer com que a cadeia seja finalizada novamente. No entanto, o invasor também perde uma parte de seu ether em stake. A inatividade persistente em validadores que representam 33% do total de ether em stake é muito cara, mesmo que os validadores não sejam penalizados.

Supondo que a rede Ethereum seja assíncrona (ou seja, há atrasos entre o envio e o recebimento de mensagens), um invasor que controla 34% do stake total pode causar finalidade dupla. Isso ocorre porque o invasor pode cometer uma equivocação quando é escolhido para ser um produtor de bloco e, em seguida, votar duas vezes com todos os seus validadores. Isso cria uma situação em que existe uma bifurcação da blockchain, cada uma com 34% do ether em stake votando nela. Cada bifurcação exige apenas que 50% dos validadores restantes votem a seu favor para que ambas as bifurcações sejam apoiadas por uma supermaioria, caso em que ambas as cadeias podem ser finalizadas (porque 34% dos validadores invasores + metade dos 66% restantes = 67% em cada bifurcação). Os blocos concorrentes teriam que ser recebidos por cerca de 50% dos validadores honestos, portanto, esse ataque é viável apenas quando o invasor tem algum grau de controle sobre o tempo das mensagens que se propagam pela rede, para que possa empurrar metade dos validadores honestos para cada cadeia. O invasor necessariamente destruiria todo o seu stake (34% de ~10 milhões de ether com o conjunto de validadores de hoje) para alcançar essa finalidade dupla porque 34% de seus validadores estariam votando duas vezes simultaneamente - uma ofensa passível de penalização com a penalidade de correlação máxima. A defesa contra esse ataque é o custo muito alto de destruir 34% do total de ether em stake. A recuperação desse ataque exigiria que a comunidade Ethereum coordenasse "fora de banda" e concordasse em seguir uma ou outra das bifurcações e ignorar a outra.

Invasores usando ~50% do stake total

Com 50% do ether em stake, um grupo malicioso de validadores poderia teoricamente dividir a cadeia em duas bifurcações de tamanhos iguais e, em seguida, simplesmente usar todo o seu stake de 50% para votar de forma contrária ao conjunto de validadores honestos, mantendo assim as duas bifurcações e impedindo a finalidade. O vazamento por inatividade em ambas as bifurcações acabaria levando ambas as cadeias a serem finalizadas. Neste ponto, a única opção é recorrer a uma recuperação social.

É muito improvável que um grupo adversário de validadores possa controlar consistentemente e com precisão 50% do stake total, dado um grau de fluxo nos números de validadores honestos, latência da rede, etc. - o enorme custo de montar tal ataque combinado com a baixa probabilidade de sucesso parece ser um forte desincentivo para um invasor racional, especialmente quando um pequeno investimento adicional na obtenção de mais de 50% desbloqueia muito mais poder.

Com >50% do stake total, o invasor poderia dominar o algoritmo de escolha de fork. Nesse caso, o invasor seria capaz de atestar com o voto da maioria, dando-lhe controle suficiente para fazer reorgs curtos sem precisar enganar clientes honestos. Os validadores honestos seguiriam o exemplo porque seu algoritmo de escolha de fork também veria a cadeia favorecida pelo invasor como a mais pesada, para que a cadeia pudesse ser finalizada. Isso permite que o invasor censure certas transações, faça reorgs de curto alcance e extraia o máximo de MEV reordenando os blocos a seu favor. A defesa contra isso é o enorme custo de um stake majoritário (atualmente pouco menos de US$ 19 bilhões) que é colocado em risco por um invasor porque a camada social provavelmente intervirá e adotará uma bifurcação minoritária honesta, desvalorizando drasticamente o stake do invasor.

Invasores usando >=66% do stake total

Um invasor com 66% ou mais do total de ether em stake pode finalizar sua cadeia preferida sem ter que coagir nenhum validador honesto. O invasor pode simplesmente votar em sua bifurcação preferida e, em seguida, finalizá-la, simplesmente porque pode votar com uma supermaioria desonesta. Como detentor de stake com supermaioria, o invasor sempre controlaria o conteúdo dos blocos finalizados, com o poder de gastar, retroceder e gastar novamente, censurar certas transações e fazer reorg da cadeia à vontade. Ao comprar ether adicional para controlar 66% em vez de 51%, o invasor está efetivamente comprando a capacidade de fazer reorgs ex post e reversões de finalidade (ou seja, mudar o passado, bem como controlar o futuro). As únicas defesas reais aqui são o enorme custo de 66% do total de ether em stake e a opção de recorrer à camada social para coordenar a adoção de uma bifurcação alternativa. Podemos explorar isso com mais detalhes na próxima seção.

Pessoas: a última linha de defesa

Se os validadores desonestos conseguirem finalizar sua versão preferida da cadeia, a comunidade Ethereum será colocada em uma situação difícil. A cadeia canônica inclui uma seção desonesta incorporada em sua história, enquanto validadores honestos podem acabar sendo punidos por atestar uma cadeia alternativa (honesta). Observe que uma cadeia finalizada, mas incorreta, também pode surgir de um bug em um cliente majoritário. No final, o último recurso é contar com a camada social - Camada 0 - para resolver a situação.

Um dos pontos fortes do consenso PoS do Ethereum é que há uma série de estratégias defensivas (opens in a new tab) que a comunidade pode empregar diante de um ataque. Uma resposta mínima poderia ser forçar a saída dos validadores dos invasores da rede sem nenhuma penalidade adicional. Para entrar novamente na rede, o invasor teria que entrar em uma fila de ativação que garante que o conjunto de validadores cresça gradualmente. Por exemplo, adicionar validadores suficientes para dobrar a quantidade de ether em stake leva cerca de 200 dias, efetivamente comprando aos validadores honestos 200 dias antes que o invasor possa tentar outro ataque de 51%. No entanto, a comunidade também pode decidir penalizar o invasor com mais severidade, revogando recompensas passadas ou queimando alguma parte (até 100%) de seu capital em stake.

Qualquer que seja a penalidade imposta ao invasor, a comunidade também deve decidir em conjunto se a cadeia desonesta, apesar de ser a favorecida pelo algoritmo de escolha de fork codificado nos clientes do Ethereum, é de fato inválida e que a comunidade deve construir sobre a cadeia honesta em vez disso. Validadores honestos poderiam concordar coletivamente em construir sobre uma bifurcação aceita pela comunidade da blockchain do Ethereum que pode, por exemplo, ter se bifurcado da cadeia canônica antes do início do ataque ou ter os validadores dos invasores removidos à força. Validadores honestos seriam incentivados a construir nesta cadeia porque evitariam as penalidades aplicadas a eles por falharem (com razão) em atestar a cadeia do invasor. Corretoras, rampas de acesso (on-ramps) e aplicativos construídos no Ethereum presumivelmente prefeririam estar na cadeia honesta e seguiriam os validadores honestos para a blockchain honesta.

No entanto, isso seria um desafio substancial de governança. Alguns usuários e validadores sem dúvida perderiam como resultado da mudança de volta para a cadeia honesta, as transações em blocos validados após o ataque poderiam ser revertidas, interrompendo a camada de aplicativos, e isso simplesmente mina a ética de alguns usuários que tendem a acreditar que "o código é a lei". Corretoras e aplicativos provavelmente terão vinculado ações offchain a transações onchain que agora podem ser revertidas, iniciando uma cascata de retrações e revisões que seriam difíceis de desfazer de forma justa, especialmente se ganhos ilícitos tiverem sido misturados, depositados em DeFi ou outros derivativos com efeitos secundários para usuários honestos. Sem dúvida, alguns usuários, talvez até institucionais, já teriam se beneficiado da cadeia desonesta, seja por serem astutos ou por acaso, e poderiam se opor a uma bifurcação para proteger seus ganhos. Houve apelos para ensaiar a resposta da comunidade a ataques >51% para que uma mitigação coordenada sensata pudesse ser executada rapidamente. Há algumas discussões úteis de Vitalik no ethresear.ch aqui (opens in a new tab) e aqui (opens in a new tab) e no Twitter aqui (opens in a new tab). O objetivo de uma resposta social coordenada deve ser muito direcionado e específico sobre a punição do invasor e a minimização dos efeitos para outros usuários.

A governança já é um tópico complicado. Gerenciar uma resposta de emergência de Camada 0 a uma cadeia de finalização desonesta seria, sem dúvida, um desafio para a comunidade Ethereum, mas isso já aconteceu - duas vezes - na história do Ethereum).

No entanto, há algo bastante satisfatório no fato de o último recurso estar no mundo real. Em última análise, mesmo com essa fenomenal pilha de tecnologia acima de nós, se o pior acontecesse, pessoas reais teriam que coordenar sua saída disso.

Resumo

Esta página explorou algumas das maneiras pelas quais os invasores podem tentar explorar o protocolo de consenso de Prova de Participação (PoS) do Ethereum. Reorgs e atrasos de finalidade foram explorados para invasores com proporções crescentes do total de ether em stake. No geral, um invasor mais rico tem mais chance de sucesso porque seu stake se traduz em poder de voto que ele pode usar para influenciar o conteúdo de blocos futuros. Em certos valores limite de ether em stake, o poder do invasor aumenta:

33%: atraso de finalidade

34%: atraso de finalidade, finalidade dupla

51%: atraso de finalidade, finalidade dupla, censura, controle sobre o futuro da blockchain

66%: atraso de finalidade, finalidade dupla, censura, controle sobre o futuro e o passado da blockchain

Há também uma série de ataques mais sofisticados que exigem pequenas quantidades de ether em stake, mas dependem de um invasor muito sofisticado ter um controle preciso sobre o tempo das mensagens para influenciar o conjunto de validadores honestos a seu favor.

No geral, apesar desses vetores de ataque em potencial, o risco de um ataque bem-sucedido é baixo, certamente menor do que os equivalentes de Prova de Trabalho (PoW). Isso se deve ao enorme custo do ether em stake colocado em risco por um invasor que visa sobrecarregar os validadores honestos com seu poder de voto. A camada de incentivos embutida de "cenoura e bastão" protege contra a maioria das más condutas, especialmente para invasores de baixo stake. Ataques mais sutis de salto e balanceamento também têm pouca probabilidade de sucesso porque as condições reais da rede tornam o controle preciso da entrega de mensagens a subconjuntos específicos de validadores muito difícil de alcançar, e as equipes de clientes fecharam rapidamente os vetores de ataque conhecidos de salto, balanceamento e avalanche com patches simples.

Ataques de 34%, 51% ou 66% provavelmente exigiriam coordenação social fora de banda para serem resolvidos. Embora isso provavelmente seja doloroso para a comunidade, a capacidade de uma comunidade responder fora de banda é um forte desincentivo para um invasor. A camada social do Ethereum é o último recurso - um ataque tecnicamente bem-sucedido ainda pode ser neutralizado pela comunidade concordando em adotar uma bifurcação honesta. Haveria uma corrida entre o invasor e a comunidade Ethereum - os bilhões de dólares gastos em um ataque de 66% provavelmente seriam obliterados por um ataque de coordenação social bem-sucedido se fosse entregue com rapidez suficiente, deixando o invasor com grandes quantidades de ether em stake ilíquido em uma cadeia desonesta conhecida ignorada pela comunidade Ethereum. A probabilidade de que isso acabe sendo lucrativo para o invasor é suficientemente baixa para ser um impedimento eficaz. É por isso que o investimento na manutenção de uma camada social coesa com valores estreitamente alinhados é tão importante.