fix links

Author: corwintines

public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md

@@ -4,7 +4,7 @@ description: Aprenda sobre os vetores de ataque conhecidos na prova de participa
 lang: pt-br
 ---
 
-Ladrões e sabotadores estão constantemente buscando oportunidades para atacar o software cliente do Ethereum. Esta página descreve os vetores de ataque conhecidos na camada de consenso do Ethereum e mostra como esses ataques podem ser defendidos. As informações nesta página foram adaptadas de uma [versão longa] (https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs).
+Ladrões e sabotadores estão constantemente buscando oportunidades para atacar o software cliente do Ethereum. Esta página descreve os vetores de ataque conhecidos na camada de consenso do Ethereum e mostra como esses ataques podem ser defendidos. As informações nesta página foram adaptadas de uma [versão longa](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs).
 
 ## Pré-requisitos {#prerequisites}
 
@@ -58,11 +58,11 @@ Essencialmente, todos os ataques com pouco stake são variações sutis de dois
 
 #### reorgs {#reorgs}
 
-Vários artigos descreveram ataques ao Ethereum que realizam reorgs ou atraso de finalidade com apenas uma pequena proporção do total de ethers em stake. Geralmente, esses ataques dependem de o atacante reter algumas informações de outros validadores e, em seguida, divulgá-las de maneira sutil e/ou em algum momento oportuno. Eles geralmente visam deslocar algum(ns) bloco(s) honesto(s) da cadeia padrão. [Neuder et al. 2020 (https://arxiv.org/pdf/2102.02247.pdf) mostrou como um validador atacante pode criar e atestar um bloco ("B") para um determinado slot "n+1", mas evita propagá-lo para outros nós na rede. Em vez disso, eles mantêm o 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 atacante pode liberar seu bloco retido ("B") e suas atestações retidas para ele, além de atestar que "B" é a cabeça da cadeia com seus votos para o slot "n+2", efetivamente negando a existência do bloco honesto "C". Quando o bloco honesto "D" é liberado, o algoritmo de escolha de fork vê "D" construindo sobre "B" como sendo mais pesado do que "D" construindo sobre "C". O atacante conseguiu, portanto, remover o bloco honesto "C" no slot "n+2" da cadeia padrão usando uma reorganização ex ante de 1 bloco. [Um atacante com 34%](https://www.youtube.com/watch?v=6vzXwwk12ZE) do stake tem uma chance muito alta de sucesso nesse ataque, como explicado [nesta nota](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair). Em teoria, porém, esse ataque poderia ser tentado com stakes menores. [Neuder et al 2020](https://arxiv.org/pdf/2102.02247.pdf) descreveu esse ataque funcionando com 30% do stake, mas posteriormente foi demonstrado que ele é viável com [2% do stake total](https://arxiv.org/pdf/2009.04987.pdf) e, depois, até mesmo para um [único validador](https://arxiv.org/abs/2110.10086#) usando técnicas de balanceamento que examinaremos na próxima seção.
+Vários artigos descreveram ataques ao Ethereum que realizam reorgs ou atraso de finalidade com apenas uma pequena proporção do total de ethers em stake. Geralmente, esses ataques dependem de o atacante reter algumas informações de outros validadores e, em seguida, divulgá-las de maneira sutil e/ou em algum momento oportuno. Eles geralmente visam deslocar algum(ns) bloco(s) honesto(s) da cadeia padrão. [Neuder et al. 2020](https://arxiv.org/pdf/2102.02247.pdf) mostrou como um validador atacante pode criar e atestar um bloco ("B") para um determinado slot "n+1", mas evita propagá-lo para outros nós na rede. Em vez disso, eles mantêm o 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 atacante pode liberar seu bloco retido ("B") e suas atestações retidas para ele, além de atestar que "B" é a cabeça da cadeia com seus votos para o slot "n+2", efetivamente negando a existência do bloco honesto "C". Quando o bloco honesto "D" é liberado, o algoritmo de escolha de fork vê "D" construindo sobre "B" como sendo mais pesado do que "D" construindo sobre "C". O atacante conseguiu, portanto, remover o bloco honesto "C" no slot "n+2" da cadeia padrão usando uma reorganização ex ante de 1 bloco. [Um atacante com 34%](https://www.youtube.com/watch?v=6vzXwwk12ZE) do stake tem uma chance muito alta de sucesso nesse ataque, como explicado [nesta nota](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair). Em teoria, porém, esse ataque poderia ser tentado com stakes menores. [Neuder et al 2020](https://arxiv.org/pdf/2102.02247.pdf) descreveu esse ataque funcionando com 30% do stake, mas posteriormente foi demonstrado que ele é viável com [2% do stake total](https://arxiv.org/pdf/2009.04987.pdf) e, depois, até mesmo para um [único validador](https://arxiv.org/abs/2110.10086#) usando técnicas de balanceamento que examinaremos na próxima seção.
 
 ![ex-ante re-org](reorg-schematic.png)
 
-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)
+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)
 
 Um ataque mais sofisticado pode dividir o conjunto do validador honesto em grupos discretos contendo visões diferentes da cabeça da cadeia. Isso é conhecido como um **ataque de balanceamento**. O atacante espera pela sua oportunidade de propor um bloco e, quando ela chega, engana e propõe dois. Ele envia um bloco para metade do conjunto do validador honesto e o outro bloco para a outra metade. O erro seria detectado pelo algoritmo de escolha de fork e o proponente de blocos seria reduzido e removido pela rede, mas os dois blocos ainda existiriam e teriam cerca de metade do conjunto validador atestando cada fork. Enquanto isso, os demais validadores maliciosos retêm suas atestações. Então, ao liberar seletivamente as atestações favorecendo um ou outro fork 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 um ou outro fork. Isso pode continuar indefinidamente, com os validadores atacantes mantendo uma divisão igual de validadores entre os dois forks. Como nenhum fork pode atrair uma supermaioria de 2/3, a rede não seria finalizada.
 
@@ -132,7 +132,7 @@ Seja qual for a penalidade imposta ao atacante, a comunidade também tem de deci
 
 No entanto, isso constituiria um desafio substancial em termos de governança. Alguns usuários e validadores certamente se perderiam ao retornar à cadeia honesta. As transações em blocos validados após o ataque poderiam ser anuladas, perturbando a camada de aplicação, o que simplesmente compromete a ética de alguns usuários que tendem a acreditar que “código é lei”. Agências de câmbio e aplicações teriam provavelmente vinculado ações fora da cadeia a transações na cadeia, que agora podem ser anuladas, começando uma cascata de retratações e revisões que seria difícil de desfazer de forma justa, especialmente se os ganhos obtidos ilicitamente tiverem sido misturados, depositados em DeFi ou em outros derivados com efeitos secundários para usuários honestos. Sem dúvida que alguns usuários, talvez mesmo institucionais, já teriam se beneficiado da cadeia desonesta, seja por esperteza ou por acaso, e poderiam se opor a um fork para proteger seus ganhos. Houve pedidos para ensaiar a resposta da comunidade a ataques de >51% para que uma mitigação coordenada e sensata possa ser executada rapidamente. Há uma discussão útil de Vitalik no ethresear.ch [aqui](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925) e [aqui](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363) e no Twitter aqui. O objetivo de uma resposta social coordenada é o de ser muito direcionada e específica para punir o atacante e minimizar os efeitos para outros usuários.
 
-Governança já é um tema complicado. Gerenciar uma resposta de emergência na Camada 0 para uma cadeia de finalização desonesta seria, sem dúvida, um desafio para a comunidade Ethereum, mas isso [já aconteceu](/history/#dao-fork-summary) — [duas vezes](/history/#tangerine-whistle) — na história da Ethereum).
+Governança já é um tema complicado. Gerenciar uma resposta de emergência na Camada 0 para uma cadeia de finalização desonesta seria, sem dúvida, um desafio para a comunidade Ethereum, mas isso [já aconteceu](/history/#dao-fork-summary) — [duas vezes](/history/#tangerine-whistle) — na história da Ethereum.
 
 No entanto, há algo que é bastante satisfatório na última tentativa no mundo real. Por fim, mesmo com essa pilha fenomenal de tecnologia acima de nós, se o pior alguma vez acontecer, pessoas reais terão de coordenar a solução.